JB. Asked: 2009-05-22 11:34:33 +0800 CST2009-05-22 11:34:33 +0800 CST 2009-05-22 11:34:33 +0800 CST 何时关闭 TCP SACK？ 772 我一直在查看 Linux 调整参数，并查看了一些关闭 SACK 的配置。谁能解释一下？ 这将针对繁忙的 Web 服务器进行调整。 linux http web-server 3 个回答 Voted Best Answer sh-beta 2009-05-22T13:11:57+08:002009-05-22T13:11:57+08:00 一个基本的 TCP ACK 说“我收到了直到 X 的所有字节”。选择性 ACK 允许您说“我收到了字节 XY 和 VZ”。 因此，例如，如果主机向您发送了 10,000 个字节，而 3000-5000 字节在传输过程中丢失，ACK 会说“我得到了 3000 以内的所有内容”。另一端必须再次发送字节 3001-10000。SACK 可以说“我得到了 1000-2999 和 5001-10000”，主机只会发送 3000-5000。 这在高带宽、有损（或高延迟）链路上非常有用。问题是它可能在特定情况下导致严重的性能问题。正常的 TCP ACK 将使服务器处理高带宽、有损连接（发送 500 字节、等待、发送 500 字节、等待等）。SACK 让它适应高延迟，因为它确切知道实际丢失了多少数据包。 这是可能发生坏事的地方。攻击者可以强迫您的服务器长时间保持大量的重传队列，然后一遍又一遍地处理整个该死的事情。这可能会占用 CPU、占用 RAM 并消耗超出应有的带宽。简而言之，轻量级系统可以针对更强大的服务器发起 DoS。 如果您的服务器很健壮并且不提供大文件，那么您可以很好地避免这种情况。 如果您主要为 Intranet 或其他低延迟用户组提供服务，那么 SACK 不会给您带来任何好处，并且可以出于安全原因将其关闭而不会造成性能损失。 如果您使用的是低带宽链接（例如 1Mbps 或更低，这是一个完全任意的经验法则），SACK 可能会通过使您的连接饱和而导致正常操作出现问题，因此应将其关闭。 最终，这取决于你。考虑您服务的对象、服务对象、服务对象，并权衡您的风险程度与 SACK 的性能影响。 这里对 SACK 及其漏洞有一个很好的概述。 Chris Markle 2009-12-30T15:25:17+08:002009-12-30T15:25:17+08:00 TCP SACK 经常被禁用的另一个原因是有大量的网络设备无法正确处理此选项。我们一直在使用我们提供的使用 TCP 的高速文件传输产品看到这一点。最常见的问题是网关设备的问题，例如随机化通过设备从内部网络传输到外部的 TCP 数据包的序列号，但不会“取消随机化”可能从远程发送的 TCP SACK 选项结尾。如果这些设备没有将实际的 SACK 值转换回正确的值，那么当远程端尝试使用 SACK 来获得选择性 ACK 好处时，TCP 会话将永远不会在面对丢包的情况下完成。 如果人们更积极地对这个设备应用预防性软件维护，这可能不会成为问题，但他们往往不会。 Isaac 2013-09-27T15:13:39+08:002013-09-27T15:13:39+08:00 我可以从痛苦的经验中确认，当使用某些 Cisco ASA 防火墙设备时，tcp_sack = 1 会导致通过 sftp/rsync/scp 等文件传输超过 12mb 的数据停滞。 每次它都会停滞不前。 我们在两个不同数据中心的主机 A 和主机 B 之间通过专用的 100mbps 链路传输，都使用 cisco 防火墙和带有 centos 的交换机硬件。 这可以通过修改缓冲区大小来有所缓解——例如，除非我将 sftp 缓冲区设置为 2048，否则我无法通过 sftp 从主机 A 向主机 B 传输 1GB 文件，但无论主机 B 是否从 A 中提取文件，我都可以。 使用 rsync 和发送/接收缓冲区调整对同一文件进行的实验使我能够从 A 推送到 B 的 1GB 文件的 70mb 左右。 然而，最终的答案是禁用主机 A 上的 tcp_sack。最初通过在内核中即时设置 tcp_sack = 0 - 但最终 - 我将它添加到我的 /etc/sysctl.conf
一个基本的 TCP ACK 说“我收到了直到 X 的所有字节”。选择性 ACK 允许您说“我收到了字节 XY 和 VZ”。
因此，例如，如果主机向您发送了 10,000 个字节，而 3000-5000 字节在传输过程中丢失，ACK 会说“我得到了 3000 以内的所有内容”。另一端必须再次发送字节 3001-10000。SACK 可以说“我得到了 1000-2999 和 5001-10000”，主机只会发送 3000-5000。
这在高带宽、有损（或高延迟）链路上非常有用。问题是它可能在特定情况下导致严重的性能问题。正常的 TCP ACK 将使服务器处理高带宽、有损连接（发送 500 字节、等待、发送 500 字节、等待等）。SACK 让它适应高延迟，因为它确切知道实际丢失了多少数据包。
这是可能发生坏事的地方。攻击者可以强迫您的服务器长时间保持大量的重传队列，然后一遍又一遍地处理整个该死的事情。这可能会占用 CPU、占用 RAM 并消耗超出应有的带宽。简而言之，轻量级系统可以针对更强大的服务器发起 DoS。
如果您的服务器很健壮并且不提供大文件，那么您可以很好地避免这种情况。
如果您主要为 Intranet 或其他低延迟用户组提供服务，那么 SACK 不会给您带来任何好处，并且可以出于安全原因将其关闭而不会造成性能损失。
如果您使用的是低带宽链接（例如 1Mbps 或更低，这是一个完全任意的经验法则），SACK 可能会通过使您的连接饱和而导致正常操作出现问题，因此应将其关闭。
最终，这取决于你。考虑您服务的对象、服务对象、服务对象，并权衡您的风险程度与 SACK 的性能影响。
这里对 SACK 及其漏洞有一个很好的概述。
TCP SACK 经常被禁用的另一个原因是有大量的网络设备无法正确处理此选项。我们一直在使用我们提供的使用 TCP 的高速文件传输产品看到这一点。最常见的问题是网关设备的问题，例如随机化通过设备从内部网络传输到外部的 TCP 数据包的序列号，但不会“取消随机化”可能从远程发送的 TCP SACK 选项结尾。如果这些设备没有将实际的 SACK 值转换回正确的值，那么当远程端尝试使用 SACK 来获得选择性 ACK 好处时，TCP 会话将永远不会在面对丢包的情况下完成。
如果人们更积极地对这个设备应用预防性软件维护，这可能不会成为问题，但他们往往不会。
我可以从痛苦的经验中确认，当使用某些 Cisco ASA 防火墙设备时，tcp_sack = 1 会导致通过 sftp/rsync/scp 等文件传输超过 12mb 的数据停滞。
每次它都会停滞不前。
我们在两个不同数据中心的主机 A 和主机 B 之间通过专用的 100mbps 链路传输，都使用 cisco 防火墙和带有 centos 的交换机硬件。
这可以通过修改缓冲区大小来有所缓解——例如，除非我将 sftp 缓冲区设置为 2048，否则我无法通过 sftp 从主机 A 向主机 B 传输 1GB 文件，但无论主机 B 是否从 A 中提取文件，我都可以。
使用 rsync 和发送/接收缓冲区调整对同一文件进行的实验使我能够从 A 推送到 B 的 1GB 文件的 70mb 左右。
然而，最终的答案是禁用主机 A 上的 tcp_sack。最初通过在内核中即时设置 tcp_sack = 0 - 但最终 - 我将它添加到我的 /etc/sysctl.conf