三次握手
TCP连接是通过三次握手来连接的
- 第一次握手
当客户端向服务器发起连接请求报文段时,客户端会发送同步序列标号SYN
到服务器,在这里我们设SYN
为m,这时客户端的状态为SYN_SENT
,等待服务器确认。
- 第二次握手
当服务器收到客户端发送的SYN
后,服务器要做的是确认客户端发送过来的SYN
,在这里服务器发送确认包ACK
,这里的ACK
为m+1,意思是说“我收到了你发送的SYN
了”,同时,服务器也会向客户端发送一个SYN
包,这里我们设SYN
为n。这时服务器的状态为SYN_RECV
。
服务器端一共发送了SYN
和ACK
两个包
- 第三次握手
客户端收到服务器发送的SYN
和ACK
包后,需向服务器发送确认包ACK
,“我也收到你发送的SYN了,我这就给你发个确认过去,然后我们即能合体了”,这里的ACK
为n+1,发送完毕后,客户端和服务器的状态为ESTABLISH
,即TCP连接成功
在三次握手中,客户端和服务器端都发送两个包SYN
和ACK
,只不过服务器端的两个包是一次性发过来的,客户端的两个包是分两次发送的
四次挥手
当客户端和服务器通过三次握手建立了TCP连接以后,当数据传送完毕,肯定是要断开TCP连接的啊。那对于TCP的断开连接,这里就有了神秘的“四次挥手”
当A端(主机1) 和B端(主机2)要断开连接时,需要四次握手,这里称为四次挥手。
断开连接请求可以由客户端发出,也可以由服务器端发出,在这里我们称A端向B端请求断开连接。
- 第一次挥手
A端向B端请求断开连接时会向B端发送一个带有FIN
标记的报文段,这里的FIN
是FINish
的意思,此时,主机1进入FIN_WAIT_1
状态;这表示主机1没有数据要发送给主机2了;
- 第二次挥手
B端收到A发送的FIN
后,B段现在可能现在还有数据没有传完,所以B端并不会马上向A端发送FIN
,而是先发送一个确认序号ACK
,意思是说“你发的断开连接请求我收到了,但是我现在还有数据没有发完,请稍等一下呗”。 主机1进入FIN_WAIT_2
状态;
- 第三次挥手
当B端的事情忙完了,那么此时B端就可以断开连接了,此时B端向A端发送FIN
序号,意思是这次可以断开连接了。同时主机2进入LAST_ACK
状态;
- 第四次挥手
A端收到B端发送的FIN后,会向B端发送确认ACK
,然后主机1进入TIME_WAIT
状态;主机2收到主机1的ACK
报文段以后,就关闭连接;此时,主机1等待两个MSL后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。
MSL是Maximum Segment Lifetime,最大报文段生存时间,2个MSL是报文段发送和接收的最长时间。
三次握手(连接)和四次挥手(断开)
两次握手可以么?
TCP连接时是三次握手,那么两次握手可行吗?
在《计算机网络》中是这样解释的:已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送ACK包。这样就会白白浪费资源。
而经过三次握手,客户端和服务器都有应有答,这样可以确保TCP正确连接。
为什么TCP连接是三次,挥手确是四次?
在TCP连接中,服务器端的SYN和ACK向客户端发送是一次性发送的,而在断开连接的过程中,B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后,B端可能还有数据要传输,所以先发送ACK,等B端处理完自己的事情后就可以发送FIN断开连接了。
为什么在第四次挥手后会有2个MSL的延时?
前文说到
MSL是Maximum Segment Lifetime,最大报文段生存时间,2个MSL是报文段发送和接收的最长时间。
假定网络不可靠,那么第四次发送的ACK可能丢失,即B端无法收到这个ACK,如果B端收不到这个确认ACK,B端会定时向A端重复发送FIN,直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。