get和post的区别

Posted 2020-09-02 IT-HourseMan

1.GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

　　POST把提交的数据则放置在是HTTP包的包体中。

简而言之：GET把参数包含在URL中，POST通过request body传递参数。

2.根据HTTP规范，GET用于信息获取，而且应该是安全的和幂等的。

　　(1).所谓安全的意味着该操作用于获取信息而非修改信息。换句话说，GET 请求一般不应产生副作用。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。

　　* 注意：这里安全的含义仅仅是指是非修改信息。

　　(2).幂等的意味着对同一URL的多个请求应该返回同样的结果。这里我再解释一下幂等这个概念：

3.GET请求在URL中传送的参数是有长度限制的，而POST没有

　　(1).首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

　　注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。[见参考资料5]

　　(2).理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说“POST数据量存在80K/100K的大小限制”是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。

简而言之：GET请求发送数据更小。

4.GET请求会被浏览器主动cache，而POST不会，除非手动设置。

5.GET请求只能进行url编码，而POST支持多种编码方式。

6.GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。

7.对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

8.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery（注释1）攻击。

9.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. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。

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

　　

注释1：跨站请求伪造（Cross Site Request Forgery (CSRF)）

    跨站请求伪造（Cross Site Request Forgery (CSRF)）也被称为：one click attack/session riding，缩写为：CSRF/XSRF，是一种挟制终端用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。攻击人员通过一些手段让终端用户点击存在攻击的链接或者页面，例如攻击人员通过xss漏洞在终端用户的页面中执行，或者将这个代码放在一个具有诱惑性的页面中，亦或者将链接直接放在论坛帖子中。

    CSRF攻击原理

    1. 用户登录可信任的网站A（存在缺陷的交易网站）；

    2. 网站A返回登录session信息并将session存储在本地cookie；

    3. 用户访问其他网站B（论坛、好友发送页面），网站B中包含执行网站A相关操作的请求操作(转账URL、退款URL)并且能够直接执行；

    4. 网站B页面加载过程中携带网站A的cookie将请求发送到网站A的服务器；

    5. 网站A服务器根据请求校验用户信息后执行具体操作(资金损失)，从而达到了模拟用户在网站A的相关操作使用户或者网站A遭受伤害或损失。

    下图为一具体的流程：

   

    图1 CSRF原理示例

    用户被攻击的两个条件是：

    1. 登录了网站A并在本地保存了cookie；

    2. 在未退出网站A或者清除cookie的情况下访问了网站B，并且在网站B帮助用户向网站A提交了请求。

    CSRF防御

    1. token校验

    用户进行操作交互前先构造一个token值(随机数)，后续每次操作请求必须带上token值，服务器校验token合法后才进行相关操作，这样黑客因为无法提前获知用户的token，就无法构造出正确的操作URL。加上token后操作URL必须带上一随机值，如下：

    http://www.xxxxx.com/changeprice?orderId=123456789&fromprice=100.00&toPrice=0.01&t=rand()

    按照之前的攻击执行结果如下：

   

    坏人因为没有小白的token信息，因此伪造的URL是不能被服务器处理的，从而导致阴谋无法得逞。

    这个方法已经可以杜绝99%的CSRF攻击，由于用户的Cookie很容易由于网站的XSS漏洞而被盗取，这就另外的1%。一般的攻击者看到有需要算token值，基本都会放弃了，某些除外，所以如果需要100%的杜绝，这个不是最好的方法。

    (2).验证码

    这个方案的思路是：每次的用户提交都需要用户在表单中填写一个图片上的随机字符串，这个方案可以完全解决CSRF，但在易用性方面似乎不是太好。