有点晕,从长连接的角度来说,keep-alive和websocket有什么区别?
发布于 9 天前 作者 hwoarangzk 304 次浏览 来自 问答

求问

8 回复

已经不是一个协议的事情了。。。。一个是 http 协议,一个是 websocket。。。。。。。。。。

两者都怎么实现长连接的呢?主要是有同事告诉我,keep-alive如果实现了长连接,那还要websocket干嘛,顿时无言以对

长连接应该是,客户端往服务器端发送一个http请求,然后服务端等到任务完成之后才返回。这个任务完成的时间可以是几个小时,而一般的http请求得到返回的时间没那么长。客户端得到服务器端返回的信息之后,马上又发一个请求,然后服务器端继续前面的事情,也就是不立即返回,等有了新的信息之后再返回。 websocket是指客户端和服务器之间建立一个websockt连接,然后客户端可以给服务器发信息,服务器也可以给客户端发信息。从行为上来说,对比长连接,服务器的不需要把请求hold住,而客户端也不需要接收一次信息后再立刻发送请求。 在没有websocket之前,只有长连接可以选择。

嗯哪,其实最大区别是能否互推消息

@kolyjjj 听了层主的解释,是不是说长连接在链接未结束之前,所有的网络链接所占用的资源不能释放?比如我用长连接的方式做了一个Web页面,只要链接不结束,那么几万个用户使用的时候,是不是这几万个链接占用的服务器内存就是巨大的?

你可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁,它和 HTTP 有一些共性,是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。在以前 HTTP 协议中所谓的 keep-alive connection 是指在一次 TCP 连接中完成多个 HTTP 请求,但是对每个请求仍然要单独发 header;所谓的 polling 是指从客户端(一般就是浏览器)不断主动的向服务器发 HTTP 请求查询是否有新数据。这两种模式有一个共同的缺点,就是除了真正的数据部分外,服务器和客户端还要大量交换 HTTP header,信息交换效率很低。它们建立的“长连接”都是伪.长连接,只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。

WebSocket 解决的第一个问题是,通过第一个 HTTP request 建立了 TCP 连接之后,之后的交换数据都不需要再发 HTTP request了,使得这个长连接变成了一个真.长连接。但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP 协议是有区别的,所以它需要对服务器和客户端都进行升级才能实现。在此基础上 WebSocket 还是一个双通道的连接,在同一个 TCP 连接上既可以发也可以收信息。此外还有 multiplexing 功能,几个不同的 URI 可以复用同一个 WebSocket 连接。这些都是原来的 HTTP 不能做到的。

详情

也可以简单的理解为,keep-alive 只是一种为了达到复用tcp连接的“协商”行为,双方并没有建立正真的连接会话,服务端也可以不认可,也可以随时(在任何一次请求完成后)关闭掉。WebSocket 不同,它本身就规定了是正真的、双工的长连接,两边都必须要维持住连接的状态。

另外,http协议决定了浏览器端总是主动发起方,http的服务端总是被动的接受、响应请求,从不主动。 而WebSocket协议,在连接之后,客户端、服务端是完全平等的,不存在主动、被动之说。

回到顶部