HTTP protocol versions

HTTP / 0.9

HTTP is the original version of the HTTP protocol. It only supports GET and requests to access resources in HTML format.

HTTP / 1.0

The request line must end with a protocol version field (HTTP /1.0); A header message must be included

Improved in version 0.9, adding POST and HEAD requests; No longer limited to HTML version 0.9, according to the content-Type can support a variety of data formats, namely MIME multi-purpose Internet mail extensions, such as text/ HTML, image/ JPEG, etc. It also supports cache, which allows clients to access a unified website within a specified period of time.

Again, the format of HTTP requests and responses has changed. In addition to the data section, each communication must include headers (HTTP headers) that describe some metadata.

Other new features include Status Code, multi-character set support, multi-part Type, authorization, cache, and Content encoding.

However, version 1.0 works in such a way that only one TCP connection can be sent at a time. When the server responds, the connection is closed and the next TCP connection needs to be established again, but keepalive is not supported.

The cost of creating a TCP connection is high because of the three-way handshake between the client and the server and the slow start. As a result, HTTP 1.0 has poor performance. The more external resources a web page loads, the more this problem becomes

To solve this problem, some browsers use a non-standard Connection field when making requests.

Connection: keep-alive
Copy the code

This field requires that the server not close the TCP connection so that other requests can be reused. The server also responds to this field.

Connection: keep-alive
Copy the code

A TCP connection is established that can be reused until the client or server actively closes the connection. However, this is not a standard field and may not behave consistently across implementations, so it is not a fundamental solution.

The content-type field

In terms of character encoding, version 1.0 stipulated that the header information must be ASCII and the following data can be in any format. So when the server responds, it has to tell the client what format the data is in, and that’s what the Content-Type field is for.

Here are some common content-Type field values.

text/plain

 text/html 

text/css 

image/jpeg 

image/png

 image/svg+xml 

audio/mp4 

video/mp4 

application/javascript 

application/pdf 

application/zip 

application/atom+xml 

These data types are collectively called MIME types, and each value contains a primary and secondary type separated by a slash.

In addition to predefined types, vendors can also customize types.

application/vnd.debian.binary-package

The above type indicates that binary packets are being sent from the Debian system.

MIME types can also use semicolons at the end to add parameters.

Content-Type: text/html; charset=utf-8
Copy the code

The above type indicates that a web page is being sent and the encoding is UTF-8.

When a client requests, it can use the Accept field to declare which data formats it accepts

meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <! <meta charset=" utF-8 "/>Copy the code

In the code above, the client declares that it can accept data in any format. MIME Types can be used not only in HTTP but also in other places, such as HTML web pages.

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <! <meta charset=" utF-8 "/>Copy the code

The Content – Encoding field

Since the data can be sent in any format, the data can be compressed before being sent. Content-encoding Specifies the data compression method.

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Copy the code

At request time, the client uses the accept-Encoding field to indicate which compression methods it can Accept.

Accept-Encoding: gzip, deflate
Copy the code

HTTP / 1.1

The biggest change in version 1.1 is the introduction of persistent connection. That is, TCP connections are not closed by default and can be reused by multiple requests without declaring connection: keep-alive. Fixes the keepalive problem in version 1.0. Version 1.1 added persistent connections, allowing multiple HTTP requests for a TCP connection.

The client and server can close the connection if they find the other side inactive for a period of time. However, it is standard practice for the client to send Connection: close on its last request, explicitly asking the server to close the TCP Connection.

Connection: close
Copy the code

Currently, most browsers allow up to six persistent connections to the same domain name. It reduces latency and improves bandwidth utilization

The pipeline mechanism is added to allow multiple requests to be sent simultaneously in the same TCP connection, increasing the concurrency and further improving the efficiency of THE HTTP protocol. For example, the client needs to request two resources. In the past, in the same TCP connection, first send A request, and then wait for the server to respond, and then send A request B. The pipeline mechanism allows the browser to make both A and B requests at the same time, but the server responds to A and B requests in the same order.

The Content – Length field

A TCP connection can now send multiple responses, and there has to be a mechanism to distinguish which response packets belong to. This is what the Content-Length field is for, declaring the length of the response.

Content-Length: 3495
Copy the code

The code tells the browser that the response is 3495 bytes long, and that the following bytes belong to the next response.

In version 1.0, the Content-Length field was not required because the browser noticed that the server had closed the TCP connection, indicating that all the packets had been received.

Block transfer encoding

To use the Content-Length field, the server must know the Length of the response before sending it.

For some time-consuming dynamic operations, this means that the server waits until all operations are complete before sending data, which is obviously inefficient. A better approach is to send a block of data as it is generated, using a stream instead of a buffer.

Thus, version 1.1 makes it possible to use chunked transfer encoding instead of content-Length. Any request or response header with a Transfer-Encoding field indicates that the response will consist of an undetermined number of data blocks.

Transfer-Encoding: chunked
Copy the code

Each non-empty block of data is preceded by a hexadecimal number indicating the length of the block. Finally, a block of size 0 indicates that the data for this response has been sent. Here’s an example.

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
 
25
This is the data in the first chunk
 
1C
and this is the second one
 
3
con
 
8
sequence
 
0
Copy the code

Added request modes such as PUT, PATCH, OPTIONS, and DELETE.

In addition, the Host field has been added to the client request header to specify the domain name of the server. HTTP1.0 assumes that each server is bound to a unique IP address, so the URL in the request message does not pass the hostname. However, with the development of virtual hosting technology, there can be multiple virtual hosts (multi-homed Web Servers) on a physical server, and they share the same IP address.

Host: www.example.com

With the Host field, requests could be sent to different sites on the same server, laying the foundation for the rise of virtual hosting. Realize that you can create multiple virtual WEB sites on a WEB server using different host names on the same IP address and port number. That is, multiple virtual sites on the Web Server can share the same IP address and port. An error (400 Bad Request) will be reported if there is no Host header field in the Request message.

Although version 1.1 allows reuse of TCP connections, all data traffic within the same TCP connection is sequential. The server processes requests in queue order. The server does not process another response until it has processed one. If the first request takes a long time to process, there will be many requests waiting in the queue, which will cause the problem of “queue blocking”. In addition, HTTP is a stateless connection. Therefore, repeated fields need to be added to each request, reducing bandwidth utilization.

A new problem with multiplexing is that critical requests can be blocked on a shared connection basis. SPDY allows you to prioritize each request so that important requests get a response first. For example, when the browser loads the home page, the HTML content of the home page should be displayed first, and then all kinds of static resource files and script files are loaded, so as to ensure that users can see the content of the web page in the first time.

To avoid this problem, there are only two ways to reduce the number of requests and open more persistent connections at the same time. This has led to many web optimization techniques, such as merging scripts and style sheets, embedding images in CSS code, domain sharding, and more. This extra work could have been avoided if the HTTP protocol had been better designed.

100(Continue) Status(Save bandwidth)

HTTP/1.1 adds a new status code 100 (Continue). The client sends an Unauthorized request for the lead domain only. If the server rejects the request because of permissions, it returns the response code 401 (Unauthorized). If the server receives the request and sends back the response code 100, the client can continue to send the full request with the entity. The use of the 100 (Continue) status code allows a client to test the server with the Request header before sending the request body to see if the server wants to receive the request body, and then decide whether to send the request body.

HTTP/1.1 added some new features of cache over 1.0. Stale objects are not discarded when their Age expires, but are revalidated with the source server.

HTTP 1.1 supports sending only header information (without any body information) and returning 100 if the server thinks the client has permission to request the server, or 401 otherwise. The client does not start sending the request body to the server until it receives 100. This saves bandwidth by saving the client from sending the body request when the server returns 401.

HTTP1.1 also has authentication mechanisms. Many Web sites require users to provide a username-password pair in order to access documents stored on their servers. This requirement is called authentication. HTTP provides special status codes and headers to help Web sites perform authentication.

HTTP supports delivery of a portion of the content. In this way, when the client already has some resources, it only needs to request other resources from the server. This is the basis for supporting file breakpoint continuation.

HTTP/1.1 supports file breakpoint continuation, RANGE:bytes, HTTP/1.0 Each transfer of a file starts from the file header, which is 0 bytes. RANGE:bytes=XXXX Indicates that the server is required to send the file from the XXXX byte. The return code is 206 (Partial Content)

Add 24 error status response codes in HTTP1.1. For example, 409 (Conflict) indicates that the requested resource is in Conflict with the current state of the resource. 410 (Gone) Indicates that a resource on the server is permanently deleted.

HTTP / 2.0

To solve the problem of low utilization of version 1.1, HTTP/2.0 was proposed. Add duplex mode, that is, not only the client can send multiple requests at the same time, the server can also process multiple requests at the same time, solve the problem of queue head congestion (HTTP2.0 uses multiplexing technology, do the same connection concurrently processing multiple requests, and the number of concurrent requests than HTTP1.1 several orders of magnitude larger); HTTP requests and responses in the status line and request/response headers are some of the information field, and no real data, so all of the information field in version 2.0 set up a table, for each field in the table index, the client and server to use the table together, between them, taking the index number to represent the information field, This avoids the repetitive, cumbersome fields of older 1.0 versions and delivers them in a compressed manner, improving utilization.

In addition, the server push function is also added, that is, the server actively sends data to the client without request.

The current mainstream protocol version is HTTP/1.1.

Binary protocol

The HTTP/1.1 header is definitely text (ASCII encoded), and the data body can be either text or binary. HTTP/2 is a completely binary protocol. Headers and data bodies are binary and collectively referred to as “frames” : header and data frames. One advantage of the binary protocol is that additional frames can be defined. HTTP/2 defines nearly ten frames, setting the stage for future advanced applications. If you do this with text, parsing the data becomes cumbersome, while binary parsing is much more convenient.

multiplex

HTTP/2 multiplexes TCP connections so that both the client and the browser can send multiple requests or responses at the same time in a single connection without having to follow the sequence, thus avoiding “queue congestion”.

For example, in A TCP connection, the server receives both A request and B request, and responds to A request first, only to find that the process is time-consuming. It sends the completed part of A request, responds to B request, and then sends the rest of A request.

Such two-way, real-time communication is called Multiplexing.

The data flow

Because HTTP/2 packets are sent out of order, successive packets within the same connection may be different responses. Therefore, the packet must be marked to indicate which response it belongs to.

HTTP/2 refers to all packets of data for each request or response as a stream. Each data stream has a unique number. The data flow ID must be marked when the data packet is sent to distinguish which data flow it belongs to. In addition, it is stipulated that the data stream sent by the client must have an odd number of ids, and the data stream sent by the server must have an even number of ids.

Halfway through a stream, both the client and server can send a signal (RST_STREAM frame) to cancel the stream. Version 1.1 The only way to cancel the data stream is to close the TCP connection. That is, HTTP/2 can cancel a request while keeping the TCP connection open and available for other requests.

The client can also specify the priority of the data flow. The higher the priority, the sooner the server will respond.

Header compression

The HTTP protocol has no state, and all information must be attached to each request. Therefore, many fields of the request are repeated, such as Cookie and User Agent. The same content must be attached to each request, which will waste a lot of bandwidth and affect the speed. HTTP/2 optimizes this by introducing header compression. On the one hand, the header information is compressed using gzip or COMPRESS and then sent. On the other hand, both the client and the server maintain a header table where all fields are stored, generating an index number, and then not sending the same field, but only the index number, which increases speed.

Server push

HTTP/2 allows a server to send resources to a client unsolicited, which is called server push.

This means that when we request data from an HTTP2.0 enabled Web server, the server will incidentally push some resources to the client, so that the client will not create a connection to send a request to the server. This is a great way to load static resources.

These resources pushed by the server side actually exist somewhere on the client side, and the client side can load these resources directly from the local, without going to the network, the speed is naturally much faster.

A common scenario is that a client requests a web page that contains many static resources. Under normal circumstances, the client must receive the web page, parse the HTML source code, find the static resource, and then send a static resource request. In fact, the server can expect the client to request a web page, it is likely to request static resources, so take the initiative to send these static resources together with the web page to the client.

Server push can send the resources required by the client to the client along with index. HTML, saving the step of repeated requests by the client. Because there are no requests, connections, etc., static resources can be pushed by the server to greatly improve the speed.

The key to HTTP performance optimization is not high bandwidth, but low latency. TCP connections “tune” themselves over time, limiting the maximum speed of the connection at first and increasing the speed of the transfer over time if the data is successfully transferred. This tuning is called TCP slow start (congestion control). For this reason, HTTP connections that are inherently abrupt and short become very inefficient.

HTTP/2 enables more efficient use of TCP connections by having all data flows share the same connection, allowing high bandwidth to truly serve HTTP’s performance gains.

2. HTTP response model

After the server receives an HTTP request, there are several ways to respond to the request. Here are four models of HTTP responses:

Single-process I/O model

The server starts a process. Each process can process only one request, and the request is processed in sequence.

Multi-process I/O model

The server can start multiple processes in parallel. The same process can process only one request, so that the server can process multiple requests at the same time.

Reuse I/O model

The server starts a process, but at the same time, open multiple threads, a thread response to a request, the same can be achieved at the same time processing multiple requests, concurrent execution between threads;

Multithreaded I/O model

The server starts multiple processes in parallel and each process starts multiple threads at the same time, so that the server can process the number of processes M* the number of threads per process N requests.

Request and response messages

1. Request packets

An HTTP request packet consists of three parts (request line + request header + request body) :

Here is an actual request message:

GET and POST are the most common HTTP methods. Other HTTP methods include DELETE, HEAD, OPTIONS, PUT, and TRACE. However, while most current browsers only support GET and POST, Spring 3.0 provides a HiddenHttpMethodFilter that allows you to specify these special HTTP methods with the form parameter “_method” (and actually submit the form via POST). After the HiddenHttpMethodFilter is configured on the server side, Spring emulates the corresponding HTTP methods based on the values specified by the _method parameter, so that these HTTP methods can be used to map processing methods.

② is the URL address corresponding to the request, which together with the Host attribute of the packet header constitutes a complete request URL, and ③ is the protocol name and version number.

④ Is an HTTP packet header. The packet header contains several attributes in the format of Attribute Name: Attribute value. The server obtains information about the client based on the attributes.

⑤ is a newspaper style, which encodes component values in a page form into a format string with param1=value1&param2=value2 key-value pairs. It holds data for multiple request parameters. Not only can the message format pass the request parameters, but the request URL can also be passed via something like “/chapter15/user.html? Param1 =value1& Param2 =value2 is used to pass the request parameters.

If we break it down further, you can see a more detailed structure:

Attribute of the HTTP request header

What are header attributes? We may as well illustrate with a short story.

It's nearly noon, Zhang Sanfeng doesn't want to go to the canteen, so he calls for take-out: Boss, I want a [fish fragrant pork], I want to send it to me before 12:30, I'm in the R&D department of Jianghu Lake Company, my name is Zhang Sanfeng.Copy the code

Here, you want [yu Xiang Rou si] to be equivalent to the HTTP message, while “send by 12:30”, you call “Zhang Sanfeng” and other messages are equivalent to the HTTP header. They are ancillary information that will help you close the deal with the restaurant owner

Both the request HTTP packets and the response HTTP packets have several packet attributes, which are ancillary information to assist the client and server in the transaction.

Common HTTP request header attributes

Accept

The request message tells the server what type of response the client accepts through an Accept header attribute.

The following header is equivalent to telling the server that the response type is only plain text data. Don’t send any other pictures or videos, then I will be dead

Accept:text/plain   
Copy the code

Cookie

The Cookie of the client is passed to the server through this header property. As follows:

Cookie: $Version=1; Skin=new; jsessionid=5F4771183629C9834F8382E23BE13C4CCopy the code

How does the server know that multiple requests from the client belong to one Session? Notice the background of the jsessionid = 5 f4771183629c9834f8382e23be13c4c yet? Jsessionid = jsessionID = jsessionID = jsessionID = jsessionID = jsessionID = jsessionID = jsessionID = jsessionID = jsessionID (Of course, you can rewrite the URL to attach the session ID at the end of each URL.)

Referer

Indicates the URL from which the request comes. If you search for an advertising page of a merchant through Google and you are interested in this advertising page, send a request message to the website of the merchant with a click of the mouse. The attribute value of the Referer header of the request message is www.google.com. Many seemingly magical web monitoring software (such as the famous “I want”) simply put a piece of JavaScript on your web page and can help you monitor traffic, the distribution of visitors across the country and other reports and charts, using this Referer and other HTTP headers.

Cache-Control

Control of caching, such as a request that the content returned by the response should be cached by the client for a year, or that it should not be cached, can be achieved through this header.

If the following Settings are set, the server will not cache the response content of the corresponding request in the client:

Cache-Control: no-cache   
Copy the code

2. Anatomy of HTTP response packets

Response message structure

The HTTP response packet also consists of three parts (response line + response header + response body) :

Here is an actual HTTP response message:

① Packet protocol and version; ② Status code and status description; ③ The response header is also composed of multiple attributes; ④ Response style, that is, we really want the “dry goods”.

Response status code

Compared with the request packet, the response packet has a response status code, which tells the client the processing result of the request in a clear and unambiguous language.

The HTTP response status code consists of five segments:

1XX message: the request has been received and is being processed. 2XX Processing is successful: The request is received, I understand what you want, the request is accepted, and the processing is complete. 3XX redirect to another location. It lets the client make another request to complete the processing. 4XX processing errors occur, and the client is responsible for such errors. For example, the client requests a non-existent resource, the client is not authorized, and access is prohibited. When 5XX processing errors occur, the fault is on the server. For example, the server throws an exception, the route fails, and the HTTP version is not supported.Copy the code

Here are a few common status codes:

100 Continue. The client should continue with its request

101 Switching Protocols Switching protocol. The server switches protocols based on client requests. You can only switch to a more advanced protocol, for example, the new version of HTTP

200 The OK request succeeded. Typically used for GET and POST requests

201 Created Created. The new resource was successfully requested and created

202 Accepted. The request has been accepted, but processing is not complete

Our Authoritative Information is Authoritative. The request succeeded. The meta information returned is not the original server, but a copy

204 No Content No Content. The server processed successfully, but did not return content. You can ensure that the browser continues to display the current document without updating the web page

205 Reset Content Resets the Content. The server is successful, and the user end (for example, browser) should reset the document view. Use this return code to clear the browser’s form field

206 Partial Content The server successfully processed some of the GET requests

300 Multiple Choices. The requested resource can include multiple locations, and a list of resource characteristics and addresses can be returned for user terminal (e.g., browser) selection

301 Moved Permanently Moved Permanently. The requested resource has been permanently moved to the new URI, the return message will include the new URI, and the browser will automatically redirect to the new URI. Any future new requests should be replaced with a new URI

302 Found temporary movement. Similar to 301. But resources are moved only temporarily. The client should continue to use the original URI

303 See Other View Other IP addresses. Similar to 301. Use GET and POST requests to view

304 Not Modified. The requested resource is not modified, and the server does not return any resources when it returns this status code. Clients typically cache accessed resources by providing a header indicating that the client wants to return only resources that have been modified after a specified date

305 Use Proxy Uses Proxy. The requested resource must be accessed through a proxy

306 Unused INDICATES the Unused HTTP status code

307 Temporary Redirect Temporary redirection. Similar to 302. Use GET to request redirection

400 Bad Request The syntax of the client Request is incorrect and cannot be understood by the server

401 Unauthorized Requests require user authentication

402 Payment Required for future use

403 Forbidden The server understands the request from the client but rejects the request

404 Not Found The server could Not find the resource (web page) requested by the client. With this code, a web designer can set up a personalized page that says “the resource you requested could not be found.

405 Method Not Allowed The Method in the client request is prohibited

406 Not Acceptable The server was unable to complete the request based on the content nature of the client request

407 Proxy Authentication Required The request requires the identity of the Proxy, similar to that of the 401, but the requester should use the Proxy for authorization

408 Request time-out The server waits for the Request sent by the client for a long Time and times out

409 Conflict server may return this code after completing the client PUT request. A Conflict occurred when the server processed the request

410 Gone The resource requested by the client does not exist. 410 differs from 404 in that if a resource previously had a 410 code that is now permanently deleted, the site designer can specify a new location for the resource through the 301 code

411 Length Required The server cannot process requests without Content-Length sent by clients

412 Precondition Failed The client’s request information

413 Request Entity Too Large The server rejects the Request because the requested Entity is Too Large. To prevent continuous requests from clients, the server may close the connection. If the server is temporarily unable to process it, a retry-after response is included

414 Request-URI Too Large The URI of the Request is Too long (usually the URL), and the server cannot process it

415 Unsupported Media Type The server cannot process the Media format attached to the request. 416 Requested range not satisfiable: The Requested range was invalid

417 Expectation Failed The server cannot meet Expect’s request header information

500 Internal Server Error Indicates an Internal Server Error. The request cannot be completed

501 Not Implemented The request was Not supported by the server

502 Bad Gateway The server working as a Gateway or proxy received an invalid response from the remote server when attempting to execute the request

503 Service Unavailable The server cannot process requests from clients temporarily due to overload or system maintenance. The length of the delay can be included in the server’s retry-after header

504 Gateway time-out The server acting as a Gateway or proxy fails to obtain requests from the remote server in a timely manner

505 HTTP Version Not Supported The Server does not support the HTTP Version. 500 Internal Server Error

When you see this error, you should check the server log. It must have thrown a bunch of exceptions. Get up and fix the BUG.

Common HTTP response header attributes

Cache-Control

After the response is output to the client, the server tells the client how to control the cache of the response content through the header of the response.

Below, the Settings of the client response content cache for 3600 seconds, which is within 3600 seconds, if the customer again to access the resources, directly from the client cache returned to the customer, don’t again from the server (of course, the functions are implemented by the client, the server is only through this attribute prompt the client “should do”, do not do, It’s up to the client, if it’s a client that claims to support HTTP, that’s how it should be implemented).

Cache-Control: max-age=3600   
Copy the code

ETag

A header attribute that represents the version of the response server resource (such as a page). If a server resource changes, this ETag changes accordingly. It is a useful complement to cache-control, allowing clients to be “smarter” about when to fetch resources from the server and when to return a response directly from the Cache.

For an explanation of the ETag, you can see: en.wikipedia.org/wiki/HTTP\_… . Spring 3.0 it also provide a org. Springframework. Web. Filter. ShallowEtagHeaderFilter (the content of the principle is very simple, to the JSP output MD5, so content have change the ETag changes accordingly). The ETag used to generate the response, because this really helps reduce the interaction between the request and the response.

Here is an ETag:

ETag: "737060cd8c284d8af7ad3082f209582d"  
Copy the code

Location

In JSP, we Redirect the page to page A, which means that the client sends A request to page A. The URL of page A, which needs to be Redirect to, is actually informed to the client by the Location attribute of the response header. Will redirect client to itEye’s home page:

Location: http://www.it 
Copy the code

Set-Cookie

The server can set the Cookie of the client through this response header property:

Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1  
Copy the code

Four, HTTPS

When the Internet was born in 1990, data was transmitted using the hypertext transfer protocol HTTP, which is why web addresses now start with HTTP. However, HTTP protocol transmission data is plaintext transmission, any person can see the transmission of the packet, which is obviously not safe. In 1994, Netscape added HTTP to the encryption protocol, beginning to add SSL (Secure Socket Layer) to HTTP. It’s called “HTTP over SSL” or “HTTP Secure”, which we now know as HTTPS.

SSL/TLS

SSL/TLS is the session layer of TCP/IP layer 7, used to authenticate users and servers, encrypt and decrypt data, and maintain data integrity to ensure that data will not be modified during transmission.

TLS (Transport Layer Security) is a new protocol developed by THE IETF. TLS1.0 is based on THE SSL3.0 protocol specification and is the later version of SSL3.0, which can be understood as SSL3.1. The main purpose of TLS is to make SSL more secure and complete.

The TLS record format is the same as the SSL record format, but the version number value is different. Version 1.0 of TLS uses the version number SSLv3.1. SSL/TLS is classified into symmetric encryption and asymmetric encryption.

Symmetric encryption

Symmetric encryption means that both encryption and decryption use the same key. As shown below:

Asymmetric encryption

Asymmetric encryption corresponds to a pair of keys, called a private key and a public key. Encryption with the private key requires decryption with the public key, and encryption with the public key requires decryption with the private key. As shown below:

HTTPS Encryption Process

The figure above is a coarse-grained illustration of HTTPS’s asymmetric and symmetric encryption and decryption processes:

1. The client browser initiates the connection.

2. The WEB server sends the public key to the client.

3. The client generates a session key, encrypts the session key with the public key, and sends it to the server.

4. The server decrypts the session key with the private key.

5. The client and server use the Session key to communicate symmetrically.

The entire process can be abstracted in this way, but the actual session key generation is the result of multiple negotiations (as discussed later in this article), so let’s keep it simple for now. There is a problem with the whole process. What if the public key sent by the WEB server to the client in Step 2 is modified by the middleman? In other words, how can the client verify the correctness of the public key? That’s where digital signatures come in

A digital signature

As shown in the preceding figure, the public key content is followed by a digital signature, which is the ciphertext that encrypts the HASH of the public key content with the private key. After obtaining the public key, the client recomputes the public key using the same HASH algorithm to obtain the HASH value hash1. Then decrypt the digital signature with the public key to obtain the HASH value hash2. If hash1 equals hash2, the public key has not been modified by the middleman. Even if the middleman modifies the contents of the public key, he does not have a private key to regenerate the digital signature. When the user obtains the modified public key and calculates the HASH, an error will be reported.