tcp状态机

标签：内核   相同   操作系统   sea   问题   服务器端   ast   exception   数据   

tcp共有11种状态，其中涉及到关闭的状态有5 个。这5 个状态相互关联，相互纠缠，而且状态变化触发都是由应用触发，但是又涉及操作系统和网络，所以正确的理解TCP 在关闭时网络状态变化情况，为我们诊断网络中各种问题，快速定位故障有着非常重要的作用和意义。

TCP连接的建立到关闭，需要经历以下状态迁移（假定Client发起连接，并主动关闭连接）：

• Client

　　CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

• Server

　　CLODED -> LISTEN -> SYN_RECEIVED -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

• 两个主要的错误状态分析

1. CLOSE_WAIT
   1. 服务器端收到客户端（主动关闭方）发来的fin，等待自己发送ack和fin。、
   2. 原因：客户端频繁的发送fin，主动关闭方频繁调用close（）？
2. TIME_WAIT
   1. 客户端收到服务器端发来的fin，等待自己发送最终的ack。
   2. 原因：服务器端没有收到最后的ack，重复发送fin。被动关闭方频繁调用close（）？网络原因？？？

   3. TCP不允许处于TIME_WAIT状态的socket 建立一个连接。处于TIME_WAIT状态的 socket 在等待了两倍的MSL时间之后，将会转变为CLOSED状态。这里TIME_WAIT状态持续的时间是2MSL（MSL是任何IP数据报能够在因特网中存活的最长时间），足以让这两个方向上的数据包被丢弃（最长是2MSL）。通过实施这个规则，我们就能保证每成功建立一个TCP连接时，来自该连接先前化身的老的重复分组都已经在网络中消逝了

      • MSL( 最大分段生存期 ) 指明 TCP 报文在 Internet 上最长生存时间，每个具体的 TCP 实现 都必须选择一个确定的 MSL 值。 RFC 1122 建议是 2 分钟，但 BSD 传统实现采用了 30 秒。
   4. 解决：将内核参数MSL设置的短一些，快速的结束这一次tcp连接

   5. TIME_WAIT存在的两个理由就是

      1. 可靠地实现TCP全双工连接的终止；
         • 如果不维持这个状态信息，那么主动方将回到CLOSED状态，并对被动方重发的FIN包响应RST包，而被动关闭方将此包解释成一个错误（在Java中会抛出connection reset的SocketException)。因而，要实现TCP全双工连接的正常终止，必须能够处理四次握手协议中任意一个包丢失的情况，主动关闭方必须维持状态信息进入TIME_WAIT状态。
      2. 允许老的重复分节（数据报）在网络中消逝。
         • 如果 TIME_WAIT 状态保持时间不足够长 ( 比如小于 2MSL) ，第一个连接就正常终止了。 第二个拥有相同相关五元组的连接出现，而第一个连接的重复报文到达，干扰了第二个连接。 TCP 实现必须防止某个连接的重复报文在连接终止后出现，所以让 TIME_WAIT 状态保持时间足够长 (2MSL) ，连接相应方向上的 TCP 报文要么完全响应完毕，要么被丢弃。建立第二个连接的时候，不会混淆。
         • 使用 SO_REUSEADDR 选项，如果使用同一个五元组，可能收到上一个连接的报文的情况，慎用
           • 这个套接字选项通知内核，如果端口忙，但 TCP 状态位于 TIME_WAIT ，可以重用端口。如果端口忙，而 TCP 状态位于其他状态，重用端口时依旧得到一个错误信息，指明 " 地址已经使用中 " 。 如果你的服务程序停止后想立即重启 ，而新套接字依旧使用同一端口，此时 SO_REUSEADDR 选项非常有用。　　

tcp状态机

标签：内核   相同   操作系统   sea   问题   服务器端   ast   exception   数据   

原文地址：http://www.cnblogs.com/bier/p/6122367.html