The get and post of HTTP protocol

The next chapter is about jquery's transmission data, so just hit get and post, tell me what I've always understood about them.

Purely from the HTTP protocol, the HTTP protocol regulates them: one for fetching data, one for modifying data, and just for a protocol specification.

Essentially, the bottom layer of HTTP is TCP/IP. So the bottom layer of get and post is TCP/IP, that is to say, get/post are all TCP links. The things that get and post can do are the same. You have to add the request body to get the post with the URL parameter, technically it is completely OK.
Does that mean you've wiped out all your old ideas?
The so-called "previous view" is actually an inherent thought that Web developers develop in the long term Web: Get uses a URL or cookie to pass the argument. And post puts the data in the body. The URL of get has a length limit, then the post data can be very large. Post is safer than get because the data is not visible on the address bar. For the data type of the parameter, get only accepts ASCII characters, and post has no limit. The GET request will be actively cache by the browser, and post will not, unless manually set. The URL address generated by Get can be bookmark, and post cannot.

To tell you the truth, I used to develop the web is that, in fact, this is just a web developer in practice because of various external conditions such as (browser, server) and so on the habit, indeed, in the web development does have to follow this thinking to develop, otherwise there will be a series of problems. So these 7 are actually some of the conventions that Web development HTML adds to the HTTP protocol.
A case of Daniel:

In my world of great World Wide Web, TCP is like a car, we use TCP to transport data, it is very reliable, and never lose a few pieces of the phenomenon. But if the road is full of seemingly identical cars, the world seems to be a mess, the dispatch of the car may be in front of the full cargo of the car blocked on the road, the entire traffic system will be paralyzed. In order to avoid this happening, the traffic rules HTTP was born. HTTP sets a number of service categories for vehicle transport, such as GET, POST, put, delete, and so on, HTTP provides that when executing a GET request, the car is labeled (set method to get), and the transmitted data is placed on top of the car (URL) To facilitate recording. If it is a POST request, put the post label on the car and place the goods in the carriage. Of course, you can secretly hide some goods in the carriage while getting, but it is very disgraceful, or you can put some data on the roof of the car when you post it, people feel silly. HTTP is just a code of conduct, and TCP is the basics of how get and post are implemented.

However, we only see HTTP's request for a transfer channel (URL or requrest body) for Get and post parameters. Where does the restriction on parameter size come from in the standard answer?

There is another important role in my world of the Web: transportation companies. Different browsers (initiating HTTP requests) and servers (accepting HTTP requests) are different shipping companies. Although theoretically, you can have unlimited stack of goods on the top of the car (unlimited parameters in the URL). But transport companies are not stupid, loading and unloading also have a lot of cost, they will limit the single traffic to control the risk, the amount of data is too large for browsers and servers are a big burden. The industry's unwritten rule is that (most) browsers typically limit URL lengths to 2K bytes, while (most) servers handle up to 64K-sized URLs. More than the part that is not handled. If you use Get service, in request body secretly hidden data, different server processing way is also different, some servers will help you unload, read out data, some servers directly ignore, so, although got can bring request body, also can not guarantee to be received OH.
Okay, now you know that get and post are essentially TCP links, and there's no difference. However, due to the HTTP requirements and browser/server restrictions, they are in the application process to reflect some differences.

So now you can understand what web developers think of these ideas, though they're right, but they can't be said to be the difference between get and post in the HTTP protocol, just a convention for web developers.
In addition, say the difference outside the web.

Get generates a TCP packet; Post generates two TCP packets.
Long to say:
For a Get-mode request, the browser sends the HTTP header and data one concurrent, and the server responds 200 (returns data);
And for post, browser first send header, server response continue, browser again send data, server response OK (return data).
In other words, get only need a car to run a trip to deliver the goods, and the post has to run two times, first, and the server to say hello "Hi, I will send a batch of goods, you open the door to greet me," and then back to send the goods to the past.
Because the post takes two steps and consumes a little more time, it looks like get is more efficient than post. So the Yahoo team recommends using get to replace post to optimize site performance. But this is a pit! Jump should be cautious. Why?
1. Get and post both have their own semantics, can not be arbitrarily mixed.
2. According to research, in a good network environment, the time to send a packet and two times the time difference between packets can be ignored. In the case of poor network environment, TCP with two packets has great advantages in verifying the integrity of packets.
3. Not all browsers will send two packets in post, Firefox will only send one time.

Reference: http://www.techweb.com.cn/network/system/2016-10-11/2407736.shtml