一个基本的TCP ACK说“我收到了所有字节,直到X.”选择性ACK允许您说“我收到字节X-Y和V-Z”.
因此,例如,如果主机发送了10,000个字节并且字节3000-5000在传输过程中丢失,则ACK会说“我的所有内容都高达3000”.另一端必须再次发送字节3001-10000. SACK可以说“我得到了1000-2999和5001-10000”,主持人只会发送3000-5000.
这在高带宽,有损(或高延迟)链路上非常有用.问题是它可能在特定情况下导致严重的性能问题.正常的TCP ACK将使服务器处理带有小孩手套的高带宽,有损连接(发送500个字节,等待,发送500个字节,等待等). SACK允许它适应高延迟,因为它确切地知道实际丢失了多少数据包.
这是坏事可能发生的地方.攻击者可以强制你的服务器长时间保留一个庞大的重传队列,然后一遍又一遍地处理那个该死的东西.这可能会占用CPU,占用内存,并消耗比应有的更多带宽.简而言之,轻量级系统可以针对更强大的服务器启动DoS.
如果您的服务器功能强大且不提供大型文件,那么您就可以完全避免这种情况.
如果您主要为内部网或其他低延迟用户群提供服务,则SACK不会为您购买任何内容,并且可以出于安全原因而关闭,而不会造成任何性能损失.
如果您使用的是低带宽链路(比如1Mbps或更低的完全随意的经验法则),SACK可能会导致连接饱和,导致正常操作出现问题,应该关闭.
归根结底,这取决于你.考虑一下你所服务的对象,对象的对象,以及对SACK性能影响的风险程度.
有一个很好的概述SACK及其漏洞here.