关于http post两阶段提交的一些问题

之前一些应用经常会出现请求超时而引起用户体验极度下降，我们每个应用都会做用户体验的优化。当然有很多其它原因，但是对于

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久。

 

今天上午风控项目中使用hessian调用又出现超时问题，经过分析hessian的POST也是两阶段提交，无解，除非换协议。

 

对于AJAX的使用，yahoo推荐用GET代替POST，所以如果数据量不是很大，坚决不要用POST。