When to turn TCP SACK off?

转载 2014年09月17日 09:22:46

转自stackoverflow:

原文地址:http://serverfault.com/questions/10955/when-to-turn-tcp-sack-off


ask:

I've been looking at Linux tuning params and see some configs where SACK is turned off. Can anyone explain this?

This would be tuning for a busy web server.

answers 1:

A basic TCP ACK says "I received all bytes up to X." Selective ACK allows you to say "I received bytes X-Y, and V-Z."

So, for instance, if a host sent you 10,000 bytes and bytes 3000-5000 were lost in transit, ACK would say "I got everything up to 3000." The other end would have to send bytes 3001-10000 again. SACK could say "I got 1000-2999, and 5001-10000" and the host would just send the 3000-5000.

This is great over a high bandwidth, lossy (or high delay) link. The problem is that it can cause severe performance issues in specific circumstances. Normal TCP ACKs will make the server treat a high-bandwidth, lossy connection with kid gloves (send 500 bytes, wait, send 500 bytes, wait, etc). SACK lets it adapt to the high delay because it knows exactly how many packets were actually lost.

Here is where bad things can happen. An attacker can force your server to keep a massive retransmission queue for a long time, then process that whole damn thing over and over and over again. This can peg the CPU, eat up RAM, and consume more bandwidth than it should. In a nutshell, a lightweight system can initiate a DoS against a beefier server.

If your server is robust and doesn't serve large files, you're pretty well insulated against this.

If you're mostly serving an intranet or other low-latency group of users, SACK buys you nothing and can be turned off for security reasons with no performance loss.

If you're on a low-bandwidth link (say 1Mbps or less as a completely arbitrary rule of thumb), SACK can cause problems in normal operations by saturating your connection and should be turned off.

Ultimately, it's up to you. Consider what you're serving, to whom, from what, and weigh the degree of your risk against the performance effects of SACK.

There is a great overview of SACK and its vulnerability here.

answers 2:

Another reason that TCP SACK is often disabled is that there is an amazing amount of network gear out there that fails to handle this option correctly. We see this all the time with a high-speed file transfer product that we provide that uses TCP. The most common issue is that of gateway devices that do things like randomize sequence numbers for TCP packets transiting through the device from internal networks to external, but that don't "un-randomize" the TCP SACK options that might be sent from the remote end. If the actual SACK values are not translated back to the proper values by these devices, then then TCP session will never complete in the face of packet loss when the remote end tries to use SACK to get the selective ACK benefits.

Probably this would be less of an issue if people were to more aggressively apply preventive software maintenance to this gear, but they tend not to.


answers3:

I can confirm from bitter experience that tcp_sack = 1 causes stalled data transfer over sftp/rsync/scp etc with files in excess of around 12mb when using certain Cisco ASA firewall appliances.

EVERY Time it would be stalled.

We were transferring over a dedicated 100mbps link between host A and host B in two different data centres, both using cisco firewall and switch hardware with centos.

This can be mitigated somewhat by modifying buffer sizes - e.g. I could not transfer 1GB file via sftp from host A to host B unless I set the sftp buffer to 2048, but I could regardless if host B was pulling the file from A.

Experiments with the same file using rsync and send/receive buffer tuning allowed me to get up yo around 70mb of a 1GB file pushed from A to B.

However, the ultimate answer was to disable tcp_sack on host A. Initially by setting tcp_sack = 0 in the kernel on-the-fly - but ultimately - I added it to my /etc/sysctl.conf


Linux(Ubuntu, Fedora, Vmware)使用笔记(2)

如何在vmware虚拟机内安装使用Fedora以及Ubuntu操作系统
  • zwvista
  • zwvista
  • 2016年08月30日 17:09
  • 406

TCP SACK选项详解

TCP通信时,如果发送序列中间某个数据包丢失,TCP会通过重传最后确认的包开始的后续包, 这样原先已经正确传输的包也可能重复发送,急剧降低了TCP性能。为改善这种情况,发展出 SACK(Selec...
  • uestczshen
  • uestczshen
  • 2017年01月03日 16:54
  • 427

linux tcp SACK分析(一)

why  should SACK be designed  ?    TCP may experience poor performance when multiple packets are ...
  • already_skb
  • already_skb
  • 2015年03月08日 10:39
  • 1046

android打包apk时异常 Export aborted because fatal lint errors were found

1.打包时弹出异常提示框 Export aborted because fatal lint errors were found. These are listed in the Lint View...
  • u013771273
  • u013771273
  • 2015年08月03日 10:00
  • 500

TCP-IP详解:SACK选项(Selective Acknowledgment)

参考教材:TCP-IP Guide 引入理由 在文章TCP-IP详解:超时重传机制中,有介绍到快速重传和超时重传都会面临到一个重传什么包的问题,因为发送端也不清楚丢失包后面传送的数据是否有成功的送...
  • wdscq1234
  • wdscq1234
  • 2016年09月11日 18:16
  • 2943

传输层学习之五(TCP的SACK,F-RTO)

一、SACK选项 默认情况下TCP采取的是累积确认机制,这时如果发生了报文乱序到达,接收方只会重复确认最后一个按序到达的报文段,为此发送方的处理只能是重复按序到达接收方的报文段之后的那个报文段,因而它...
  • goodluckwhh
  • goodluckwhh
  • 2013年08月23日 18:53
  • 10074

TCP的核心系列 — SACK和DSACK的实现(一)

TCP的实现中比较重要的一部分就是:SACK和DSACK的实现。 SACK和DSACK的处理部分由Ilpo Järvinen (ilpo.jarvinen@helsinki.fi) 维护。 为了便于理...
  • zhangskd
  • zhangskd
  • 2013年08月12日 16:16
  • 5727

TCP协议中的SACK选项

TCP协议通过滑动窗口实现流量控制,而在TCP首部中有一个32位ack字段,该字段表示接收端希望收到的下一个字节的序号,该ack为累积确认。这样做的缺陷在于:假如接收端收到了序号(2,3...5)和序...
  • JXH_123
  • JXH_123
  • 2014年05月28日 19:18
  • 1302

TCP对SACK的处理以及乱序的处理细节

不容易啊,天气热得厉害,终于到了周末却哪里也去不了,昨晚就特意向老婆申请了一段不长不短的周末时间用来总结近期的工作,也实属不易,如果申请没有获得批准,我也只好利用夜晚了,因为我几乎是一个不用怎么睡觉,...
  • dog250
  • dog250
  • 2016年05月07日 11:17
  • 10260

TCP的核心系列 — SACK和DSACK的实现(三)

不论是18版,还是37版,一开始都会从TCP的控制块中取出SACK选项的起始地址。 SACK选项的起始地址是保存在tcp_skb_cb结构的sacked项中的,那么这是在什么时候做的呢? SACK块并...
  • zhangskd
  • zhangskd
  • 2013年08月12日 16:20
  • 5439
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:When to turn TCP SACK off?
举报原因:
原因补充:

(最多只允许输入30个字)