完整流程#

要解决的问题#

三报文握手#

1. 发送TCP连接请求报文段
   • 同步位SYN被设置为1；TCP规定SYN被设置为1的报文段不能携带数据。
   • 序号字段seq被设置为x
2. 向TCP客户端进程发生TCP连接请求确认报文段
   • ack = x + 1，是对TCP客户端进程所选择的初始序号的确认
   • 同步位SYN和确认位ACK都设置为1，表面这是一个TCP连接请求确认报文段
3. 给TCP服务器发送一个普通的TCP确认报文段，进入连接已建立状态
   • TCP双方都进入连接已建立状态
   • seq = x +1确认第一次连接，ack = y+1确认第二次连接

能不能使用“两报文握手”进行连接#

如果是两报文握手，TCP服务器会先进入连接已建立状态，此时TCP客户端可能有多个TCP请求，会造成TCP服务器进入状态，客户端没有进入状态的情况，造成资源浪费

三报文就会是TCP客户端进入连接已建立状态，每一次请求连接都不会造成服务器浪费

”四报文挥手”释放连接#

1. 客户端中的应用进程通知其TCP释放连接（主动关闭），TCP客户进程发送TCP连接释放报文段，并进入终止等待1状态，该报文段的首部终止位为1（FIN=1），确认位（ACK=1）表明这是一个TCP连接释放报文段，序号seq的值为u(它等于之前发送的报文最后一个字节的序号加一)。（TCP规定FIN设置为1的报文段即使不携带数据也要消耗掉一个序号），确认号ack的值为v(它等于TCP客户进程之前已收到的最后一个字节的序号加一)。
2. 服务器 收到TCP客户端发送的TCP连接释放报文段后发送了一个TCP确认报文段，并处于关闭等待状态。该报文段的首部位ACK设置为1，表明这个是一个普通的ACK确认报文段，序号seq设置为v(TCP服务器进程之前已传送过的最后一个字节的序号位+1，也与之前TCP服务器端收到的确认号匹配)，确认号ack字段设置为u+1(这是对TCP连接释放报文段的确认)。
3. 如果此时TCP服务器进程仍有数据要发送，那么TCP客户进程会进行数据的接收，此时TCP客户端处于终止等待2状态，如果TCP服务器进程没有数据要发送，那么其发送TCP连接释放报文段并进入最后确认状态。TCP连接释放报文段的终止位FIN设置为1，ACK设置为1，表明这是一个TCP连接释放报文段，并对之前收到的报文段进行确认。TCP连接释放报文段的seq值为w（可能由于TCP服务器又发送了一些数据），ack设置为u+1（是对TCP连接释放报文的序号进行确认）。
4. TCP客户进程根据服务器的TCP服务端进程发送的TCP连接释放报文段，发送一个TCP确认报文段，并处于时间等待状态。确认位ACK的值设置为1，seq的值设置为u+1（因为TCP连接释放的序号值为u虽然不携带数据但是要消耗掉一个序号），确认号ack的值设置为w+1,这是对所收到的TCP连接释放的确认。

为什么要经过2MSL时间而不直接进入关闭状态呢？#

这是因为如果直接进入关闭状态，而TCP客户端发送的TCP确认报文段进行了丢失，那么TCP服务器端就接收不到最后的TCP确认报文段，TCP服务器端就会一直重传TCP连接释放但此时的TCP客户端已经处于关闭状态，就会对TCP服务器端发送的TCP连接释放不理睬，那TCP服务器端就会一直发送TCP连接释放，最终造成资源的浪费。

是看客户端是否接收完数据，所以服务器要最后确认接收完才关闭