TCP/IP 特定问题
某些编程技术遇到与 TCP/IP 实现相关的性能问题。 此类性能问题并不表示 TCP/IP 效率低下或性能瓶颈：相反，当无法理解 TCP/IP 操作时，会出现这些问题。
以下问题确定了 TCP/IP 操作和网络应用程序开发选项组合导致性能不佳的常见方案。
连接密集型应用程序。
某些应用程序为每个事务实例化新的 TCP 连接。 建立 TCP 连接需要一些时间，会导致额外的 RTT，并且启动速度缓慢。 此外，关闭的连接受 TIME-WAIT 的约束，这会消耗系统资源。
连接密集型应用程序很常见，主要是因为它们易于创建;测试和错误处理非常简单。 在持久性连接上检测故障可能需要花费大量代码和精力，因此有时无法完成。
通过重用 TCP 连接来修复这种情况。 这可能会导致通过 TCP 连接进行序列化，除非事务通过多个连接进行多路复用。 如果采用此方法，连接数应限制为两个，并且需要应用层框架和高级错误处理。
零长度发送缓冲区和阻止发送。
通过使用 setsockopt 函数将发送缓冲区 (SO_SNDBUF) 设置为零来关闭缓冲类似于关闭磁盘缓存。 将发送缓冲区设置为零并发出阻止发送时，应用程序有 50% 的几率达到 200 毫秒的延迟确认。
不要关闭发送缓冲，除非你已考虑在所有网络环境中的影响。 一个例外：使用重叠 I/O 的流数据应将发送缓冲区设置为零。
Send-Send-Receive 编程模型。
构造应用程序以执行发送-发送-接收会增加遇到 Nagle 算法的可能性，这会导致 RTT+200 毫秒的延迟。 如果最后一次发送小于 TCP 最大段大小 (MSS，则可能会遇到 Nagle 算法，单个数据报中的最大数据) 。 在 IPv4 中，MSS 可以是 (64K 的非常大的值，在 IPv6) 中甚至更大，因此不要指望通常较小的 MSS。 更好的选择是使用 WSASend 或 memcpy 函数将两个发送合并为单个发送。
大量同时连接。
除特殊用途应用程序外，并发连接不应超过 2。 超过两个并发连接会导致资源浪费。 一个好的规则是最多有四个短期连接，或每个目标的两个持久连接。
相关主题