目录
1、三次握手:为了建立长链接进行交互即建立一个会话,使用http/https协议
一、三次握手 四次挥手
1、三次握手:为了建立长链接进行交互即建立一个会话,使用http/https协议
① :客户端产生初始化序列号s eq=x ,向服务端发送建立连接的请求报文,将 SYN=1 同步序列号;② :服务端接收建立连接的请求之后,产生初始化序号s eq=y ,并发送一个确认号(a ck=x+1) ,向客户端发送 建立连接的请求(SYN=1 ),确认客户端的数据 (ACK=1)③ :客户端收到服务端的回复(a ck=y+1 ,包含收到请求,确认信号), ACK=1 ,确认客户端的数据,三次握手 成功
序列号 (seq):用来标识从计算机A发送到计算机B的数据包的序号,计算机发送数据时对此进行标记。
确认号(ack):表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。
控制位:描述了A B 两台电脑目前处于什么状态 ,分别为 URG、ACK、PSH、RST、SYN、FIN
URG(紧急位) | 紧急指针(urgent pointer)有效。 |
ACK(确认位) | 确认序号有效。 |
PSH(急切位) | 接收方应该尽快将这个报文交给应用层。 |
RST(重置位) | 重置连接。 |
SYN(同步位) | 建立一个新连接。 |
FIN(断开位) | 断开一个连接。 |
2、四次挥手是一个断开连接释放服务器资源的过程
- 第一次挥手:客户端向服务器发送FIN报文(FIN=1,seq=u),发完后进入 FIN-WAIT-1 状态,即主动关闭TCP连接,不再发送数据,但可以接收服务器发来的报文,等待服务器回复
- 第二次挥手:服务器接到FIN报文后,返回一个ACK报文(ACK=1,ack=u+1,seq=v),表明自己接收到此报文,服务器进入 CLOSE-WAIT 关闭等待状态,此时客户端就知道服务端接到自己的断开连接请求,进入到 FIN-WAIT-2 状态,TCP处于半关闭状态,但服务器端可能还有数据要传输。
- 第三次挥手:服务器关闭客户端连接,发送FIN报文(FIN=1,seq=w,ack=u+1)给客户端,此时服务器处于 LAST-ACK 状态,等待客户端回应。
- 第四次挥手:客户端收到FIN报文后,发送一个ACK(ACK=1,ack=w+1,seq=u+1)给服务器作为应答,此时客户端处于 TIME-WAIT 状态,这个状态是为了等待足够的时间以确保TCP接收到连接中断请求的确认。
- 注意:这时服务器到客户端的TCP连接并未被释放,客户端需要经过等待2MSL(MSL表示一个报文的来回时间)后才会进入 CLOSED 状态,这样做的目的是确保服务器收到自己的ACK报文,如果在规定时间没有收到客户端发的ACK,那么服务器会重发FIN,客户端再次收到FIN报文,就知道自己的ACK丢了,然后会重发ACK给服务器。服务器收到ACK后,就会关闭连接,处于CLOSE状态了。
关于三次握手 和 四次挥手里的一些问题
- 防⽌客户端最后⼀次发给服务器的确认在⽹络中丢失以⾄于客户端关闭,⽽服务端并未关闭,导致资源的浪费。
- 等待最⼤的2msl可以让本次连接的所有的⽹络包在链路上消失,以防造成不必要的⼲扰。
客户端为什么会要有 TIME-WAIT 状态:
- 如果最终的ACK丢失,服务器会重发FIN,客户端必须维护TCP状态信息以便可以重发最终的ACK,否则就发送RST(TCP连接出错),结果服务端认为发生错误。
- TCP实现必须可靠地终止连接的两个方向(全双工关闭),客户端必须进入TIME_WAIT状态,以免可能出现重发ACK的情形。
为什么连接的时候是三次握手,关闭的时候却是四次握手?
因为握手的时候并没有数据传输,所以服务端的 SYN 和 ACK 报文可以一起发送 ,但是挥手的时候有数据在传输,所以 ACK 和 FIN报文不能同时发送,需要分两步,所以会比握手多一步。
为什么三次挥手不行
因为服务端在接收到FIN, 往往不会立即返回FIN ,必须等到服务端所有的报文都发送完毕了,才能发FIN。因此先发一个ACK表示已经收到客户端的FIN,延迟一段时间才发FIN。这就造成了四次挥手。
如果是三次挥手会造成:
如果将服务端的两次挥手合为一次,等于说服务端将ACK和FIN的发送合并为一次挥手,这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端,从而让客户端不断的重发FIN。所有只能第二次握手先发送ACK确认接收到了客户端的数据,等服务器发送完了数据,再发送FIN包进行第三次挥手。