当通过TCP发送的消息速率增加时，为什么请求-响应消息对的等待时间减少？

Question

简介

我有一个通过TCP连接进行通信的客户端和服务器的设置，我遇到了奇怪的延迟行为，我无法理解。

上下文

客户端向服务器发送请求消息，然后服务器向客户端发送响应消息。我将latency定义为从发送请求消息到接收响应消息的时间。我可以以不同的[[rates发送请求消息（限制请求的频率），但是在任何时候我总是最多只有一条未完成的请求消息。即，无并发/重叠请求-响应消息对。

我已经以三种方式实现了请求和响应消息的发送：首先是使用我自己的序列化方法直接在TCP套接字上，其次，是使用gRPC通过HTTP2在RPC上进行通信，第三是使用Apache Thrift（一个RPC框架类似于gRPC）。gRPC依次以4种不同的客户端/服务器类型实现，对于Thrift，我有3种不同的客户端/服务器类型。

[在所有解决方案中，当增加请求消息的发送速率时，我会减少等待时间（在gRPC和Thrift中，通过RPC方法传递请求-响应对）。当完全不限制请求速率，而是在收到响应后立即发送新请求时，观察到最佳延迟。延迟是使用std :: chrono :: steady_clock原语测量的。我不知道是什么原因造成的。我确保在开始实际测试之前通过发送10k请求消息来预热TCP连接（通过TCP缓慢启动阶段）。

我如何实现节流并测量延迟（在客户端ofc上：]

double rate;
std::cout << "Enter rate (requests/second):" << std::endl;
std::cin >> rate;
auto interval = std::chrono::microseconds(1000000)/rate;

//warmup-phase is here, but not included in this code.

auto total_lat = std::chrono::microseconds(0);
auto iter_time = start_time;
int i = 0;
for(i = 0; i < 10000; i++){ // send 10k requests.
  iter_time = std::chrono::steady_clock::now();
  RequestType request("ABCDEFGHIJKLMNOPQRSTUVWXYZ");
  ResponseType response;
  auto start = std::chrono::steady_clock::now();
  sendRequest(request); //these looks different depending on gRPC/Thrift/"TCP"
  receiveResponse(&response);
  auto end = std::chrono::steady_clock::now();
  auto dur = std::chrono::duration_cast<std::chrono::microseconds>(end-start);
  total_lat+=dur;
  std::this_thread::sleep_until(iter_time+interval); //throttle the sending..
}
// mean latency: total_lat / i

我使用docker-compose在单独的docker容器中运行客户端/服务器，我也在kubernetes集群中运行它们。在这两种情况下，我都会经历相同的行为。我在想，也许我的节流/时间测量代码正在做我不知道/不了解的事情。
在所有情况下，TCP套接字都设置为TCP_NODELAY。服务器是单线程/多线程的非阻塞/阻塞，有各种不同的变体，客户端是同步的，有些是异步的等等。因此，尽管有很多变体，但它们在所有变体中都表现得一样。
这里有什么想法可能导致这种行为？

Answer 1

现在，我认为延迟问题不在网络堆栈中，而是在您生成和接收消息的速率中。

您的测试代码似乎没有任何实时保证，这也需要在容器中设置。这意味着您的“ for循环”并非每次都以相同的速度运行。 OS调度程序可以停止运行其他进程（这是进程共享CPU的方式）。使用容器化机制，这种行为会变得更加复杂。

虽然TCP中有一些机制可以引起延迟变化（如@DNT所述），但我认为您不会看到它们。特别是如果服务器和客户端是本地的。这就是为什么在查看TCP堆栈之前先排除消息生成和接收的速率的原因。