Istio中maxRequestsPerConnection参数为何会影响HTTP/1.1请求？

你的疑惑源于对maxRequestsPerConnection参数作用的理解偏差，以及它和Istio连接池其他参数的交互逻辑，咱们一步步拆解原因：

核心认知纠正 #

首先要明确：HTTP/1.1单TCP连接同一时间只能串行处理一个请求这个结论没错，但maxRequestsPerConnection控制的是该TCP连接生命周期内可处理的总请求数量，而非并发请求数。当值为1时，每个连接处理完1个请求就会被关闭；值为10时，一个连接可以连续处理10个请求后才会被销毁。

结合你的配置分析第一次压测结果 #

先看你初始的DestinationRule配置：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: httpbin
spec:
  host: httpbin
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1  # 连接池最多只能维持1个TCP连接
      http:
        http1MaxPendingRequests: 1  # 连接忙时，最多允许1个请求排队等待
        maxRequestsPerConnection: 1  # 每个连接仅能处理1个请求就关闭

你的Fortio压测参数是-c 5（5个并发客户端）、qps 0（尽可能快发起请求），实际流程是：

1. 第一个请求到达时，Istio新建TCP连接处理它，此时连接池已达上限（maxConnections=1）。
2. 第二个请求进入等待队列（http1MaxPendingRequests=1）。
3. 剩余3个请求因为连接池满且队列也满，直接被Istio返回503。
4. 第一个请求处理完成后，该TCP连接被立即关闭（因为maxRequestsPerConnection=1）。Istio需要新建连接处理队列里的第二个请求，但在新建连接的间隙，又有大量新请求涌入，再次触发连接池+队列满的情况，导致大部分请求被拒绝。

这就是第一次压测仅12.6%请求返回200的原因。

修改maxRequestsPerConnection=10后的变化 #

当你把参数调整为10后：

• 每个TCP连接可以连续处理10个请求，无需每次处理完就关闭重建，连接复用率大幅提升。
• 当一个请求处理完成后，同一个连接可以立即处理队列里的下一个请求，甚至新到来的请求，不需要等待新建连接的间隙时间。
• 更多请求能被及时纳入连接池或队列处理，不会因为资源耗尽被直接拒绝，因此200响应比例提升到了28.1%。

你看到的sockets used数值从876降到723，也侧面印证了连接复用的提升——更少的socket被创建，因为每个socket承载了更多请求。

内容的提问来源于stack exchange，提问作者yu saito