grpc - 流窗口大小与 HTTP/2 和流性能有关

Question

我遇到了的概念窗口大小 浏览 gRPC 时 dial options .因为gRPC底层使用的是HTTP/2，所以挖了这个article up，它描述了:

Flow control window is just nothing more than an integer value indicating the buffering capacity of the receiver. Each sender maintains a separate flow control window for each stream and for the overall connection.

如果这是 gRPC 讨论的窗口大小，我理解正确。这是为了 HTTP/2 在同一个连接中维护多个并发流。基本上是一个向发送方通告接收方希望发送方接下来发送多少数据的数字。出于控制流的原因，连接将不同流的数据串行放置在不同的窗口之间。
我的问题是: window 是全部还是什么都没有？意思是如果我的窗口大小是 n字节，流不会发送任何数据，直到它累积至少 n字节？更一般地说，如果我维护 ，我如何最大限度地提高流的性能只有一个流 ?我认为更大的窗口大小有助于避免开销但会增加数据丢失的风险？

Answer 1

Meaning if my window size is n bytes, the stream won't send any data until it's accumulated at least n bytes?

不。
发送方可以发送小于或等于 n 的任意字节数.

More generally, how do I maximize the performance of my stream if I maintain only one stream?

对于一个流，只需使用最大可能值， 2^31-1 .
此外，您要配置接收器以发送 WINDOW_UPDATE帧足够快，以便发送方始终拥有足够大的流量控制窗口，使其永不停止发送。
需要注意的一件重要事情是最大流量控制窗口的配置与接收器的内存容量有关。
由于 HTTP/2 是多路复用的，实现必须继续读取数据，直到流控窗口耗尽。
使用最大流量控制窗口 2 GiB 意味着接收器需要准备好缓冲至少 2 GiB 的数据，直到应用程序决定使用该数据。
换句话说:实现从网络读取数据，应用程序使用这些数据可能以不同的速度发生；如果读取比消耗快，则实现必须读取数据并将其累积到一边，直到应用程序可以使用它。
当应用程序消费数据时，它告诉实现消费了多少字节，并且实现可能会发送一个 WINDOW_UPDATE帧发送给发送方，再次放大流量控制窗口，以便发送方可以继续发送。
请注意，实现确实希望应用背压，即在发送 WINDOW_UPDATE 之前等待应用程序使用数据s 返回给发件人。
如果实现(错误地)在将数据传递给应用程序之前确认了数据的消耗，那么它对内存爆炸是开放的，因为发送方将继续发送，但接收方被迫将其累积到一边，直到它的主机内存接收器耗尽(假设应用程序消耗数据比从网络读取数据的实现慢)。
鉴于上述情况，对于最大流量控制窗口，单个连接可能需要多达 2 GiB 的内存。
想象一下 1024 个连接(对于服务器来说不是很多)，您需要 2 TiB 的内存。
还要考虑到对于如此大的流量控制窗口，您可能会在流量控制窗口耗尽之前遇到 TCP 拥塞(线头阻塞)。
如果发生这种情况，您基本上会回到 TCP 连接容量，这意味着 HTTP/2 流量控制限制永远不会触发，因为 TCP 限制之前触发(或者您受到带宽等的其他限制)。
另一个需要考虑的是，您希望避免发送方耗尽流量控制窗口，从而被迫暂停并停止发送。
对于 1 MiB 的流量控制窗口，您不想接收 1 MiB 的数据，消费它然后发回 WINDOW_UPDATE 1 MiB，否则客户端将发送 1 MiB，暂停，接收 WINDOW_UPDATE ，再发送 1 MiB，再次停止，等等(另见 how to use Multiplexing http2 feature when uploading)。
从历史上看，小的流量控制窗口(如 64 KiB 规范中建议的那样)导致浏览器下载速度超慢，浏览器很快意识到他们需要告诉服务器他们的流量控制窗口足够大，这样服务器就不会停止下载。
目前，Firefox 和 Chrome 将其设置为 16 MiB。
您想向发件人提供 WINDOW_UPDATE s 所以它永远不会停止。
这是应用程序消耗接收数据的速度的组合，在发送 WINDOW_UPDATE 之前您希望“累积”消耗的字节数的数量。 (避免发送 WINDOW_UPDATE过于频繁)，以及 WINDOW_UPDATE需要多长时间从接收者到发送者。