如何在没有网络延迟的情况下计算HTTP请求处理时间？

Question

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

我希望将网络延迟作为TCP连接时间。据我所知，这段时间在很大程度上取决于网络。

主要思想是计算：

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

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

我有两个问题：

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

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

Answer 1

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

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

理想情况下，它也可能具有最坏情况，平均情况，最佳案例服务时间。

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

Answer 2

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

• 连接时间和延迟：如果您基于网络延迟指标，请注意它需要考虑 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 会话的应用中）。