When to turn TCP SACK off?

本文探讨了TCP SACK(选择确认)的功能及应用场景,包括其在高带宽、高延迟网络中的优势,以及在网络设备不正确处理SACK选项时可能引发的问题。此外,还讨论了在特定条件下禁用SACK的原因。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

转自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


内容概要:本文深入探讨了Kotlin语言在函数式编程和跨平台开发方面的特性和优势,结合详细的代码案例,展示了Kotlin的核心技巧和应用场景。文章首先介绍了高阶函数和Lambda表达式的使用,解释了它们如何简化集合操作和回调函数处理。接着,详细讲解了Kotlin Multiplatform(KMP)的实现方式,包括共享模块的创建和平台特定模块的配置,展示了如何通过共享业务逻辑代码提高开发效率。最后,文章总结了Kotlin在Android开发、跨平台移动开发、后端开发和Web开发中的应用场景,并展望了其未来发展趋势,指出Kotlin将继续在函数式编程和跨平台开发领域不断完善和发展。; 适合人群:对函数式编程和跨平台开发感兴趣的开发者,尤其是有一定编程基础的Kotlin初学者和中级开发者。; 使用场景及目标:①理解Kotlin中高阶函数和Lambda表达式的使用方法及其在实际开发中的应用场景;②掌握Kotlin Multiplatform的实现方式,能够在多个平台上共享业务逻辑代码,提高开发效率;③了解Kotlin在不同开发领域的应用场景,为选择合适的技术栈提供参考。; 其他说明:本文不仅提供了理论知识,还结合了大量代码案例,帮助读者更好地理解和实践Kotlin的函数式编程特性和跨平台开发能力。建议读者在学习过程中动手实践代码案例,以加深理解和掌握。
内容概要:本文深入探讨了利用历史速度命令(HVC)增强仿射编队机动控制性能的方法。论文提出了HVC在仿射编队控制中的潜在价值,通过全面评估HVC对系统的影响,提出了易于测试的稳定性条件,并给出了延迟参数与跟踪误差关系的显式不等式。研究为两轮差动机器人(TWDRs)群提供了系统的协调编队机动控制方案,并通过9台TWDRs的仿真和实验验证了稳定性和综合性能改进。此外,文中还提供了详细的Python代码实现,涵盖仿射编队控制类、HVC增强、稳定性条件检查以及仿真实验。代码不仅实现了论文的核心思想,还扩展了邻居历史信息利用、动态拓扑优化和自适应控制等性能提升策略,更全面地反映了群体智能协作和性能优化思想。 适用人群:具备一定编程基础,对群体智能、机器人编队控制、时滞系统稳定性分析感兴趣的科研人员和工程师。 使用场景及目标:①理解HVC在仿射编队控制中的应用及其对系统性能的提升;②掌握仿射编队控制的具体实现方法,包括控制器设计、稳定性分析和仿真实验;③学习如何通过引入历史信息(如HVC)来优化群体智能系统的性能;④探索中性型时滞系统的稳定性条件及其在实际系统中的应用。 其他说明:此资源不仅提供了理论分析,还包括完整的Python代码实现,帮助读者从理论到实践全面掌握仿射编队控制技术。代码结构清晰,涵盖了从初始化配置、控制律设计到性能评估的各个环节,并提供了丰富的可视化工具,便于理解和分析系统性能。通过阅读和实践,读者可以深入了解HVC增强仿射编队控制的工作原理及其实际应用效果。
<think>我们正在讨论TCPSACK(选择性确认)功能。根据引用,SACK用于在TCP连接中提供更精细的确认机制,允许接收方通知发送方哪些数据段已经成功接收,哪些丢失,从而优化重传。以下将详细解释SACK。</think>### TCP SACK(Selective Acknowledgment)功能详解 #### 一、基本概念与作用 SACK(选择性确认)是TCP协议的扩展功能,用于**优化数据传输效率**。其核心作用是: 1. **精确反馈接收状态** 接收方通过SACK选项告知发送方**哪些数据块已成功接收**(即使存在不连续的数据段)[^2][^3] $$ \text{传统ACK} \rightarrow \text{仅确认连续数据} \quad \text{vs} \quad \text{SACK} \rightarrow \text{标记非连续接收块} $$ 2. **减少无效重传** 当发生数据包丢失时,发送方仅重传**实际丢失的片段**,而非整个滑动窗口的数据[^3] #### 二、协议实现机制 ##### 1. 报文格式 SACK信息通过TCP头部Options字段传递,主要有两种格式[^2]: ```mermaid graph LR A[TCP头部] --> B[Options字段] B --> C[SACK选项类型=5] C --> D[长度字段] D --> E[左边界1] E --> F[右边界1] F --> G[...边界对] ``` - 每个SACK块包含`(left edge, right edge)`边界对 - 最多可携带**4个SACK块**(受40字节Option空间限制) ##### 2. 工作流程 ```mermaid sequenceDiagram participant Sender participant Receiver Sender->>Receiver: 发送Seq1-1000, Seq1001-2000 Receiver->>Sender: ACK1001 + SACK(Seq2001-3000) Sender->>Receiver: 重传Seq1001-2000 Receiver->>Sender: ACK3001 ``` 1. 接收方检测到数据段丢失(如Seq1001-2000丢失) 2. 发送包含最新连续ACK(1001)和SACK块(确认已收到的非连续数据段) 3. 发送方根据SACK信息**选择性重传丢失段**[^1][^3] #### 三、关键技术优势 1. **应对多重丢包** 在连续丢失多个数据包时,SACK仍能精确识别所有丢失块位置 $$ \text{丢包场景} = \{ \text{Seq}_i, \text{Seq}_j, \text{Seq}_k \} \rightarrow \text{SACK精准定位} $$ 2. **避免重传风暴** 减少因单一丢包导致整个窗口数据重传的情况(传统TCP的"Go-Back-N"问题) 3. **带宽利用率提升** 实验数据显示:在高丢包率(>5%)环境中,SACK可使吞吐量提升30%-50%[^3] #### 四、启用条件与交互规则 1. **协商机制** 在TCP三次握手阶段通过`SACK Permitted`选项(Kind=4)协商启用[^1] ```mermaid graph LR C[Client]-SYN+SACK_perm->S[Server] S-SYN+ACK+SACK_perm->C ``` 2. **触发条件** - 接收方检测到**非连续数据到达**时自动生成SACK - 需配合**重复ACK**机制(Dup-ACK≥3时触发快速重传)[^3] #### 五、典型应用场景 1. **高延迟网络** 卫星通信等长RTT网络,避免大范围回退重传 2. **无线网络环境** 应对无线信道的高随机丢包率 3. **数据中心网络** 解决微突发(microburst)导致的瞬时多包丢失 > **注意**:SACK需发送/接收双方同时支持,现代操作系统默认启用(Linux内核≥2.4,Windows≥XP) ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值