Codewords are not easy, and helpful students hope to pay attention to my WeChat public account: Code program life, thank you! The code is self-used and fetched.
一、HTTP 3.0
HTTP3.0, also known as HTTP over QUIC. The core of HTTP3.0 is the QUIC (quick) protocol, a new protocol evolved from SPDY v3 proposed by Google in 2015. The traditional HTTP protocol is based on the transport layer TCP protocol, while QUIC is based on the transport layer UDP. The protocol can be defined as: HTTP3.0 is a safe and reliable HTTP2.0 protocol based on UDP.
The QUIC protocol solves the following problems for the HTTP2.0 protocol based on TCP and TLS.
1.1 Reduce the TCP three-way handshake and TLS handshake time
Whether it is HTTP1.0/1.1 or HTTPS, HTTP2.0, TCP is used for transmission. HTTPS and HTTP2 also need to use the TLS protocol for secure transmission. This causes two handshake delays, and QUIC based on the UDP protocol, because UDP itself has no concept of connection, only one interaction is required when the connection is established, and half of the handshake time. The difference is as follows:
1.2 The head-of-line blocking problem of multiplex packet loss
QUIC retains the characteristics of HTTP2.0 multiplexing. In the previous multiplexing process, there are multiple streams on the same TCP connection. If one of the streams loses packets, the streams before and after the retransmission will be affected. There is no dependency between multiple streams on a connection in QUIC. Therefore, when packet loss occurs, it will only affect the current stream, and the problem of head-of-line blocking is avoided.
1.3 Optimize the retransmission strategy
The previous TCP packet loss retransmission strategy was to mark each packet with a sequence number at the sender. When the receiver receives the packet, it will return an ACK packet with the corresponding number to the sender to inform The sender's packet has indeed been received. When the sender has not received the returned ACK after a certain period of time, it will think that the packet has been lost, and start the retransmission mechanism. Re-transmit the packet with the same number as the original to ensure that there is nothing on the receiving end. Missing packets. Such a mechanism will bring some problems. Assume that the sender sends the same packet twice (initial + retransmission), using the same sequence number: number N. Later, when the sender gets the return ACK of the number N packet, it will not be able to determine that this ACK with the number N is the ACK returned by the receiver after receiving the initial packet. This will increase the time-consuming calculation of subsequent retransmissions. In order to avoid this problem with QUIC, when the sender transmits packets, each initial and retransmitted packet uses a new number, unique packet number. Each number is unique and strictly increases, so that every time an ACK is received , You can determine whether the ACK is from the initial packet or retransmitted packet based on the number.
1.4 Flow control
Through flow control, the amount of data transmitted by the client can be limited. With flow control, the receiving end can only reserve the corresponding size of the receiving buffer, optimizing the space occupied by the memory. But if there is a stream with extremely slow traffic, a single stream may use up all the resources of the receiving end. In order to avoid this potential HOL Blocking, QUIC uses connection flow control and stream flow control flow control to limit the maximum buffer size that a single Stream can occupy.
1.5 Connection migration
The TCP connection is based on a four-tuple (source IP, source port, destination IP, destination port). When switching networks, at least one factor will change, causing the connection to change. When the connection changes, if the original TCP connection is still used, the connection will fail. You have to wait for the original connection to time out and re-establish the connection. So we sometimes find that when switching to a new network, even if the new network is in good condition, But the content still takes a long time to load. If it is implemented well, a new TCP connection is established immediately when a network change is detected. Even so, it still takes several hundred milliseconds to establish a new connection. The connection of QUIC is not affected by the quadruple. When these four elements change, the original connection is still maintained. The QUIC connection does not use a four-tuple as the identification, but uses a 64-bit random number. This random number is called Connection ID, which corresponds to each stream. Even if the IP or port changes, as long as the Connection ID does not change, the connection remains Can be maintained.
2. History of HTTP
2.1 Web ancestor HTTP
The full name of HTTP is: HyperText Transfer Protocol (HyperText Transfer Protocol).
With the birth of computer networks and browsers, HTTP1.0 also followed. It is at the application layer of computer networks. HTTP is built on top of the TCP protocol. Therefore, the bottleneck of the HTTP protocol and its optimization techniques are based on the TCP protocol. Its own characteristics, such as the 3-way handshake for TCP connection establishment and the 4 waves for disconnection, as well as the RTT delay time caused by each connection establishment.
2.2 HTTP and modern browsers
As early as when HTTP was established, it was mainly for transmitting Hypertext Markup Language (HTML) documents from the WEB server to the client's browser. It also means that for the front end, the HTML page we write will be placed on our WEB server, and the user side accesses the URL address through the browser to obtain the displayed content of the web page, but since WEB2.0, our page has become complicated , It’s not just some simple text and pictures. At the same time, our HTML page has CSs and JavaScript to enrich our page display. When Ajax appears, we have another way to get data from the server. These are actually based on the HTTP protocol. Also in the mobile Internet era, our pages can run in mobile browsers, but compared with PCs, the mobile network conditions are more complicated, which makes us have to understand HTTP in depth and continue to optimize the process.
2.3 HTTP basic optimization
- Bandwidth
If we are still at the stage of dial-up Internet access, bandwidth may become a serious problem that affects requests, but now that the network infrastructure has greatly improved bandwidth, we no longer have to worry about bandwidth affecting network speed, then Only delay is left. - Delay
1. Browser blocking (HOL blocking) : The browser will block the request for some reasons. The browser can only have 4 connections for the same domain name at the same time (this may vary depending on the browser kernel). If the maximum number of connections of the browser is exceeded, subsequent requests will be blocked.
2. DNS Lookup : The browser needs to know the IP of the target browser to establish a connection. The system that resolves domain names to IP is DNS. This can usually use DNS cache results to achieve the purpose of reducing this time.
3. Establish connection (Initial connection) : HTTP is based on the TCP protocol, and the browser can only piggyback the HTTP request message in the third handshake to achieve the real connection establishment, but these connections cannot be reused, which will cause every Each request has undergone a three-way handshake and slow start. The three-way handshake has a more obvious impact in high-latency scenarios, and a slow start has a greater impact on file type requests. The following is a three-way handshake flowchart:
2.4 Some differences between HTTP1.0 and HTTP1.1
HTTP 1.0 was first used in web pages in 1996. At that time, it was only used on some relatively simple web pages and network requests, while HTTP 1.1 was only widely used in current major browser network requests in 1999. At the same time, HTTP 1.1 is currently the most widely used HTTP protocol.
The main differences are mainly reflected in:
- Cache processing : In HTTP1.0, lf-Modified-Since and Expires in the header are mainly used as the criteria for caching judgment. HTTP1.1 introduces more cache control strategies such as Entitytag, lf-Unmodified-Since, If -Match, lf-None-Match and more optional cache headers to control the cache strategy.
- Bandwidth optimization and use of network connections : In HTTP1.0, there are some phenomena of wasting bandwidth. For example, the client only needs a part of an object, but the server sends the entire object, and does not support the function of resumable transmission. HTTP 1.1 introduces the range header field in the request header, which allows only a certain part of the resource to be requested, that is, the return code is 206 (Partial Content), which facilitates the free choice of developers in order to make full use of bandwidth and connections.
- Error notification management : 24 new error status response codes have been added to HTTP 1.1, such as 409 (Conflict) indicates that the requested resource conflicts with the current state of the resource; 410 (Gone) indicates that a resource on the server is permanent Sexual deletion.
- Host header processing : In HTTP1.0, each server is considered to be bound to a unique IP address. Therefore, the URL in the request message does not convey the hostname. But with the development of virtual host technology, there can be multiple virtual hosts (Multi-homed Web Servers) on a physical server, and they share an IP address. Both the HTTP1.1 request message and response message should support the Host header field, and if there is no Host header field in the request message, an error (400 Bad Request) will be reported.
- Persistent Connection : HTTP 1.1 supports PersistentConnection and Pipelining processing of requests. Multiple HTTP requests and responses can be transmitted on a TCP connection, reducing the consumption and delay of establishing and closing connections. Persistent connections are also Corresponding to Connection: keep-alive in HTTP1.1, it makes up for the shortcomings of HTTP1.0 that each request has to create a connection to a certain extent.
2.5 Some existing problems of HTTP1.0 and 1.1
- HTTP1.0 and HTTP1.1 can be called HTTP1.x. As mentioned above, when HTTP1.x transmits data, it needs to re-establish the connection every time, which undoubtedly increases a lot of delay time, especially on the mobile terminal. More prominent.
- When HTTP1.x transmits data, all transmitted content is plaintext, and neither the client nor the server can verify the identity of the other party, which cannot guarantee the security of the data to a certain extent.
- When HTTP1.x is used, the content carried in the header is too large, which increases the transmission cost to a certain extent, and the header does not change much each time the request is made, especially on the mobile terminal, which will increase user traffic.
- Although HTTP1.1 supports keep-alive to compensate for the delay caused by multiple connection creation, the use of keep-alive will also bring a lot of performance pressure on the server, and for services that are constantly requested for a single file (such as Image storage website), keep-alive may greatly affect performance, because it keeps unnecessary connections for a long time after the file is requested. Similarly, keep-alive cannot solve the head-of-line blocking (HOL) problem.
2.6 HTTPS debut
In order to solve some of the above problems, Netscape created HTTPS in 1994 and used it in the Netscape Navigator browser. Initially, HTTPS was used together with SSL. When SSL gradually evolved to TLS (in fact, the two are the same thing, but the names are different), the latest HTTPS was officially confirmed by RFC 2818 published in May 2000. To put it simply, HTTPS is a secure version of HTTP, and due to the higher security requirements of today’s era, both Chrome and Firefox strongly support the use of HTTPS on websites. Apple also forces apps to use HTTPS to transmit data in the ioS 10 system. This shows that HTTPS is imperative.
2.7 Some differences between HTTPS and HTTP
- The HTTPS protocol requires a CA to apply for a certificate. Generally, there are few free certificates and a fee is required.
- HTTP is a hypertext transfer protocol, information is transmitted in plain text, and HTTPS is a secure TLS encrypted transfer protocol.
- HTTP and HTTPS use completely different connection methods and use different default ports. The former is 80 and the latter is 443.
- The HTTPS connection is very simple. The HTTPS protocol is a network protocol constructed by the TLS+HTTP protocol for encrypted transmission and identity authentication, which is safer than the HTTP protocol.
2.8 HTTPS transformation
If a website wants to replace the whole site from HTTP to HTTPS, you may need to pay attention to the following points:
- Install CA certificate : General certificates are charged, and some are free.
1. Let's Encrypt: Free, fast, supports multiple domain names, three commands can sign + export certificates. The disadvantage is that there is only a three-month validity period, and it needs to be renewed when it expires.
2. Comodo PositiveSSL: Charge, but relatively stable. - Configure WEB server : After purchasing the certificate, configure your own domain name on the website provided by the certificate, after downloading the certificate, configure your own WEB server, and carry out code transformation at the same time.
- HTTPS will reduce user access speed : TLS requires a handshake, and HTTPS will reduce the speed to a certain extent, but as long as it is reasonably optimized and deployed, the impact of HTTPS on speed is completely acceptable. In many scenarios, the speed of HTTPS is not inferior to HTTP at all. If SPDY is used, the speed of HTTPS is even faster than HTTP. Compared with HTTPS to reduce the access speed, in fact, the CPU pressure on the server side needs to be more concerned. The large number of key algorithm calculations in HTTPS will consume a lot of CPU resources. Only with sufficient optimization, the machine cost of HTTPS will not increase significantly.
2.9 Speed up your website with SPDY
In 2012, Google put forward the SPDY (pronounced "speedy") solution in 2012. Everyone started to look at and solve the problems of the old version of the HTTP protocol itself from the front. SPDY can be said to be a combination of the advantages of both HTTPS and HTTP. The transmission protocol mainly solves:
- Reduce latency : In response to the high latency of HTTP, SPDY elegantly adopts multiplexing. Multiplexing uses multiple request streams to share a TCP connection, which reduces the delay of creating multiple TCPs and improves bandwidth utilization.
- Request priority (Request Prioritization) : Multiplexing brings a new problem is that on the basis of connection sharing, it may cause key requests to be blocked. SPDY allows setting priorities for each request, so that important requests will be responded to first. For example, when the browser loads the homepage, the html content of the homepage should be displayed first, and then various static resource files, script files, etc. are loaded, so as to ensure that users can see the content of the webpage the first time.
- Header compression : As mentioned earlier, HTTP1.x headers are often redundant and redundant, and the content of some headers is relatively "large" without compression (such as cookies and user-agents, etc.). Choosing a proper compression algorithm can reduce the size and quantity of packets, which not only saves resources, but also reduces the delay of data transmission.
- HTTPS-based encryption protocol transmission : retains the TLS encryption feature of HTTPS, which greatly improves the reliability of data transmission.
- Server Push : A webpage that uses SPDY. For example, my webpage has a request for sytle.css. When the client receives the sytle.css data, the server pushes the index.js file to the client. At the end, when the client tries to get index.js again, it can get it directly from the cache without sending any more requests.
SPDY is located under HTTP and over TCP and SSL, so that it can be easily compatible with the old version of the HTTP protocol (the content of HTTP1.x is encapsulated into a new frame format), and the existing SSL functions can be used at the same time.
Since SPDY is not a standard protocol, SPDY failed to become a formal standard by itself. However, members of the SPDY development team participated in the HTTP 2.0 formulation process. SPDY also has its own compatibility issues. After HTTP2.0 comes out, most browsers will no longer support it.
2.10 The Past and Present of HTTP2.0
With HTTP1.x, then HTTP2.0 will appear logically. HTTP2.0 can be said to be an upgraded version of SPDY (in fact, it was originally designed based on SPDY). However, there are still differences between HTTP2.0 and SPDY, mainly in the following two points:
- The compression algorithm of HTTP2.0 message header adopts HPACK algorithm instead of DEFLATE algorithm adopted by SPDY.
- HTTP2.0 supports plaintext HTTP transmission in the early design stage, while SPDY forces the use of HTTPS. In the later stage, both need to use HTTPS.
In September 2015, Google announced plans to remove support for SPDY and embrace HTTP2.0, which will take effect in Chrome 51.
New features of HTTP2.0
Most of the features of HTTP2.0 are similar to SPDY, mainly the following 4:
- The new binary format (Binary Format) : HTTP1.x parsing is based on text. The format analysis based on the text protocol has natural defects, and the expression of the text is diversified. There are bound to be many scenarios to consider the robustness. The binary system is different, and only the combination of 0 and 1 is recognized. Based on this consideration, the protocol analysis of HTTP2.0 decided to adopt the binary format, which is convenient and robust.
- Multiplexing (MultiPlexing) : That is, connection sharing, that is, each request is used as a connection sharing mechanism. A request corresponds to an id, so that there can be multiple requests on a connection, and the requests of each connection can be randomly mixed together, and the receiver can assign the request to different server requests according to the id of the request. The difference between multiplexing principle and keep alive is as follows:
- Header compression : As mentioned above, the HTTP1.x header mentioned above contains a lot of information, and it must be sent repeatedly each time. HTTP2.0 uses an encoder to reduce the size of the header that needs to be transmitted, and each party in the communication caches a copy The headerfields table not only avoids the transmission of repeated headers, but also reduces the size that needs to be transmitted.
- Server Push : Like SPDY, HTTP2.0 also has a Server Push function.
At present, most websites have enabled HTTP2.0, such as YouTuBe, Taobao and other websites, you can use the Chrome console to check whether Server Push is enabled, as shown in the figure below:
2.12 Upgrade and transformation of HTTP2.0
Compared with the upgrade and transformation of HTTPS, HTTP2.0 acquisition will be slightly simpler. You may need to pay attention to the following issues:
- The previous article said that HTTP2.0 needs to be based on HTTPS, and now mainstream browsers like Chrome, Firefox still only support the HTTP2.0 protocol deployed based on TLS, so if you want to upgrade to HTTP2.0, it is better to upgrade HTTPS first.
- After your website has been upgraded to HTTPS, it is much easier to upgrade to HTTP2.0. All you need to do is to upgrade the server. If you use Nginx, you need to start the corresponding protocol in the configuration file.
- If HTTP2.0 is used, what to do with the original HTTP1.x? Don't worry about this problem. HTTP2.0 is fully compatible with the semantics of HTTP1.x. For browsers that do not support HTTP2.0, Nginx will automatically be downward compatible.
There is a WeChat mini program course design, complete design needs, contact personal QQ: 505417246
Pay attention to the following WeChat public account, you can receive WeChat applet, Vue, TypeScript, front-end, uni-app, full-stack, Nodejs, Python and other practical learning materials. The
latest and most complete front-end knowledge summary and project source code will be released to the WeChat public as soon as possible Number, please pay attention, thank you
After paying attention to the official account , reply to the front-end interview questions and receive a large number of front-end interview questions summary pdf data
