TCP/IP and HTTP knowledge is too confused, there are some blind spots, so I sorted out the relevant knowledge points.
TCP/IP protocol
TCP/IP protocol model:
Peer transmission:
TCP three handshakes four waves
Note: SYN: synchronize sequence number; Seq: send sequence number; ACK: confirmation character
Three-way handshake process:
One-handshake: The client sends a request packet to the server. SYN is 1, Seq is X, and SYN_SEND is entered
Two-handshake: the service sends ACK: x+1, SYN: 1, Seq: Y to receive a request packet. SYN_RECV is then entered
Three-way handshake: Seq+ACK packets are sent to the server. After the packet is sent, both the client and the server enter the ESTABLISHED state to complete the TCP three-way handshake.
Why the third handshake?
The third handshake could theoretically be omitted entirely, and the connection should be established at the second handshake when the server asks if the client is ready. So why is there a third handshake?
An error occurs in case an invalid connection request segment is suddenly sent to the server. The main reason for this is that the client’s first handshake request is delayed in some cases until the connection is released. If only two handshakes are used, then the connection is established, but the connection is never used or released, and a lot of resources of the server are wasted.
Second wave: Host 2 receives the FIN segment from host 1 and sends an ACK segment back to Host 1. This Acknowledgment Number is set to Sequence Number plus 1. Host 1 enters the FIN_WAIT_2 state. Host 2 tells host 1 that I “agree” to your shutdown request;
Third wave: Host 2 sends a FIN packet to host 1 to close the connection, and host 2 enters the LAST_ACK state.
Fourth wave: Host 1 receives the FIN packet from host 2 and sends an ACK packet to host 2. Then host 1 enters the TIME_WAIT state. Host 2 closes the connection after receiving the ACK packet from host 1. If host 1 does not receive a reply after waiting for 2MSL, then the Server is shut down.
Why do you wave four times?
TCP is a connection-oriented, reliable, byte stream – based transport-layer communication protocol. TCP is in full-duplex mode. When host 1 sends a FIN packet, it only indicates that host 1 has no data to send. Host 1 tells host 2 that all data has been sent. However, at this point, host 1 can still accept data from host 2; When host 2 returns an ACK packet, it indicates that it knows that host 1 has no data to send, but host 2 can send data to host 1. When host 2 also sends a FIN packet segment, host 2 also has no data to send, and tells host 1 that it has no data to send, and both parties happily break the TCP connection.
Simple HTTP protocol
The request line
The Request line is divided into three parts: Request method, Request address, and protocol version
Request header
- No-cache Indicates that the client does not cache expired resources
- No-store indicates that no cache is performed
- Max-age indicates that the cache duration of the resource is smaller than the specified value. The client accepts the cache resource and the cache server does not confirm the validity of the resource
- Close indicates that the server is explicitly disconnected
- Keep-alive indicates to save the persistent connection. Before HTTP/1.1, the default connection is non-persistent. You need to add this field if you want to save the persistent connection
Request body
The difference between Post and Get
Let’s start with side effects and idempotence.
Side effects refer to changes made to resources on the server. Searching has no side effects, while registration has side effects.
Idempotent means that M and N requests (different and both greater than 1) are sent, and the state of the resources on the server is consistent. Registering 10 and 11 accounts is not idempotent, making 10 and 11 changes to articles is idempotent.
In standard application scenarios, Get is mostly used in idempotent scenarios with no side effects, such as searching for keywords. Post is mostly used in side-effect, non-idempotent scenarios, such as registrations.
Technically speaking:
- Get requests can be cached, but Post requests cannot
- Post is a little more secure than Get, because Get requests are contained in the URL and will be saved by the browser. Post is not, but in the case of packet capture, it is the same.
- Post can use the Request Body to transfer more data than Get, which doesn’t have this technology
- Urls have a length limit that affects Get requests, but this length limit is browser-specific, not RFC specific
- Post supports more encoding types and does not restrict data types
Reference documentation
Juejin. Cn/post / 684490…
Juejin. Cn/post / 684490…