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...
