Internet的大部分都不能按照用户希望的那样传输数据包。点对点流量和垃圾邮件进一步阻塞了链接。路由器不得不处理这些超额的流量，往往是直接丢弃这些流量，并依赖TCP挽回丢失。

    数据的丢失一般意味着必须重发数据，这一过程也就是所谓的重传。本文说“一般”是因为许多基于UDP的应用（如语音和视频）能够承受一定量的丢失。在某些情况下（如实时更新），分发比获得百分之百的数据更重要。对语音电话来说，通话过程有短暂的中断比越来越大的延迟要好得多。

    TCP协议处理数据重发，尽管这回增加一点数据。假设从公路A点到B点需要1min，如果公路上只有一辆车往返，就可以每隔2min发送一整车的货物。增加一倍的车辆，就可以增加一倍每分钟的运输量。但是这里有一个限制：在某个点上，公路会变得拥塞，增加车辆会减慢所有的车辆。也许是交通事故或车辆熄火，不管是那种情况，都需要减少车辆数。换句话说，有一个最佳的车辆数可以使每分钟运输的货物最多。

    TCP使用一种非贪婪的方式尽可能多地传输数据。TCP也会在传输中寻找最优的数字。为了做到这一点，先发送一个数据包并等待响应，然后发送一对数据包并等待响应。不断重复这个过程，在发送者和接收者之间发送越来越多的数据包，直到出现错误。实际上，不同的计算机和设备有不同的初始化数据包数和不同的斜率来榨取更多的Internet性能，但是基本功能是一样的。

    丢包有以下3种效果。

   （1）TCP重发数据包，会消耗带宽。

   （2）发送者的TCP协议栈减少数据包数量，减少连接的总带宽。

   （3）对于用正确顺序分发和接收数据包的TCP来说，不得不保持其他数据包直到正确的数据包到达，这意味着它不能分发内容的其他部分直到被请求的数据包到达。

    换句话说，丢包是不好的。页面越大，网络就越拥塞，发送者和接收者之间的距离越远，对象越多，丢包的几率就越大。

    要尽最大努力地减少往返时间，大多数方法是显而易见的，使内容离终端用户更近，确保内容尽可能的小。大多数Web应用延迟来自于趟数，它是获得多个对象的过程中来往重复形成的，会真正拖慢网站。