search

akka / akka-http

The Streaming-first HTTP server/module of Akka
https://doc.akka.io/docs/akka-http
Other
1.34k stars 594 forks source link

Discuss whether WINDOW_UPDATEs should be sent out eagerly #3610

Open jrudolph opened 3 years ago

jrudolph commented 3 years ago

The "WINDOW goals" for incoming data are configured using the http2.incoming-connection-level-buffer-size and http2.incoming-stream-level-buffer-size settings. However, these values are not immediately conveyed to the peer:

The potential disadvantage of the current behavior is that peers (especially clients) might be not allowed to use the full bandwidth of a connection (as configured through the settings) until data is first received (on the connection or the entity stream).

For servers that might be a conservative behavior after all: requests don't include entity data in most cases (like usual GET requests). On a connection that only ever uses GET requests, no WINDOW_UPDATEs will ever be sent.

For clients, (response) entity data is quite likely on the other hand, so we might optimize there by sending out WINDOW_UPDATEs eagerly, so that servers are immediately allowed to send as much response data as configured. (If we go that way, we should use the same behavior for servers and clients and don't care about those little extra WINDOW_UPDATE frames that we would send eagerly).

ignasi35 commented 3 years ago

I think eagerly sending WINDOW_UPDATE is preferable in gRPC:

jrudolph commented 3 years ago

I think eagerly sending WINDOW_UPDATE is preferable in gRPC:

  • request payload is very likely (even if small)
  • network bandwidth (especially in microservices setups) is way higher than general web use cases (browser-server)

Not sure it would really fit the use case then. In any case the default window size is 65536, which should be enough for non-streaming normal gRPC requests. Sending out the WINDOW_UPDATE eagerly will mainly benefit peers behind a high-bandwidth-delay product connection. In the worst case, sending lazily will add half a RTT to the first big data packet.