When I talk about HTTP, what do I talk about?

When we open a website, we may not notice where the HTTP in front of the website comes from. But it certainly plays an important role in the web. This article elaborates on the evolution of HTTP from 1 to 3, from origin to development.

Said in the previous

This article does not attempt to cover all of HTTP, and in fact it is impossible to cover it in a short space. This article is also not intended to delve into one particular aspect of HTTP, as the Definitive GUIDE to HTTP or the RFC protocol does.

The goal of this article is to help the reader understand the evolution of HTTP and talk about how it has changed.

The origin of the HTTP

HTTP was originally initiated by Tim BernersLee in 1989 at CERN, the European Organization for Nuclear Research. Tim BernersLee has come up with an idea that would allow far-flung researchers to share knowledge. The basic idea is to make the WWW (World Wide Web) accessible to each other by means of HyperText, which is formed by the interrelation of multiple documents. The HyperText Transfer Protocol, or HTTP, for transport was born.

WWW is the name that Web browsers used to use to browse hypertext client applications. It is now used to refer to the collection of these series, also known as Web for short.

HTTP itself is a simple request-response protocol that typically runs on top of TCP. From the whole network model, HTTP is an application layer protocol. In the OSI seven-tier model, HTTP is at the top. It does not involve the transmission of packets, but specifies the communication format between the client and the server. Determines what messages the client may send to the server and what responses it may receive. The headers of the request and response messages are given in ASCII code.

HTTP adopts BS architecture, that is, browser-to-server architecture. The client sends HTTP requests to the server through the browser, and the server responds to the client’s requests after parsing. It is this simple and practical model that makes HTTP a protocol based on TCP/IP quickly popularized.

HTTP / 0.9 to HTTP / 1.1

HTTP did not evolve overnight. HTTP was invented to solve the problem of text transfer. Because the protocol itself is very simple, many application methods are envisaged and put into practice on this basis. HTTP now extends beyond the Web framework and is used in a variety of scenarios.

HTTP / 0.9

The earliest version of the HTTP protocol was HTTP/0.9, released in 1990.

As mentioned earlier, HTTP was invented in 1989. HTTP was not established as a formal standard at the time. HTTP at this point actually stands for HTTP/1.0, so it is called HTTP/0.9. This version has only one command: GET. GET is used to retrieve server resources, such as requesting the index.html file in the server root directory. This version of the protocol states that the server can only respond to strings in HTML format, and cannot respond to other formats. This means that multimedia resources, such as images and videos, cannot be transmitted on HTTP/0.9.

HTTP / 1.0

HTTP was officially published as a standard in May 1996, with the version named HTTP/1.0 and documented in RFC1945 [www.ietf.org/rfc/rfc1945…

HTTP/1.0 release, added POST command and HEAD command, rich browser and server interaction means. This version of the HTTP protocol can send content in any format, including text, images, video, files, and so on, and it laid the foundation for the great development of the Internet.

In addition to the request method and support for sending files, HTTP/1.0 added format changes. In addition to the data section, each communication must include headers (HTTP headers) that describe some metadata. Status codes, multi-character set support, multi-part type, authorization, cache, content encoding, and more have also been added.

HTTP / 1.1

HTTP/1.0 is not perfect either, with the main drawback being that only one request can be sent each time a TCP connection is established. Once the data is sent, the connection is closed, and if additional resources are requested, a new connection must be created. If multiple requests are made, it is bound to cause a significant resource performance drain on the server.

HTTP/1.1, published in January 1997, is the current mainstream HTTP protocol version. The original standard was RFC2068, and the revised version RFC2616 is the current version.

One of the most famous is released in June 1999, RFC 2616 [tools.ietf.org/html/rfc261… a version of the now widely used in the HTTP protocol, HTTP / 1.1.

The biggest change in this release is the addition of persistent connections to the HTTP standard, meaning that TCP connections are not closed by default and can be reused by multiple requests. In addition, HTTP/1.1 has many new methods, such as PUT, PATCH, HEAD, OPTIONS, DELETE. The improved HTTP/1.1 version is still in use today.

This section describes the HTTP protocol

request

The client sends an HTTP request to the server in the following format:

Request line, header, blank line and request data are composed of four parts.

Get request example

GET/HTTP/1.1 2 > Host: www.baidu.com 3 > user-agent: curl/7.52.1 4 > Accept: /

The first part: the request line, which specifies the type of request, the resource to access, and the HTTP version to use.

The second part: the request header, the part immediately after the request line (the first line), describes the additional information to be used by the server

From the second line, the request header, HOST will indicate the destination of the request. User-agent, which can be accessed by both server-side and client-side scripts, is an important basis for browser type detection logic. This information is defined by your browser, sent automatically on every request, etc.

Part 3: Blank lines. Blank lines after the request header are required

There must be empty rows even if the request data in Part 4 is empty.

Part four: Request data, also known as the body, can be added to any other data.

The request data for this example is null.

The response message

Typically, after receiving and processing a request from a client, the server returns an HTTP response message.

The HTTP response also consists of four parts: the status line, the message header, the blank line, and the response body.

example

1 < HTTP/1.1 200 OK 2 < Accept-ranges: bytes 3 < cache-control: private, no-cache, no-store, proxy-revalidate, no-transform 4 < Connection: keep-alive 5 < Content-Length: 2381 6 < Content-Type: text/html 7 < Date: Thu, 11 Jun 2020 16:04:33 GMT 8 < Etag: “588604c8-94d” 9 < Last-Modified: Mon, 23 Jan 2017 13:27:36 GMT 10 < Pragma: no-cache 11 < Server: BFE /1.0.8.18 12 < set-cookie: BDORZ=27315; max-age=86400; domain=.baidu.com; path=/ 13 < 14 15 <meta HTTP-equiv=content-type content=text/html; charset=utf-8><meta HTTP-equiv=X-UA-Compatible content=IE=Edge>… 16

The first part: status line, which consists of HTTP protocol version number, status code, and status message.

The first behavior status line, (HTTP/1.1) indicates HTTP version 1.1, status code 200, and status message (OK)

The second part: the message header, which describes some additional information to be used by the client

The second and third lines act as message headers.

Date: the Date and time when the response is generated. Content-type: Specifies the MIME Type of HTML(text/ HTML). The encoding Type is UTF-8

Part 3: Blank lines. Blank lines after the message header are required

Part four: Response body: the text message returned by the server to the client.

The HTML following the blank line is the response body.

Status code

The status code consists of three digits. The first number defines the categories of the response. There are five categories:

• 1XX: indicates that the request has been received and processing continues

• 2xx: success – The request is successfully received, understood, or accepted

• 3xx: Redirect – Further action must be taken to complete the request

• 4XX: client error – The request has a syntax error or the request cannot be implemented

• 5xx: Server side error – The server failed to fulfill a valid request

Security and HTTPS

HTTP was born to solve the problem of information transmission and sharing, without considering the security problems faced by the rapid development of the Internet.

Generally speaking, HTTP starts the data transfer after the TCP three-way handshake. Because HTTP transmits data in plain text, it does not have any data encryption or identity verification mechanism. At the same time, the lower layer protocol does not guarantee data security and confidentiality. Therefore, during network transmission, any third party of any node can hijack traffic, tamper with data or steal information at will.

HTTP cannot ensure the confidentiality, integrity and authenticity of data, and cannot meet the security requirements of modern Internet applications.

With the development of the Web, the use of HTTP is increasing, and the demand for information security is becoming more and more urgent. SSL (Secure SocketsLayer) comes into being.

When it comes to security requirements, the first thing that comes to mind is to encrypt information. SSL, or Secure Socket Layer, as its name implies, is the secure socket layer provided over TCP. It is located between the application layer and the transport layer. The data at the application layer is not directly transmitted to the transport layer but to the SSL layer. The SSL layer encrypts the data received from the application layer and ensures the security of data transmission on the network by using data encryption, identity authentication and message integrity verification mechanisms. HTTPS refers to Hyper Text Transfer Protocol over SecureSocket Layer.

When it comes to the specific implementation, the industry is usually used in general symmetric encryption and asymmetric encryption. How to encrypt? How do I know if the server has not been tampered with? How do I pass the encryption key? With that in mind, let’s take a look at how HTTPS works.

1. The client initiates an HTTPS request

The user types in an HTTPS url in the browser and connects to port 443 on the server.

2. Configure the server

A server that uses HTTPS must have a digital certificate. You can make the certificate by yourself or apply for it from an organization. The difference is that the certificate issued by yourself must be authenticated by the client before you can access the certificate. Free SSL certificate).

This certificate is a pair of public and private keys, if don’t quite understand, public and private keys can imagine as a key and a locks, but the world only you a man who had the key, you can put the locks to others, other people can use this lock lock important things up, and then sent to you, because only you a man who had the key, So only you can see what’s locked with this lock.

3. Send certificates

The certificate is actually the public key, but contains a lot of information, such as the certificate authority, expiration time and so on.

4. The client parses the certificate

This part of the work is done by TLS on the client side. First, it verifies whether the public key is valid, such as the issuing authority, expiration time, etc. If an exception is found, a warning box will pop up, indicating that there is a problem with the certificate.

If the certificate is fine, then generate a random value and encrypt it with the certificate. As mentioned above, lock the random value so that you can’t see what’s locked unless you have a key.

5. Transmit encrypted information

This part transmits the random value encrypted with the certificate. The purpose is to let the server get this random value, and the communication between the client and the server can be encrypted and decrypted by this random value.

6. Service segment decrypts information

The service side, after using a private key to decrypt the received client coming random value (private key), then the content through the value for symmetric encryption, the so-called symmetric encryption is that information and a private key by some algorithms are mixed together, so unless you know the private key, you can’t get access to content, and just the client and the server knows the private key, so as long as the encryption algorithm is tough enough, If the private key is complex, the data is secure.

7. Transmit encrypted information

This information is encrypted with the private key of the service segment and can be restored on the client.

8. The client decrypts the information

The client decrypts the message sent by the service segment with the previously generated private key, and then obtains the decrypted content. The whole process, even if the third party listens to the data, there is nothing to do.

That’s how HTTPS works. Let’s focus again on the evolution of SSL.

In 1994, Netscape created the original specification of the SSL protocol and gradually released improved versions of the protocol. SSL 2.0 was released in 1995. In 1996, Netscape and Paul Kocher designed and released the SSL 3.0 protocol, which was widely accepted and supported on the Internet. The Internet Engineering Task Force (IETF) took over responsibility for the protocol and renamed it TLS (Transport Layer Security).

We see that the SSL 2.0 specification was released around 1995, while SSL 3.0 was released in November 1996. It is interesting to note that SSL is 3.0 in RFC 6101 [tools.ietf.org/html/rfc610…]. The RFC was released in August 2011. It is located in the historical category, the category is usually considered idea and discarded document, or a decision record when they have a historic agreement (according to the IETF [https://www.ietf.org/about/groups/iesg/statements/]). In this case, it is necessary to have an IETF document describing SSL 3.0, where it can be used as a specification reference.

Let’s look at how SSL inspired the development of TLS. The latter in November 1996 to draft ietf – the TLS protocol – 00 [tools.ietf.org/html/draft-…]. Announce the beginning. It has experienced six draft version, and in early 1999 as the RFC 2246 [https://tools.ietf.org/html/rfc2246] – the TLS 1.0 release.

Between 1995 and 1999, SSL and TLS protocols were used to protect HTTP traffic over the Internet. This works well as a de facto standard. Until January 1998, as I – D draft ietf – TLS HTTPs – 00 [tools.ietf.org/html/draft-…]. The formal standardization process of HTTPS has just begun. This work concluded with the release of TLS over RFC 2616-HTTP in May 2000.

TLS continued to evolve between 2000 and 2007, standardizing as TLS 1.1 and 1.2. Until seven years later, the TLS started the next version, the version in April 2014 was adopted as draft ietf – TLS – tls13-00 [tools.ietf.org/html/draft-… After 28 draft, in August 2018, the complete version 1.3 RFC 8446 [https://tools.ietf.org/html/rfc8446] – TLS.

Improvement and HTTP2

Back to HTTP itself. HTTP/1.1 was good enough for a long time (indeed, it is still the most widely used), but the changing requirements of the Web made it necessary to have a better and more appropriate protocol.

HTTP/1.1 We have been using HTTP/1.x for quite some time since it was released in 1997. But with the development of the Internet for nearly 10 years of explosive, from the original web content is given priority to with the text, to the present to rich media (such as images, audio, video), and the page content is more and more high demand of real-time application (for example, live chat, video), so some characteristics of the agreement at the time, has been gradually cannot meet the needs of modern network.

If you look closely at the resources required to download on the front pages of the most popular websites, there is a very clear trend. In recent years, the amount of data needed to download the homepage of a website is gradually increasing, and has exceeded 2100K. But here’s the thing: the average number of resources per page that need to be downloaded in order to display and render is over 100.

Based on this, Between 2010 and 2015, Google demonstrated an alternative way to exchange data between the client and server by implementing an experimental SPDY protocol. It collects focus issues for developers on both the browser and server side, clarifies increased response volume and solves complex data transfers. The goals set when starting the SPDY project were:

• Page load time (PLT) reduced by 50%.

• There is no need for the site author to change anything.

• Minimize deployment complexity without requiring network infrastructure changes.

• Work with the open source community to develop this new protocol.

• Collect real performance data to verify that the experimental protocol works. In order to achieve the goal of reducing page load times, SPDY introduced a new binary frame data layer to enable multiple requests and responses, prioritize, minimize, and eliminate unnecessary network latency in order to make more efficient use of the underlying TCP connection.

**HTTP/1.1 has two major drawbacks: inadequate security and poor performance. ** Due to the huge historical baggage of HTTP/1.x, protocol modification, compatibility is a primary consideration, otherwise it will destroy the countless existing assets on the Internet.

As shown in the figure above, SPDY sits below HTTP and above TCP and SSL, making it easy to accommodate older VERSIONS of HTTP while using existing SSL functionality.

The SPDY protocol has been used as the basis for HTTP/2 since it was proven to work in Chrome, and major features are inherited in HTTP/2.

Then came 2015 and HTTP/2.0.

Changes to HTTP/2 over HTTP/1.1 do not break the work of existing programs, but new programs can get better speed with new features.

HTTP/2 retains most of the semantics of HTTP/1.1, such as request methods, status codes, and even URIs, consistent with most HTTP header fields. HTTP/2 takes a new approach to encoding and transferring data between client and server.

Let’s look at the specific features of HTTP/2:

• Binary frame splitting layer: a binary frame splitting layer is added between the application layer and the transport layer, so as to break through the performance limitation of HTTP/1.1, improve the transmission performance, and achieve low latency and high throughput without changing HTTP semantics, HTTP methods, status codes, URIs and header fields. At the binary framing layer, HTTP/2.0 splits all transmitted information into smaller messages and frames and encodes them in binary format, where the http1.x header is encapsulated in the Headers frame and our Request body is encapsulated in the Data frame.

• Multiplexing: For HTTP/1.x, even if the long connection is enabled, the request is sent in serial mode. In the case of sufficient bandwidth, the bandwidth utilization is not enough. HTTP/2.0 adopts multiplexing mode, which can send multiple requests in parallel to improve the bandwidth utilization.

• Data flow priority: Since requests can be sent concurrently, what if the browser is waiting for key CSS or JS files to finish rendering the page while the server is focused on sending images? HTTP/2.0 can set priority values for data streams, which determine the different priority policies used by clients and servers to handle different streams.

• Server push: In HTTP/2.0, the server can send content to the client in addition to the request. For example, when a page is being requested, the server will push the related logo, CSS, etc. directly to the client, instead of waiting for the request to be sent, because the server thinks the client will need these things. This is equivalent to gathering all the resources in one HTML document.

• Header compression: The header table is used to track and store previously sent key-value pairs, which are not sent each time the same content is requested and responded to.

• HTTP/2.0 supports plaintext HTTP transport, while SPDY enforces HTTPS.

• HTTP/2.0 headers are compressed using HPACK rather than DEFLATE, which is used by SPDY.

QUIC and HTTP3

Although HTTP/2 improves the performance of web pages, it does not mean that it is perfect, HTTP/3 is to solve some of the problems HTTP/2 has been introduced. Over Time, as more and more traffic moves to mobile phones, the network environment of mobile phones will encounter problems such as high packet loss rate, long Round Trip Time (RTT) and connection migration, which make HTTP/TCP protocol, which is mainly designed for wired networks, encounter difficulties.

We can look at two typical problems.

The first is the cost of shaking hands. HTTP/2 uses TCP for transmission, and TLS for secure transmission if HTTPS is used. TLS also requires a handshake process, which requires two handshake delay processes:

• When establishing a TCP connection, three handshakes are required to confirm the connection with the server, that is, 1.5 RTT is consumed before data is transmitted.

• To establish a connection to TLS, there are two versions of TLS – TLS 1.2 and TLS 1.3. Each version takes a different amount of time to establish a connection, and generally requires 1 or 2 RTTS.

In short, we need to spend 3-4 RTTS before transferring data.

Second, TCP header blocking is not completely resolved. We know that in HTTP/2 multiple requests run through a TCP pipe for multiplexing purposes. However, HTTP/2 does not perform as well as HTTP/ 1.x when packet loss occurs. In order to ensure reliable transmission, TCP has a special mechanism of packet loss and retransmission. Lost packets must wait for retransmission confirmation. When HTTP/2 packet loss occurs, the whole TCP must wait for retransmission, and all requests in the TCP connection will be blocked. In the case of HTTP/1.1, multiple TCP connections can be opened, but only one of them is affected, and the remaining TCP connections can still transmit data.

At this point, it’s easy to think, why not just modify TCP? This is already an impossible task. Because TCP has existed for too long, it has been ubiquitous in various devices, and this protocol is implemented by the operating system, so it is very troublesome to update and does not have display operation.

HTTP/3 is coming on QUIC.

HTTP3 is a QUIC-based protocol, as shown in the figure above. First, QUIC is an open source protocol proposed by Google. It is based on UDP, and its direct competitor is TCP. The performance of QUIC protocol is very good, and even 0-RTT encrypted communication can be achieved in some scenarios.

In Google about QUIC [docs.google.com/document/d/…]. QUIC has the following major advantages over HTTP/2:

• Reduce connection establishment latency

• Improved congestion control

• Multiplexing without head-of-line blocking

• Forward Error Correction (Correcting previous errors)

• Connection migration

Multiplexing to avoid queue head blocking

It’s easy to say, but not so obvious to understand, and to understand exactly what the QUIC protocol does and why it’s necessary, I think it’s best to start with the basics of HTTP/1.0.

Pipiline

According to Google, requesting a web page now involves an average of 80 resources and more than 30 domain names. Consider the most primitive case, which requires a TCP request to be established for each resource requested, which is clearly unacceptable. The HTTP protocol specifies a field Connection, but the default value is close, which means it is not enabled.

HTTP 1.1 as early as 1999 [www.ietf.org/rfc/rfc2616…] The protocol changes the default value of Connection to keep-alive, so that multiple HTTP requests under the same domain name can reuse the same TCP Connection. This practice is called HTTP Pipeline and has the advantage of significantly reducing the number of connections to be established, which is a significant reduction in RTT.

Taking the above data as an example, if 80 resources were to go through HTTP 1.0 once, 80 TCP connections would be established and 80 handshakes, or 80 RTTS. If HTTP 1.1 was used, only 30 TCP connections (i.e., 30 RTTS) needed to be established, a 62.5% improvement in efficiency.

Pipeline solves the problem of WASTED TCP connections, but it still has some disadvantages of its own, namely the problem of queue blocking, which is inevitable for all Pipeline models.

Team head block

To use a simple and intuitive example, assume that loading an HTML requires a total of 10 resource requests, and the total request time is the sum of each resource request time. The most intuitive experience is that the faster the network speed, the shorter the request time. However, if a request for a resource is blocked (for example, SQL statement execution is very slow). But for the client, all subsequent requests are blocked.

Head of line blocking (HOC) refers to the fact that when multiple serial requests are being executed, subsequent requests cannot be executed if the first request is not completed. For example, if the transmission of the fourth resource takes a long time, the subsequent resources have to wait, wasting a lot of time and bandwidth resources are not fully utilized.

Therefore, the HTTP protocol allows clients to make multiple parallel requests, such as up to six concurrent requests on my machine. Concurrent requests are primarily used to solve HOC problems, and when there are three concurrent requests, the situation looks like this:

It can be seen that although the request for the fourth resource is blocked, the other resource requests are not necessarily blocked. In general, the average utilization of the network is improved.

It’s true that supporting concurrent requests is one solution to the HOC problem. However, we need to understand that “concurrent requests do not directly solve the problem of HOC, but minimize the impact of HOC.” For example, in the picture above, the problem of HOC still exists, but it does not waste too much bandwidth.

Some readers may wonder, why not make a few more concurrent HTTP requests? As I said, my computer supports up to six concurrent requests. Google did an experiment, switched from six to ten, and tried to visit more than 3,000 web pages. The average visit time increased by about 5%. This is because the number of domain names involved in a single request is limited, and any number of concurrent HTTP requests will not significantly improve bandwidth utilization, but will consume performance.

The practice of SPDY

Is there a way to solve the queue head jam?

The answer is yes. SPDY uses Multiplexing, which allows multiple HTTP requests to share the same TCP connection. Let’s assume that each resource is delivered in multiple packets. In HTTP 1.1, packets from the following resource can only be delivered once all packets from the preceding resource have been delivered (HOC problem). SPDY does not require this, and everyone can be delivered together.

The trade-off is that there is a bit of redundancy in the data, and packets from each resource are tagged to indicate which resource they belong to, so that the client can eventually concatenate them properly. Different markers can be interpreted as different colors in the diagram, and each small square can be interpreted as a package of resources.

TCP window

Do you think SPDY’s multiplexing is good enough to solve the queue blocking problem? Unfortunately, it doesn’t, and I’m pretty sure that HOC is a nightmare as long as you’re using TCP to connect. Let’s take a look at TCP implementation details.

We know that THE TCP protocol guarantees the reachabability of the data, and if packet loss or error occurs, the data will be retransmitted. The problem is that if a packet is lost, subsequent packets have to stop and wait for the packet to be retransmitted, so queue head blocking occurs. The designers of TCP weren’t stupid, either. They invented the concept of sliding Windows:

The advantage is that after the first packet (1-1000) is sent, the second packet can be sent without waiting for an ACK to return. As you can see in the figure, the TCP window size is 4, so after the fourth packet is sent, it will wait until the ACK of the first packet returns. This allows the window to slide back one bit and a fifth packet is sent.

It doesn’t matter if the first, second and third packets are lost. When the sender receives the fourth packet, it can be sure that the first three ACKS are lost rather than the packet. Otherwise, it won’t receive the 4001 ACK, so the sender can boldly slide the window backwards by four digits.

The concept of sliding Windows greatly improves the anti-interference ability of TCP data transmission, generally losing one or two ACKS is not at all concerned. But if the sent packet is lost, or an error, the window can not slide forward, there is a queue blocking phenomenon.

How does QUIC do it

QUIC protocol is based on UDP. We know that UDP protocol is only responsible for sending data, but does not guarantee data reachability. On the one hand, this provides the basis for the multiplexing of QUIC, on the other hand, QUIC protocol itself is required to ensure the data reachability.

SPDY marks individual packets to indicate which HTTP request they belong to. SPDY doesn’t care whether the packets reach the client or not, because data reachability is guaranteed by TCP. Since the client must receive the packet, it is only necessary to sort and concatenate it. QUIC protocol adopts the idea of multiplexing, but at the same time, it has to guarantee the reachability of data.

TCP packet loss retransmission is not a good idea, because once the sequence is established, queue head blocking is inevitable. And after the unordered data is sent to the recipient, how to ensure that the packet is not lost, good packet? This seems like an impossible task, but if you reduce the requirement to: at most, one packet is lost, or one packet is wrong. Things are much simpler. RAID 5 uses xor computing plus data redundancy to ensure Forward Error correction. The QUIC protocol also adopts this idea, which will not be repeated here.

Using the idea of redundant data, QUIC protocol basically avoids retransmitting data. Of course, the QUIC protocol does support retransmission, such as some very important data or the loss of two packages.

Less RTT, faster requests

As mentioned earlier, the basic flow of an HTTPS request is three TCP handshakes plus four SSL/TLS handshakes. So you need three RTTS. But QUIC can even do 0RTT in some scenarios.

So let’s start with what 0RTT is. The so-called 0RTT means that when both parties initiate a communication connection, the first data packet can carry valid service data. As we know, this is completely impossible with traditional TCP unless you enable TCP quick open, which is hard because few people want to mess with the operating system’s network protocol stack for this benefit. If TCP fast open is not enabled, at least one RTT is required before transmitting the first data.

Let’s talk about HTTP2 here. For HTTP2, an additional RTT would have been required to negotiate whether both the client and server support HTTP2, but fortunately it can be merged with SSL handshake requests. This has led to the phenomenon that most major browsers support only HTTPS2 and not HTTP2 alone. Since HTTP2 requires an additional RTT and HTTPS2 requires two additional RTTS, it is cost-effective to add just one RTT for data security.

TCP Quick Open

TCP fast Open means that the client can send the first SYN handshake packet with data, but the TCP implementer is not allowed to upload the packet to the application layer. This is mainly in order to prevent the TCP flood attack [tools.ietf.org/html/rfc498…

If SYN packets can be transmitted to the application layer, existing defenses cannot defend against flooding attacks, and servers run out of memory and CPU.

Of course TCP fast opening is not completely impossible. TFO (TCP Fast Open) was designed as an extension of TCP to not only carry data while sending the SYN, but also ensure security.

TFO designs a Cookie, which is generated by the server during the first handshake, primarily to identify the client and to save configuration information from the last session. Therefore, when the TCP connection is re-established, the client carries SYN + Cookie + request data, and then starts sending data without waiting for ACK to return.

After receiving the SYN, the server verifies whether the Cookie is valid or not. If not, the server reverts to the three-way handshake, as shown below:

Also, for security purposes, the server logs a value PendingFastOpenRequests for each port that indicates how many requests are utilizing TFO and will not accept them if they exceed a preset limit.

Three things can be concluded about TFO optimization:

• The Cookie idea designed by TFO is similar to the Session Ticket in SSL handshake recovery. In both cases, the server generates a Cookie and sends it to the client to save, thus avoiding subsequent handshakes and facilitating quick recovery.

• TFO will never be triggered by the first request because the server will return the Cookie along with the ACK upon receiving the SYN request. This Cookie can only be used for TFO if the client reconnects later

• TFO does not consider filtering repeated requests at the TCP layer, as previous similar proposals to do filtering were rejected because they could not be secured. So TFO just avoids flooding (like backlog), but it is still possible to duplicate the data that the client receives along with SYN packets. However, only SYN data duplication is possible, so TFO does not handle this situation and requires the server program to resolve it itself. This means not only operating system support, but also applications (such as MySQL) that support TFO.

TFO enables TCP to become 0-RTT. The core idea is similar to Session Ticket: The context of the current Session is cached on the client. If you need to resume the conversation later, you just send the cache to the server for validation instead of spending an RTT waiting.

Combining TFO with Session Ticket technology, a request that would otherwise take three RTTS to complete can be optimized to one RTT. Using the QUIC protocol, we can even go one step further and send the Session Ticket in TFO as well, thus achieving 0-RTT conversation recovery.

What did QUIC do

Let’s see what QUIC does.

First of all, 0-RTT is impossible, even for QUIC, if the two parties using QUIC to encrypt communication have never communicated before.

QUIC handshake requires a data exchange, and 0-RTT delay can complete the key negotiation during the handshake. Compared with TLS, QUIC handshake is 5 times more efficient and has higher security. During the handshake, the Diffie-Hellman algorithm is used to negotiate the initial key. The initial key depends on a set of configuration parameters stored on the server, which are periodically updated. After the initial key negotiation succeeds, the server provides a temporary random number for both parties to generate a session key based on this number.

The specific handshake process is as follows:

(1) The client determines whether all configuration parameters of the server are available locally. If so, go to (5) directly; otherwise, continue

(2) The client sends an Inchoate Client Hello (CHLO) message to the server, requesting the server to transmit configuration parameters

The server receives the REJECTION (REJ) message after receiving CHLO, which contains part of the configuration parameters of the server

(4) The client receives REJ, extracts and stores server configuration parameters, and hops back to (1)

(5) The client sends a full Client Hello message to the server to start the formal handshake. The message includes the public number selected by the client. In this case, the client can calculate the initial key based on the obtained server configuration parameters and the selected public number.

(6) The server receives the full client Hello and replies to REJ if it disagrees with the connection, the same as (3); If the connection is agreed, the initial key is calculated based on the client’s public number and a Server Hello (SHLO) message is returned, which is encrypted with the initial key and contains a temporary public number selected by the server.

(7) If the client receives a reply from the server, the case is the same as (4); In the case of SHLO, an attempt is made to decrypt with the initial key to extract the temporary public number

(8) According to the temporary public number and the initial key, the client and server deduce the session key based on SHA-256 algorithm respectively

(9) Both parties use the session key to communicate. The initial key is useless now, and the QUIC handshake process is completed. The process of updating the session key is similar to the previous process, except that some fields in the packet are slightly different.

Write in the last

I think of a famous saying: there is no problem in the computer field that can’t be solved by adding another layer. If there is, add another layer. Network model is originally layer upon layer of accumulation, to the Web can quickly and vividly show to people with rich content. As HTTP evolves, we can see that several layers have been added in between. I don’t know what will happen in the future?

You’ll notice that I use the word evolution more than once. Yes, it comes from Darwin’s theory of evolution. In my opinion, the evolution theory of “natural selection, survival of the fittest” is very similar to the technological change in the field of computer, except here, it is not natural selection, but human selection. It’s up to the market and the users to choose. I don’t know how we, as selectors, will dominate the trend of technology.

Recommended reading

Brief analysis of QUIC/HTTP3 protocol

Talk about Websockets and HTTP