TCP 究竟有什么性能疑问

概述

TCP 的性能疑问实质是偏心与效率的取舍疑问。

TCP 成功牢靠传输层的外围有三点：

(1) 确认与重传 (曾经可以满足 “牢靠性”，但是或许存在性能疑问)

(2) 滑动窗口 (也就是流量控制，为了提高吞吐量，充沛应用链路带宽，防止发送方发的太慢)

(3) 拥塞控制 (防止网络链路过载形成丢包，防止发送方发的太快)

滑动窗口和拥塞控制相互制约，使发送方可以从网络链路的全局角度来智能调整发送速率，从这个角度来看，TCP 关于整个网络的意义曾经超越 “传输层”。

拥塞控制

相比滑动窗口，拥塞控制的视角更为片面，会对整个网络链路中的一切服务器、路由器，以及降落网络传输性能的无关要素启动综合考量。

既然拥塞控制要思索这么多要素，那就无法防止地会在某些场景下存在所谓 “性能疑问”，上方来详细剖析下。

1. 慢启动

慢启动自身不会形成性能疑问，由于慢启动时，cwnd(拥塞窗口大小值) 是指数级增长，所以 “慢启动” 其实并不慢，这一点咱们在之前的TCP 拥塞控制成功原理文章中曾经讲过了。

但是在特定场景下 (如 HTTP)，慢启动会参与数据传输的往复次数。

这里以Linux为例，内核在 3.0 之后，驳回了 Google 的倡导，将cwnd初始化为 10 个 MSS，自动的MTU为 1500,MSS为 1460, 那么，第一次性发送的 TCP 数据 (Segment) 总量为:

自动状况下，ssthresh 值为 65 KB，也就是从 慢启动阶段 进入到 拥塞防止阶段 的阈值。

咱们随意访问一个网站的主页 (例如 stackoverflow.com), 这里就以其 html 文本数据大小 (68.8 KB) 为例，说明一下慢启动关于服务端发送照应数据，带来了哪些性能影响。

经过 3 次发送后，14 + 28 + 56 = 98 KB, html 文本数据传输成功，一共教训了 3 个往复次数。

当网页资源加载成功后，普通很少再去加载其余资源/数据，但是此时，cwnd也才刚刚凑近ssthresh阈值大小。

假定如今咱们消弭掉慢启动阶段，间接火力全开，第 1 次就发送数据总量:65 KB, 那么就只要要教训 2 个往复次数，就可以成功数据传输。

2. 拥塞出现 (丢包)

在基于丢包的拥塞控制算法中 (例如 Reno、Cubic、NewReno), 以为一旦出现丢包，就是网络链路出现了拥塞，所以发送方会急剧地减小发送窗口，甚至进入持久的期待形态（超时重传）。

1%的丢包率并不仅是降落1%的传输性能，而是或许降落50%甚至更多 (取决于详细的 TCP 成功)，此时就或许出现极其状况: 网络花在重传被丢掉的数据包的期间比发送新的数据包的期间还要多，所以这是形成所谓 TCP 性能疑问的最大元凶。

丢包同时会减轻网络链路拥塞，假定 1 个 TCP 数据段转发到第 N 个路由器，前 N-1 个路由器曾经成功转发，但是第 N 个路由器转发时失落了数据段，最终造成失落的数据段糜费了前面一切路由器的带宽。

TCP Reno 算法出现丢包时，性能间接腰斩

TCP Tahoe 算法出现丢包时，间接重置，进入慢启动环节

这里以 HTTP 场景为例，丢包带来的影响在HTTP/2中体现更为重大，由于HTTP/2只经常使用 1 个 TCP 衔接启动传输。所以 1 次丢包会造成一切的资源下载速度变慢。而HTTP/1.1或许有多个独立的 TCP 衔接，1 次丢包也只会影响其中 1 个 TCP 衔接，所以这种场景下HTTP/1.1反而会取得更好的性能。

3.顺序牢靠性保障

虽然 TCP 确保一切数据包有序抵达，但是这个顺序语义保障或许会引发相似HTTP 队列头部恳求阻塞(head of line blocking) 疑问。

TCP 在传输时经常使用序列号 (Seq) 标识数据的顺序，一旦某个数据失落，后续的数据须要保留在接纳方的 TCP 缓冲区中，期待失落的数据重传成功后，能力启动下一步处置 (传递到运行层)。

运行层无法得悉 TCP 接纳缓冲区的状况，所以肯活期待序列 (Seq) 完整之后才可以失掉运行数据。但是实践上，曾经接纳到的数据包中，很或许就有运行层可以间接处置的数据，所以，这也可以称之为TCP 队列头部恳求阻塞(head of line blocking) 疑问。

4.改良和提升

针对基于丢包的拥塞控制算法，最显著的改良就是经常使用更为正当的拥塞控制算法，例如可以更好地顺应高带宽、高时延、且容忍必定丢包率的 BBR 算法。

假设保障 TCP 可以在0 丢包的前提下传输数据，那么人造而然可以最大化应用带宽。