HTTP things you may not know.

HTTP is a stateless protocol based on TCP/IP communication protocol to transfer data, and it is an object-oriented protocol belonging to the application layer. When it comes to application layer, refer to the content in “Computer Network”. I forgot to bring it with me when I didn’t read this book at home. I really regret that I didn’t master these fundamentals in university. (Mastering some basic knowledge is beneficial but not harmful, and computer knowledge is interlinked, not divided into a specific field, just like the book “Computer Basics”, although there is no important knowledge to master, but this is a benchmark to determine your level. TCP/IP network communication model is divided into four layers as follows:

HTTP is a set of protocols based on the application layer, which includes all the protocols that work with applications using the underlying network to exchange application-specific data (from Wikipedia), as listed in the table, for those who are interested. This article focuses on HTTP. The browser, as the HTTP client, sends a request to the WEB server through the URL. When the server receives a request from the client (browser), it returns a response message. This is a simple “request-reply” mode. I found some information and explained it like this:

• Protocols have no memory for transaction processing
• There is no context for the same URL request
• Each request is independent, its execution and results with the previous request and after the request is not directly related, it will not be directly affected by the previous request response, will not directly affect the back of the request response
• The server does not store the state of the client, and the client must bring its state to the server each time

Since HTTP is stateless, what does the keep-alive value mean? The purpose of keep-alive is to maintain a persistent connection between the client and the server. This is also to reduce request/response overhead and improve performance. However, this does not mean that HTTP is not stateless because of this parameter in the request header. And stateless means that at the application level the server doesn’t keep any information about the state of the client. Ok speaking of which, it’s time to play around with cookies and sessions, both of which are the medium through which the client communicates with the server. In short, cookies are the storage space on the client, maintained by the browser. It adopts the scheme of maintaining state on the client, while the session mechanism adopts the scheme of maintaining state on the server. In some cases, the state preserving scheme on the server also needs to store an identifier on the client, so the session mechanism may need to resort to the cookie mechanism to achieve the purpose of saving the identifier. (A recent project made me realize my narrow knowledge area, such as session/ HTTP knowledge, which I only knew before but didn’t have a deep understanding of. Personally, I think I still need to abandon the idea of not understanding very well in some professional fields. Sometimes, I will gain extra gains by digging into the corners.) Cookies and sessions can both save state and keep-alive connections, but, but, they do not change the stateless nature of HTTP itself, because these methods help the client and server to establish a better set of cooperative communication to improve communication and development efficiency.

HTTP transmits data and establishes connections through URIs. Uniform Resource Identifiers (URIs) are different from Uniform Resource Locator (urls), which are Uniform Resource identifiers. The relationship between the two can be understood as a URL is a specific type of URI, and a URL contains enough information to find a resource. Here’s an example of a random address:

http://www.google.com:7001/signContract?apptoken=jksldjflkdjslkfjds&contractId=110&orderId=911#user

From the URL we can see that the parameters in the URL contain the following items:

1. Part of agreement:HTTP:This means that the web page uses the HTTP protocol.//It is not recommended to mix HTTP and HTTPS links under the same domain nameMixed content, posing a threat to website security, specific aboutMixed contentWhen it comes to the safety knowledge of the WE end, interested students can go to know about it, I also accidentally asked this question by a friend to understand, more understanding is harmful.
2. Domain name part: The domain name of this address is”www.google.com“, a URL can also use IP address as a domain name, such as using this IP can also open Baidu home page (muck) :202.108.22.5As for why, interested students can go to knowDNS(Domain Name System).
3. Port:”7001“The domain name is followed by a colon (:) followed by the port, which can be omitted. If omitted, the browser’s default port is 80.
4. Directory path: from the first “/” starting from the port number to the last “/”, between which is the directory part, such as “signContract”.
5. Parameter part: From “? The part between “#” and “start” is the parameter. Multiple parameters are connected by “&”, in this case,”
   
   “apptoken=jksldjflkdjslkfjds&contractId=110&orderId=911“
6. Anchor: From “#” to the end of the anchor section, parameters can be omitted.

Without going into details about HTTP status codes, requests, and responses, I think it’s worth revisiting how HTTP works. First, the client sends a request packet to the server, which contains the request method, URL, protocol version, request header, and request data. The server responds with a status line, which contains the protocol version, success or error code, server information, response header, and response data. Here are the steps to respond to an HTTP request:

• The client connects to the Web server: usually from the browser address bar to create oneTCP socket connection, for example:”https://www.google.com/“
• Sending an HTTP request: The client sends a text request packet to the Web server through the TCP socket. A request packet consists of the request line, request header, blank line, and request data.
• The server accepts the request and returns the HTTP response: The Web server parses the request and locates the requested resource. Return to the client for reading.
• Release connection: ifconnectionforclose, the server actively closes the TCP connection, and the client passively closes the connection and releases the TCP connection. ifconnectionforKeep alive -, the connection will remain for a period of time.
• The client browser parses the HTML content: The client browser first parses the status line to see the status code indicating whether the request was successful. The response header is then parsed, which tells you the HTML document and its character set of several bytes. The client browser reads the response data HTML and renders it in the browser.

The above can be understood as a complete request and response process, which also involves DNS domain name resolution, TCP three-way handshake and other details, because this article focuses on HTTP will not be covered in detail (interested students can go to research). About HTTP related knowledge is I recently come into contact with, so to summarize to deepen their impression, if there is ambiguity in this paper still hope not stingy correct or incorrect, but if you want to return the HTTP whole understand far, read personal take on the bus last week, after all, a book illustration HTTP, think about really is to learning, Keep going and never stop! Keep going and never stop!

• Thank you very much to Wikipedia and the authors of the links below for your clarification.
• www.jianshu.com/p/80e25cb1d…
• www.cnblogs.com/bellkosmos/…