5 ms·
I'm interested in using HTTP/3 for bi-directional communication. Anyone with more experience on this care to weigh in? I know there's WebSockets but that's ty
by john567 5y ago
I'm interested in using HTTP/3 for bi-directional communication.
Anyone with more experience on this care to weigh in?
I know there's WebSockets but that's typically implemented over HTTP/1.1 with durable TCP connections.
Let's say I wanted to do near real time (lowest possible latency preferably) synchronization in a server/client architecture, can HTTP/3 make sense here?
- Matthias247 5y agoHTTP/3 pretty much performs like HTTP/2 there. You kind of have 2 options: 1. Make as many requests/responses as you require, and let the mulitiplexing of the protocol level do the job for you. Still might mean extra latency for sending another request to get the next chunk of data, but you might be able to send it ahead of time (long-polling style). 2. Make a single request, and stream all data bidirectionally in the request and resopnse body. bodies can be almost infinite and if you are using a custom library you can use them however you want. E.g. put small delimited messages into it in either direction - which is what gRPC streaming is doing. This will require libraries which actually support streaming, and not just Request->Response. Especially browsers are tricky here. All those options have in common that you get reliability and flow-control in them. If you don't want to have that - because you maybe e.g. rather want to skip outdated data - then building on a lower layer like directly on QUIC makes more sense. This capability might come to browsers with WebTransport.