Tag: IETF

HTTP/3

· Leave a comment ·

The HTTP-over-QUIC experimental protocol will be renamed to HTTP/3 and is expected to become the third official version of the HTTP protocol, officials at the Internet Engineering Task Force (IETF) have revealed.

This will become the second Google-developed experimental technology to become an official HTTP protocol upgrade after Google’s SPDY technology became the base of HTTP/2.

HTTP-over-QUIC is a rewrite of the HTTP protocol that uses Google’s QUIC instead of TCP (Transmission Control Protocol) as its base technology.

QUIC

QUIC stands for “Quick UDP Internet Connections” and is, itself, Google’s attempt at rewriting the TCP protocol as an improved technology that combines HTTP/2, TCP, UDP, and TLS (for encryption), among many other things.

In a mailing list discussion last month, Mark Nottingham, Chair of the IETF HTTP and QUIC Working Group, made the official request to rename HTTP-over-QUIC as HTTP/3, and pass it’s a development from the QUIC Working Group to the HTTP Working Group.

In the subsequent discussions that followed and stretched over several days, Nottingham’s proposal was accepted by fellow IETF members, who gave their official seal of approval that HTTP-over-QUIC becomes HTTP/3, the next major iteration of the HTTP protocol, the technology that underpins today’s World Wide Web.

According to web statistics portal W3Techs, as of November 2018, 31.2 percent of the top 10 million websites support HTTP/2, while only 1.2 percent support QUIC.

What is QUIC?

QUIC (Quick UDP Internet Connections) is a new transport protocol for the internet, developed by Google.

QUIC solves a number of transport-layer and application-layer problems experienced by modern web applications while requiring little or no change from application writers. QUIC is very similar to TCP+TLS+HTTP2 but implemented on top of UDP. Having QUIC as a self-contained protocol allows innovations which aren’t possible with existing protocols as they are hampered by legacy clients and middleboxes.

Key advantages of QUIC over TCP+TLS+HTTP2 include:

  • Connection establishment latency
  • Improved congestion control
  • Multiplexing without head-of-line blocking
  • Forward error correction
  • Connection migration

Connection Establishment

QUIC handshakes frequently require zero roundtrips before sending a payload, as compared to 1-3 roundtrips for TCP+TLS.

The first time a QUIC client connects to a server, the client must perform a 1-roundtrip handshake in order to acquire the necessary information to complete the handshake. The client sends an inchoate (empty) client hello (CHLO), the server sends a rejection (REJ) with the information the client needs to make forward progress, including the source address token and the server’s certificates. The next time the client sends a CHLO, it can use the cached credentials from the previous connection to immediately send encrypted requests to the server.

Capture3

Congestion Control

QUIC has pluggable congestion control and provides richer information to the congestion control algorithm than TCP. Currently, Google’s implementation of QUIC uses a reimplementation of TCP Cubic and is experimenting with alternative approaches.

One example of richer information is that each packet, both original and retransmitted, carries a new sequence number. This allows a QUIC sender to distinguish ACKs for retransmissions from ACKs for originals and avoids TCP’s retransmission ambiguity problem. QUIC ACKs also explicitly carry the delay between the receipt of a packet and its acknowledgment being sent, and together with the monotonically-increasing sequence numbers.  This allows for precise roundtrip-time calculation.

Finally, QUIC’s ACK frames support up to 256 NACK ranges, so QUIC is more resilient to reordering than TCP (with SACK), as well as able to keep more bytes on the wire when there is reordering or loss. Both client and server have a more accurate picture of which packets the peer has received.

Multiplexing

One of the larger issues with HTTP2 on top of TCP is the issue of head-of-line blocking. The application sees a TCP connection as a stream of bytes. When a TCP packet is lost, no streams on that HTTP2 connection can make forward progress until the packet is retransmitted and received by the far side – not even when the packets with data for these streams have arrived and are waiting in a buffer.

Because QUIC is designed from the ground up for multiplexed operation, lost packets carrying data for an individual stream generally only impact that specific stream. Each stream frame can be immediately dispatched to that stream on arrival, so streams without loss can continue to be reassembled and make forward progress in the application.

Forward Error Correction

In order to recover from lost packets without waiting for a retransmission, QUIC can complement a group of packets with an FEC packet. Much like RAID-4, the FEC packet contains parity of the packets in the FEC group. If one of the packets in the group is lost, the contents of that packet can be recovered from the FEC packet and the remaining packets in the group. The sender may decide whether to send FEC packets to optimize specific scenarios (e.g., beginning and end of a request).

Connection Migration

QUIC connections are identified by a 64-bit connection ID, randomly generated by the client. In contrast, TCP connections are identified by a 4-tuple of source address, source port, destination address, and destination port. This means that if a client changes IP addresses (for example, by moving out of Wi-Fi range and switching over to cellular) or ports (if a NAT box loses and rebinds the port association), any active TCP connections are no longer valid. When a QUIC client changes IP addresses, it can continue to use the old connection ID from the new IP address without interrupting any in-flight requests.

For a detailed explanation, read the book: HTTP/3 Explained by Daniel Stenberg

HTTP/3 explained is a free and open booklet describing the HTTP/3 and QUIC protocols.

http3-explained-fakebook800

Watch this Google Developers QUIC tech Talk:

Do drop a comment below.

Source: zdnet, Google, Chromium Blog, Chromium

 

HTTP/2

· Leave a comment ·

HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google.

HTTP/2 was developed by the Hypertext Transfer Protocol working group httpbis (where bis means “second”) of the Internet Engineering Task Force (IETF).

HTTP Timeline pic
                                                                                                                                                   ~ HTTP Timeline

What is a Protocol?

A protocol is a set of rules that govern the data communication mechanisms between clients (for example web browsers used by internet users to request information) and servers (the machines containing the requested information).

Protocols usually consist of three main parts: Header, Payload, and Footer.

The Header placed before the Payload contains information such as source and destination address as well as other details (such as size and type) regarding the Payload.

The Payload is the actual information transmitted using the protocol.

The Footer follows the Payload and works as a control field to route client-server requests to the intended recipients along with the Header to ensure the Payload data is transmitted free of errors.

 

Protocol
                                                                                                                                                     ~ Mail HTTP/2

The system is similar to the postal mail service. The letter (Payload) is inserted into an envelope (Header) with destination address written on it and sealed with glue and postage stamp (Footer) before it is dispatched.

What is SPDY?

SPDY (pronounced SPeeDY) is a networking protocol developed by Google with the purpose of speeding up the delivery of web content. It does this by modifying HTTP traffic which in turn reduces web page latency and improves web security.

HTTP, while powerful in its day, cannot keep up with the demands of today’s digital world, which is the reason SPDY was introduced to help meet those demands.

What is HTTP/2?

HTTP/2 is the second major version update to the HTTP protocol since HTTP1.1 which was released more than 15 years ago. The HTTP/2 protocol was developed due to the ever-evolving digital world and the need to load more resource intensive web pages.

SPDY was also implemented to help reduce web page latency users experience when using HTTP1.1. HTTP/2 is based off SPDY, however, contains key improvements that have led to the deprecation of SPDY in February 2015.

How does HTTP/2 work?

Whenever you click on a link to visit a site a request is made to the server. The server answers with a status message (header) and a file list for that website. After viewing that list, the browser asks for the files one at a time. The difference between HTTP 1.1 and HTTP/2 lies in what happens next.

Say you want a new LEGO set. First, you go to the store to buy your LEGO. When you get home, you open the box and look at the instructions, which tell you what you have to do: one brick at a time. So for every brick, you have to look at the instructions to see which brick to use next. The same for the next brick, and so on. This back-and-forth keeps happening until you have finished the entire LEGO set. If your set has 3,300 bricks, that’ll take quite a while. This is HTTP1.1.

With HTTP/2 this change. You go to the store to pick up your box. Open it, find the instructions and you can ask for all the bricks used on one section of the LEGO set. You can keep asking the instructions for more bricks, without having to look at the manual. “These bricks go together, so here they are.” If you want it really quickly, you could even get all the bricks at once so you can build the set in an instant.

Picture7

Differences from HTTP1.1

Similar to SPDY, using HTTP/2 does not require any changes to how web applications currently work, however, applications are able to take advantage of the optimization features to increase page load speed.

Differences between the HTTP1.1. and HTTP/2 protocol includes the following:

  • HTTP/2 is binary, instead of textual
  • It is fully multiplexed, instead of ordered and blocking
  • It can use one connection for parallelism
  • It uses header compression to reduce overhead
  • It allows servers to “push” responses proactively into client caches instead of waiting for a new request for each resource.

Is it HTTP/2.0 or HTTP/2?

The Working Group decided to drop the minor version (“.0”) because it has caused a lot of confusion in HTTP/1.x.

In other words, the HTTP version only indicates wire compatibility, not feature sets or “marketing.”

Similarities with HTTP1.x and SPDY

HTTP1.x SPDY HTTP2
SSL not required but recommended. SSL required. SSL not required but recommended.
Slow encryption. Fast encryption. Even faster encryption.
One client-server request per TCP connection. Multiple client-server requests per TCP connection. Occurs on a single host at a time. Multi-host multiplexing. Occurs on multiple hosts at a single instant.
No header compression. Header compression introduced. Header compression using improved algorithms that improve performance as well as security.
No stream prioritization. Stream prioritization introduced. Improved stream prioritization mechanisms used.

Conclusion

HTTP/2 is without a doubt the direction the web is moving towards in terms of the networking protocol that is able to handle the resource needs of today’s websites. While SPDY was a great step forward in improving HTTP1.1, HTTP/2 has since further improved the HTTP protocol that has served the web for many years.

According to W3Techs, as of November 2018, 31% of the top 10 million websites supported HTTP/2.

Source: kinsta, wikipedia, yoast, github, keycdn,