Reverse proxy Too much Tcp Connection issue

[linking12]

Reverse proxy Too much Tcp Connection issue

[lianglli]

1. 目前不支持后端upstream的H3协议，如果有广泛的业务场景需求，可以考虑排期支持。
   在长连接业务中是有收益的，大量的客户端h3长连接到tengine，tengine到后端维持h3长连接。

2. angie这个queue相当于加了一层buffer，但队列满时，依旧是502，这个功能的意义不是很大。可以适当调整$upstream_read_time后端超时时间，并且保证客户端调用侧的超时时长大于后端upstream的超时时长。

[lhanjian]

1. 目前不支持后端upstream的H3协议，如果有广泛的业务场景需求，可以考虑排期支持。
   在长连接业务中是有收益的，大量的客户端h3长连接到tengine，tengine到后端维持h3长连接。
2. angie这个queue相当于加了一层buffer，但队列满时，依旧是502，这个功能的意义不是很大。可以适当调整$upstream_read_time后端超时时间，并且保证客户端调用侧的超时时长大于后端upstream的超时时长。

现在是否有h2 upstream可以开源出来了？

[linking12]

1. 目前不支持后端upstream的H3协议，如果有广泛的业务场景需求，可以考虑排期支持。
   在长连接业务中是有收益的，大量的客户端h3长连接到tengine，tengine到后端维持h3长连接。
2. angie这个queue相当于加了一层buffer，但队列满时，依旧是502，这个功能的意义不是很大。可以适当调整$upstream_read_time后端超时时间，并且保证客户端调用侧的超时时长大于后端upstream的超时时长。
   @lianglli 多谢回复，关于2的话，我有一个场景困扰很久；

对于nginx来说反向代理走http1.1协议，在突增流量的情况下，如果backend的接口响应变慢了，nginx会大量开启新的TCP连接到backend，这个并不是预期的，所以走h2/h3的连接复用或者通过queue缓存一部分request应该是比较好的选择，或者面对突增流量，下游接口变慢有更好的解决方案吗？