GET 和 POST 的区别 以及为何 GET请求 比 POST请求 更快

引子： 和朋友的聊天中得知他公司后台接口所有都是 POST 请求， 我表示很纳闷为何全是 POST 请求呢？

GET 比 POST 安全，或者说 便于后台方便，后台不用区分包装类  （因此所有用 POST 请求）?

相对来讲是POST更安全些，可是后台全部接口都是带敏感性的么？ 好比静态数据（数据字典、省市区、类型之类的）这时候也要 post ？

带敏感性的请求POST彻底是应该的，但普通请求（大多数获取数据请求）都应该往GET请求看齐，由于GET请求对于浏览器来讲减轻了其压力、并且请求比POST快，提高页面数据响应、渲染速度；

先看看他们区别再看从哪些方面说明为何GET更快？还有快多少呢：

区别：

分类	GET	POST	对比
后退按钮/刷新	无害	数据会被从新提交（浏览器应该告知用户数据会被从新提交）。	每次都从新提交这无疑会对浏览器形成压力，该问题也是做为web端性能优化的重要方向之一
缓存	能被缓存	不能缓存	缓存能够为浏览器减小请求链数，web端性能优化的重要方向之一
历史	参数保留在浏览器历史中。	参数不会保存在浏览器历史中。	至关于缓存，可减小浏览器压力
对数据长度的限制	是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。	无限制。	HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大可能是浏览器和服务器的缘由。 服务器是由于处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制
安全性	与 POST 相比，GET 的安全性较差，由于所发送的数据是 URL 的一部分。在发送密码或其余敏感信息时毫不要使用 GET ！	POST 比 GET 更安全，由于参数不会被保存在浏览器历史或 web 服务器日志中。	从传输的角度来讲，他们都是不安全的，由于 HTTP 在网络上是明文传输的，浏览器F12下什么都一目了然，或者抓个包，就能完整地获取数据报文。 要想安全传输，Encode(转码)固然对于懂的人来讲也不安全； 比较安全的只有加密，也就是 HTTPS
对数据类型的限制	只容许 ASCII 字符。	没有限制。也容许二进制数据。	POST选择更多

 快的缘由：

1.post请求包含更多的请求头

　　由于post须要在请求的body部分包含数据，因此会多了几个数据描述部分的首部字段（如content-type），这实际上是微乎其微的

2.最重要的一条，post在真正接受数据以前会先将请求头发送给服务器进行确认，而后才真正发送数据

　　post请求的过程：

　　1.浏览器请求tcp链接（第一次握手）

　　2.服务器答应进行tcp链接（第二次握手）

　　3.浏览器确认，并发送post请求头（第三次握手，这个报文比较小，因此http会在此时进行第一次数据发送）

　　4.服务器返回100 continue响应

　　5.浏览器开始发送数据

　　6.服务器返回200 ok响应

 

　　get请求的过程

　   1.浏览器请求tcp链接（第一次握手）

　　2.服务器答应进行tcp链接（第二次握手）

　　3.浏览器确认，并发送get请求头和数据（第三次握手，这个报文比较小，因此http会在此时进行第一次数据发送）

　　4.服务器返回200 ok响应

 

　　也就是说，目测get的总耗是post的2/3左右

3.get会将数据缓存起来，而post不会

　　能够作个简短的测试，使用ajax采用get方式请求静态数据（好比html页面，图片）的时候，若是两次传输的数据相同，第二次之后耗费的时间将在10ms之内（chrome测试），而post每次耗费的时间都差很少……

　　经测试，chrome下和firefox下若是检测到get请求的是静态资源，则会缓存，若是是数据，则不缓存，可是IE这个傻X啥都会缓存起来

　　固然，应该没人会用post去获取静态数据吧，反正我是没看到过。

4.post不能进行管道化传输

　　http权威指南中是这样说的：

　　http在的一次会话须要先创建tcp链接（大部分是tcp，可是其余安全协议也是能够的），而后才能通讯，若是每次链接都只进行一次http会话，那这个链接过程占的比例太大了！

　　因而出现了持久链接：在http/1.0+中是connection首部中添加keep-alive值，在http/1.1中是在connection首部中添加persistent值，固然二者不只仅是命名上的差异，http/1.1中，持久链接是默认的，除非显示在connection中添加close，不然持久链接不会关闭，而http/1.0+中则刚好相反，除非显示在connection首部中添加keep-alive，不然在接收数据包后链接就断开了。

　　出现了持久链接还不够，在http/1.1中，还有一种称为管道通讯的方式进行速度优化：把须要发送到服务器上的全部请求放到输出队列中，在第一个请求发送出去后，不等到收到服务器的应答，第二个请求紧接着就发送出去，可是这样的方式有一个问题：不安全，若是一个管道中有10个链接，在发送出9个后，忽然服务器告诉你，链接关闭了，此时客户端即便收到了前9个请求的答复，也会将这9个请求的内容清空，也就是说，白忙活了……此时，客户端的这9个请求须要从新发送。这对于幂等请求还好（好比get，多发送几回都不要紧，每次都是相同的结果），若是是post这样的非幂等请求（好比支付的时候，多发送几回就惨了），确定是行不通的。

　　因此，post请求不能经过管道的方式进行通讯！

　　颇有可能，post请求须要从新创建链接，这个过程不跟彻底没优化的时候同样了么？

　　因此，在可使用get请求通讯的时候，不要使用post请求，这样用户体验会更好，固然，若是有安全性要求的话，post会更好。

结语： 有不对之处欢迎指正

参考：

1. https://segmentfault.com/a/1190000018129846

2. https://www.cnblogs.com/strayling/p/3580048.html