[WEB]关于HTTP 请求方式: GET和POST的比较的本质

GET和POST两种基本请求方法的区别
一：
1.最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数；GET是从服务器上获取数据，POST是向服务器传送数据。
2.GET在浏览器回退时是无害的，而POST会再次提交请求。
3.GET产生的URL地址可以被Bookmark，而POST不可以。
4.GET请求会被浏览器主动cache，而POST不会，除非手动设置。
5.GET请求只能进行url编码，而POST支持多种编码方式。
6.GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留；在客户端， GET方式在通过URL提交数据，数据在URL中可以看到；POST方式，数据放置在HTML HEADER内提交。
7.GET请求在URL中传送的参数是有长度限制的(1024k)，而POST么有。
8.对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
9.GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
10.对于GET方式，服务器端用Request.QueryString获取变量的值，对于POST方式，服务器端用Request.Form获取提交的数据。

二：GET和POST是什么？HTTP协议中的两种发送请求的方法。
HTTP是什么？HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议。
HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP，也就是说，GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body，给POST带上url参数，技术上是完全行的通的。
在我大万维网世界中，TCP就像汽车，我们用TCP来运输数据，它很可靠，从来不会发生丢件少件的现象。但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。为了避免这种情况发生，交通规则HTTP诞生了。HTTP给汽车运输设定了好几个服务类别，有GET, POST, PUT, DELETE等等，HTTP规定，当执行GET请求的时候，要给汽车贴上GET的标签（设置method为GET），而且要求把传送的数据放在车顶上（url中）以方便记录。如果是POST请求，就要在车上贴上POST的标签，并把货物放在车厢里。当然，你也可以在GET的时候往车厢内偷偷藏点货物，但是这是很不光彩；也可以在POST的时候在车顶上也放一些数据，让人觉得傻乎乎的。HTTP只是个行为准则，而TCP才是GET和POST怎么实现的基本。


在我大万维网世界中，还有另一个重要的角色：运输公司。不同的浏览器（发起http请求）和服务器（接受http请求）就是不同的运输公司。 虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。业界不成文的规定是，（大多数）浏览器通常都会限制url长度在2K个字节，而（大多数）服务器最多处理64K大小的url。超过的部分，恕不处理。如果你用GET服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略，所以，虽然GET可以带request body，也不能保证一定能被接收到哦。
好了，现在你知道，GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
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. 据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

* URL的定义和组成

　　Uniform Resource Locator 统一资源定位符
　　URL的组成部分：http://www.mbalib.com/china/index.htm
　　http://：代表超文本传输协议
　　www：代表一个万维网服务器
　　mbalib.com/：服务器的域名，或服务器名称
　　China/：子目录，类似于我们的文件夹
　　Index.htm:是文件夹中的一个文件
　　/china/index.htm统称为URL路径

注：以上参阅 https://www.cnblogs.com/logsharing/p/8448446.html
三：HTTP请求中POST与GET的原理区别
一般我们在浏览器输入一个网址访问网站都是GET请求;再FORM表单中，可以通过设置Method指定提交方式为GET或者POST提交方式，默认为GET提交方式。
HTTP定义了与服务器交互的不同方法，其中最基本的四种：GET，POST，PUT，DELETE，HEAD，其中GET和HEAD被称为安全方法，因为使用GET和HEAD的HTTP请求不会产生什么动作。不会产生动作意味着GET和HEAD的HTTP请求不会在服务器上产生任何结果。但是安全方法并不是什么动作都不产生，这里的安全方法仅仅指不会修改信息。
四：HTTP响应报文的格式
status，状态码描述了请求过程中发生的情况
reson-phrase 是数字状态码的可读版本
常见的状态码以及含义如下：
200 OK 服务器成功处理请求
301/302 Moved Permanently（重定向）请求的URL已移走。响应报文中应该包含一个Location URL，说明资源现在所处的位置
304 Not Modified（未修改） 客户的缓存资源是最新的，要客户端使用缓存内容
404 Not Found 未找到资源
501 Internal Server Error 服务器遇到错误，使其无法对请求提供服务
注：三 四参阅 (https://blog.csdn.net/yipiankongbai/article/details/24025633)
五：后台获取值 

post提交方式，get提交方式，context.Request.QueryString["key"]，context.Request.Form["key"]，context.Request.Params["key"]，context.Request.["key"]
get ：把请求封装在请求字符串中（所以在web项目中，用context.Request.QueryString["key"]可以取到请求中的参数，post中这个方法取不到）
post：把请求参数封装在报文体中（所以在web项目中，用context.Request.Form["key"]可以取到请求中的参数）
注：1.context.Request.Params["key"]无论是post还是get都能取到。
context.Request.["key"]无论是post还是get都能取到。
它们两个其实就是都封装了上面的两种取值方式，所以能够取到。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

01 特点

1.1 http的特点
  • 基于tcp/ip、一种网络应用层协议、超文本传输协议HyperText Transfer Protocol
  • 工作方式：客户端请求服务端应答的模式
  • 快速：无状态连接
  • 灵活：可以传输任意对象，对象类型由Content-Type标记
  • 客户端请求request消息包括以下格式：请求行（request line）、请求头部（header）、空行、请求数据

  •  

     

服务端响应response也由四个部分组成，分别是：状态行、消息报头、空行、响应正文

 

 

1.2 请求方法

http请求可以使用多种请求方法。HTTP1.0定义了三种请求方法：GET, POST 和 HEAD方法。

HTTP1.1新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

  • 1 GET 请求指定的页面信息，并返回实体主体。
  • 2 HEAD 类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头
  • 3 POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
  • 4 PUT 从客户端向服务器传送的数据取代指定的文档的内容。
  • 5 DELETE 请求服务器删除指定的页面。
  • 6 CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
  • 7 OPTIONS 允许客户端查看服务器的性能。
  • 8 TRACE 回显服务器收到的请求，主要用于测试或诊断。
1.3 我们耳熟能详的的区别

http协议最常见的两种方法GET和POST，这几点答案其实有几点并不准确

  • 请求缓存：GET 会被缓存，而post不会

  • 收藏书签：GET可以，而POST不能

  • 保留浏览器历史记录：GET可以，而POST不能

  • 用处：get常用于取回数据，post用于提交数据

  • 安全性：post比get安全

  • 请求参数：querystring 是url的一部分get、post都可以带上。get的querystring（仅支持urlencode编码），post的参数是放在body（支持多种编码）

  • 请求参数长度限制：get请求长度最多1024kb，post对请求数据没有限制

02 常见的误区

get和post误区

针对上面常见的区别，如果面试的时候这么说，肯定是有很大的毛病，刚在学校面试的时候也曾经囫囵吞枣地这样说过，现在回过头再想以前的错误认知，又有许多新的认识。

2.1 误区一

“用处：get常用于取回数据，post用于提交数据”

曾听到过这样一种说法：get替换post来优化网站性能，虽然这种说法没错，也的确get常被用于取回数据，但是post也被一些ui框架使用于取回数据，比如kendo ui中的grid，就是用post来接受数据的。所以结论是get、post用途也是因地制宜。如果你有使用过kendo UI，会发现分页、过滤、自定义的参数都包含在form data里面。

请求参数get是querystring（仅支持urlencode编码），post是放在body（支持多种编码） query参数是URL的一部分，而GET、POST等是请求方法的一种，不管是哪种请求方法，都必须有URL，而URL的query是可选的，可有可无。

2.2 误区二

“请求参数长度限制：get请求长度最多1024kb，post对请求数据没有限制”

这句话看上去实在没毛病啊，菜鸟教程也是这样说的啊。虽然字面意思上没有错误，但是理解一定要正确。我想说的是GET方法提交的url参数数据大小没有限制，在http协议中没有对url长度进行限制（不仅仅是querystring的长度），这个限制是特定的浏览器及服务器对他的限制

下面就是对各种浏览器和服务器的最大处理能力做一些说明

  • IE浏览器对URL的最大限制为2083个字符
  • Firefox (Browser)：对于Firefox浏览器URL的长度限制为65,536个字符。
  • Safari (Browser)：URL最大长度限制为 80,000个字符。
  • Opera (Browser)：URL最大长度限制为190,000个字符。
  • Google (chrome)：URL最大长度限制为8182个字符。
  • Apache (Server)：能接受最大url长度为8,192个字符。
  • Microsoft Internet Information Server(IIS)：能接受最大url的长度为16,384个字符。

所以为了符合所有标准，url的最好不好超过最低标准的2083个字符（2k+35）。当然在做客户端程序时，url并不展示给用户，只是个程序调用，这时长度只收web服务器的影响了。对于中文的传递，一个汉字最终编码后的字符长度是9个字符。

最常见的form表单，浏览器默认的form表单，默认的content-type是application/x-www-form-urlencoded,提交的数据会按照key value的方式，jquery的ajax默认的也是这种content-type。当然在post方式中添加querystring一定是可以接收的到，但是在get方式中加body参数就不一定能成功接收到了。

2.3 误区三

“post比get安全性要高”

这里的安全是相对性，并不是真正意义上的安全，通过get提交的数据都将显示到url上，页面会被浏览器缓存，其他人查看历史记录会看到提交的数据，而post不会。另外get提交数据还可能会造成CSRF攻击。

2.4 误区四：
“GET产生一个TCP数据包；POST产生两个TCP数据包。”

这一点理解起来还是有一定难度的,实际上，不论哪一种浏览器，在发送 POST 的时候都没有带 Expect 头，server 也自然不会发 100 continue。通过抓包发现，尽管会分两次，body 就是紧随在 header 后面发送的，根本不存在『等待服务器响应』这一说。从另一个角度说，TCP 是传输层协议。别人问你应用层协议里的 GET 和 POST 有啥区别，你回答说这俩在传输层上发送数据的时候不一样，确定别人不抽你？参考资料：https://zhuanlan.zhihu.com/p/25028045

3 http状态码附录

3.1 状态码1xx
  • 100 Continue：服务器仅接收到部分请求，但是一旦服务器并没有拒绝该请求，客户端应该继续发送其余的请求。
  • 101 Switching Protocols：服务器转换协议：服务器将遵从客户的请求转换到另外一种协议。
  • 102: 由WebDAV（RFC 2518）：扩展的状态码，代表处理将被继续执行
3.2 状态码2xx:成功
  • 200 OK：请求成功（其后是对GET和POST请求的应答文档。）
  • 201 Created：请求被创建完成，同时新的资源被创建。
  • 202 Accepted：供处理的请求已被接受，但是处理未完成。
  • 203 Non-authoritative Information：文档已经正常地返回，但一些应答头可能不正确，因为使用的是文档的拷贝。
  • 204 No Content：没有新文档。浏览器应该继续显示原来的文档。如果用户定期地刷新页面，而Servlet可以确定用户文档足够新，这个状态代码是很有用的。
  • 205 Reset Content：没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。
  • 206 Partial Content：客户发送了一个带有Range头的GET请求，服务器完成了它。
3.3 状态码3xx:重定向
  • 300 Multiple Choices：多重选择。链接列表。用户可以选择某链接到达目的地。最多允许五个地址。
  • 301 Moved Permanently：所请求的页面已经转移至新的url
  • 302 Found：所请求的页面已经临时转移至新的url。
  • 303 See Other：所请求的页面可在别的url下被找到。
  • 304 Not Modified：未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（一般是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还可以继续使用。
  • 305 Use Proxy：客户请求的文档应该通过Location头所指明的代理服务器提取。
  • 306 Unused：此代码被用于前一版本。目前已不再使用，但是代码依然被保留。
  • 307 Temporary Redirect：被请求的页面已经临时移至新的url。
3.4 状态码4xx:客户端错误
  • 400 Bad Request：服务器未能理解请求。
  • 401 Unauthorized：被请求的页面需要用户名和密码。
  • 401.1：登录失败。
  • 401.2：服务器配置导致登录失败。
  • 401.3：由于 ACL 对资源的限制而未获得授权。
  • 401.4：筛选器授权失败。
  • 401.5：ISAPI/CGI 应用程序授权失败。
  • 401.7：访问被 Web 服务器上的 URL 授权策略拒绝。这个错误代码为 IIS 6.0 所专用。
  • 402 Payment Required：此代码尚无法使用。
  • 403 Forbidden：对被请求页面的访问被禁止。
  • 404 Not Found: 服务器无法找到被请求的页面。
  • 405 Method Not Allowed: 请求中指定的方法不被允许。
  • 406 Not Acceptable: 服务器生成的响应无法被客户端所接受。
  • 407 Proxy Authentication Required: 用户必须首先使用代理服务器进行验证，这样请求才会被处理。
  • 408 Request Timeout: 请求超出了服务器的等待时间。
  • 409 Conflict: 由于冲突，请求无法被完成。
  • 410 Gone: 被请求的页面不可用。
  • 411 Length Required: "Content-Length" 未被定义。如果无此内容，服务器不会接受请求。
  • 412 Precondition Failed: 请求中的前提条件被服务器评估为失败。
  • 413 Request Entity Too Large: 由于所请求的实体的太大，服务器不会接受请求。
  • 414 Request-url Too Long: 由于url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种情况。
  • 415 Unsupported Media Type: 由于媒介类型不被支持，服务器不会接受请求。
  • 416 Requested Range Not Satisfiable: 服务器不能满足客户在请求中指定的Range头。
  • 417 Expectation Failed: 执行失败。
  • 423: 锁定的错误。
3.5 状态码5** 服务端错误
  • 500 Internal Server Error：请求未完成。服务器遇到不可预知的情况。
  • 501 Not Implemented：请求未完成。服务器不支持所请求的功能。
  • 502 Bad Gateway：请求未完成。服务器从上游服务器收到一个无效的响应。
  • 503 Service Unavailable：请求未完成。服务器临时过载或当机。
  • 504 Gateway Timeout：网关超时。
  • 505 HTTP Version Not Supported：服务器不支持请求中指明的HTTP协议版本。

 

posted on 2018-06-03 09:31  欢笑一声  阅读(206)  评论(0)    收藏  举报

导航