Http与WebSocket对比

Http工作模式与WebSocket有所不同,本文将从应用场景入手对比两者的区别。

WebSocket

基于单个tcp连接提供全双工通信的协议,信息交换模式是双向的,服务器能直接将信息推送到客户端。

Http协议

Http提供半双工通信,不直接支持信息推送。

HTTP和WebSocket的区别

交互模式

流的内容都是http请求和响应,区别在于编码和打包方式。

WebSocket增加了一些特性对流进行管理,并保留旧语义。

HTTP和WebSocket的区别

HTTP和WebSocket的区别

使用加密WebSocket连接,WebSocket连接使用Transport Layer Security (TLS),确保浏览器使用显式代理服务器时,能够发出HTTP CONNECT命令。

在WebSocket客户端和WebSocket服务器间建立一个安全隧道,通过HTTP代理提供端到端的tcp通信。

HTTP和WebSocket的区别及使用场景

应用场景

通常在选择HTTP协议与WebSocket时遵循以下原则:

1、先假设默认应采用HTTP协议。

2、查看以下指导尝试说服自己是否应选择WebSocket。

HTTP应用场景

评估HTTP协议时根据应用场景进行思考,涉及到以下场景时会发现HTTP协议非常适合。

检索资源

客户端只需知道资源当前状态,无需再次更新。

如:球迷想知道上周比赛结果,游戏结果已定,不太可能发生更新。

此场景,HTTP是合适的,若比赛正在进行中,比赛分数不断变化且频繁更新。WebSocket是更好的选择。

高度可缓存资源

资源很少改变或多个客户端同时检索,可从缓存中受益。

“很少”一词在这里变得很隐晦,须根据客户端访问模式来判断,而非固定的时间。

如果频繁检索高度易变的资源,特别是由多个客户端进行检索,这些资源仍具有很高的可缓存性。

WebSocket设计不允许显式或透明代理缓存消息,从而直接影响客户端的性能。

如:上周比赛结果高度可缓存,非常适合HTTP。

正在进行的比赛得分,WebSocket更适合。

幂等性和安全性

HTTP方法具有的幂等性和安全性众所周知。

这一特性允许客户端能很好应对超时或临时网络问题。

如果,请求不修改正在执行的资源,则该请求是“安全的”。

此特性是启用缓存或预取的关键。

采用安全和幂等的设计,根源是抵御通信故障。

这种情况HTTP非常适合。

注:请求可多次发出而不会影响最终结果,则该请求是“幂等的”。

WebSocket将这些问题留给消息传递层,意味着没有广泛的行业标准支持。

错误方案

HTTP设计围绕请求 - 响应的消息传递模式,这意味着它对错误方案有广泛的支持。

HTTP设计允许用错误描述响请求、使用细微的状态区分成功场景。

WebSocket协议仅支持连接错误,建立连接交换消息,所以,需在传递层设计错误应对方案。

同步事件

请求 - 响应模式非常适合同步操作。

HTTP响应是一种明确请求,允许对其进行后续操作。

WebSockets将细节留给消息传递层,WebSocket协议不保证任何形式的消息确认。

设计中应尽量避免假设客户端,能完美地同步操作。

尽可能提供无状态交互,或允许客户端并行请求,这将使应用可以更好的应对不可避免的网络问题,或有bug的客户端。

WebSocket应用场景

WebSocket有一组自己的应用场景,是一些项目的最佳选择。

快速响应时间

客户端需要对更改做出快速反应时,尤其无法预测的更改,WebSocket是最佳选择。

考虑多用户实时聊天的应用,使用WebSockets每个用户都可以实时发送和接收消息。

与REST相比WebSockets更高效,它不需要为每条消息的发送/接收产生额外开销。

持续更新

客户端关心资源状态的持续更新时,WebSockets是个不错的选择,客户端无法预测何时发生变化。

如果客户端能预测更改发生的时间或不频繁发生的更改,HTTP协议更合适。

如:每小时更改一次的资源,或只在得知相关资源修改后才执行请求。

如果客户端不确定相关资源是否会被修改WebSockets是更好的选择。

Ad-hoc消息传递

WebSocket协议不是围绕请求 - 响应而设计的。

消息可在任何时候从连接的一端发出,且没有任何本地支持来表示一个消息与另一个消息有关。

这使得该协议非常适合“发送就忘记”的消息传递方案。

小负载高频消息

WebSocket协议提供交换消息的持久连接。

仅在连接一开始产生开销,后续每条消息都能使用该连接。

WebSockets专为长连接方案而设计,避免建立连接和发送HTTP请求/响应头的开销。

但它不应被极端使用,若只发送少量消息或消息传递非常少,应避免WebSockets,除非客户必须快速接收或执行更新,否则,维护开放连接是不必要的浪费。

注:虽然HTTP v1.1允许多个请求重用单个连接,但通常会有少量超时时间用于控制资源消耗。

HTTP错误应用场景

1、依赖于客户端轮询服务,而不是由用户主动发起。

2、需要频繁的调用发送小消息。

3、客户端需快速响应对资源的更改,且无法预测更改何时发生。

思考:WebSocket解决方案在设计、实现、测试、操作上,能否大大减少此类场景的工作量吗?

WebSockets错误应用场景

1、连接仅用于极少数事件或非常短的时间,客户端无需快速响应事件。

2、需一次打开多个WebSockets到同一服务。

3、打开WebSocket,发送消息,接着关闭它 - 然后再重复该过程。

4、消息传递层中重新实现请求/响应模式。

思考:HTTP解决方案在设计、实施、测试、运营方面,能大大减少此类场景的工作量吗?

结论与建议

应假设默认应该采用传统HTTP协议,若能很好完成工作,则用它,除非上述指导原则能够说服使用WebSockets。