The seven-layer network model and TCP, UDP, what happens in an HTTP request

  [[267883]]

1. Seven-layer network model

The http protocol runs at the application layer

2. TCP-UDP

1. The difference between TCP and UDP protocols

2. What happens during an HTTP request?

3. How does the TCP protocol ensure reliable transmission?

4. Differences between HTTP and HTTPS

5. TCP three-way handshake and four-way wave,

6. Common status codes.

2.1 TCP-UDP Differences

• UDP and UDP usage scenarios

There is no need to establish a connection before transmitting data, and data can be sent directly to the target machine. After receiving the UDP message, the remote host does not need to give any confirmation. UDP messages may be lost, but UDP works very efficiently in scenarios such as video streaming and live streaming (instant communication, no concern for data loss, and security) such as video and live streaming.

• TCP and TCP usage scenarios

Connection-oriented service. Connect first and then transmit data. After the data transmission is completed, the connection must be released. TCP does not provide broadcast or multicast services. Since TCP needs to provide reliable, connection-oriented transport services (TCP's reliability is reflected in the three-way handshake to establish a connection before transmitting data, and during data transmission, there are confirmation, window, retransmission, and congestion control mechanisms. After the data is transmitted, the connection will be disconnected to save system resources), this inevitably adds a lot of overhead, such as confirmation, flow control, timer, and connection management. This not only makes the header of the protocol data unit much larger, but also takes up a lot of processor resources. TCP is generally used in scenarios such as file transfer, sending and receiving emails, and remote login. (Data transmission where information security is relatively important).

2.2 What happens in an HTTP request?

1. The user enters the URL in the browser

2. The browser gets the URL to request the IP

3. Send a TCP connection 3-way handshake to the target IP

4. The server parses the request and returns the processed HTML page (string)

5. The browser parses and renders the screen according to the rules

6. Connection Ended

*** point: None

Second point: The order of the browser parsing the URL entered by the user is:

First check whether there is a corresponding IP address locally, and return it if found. If not found, request the next-level DNS server until it finds the root node.

Browser cache --> System cache --> Router cache --> ISP DNS cache --> Recursive search from root domain name servers

If none is found, an error is returned

The third point: three-way handshake

First handshake: The sender first sends a data packet with a SYN (synchronize) flag to the server, and waits for a response within a certain period of time.

Second handshake: After the server receives the SYN packet, it returns a packet with a SYN/ACK (acknowledgement charactor) confirmation character flag to indicate confirmation of receipt of the message.

The third handshake: After the receiver receives the confirmation message from the server, it sends a data packet with an ACK mark to the receiver, indicating that the handshake is successful

Note: There is a waiting time in the above process. If the server or client does not respond within the waiting time, the request is considered failed and the request is made again. The reason why the server did not respond may be that the stack is full.

• After the connection is successfully established, the browser sends an HTTP request to the WEB server

The role of the three-way handshake:

• The purpose is to establish a reliable communication channel. When it comes to communication, it is simply the sending and receiving of data. The main purpose of the three-way handshake is for both parties to confirm that the sending and receiving of themselves and the other party are normal.

1. First handshake: Client cannot confirm anything; Server confirms that the other party is sending normally
2. Second handshake: The client confirms that its own sending and receiving are normal, and the other party's sending and receiving are normal; the server confirms that its own receiving is normal, and the other party's sending is normal
3. The third handshake: The client confirms that its own sending and receiving are normal, and the other party's sending and receiving are normal; the server confirms that its own sending and receiving are normal, and the other party's sending and receiving are normal

• The server returns the SYN sent by the sender to tell the sender that the received information is indeed the signal you sent.
• The communication between the two parties must be correct if both parties send information to each other correctly. The SYN signal proves that there is no problem with the channel from the sender to the server, and the channel from the server to the sender is verified by the ACK signal.

Step 4: ngimx + uwsgi (Django) as a column (unfinished)

1. Nginx part (unfinished)

2.Django part:

• According to the requested URL, we come to Django's routing relationship mapping.
• Then verify through a series of Middleware (process_request(request,)) such as CSRF IP blacklist filtering, crawler filtering and other middleware
• Go to the Views view function corresponding to the URL. According to the request content, go to the database and Templates to get the data back for rendering and return the response result.
• The response is verified again through a series of middleware. (process_response(request, response)) *** returned to the Client

Step 5: Browser Rendering

The browser gets the result and renders it according to HTML CSS JS

Step 6: Wave four times to disconnect

• Client-sends a FIN to close the data transmission from the client to the server
• The server receives this FIN and sends back an ACK, confirming that the sequence number is the received sequence number plus 1. Like SYN, a FIN will occupy a sequence number
• Server-closes the connection with the client and sends a FIN to the client
• Client-sends an ACK message to confirm, and sets the confirmation number to the received number plus 1