javascript - 禁用 Nagle 的算法客户端/JavaScript

Question

是否也需要在客户端禁用 Nagle 算法？如果是这种情况，我还没有找到单独通过 JavaScript 禁用 Nagle 算法的方法。

我正在尝试从 Raspbian OS 上托管的 PHP CLI 服务器(也托管在 Windows 7 和 Ubuntu 上，结果相同)跨 websocket 传输数据。此服务器已成功创建套接字并接受多个连接，并已设置 TCP_NODELAY 标志(仅通过 socket_get_option 验证)。

$sock = socket_create(AF_INET, SOCK_STREAM, SOL_TCP)
socket_set_option($sock, SOL_SOCKET, TCP_NODELAY, 1);

在大多数平台上，无论设置了这个 TCP_NODELAY 标志，数据都将流式传输而不会聚集。但是，在 Windows 7 Chrome 和 Firefox 上，数据以 block 的形式到达(延迟 0.2 秒)。在 Windows 8、Linux、iOS 和 Windows 7 的 Internet Explorer 11 上:我根本看不到这个问题。

http://www.13willows.com/hovelme/script/serverControl.php这是测试网站，单击“连接”，然后单击“查看游戏”，您应该看到当前数据包每 50 毫秒从 1 稳定增加到 20。但是，在某些客户端上，它大约每 200 毫秒一次跳转 4。

有什么想法可以阻止这种情况吗？使用 node.js/socket.io 是否可以解决类似的问题并仍然允许我从用户的浏览器运行代码？

Answer 1

至少 Chrome 似乎禁用了所有 WebSocket 套接字的 Nagle 算法:

Worth noting that Chrome also disables the Nagle algorithm on all of its TCP sockets.

但似乎应该在两侧都启用 NODELAY 选项以保证低延迟:

We already disable Nagle on all platforms, using just such a method, but that doesn't disable delaying ACKs (Or at least it doesn't on Windows, it's certainly possible it does elsewhere).

source

Chromium 源代码似乎证明了这一点(但我不是 Chromium 开发人员，所以我只是猜测如上面的一位评论员所说，在所有 TCP 套接字上调用了以下代码):

void TCPSocketPosix::SetDefaultOptionsForClient() {
  DCHECK(socket_);

  // This mirrors the behaviour on Windows. See the comment in
  // tcp_socket_win.cc after searching for "NODELAY".
  // If SetTCPNoDelay fails, we don't care.
  SetTCPNoDelay(socket_->socket_fd(), true);

  // TCP keep alive wakes up the radio, which is expensive on mobile. Do not
  // enable it there. It's useful to prevent TCP middleboxes from timing out
  // connection mappings. Packets for timed out connection mappings at
  // middleboxes will either lead to:
  // a) Middleboxes sending TCP RSTs. It's up to higher layers to check for this
  // and retry. The HTTP network transaction code does this.
  // b) Middleboxes just drop the unrecognized TCP packet. This leads to the TCP
  // stack retransmitting packets per TCP stack retransmission timeouts, which
  // are very high (on the order of seconds). Given the number of
  // retransmissions required before killing the connection, this can lead to
  // tens of seconds or even minutes of delay, depending on OS.
#if !BUILDFLAG(IS_ANDROID) && !BUILDFLAG(IS_IOS)
  const int kTCPKeepAliveSeconds = 45;

  SetTCPKeepAlive(socket_->socket_fd(), true, kTCPKeepAliveSeconds);
#endif
}

link to source line

另请参阅此可能的解决方法 - https://stackoverflow.com/a/13406438/3167374