the difference:
There is also the number of request packets: get is 1 httpheader+data, post is two, http header first, then data
In my big World Wide Web world, TCP is like a car. We use TCP to transport data. It is very reliable and there is never a phenomenon of missing or missing items. But if there are all cars that look exactly the same on the road, then the world looks like a mess. The cars delivering urgent items may be blocked on the road by cars full of cargo in front, and the entire transportation system will definitely be paralyzed. To avoid this, the traffic rule HTTP was born. HTTP sets several service categories for automobile transportation, such as GET, POST, PUT, DELETE, etc. HTTP stipulates that when a GET request is executed, the car should be labeled as GET (set method to GET) and require Put the transmitted data on the roof (in the url) for easy recording. If it is a POST request, a POST label must be attached to the car and the goods should be placed in the compartment. Of course, you can also secretly hide some goods in the carriage during GET, but this is very shameful; you can also put some data on the roof during POST, which makes people feel silly. HTTP is just a code of conduct, and TCP is the basis of how GET and POST are implemented.
In my big World Wide Web, there is another important role: transportation company. Different browsers (initiating http requests) and servers (receiving http requests) are different transportation companies. Although in theory, you can pile up unlimited goods on the roof of the car (unlimited parameters in the URL). But the transportation company is not stupid. Loading and unloading are also very costly. They will limit the single transportation volume to control the risk. The large amount of data is a great burden on the browser and server. The unwritten rule in the industry is that (most) browsers usually limit URL length to 2K bytes, while (most) servers handle up to 64K URLs. The excess part will not be processed. If you use the GET service and you secretly hide data in the request body, the processing methods of different servers are also different. Some servers will help you unload and read the data, and some servers will ignore it directly. Therefore, although GET can carry request body, it cannot It is guaranteed to be received.
There is another major difference between GET and POST. Simply put:
GET generates one TCP data packet; POST generates two TCP data packets.
Long said:
For GET requests, the browser will send the http header and data together, and the server will respond with 200 (return data);
For POST, the browser first sends the header, the server responds with 100 continue, the browser then sends data, and the server responds with 200 ok (return data).
In other words, GET requires only one car run to deliver the goods, while POST has to run two times. The first one is to say hello to the server, "Hey, I will send a batch of goods later, you open The door greeted me", and then returned to deliver the goods.
Because POST requires two steps and consumes a little more time, it seems that GET is more effective than POST. Therefore, the Yahoo team recommends replacing POST with GET to optimize website performance. But this is a pit! Be cautious when jumping in. why?
-
GET and POST have their own semantics and cannot be mixed casually.
-
According to research, when the network environment is good, the difference between the time to send a packet and the time to send two packets can basically be ignored. In the case of poor network environment, two-packet TCP has great advantages in verifying the integrity of data packets.
-
Not all browsers send a packet twice in POST, Firefox only sends it once.
Reference from: https://www.w3school.com.cn/tags/html_ref_httpmethods.asp
https://mp.weixin.qq.com/s?__biz=MzI3NzIzMzg3Mw==&mid=100000054&idx=1&sn=71f6c214f3833d9ca20b9f7dcd9d33e4#rd