Features of each protocol

HTTP/1.0 – Stateless connectionless application layer protocol

  • Stateless: The server does not track the requested status
  • No connection: The browser establishes a TCP connection for each request

HTTP/1.0 specifies that the browser and server maintain a transient connection. Each request from the browser requires a TCP connection with the server. The server disconnects the TCP connection immediately after processing (no connection). The server does not track each client nor record past requests (stateless).

The problem caused by statelessness can be solved by using the cookie/session mechanism for identity authentication and status recording.

However, the connectionless nature causes the following performance defects:

  1. Unable to reuse connection. Each time a request is sent, a TCP connection needs to be made, and the TCP connection release process is time-consuming. This connectionless nature leads to very low network utilization.
  2. Head of line blocking. Because HTTP/1.0 states that the next request must be sent before the previous request response arrives. If a request response never arrives, the next request is not sent, and the one that causes the block.

To solve these problems, HTTP/1.1 came along.

HTTP / 1.1

  • Long connection. HTTP/1.1 adds a Connection field, via SettingsKeep-alive(The default value is set.) The TCP connection can be kept open continuously, avoiding the repeated establishment and release of TCP connections for each client and server request, improving network utilization. If the client wants to close the HTTP connection, it can be carried in the request headerConnection:falseTo tell the server to close the request
  • Support request pipelining. Long connections based on HTTP/1.1 make request pipelining possible. Pipelining enables requests to be transmitted “in parallel”. For example, if the body of the response is an HTML page with many IMGs in it, keep-alive will be useful for sending multiple requests “in parallel”. (Note that “parallel” is not really a parallel transport, as explained below.)

Note that the server must send back the results in the order in which the client requests them so that the client can distinguish between the responses to each request.

That is, HTTP pipelining allows us to move the FIFO queue from the client side (request queue) to the server side (response queue).

As shown in the figure, the client sends two requests at the same time to get THE HTML and CSS, respectively. If the server’s CSS resources are ready first, the server will send the HTML first and then the CSS.

In other words, the CSS response can’t begin transferring until the HTML response is fully transferred. That is, two parallel responses are not allowed at the same time.

As you can see, HTTP/1.1 still does not solve the problem of head of line blocking. There are also various problems with pipelining, so many browsers either don’t support it at all or simply turn it off by default, and the conditions are very strict… And it doesn’t really seem to be of any use.

What about the parallel requests we see on the Google console?

As shown in the figure, the green portion represents a waiting time for the request to be initiated and the server to respond, while the blue portion represents the download time of the resource. In theory, an HTTP response should start when the previous resource has been downloaded before the next resource can be downloaded. Here, however, parallel downloads of response resources occur. Why is that?

Although HTTP/1.1 supports pipelining, the server must also send back responses one by one, which is a major drawback. In fact, browser vendors today take a different approach and allow us to open multiple TCP sessions. In other words, the parallelism we see above is actually HTTP requests and responses over different TCP connections. This is the familiar browser limit for loading 6 to 8 resources in the same domain in parallel. And this is true parallelism!

In addition, HTTP/1.1 added caching, new fields such as cache-control, support for breakpoint transmission, and the Host field (which enables a server to create multiple Web sites).

HTTP / 2.0

To understand a few concepts:

  • Frame: The smallest unit of HTTP/2 data communication message: refers to the logical HTTP message in HTTP/2. Such as request and response, messages consist of one or more frames.
  • Flow: A virtual channel that exists in a connection. Streams can carry two-way messages, and each stream has a unique integer ID.
  • Message: A complete sequence of data frames corresponding to a logical message.

1. Binary frame division

HTTP/2 transmits data in binary format rather than HTTP/1.x’s text format, and binary protocols parse more efficiently. HTTP / 1 request and response packets consist of the start line, header, and (optional) entity body, which are separated by text newlines. HTTP/2 splits the request and response data into smaller frames, and they are binary encoded.

2. Multiplexing

  • All communication under the domain name is done in a single connection.
  • A single connection can host any number of two-way data streams.
  • The data stream is sent as a message, which in turn consists of one or more frames that can be sent out of order because they can be reassembled according to the stream identifier at the head of the frame

This feature greatly improves performance:

  • A domain name requires only one TCP connection, eliminating the delay and memory consumption caused by multiple TCP connections.
  • Requests and responses can be interleaved in parallel on a single connection without interference.
  • In HTTP/2, each request can have a priority value of 31 bits. 0 indicates the highest priority. A higher value indicates a lower priority. With this priority value, clients and servers can take different policies when dealing with different streams to optimally send streams, messages, and frames.

As you can see, HTTP/2.0 implements true parallel transport, with the ability to make any number of HTTP requests over a SINGLE TCP. And this powerful function is based on the “binary frame” feature.

3. Server push

The server can actively push other resources while sending the PAGE HTML, rather than waiting for the browser to parse to the appropriate location, initiate a request and then respond. For example, the server can actively push JS and CSS files to the client without having to send these requests while the client parses the HTML.

The server can actively push, the client also has the right to choose whether to receive. If the server pushes a resource that has already been cached by the browser, the browser can reject it by sending RST_STREAM. Active push also complies with the same origin policy. The server does not randomly push third-party resources to the client.

4. Head compression

In HTTP/1.x, header metadata is sent in plain text, typically adding 500 to 800 bytes to the load per request.

Take cookies, for example. By default, the browser will attach cookies to the header and send them to the server on every request. (Because cookies are large and repeatedly sent each time, they generally do not store information and are only used for status recording and identity authentication)

HTTP/2.0 uses encoder to reduce the size of headers that need to be transmitted, and the communication parties cache a header fields table, which not only avoids repeated transmission of headers, but also reduces the size of headers that need to be transmitted. Efficient compression algorithms can greatly compress the header, reducing the number of packets sent and thus reducing latency.

Differences between protocols

X keep-alive differs from HTTP/2 multiplexing

  • HTTP/1.x is text-based and can only be passed as a whole; HTTP/2 is binary stream-based and can be broken down into separate frames that are sent interleaved
  • HTTP/1.x keep-aliveThe response must be returned in the order the request was sent; HTTP/2 multiplexing does not respond sequentially
  • HTTP/1.x keep-aliveTo solve queue header congestion, resources on the same page are distributed to different domain names and multiple TCP connections are enabled. All communication between HTTP/2 and the domain name is done on a single connection
  • HTTP/1.x keep-aliveA single TCP connection can process only one request at a time (the life cycles of two requests cannot overlap). HTTP/2 A single TCP can send multiple requests and responses at the same time

Supplement knowledge

1. The cookie and session

1.1 What is Cookie

HTTP is a stateless protocol (for the transaction without memory, each time the client and the server session is complete, the server will not save any session information) : each request is completely independent, the server can’t confirm the identity of visitors to the current information, unable to distinguish between the last request of the sender and the sender is not the same person at this time. So in order for the server and browser to do session tracking (to know who is visiting me), they must actively maintain a state that tells the server whether the previous two requests came from the same browser.

This state needs to be implemented through cookies or sessions.

Cookie stored on the client: A cookie is a small piece of data that the server sends to the user’s browser and keeps locally. It is carried and sent to the server the next time the browser makes a request to the same server.

Cookies are not cross-domain: each cookie is bound to a single domain name and cannot be used under other domain names. First-level domain names and second-level domain names are allowed to be shared (depending on domain).

Cookie important attributes:

attribute instructions
name=value Key-value pair, set the name of the Cookie and its corresponding value, must beString type– If the value is a Unicode character, the character encoding is required. – If the value is binary data, BASE64 encoding is required.
domain Specifies the domain name to which the cookie belongs. Default is the current domain name
path Specify the cookieWhich path (route) takes effectThe default is ‘/’. If the cookie is set to/ABC, only routes under/ABC can access the cookie, for example, / ABC /read.
maxAge Cookie validity time, in seconds. If it is an integer, the cookie expires after maxAge seconds. If it is negative, the cookie is a temporary cookie and will not be saved in any form when the browser is closed. If the value is 0, the cookie is deleted. The default value is -1.Better than Expires.
expires Expiration time, at which point the cookie will expire. Generally, the browser’s cookie is saved by default. When closing the browser to end the session, the cookie will be deleted
secure Whether the cookie is transmitted only using a secure protocol. Security protocols include HTTPS and SSL. Data is encrypted before being transmitted over the network. The default is false. When secure is true, cookies are not valid for HTTP, but for HTTPS.
httpOnly If the httpOnly attribute is set for a cookie, the cookie information cannot be read through THE JS script, but the cookie can be manually modified through the Application, so it can only prevent XSS attacks to a certain extent, not absolute security

1.2 What is Session

  • Session is another mechanism for recording the state of the session between the server and client
  • The session is implemented based on cookies. The session is stored on the server, and the sessionId is stored in the cookie of the client

  • Session authentication process:
    • When a user requests the server for the first time, the server creates a Session based on the information submitted by the user
    • The Session id is returned to the browser when the request is returned
    • After receiving the SessionID information from the server, the browser stores the information in the Cookie, and the Cookie records the domain name of the SessionID
    • When the user accesses the server for the second time, the request will automatically determine whether there is Cookie information under the domain name. If there is Cookie information, the server will automatically send the Cookie information to the server, and the server will obtain the SessionID from the Cookie. If the Session id is not found, the user is not logged in or the login is invalid. If the Session id is found, the user is logged in and you can perform the following operations.

According to the above process, SessionID is a bridge between Cookie and Session, and most systems also verify user login status based on this principle.

1.3 Differences between Cookies and Sessions

  • Security: The Session is more secure than the Cookie. The Session is stored on the server and the Cookie is stored on the client.
  • The value types are different: Cookies only support string data. If you want to set other types of data, you need to convert them into strings. Session can store any data type.
  • Different validity periods: Cookies can be set to remain for a long time. For example, the default login function that we often use, the Session usually expires for a short time, and the client is closed (by default) or the Session times out (no operation is performed for 30 minutes).
  • Different storage sizes: The data stored by a single Cookie cannot exceed 4K, and the data stored by a Session is much higher than that stored by cookies. However, if there are too many visits, too many server resources will be occupied.

2. A TCP connection

2.1 Three handshakes

Establish a TCP connection with a three-way Handshake. When a TCP connection is established, the client and server need to send three packets to confirm the connection. The whole process is shown in the figure below:

  1. First handshake: Client will flagSYN=1, randomly generating a valueseq=JAnd sends the packet to the Server. The Client accesses the packetSYN_SENTStatus waiting for Server confirmation.
  2. Second handshake: The Server receives the packet by the flag bitSYN=1When the Client requests to establish a connection, the Server flags the bitSYNandACKI’m going to set them all to 1,ack=J+1, randomly generating a valueseq=KAnd sends the packet to the Client to confirm the connection request, and the Server entersSYN_RCVDState.
  3. Third handshake: The Client checks the handshake after receiving the confirmationackIs it J plus one,ACKWhether it is 1, and flags the bit if it is correctACKSet to 1.ack=K+1And sends the packet to the Server. The Server checks whether ack is K+1 and ACK is 1. If yes, the connection is established successfully and the Client and Server enterESTABLISHEDAfter the three-way handshake is complete, data can be transferred between the Client and Server.

In a nutshell, it is

  1. When establishing a connection, the client sends a SYN packet (SYN= I) to the server and entersSYN-SENDStatus waiting for server confirmation
  2. After receiving a SYN packet, the server acknowledges the SYN (ACK = I +1) from the client and sends a SYN (ACK = K) packet. In this case, the server accesses the serverSYN-RECVstate
  3. After receiving the SYN+ACK packet from the server, the client sends an ACK message (ACK = K +1) to the server. After the packet is sent, the client and the server accessESTABLISHEDState, completes the three-way handshake, and the client and server begin transmitting data.

2.2 Wave four times

The so-called four-way Wavehand refers to the termination of A TCP connection. When a TCP connection is disconnected, the client and server need to send a total of Four packets to confirm the connection. The whole process is shown in the figure below:

A TCP connection is full-duplex. Therefore, each direction must be closed separately. After completing the data transmission task, one party sends a FIN to terminate the connection in this direction. However, data can still be sent on this TCP connection until a FIN is also sent in that direction. The party that closes first performs an active shutdown, while the other party performs a passive shutdown, as depicted in the figure above.

  1. First wave: Client sends oneFINIs used to disable data transfer from Client to Server, and the Client entersFIN_WAIT_1State.
  2. Second wave: Server receivedFINAfter that, send oneACKTo the Client, confirm that the sequence number is +1 (the same as that for SYN, one FIN occupies one sequence number), and the Server entersCLOSE_WAITState.
  3. Third wave: Server sends oneFINIs used to disable data transfer from the Server to the Client, and the Server entersLAST_ACKState.
  4. Fourth wave: The Client receives the messageFINThen, the Client enters the TIME_WAIT state and sends an ACK to the Server to confirm that the sequence number is received +1CLOSEDState, complete four waves.

2.3 Why is it three handshakes to establish a connection and four waves to close a connection?

This is because in LISTEN state, the server receives a SYN packet for establishing a connection and sends the ACK and SYN packets to the client. And close the connection, when I received the other side of the FIN message just said to each other can no longer send data but also receives the data, the board may not all data are sent to each other, so their can immediately close, also can send some data to each other, then send the FIN message now agreed to close the connection to the other side, therefore, Your ACK and FIN are usually sent separately.

3. Keep-Alive

HTTP/1.0 introduced keep-alive long connections, which were disabled by default in HTTP/1.0. Connection: keep-alive; HTTP/1.1 is enabled by default, whether Connection: keep-alive is added or not.

Keep-alive disperses resources on the same page to different domain names to solve queue header blocking and enables multiple TCP connections.

The so-called long connection refers to the process of establishing a TCP connection through AN HTTP request. The request ends and the TCP connection continues for a period of time (timeout). During this period, the same client sends requests to the server to reuse the TCP connection and reset the timeout time counter. TCP can be reused for the rest of the timeout period. This eliminates the cost of repeatedly creating and destroying TCP connections.

Does TCP disconnect immediately after the timeout? If no data is received from the client within two hours, the server sends a probe segment, then every 75 seconds. If there is no response from the client after 10 probe segments are sent, the server assumes that the client is faulty and closes the connection. — From Xie Xiren, Computer Networks

4. HTTP cache processing

4.1 Browser Cache

Analysis of cache process:

From the figure above, we can know:

  • Each time the browser initiates a request, it first looks up the result of the request and the cache identifier in the browser cache
  • Each time the browser gets the result of the returned request from the server, it stores the result and the cache id in the browser cache

Browser caching is divided into two phases: local caching (strong caching) and negotiated caching (revalidation).

Where, the common HTTP cache header field:

Strong caching: The process of looking up the result of a request to the browser cache and deciding whether to use the cached result based on the result’s caching rules

  • Expires (HTTP / 1.0)
  • Cache-control HTTP / 1.1) (

Negotiation cache: After the strong cache is invalid, the browser sends a request to the server with the cache id. The server decides whether to use the cache based on the cache ID

  • Last-modified and if-Modified-since (HTTP/1.0)
  • ETag and if-none-match (HTTP/1.1)

4.2 Strong Cache (Cache Control)

Strong caching indicates whether the cache is used during the cache (whether the cache is valid) and whether the HTTP request needs to be re-sent

The fields that Control strong caching are Expires and cache-control, where cache-control takes precedence over Expires

The Expires (HTTP/1.0) value is the expiration time for the server to return the request result cache:

Expires: Wed, 22 Oct 2018 08:41:00 GMT

Indicates that the resource will expire after Wed, 22 Oct 2018 08:41:00 GMT and needs to be requested again.

In addition, Expires is limited to the client time, and changing the client time can invalidate the cache.

So cache-control is now in HTTP/1.1

Cache-control HTTP / 1.1) (

Cache-control: max-age=30

The value of this attribute indicates that the resource will expire after 30 seconds and needs to be requested again. This means that if the request is made again within 30 seconds, the cache will be used directly. Strong caching takes effect.

It compares to Expires:

  • The Expires time value in an HTTP response packet is an absolute value
  • Cache-control in the HTTP response packet is max-age=600, which is a relative value (Expires is limited by the client time).

In addition to max-age, it has the following values:

Note the following no-cache: the resource is still cached, and the cache must be verified by the server before it can be used

Is max-age=0 equivalent to no-cache?

In the literal sense of the specification, max-age expiration means revalidation SHOULD be done, and no-cache means revalidation MUST be done. But the reality is that, depending on the browser implementation, for the most part the two behave the same. (If max-age=0, must-revalidate is equivalent to no-cache.)

Since HTTP/1.1, Expires has been replaced by cache-control. Cache-control is a relative time. Even if the client time changes, the relative time does not change. This keeps the server and client time consistent. Cache-control is also very configurable.

Cache-control takes precedence over Expires, and in order to be compatible with HTTP/1.0 and HTTP/1.1, we set both fields in the actual project.

4.3 Negotiating Cache (Cache Verification)

If the cache expires:

  • No cache-control or Expires
  • Cache-control and Expires
  • Set up the no – cache

Need to initiate a request to verify that the server resource has been updated:

  • There are updates, return 200, update the cache
  • 304 is returned. The browser cache validity period is updated

Last-modified and if-Modified-since (HTTP/1.0)

  • Last-modified (response header)
  • If-modified-since (request header)

Last-modified indicates the Last Modified date of the local file. If-modified-since will send the last-Modified value to the server and ask the server If the resource has been updated Since this date. If it has been updated, the new resource will be sent back, otherwise the 304 status code will be returned.

However, this approach has some disadvantages, such as:

  • For load-balanced servers, last-Modified generation may vary from server to server
  • The GMT format has minimum units, for example, and will not be recognized if it changes within a second

ETag and if-none-match (HTTP/1.1)

To solve the above problem, HTTP/1.1 adds this set of tags

  • ETag (response header)
  • If-none-match (request header)

An ETag is similar to a file fingerprint, which is a unique identification sequence of a file. When a resource changes, the ETag will be generated again. If-none-match will send the current ETag to the server and ask whether the ETag of the resource has changed. And the ETag priority is higher than last-Modified

Using ETag allows you to accurately identify resource changes, even when updates are made within seconds, allowing the browser to sense and use the cache more effectively

ETag strength and weakness

The ETag mechanism supports both strong and weak checks. They are distinguished by the presence of “W/” at the beginning of the ETag identifier, as in:

“123456789” – a strong ETag validator W/”123456789″ – a weak ETag validator

A strong ETag requires that resources match exactly at the byte level. A weak ETag has a “W/” tag in front of the value. It only requires that resources remain semantically unchanged, but may have some internal changes (such as reordering tags in HTML, or adding a few extra Spaces).

4.4 than response

The server tells the proxy server that it needs to cache two versions of this resource by specifying Vary: accept-encoding:

  • The compression
  • uncompressed

In this way, the old browser and the new browser, through the proxy, get the uncompressed and compressed versions of the resource respectively, avoiding the embarrassment of both getting the same resource.

Vary: Accept-Encoding, User-Agent

As set up above, the proxy server will cache resources based on compression and browser type. This way, the same URL can return different cached content for PC and Mobile.

Refer to the article

– Zero – Comparison of major features of HTTP1.0 HTTP1.1 HTTP2.0

Read HTTP/2 features

SisterAn – making/issue

SisterAn – cookie_session