Introduction and understanding of http1.0 http1.1 http2.0 http3.0 websocket GRPC signalR

HTTP Version Introduction

A.Http0.9 version
0.9 is the originator version, its main features include:

• The request method support is limited.
  Only the GET request method is supported, and other request methods are not supported. Therefore, the amount of information transmitted from the client to the server is very limited, that is, the commonly used Post request cannot be used now.
• The request header
  does not support the version number specified in the request, and the server only has the ability to return HTML strings
• The response is closed
  After the server responds, the TCP connection is closed immediately

B.Http1.0 version

Version 1.0 is mainly an enhancement of version 0.9, and the effect is more obvious. The main features and shortcomings include:

• Enriched request methods
  The request method has added POST, DELETE, PUT, HEADER and other methods, which improves the magnitude of information sent by the client to the server
• Add request header and response header
  Add the concept of request header and response header, you can specify the HTTP protocol version number and other header information in the communication, making C/S interaction more flexible and convenient
• Rich data transmission content
  Expanded the transmission content format, including: pictures, audio and video resources, binary, etc. can be transmitted. Compared with 0.9, which can only transmit html content, http has more application scenarios
• Poor link reusability
  In version 1.0, each TCP connection can only send one request, and the connection will be closed after the data is sent. If other resources are requested, the connection must be re-established. In order to ensure correctness and reliability, TCP requires three handshakes and four handshakes between the client and server, so the cost of establishing a connection is very high, and the sending rate is slow at the beginning based on congestion control, so the performance of version 1.0 is not ideal .
• Disadvantages of stateless and connectionless
  version 1.0 is stateless and connectionless . In other words, the server does not track or record the requested state. The client needs to establish a tcp connection for each request and cannot be reused, and 1.0 stipulates that the previous The next request can only be sent after the request response arrives. If the previous one is blocked, the subsequent request will be blocked. Packet loss and out-of-sequence problems and high-cost connection processes cause many problems in multiplexing and head-of-line blocking , so connectionless and stateless is a weakness of version 1.0 .

C.Http1.1 version
1.1 was launched about one year after the release of version 1.0. It is an optimization and improvement of version 1.0 . The main features of version 1.1 include:

• Add a new Connection field for long connections
  , you can set the keep-alive value to keep the connection from disconnecting, that is, the TCP connection is not closed by default, and can be reused by multiple requests. This is also a very important optimization of version 1.1, but the S-side server only handles After one response is completed, the next response will be performed. If the front response is particularly slow, there will be many requests waiting in line later, and there will still be head-of-line blocking problems.
• 
  On the basis of long connection, pipelining can continue to send subsequent requests without waiting for the first request response, but the order of responses is still returned in the order of requests, that is, in the same TCP connection, the client can send multiple requests at the same time . requests, further improving the transmission efficiency of the HTTP protocol.
• More request methods
  Added PUT, PATCH, OPTIONS, DELETE and other request methods.
• host field
  The Host field is used to specify the domain name of the server, so that multiple requests can be sent to different websites on the same server, which improves the reuse of the machine. This is also an important optimization

D. Http2.0 version
2.0 is a milestone version. Compared with version 1.x, it has a lot of optimizations to adapt to the current network scene. Several important functions include:

• Binary format
  1.x is a text protocol, but 2.0 uses binary frames as the basic unit. It can be said that it is a binary protocol that divides all transmitted information into messages and frames, and uses binary format encoding. One frame contains data and Identifiers make network transmission efficient and flexible.
• Multiplexing
  is a very important improvement. In 1.x, there are problems with the consumption and efficiency of establishing multiple connections. In version 2.0, multiple requests share one connection, and multiple requests can be processed simultaneously in one TCP The concurrency of the connection is mainly distinguished by the identification in the binary frame to realize the multiplexing of the link.
• Header compression
  version 2.0 uses the HPACK algorithm to compress the header data, thereby reducing the size of the request and improving efficiency. This is very easy to understand. Previously, the same header was sent every time, which seemed very redundant. Version 2.0 is correct Incremental update of internal information effectively reduces the transmission of header data.
• Server-side push
  This function is a bit interesting. Before the 1.x version, the server was passively executed after receiving the request. In the 2.0 version, the server is allowed to actively send resources to the client, which can accelerate the client.

E. Http3.0 version

HTTP3.0, also known as HTTP Over QUIC , abandons the TCP protocol and uses the UDP-based QUIC protocol to implement it. QUIC is actually the abbreviation of Quick UDP Internet Connections , literally translated as fast UDP Internet connection. It is a UDP-based transport protocol proposed by Google. HTTP 3.0 was officially released on June 6, 2022, and the IETF formulated the HTTP 3.0 standard in RFC 9114.

Advantages of using QUIC

• Using the UDP protocol, there is no need for a three-way connection handshake, and it will also shorten the time for TLS to establish a connection.

• Solved the head-of-line blocking problem.

• Realize dynamic pluggability, and realize the congestion control algorithm in the application layer, which can be switched at any time.

• The message header and message body are respectively authenticated and encrypted to ensure security.

• Connections migrate smoothly.

WebSocket

WebSocket is a two-way communication protocol, which uses the HTTP/1.1 protocol in the handshake phase (HTTP/2 is not supported temporarily). First initiate a special HTTP request through the HTTP/HTTPS protocol for handshake and then create a TCP connection for exchanging data, which also supports long connections. WebSocket is first initiated by HTTP, and then converted to WebSocket.

Features of the WebSocket protocol

• Based on the TCP protocol, it needs to be connected through a handshake to communicate, and the server-side implementation is relatively easy.
• It has good compatibility with HTTP protocol. The default port is also 80 or 443, and the handshake phase uses the HTTP protocol, so it is not easy to shield during the handshake, and can pass through various HTTP proxy servers.
• The data format is relatively lightweight, the performance overhead is small, and the communication is efficient. Either text or binary data can be sent.
• There is no same-origin restriction, the client can communicate with any server.
• The protocol identifier is ws (or wss if encrypted), and the server URL is the URL. (eg: ws://www.example.com/chat)
• It is a two-way communication protocol that uses asynchronous callbacks to receive messages. When a communication connection is established, a persistent connection can be achieved. Both the WebSocket server and the Browser can actively send or receive data to each other. The actual push method is the server Active push, as long as there is data, it will be pushed to the requester.

handshake process

First, the client initiates a special HTTP request to the server. If the server supports this version of WebSocket, it will return a 101 response. After the handshake is completed, the next TCP data packets are frames of the WebSocket protocol. as the picture shows:

Similarities and differences between HTTP1.1 and WebSocket

Finally, as a summary, let us review the similarities and differences between HTTP1.1 and WebSocket. Deepen the understanding of WebSocket.

Similarities and differences at the protocol level

Same point

• Both are TCP-based application layer protocols.
• Both use the Request/Response model to establish connections.
• Errors are handled in the same way during connection establishment, at which point WebSocket may return the same return code as HTTP.

difference

• The HTTP protocol is based on Request/Response and can only do one-way transmission, which is a half-duplex protocol, while WebSocket is a full-duplex protocol, similar to Socket communication, and both parties can send data to the other party at any time.
• WebSocket uses HTTP to establish a connection, but defines a series of new header fields that are not used in HTTP. In other words, the request headers of the two are different.
• A WebSocket connection cannot be forwarded through a middleman, it must be a direct connection. If it is forwarded through a proxy, a proxy must withstand so many WebSocket connections without releasing it, which is similar to a DDOS attack.
• When WebSocket establishes a handshake connection, the data is transmitted through the HTTP protocol, but after the connection is established, the actual data transmission stage does not require the participation of the HTTP protocol.
• The data transmitted by WebSocket is a binary stream, which is frame-based. The HTTP transmission is plaintext transmission, which is a string transmission. The data frames of WebSocket are ordered.

The relationship between websocket and HTTP can refer to the following figure

 WebSockets were originally designed for HTTP/1.1, but were later repurposed for HTTP/2.

 .NET 7 introduces HTTP/2-based Websockets support for Kestrel, the SignalR JavaScript client, and SignalR with Blazor WebAssembly.

HTTP/2 WebSockets use CONNECT requests instead of GET, so you may need to update your own routes and controllers.

SignalR

ASP.NET Core SignalR is an open source library that can be used to simplify adding real-time web functionality to applications. Real-time web functionality enables server-side code to push content to the client. According to my understanding, it is also a message transmission framework based on Http2.0.

Candidates suitable for SignalR:

• Apps that require frequent updates from the server. Examples include games, social networking, voting, auctions, maps, and GPS applications.
• Dashboard and monitoring apps. Examples include company dashboards, instant sales updates, or travel alerts.
• collaborative application. Examples of collaboration applications include whiteboard applications and team meeting software.
• Apps that require notifications. Social networking, email, chat, games, travel alerts, and many other applications use notifications.

SignalR provides an API for creating server-to-client remote procedure calls (RPC). RPCs call functions on the client side from server-side .NET Core code. Provides multiple supported platforms , each of which has its own client SDK. Therefore, the programming language invoked by the RPC calls differs.

Here are some features of ASP.NET Core SignalR:

• Connection management is handled automatically.
• Simultaneously send a message to all connected clients. For example chat rooms.
• Send a message to a specific client or group of clients.
• Scale it to handle increasing traffic.
• SignalR Central Protocol

transmission

SignalR supports the following technologies for handling real-time communications (in order of normal fallback):

• WebSockets
• Server-Sent Events
• long polling

SignalR automatically chooses the best transport method within the capabilities of the server and client.

center

SignalR uses hubs to communicate between clients and servers.

A hub is an advanced pipeline that allows clients and servers to call methods on each other. SignalR automatically handles scheduling across computer boundaries and allows clients to call methods on the server and vice versa. Strongly typed parameters can be passed to methods, enabling model binding. SignalR provides two built-in central protocols: a JSON-based text protocol and a MessagePack-based binary protocol. MessagePack typically creates smaller messages compared to JS.

The hub invokes client code by sending a message containing the name and parameters of the client method. Objects sent as method arguments are deserialized using the configured protocol. The client tries to match the name to the method in the client code. When the client finds a match, it calls the method and passes it the deserialized parameter data.

GRPC

overview

GRPC is a high-performance, general-purpose open source RPC framework, based on 底层HTTP/2协议标准and 协议层Protobuf序列化协议developed by and supports many development languages.

gRPC is also based on the idea of ​​defining a service and specifying its methods (including parameters and return types) that can be called remotely. Implement this interface on the server side and run a gRPC server to handle client calls. Having a stub on the client can act like a method on the server.

gRPC uses protocol buffersas the interface description language (IDL) and the underlying information exchange format

advantage

1. Binary protocol based on HTTP/2 (Protobuf serialization mechanism);
2. A connection can be multiplexed, and multiple requests and responses can be processed concurrently;
3. Class library implementation in multiple languages;
4. Service definition files and automatic code generation (.proto files and Protobuf build tools).
5. RPC also provides many extension points for functional customization and expansion of the framework. For example, through the open load balancing interface, it can seamlessly integrate with third-party components (Zookeeper, domain name resolution service, SLB service, etc.)

Reference document: I finally understand, a brief history of HTTP protocol development - Zhihu (zhihu.com)