Development history of http protocol & new features of http2

Development History

HTTP/0.9 (in the past)

Approximate time: In the past-1996

  • Only one command GET
  • There is no information describing the data such as HEADER
  • After the server has finished sending, close the TCP connection

HTTP/1.0 (in the past)

Approximate time: around 1996

  • Many commands have been added
  • Increase status code and header
  • Multi-character set support, multi-part sending, permissions, caching, etc.

HTTP/1.1 (now)

Approximate time: around 1996-now

  • Persistent connection
  • pipeline
  • Add host and some other commands

HTTP2 (The future is here)

Approximate time: 2012 began to formulate specifications

  • All data is transmitted in binary
  • Sending multiple requests in the same connection no longer needs to be in order
  • Header compression and push functions to improve efficiency

Overview

Insert picture description here

http2

  • Using binary protocol: HTTP/1.1 header information is text (ASCII encoding), and the data body can be text (very troublesome to parse) or binary. HTTP/2 is a complete binary protocol, the header information and data body are both binary, commonly known as "frame" (FRAME): header information frame and data frame. One advantage of the binary protocol is that additional frames can be defined and the analysis is convenient.
  • Multiplexing (two-way, real-time communication): HTTP/2 multiplexes TCP connections. In one connection, both the client and server can send multiple requests or responses at the same time, instead of having to correspond to each other in order, so Avoid "head-of-line blocking". For example: in a TCP connection, the server receives the request of A and request B at the same time, and first responds to the request of A. It turns out that the processing process is very time-consuming, so it sends the processed part of the request of A, and then responds to the request of B to complete After that, the remaining part of the B request is sent.
  • Data flow: The data flow of HTTP/2 is sent out of order. The consecutive data packets in the same connection may belong to different responses. Therefore, the data packet must be marked to indicate which response it belongs to. HTTP/2 refers to all data packets of each request or response as a data stream. Each data stream has a unique number. When a data packet is sent, the data stream ID must be marked to distinguish which data stream it belongs to. In addition, it is stipulated that the ID of the data stream sent by the client is an odd number, and the ID sent by the server is an even number. When the data stream is half sent, both the client and the server can send a signal to cancel the data stream. That is, HTTP/2 can cancel a request while ensuring that the TCP connection is still open and can be used by other requests. The client can also specify the priority of the data stream. The higher the priority, the sooner the server responds.
  • Header information compression: The previous version of HTTP2 protocol does not have status, and all information must be attached to each request. Therefore, many fields of the request are repeated, such as COOKIE and USER AGENT, which have exactly the same content and must be attached to each request. This wastes a lot of bandwidth and affects speed. HTTP/2 optimizes this. Introduced header compression mechanism. On the one hand: the header information is compressed using GZIP or COMPRESS and then sent. On the other hand, the client and server maintain a header information table at the same time, all fields will be stored in this table, an index number will be generated, and the same fields will not be sent in the future , Only the index number is sent to increase the speed.
  • Server push: HTTP/2 allows the server to actively send resources to the client without request -> server push. eg: The client requests a web page, which contains static resources. Under normal circumstances, the client must parse the HTML source code after receiving the web page and find that there are static resources before sending a static resource request; in fact, the server can expect that after the client requests the web page, it is likely to request static resources again, so take the initiative to add these The static resources are sent to the client along with the web page.

reference

https://www.jianshu.com/p/6faabcc55df4
https://www.runoob.com/http/http-tutorial.html

Guess you like

Origin blog.csdn.net/weixin_43972437/article/details/114887784