为什么是三次握手和四次挥手[随手笔记]

网上的回答各种各样，总结了一份比较认可的回答.

参考链接

参考链接1

参考链接2

单工、半双工、全双工的解释

三次握手过程

• 客户端将报文段中的SYN=1，并选择一个seq=x，(即该请求报文的序号为x) 将这个报文发送到服务器。此时，客户端进入同步已发送状态（SYN-SEND）.SYN报文段不能携带数据，但是要消耗掉一个序号。

• 服务器收到请求报文后，若同意建立连接，则回复报文中，SYN=1,ACK=1，并选择一个seq = y,且报文中确认号为x+1，序号为y .此时服务器进入同步已接收状态（SYN-RCVD）

• 客户端收到服务器的同步确认后，对服务器发送确认的确认。将ACK=1,确认号为y+1,而报文首部的序号为x+1，将该报文发出后，客户端进入已连接状态（ESTABLISHED）。

• 服务器收到客户端的确认后，也进入已连接状态。

四次挥手过程

• 客户端发送一个FIN，用来关闭客户到服务器的数据传送。
• 服务器收到，发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
• 服务器关闭客户端的连接，发送一个FIN给客户端。
• 客户端发回ACK报文确认，并将确认序号设置为收到序号加1。同时自身等待2MSL就转到CLOSED状态

为什么是三次握手而不是二次或者四次

• 为什么是三次握手而不是两次或者四次：简单的说两次不可靠四次不高效。
  • 具体说明一下为什么两次不可靠：服务器也发送syn到客户端，客户端收到回复ack。这个时候最多可以确定服务器即可以收也可以发，但是对于客户端来说，它并不知道服务器是否收到了自己的回应。
  • 对于为什么不是四次握手，有的解释是1这样的收发数据，其实是通过两个连接完成的，此时的连接是单工的。也有的认为2把三步拆分成四步减慢了传输速率并且资源浪费，我个人认为这个解释更符合自己的理解

确保数据能够完整传输。
当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。
但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，（按照常理的话，第二次和第三次挥手应该一起回复FIN=1和ACK=1的，但是因为服务器端可能有数据没发完，所以不能也立刻去主动申请关闭，所以要把ACK和FIN分开）
再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。

为什么是四次挥手

• 网上对这个问题的回答各有各的理解。我比较认可的下面第一个回答:

 如tcp挥手是三次，fin,fin/ack,ack。现实中是存在的，有时候三次，有时候四次。为何呢？
 
 首先fin是用于关闭从本端到对端的连接，表示本端没有数据给对端了。
 
  对端收到该fin后，会回复ack，这是tcp确认机制的要求。
 
 这时候，本端是不能发送数据给对端，但对端仍然可以发数据给本端。
 
 等对端没数据给本端时，也发送给fin给本端，关闭从对端到本端的连接。
 
 本端收到对端的fin后，回复ack。
 
 到这里，经过四次挥手，双工的tcp连接才完全关闭。
 
 还有一种情况，本端要关闭到对端连接，发送fin给到对端时，刚好对端也没数据给本端，对端就回复fin/ack了。
 
 而是，四次挥手变成三次了。
 
 这也好理解，你没话跟我说(没数据给我)，我既可以有话跟你讲(有数据给你)，也可以对你无言(无数据给你)，选择权在我(回复ack还是fin/ack，我说了算)。
 
 综上，握手一定是三次，挥手既可以是三次，也可以是四次，当然一般都是说四次挥手，没必要咬文嚼字，知道就好。
 

当被动方收到主动方的FIN报文通知时，它仅仅表示主动方没有数据再发送给被动方了。但未必被动方所有的数据都完整的发送给了主动方，所以被动方不会马上关闭SOCKET,它可能还需要发送一些数据给主动方后，（按照常理的话，第二次和第三次挥手应该一起回复FIN=1和ACK=1的，但是因为服务器端可能有数据没发完，所以不能也立刻去主动申请关闭，所以要把ACK和FIN分开）再发送FIN报文给主动方，告诉主动方同意关闭连接，所以这里的ACK报文和FIN报文多数情况下都是分开发送的。