Coffee Break

Why Pinterest Moved to HTTP/3?

tags:

, ,

categories:

  • About a month ago (Feb 24, 2023), Pinterest published a blog that they moved to HTTP/3
  • Why make the move?
    • HTTP/3 will help in cases of large payload transmissions such as image/video downloading. (No HOL in HTTP/3)
    • Connection Migration across IP address, such as mobile use cases. (No Handshakes in HTTP/3)
    • Congested network or limited bandwidth. (Less RTT in HTTP/3)
  • What is HTTP/3?! It seemed like recently we heard about HTTP2 and the rest of the web has still been questioning to use it or not.
  • Looking at the features of each evolution of HTTP 1.1, 2.0, 3.0, it has always been trying to address latency and performance optimisations in connection handling.
FeaturesHTTP/1.1HTTP/2HTTP/3
Request-response modelClient sends one request, server sends one responseClient sends multiple requests, server responds with multiple responsesClient sends multiple requests, server responds with multiple responses
MultiplexingNo, each request-response pair requires a separate connectionYes, multiple requests and responses can be sent over a single connectionYes, similar to HTTP/2
Server pushNoYes, server can send multiple responses to a single requestYes, similar to HTTP/2
Header compressionNoYes, using HPACKYes, using QPACK
Binary framingNoYesYes
Stream prioritizationNo Yes, clients can assign priority to requestsYes, similar to HTTP/2
Connection re-useYes, but only for a single request-response pair at a timeYes, multiple requests and responses can be sent over a single connectionYes, similar to HTTP/2
Encryption/TLS requirementOptionalRequired, supports TLS 1.2 and 1.3Required, supports TLS 1.3 (via QUIC Protocol)
Protocol overheadHigh due to multiple connections and uncompressed headersReduced due to multiplexing and header compressionFurther reduced due to improvements in transport layer and QPACK compression
HOL blocking problemYes, where slow or blocked requests can hold up subsequent requests on the same connectionYes, where large or slow requests can hold up subsequent requests on the same connection. Resolves HOL over HTTP but not TCP.No, thanks to QUIC’s built-in support for multiplexing and prioritisation. Resolves HOL over HTTP and TCP. It achieves this via UDP.

The defining feature in HTTP 3 is the QUIC protocol which abstracts away some of the TCP responsibilities in the predecessors. This includes connection verification, packet ACK during packet losses, and some security related features.

What is so quick about HTTP/2 (Compared to HTTP/1.1?)

  • In HTTP/1.1, requests and responses are sent over a single connection in a sequential, blocking fashion. This means that each request must be processed and completed before the server can move on to the next request. As a result, if a single request is delayed or lost in transmission, it can cause subsequent requests to be delayed as well, leading to HOL blocking.
  • The trademark feature of HTTP/2 is multiplexing. which allows multiple requests and responses to be sent over a single connection simultaneously. In other words, the client can send multiple requests to the server at the same time, and the server can send multiple responses back to the client at the same time, without having to wait for previous requests or responses to be completed.
  • HTTP/2 also includes a feature called stream prioritization, which allows the client to assign priorities to different streams. This ensures that higher-priority streams are processed and completed before lower-priority streams, even if the lower-priority streams were initiated first. Stream prioritization helps to prevent HOL blocking by ensuring that important requests are processed and completed as quickly as possible.
  • The HOL still exists in the TCP level. If a TCP buffer forms multiple requests/responses, the HTTP level is unaware and need to wait for TCP level to finish collecting the rest of the packets.

What is so QUIC about HTTP/3? (Compared to HTTP2?)

  • Recall that TCP packets has unique sequence numbers and the data must be passed to the receiver in order. HTTP layer has no visibility in TCP retransmissions or TCP buffers and must wait for full sequence before it can access the data. It is possible for the TCP buffer is able to form different request/responses already, and can be delivered to HTTP layer without waiting for the delayed packet.
  • TCP is a highly reliable protocol. It has some behavior of FIFO type of packet transmission behavior. If one of the packet is lost during transmission, the stream will halt until the lost packet is re-transmitted. The slowness comes from the server having to wait/detect that there is a lost packet, retransmit the packet, and receive acknowlegement.
  • TCP also have something called Congestion Control Algorithm, the purpose is to relax the network during low bandwidth and not overwhelm the internet.
    • It does this by having timeouts, exponential backoff, and prioritisation of packets when a packet is continuously unable to be delivered.
  • The QUIC protocol reimplements some behaviours of the TCP protocol, over UDP while taking advantage of the lean features of UDP. It sends “90% of the data” in one go, and eventually the other “10%”.
    • The server will use one connection and create multiple streams. Each streams sends a different type of packet, unordered, unverified via UDP. If one of the packet gets lost, it only affect that particular stream.
    • The QUIC protocol also implements something similar to Congestion Control Algorithm except it understands different streams within a UDP connection.
    • Since this is UDP which is unreliable, unsecure out of the box, QUIC protocol implements security very similar to TLS 1.3 outside of UDP.
  • Another feature that makes QUIC fast is that it reduces round trip times that existed in TCP + TLS. The RTT in TCP TLS requires 3 trips before data begins transmitting while QUIC requires 0-1 trip.

Pinterest Migration

  • It requires both CDN and Client Apps to enable HTTP/3.
    • Certain CDN have different levels of support. Not all CDN has same support. This is an issue for multi CDN networks. Cross CDN networks are challenging.
    • Most browsers have support.
    • Mobile have some level of support but low controllability. It can only be turned on/off on server side, not client side.
  • There also could be compatibility issues. HTTP/3 is considered relatively new and because it encrypts the meta data as well, it can exhibit buggy behaviours during transmissions.
  • Focused on migrating image/video traffic to use HTTP3.
    • 70% of IOS image traffic is on HTTP3 via Cronet
    • Android Video is using HTTP3 via Exoplayer and Cronet
  • Reliability improved significantly when there are huge congestions in the network. But otherwise seems to be minor improvements in for low to medium congested networks. This is probably related to RTTs

Final Thoughts about HTTP/3

  • While the benefit is definitely there, it seems to be more helpful in cases where network is severely congested or wanting to improve the initial secure connection. I think the improvement would be high when moving from HTTP 1.1 to HTTP 3 where the HOL if completely removed.
  • As with HTTP/2, it is going to take some time for the world to begin adopting to use new HTTP versions. The adoption is required at the kernel level, router/dns levels, and client side.
    • Before HTTP 3, majority of the meta data is still available. There are a lot of features already developed with the expectations of being able to see the meta data.
    • It is common for HTTP to be monitored or intercepted. For example firewalls/security. If the meta data is not visible, these traffic might get blocked permanently which makes the migration a breaking change.
    • Server side changes now requires different routing rules. Oddly need to open UDP 443 in addition to TCP 443 rules. Also need to take into account of load balancing rules and connection stickiness since UDP 443 is session-less protocol.
  • I would not migrate to HTTP/3 unless I have good control of server side and client side tech stacks.
  • By default, I would not seriously consider it as a whole until another 2-3 years… There’s been no mention of backend turning on HTTP 3, so seemed like Pinterest approach was at CDN. Since HTTP3 implementation is so different, the technology may not be ready long running stateful connections.

References

buymeacoffee

Buy me a coffee

Leave a comment