上文讲过，在以太网中，不论要发多少字节的TCP数据，78个字节的固定协议格式是必须的。很显然，每个以太网帧越大，最大不超过1538个字节，则有效载荷占比越高。而以太网帧越小，同样字节的应用层数据，需要分拆成更多的包。这个结论在后续的分析中会用到，不再赘述。

在网络中，点到点的延迟，最大因素是距离。比如局域网内，可以做到1毫秒以内，同城则需要10毫秒，甚至更多，而城际之间，比如上海到北京，需要30到50毫秒。洲际之间，比如上海到纽约，可能要达到300毫秒，卫星可能会少点，暂时没有这个数据。这些数据并不是精确的值，会受到很多因素影响。这个距离直接决定了RTT的值。

第二个因素就是RTO，超时重传。看起来只是一个简单的值，但如何估算一个准确有效的值，相关RTO的算法就有很多讨论和论文。早期TCP协议栈中，RTO有指数退避算法，丢了3个包，RTO就是初始的8倍。在linux中，RTO默认最小值为200毫秒。如果发生了丢包，那么传输延迟就直接被打骨折了。在新版Linux内核中，已经实现了RFC6298，对RTO的估算有了不小的改进。因此，重传率在网络中是非常重要的一个指标。

第三个因素是滑动窗口，当接收端的处理慢时，发送方每次能够发送的字节数就不断被缩小，直到为0。正如文章开头所说的，相同字节的数据就要被拆成更多的以太网帧，自然就慢了。

第四个因素是拥塞控制算法，和RTO的算法一样，有很多讨论和论文。根本点，还是在改善重传效率上，既要快速恢复，又要不重复传输。

针对TCP的延迟，还有更多的优化方案，后续再讨论。
 

在高速网络中，比如40Gbps，甚至100Gbps的网络，网络传输速度已经和芯片内部的传输速度相差无几，对程序提出更苛刻的要求，暂时不深入讨论。