7

由于服务器和客户端之间的地理距离，网络延迟可能会有很大差异。所以我想得到“纯”的req。没有网络延迟的服务处理时间。

我想将网络延迟作为 TCP 连接时间。据我了解，这个时间很大程度上取决于网络。

主要思想是计算：

  • TCP连接时间，
  • TCP第一个数据包接收时间，
  • 获取“纯”服务时间 = TCP 第一个数据包接收（等待时间）- TCP 连接。

我将 TCP 连接除以 2，因为实际上有 2 个请求响应（3 次握手）。

我有两个问题：

  1. 我应该计算 TCP 所有数据包的接收时间而不是只计算第一个数据包吗？
  2. 这种方法一般可以吗？

PS：作为工具，我使用 Erlang 的 gen_tcp。我可以显示代码。

4

2 回答 2

4

如果有的话，我猜“纯”服务时间 = TCP 第一个数据包接收 - TCP 连接.. 你已经写了其他方式。

您的第一个问题的一个可能答案是，理想情况下，您应该通过考虑许多数据包的纯服务时间而不仅仅是第一个数据包来计算至少某种平均值。

理想情况下，它还可以有最坏情况、平均情况、最佳情况服务时间。

要回答第二个问题，我们需要您为什么只需要纯服务时间。我的意思是，既然它是一个网络应用程序，网络延迟（连接时间等......）也应该包含在“响应时间”中，而不仅仅是纯粹的服务时间。这是我基于给定信息的观点。

于 2013-03-05T14:26:44.657 回答
1

在过去为网络性能监控供应商工作时，我曾研究过类似的问题。恕我直言，在继续之前有一些问题要问：

  • 连接时间和延迟：如果您基于网络延迟指标，请注意它考虑了 3 个步骤：客户端发送 TCP/SYN，服务器以 TCP/SYN-ACK 响应，客户端以最终 ACK 响应以设置TCP 连接。这意味着 CT 相当于 1.5 RTT（往返时间）。这验证了您提到的在帐户中执行 TCP 设置过程的前两个步骤。
  • 考虑到后来的 TCP 交换：虽然这听起来像是在会话过程中不断评估网络延迟的好主意，但这变得更加棘手。原因如下： 1. 并非所有数据包都必须得到确认（RFC1122 或https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment），当它发生时会产生错误的测量结果，因此您需要启发式方法来取消这些数据包你的计算。2. 并非所有系统都将确认数据包视为高优先级任务。这意味着一些高值会污染您的网络延迟数据，并仅反映服务器的负载水平。

因此，如果您只使用第一个（且可靠的）测量，您可能会错过一些网络延迟变化（尤其是在使用持久 TCP 会话的应用程序中）。

于 2021-05-06T15:01:17.860 回答