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 编程模型。
构建应用程序以执行 send-send-receive 会增加遇到 Nagle 算法的可能性，这会导致 RTT+200 毫秒延迟。 如果上次发送小于 TCP 最大段大小（MSS，单个数据报中的最大数据），则可能会遇到 Nagle 算法。 MSS 可以是非常大的值（IPv4 中的 64K，在 IPv6 中甚至更大），因此不要指望通常较小的 MSS。 更好的选择是使用 WSASend 或 memcpy 函数将这两个发送合并到单个发送中。
大量同时连接。
除特殊用途应用程序外，并发连接不应超过两个。 超过两个并发连接会导致资源浪费。 一个好的规则是，每个目标最多有四个短生存期连接，或两个永久性连接。
相关主题