使用静态打开的 Web 套接字建立新连接没有开销（因为连接已经打开并建立），但是当您在地球的另一端发出请求时，网络需要一些时间，因此当您“正在与地球另一端的服务器交谈。
这就是网络的运作方式。
您从您自己 LAN 上的服务器获得近乎即时的响应，并且服务器距离（在网络拓扑方面）越远，每个数据包通过的路由器越多，总延迟就越大。正如您在之前与此主题相关的问题中所看到的，当您tracert从您的位置到服务器位置执行 a 时，您会看到每个数据包必须遍历很多不同的跃点。这些跃点中的每一个的时间都加起来，如果繁忙的路由器没有立即处理您的数据包，它们也可能会增加一个小的延迟。
发送数据包和获得响应之间的延迟只是数据包传输时间的 2 倍，加上您的服务器响应所需的时间，再加上 TCP 的一点点开销（因为它是一个可靠的协议，它需要确认）。您无法加快传输时间，除非您选择更近的服务器或以某种方式影响数据包采用的路由到更快的路由（一旦您选择了要使用的本地 ISP，这通常不受您的控制）。
终端上的任何缓冲都不会减少到服务器的往返时间。
此外，客户端和服务器之间的网络跳数越多，传输时间从一个时刻到下一个时刻的变化就越大。数据包经过的每一台路由器以及它所经过的每一条链路都有自己的负载、拥塞等……随着时间的推移而变化。您可能会观察到最小传输时间（它永远不会比 x 快），但是随着时间的推移，许多事情会影响它，使其在某些时候比它慢。甚至可能有 ISP 将路由器脱机进行维护的情况，这会给处理流量的其他路由器或跳之间的路由带来更多负载，因此临时但更慢和更长的路由被替代。有数百种事情会导致运输时间不时变化。
您还没有说明这是否相关，但是当给定往返的延迟很差或性能非常重要时，您想要做的是尽量减少您等待的往返次数。您可以通过以下几种方式做到这一点：
1. 不要对小块数据进行排序。 发送大量数据的最慢方法是发送一点数据，等待响应，再发送一点数据，等待响应等......如果你有 100 个字节要发送并且你发送了数据 1每次等待响应一个字节，而您的往返时间是 X，那么您发送所有数据的总时间是 100 倍。相反，收集更大的数据并一次发送。如果您一次发送 100 个字节，您可能只有 X 的总延迟而不是 100X。
2. 如果可以，并行发送数据。 上面解释了发送数据，等待响应，发送更多数据，当往返时间很短时等待响应慢的模式。如果您的数据可以标记为独立存在，那么有时您可以并行发送数据，而无需等待先前的响应。在上面的例子中，发送 1 个字节，等待响应，发送下一个字节，等待响应非常慢。但是，如果您发送 1 个字节，然后发送下一个字节，然后发送下一个字节，然后在一段时间后处理所有响应，您将获得更好的吞吐量。显然，如果您已经有 100 字节的数据，您也可以一次发送所有数据，但是如果数据是实时到达的，您可能只想在它到达时将其发送出去，而不是等待先前的响应。
3. 一次发送更大的数据。 如果可以，请一次发送更大的数据块。根据您的应用程序，在发送之前实际等待数据累积可能有意义也可能没有意义，但是如果您已经有 100 字节的数据，则尝试一次发送所有数据，而不是将其分成较小的部分发送。
| 归档时间： |
|
| 查看次数： |
1513 次 |
| 最近记录： |