2018 April 20 TCP

TCP三次握手与四次挥手

TCP三次握手过程

客户端向服务器端发送SYN包（SYN=x），并进入SYN_SEND状态，等待服务器确认。

服务器端收到SYN包，确认客户的SYN，即发送ACK=x+1，同时自己也发送一个SYN标志（syn=y），即向客户端发送（ack+syn）包，服务器进入SYN_RECV状态。

客户端收到服务器端的syn+ack包，想服务器发送ack（ack=y+1）。此包发送完毕，客户端和服务器端进入established状态，完成三次握手。

三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方的任何一方主动关闭连接之前，TCp连接将被一直保持下去。

主动关闭方发送一个FIN（seq=u）（用来关闭主动方到被动关闭方的数据传送，也就是主动方告诉被动关闭方：我不会给你传数据了）。（在FIN包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据），此时，主动关闭方可以接收数据。

被动关闭方收到FIN包后，发送一个ack给对方，确认序号ack=u+1。

被动关闭方发送一个FIN包（seq=m），用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉朱动关闭方：我的数据也发送完了，不会再给你传数据了。

主动关闭方收到FIN后，发送一个ACK（ack=m+1）。至此，完成四次挥手。

如果把三次握手改为两次握手，就可能发生死锁。假定A给B发送一个连接请求，B收到了这个请求，并发送了一个确认应答。按照两次握手规定，B认为连接已经成功建立了，可以开始发送数据了。

而若B的确认应答在传输中被丢失，A将不知道B是否已准备好，也不知道B发送数据所用的初始序列号，A甚至怀疑B是否收到了自己的连接请求。在这种情况下，A认为连接还未成功，将忽略B发送的任何数据，只等待B的连接确认应答。而B在发出的数据超时后，重复发送同样的分组，这样就形成了死锁。