[翻译] 广域网下的网络传输

[翻译] 广域网下的网络传输

我的网络性能在局域网很好, 但在广域网中表现很糟糕. 为什么?

影响 TCP 性能的主要因素有三个(还有其他因素, 但这是主要的三大因素): 丢包, 延迟(或RTT - 往返时间), 以及缓冲区/窗口大小. 这三者是相互关联的.

延迟/RTT

延迟/RTT 是数据包从发送方到接收方再返回(“往返”)所花费的时间. 这是一个主机从另一个主机获得关于所发送数据的信息的最短时间.

缓冲区和窗口大小

缓冲区和窗口大小决定了内核为连接保留在缓冲区中的数据量, 以及通过 TCP 连接的 “发送窗口” (通过 TCP 的发送窗口信息反映了可用缓冲区的大小). 窗口越大, 在两台主机之间传输的数据就越多. 注意, 如果窗口小于可用带宽乘以延迟(带宽延迟乘积: C * RTT), 那么发送方发送一个完整的数据窗口后会空等待接收方确认数据. 这导致了较低的性能, 也是 TCP 缓冲区自动调优存在的主要原因 - 如果没有自动调优, 您需要设置系统全局参数来优化每个目标主机, 或者应用程序必须了解底层网络才能正确设置其缓冲区大小. 通过自动调优(假设最大缓冲区大小设置得足够高但会不太高), 内核将根据每个连接的延迟正确调整 TCP 缓冲区/窗口的大小.

所以, 这一切都很好 - 它比多年前好多了, 只要网络干净, 现在的性能通常都很好.

丢包

第三个因素是丢包 - 这是使事情变得复杂的地方.

当 TCP 遇到丢包时, 它会降低其发送速率. 通过减少发送方窗口的机制, 以便它尝试发送更少的数据. 然后 TCP 再次提高其发送速率, 并希望丢包是暂时的. 现在的情况比多年前好得多 … 像 htcp 和 cubic 这样的拥塞控制算法比旧的方案(TCP Reno)更具攻击性(更高的吞吐量).

当 TCP 遇到丢包时, 它必须恢复 - 但是它从一个小窗口开始, 并随着时间的推移再次打开它. 延迟越长, 这样做的控制循环就越长. 因此, 在所有其他条件相同的情况下, TCP 连接从丢包中恢复所需的时间会随着往返时间的增加而增加.

然而, 当您在路由器, 交换机和防火墙中添加小缓冲区时, 还有其他问题会使丢包和延迟之间的交互复杂化.

当延迟很大时(任何超过 10 毫秒的事情都开始成为问题, 超过 20 毫秒的事情就变得非常棘手), 需要大窗口来获得足够的吞吐量. 当窗口很大时, TCP 可以一次性发送大量数据. 网卡通常不知道或不关心是否是 TCP. 网卡只知道当有数据包要发送时, 它就把数据包扔到链路上, 直到没有数据包要发送为止. 这种情况发生在任何链接速度的网卡配置下, 例如 10Gbps.

因此, 如果 TCP 窗口是 4MB, TCP 把 4MB 的数据传递给网卡, 网卡将以 10Gbps 的速度将数据突发发送到链路上. 这意味着发送方和接收方之间路径上的每个设备都会看到高速的数据包爆发, 如果路径上的任何地方存在缓冲或排队问题, 其中一些数据包将被丢弃, 导致 TCP 退化.

由于要求低延迟连接, TCP 窗口要小得多, 因此在低延迟时通常不会注意到这些问题. 如果数据包丢失是由于随机错误(例如, 脏光纤, 边缘光学, 电缆长度超过规格), 那么这里和那里会有一些丢包, 并且在低延迟下 TCP 将很快恢复, 人们通常不会注意到性能损失.

如果路径中有小的交换机缓冲区, 它们通常不会对低延迟连接造成损失, 因为 TCP 发送的爆发不够大, 不会造成损失. 但是, 如果使用相同的基础设施将数据发送到很远的主机, 则会看到性能急剧下降. 在随机错误的情况下, TCP 将始终处于恢复模式, 发送窗口始终很小. 在缓冲区较小的情况下, TCP 将逐渐增大, 遇到丢包, 减少其窗口, 再次增大, 以此类推 - 因此 TCP 将有效地始终具有较小的窗口, 并且性能较差.