三次握手、四次挥手相关问题

Q1：问什么要进行三次握手

A1：TCP学习总结(四)

• 主要是 为了防止"已失效的连接请求报文段"突然又传到了服务端B而产生错误
  • 所谓"已失效的连接请求报文段"是这样产生的：
  • 正常情况：
    • A发出连接请求，但因连接请求报文 丢失 而未收到确认
    • 于是A再重传一次连接，然后收到了重传连接的确认，建立连接，数据传输完毕，释放了连接
    • 由于第一个是丢失了，第二个到达了B，所以没有"已失效的连接请求报文段"
  • 异常情况：
    • A发出的第一个请求没有丢失，而是在某个网络节点 滞留，以致延误到连接释放以后的某个时间才到达B
    • 本来就是一个失效的报文段，但B收到此失效的连接请求报文段后，就误认为是A又发出一次新的连接请求就建立了新的连接
    • 由于现在A并没有发出连接请求，不会理睬B的确认，也不会向B发送数据
    • 而B以为新的运输连接已经建立了，并一直等待A发来数据，B的许多资源就这样白白浪费了
  • 而A发送第三次握手，就可以防止上述现象的发送
  • A不会向B的第二次握手发出确认：B由于收不到确认，超时后就不会为此建立连接

Q2：TIME_WAIT 等待多久以及原因

A2： 解决TIME_WAIT过多造成的问题
1、2MSL（最长报文段寿命）;
2、TIME_WAIT状态存在的理由：

• 可靠地实现TCP全双工连接的终止
  • 在进行关闭连接四次挥手协议时，最后的ACK是由主动关闭端发出的，如果这个最终的ACK丢失，服务器将重发最终的FIN，因此客户端必须维护状态信息允许它重发最终的ACK
• 允许老的重复分节在网络中消逝（防止3次握手中提到的"已失效的连接请求报文段"出现）
  • 有可能出现这种情况：前一个连接的迷途重复分组在前一个连接终止后出现，从而被误解成从属于新的化身
  • 为了避免这个情况，TCP不允许处于TIME_WAIT状态的连接启动一个新的化身，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个TCP连接的时候，来自连接先前化身的重复分组已经在网络中消逝

A3：TCP 连接有一方宕机怎么解决

Q3：TCP学习总结(四)

• 保活计时器(keepalive timer)
  • 服务端每收到一次客户的数据就重新设置保活计时器，时间的设置通常是2小时
  • 若2小时内没有收到客户端的数据，服务器还不会放弃它，以后每隔75分钟发送一次探测保文段
  • 若连续发送了10次探测保文段后，客户端仍无响应，服务器就认为客户端出现了故障，然后就关闭了这个连接
• 时间等待计时器