Talking about the HTTP protocol package

We know that the http package is mainly divided into three parts:

1. Request line

Request methods, GET and POST are the most common HTTP methods, in addition to DELETE, HEAD, OPTIONS, PUT, TRACE.
The URL address, which forms the complete request URL with the Host attribute of the message header.
Agreement name and version number.

2. The request header (hearder)

Accept: Specify the type of content that the client can receive, which can be text, image, or video type.
Accept-Encoding: Specify the data format supported by the browser, including gzip, br, etc.
Accept-Language: execute the receiving language, basically en, zh
Accept-Charset: Specify the encoding, generally utf-8
Content-Length: requested content length
Cookie: Used to store some user information so that the server can identify the user's identity (most common websites that need to log in). For example, a cookie will store the user name and password of some users. When the user logs in, it will generate one on the client Cookies are used to store relevant information, so that the browser will determine that you are a legitimate user after reading the cookie information to verify on the server, and allow you to view the corresponding web page.
Host: Specify the domain name and port number of the requested server
Origin: request source
Referer: Refers to the specific web page request from the request source
User-Agent: Tell the HTTP server, the name and version of the operating system and browser used by the client, and the content contains the information of the user who made the request.
Connection: indicates the connection status. Generally, if you open a page, but you want to transmit data, such as playing video, etc., you must keep the tcp connection unclosed, so keep-alive (long connection) is used. The short connection close was used before.
Sec-Fetch-Dest: indicates the destination of the request, that is, how to use the acquired data;

Sec-Fetch-Mode：

cors：跨域请求；XMLHttpRequest 或 Fetch 支持跨源请求。
no-cors：并不是代表请求不跨域，而是服务端不设置cors响应头，图片/脚本/样式表这些请求是容许跨域且不用设置跨域响应头的情况使用。
same-origin：同源请求， 表示不跨境，跟cors跟no-cors不一样，cors跟no-cors是要求服务端设置。
navigate：表示这是一个浏览器的页面切换请求(request)。 navigate请求仅在浏览器切换页面时创建，该请求应该返回HTML；
websocket：建立websocket连接；

Sec-Fetch-Site：

cross-site：跨域请求；
same-origin：发起和目标站点源完全一致；
same-site：有几种判定情况，详见说明；
none：如果用户直接触发页面导航，例如在浏览器地址栏中输入地址，点击书签跳转等，就会设置none；

3. Response line

Agreement name and version number

Status code and description

1**	信息，服务器收到请求，需要请求者继续执行操作
2**	成功，操作被成功接收并处理
3**	重定向，需要进一步的操作以完成请求
4**	客户端错误，请求包含语法错误或无法完成请求
5**	服务器错误，服务器在处理请求的过程中发生了错误
200 - 请求成功
301 - 资源（网页等）被永久转移到其它URL
404 - 请求的资源（网页等）不存在
500 - 内部服务器错误

4. Response header

Access-Control-Allow-Credentials: Set to true, which means that the server clearly allows the cookie to be included in the request and sent to the server together. Indicates whether the credential can be used to make the actual request.
Access-Control-Expose-Headers：
Access-Control-Allow-Methods: Request method
Access-Control-Allow-Origin: For requests that do not require credentials, the server will use "*" as a wildcard to allow all domains to have access to resources.
```
如需允许所有资源都可以访问您的资源，您可以如此设置：
Access-Control-Allow-Origin: *
如需允许https://developer.mozilla.org访问您的资源，您可以设置：
Access-Control-Allow-Origin: https://developer.mozilla.org
```
- Content-Length: The size in bytes returned
- Age: The message header contains the length of time the object is stored in the cache agent
- Date: time
- Set-Cookie: Set the cookie associated with the page, and send the cookie information to the client again

Cookie

Because the HTTP protocol is stateless, that is, the server does not know what the user did last time, which severely hinders the implementation of interactive Web applications. In a typical online shopping scenario, a user browses several pages and buys a box of biscuits and two bottles of drinks. At the final checkout, due to the stateless nature of HTTP, the server does not know what the user bought without additional means, so cookies are one of the "extra methods" used to circumvent the statelessness of HTTP. The server can set or read the information contained in Cookies to maintain the state of the user in the conversation with the server.

In the shopping scene just now, when the user purchases the first item, the server sends a cookie to the user while sending the web page to the user, recording the information of that item. When the user visits another page, the browser will send the Cookie to the server, so the server knows what he bought before. The user continues to buy drinks, and the server adds new product information to the original cookie. At checkout, the server can read the cookie sent.

Another typical application of cookies is when logging in to a website, the website often asks the user to enter a user name and password, and the user can check "Automatically log in next time". If checked, the next time the user visits the same website, the user will find that he has logged in without entering the user name and password. This is because the server sent a cookie containing login credentials (an encrypted form of user name and password) to the user's hard disk during the previous login. When logging in for the second time, if the cookie has not expired, the browser will send the cookie and the server verifies the credentials, so the user can log in without entering the user name and password.

session

But the problem is that we also know that many of the current website functions are complex and involve a lot of data interaction. For example, the shopping cart function of an e-commerce website has a large amount of information and a complex structure, which cannot be transmitted through a simple cookie mechanism. More information, and you must know that the cookie field is stored in the HTTP header. Even if it can carry this information, it will consume a lot of bandwidth and consume network resources.
Session can work with cookies to solve this problem. For example, a cookie stores such a variable sessionID=xxxx, and only passes this cookie to the server, and then the server finds the corresponding session through this ID. This session is a data structure in which it stores With detailed information such as the user's shopping cart, the server can use the information to return the user's customized webpage, effectively solving the problem of tracking the user.
A session is a data structure designed by the website developer, so it can carry various data. As long as a unique session ID is passed from the client's cookie, the server can find the corresponding session and recognize the client.
Of course, because the session is stored in the server, it will definitely consume server resources, so the session generally has an expiration time. The server generally checks and deletes the expired session periodically. If the user accesses the server again later, he may face re-login. Wait for measures, and then the server creates a new session and transmits the session ID to the client in the form of a cookie.