get 和 post 请求的区别

get 和 post 是HTTP协议的两种常用的请求方法，既然常用，那么就会经常有人问它们到底有什么区别呢？

对此总结出来以下五点：

• get 是不安全的，因为数据被放在URL里面传输，post 数据是放在请求体里面的。
• get 传的数据量较小，主要是因为受URL长度限制，post 传送的数据量一般不受限制。
• get 只能使用ascll编码，post 没有限制。
• get 请求是可缓存的，后退不刷新；post 请求不缓存，后退重新请求。
• get 是一次tcp连接，post一般是两次。

根据HTTP规范，get 是用来获取资源的，请求访问已被 URL 识别的资源。post 向指定资源提交数据进行处理请求，可能会导致新的资源的建立和/或已有资源的修改。虽然用 get 方法也可以传输实体的主体，但一般不用 get 方法进行传输，而是用 post 方法。

本来我是想总结一下两种方法的区别，但是无意间看到一篇博客里面提到前两条区别都是错误的。里面还详细给出了错误的原因，觉得说的很有道理，因此在下面用前两条转载一下此篇博客中提到的解释。

 

一、GET和POST与数据如何传递没有关系

 　GET和POST是由HTTP协议定义的。在HTTP协议中，Method和Data（URL， Body， Header）是正交的两个概念，也就是说，使用哪个Method与应用层的数据如何传输是没有相互关系的。

     HTTP没有要求，如果Method是POST数据就要放在BODY中。也没有要求，如果Method是GET，数据（参数）就一定要放在URL中而不能放在BODY中。

     那么，网上流传甚广的这个说法是从何而来的呢？我在HTML标准中，找到了相似的描述。这和网上流传的说法一致。但是这只是HTML标准对HTTP协议的用法的约定。怎么能当成GET和POST的区别呢？

    而且，现代的Web Server都是支持GET中包含BODY这样的请求。虽然这种请求不可能从浏览器发出，但是现在的Web Server又不是只给浏览器用，已经完全地超出了HTML服务器的范畴了。

 

二、HTTP协议对GET和POST都没有对长度的限制

　　HTTP协议明确地指出了，HTTP头和Body都没有长度的要求。而对于URL长度上的限制，有两方面的原因造成：

     1. 浏览器。据说早期的浏览器会对URL长度做限制。据说IE对URL长度会限制在2048个字符内（流传很广，而且无数同事都表示认同）。但我自己试了一下，我构造了90K的URL通过IE9访问live.com，是正常的。网上的东西，哪怕是Wikipedia上的，也不能信。

     2. 服务器。URL长了，对服务器处理也是一种负担。原本一个会话就没有多少数据，现在如果有人恶意地构造几个几M大小的URL，并不停地访问你的服务器。服务器的最大并发数显然会下降。另一种攻击方式是，把告诉服务器Content-Length是一个很大的数，然后只给服务器发一点儿数据，嘿嘿，服务器你就傻等着去吧。哪怕你有超时设置，这种故意的次次访问超时也能让服务器吃不了兜着走。有鉴于此，多数服务器出于安全啦、稳定啦方面的考虑，会给URL长度加限制。但是这个限制是针对所有HTTP请求的，与GET、POST没有关系。

 

三、关于区别五的解释

　　对于get方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；

　　而对于post，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。

　　也就是说，get只需要汽车跑一趟就把货送到了，而post得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。

　　因为post需要两步，时间上消耗的要多一点，看起来get比post更有效。

　　其实据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

　　并不是所有浏览器都会在post中发送两次包，Firefox就只发送一次。