So, in order to have HTTP/2 supports multiplexing by using single TCP connection, we need a way to differentiate different request/response pair through single TCP connection, thus we introduce stream ID as the key mapping to request/response.
TCP has it's own sequence number to construct the packets in order on the receiving side.
Thus, the upper HTTP layer will receive the ordered TCP response thus base on stream ID can it builds up the response/request pair.
When the HTTP/2 TCP connection is established,
the client and server exchange SETTINGS frames first,
(like TCP's MSS setting option during init. SYN handshake, can't be changed once connection is established)
which indicates how many streams can be open at a time(or how many parallel requests), how many bytes server is ready to receive for a stream and for the whole connection, and the rate at which data can be delivered or received i.e., window size.
As you can spot there's a performance issue here.
TCP also times-out if missing a package(receiving side) during transfer which triggers sender side to re-send.
(triple ACK, slow start and fast recovery, sliding window/receiving side and congestion window/sender side)
Like VxLAN, UDP comes to the rescue.
(Since it's unreliable protocol, send and forget)
QUIC also based on UDP.
Since UDP is unreliable, QUIC can build it's own flow-control/reliability base on UDP.
QUIC also uses TLS 1.3 to protect data and transport layer
(i.e protocol headers)
Drawbacks:
Since QUIC is deployed in user space, performance is a big issue(for now).
No DMA for NIC like TCP and other optimization tricks done for TCP.
Reference:
QUIC:
https://http3-explained.haxx.se/en/
https://www.fastly.com/blog/why-fastly-loves-quic-http3
QUIC Downsides discussion:
https://news.ycombinator.com/item?id=19461777
Kernel TLS:
https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/
TCP LSO:
https://en.wikipedia.org/wiki/Large_send_offload
HTTP Head-of-line blocking:
https://en.wikipedia.org/wiki/Head-of-line_blocking
HTTP pipelining:
https://en.wikipedia.org/wiki/HTTP_pipelining
HTTP/2 multiplexing:
https://stackoverflow.com/a/36519379
http://qnimate.com/what-is-multiplexing-in-http2/
TCP has it's own sequence number to construct the packets in order on the receiving side.
Thus, the upper HTTP layer will receive the ordered TCP response thus base on stream ID can it builds up the response/request pair.
When the HTTP/2 TCP connection is established,
the client and server exchange SETTINGS frames first,
(like TCP's MSS setting option during init. SYN handshake, can't be changed once connection is established)
which indicates how many streams can be open at a time(or how many parallel requests), how many bytes server is ready to receive for a stream and for the whole connection, and the rate at which data can be delivered or received i.e., window size.
As you can spot there's a performance issue here.
TCP also times-out if missing a package(receiving side) during transfer which triggers sender side to re-send.
(triple ACK, slow start and fast recovery, sliding window/receiving side and congestion window/sender side)
Like VxLAN, UDP comes to the rescue.
(Since it's unreliable protocol, send and forget)
QUIC also based on UDP.
Since UDP is unreliable, QUIC can build it's own flow-control/reliability base on UDP.
QUIC also uses TLS 1.3 to protect data and transport layer
(i.e protocol headers)
Drawbacks:
Since QUIC is deployed in user space, performance is a big issue(for now).
No DMA for NIC like TCP and other optimization tricks done for TCP.
Reference:
QUIC:
https://http3-explained.haxx.se/en/
https://www.fastly.com/blog/why-fastly-loves-quic-http3
QUIC Downsides discussion:
https://news.ycombinator.com/item?id=19461777
Kernel TLS:
https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/
TCP LSO:
https://en.wikipedia.org/wiki/Large_send_offload
HTTP Head-of-line blocking:
https://en.wikipedia.org/wiki/Head-of-line_blocking
HTTP pipelining:
https://en.wikipedia.org/wiki/HTTP_pipelining
HTTP/2 multiplexing:
https://stackoverflow.com/a/36519379
http://qnimate.com/what-is-multiplexing-in-http2/
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.