POST和GET都是向服务器提交数据，并且都会从服务器获取数据。
区别：
1、传送方式：get通过地址栏传输，post通过报文传输。
2、传送长度：get参数有长度限制（受限于url长度），而post无限制
3、GET和POST还有一个重大区别，简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包
长的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
1. GET与POST都有自己的语义，不能随便混用。
2. 据研究，在网络环境好的情况下，发一次包的
3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
建议：
1、get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
2、在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；
案例：一般情况下，登录的时候都是用的POST传输，涉及到密码传输，而页面查询的时候，如文章id查询文章，用get 地址栏的链接为：article.php?id=11，用post查询地址栏链接为：article.php， 不会将传输的数据展现出来。
拓展资料：
GET在浏览器回退时是无害的，而POST会再次提交请求。
GET产生的URL地址可以被Bookmark，而POST不可以。
GET请求会被浏览器主动cache，而POST不会，除非手动设置。
GET请求只能进行url编码，而POST支持多种编码方式。
GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
GET请求在URL中传送的参数是有长度限制的，而POST么有。
对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
GET参数通过URL传递，POST放在Request body中。
-----------------------------------------------------------------------------------------------------------------------------------------------
引子： 和朋友的聊天中得知他公司后台接口全部都是 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
引子： 和朋友的聊天中得知他公司后台接口全部都是 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