Requirements: Most websites now mainly use the Http/1.1 and Http/2.0 version protocols, for websites that only support the HTTP/2 protocol version, using HttpClient to send requests by default, will throw System.Net.Http.Http.HttpRequestException: An error occurred while sending the request. ---> System.IO.IOException: Unable to read data from the transport connection: The software in your host has aborted an established connection. ---> System.Net.Sockets.SocketException (10053): Software in your host aborts an established connection. at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.CreateException(SocketError error, Boolean forAsyncThrow).
History of the HTTP protocol
Timeline
HTTP/0.9
The obsolete HTTP/0.9 was the first version of the HTTP protocol, born in 1989. It is extremely simple, allowing the client to send a GET request and does not support the request header. Since there is no protocol header, HTTP/0.9 can only support one type of content - plain text. The server can only respond to strings in HTML format, not other formats. When the server is done sending, the TCP connection is closed.
HTTP/0.9 has a typical statelessness, where each visit is processed independently and disconnected when processing is complete. If the requested page does not exist, no error codes are returned.
HTTP/1
HTTP/1 is a collective term for HTTP 1.0 and HTTP 1.1, which refers to the versions of the HTTP protocol that are 1.0 and 1.1, respectively.
HTTP 1.0 was the second version of the HTTP protocol and is still widely adopted today. It has made a number of enhancements and improvements based on HTTP/0.9, including:
More formats such as images, videos, binaries can be sent beyond just text
On top of and POST request methods have been added
Changed the format of HTTP requests and responses. In addition to the data part, each communication must include an HTTP header that describes some metadata, i.e., the request header information is added
Added functions such as response status code, multi-character set support, authorization, cache, and content encoding
Although it is still a stateless protocol, long connections can be supported by adding the "Connection: keep-alive" header to the request
HTTP 1.1
HTTP 1.1 is a standardized protocol, and HTTP 1.1 eliminates a lot of ambiguity and introduces several improvements.
peculiarity
Cache processing, HTTP 1.1 introduces more cache control policies, such as Entity tag, If-Unmodified-Since, If-Match, If-None-Match, etc., and more optional cache headers to control the cache policy.
Bandwidth optimization and the use of network connections introduce a range in the request header, which allows only one part of the resource to be requested, that is, return the 206 status code, which makes it easier for developers to freely choose to make full use of bandwidth and links, and can use Range and Content-Range to create a breakpoint resumption function.
Error notification management, 24 new error status codes have been added in HTTP 1.1.
Adding the Host header allows different domain names to be configured on servers with the same IP address.
Support long connections, HTTP 1.1 supports long connections, multiple HTTP requests and responses can be transmitted on a TCP connection, reducing the consumption and delay of establishing and closing connections, and Connection:keep-alive is enabled by default in HTTP 1.1, and general browsers allow 6 long links to be established at the same time for the same domain name.
Added pipelining technology to allow a second request to be sent before the first response is fully sent to improve queue blocking, but the order of responses will still be returned in the order of the requests.
Support response chunking, by setting Transfer-Encoding: chunked for chunked response, allowing the response data to be divided into multiple parts, and the server can release the buffer as soon as possible to obtain faster response speed.
HTTP 2.0
HTTP 2.0 has better performance, and now web pages are becoming more and more complex, and even evolve into unique applications, the amount of media playback, the size of scripts to enhance interaction has also increased a lot, and more data is transmitted through HTTP requests, so HTTP 2.0 has made a lot of optimizations for network efficiency.
peculiarity
Binary Frame Splitting, HTTP 2.0 is a binary protocol rather than a text protocol that splits all transmitted information into smaller messages and frames and encodes them in binary format.
Multiplexing, parallel requests can be processed in the same link, all accesses under the same domain name are from the same TCP connection, HTTP messages are broken down into independent frames, and the server reassembles the messages according to identifiers and headers, removing the order and blocking constraints in HTTP 1.1.
Compressing headers, which are often similar in a series of requests, removes the cost of duplication and transmission of duplicate data.
Server-side push, the server can proactively push resources to the client without explicit request from the client.
HTTP 3.0
HTTP 3.0 is currently in the formulation and testing stage, is a new HTTP protocol in the future, HTTP 3.0 protocol runs on top of the QUIC protocol, is based on UDP to achieve reliable transmission, trade-off transmission speed and transmission reliability and optimize, using UDP will avoid TCP queue blocking problem, and speed up network transmission speed, but also need to achieve a reliable transmission mechanism, HTTP 3.0 is not an extension of HTTP 2.0, HTTP 3.0 will be a completely new protocol.
HttpClientHandler VS SocketsHttpHandler
The default message handler used by HttpClient in the .NET Framework and .NET Core 2.0 and earlier is HttpClientHandler.
Starting with .NET Core 2.1, classesSocketsHttpHandler provides a higher-level HTTP networking class(e.g. HttpClient). Using SocketsHttpHandler offers many advantages:
Performance has improved significantly compared to previous implementations.
Eliminate platform dependencies to simplify deployment and service. For example, libcurl no longer depends on .NET Core for macOS and .NET Core for Linux.
Consistent behavior across all .NET platforms.
In .NET 9, HttpClientFactory uses SocketsHttpHandler as the main handler
HttpClientFactory allows configuring HttpClient pipelines for named and typed HttpMessageHandler objects. The innermost handler or the handler that actually sends requests on the network is called the master handler. If not configured, this handler was always an HttpClientHandler before. While the default master handler is the implementation details, there are users who rely on it. For example, some users cast the main handler to the HttpClientHandler setting properties such as ClientCertificates, UseCookies, and UseProxy.
Link:The hyperlink login is visible.
The global configuration requests the HTTP protocol version
The code is as follows:
DefaultRequestVersionThe default setting is HttpVersion.Version11。
The DefaultRequestVersion property specifies the default HTTP version to be used for requests sent using this HttpClient instance, when it constructs the HttpRequestMessage to send, specifically by calling 、、、GetStreamAsyncGetAsyncGetAsyncGetByteArrayAsync, PatchAsyncGetStringAsync, PostAsync and PutAsync.
DefaultRequestVersion propertyDoes not apply to the SendAsync method。 The HttpRequestMessage parameter passed to the SendAsync method as a parameter has its own Version property that controls the HTTP version used for the request.
Link:The hyperlink login is visible.
HttpVersionPolicy negotiation policy
RequestVersionOrLower: Use the requested version, or downgrade to a lower version (but not higher than the requested version). This is the default behavior. In simple terms, the highest used protocol version is the current version, and if the current protocol version is not supported, it will be downgraded.
RequestVersionOrHigher: Use the highest version supported by the server, but not lower than the requested version. That is, upgrades are allowed, and downgrades below the requested version are not allowed. In simple terms, use higher-version protocols for communication whenever possible.
RequestVersionExact: Strictly use the requested version, no upgrades or downgrades are allowed.
HttpClient uses the Http/2.0 version protocol
The test code is as follows:
The request uses version 1.1, and the final client and server negotiate to use the 2.0 protocol to communicate, so the final response is version 2.0, as shown in the figure below:
Reference:
The hyperlink login is visible.
The hyperlink login is visible.
The hyperlink login is visible. |
Posted on 2025-8-31 21:16:47
|
|
|
|
Landlord|
Posted on 2025-8-31 21:46:27
|
