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


相关文章推荐

Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program

Slow performance occurs when you copy data to a TCP server by using a Windows Sockets API program ...
  • pud_zha
  • pud_zha
  • 2012年08月31日 15:34
  • 793

Bind: Address Already in Use Or How to Avoid this Error when Closing TCP Connections

In order for a network connection to close, both ends have to send FIN (final) packets, which indi...
  • yy_msdn
  • yy_msdn
  • 2011年08月20日 22:54
  • 974

Tomcat如何禁用session(Turn off the Session in Tomcat )

有时候我们不需要用到session,而session在tomcat中是属于关键功能,它在启动的时候会自动创建,这样就会消耗一定的内存空间,如果访问量大了session就会产生很多。这样也不利于我们进行...
  • ywch520
  • ywch520
  • 2016年06月07日 20:27
  • 2997

关灯看视频(Turn Off the Lights)

关灯看视频(Turn Off the Lights)观看视频时自动调暗页面,让您仿佛置身于电影院中只要轻轻按下灯的开关,页面就会暗淡下去。 然后您就可以专心享受视频了。 再按一次开关,页面就会恢复回原...

FZU 1704 Turn off the light

高斯消元 套模板, 求出方程的自由变量个数,由于变量取值只有0,1; 故2^(var-k)种方法,var-k最大取100,用高精 #include #include #include #i...
  • qianlv_
  • qianlv_
  • 2013年02月05日 21:58
  • 298

TCP RENO NEWRENO SACK

  • 2012年04月16日 21:29
  • 1.09MB
  • 下载

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

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

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

不论是18版,还是37版,一开始都会从TCP的控制块中取出SACK选项的起始地址。 SACK选项的起始地址是保存在tcp_skb_cb结构的sacked项中的,那么这是在什么时候做的呢? SACK块并...

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

18版本对于每个SACK块,都是从重传队列头开始遍历。37版本则可以选择性的遍历重传队列的某一部分,忽略 SACK块间的间隙、或者已经cache过的部分。这主要是通过tcp_sacktag_skip(...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:When to turn TCP SACK off?
举报原因:
原因补充:

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