设置 TCP_QUICKACK 和 TCP_NODELAY

发布于 2024-12-02 17:01:35 字数 395 浏览 0 评论 0原文

如果在之前设置了 TCP_NODELAY 的情况下对套接字上的每个调用都设置了 TCP_QUICKACK 设置，那么 QUICKACK 选项是否会覆盖 NODELAY 调用？

连接时：

int i = 1;
setsockopt( iSock, IPPROTO_TCP, TCP_NODELAY, (void *)&i, sizeof(i));

每次写入时：

int i = 1;
setsockopt( iSock, IPPROTO_TCP, TCP_QUICKACK, (void *)&i, sizeof(i));

对 TCP_QUICKACK 的调用会使之前对 TCP_NODELAY 的调用无效吗？

原文

If you set the TCP_QUICKACK setting on every call on the socket, having previously set TCP_NODELAY, will the QUICKACK option overwrite the NODELAY call?

On connect:

int i = 1;
setsockopt( iSock, IPPROTO_TCP, TCP_NODELAY, (void *)&i, sizeof(i));

On each write:

int i = 1;
setsockopt( iSock, IPPROTO_TCP, TCP_QUICKACK, (void *)&i, sizeof(i));

Will the call to TCP_QUICKACK null the previous call to TCP_NODELAY?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

夕色琉璃 2024-12-09 17:01:35

这两个选项之间没有直接关系，它们只是用于不同的目的。

TCP_NODELAY 旨在禁用/启用段缓冲，以便数据可以尽快发送到对等点，因此这通常用于提高网络利用率。 TCP_QUICKACK 用于在某些协议级别交换下尽早发送确认而不是延迟，并且它不是稳定/永久的，后续的 TCP 事务（可能在幕后发生）可以忽略此选项，具体取决于实际的协议级别处理或用户设置和堆栈行为之间的任何实际分歧。

注意 TCP_NODELAY 是可移植的，而 TCP_QUICKACK 则不可移植（仅适用于 Linux 2.4.4+）。

回复收藏 0 原文

假装爱人 2024-12-09 17:01:35

使用 TCP_QUICKACK，而不是 TCP_NODELAY

开启 TCP_NODELAY 也有类似的效果，但可以提高吞吐量
对于小写入来说更糟。如果你编写一个只发送一些数据的循环
使用“write()”将字节（最坏情况，一个字节）发送到套接字，并且 Nagle
使用 TCP_NODELAY 禁用算法，每次写入都会变成一个 IP
包。这使 IP 和 TCP 的流量增加了 40 倍
每个有效负载的标头。 Tinygram 预防不会让您发送
第二个数据包（如果您在飞行中有一个数据包），除非您有足够的数据
填充最大尺寸的数据包。它累积一轮的字节数
行程时间，然后发送队列中的所有内容。几乎总是这样
你想要什么。如果设置了 TCP_NODELAY，则需要做更多
意识到缓冲和刷新问题。这些对于批量来说都不重要
单向传输，即当今大多数 HTTP。（我从来没有看过
这对 SSL 握手的影响，这可能很重要。）短
版本：设置 TCP_QUICKACK。如果你发现这样的情况
更糟糕的是，请告诉我。约翰·内格尔

https://news.ycombinator.com/item?id=10608356

更新:

更有争议的是，考虑到流量和应用程序组合以及我们今天拥有的硬件功能，我怀疑现代系统不需要 Nagle 的算法。换句话说，TCP_NODELAY 应该是默认值。这将使一些“写入每个字节”的代码比其他情况更慢，但如果我们关心效率，这些应用程序无论如何都应该被修复。

随着这件事在互联网上流传开来，许多人询问了 TCP_QUICKACK 的问题。由于一些原因，我不倾向于使用它，包括缺乏可移植性和奇怪的语义（说真的，请阅读手册页）。更大的问题是 TCP_QUICKACK 并没有解决内核保留数据的时间比我的程序想要的时间长的根本问题。当我说 write() 时，我的意思是 write()。

https://brooker.co.za/blog/2024/05/ 09/nagle.html

回复收藏 0 原文

西瓜 2024-12-09 17:01:35

简短回答

要禁用 Nagle 的缓冲算法，请使用 TCP_NODELAY 套接字选项。
要禁用延迟 ACK，请使用 TCP_QUICKACK 套接字选项。

详细信息

Nagle 算法
- Nagle 算法以其创建者 John Nagle 的名字命名，是一种通过减少网络上发送的小数据包数量来提高 TCP 效率的机制。
- 目标是在应用程序向套接字传送数据的速度相当缓慢时，防止节点传输许多小数据包。
- 如果某个进程导致传输许多小数据包，则可能会造成过度的网络拥塞。如果数据包的有效负载小于 TCP 标头数据，则尤其如此。
延迟确认
- TCP 延迟确认或延迟 ACK 是某些 TCP 实现使用的另一种技术，旨在提高网络性能并减少拥塞。
- 延迟 ACK 的发明是为了减少确认分段所需的 ACK 数量并减少协议开销。
- 延迟 ACK 意味着 TCP 不会立即确认每个收到的 TCP 段。多个 ACK 响应可以组合在一起形成单个响应，从而减少协议开销。
Nagle 算法和延迟 ACK 在 TCP/IP 网络中不能很好地协同工作
- 如果可以的话，延迟 ACK 会尝试为每个段发送更多数据。但 Nagle 算法的一部分依赖于 ACK 来发送数据。
- Nagle 的算法和延迟的 ACK 一起产生了一个问题，因为延迟的 ACK 正在等待发送 ACK，而 Nagle 的算法正在等待接收 ACK
- 示例
```
客户：嗨！这是第一个数据包
服务器：<沉默，等待第二个数据包，我最终会确认>
客户端：<沉默，好吧，我在等待 ACK，也许网络拥塞>
服务员：好吧，我很无聊。这是一个确认
客户：太好了，这是第二包！
服务员：甜甜的。我们已经完成了
```
  - 客户端这样做是因为 Nagle 算法，而服务器这样做是因为延迟的 ACK。
如何解决 Nagle 算法和延迟 ACK 引起的问题
- 启用 TCP_NODELAY 以通过服务器上的全局套接字选项禁用 Nagle 算法
- 在代理服务器和负载均衡器上进行配置文件调整：如果您运行的应用程序或环境有时只有高度交互的流量和繁琐的协议，这一点尤其重要。通过在负载均衡器级别动态切换 Nagle 算法和 TCP_NODELAY，您甚至可以保持高度异构的流量混合以最佳状态运行。
- 减少服务器和负载均衡器上的延迟 ACK 计时器。有时，这种优化是在应用程序级别的软件中处理的，但当情况并非如此时，您仍然可以在服务器或负载均衡器级别动态管理 ACK 计时器。
- 在进行这些更改时，请密切关注网络流量，并了解每次调整对拥塞的影响。

更多详情请参考此

Short answer

To disable Nagle's buffering algorithm, use the TCP_NODELAY socket option.
To disable Delayed ACKs, use the TCP_QUICKACK socket option.

Details

Nagle's algorithm
- Nagle's algorithm, named after its creator John Nagle, is one mechanism for improving TCP efficiency by reducing the number of small packets sent over the network.
- The goal was to prevent a node from transmitting many small packets if the application delivers data to the socket rather slowly.
- If a process is causing many small packets to be transmitted, it may be creating undue network congestion. This is especially true if the payload of a packet is smaller than the TCP header data.
Delayed ACK
- TCP delayed acknowledgment or Delayed ACK is another technique used by some implementations of the TCP in an effort to improve network performance and reduce congestion.
- Delayed ACK was invented to reduce the number of ACKs required to acknowledge the segments and reduce the protocol overhead.
- Delayed ACK means TCP doesn't immediately acknowledge every single received TCP segment. Several ACK responses may be combined together into a single response, reducing protocol overhead.
Nagle's Algorithm and Delayed ACK Do Not Play Well Together in a TCP/IP Network
- Delayed ACK tries to send more data per segment if it can. But part of Nagle's algorithm depends on an ACK to send data.
- Nagle's algorithm and Delayed ACKs together create a problem because Delayed ACKs are waiting around to send the ACK while Nagle's is waiting around to receive the ACK
- Sample
```
client: hi! Here’s the first packet
server: <silence, waiting for the second packet, well I’ll ack eventually>
client: <silence, well I’m waiting for an ACK, maybe there’s network congestion>
server: Ok I am bored. Here’s an ack
client: Great, here’s the second packet!
server: Sweet. we’re done here
```
  - The client is doing it because of Nagle’s algorithm, and the server is because of delayed ACKs.
How can I resolve the issues caused by Nagle's algorithm and Delayed ACKs
- Enable TCP_NODELAY to disable Nagle's algorithm via global socket options on the servers
- Make profile tweaks on proxy servers and Load Balancers: This is especially relevant if you're running applications or environments that only sometimes have highly interactive traffic and chatty protocols. By dynamically switching Nagle's Algorithm and TCP_NODELAY on and off at the load balancer level, you can keep even highly heterogeneous traffic mixes running optimally.
- Reduce the Delayed ACK timer on your servers and load balancers. Sometimes, this kind of optimization is handled in software, at the application level, but when that's not the case, you may still be able to dynamically manage the ACK timer at the server or load balancer level.
- As you're making these changes, keep careful watch on your network traffic and see how each tweak impacts congestion.