TCP的运输连接管理

TCP的运输连接管理

参考谢希仁的《计算机网络》第七版的5.9节

TCP的连接建立——“三次握手”

参考谢希仁的《计算机网络》第七版5.9.1这一节关于“三次握手”的论述，TCP建立连接时进行的是“three way handshake”，也就是“三报文握手”，即一次握手交换了三次报文，这等同于一次握手，手上下摇晃了三下，而不是三次握手

即便上述的解释如此，但为了方便后续描述，我依然使用“三次握手”的说法

这里我不对“三次握手”过程中具体的序号以及信号位变化作过多的阐述，而是着重于说明为什么需要“第三次握手”

客户机A想要与服务器B建立TCP连接，所以A向B发送了一个连接请求报文（第一次握手），此时B正常接收到了该请求报文，于是向A发送确认连接报文（第二次握手），A收到确认连接报文后就向B发送一个确认报文（第三次握手），用以向B确认自己收到了B的确认连接报文

以上就是“三次握手”的大致过程

实际上“三次握手”还可以实践为“四次握手”，也就是将“第二次握手”时发送的确认连接报文分为两个报文发送：确认连接报文包含确认报文和同步报文，那么可以将此报文拆分为确认报文发送一次，同步报文再发送一次（这和一次发送等效，所以既然三次能解决的问题没必要分为四次）

当A收到了来自B的确认连接报文，就会进入ESTABLISHED状态，也就是确认状态，那么为什么还要向B再发送一个确认报文呢？
这是为了避免由“已失效的连接请求报文”导致的差错
这个意思是说当A向B发送连接请求报文的时候，该连接请求报文可能会在网络中丢失（彻底失效而不再影响后续连接的报文），这样A在一段时间后没有收到确认连接的报文可以选择重新发送一次连接请求报文，这样当连接请求报文被B接收到时，B向A发送确认连接报文就可以建立连接了。此时没有“第三次握手”也可以。
但是有一种情况是A发出的请求报文在网络中的一个节点滞留了太久，导致A以为这个报文已经丢失了（这就是“已失效的连接请求报文”），而此时A又不重新发送新的连接请求。到一段时间后，那个滞留了的连接请求报文可能会最终到达B，这时候B就很自然地向A发送确认连接报文，但此时A并没有向B发送连接请求，并没有在等待B的确认，所以不会理会B发送的确认连接报文。而如果此时并不存在“第三次握手”，这就会导致B一直留出部分资源维持连接，等待A传输数据过来，这就会导致服务器资源的浪费；但如果此时有“第三次握手”，那么B在等了一段时间后没有等到由“第三次握手”带来的确认报文，就会知道A并没有在等待B的连接，B就可以释放占用的资源而不用白白地等待了

由于一次交互就需要一个请求和一个响应共”两次握手“，而为了避免由于”已经失效的连接请求“导致的差错，需要A向B再发一次确认，另需要一次“握手”，所以共需要“三次握手”

TCP的连接释放——“四次挥手”

这里我不对“四次挥手”过程中具体的序号以及信号位变化作过多的阐述，而是着重于说明为什么需要“四次挥手”来完成连接释放，以及最后一次挥手后的 2 MSL 时间的作用（MSL，Maximum Segment Lifetime，最长报文段寿命）

要知道为什么需要“四次挥手”才能释放连接，只要知道这“四次挥手”起到了什么作用就可以了

当客户机A想要释放与服务器B的连接，则需要主动向B发送一个连接释放请求（第一次挥手）并停止发送数据，B收到这个报文后就向A发送一个确认释放报文（第二次挥手）。要注意这时A与B之间的连接并没有完全关闭，而是处于半关闭状态，也就是A已经没有数据要发送了，而B还可以向A发送数据。当一端时间后B不再向A发送数据时，B就向A发送连接释放报文（第三次挥手），这时A如果收到报文后就向B发送确认释放报文（第四次挥手），当B进入关闭状态后的大概 2 MSL 时间后A也进入关闭状态，至此连接彻底释放
所以需要四次挥手的原因就是A和B之间连接的释放分为了两段，一段释放一半的连接，先释放A向B方向的数据传输连接，再释放B向A方向的数据传输连接，这是因为当A主动请求断开连接时，A这边已经非常确定地停止了数据传输，但B那边可能还有数据没有发送完毕，所以需要A再等一会儿后在进一步的释放连接。
而一次交互自然会有一个请求和一个响应共“两次挥手”，而连接的释放分为了两段，有两次交互，自然也就需要“四次挥手”了

可以注意到A在“第四次挥手”后并没有直接进入关闭状态，而是等待了 2 MSL 的时间，这么做有两个原因：

1. 防止A“第四次挥手”时发送的确认报文丢失导致B无法正常进入关闭状态
   A发送的这个确认报文可能会丢失，如果A在发送确认报文后立刻进入关闭状态，那么如果报文丢失了，B则无法正常进入关闭状态。由于收不到来自A的确认，B会不停重复“第三次挥手”，并且一直无法进入关闭状态。如果A不立即进入关闭状态，而是等 2 MSL 时间，则B可以在得不到确认时重新发送连接释放请求，此时A并没有进入关闭状态，可以接收到B的请求，那么A就重传确认释放报文（等待时间重新设置为 2 MSL）；如果B收到了A的确认就会进入关闭状态，那么A在2 MSL 时间就不会再次收到B的新释放请求，这样A就可以进入关闭状态了
2. 防止“已经失效的连接请求报文”出现在新连接中
   在A和B连接时，可能会存在一些滞留在网络中的报文段，经过2 MSL 时间后才进入关闭状态可以使这些报文段从网络中消失，而不至于影响后续新的连接

服务器B实际上还会设置一个保活计时器（keepalive timer）来避免客户机A由于故障而无法正常保持和关闭连接的情况。这个保活计时器一般设置为2小时，当A向B发送数据，计时器就会重新设置为2小时，而当A超过两小时没有向B发送数据，B就会每隔75秒向A发送一个探测报文，当10个这样的探测报文发出去后一直没有得到响应，B就会认为A出现故障，主动的断开连接，回收资源