get请求方式参数一直跟在后面，为什么出现了post请求方式

http0.9只有get请求，你看这样多简单，想发送什么数据，就把数据添加到url的后面，

很多人说安全性？安全影响什么了？数据暴露，即便是约定好的数据，写在那里，你说不定也不明白参数的意义，倒是安全性并非是主要原因

什么？丑陋？拖着冗长的链接，看着倒是确实不舒服，那么到底是什么主要的原因呢？难道就因为丑陋？

 

http1.0增加了post，

所谓get请求，即能将参数添加到我们的general header，我们的请求和响应headers，大家双方都有个general header，然而，url过分的长，是的响应报文和general header内部也增加了url参数

这其实完全没有必要，试想发展之初，带宽还没有现在那么大，受限于硬件性能，这样的一次请求，加一次响应，假如url的链接十分的长，长到什么程度？general header的大小 占了几乎整个请求报文的100%不到，当然，你说完全占领，这在数学上，是逼近极限的，但就请理解为几乎占领

 

这样一算的话，一来一去，一次请求加一次响应，这样所占据的带宽，是一次请求的2倍，啥意思？没什么关系？

那么如果我们的请求数量增加20次，假设我们手上的设备带宽，仅仅提供20个这样大小的请求，那么这样的响应，给用户是一种什么样的效果？当然是阻塞了，所有的请求头中的general header都将我们的带宽给占据了，响应就没了，所有的网页都卡在那里转圈圈，我想这样的画面，你是能够想象的把？

 

post的好处

既然增加了post请求，参数可以放在request body里面，这样的话，我们的response返回来，仅仅包含了响应头部，以及响应主体，response header 和response body，

response body里面，存放了请求所需要的响应信息，例如成功标志，以及返回消息等，而response响应中的general header里面，是不包含request body，这样比起公共的url，后面增加了一大摞参数，这样，明显的节省了带宽了吧！

 

为什么要节省带宽？

我们的硬件性能是不断的提升的，但是我们的需求也是日益增长的，同样的，一台电脑可以打开50个网页，和100个网页，这样的体验，是截然不同的吧？!