post方法的参数写在url中和写在body中的区别？

参考链接：www.zhihu.com/question/64…

SuperAgent中提到query方法可以用在post请求中用于在url中插入请求参数。事实证明确实可以这样用，但最好不要这样用。

屏幕快照 2019-10-21 上午11.25.02.png

http协议根据请求的数据传输能力，把http请求分为两种类型，一种是url类请求，一种是body类请求。他们之间的区别是：url类的请求，客户端无法通过请求体body给后台传数据，使用url类的请求，后台拿到的body为空。body类的请求兼容url类的请求，所以body类的请求既可以把参数放到url里传给后台，也可以把数据放在body里传给后台。

Url类请求包括但不限于GET、HEAD、OPTIONS、TRACE 等请求方法。Body类请求包括但不限于POST、PUSH、PATCH、DELETE 等请求方法。

但是根据http协议这两类请求应该各司其职。如果一定要在post请求的url中插入参数，需要和后台协定。

Web通信中传统轮询、长轮询和WebSocket区别？

背景

http协议是应用层协议，本身不对请求和响应的通信状态进行保存，所以她是无状态协议。

如果客户端需要从服务端获取更新的数据，有以下实现方式：

短轮询

1.用setInterval每隔1000ms向后台发起一个ajax请求，获取数据。

问题：

但实际上这样接收到的数据顺序并不是按照发送的顺序来的，因为有可能服务器接收请求、返回数据、客户端接收数据的总时间超过1000ms，而下次发起请求并不会等到接收到上一次请求返回数据之后才发起。

这个问题可以用async：false的方法解决这个问题，但是会导致页面假死

setInterval(function(){ 	
    $.ajax({ 		
        // ... 		
        callback:function(data){ 
            console.log(data); 		
        }  	
    }); 
},1000)

2.通过在回调函数里递归调用自身，用setTimeOut设定调用间隔时间为1000ms，就能保证每次每一次发起新的请求，都是在上一个请求返回结果并console.log出来之后才发起的。

不过这样做仍然存在问题：

首先是仍然无法保证两次请求的实际间隔时间为1000ms（只能保证数据返回之后，程序过1000ms再去发请求，请求发出直至等待数据返回的时间不确定）
和第一种方式一样，这两种请求方式每发起一个新请求，就要新建一个http请求，耗费大量资源

function poll(){ 	
    setTimeout(function(){ 		
        $.ajax({ 			
            //... 			
        callback:function(){ 
            console.log(data); 		
            poll(); // 调用自身 
        } 		
     }); 	
},1000); }

长轮询

特点：

当浏览器发起一个请求，所连接的服务器就挂起这次请求，等到服务器这边的数据有更新的时候就响应这个请求，之后关闭连接。如果在超过了一定时限之后，服务器仍然没有检测到有数据更新，服务器向请求方返回无数据更新的响应，之后关闭连接。客户端在处理完服务端返回的数据之后，再次发起新请求，建立连接。

优缺点：

这么做之后可以减少http请求的次数。但长时间的连接挂起仍然会造成资源浪费，这种方式也依旧是由客户端去不断的发起轮询，请求服务端。更加理想的方式是：服务端的数据发生变化的时候，服务端能主动把数据推送给客户端。

长连接（SSE）

屏幕快照 2019-11-05 下午5.55.31.png

特点：

没有一端提出断开就一直保持TCP连接状态，并且是由客户端发起一个请求之后，有更新的数据服务器才会向客户端推送更新。

优缺点：

客户端不用去发起大量的无用请求。不过维持一个长连接也会增加服务端的开销。

WebSocket

首先浏览器通过一个http请求和服务进行握手，握手通过后连接就建立并保持了。浏览器会发起一个请求，这个请求里包含了它想使用websocket的意向，完成握手之后浏览器和服务端应用层之间用的就不再是http协议了，而是websocket协议。

屏幕快照 2019-11-06 上午11.04.19.png

特点： WebSocket既可以服务器端主动推送消息，客户端也可以主动向服务器发起消息

疑问：有了长连接为什么还要弄Websocket？

长连接保持的是传输层的TCP连接在一定时间内不断开，http连接在服务器有数据推送给浏览器端之后就断开了，后续的http请求还是会利用已经建立起来的TCP连接。因为http协议规定了http连接是一个一来一回的过程，如果浏览器端不先发起一个请求，服务端无缘无故发出一个http响应，浏览器端不会接收。所以这算不上完全的主动由服务器向浏览器端推送更新，是建立在浏览器端先发起http请求的基础上的。

而WebSocket它和http协议一样，是应用层的协议。它实现了真正的双向平等对话 ，解决了http协议的缺陷：通信只能由客户端发起

具体实现参考链接：理论联系实际：从零理解WebSocket的通信原理、协议格式、安全性

短轮询、长轮询、长连接、Websocket总结比较

屏幕快照 2019-11-05 下午6.19.35.png

KeepAlive 机制和心跳机制

直接看这篇：长连接和心跳的那些事儿

网络相关杂项