tcp netstat用法 TIME_WAIT状态解析 MTU以及MSS

带着问题写博客

问题1：使用netstat查看有源TCP连接的状态时，经常会看到established状态，那么还有哪些状态，这些状态是如何变化的呢？

问题2：TIME_WAIT状态存在的必要？

问题3：MTU和MSS之间的关系？

1. 当网络出现异常时，netstat可以查看某个有源链接的状态。在了解这些状态的意义之前，必须先理清tcp的连接步骤，使用netstat后显示如下：

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 2 210.34.6.89:telnet 210.34.6.96:2873 ESTABLISHED

tcp 296 0 210.34.6.89:1165 210.34.6.84:netbios-ssn ESTABLISHED

tcp 0 0 localhost.localdom:9001 localhost.localdom:1162 ESTABLISHED

tcp 0 0 localhost.localdom:1162 localhost.localdom:9001 ESTABLISHED

tcp 0 80 210.34.6.89:1161 210.34.6.10:netbios-ssn CLOSE

Active UNIX domain sockets (w/o servers)

Proto RefCnt Flags Type State I-Node Path

unix 1 [ ] STREAM CONNECTED 16178 @000000dd

unix 1 [ ] STREAM CONNECTED 16176 @000000dc

unix 9 [ ] DGRAM 5292 /dev/log

unix 1 [ ] STREAM CONNECTED 16182 @000000df

这里，只分析正常情况下的状态变化图。套接字的状态主要分CLOSED、LISTEN、SYN_RCVD、SYN_SENT、ESTABLISHED、CLOSE_WAIT、LAST_ACK、FIN_WAIT_1、FIN_WAIT_2、CLOSING、TIME_WAIT。

1. 先讨论服务端套接字：

    1. 套接字以CLOSED状态为初始状态；
    2. 调用listen接口开启监听，进入LISTEN状态。很多书上将这种打开称为被动打开，这是站在套接字本身的角度去说的。其实，站在程序员的角度上，应该也可以说是主动打开；
    3. 当有客户端试图连接时。tcp将进入三次握手环节。首先，服务端收到SYN，之后发送ACK以及本身的SYN。接着进入SYN_RCVD；
    4. 接收到客户端返回的ACK之后，就进入了ESTABLISHED状态。这个状态是可以正常手法数据的状态；
    5. 这里假设关闭由客户端发起。那么服务端将收到FIN，那么在发送ACK之后，进入CLOSED_WAIT，这个FIN实际上是双方商量通讯即将关闭，快去完成善后工作；
    6. 在CLOSED_WAIT阶段等待，如果read=0，那么代表客户端已完成工作。于是调用close再回复给客户端FIN，进入LAST_ACK状态。这个FIN是正式通知，可以结束了；
    7. 在收到客户端回复的ACK之后，直接进入CLOSED状态。

2. 再分析客户端套接字：

    1. 初始状态是CLOSED状态；
    2. 调用connect试图连接服务端。将给给服务端发送一个SYN，并进入SYN_SENT状态等待回复；
    3. 如愿以偿收到ACK以及服务端的一个SYN，发送一个ACK之后，直接进入ESTABLISEHED状态；
    4. 客户端主动关闭，那么将发送一个FIN通知，并进入FIN_WAIT_1；
    5. 如愿以偿收到ACK，进入FIN_WAIT_2，当然，如果有时候服务器处理迅速，同时回复了ACK和FIN，这个状态将省略，如下所述；
    6. 接着收到服务端的正式FIN通知，回复ACK后进入TIME_WAIT状态；
    7. 在2MSL超时后，进入初始状态CLOSED。

1. 上面分析到TIME_WAIT状态，客户端进入此状态后，需要等待2MSL后，才真正回到CLOSED状态。而这就是为什么在故障时，立即再次执行服务端程序会失败的主要原因。下面容我从来慢慢解释：
   1. 什么是MSL？
      
      MSL全称是Maximum Segment Lifetime，即“报文最大生存时间”。对应于ip头的TTL域，tcp传输层也有相似的概念。MSL就是通过TTL计算出来的一个时间，一般情况下，要略大于TTL的时间。
   2. 为什么要等待2MSL？
      
      主要有两个原因：
      1. 由上个问题知道，服务端发送正式的FIN给客户端后，就直接等待ACK，只要等待ACK后，就直接关闭了。那么客户端其实并不知道服务端是否收到了这个ACK。但是这里又不能让服务端接收到ACK后也回复一个ACK后给客户端，因为这是同样的道理，服务端如果也回复ACK，那么也不知道这个ACK客户端到底有没有接收到。考虑到，报文在网络中存在的时间最长是MSL。假设客户端最后回复的ACK在网络中丢失了。那么，此时服务端正处于LAST_ACK状态，即发生了发出正式FIN，但是超时对方无回复，那么会再次发送正式FIN通知。这个FIN在网络中最多也存在1个MSL，加起来正好是最大是2MSL。
      2. 第二个理由实际上，只需要等待1MSL即可。由于tcp是面向连接的，而且对于每次连接没有一个全局的标志来确定属于哪次连接。假设一对套接字对，在通讯过程中，发生了超时，那么这些包在TIME_WAIT状态时，还可能也存在网络中，这些包可能在最终，又到达了目的地。这种情况下，如果有TIME_WAIT状态，那么tcp可以很好的处理这个信息。但是如果没有TIME_WAIT状态，tcp将分不清楚这个包到底是哪次连接的，这可能会造成混乱以及信息安全等方面问题。
   3. 可以通过什么方式避免设置这个超时等待么？
      
      可以。SCTP就使用了其他方式进行管理。

3. MTU指一种通信协议的某一层上面所能通过的最大数据包大小（以字节为单位），但是因为ipv4几乎统治通信界，说到MTU，通常说的是ip层的最大数据包的大小。对于ipv4，一般默认是1500，这是为了能够和ipv6通用。因为除了MTU还有一种最小的限制，对于ipv4来说，最小是576，对于ipv6来说，最小是1500.MSS是tcp层的一个域，用以表征分节的最大数据量，同样用字节表示。

1. tcp在建立连接阶段，发送SYN的时候，会附带自身的MSS。对于ipv4来说，MSS值最大是65535，用16位字节表示。一般情况下，MSS不会设置太大，因为如果与ip层MTU不匹配的话，会造成ip层的分包，可能会影响性能和稳定性。
2. 因此，MSS值一般是MTU-ip头-tcp头。对于ipv4来说，ip头占20，ipv6占40.tcp头始终占20.因此，在默认MTU为1500的情况下，一般MSS都会是1460.