我有一种情况，我需要在使用 grpc-go 时设置max_concurrent_streams 选项。
所以我读了这个RFC7540 document。
我阅读了这篇文章并进行了搜索，但我有一个问题仍未得到解答。
【问题讨论】：
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 协议，通常不需要像网页那样同时请求许多相关的小资源；因此，gRPC 服务器的max_concurrent_streams 值通常由特定于应用程序的因素决定。
总而言之，没有确切的答案：您必须测量并查看，或者您必须知道您的应用程序是如何工作的。
如果您知道单个客户端永远不会发出并发 gRPC 请求，那么您可以保留默认值 100，或者相反将其减少到 1。该连接中唯一存在的流将能够进入整个连接流控制窗口（除非流配置了较小的每个流的流控制窗口）。
如果您知道单个客户端会发出并发 gRPC 请求，则您必须知道或测量将交换多少、以及多少数据，并为此进行调整。
我会从默认的一切开始，监控服务器并查看它是如何工作的。可能是默认值就好了，你不需要做任何事情。
【讨论】：