目录
- 1. TCP三次握手/四次挥手
- 2. 在浏览器中输入url地址 ->> 显示主页的过程
- 3. 状态码
- 4. HTTP长连接,短连接
- 5. HTTP是不保存状态的协议,如何保存用户状态?
- 6. Cookie的作用是什么?和Session有什么区别?
- 7. HTTP 1.0和HTTP 1.1的主要区别是什么?
- 8. URI和URL的区别是什么
- 9. HTTP 和 HTTPS 的区别?
- 10. TCP如何实现可靠传输
- 11. OSI七层模型
- 12. TCP与UDP区别
- 12. 什么是操作系统
- 13. 系统调用
- 14. 进程和线程的区别
- 15. 进程间的通信方式
- 16. 线程间的通信方式
- 17. 进程调度算法
- 18. 常见的几种内存管理机制
- 19. 快表和多级页表
- 20. 线程的六种状态
1. TCP三次握手/四次挥手
三次握手四次挥手
第一次握手:客户端TCP进程也先建立传输控制块TCB,然后向服务端发送连接请求报文段,此时SYN=1,随机选定一个初始序号seq=x,,此报文不能携带数据,但是要消耗掉一个序号,发送完毕后,客户端进入SYN-SENT(同步已发送)状态
第二次握手:服务端收到客户端请求连接报文段后,若同意建立连接,则发送确认报文,确认报文中SYN=1、ACK=1,确认号ack=x+1,同时随机选定一个自己序号seq=y,确认报文段同样不能携带数据,但是也要消耗掉一个序号,发送完毕后服务端进入SYN-RCVD(同步收到)状态
第三次握手:客户端收到确认报文后,检查ack是否正确,若正确,则向服务端发送确认报文,发送后进入ESTAB-LISHED状态,服务端收到确认报文后,也进入ESTAB-LISHED状态,此时双方TCP连接正式建立。
上面的连接建立过程就是TCP三次握手。
为什么是三次握手?
为什么client收到确认报文后,还要再发送一次确认报文给server呢?这主要是为了防止已失效的连接请求报文段突然又送到了Server端。
假设现在TCP连接是两次握手机制,如下图server在收到client的连接请求,确认后就进入ESTAB-LISHED状态,会存在这样一种问题:
client发送连接请求报文,由于网络原因,长时间阻塞在某个网络节点上了,于是client重传了一次请求连接报文,第二次请求报文正常达到server,连接正常建立,数据传输完毕后,释放连接。但是假设此时第一次发送的请求报文并没有丢失,而是延误一段时间才到达server,这本是已失效的连接请求报文段,但是server收到后,会以为是client重新发送的连接请求,于是向client发送确认报文后,进入ESTAB-LISHED状态,但是client并没有发出新建连接的请求,就会忽略server的确认报文,server却在一直等待client发送数据,导致server资源浪费严重。
总结起来看,TCP三次握手过程就是client与server在相互确认各自发送和接收是否正常的过程:
第一次握手:client—>server,server确认了cilent的发送能力和自己的接收能力是正常的
第二次握手:server—>client,client确认了自己的发送能力和server的接收能力是正常的,但是server此时不清楚自己的发送能力是否正常
第三次握手:client—>server,server确认了自己的发送能力正常,同时也表明双方也都确认完毕,可以开始传输数据。
建立一个连接需要三次握手,而终止一个连接要经过四次挥手(也有将四次挥手叫做四次握手的)。这由TCP的半关闭(half-close)造成的。所谓的半关闭,其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。
TCP 连接的拆除需要发送四个包,因此称为四次挥手(Four-way handshake),客户端或服务端均可主动发起挥手动作。
刚开始双方都处于ESTABLISHED 状态,假如是客户端先发起关闭请求。四次挥手的过程如下:
第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
即发出连接释放报文段(FIN=1,序号seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN_WAIT1(终止等待1)状态,等待服务端的确认。
第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于 CLOSE_WAIT 状态。
即服务端收到连接释放报文段后即发出确认报文段(ACK=1,确认号ack=u+1,序号seq=v),服务端进入CLOSE_WAIT(关闭等待)状态,此时的TCP处于半关闭状态,客户端到服务端的连接释放。客户端收到服务端的确认后,进入FIN_WAIT2(终止等待2)状态,等待服务端发出的连接释放报文段。
第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
即服务端没有要向客户端发出的数据,服务端发出连接释放报文段(FIN=1,ACK=1,序号seq=w,确认号ack=u+1),服务端进入LAST_ACK(最后确认)状态,等待客户端的确认。
第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于 CLOSED 状态。
即客户端收到服务端的连接释放报文段后,对此发出确认报文段(ACK=1,seq=u+1,ack=w+1),客户端进入TIME_WAIT(时间等待)状态。此时TCP未释放掉,