Flow control
HTTP/2 multiplexed frames unleash the potential to take full advantage of the network resources, but without a flow control you lose any sense of traffic congestion. Any peer sending data needs to know the ingestion capabilities of the receiver, otherwise the frames can be lost. If the receiver is busy doing other stuff, it needs to be able to communicate to the sender to slow down the cadence.
TCP protocol already considers flow control by communicating the receive window
of each peer. This is the equivalent buffer size of each end point to hold incoming data. Each TCP ACK
signal contains an updated receive window
in function of the receiver availability.
The problem with TCP flow control, is that it doesn’t have enough Application Level granularity. Multiple streams in the same TCP connection prevent the optimizing of the receiving flow for each pair of stream-applications.
So in addition to TCP flow control, HTTP/2 uses the WINDOW_UPDATE
frame type (type=0x8) to...