聊点TCP干货

那么在应用层则是调用socket.close()会执行FIN的发送，如果服务器出现大量CLOSE_WAIT状态的连接，那么有可能的原因：

• 服务器压力过大，根本来不及调用close
• 存在连接泄露问题(Bug)，服务器未及时关闭连接

问题4. timewait 会带来什么问题

当客户端收到了对方的FIN时，会进入TIMEWAIT状态，此时会保持一段时间再进入CLOSE状态。

这么做的原因主要还是为了可靠的关闭连接。在将TCP 进行可靠性设计之时就考虑了许多网络的不稳定性的因素，比如：

发送给对方的ACK 可能会无法及时收到，此时对方可能重传FIN过来，如果提前进入CLOSE则会返回RST而不是ACK，就会影响关闭流程。

因此 TIMEWAIT 状态默认会持续一段时间，直到确认不会再有重传的数据包之后再安全的关闭。

黑板：这里timewait的持续时间默认是 2*MSL(总共1分钟)，这个MSL叫Max Segment Lifetime，也就是关于一个数据包在网络中传输的最大生命周期的预设。 MSL默认是30s，当然这个值在现在已经可以大幅度缩减。可见在当时在设计之初，网络状况有多么的糟糕。

那么timewait会带来什么问题?

如果频繁的主动关闭连接，可能会产生大量 timewait，由于timewait 的连接占用了一个句柄及少量内存(4K)，那么就有可能会影响其他连接的建立，比如：

该如何解决：

• 重用连接，避免频繁关闭，比如使用连接池
• 参数调优，比如开启tcptwreuse选项支持timewait连接的重复使用。

黑板：HTTP 协议里头发现了timewait的问题，于是在 HTTP 1.1 中定义了 KeepAlive 用来支持连接的重用。

问题5. RST 是什么，为什么会出现

RST 是一个特殊的标记，用来表示当前应该立即终止连接。以下这些情况都会产生RST：

• 向一个未被监听的端口发送数据
• 对方已经调用 close 关闭连接
• 存在一些数据未处理(接收缓冲区)，请求关闭连接时，会发送RST强制关闭
• 某些请求发生了超时

RST 机制有时候也会被利用，做一些端口的扫描，如下：

-> 端口开启，可接受SYN

-> 端口关闭，响应RST

小结

原文只是想总结下 TCP 参数调优的几个细节，没想到TCP 牵扯出来的东西实在太多，光是一个简单的握手、挥手流程就存在这么多的细节和坑。

可以说为了保证数据传输的可靠性，早期的设计者确实考虑了太多的东西。当然，这也为上层的应用实现铺平了道路。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!