HTTP/2 的设计主要是为了改善浏览体验，请原谅我的简化。
网页变得更加丰富，HTTP/1.1 强制使用了许多“技巧”来克服单个页面可以引用同一域上的数十个其他资源的事实 - 想想 *.css、*.js、*.png 等. 下载index.html，然后浏览器必须再发出 10-60 个请求来下载 . 引用的依赖资源index.html。
考虑到这一点，HTTP/2 的max_concurrent_streams并行度远大于 6-8（HTTP/1.1 可以实现的并行度），但显然不需要是 2^32-1。值 100 是当前网页最大值的良好近似值。
目前尚不清楚您是否“必须设置max_concurrent_streams”只是因为它是必需的，但是该值并不重要，只要它是一个合理的值并且您想更好地理解它即可。
或者，如果您必须将其设置为特定值，甚至可能动态设置，因为这是您的应用程序所需要的，所以该值确实很重要。
无论哪种情况，2^32-1 都不是一个好的值，因为它是邪恶客户端的一个简单的攻击向量。他们将打开一个连接，查看您的服务器允许 2^32-1 个流，并强制创建这么多流，这可能会耗尽服务器的内存。如果一个连接不足以炸毁服务器，它们将打开更多连接，并且每个连接有 2^32-1 个流。不好。
此外，由于 HTTP/2 是一个多路复用协议，因此需要流量控制。HTTP/2定义了连接流量控制窗口和流流量控制窗口。流流量控制窗口接入连接流量控制窗口。
这意味着较小的max_concurrent_streams值允许每个流使用连接流控制窗口的较大部分进行下载（从服务器到客户端）。对于每个客户端不进行大量并发下载的文件服务器来说，这可能是一个很好的配置。
相反，较大的max_concurrent_streams值允许更多并发请求，但每个流的流量控制窗口较小。对于网页服务器来说，这可能是一个很好的配置，其中应该同时提供许多资源，但它们可能相当小。
gRPC 是一种通用的 RPC 协议，通常不需要像网页那样同时请求许多依赖的小资源；因此，max_concurrent_streamsgRPC 服务器的价值通常由特定于应用程序的因素决定。
总之，没有确切的答案：您必须测量并查看，或者您必须知道您的应用程序如何工作。
如果您知道单个客户端永远不会发出并发 gRPC 请求，那么您可以保留默认值 100，或者相反将其减少到 1。该连接中存在的唯一流将能够接入整个连接流量控制窗口（除非该流配置了较小的每流流量控制窗口）。
如果您知道单个客户端将发出并发 gRPC 请求，您将必须知道或测量将交换多少数据以及多少数据，并进行调整。
我将从默认的一切开始，监视服务器并查看它是如何工作的。可能默认值就很好，您无需执行任何操作。
| 归档时间： |
|
| 查看次数： |
8919 次 |
| 最近记录： |