HTTP协议与WebSocket的区别

HTTP协议(REST)与WebSocket区别在于工作模式,本文将从应用场景入手对比两者的区别。

HTTP协议和WebSocket对比

WebSocket基于单个TCP连接提供全双工通信的协议,信息交换模式是双向的,服务器能直接将信息推送到客户端。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协议非常适合。

检索资源/Retrieve Resource

客户端只需知道资源当前状态,无需再次更新。如:球迷想知道上周比赛的结果,则游戏结果已定,不太可能发生更新。此场景,HTTP是合理的选择,若比赛正在进行中,比赛分数可能不断变化,且频繁更新。此时,WebSocket会是更好的选择。

高度可缓存资源/Highly Cacheable Resource

资源很少改变或多个客户端同时需检索,可从缓存中受益,“很少”一词在这里变得很隐晦,它须根据客户端访问模式来判断,而非根据固定的时间。如果频繁检索高度易变的资源,特别是由多个客户端进行检索,这些资源仍具有很高的可缓存性。WebSocket设计不允许显式或透明代理缓存消息,从而直接影响客户端的性能。

如:上周比赛结果高度可缓存,非常适合HTTP。正在进行的比赛得分,WebSocket更适合。

幂等性和安全性/Idempotency and Safety

HTTP方法具有的幂等性和安全性众所周知,这一特性允许客户端能很好应对超时或临时网络问题,如果,请求不修改正在执行的资源,则该请求是“安全的”。此特性是启用缓存或预取的关键。

采用安全和幂等的设计,其根源是抵御通信故障。这种情况HTTP非常适合,在安全性和幂等性有要求的场合http有广泛的应用。

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

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

错误方案/Error Scenarios

HTTP是围绕请求 - 响应的消息传递模式设计的,意味着它对错误方案有广泛的支持。HTTP设计允许用错误描述响请求、使用细微的状态区分成功场景。WebSocket协议仅支持连接错误,建立连接交换消息,需在传递层设计解决方案应对错误。

同步事件/Synchronized Events

请求 - 响应模式非常适合需要同步的操作。HTTP响应是一种明确的请求,允许对其进行后续操作。WebSockets将细节留给了消息传递层,WebSocket协议不保证任何形式的消息确认。

在设计中应尽量避免假设客户端,能完美地同步他们的操作。尽可能提供无状态交互,或允许客户端并行请求,因为,这将使应用可以更好的应对不可避免的网络问题,或有bug的客户端。

WebSocket应用场景

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

快速响应时间/Fast Reaction Time

当客户端需要对更改做出快速反应时,尤其是无法预测的更改,WebSocket可能是最佳选择。考虑多用户实时聊天的应用,使用WebSockets,则每个用户都可以实时发送和接收消息。与REST相比,WebSockets更高效,它们不需要为每条消息的发送/接收创建额外的请求/响应开销。

持续更新/Ongoing Updates

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

如果客户端能够预测更改发生的时间,或不频繁发生的更改,HTTP协议可能更合适,如,每小时更改一次的资源,或只在得知相关资源修改后才执行的请求。

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

Ad-hoc消息传递/Ad-hoc Messaging

WebSocket协议不是围绕请求 - 响应而设计的。消息可在任何时候从连接的一端发送,且没有任何本地支持来表示一个消息与另一个消息有关。这使得该协议非常适合“发送就忘记”的消息传递方案。

小负载高频消息/High-Frequency Messaging with Small Payloads

WebSocket协议提供了交换消息的持久连接。仅在连接一开始产生开销,后续每条消息都可使用该连接。WebSockets专为长连接方案而设计,避免建立连接和发送HTTP请求/响应头的开销。

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

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

HTTP错误的应用场景

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

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

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

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

WebSockets错误的应用场景

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

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

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

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

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

结论与建议

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