前言
众所周知啊,OSI 七层网络模型,自底向上分别是:物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
而 TCP/IP 四层模型则是:数据链路层(物理层,数据链路层合二为一)、网络层、传输层、应用层(会话层,表示层,应用层合三为一)
发送方发送出数据后,数据会从上到下,经过各种协议封装,最终在物理层以物理媒介(如电缆、无线电波)进行传输,当数据到达接收方后,再按照相反的顺序,将数据进行解包处理。
TCP 是传输层的协议之一(还有 UDP 协议),而 websocket 和 HTTP 则是最顶层应用层的协议。
作为解包的最顶层应用层的两个协议,他们都是建立在前面几层解包的基础上的,也就是说,都是基于 TCP 协议的。
TCP 协议: TCP 是一种面向连接的、可靠的、基于字节流的传输层通信协议。它负责在两台计算机之间建立一个稳定的连接,并保证数据正确无误地传输。TCP 通过三次握手建立连接,使用序列号、确认应答、滑动窗口等机制确保数据的有序、完整,并且支持拥塞控制和流量控制。
一、HTTP 的限制
在介绍 websocket 之前先来简单说一说 HTTP 吧,因为 websocket 本身就是为了补充或者取代部分 HTTP 的功能。
1、全双工和半双工
首先说说全双工和半双工吧:
全双工:全双工(Full Duplex)是允许数据在两个方向上同时传输。 半双工:半双工(Half Duplex)是允许数据在两个方向上传输,但是同一个时间段内只允许一个方向上传输。
HTTP 的工作方式就类似于半双工,是一种请求响应模式的工作方式,就是只允许客户端主动请求,而服务端被动响应,一个 Request 对应 一个 Response,显然,这种工作模式会带来一些问题:无法实现实时的信息传递,就是如果这个数据发生了改变,服务器并不能主动通知到客户端。
举个例子,A 和 B两个客户端,在访问同一张在线表格,A 向表格中写了数据,ok,推到了服务端,告诉了服务端,表格数据有变化,服务端可以将表格的变化保存下来,但是 B 这边如何实时的看到表格发生了变化呢?
2、ajax 轮询和 long poll(长轮询)
ajax 轮询和 long poll(长轮询)都是试图解决 HTTP 协议无法直接支持服务器推送问题的方法,他们都是基于 HTTP 协议的。
ajax 轮询:
ajax 轮询的原理非常简单,就是让浏览器向服务端发送一次请求,服务器收到请求后立即返回响应,并关闭连接,然后过几秒后,重复刚刚的流程。
这样的缺点是:即使没有数据更新,客户端也会不断地发送请求,这样会导致大量无用的请求,浪费服务器资源和带宽,并且数据更新也不是实时性的,因为更新只能在客户端发送新请求时被检测到。
long poll:
long poll 是 ajax 轮询的改进版,都是采用轮询的方式,但是 long poll 采取的是阻塞模型,也就是说,客户端发起连接后,如果没有新消息,就一直不返回 Response 给客户端,直到有新消息才返回,返回完之后,客户端再次建立连接,周而复始。
虽然是 ajax 轮询的改进版,但是 long poll 也是基于 HTTP 协议的,会有开销大、有延迟的问题,并且实现起来较复杂。
可以看到,强行用 HTTP 实现实时功能,会有低效、伪实时的问题。
所以,基于上面的问题,就引入了 websocket。
二、websocket
websocket 提供了真正的全双工通信能力,服务器和客户端可以同时发送和接受消息,无需等待对方的响应。
在 websocket API 中,浏览器和服务器只需要完成一次握手,就可以创建持久性的链接,进行双向的数据传输,由于建立连接后,数据交换不需要 HTTP 的协议头,从而减少了网络传输的开销,因为是持久链接,消息可以立即从发送方推送到接收方,从而大幅度减少了通信延迟。
三、总结
总结一下:WebSocket 和HTTP 都是应用层的协议。 HTTP是构建Web应用的基本协议之一,适用于简单请求和资源下载。WebSocket 则提供了更为动态和实时的通信能力,特别适合需要连续数据交换的应用场景。尽管 WebSocket 在某些方面提供了比HTTP更优的功能,但它并不是想要取代HTTP。实际上,许多Web应用会同时使用这两种协议,根据不同的需求选择最合适的通信方式。
设计目的
-
HTTP(HyperText Transfer Protocol):是一种无状态的应用层协议,主要用于在客户端(例如浏览器)和服务器之间传输超文本(如HTML页面)。它是一个基于请求-响应模式的协议,在这个模式中,客户端发起请求后,服务器响应请求并返回数据。
-
WebSocket:是一个提供全双工通信通道的协议,设计目的是为了在一个持续开放的连接中实现服务器与客户端之间的实时双向数据传输。WebSocket被设计来工作在Web环境中,克服了HTTP在实时通信方面的限制。
连接方式
-
HTTP:是无状态的,每次请求都是独立的,每个请求-响应对都需要打开一个新的连接(HTTP/1.1支持持久连接,但本质上还是请求-响应模式)。这意味着每次交互都需要重新建立连接,这在交互频繁的实时应用中会产生较大的开销。
-
WebSocket:一旦通过初始的HTTP握手建立连接,该连接就会保持开放,直到客户端或服务器显式关闭为止。这使得数据可以在同一连接上快速双向传输,降低了开销和延迟。
数据传输
-
HTTP:典型使用请求-响应模型,客户端发起请求,服务器响应并返回所请求的资源。HTTP/2引入了服务器推送功能,但通信仍基于原始的请求-响应模式。
-
WebSocket:允许服务器主动向客户端发送数据,支持更高效的双向通信。WebSocket连接上的数据传输开销小,适合需要频繁且实时交换数据的应用。
使用场景
-
HTTP:由于其无状态和基于请求-响应的模式,非常适合于传统的页面请求、API调用和Web服务。在这些场景中,客户端请求特定资源,服务器响应请求。
-
WebSocket:非常适合需要实时功能的Web应用,如在线游戏、实时交易或交流平台、实时协作工具、直播弹幕等。WebSocket适用于客户端和服务器需要频繁且快速交换数据的情况。