document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-02-22 00:40:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

PRF

Browse Source 
PART 1
This commit is contained in:
Xingyu Wang 2020-10-08 21:27:42 +08:00
parent c3ef6dfb2c
commit 82258a7245
1 changed files with 34 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

63
translated/tech/20200811 TCP window scaling, timestamps and SACK.md
View File

@ -1,49 +1,54 @@
[#]: collector: (lujun9972)
[#]: translator: (gxlct008)
[#]: reviewer: ( )
[#]: reviewer: (wxy)
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (TCP window scaling, timestamps and SACK)
[#]: via: (https://fedoramagazine.org/tcp-window-scaling-timestamps-and-sack/)
[#]: author: (Florian Westphal https://fedoramagazine.org/author/strlen/)
TCP 窗口缩放，时间戳和 SACK
TCP 窗口缩放、时间戳和 SACK
======
![][1]
Linux TCP 协议栈具有无数个 _sysctl_ 旋钮，允许更改其行为。 这包括可用于接收或发送操作的内存量，套接字的最大数量、可选特性和协议扩展。
Linux TCP 协议栈具有无数个 `sysctl` 旋钮，允许更改其行为。 这包括可用于接收或发送操作的内存量，套接字的最大数量、可选的特性和协议扩展。
有很多文章出于各种“性能调优”或“安全性”原因，建议禁用 TCP 扩展，比如时间戳或<ruby>选择性确认<rt>selective acknowledgments</rt></ruby> （SACK）。
有很多文章出于各种“性能调优”或“安全性”原因，建议禁用 TCP 扩展，比如时间戳或<ruby>选择性确认<rt>selective acknowledgments</rt></ruby>（SACK）。
本文提供了这些扩展的功能背景，默认情况下处于启用状态的原因，它们之间是如何关联的，以及为什么通常情况下将它们关闭是个坏主意。
本文提供了这些扩展的功能背景，为什么会默认启用，它们之间是如何关联的，以及为什么通常情况下将它们关闭是个坏主意。
### TCP 窗口缩放
TCP 可以维持的数据传输速率受到几个因素的限制。其中包括：
TCP 可以承受的数据传输速率受到几个因素的限制。其中包括：
* 往返时间（RTT）。这是数据包到达目的地并返回回复所花费的时间。越低越好。
* 所涉及的网络路径的最低链路速度
* 丢包频率
* 新数据可用于传输的速度。 例如，CPU 需要能够以足够快的速度将数据传递到网络适配器。如果 CPU 需要首先加密数据，则适配器可能必须等待新数据。同样地，如果磁盘存储不能足够快地读取数据，则磁盘存储可能会成为瓶颈。
* TCP 接收窗口的最大可能大小。接收窗口决定 TCP 在必须等待接收方报告接收到该数据之前可以传输多少数据 (以字节为单位)。这是由接收方宣布的。接收方将在读取并确认接收到传入数据时不断更新此值。接收窗口当前值包含在 [TCP 报头][2] 中，它是 TCP 发送的每个数据段的一部分。因此，只要发送方接收到来自对等方的确认，它就知道当前的接收窗口。这意味着往返时间（RTT）越长，发送方获得接收窗口更新所需的时间就越长。
* 往返时间（RTT）。
这是数据包到达目的地并返回回复所花费的时间。越低越好。
* 所涉及的网络路径的最低链路速度。
* 丢包频率。
* 新数据可用于传输的速度。
例如，CPU 需要能够以足够快的速度将数据传递到网络适配器。如果 CPU 需要首先加密数据，则适配器可能必须等待新数据。同样地，如果磁盘存储不能足够快地读取数据，则磁盘存储可能会成为瓶颈。
* TCP 接收窗口的最大可能大小。
接收窗口决定 TCP 在必须等待接收方报告接收到该数据之前可以传输多少数据（以字节为单位）。这是由接收方宣布的。接收方将在读取并确认接收到传入数据时不断更新此值。接收窗口当前值包含在 [TCP 报头][2] 中，它是 TCP 发送的每个数据段的一部分。因此，只要发送方接收到来自对等方的确认，它就知道当前的接收窗口。这意味着往返时间（RTT）越长，发送方获得接收窗口更新所需的时间就越长。
TCP 被限制为最多 64KB 的未确认（正在传输）数据。在大多数网络场景中，这甚至还不足以维持一个像样的数据速率。让我们看看一些例子。
##### 理论数据速率
#### 理论数据速率
由于往返时间 (RTT) 为 100 毫秒，TCP 每秒最多可以传输 640KB。在延迟 1 秒的情况下，最大理论数据速率降至 64KB/s。
在往返时间（RTT）为 100 毫秒的情况下，TCP 每秒最多可以传输 640KB。在延迟为 1 秒的情况下，最大理论数据速率降至 64KB/s。
这是因为接收窗口的原因。一旦发送了 64KB 的数据，接收窗口就已经满了。发送方必须等待，直到对等方通知它应用程序已经读取了至少一部分数据。
发送的第一个段会把 TCP 窗口缩减一个自身的大小。在接收窗口值的更新可用之前，需要往返一次。当更新以 1 秒的延迟到达时，即使链路有足够的可用带宽，也会导致 64KB 的限制。
为了充分利用一个具有几毫秒延迟的快速网络，必须有一个比传统 TCP 支持的窗口大的窗口。“64KB 限制”是协议规范的产物：TCP 头只为接收窗口大小保留 16 位。这允许接收窗口高达 64KB。在 TCP 协议最初设计时，这个大小并没有被视为一个限制。
为了充分利用一个具有几毫秒延迟的快速网络，必须有一个比传统 TCP 支持的窗口更大的窗口。“64KB 限制”是协议规范的产物：TCP 头只为接收窗口大小保留 16 位。这允许接收窗口高达 64KB。在 TCP 协议最初设计时，这个大小并没有被视为一个限制。
不幸的是，想通过仅仅更改 TCP 头来支持更大的最大窗口值是不可能的。如果这样做就意味着 TCP 的所有实现都必须同时更新，否则它们将无法相互理解。为了解决这个问题，需要改变接收窗口值的解释。
不幸的是，想通过仅仅更改 TCP 头来支持更大的最大窗口值是不可能的。如果这样做就意味着 TCP 的所有实现都必须同时更新，否则它们将无法相互理解。为了解决这个问题，我们改变了对接收窗口值的解释。
“窗口缩放选项”允许这样做，同时保持与现有实现的兼容性。
“窗口缩放选项”允许你改变这个解释，同时保持与现有实现的兼容性。
#### TCP 选项：向后兼容的协议扩展
@ -64,44 +69,44 @@ TCP 响应程序检查连接请求中包含的所有选项号。 如果它遇到
         1         1         1
```
[窗口缩放][3] 选项告诉对等点，应该使用给定的数字缩放 TCP 标头中的接收窗口值，以获取实际大小。
[窗口缩放][3] 选项告诉对等方，应该使用给定的数字缩放 TCP 标头中的接收窗口值，以获取实际大小。
例如，一个宣告窗口缩放比例因子为 7 的 TCP 启动器试图指示响应程序，任何将来携带接收窗口值为 512 的数据包实际上都会宣告 65536 字节的窗口。 增加了 128 倍。这将允许最大为 8MB 的 TCP 窗口。
不能理解此选项的 TCP 响应程序将会忽略它。 为响应连接请求而发送的 TCP 数据包（SYN-ACK）不包含窗口缩放选项。在这种情况下，双方只能使用 64k 的窗口大小。幸运的是，默认情况下，几乎每个 TCP 堆栈都支持并启用此选项，包括 Linux。
响应程序包括它自己所需的比例因子。两个对等点可以使用不同的号码。宣布比例因子为 0 也是合法的。这意味着对等点应该逐字处理它接收到的接收窗口值，但它允许应答方向上的缩放值，然后接收方可以使用更大的接收窗口。
响应程序包括它自己所需的比例因子。两个对等方可以使用不同的号码。宣布比例因子为 0 也是合法的。这意味着对等点应该逐字处理它接收到的接收窗口值，但它允许应答方向上的缩放值，然后接收方可以使用更大的接收窗口。
与 SACK 或 TCP 时间戳不同，窗口缩放选项仅出现在 TCP 连接的前两个数据包中，之后无法更改。也不可能通过查看不包含初始连接三次握手的连接的数据包捕获来确定比例因子。
支持的最大比例因子为 14。这将允许 TCP 窗口的大小高达 1GB。
##### 窗口缩放的缺点
#### 窗口缩放的缺点
在非常特殊的情况下，它可能导致数据损坏。 在禁用该选项之前——通常情况下是不可能的。 还有一种解决方案可以防止这种情况。不幸的是，有些人在没有意识到与窗口缩放的关系的情况下禁用了该解决方案。 首先，让我们看一下需要解决的实际问题。 想象以下事件序列：
在非常特殊的情况下，它可能导致数据损坏。但在你禁用该选项之前，要知道通常情况下是不可能损坏的。 还有一种解决方案可以防止这种情况。不幸的是，有些人在没有意识到与窗口缩放的关系的情况下禁用了该解决方案。 首先，让我们看一下需要解决的实际问题。 想象以下事件序列：
1. 发送方发送段：s_1，s_2，s_3，... s_n
2. 接收方看到：s_1，s_3，.. s_n，并发送对 s_1 的确认。
1. 发送方发送段：s_1、s_2、s_3、... s_n
2. 接收方看到：s_1、s_3、... s_n，并发送对 s_1 的确认。
3. 发送方认为 s_2 丢失，然后再次发送。 它还发送段 s_n+1 中包含的新数据。
4. 接收方然后看到：s_2，s_n+1，s_2：数据包 s_2 被接收两次。
4. 接收方然后看到：s_2、s_n+1，s_2：数据包 s_2 被接收两次。
例如，当发送方过早触发重新传输时，可能会发生这种情况。 在正常情况下，即使使用窗口缩放，这种错误的重传也绝不会成为问题。 接收方将只丢弃重复项。
当发送方过早触发重新传输时，可能会发生这种情况。 在正常情况下，即使使用窗口缩放，这种错误的重传也绝不会成为问题。 接收方将只丢弃重复项。
#### 从旧数据到新数据
TCP 序列号最多可以为 4GB。如果它变得大于此值，则序列会回绕到 0，然后再次增加。这本身不是问题，但是如果这种问题发生得足够快，则上述情况可能会造成歧义。
如果在正确的时刻发生回绕，则序列号 s_2（重新发送的数据包）可能已经大于 s_n+1。 因此，在最后的步骤（4）中，接收器可以将其解释为：s_2，s_n+1，s_n+m，即它可以将 **“旧”** 数据包 s_2 视为包含新数据。
如果在正确的时刻发生回绕，则序列号 s_2（重新发送的数据包）可能已经大于 s_n+1。 因此，在最后的步骤（4）中，接收器可以将其解释为：s_2、s_n+1、s_n+m，即它可以将 **“旧”** 数据包 s_2 视为包含新数据。
通常，这不会发生，因为即使在高带宽链接上，“回绕”也只会每隔几秒钟或几分钟发生一次。原始和不需要的重传之间的间隔将小得多。
通常，这不会发生，因为即使在高带宽链接上，“回绕”也只会每隔几秒钟或几分钟发生一次。原始数据包和不需要的重传的数据包之间的间隔将小得多。
例如，对于 50MB/s 的传输速度，副本要延迟到一分钟以上才会成为问题。序列号的包装速度不够快，小的延迟才会导致这个问题。
例如，对于 50MB/s 的传输速度，重复副本要延迟到一分钟以上才会成为问题。序列号的回绕速度没有快到让小的延迟会导致这个问题。
一旦 TCP 达到 “GB/s” 的吞吐率，序列号的包装速度就会非常快，以至于即使只有几毫秒的延迟也可能会造成 TCP 无法再检测到的重复项。通过解决接收窗口太小的问题，TCP 现在可以用于以前无法实现的网络速度，这会产生一个新的，尽管很少见的问题。为了在 RTT 非常低的环境中安全使用 GB/s 的速度，接收方必须能够检测到这些旧副本，而不必仅依赖序列号。
一旦 TCP 达到 “GB/s” 的吞吐率，序列号的回绕速度就会非常快，以至于即使只有几毫秒的延迟也可能会造成 TCP 无法再检测到的重复副本。通过解决接收窗口太小的问题，TCP 现在可以用于以前无法实现的网络速度，这会产生一个新的，尽管很少见的问题。为了在 RTT 非常低的环境中安全使用 GB/s 的速度，接收方必须能够检测到这些旧副本，而不必仅依赖序列号。
### TCP 时间戳
#### 最佳使用日期。
#### 最佳使用日期
用最简单的术语来说，[TCP 时间戳][3]只是在数据包上添加时间戳，以解决由非常快速的序列号回绕引起的歧义。 如果一个段看起来包含新数据，但其时间戳早于最后一个在窗口内的数据包，则该序列号已被重新包装，而“新”数据包实际上是一个较旧的副本。 这解决了即使在极端情况下重传的歧义。