Replenish:
- The so-called reverse proxy of Nginx actually just establishes a Socket B connection with the back-end server and generates a Socket object. Socket is an object that can communicate with the operating system, and the operating system is responsible for sending data;
- For HTTP protocol requests, Nginx will also establish a Socket A connection with the browser. After the connection is established, it will receive the request sent by the browser, and then send the message sent by the browser to the backend server through Socket B. The process has only one time. After sending, it only waits for the data from the backend in the onMessage function of Socket B. Once the backend server sends the end character \r\n\r\n, Nginx will These requests are Closed. Therefore, the HTTP protocol cannot support two-way communication.
- For the Websocket protocol, Socket A and B will be kept for a long time, and at the same time, onMessage will not initiate a close when no close message is received, so that full-duplex communication can be performed under the Websocket protocol.
- As for whether the asynchronous framework is necessarily related to Websocket? It can be speculated that there should be no necessary relationship. If Nginx and Django, Django is a synchronization framework, as long as Django can send return messages according to the Websocket protocol, it can support two-way interaction
Http/Websocket are both called a protocol. Can you use real-life examples to explain the protocol?
AI example:
You (the client): You are sitting at a restaurant table and want to order a menu.
Waiter (Server): A waiter stands next to you, ready to take your order.
Ordering (HTTP request): You hand the waiter a menu listing the items you want to order. (The menu and your order are the content of the agreement)
Waiting (waiting for response): The waiter goes to the kitchen with the menu and waits for the chef to prepare the food.
Serving (HTTP response): The chef prepares your order and the waiter brings the food to your table.
The purpose of the above example is to communicate between you and the restaurant. This communication must be within the restaurant's menu. In the same way, the browser must interact with the server. There are thousands of browsers. You cannot ask someone to fry beans for you. When you make fried beans and fry them, you say they are not the beans you want. How can you explain this clearly? Therefore, fried beans, how mature they are, with or without meat, spicy or not, numb or not, are all checked on the menu. If the other party does not have beans at all, you cannot order fried beans. This menu is for you. Agreement with the restaurant.
What specific protocols does Http have?
Request: The client sends a request to the server to request specific resources or perform specific operations.
- Request line: Includes HTTP method (GET, POST, etc.), requested URL, and protocol version.
- Request header: Contains additional information about the request, such as user agent, host name, etc.
- Request body: In a POST request, submitted data may be included.
Response: The server returns a response to the client, containing the requested results or error information.
- Status line: includes protocol version, status code and status message.
- Response header: Contains additional information about the response, such as server type, content type, etc.
- Response body: Contains the data returned by the server.
HTTP Methods: Define the operation type requested by the client. Common ones include GET, POST, PUT, DELETE, etc.
Status Codes: Three-digit code returned by the server, indicating the processing result of the request. For example, 200 means success, 404 means resource not found, 500 means internal server error, etc.
Request Headers and Response Headers: Contain various metadata to provide additional information about the request or response.
URL (Uniform Resource Locator): Specifies the address of a resource on the Web. URL includes protocol, domain name, port, path, etc.
Cookie and Session: Used to track user session state between client and server.
Cache Control (Caching): Control data caching between the client and server to improve performance.
Content Negotiation: The client and server negotiate the most suitable content format, such as requesting JSON or XML.
Security: HTTP can achieve secure transmission through HTTPS (based on SSL/TLS encryption).
Redirection: The server may redirect requests to other URLs. Common ones are 301 permanent redirection and 302 temporary redirection.
Authentication: HTTP can perform user authentication through Basic Auth, Bearer Token and other methods.
Cross-domain resource sharing (CORS): used for data exchange between different domains, involving security mechanisms.
A screenshot of an Ajax request
We can see that the request can carry many protocol keys, and each protocol key has a corresponding value. Here we choose Content-Type: application/json, which means that the browser passes a json string, and the server gets it After arriving, it is processed in json format. In the same way, I can also pass urlencode form, pure text/plain text form, or even binary stream. What is a stream explained here?
Usually, when we see water flow, we mainly think that it is soft, pervasive, and continuous, but if you look at it with an electron microscope, it is composed of grains of water molecules. Let’s zoom in and regard them as grains of sand. If you zoom out, quicksand is the same as water flow. This is fluid, composed of discontinuous particles.
Binary stream also means the same thing. One bit is transmitted at a time, but it is sent out continuously and quickly. When connected, it looks like current is running. This is a binary stream.
Having said all this, I just want to tell you that a stream is a bit, which is emitted by a transmitter. Because it is emitted very fast, it looks like a continuous current.
All streams at the bottom are processed in this way, but the granularity is different. For example, character streams are processed one character at a time, and each character is composed of multiple bits.
Customize some protocols
If you understand that the protocol is some secret codes agreed by both ends (people or things), then these secret codes can also be agreed on the server side, for example, add a Token key to the request, and this key must carry a value for Authentication, as long as the server is allowed to receive the Token, the browser can pass the Token over.
Why does it say the server allows it? Like the TV series you watched, when a person enters the city gate, he must first verify his identity. If you are not on the list, such as a barbarian, you will not be allowed in, so you must have the permission of the server before the Token can enter. . Therefore, if the browser wants to send a special protocol header, it must ask the server for instructions. This request is called OPTION. Many people know about POST/GET, but not many OPTIONs. This point is that I want to inspire everyone that programming comes from reality. If you have more experience, you can rely on recalling reality to speculate on the technology in programming. Programming will also encounter problems that exist in reality, so your learning becomes proactive. Yes.
So much talk is to explain that Http is a collective name for a bunch of protocol ciphers. So many ciphers (we call them logos) and the value of the ciphers are aggregated and sent to the server. After receiving it, the server calls this transmission as A request is like another order received by the chef in the kitchen.
Why haven’t we talked about connections yet?
We need to zoom in on this example, so that you can understand what a connection is, and you can also know that a connection is neither long nor short, and there is no link. This will break your conventional understanding. In fact, this is the real operation of the computer. Way.
Connection is the process of sending a courier with one trip and one return. The couriers who send the goods are not the same person.
Let’s put aside the three handshakes first and go straight to the completion of the handshake. What happens after that? Look at the picture:
We have created an XMLHttpRequest object on the browser side, and a similar XMLHttpRequest object will be created on the server side. What is recorded in this object?
In the Swoole document , getclientinfo returns an object. This object is the information stored by the server XMLHttpRequest. It is this information that records the client's IP and client port;
A little confused? Why does the server still record the client's port number? The port number is not unique to the server? Sometimes programmers can't see the full picture of a program because programs are virtual and don't exist for you unless someone tells you or you discover them yourself.
Back to the concept of express delivery:
You are in a building, and if you want to send something to someone else, the receiver will record your house number at the same time, otherwise you will not be able to receive the letter sent back to you by the server (ordinarily, our express delivery is one-way) ), so the package you send to the server must have your address and the building you live in. This client object has the ability to send the data given to it to its client. It also registers itself with the operating system, and the operating system will assign a port number to it. After the port receives the message (sent from the server), the operating system will forward the information to its onsucess function , forming a message request and callback.
At this point, do you think there is a difference between long and short connections? Do you think connection is still a concept of continuity?
Client-side XMLHttpRequest
The client's XMLHttpRequest also records the server's information. If there is no server shutdown or network interruption (this is detected by the server and notified to XMLHttpRequest), the XMLHttpRequest will not disappear and will remain in the memory.
This is the part of your programming. You create a new XMLHttpRequest. After the XMLHttpRequest three-way handshake, it is confirmed that the remote server exists normally and someone has been arranged to help you handle the matter. You can then happily send messages to the server. .
But the courier station assigns you a courier boy only once. After you send a package using XMLHttpRequest, and at the same time another courier boy brings the server package to you, he will say goodbye to you. You can think about it next time. To send a message, you have to place an order with the courier station and ask the guy to come and pick up the package.
This is how the remote server responds to Http requests. As long as it is an Http request, as long as the data is returned to you, it will say goodbye to you. We will talk about it next time if something happens. This is especially like when you go to the government affairs hall to do things, you only do one thing at a time. , finished over.
Early HTTP 1.0
There is no concept of express delivery station, why? There are fewer people using it. If you want to send something, just build a courier station yourself, and then give the thing to the courier guy to deliver it and bring it over.
As your business volume increases, you feel that you can't bear it. Every time you are asked to build a courier station, you get angry just thinking about it, so you gather a group of requests to build a courier station.
HTTP1.1
If you just want to build a courier station, you don’t need to change the version of HTTP 1.0, because HTTP is just a protocol. In order to pull the protocol down, if you don’t change the protocol, who will work hard to rebuild the courier station for you? You can make do with it, this is actually a kind of mapping of the real world, since it needs to be refurbished, there must be a header, this header is HTTP1.0 Some protocols can’t meet my needs, because I want to build a express station, so I need a new shipping method. Two seemingly unrelated things were integrated, so by changing the name of the HTTP protocol, the transport layer was changed.
It has been changed to a courier station with Yuantong, Zhongtong, and Guotong. Every time you want to send a package, you have to find a courier with a small queue to assign you a courier to pick up the package, deliver the package, and return the service to you. I'll give you the returned package.
This is the famous tcp/ip multiplexing technology in HTTP1.1. The express delivery station is built first, and then the parcel delivery is handed over to the less busy station. This is the concept of connection pool.
But a new problem comes again
I still have too many requests. I want to send 100 packages at once, and the business volume is huge. A courier brother must send 100 packages to the server at one time, and then have to report the results of these 100 packages. They are all brought back in order. Once they are mixed up, I can't tell which one is right.
At this time, you have been waiting for a long time before the courier boy brought you the return information of 100 packages. Occasionally, some packages will be lost, and you have to resend them. This is unbearable for you, so you ask for service. If the client continues to upgrade, it cannot be delivered in this way and needs to be changed.
HTTP2.0
I can send it however I want, when I want it, and to whomever I want it to be sent. The courier guy will put a mark on each package for me, and he will also bring this mark with him when he returns. In this way As soon as you come in and out, you will be able to match the number.
So you can send it in various ways. Of course, we can't do this alone, we have to change the protocol to cause trouble, so the HTTP protocol was upgraded again.
The above is the history of the development of HTTP.
The origin of the Websocket protocol
HTTP has always sent once, returned once, and placed an order for the next delivery. I have to fill in the form every time I place an order. It's disgusting. Can you only let me fill it out once, and then let me and the server send a guy directly? What about delivering our letters?
Of course it is possible, the solution is proposed by the server, you first use Http request to send me a message, and then add an Upgrade upgrade tag in it, after I receive it, I will arrange a dedicated brother to send you a letter, only You don't need to fill out the form.
When you hear it, you think it’s great, and then you tell the server, if we don’t communicate with Http, how can we tell you some news, for example, I want to say goodbye to you, or I confiscated some packages, you still I have to repeat it, or I say that the bag you sent me is too big, etc.
So the server said, let's create another protocol to specifically solve the problems you mentioned. How about we call it Websocket?
You say happily: "Great, so the Websocket protocol was born!"