Answers:
基本的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。
每当它停滞不前。
我们正在使用cisco防火墙和带有centos的交换硬件，在两个不同数据中心的主机A和主机B之间通过专用的100mbps链路进行传输。
可以通过修改缓冲区大小来减轻这种情况-例如，除非将sftp缓冲区设置为2048，否则我无法通过sftp从主机A传输1GB文件到主机B，但是我可以不管主机B是否从A提取文件。
使用rsync和发送/接收缓冲区调整对同一文件进行的实验使我可以从A推到B的70 GB的1GB文件中。
但是，最终的答案是在主机A上禁用tcp_sack。最初是通过即时在内核中设置tcp_sack = 0-但最终-我将其添加到了/etc/sysctl.conf中。