我们知道HTTP是基于TCP/IP的关于数据如何在万维网中如何通信的协议,HTTP的底层是TCP/IP。所以GET和POST的底层也是TCP/IP,也就是说,GET/POST都是TCP链接。GET和POST能做的事情是一样一样的。你要给GET加上request body,给POST带上url参数,技术上是完全行的通的。 因此从传输层上来说,get和post请求是没有什么区别的,那么我们经常提到的get和post的区别如:
1.GET在浏览器回退时是无害的,而POST会再次提交请求.
2.GET产生的URL地址可以被Bookmark,而POST不可以。
3.GET请求会被浏览器主动cache,而POST不会,除非手动设置。
4.GET请求只能进行url编码,而POST支持多种编码方式。
5.GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留。
6.GET请求在URL中传送的参数是有长度限制的,而POST么有。
7.对参数的数据类型,GET只接受ASCII字符,而POST没有限制。
8.GET比POST更不安全,因为参数直接暴露在URL上,所以不能用来传递敏感信息。
9.GET参数通过URL传递,POST放在Request body中。
用TCP来运输数据,它很可靠,从来不会发生丢件少件的现象。
但是网络是有很多这样的tcp数据包的,如何区别这些这些tcp数据包,并且规定其传输优先级别,这就是http的规范诞生了,HTTP给数据包运输设定了好几个服务类别,有GET, POST, PUT, DELETE等等,所以说HTTP只是个行为准则,而TCP才是GET和POST怎么实现的基本。
那么还有一个疑问,关于参数大小的限制又是从哪来的呢?
这就是我们浏览器和服务器的各自规定了,数据量太大,对浏览器和服务器都有很大负担,(大多数)浏览器通常都会限制url长度在2K个字节,而(大多数)服务器最多处理64K大小的url。超过的部分,恕不处理。
因此HTTP的规定和浏览器/服务器的限制,导致他们在应用过程中体现出一些不同。
可能你还会忽略GET和POST还有一个重大区别,简单的说:
GET产生一个TCP数据包;POST产生两个TCP数据包。
对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据);
而对于POST,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok(返回数据)。
因为POST需要两步,时间上消耗的要多一点,看起来GET比POST更有效。既然如此为何不用GET替换POST来优化网站性能。但这是一个坑!跳入需谨慎。为什么?
- GET与POST都有自己的语义,不能随便混用。
- 在网络环境好的情况下,发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下,两次包的TCP在验证数据包完整性上,有非常大的优点。
- 并不是所有浏览器都会在POST中发送两次包,Firefox就只发送一次。
当然Firefox为什么要这么做是有他的原因的:
我们每个应用都会做用户体验的优化。当然有很多其它原因,但是对于POST的两阶段提交引起的访问超时也发生过好几次,而且基本无解,只能修改实现方式,尽量减少传输的数据以便改用GET方式。
有不少浏览器厂商对于POST的提交采用两阶段发送数据,特别是IE系统列的XMLHttpRequest对象,所以在IE浏览器上用AJAX提交POST的数据,是按两个阶段,第一步先发送header数据,第二步再发送body部分。如果我们用winshark抓包会看到两连次结过程。
而对于firefox浏览器,则采用一次连接,这也是原来HTTP协议的“本意”,http协议本身不保存任何状态信息,一次请求一次应答。对于TCP事务而言,通讯次数越多可靠性越低,在一次连结中传输完需要的消息是最可靠的,但是却有很多浏览器厂商不愿意遵守这个原则,它们的理由也很搞笑:
假如网络环境不好,网络延迟、丢包的时候,服务端会等待(延迟时),客户端重发POST的DATA数据到服务单,来确保本次请求的完整性。
这理由不太具有说服力,header数据相对于body数据来说都是很小,如果一次传输中只收到header,body却丢了,那么这一次请求对于服务端来说,它只有等待超时才会知道后面的body没有了,这时它已经向客户端传输了请求错误码。客户端根本就谈不上重发body。当然如果浏览器厂商和WEB服务器是同一厂商,他们可以在收到header后等待body超时时发送一个重发指令给客户端,但是目前没有任何WEB服务端是这么做的,而且,这也从根本上违反了HTTP协议的规范,因为对于超时连结,如果再等它重发数据,再超时,再重发?那用户在WEB服务端定义的“超时”还能得到什么保证?
还不如一次连同header加body发送,如果数据包不完整,服务端返回连结超时用户只需要重刷一次即可,而如果两次提交,当收到header时,服务端的处理程序首先要开辟内存hode住header数据再等待body,对于同步处理的话当前进程或线程不能服务其它请求,极大降低服务端性能。最后还是返回异常给客户端,对于异步处理的话你根本不知道body什么时候过来,如果客户端只发送header就下线了,服务端可能要hode这个数据n久。