websocket和http区别 (websocket前后端交互)

WebSocket和HTTP是两种常见的网络通信协议，它们在前后端交互中有许多不同之处。在本文中，我们将详细分析WebSocket和HTTP的区别以及它们在前后端交互中的应用。

1. HTTP协议：

HTTP（超文本传输协议）是一种无状态协议，通过在客户端和服务器之间发起请求和响应来进行通信。通常，当客户端需要从服务器获取数据时，会发起一个HTTP请求，并在收到服务器端响应后获取所需数据。连接会立即关闭，这被称为“短连接”。HTTP协议基于请求-响应模式，每个请求需要服务器进行处理后才能响应，这种模式导致了一些问题，比如频繁的请求和响应会增加网络负担。

2. WebSocket协议：

WebSocket是一种全双工通信协议，允许在单个TCP连接上进行双向通信。与HTTP不同，WebSocket在客户端和服务器之间建立了一个持久的连接，允许双方在不断开连接的情况下进行实时通信。这使得WebSocket非常适合需要实时数据传输的应用，比如在线游戏、聊天应用等。WebSocket提供了更高效的数据传输方式，减少了通信开销，提高了通信速度。

3. 区别分析：

（1）连接方式：HTTP是基于请求-响应模式，每次请求都需要建立连接，完成后立即断开；而WebSocket在客户端和服务器之间建立一个持久连接，可以保持连接状态，双方可以随时发送数据。

（2）通信效率：由于HTTP每次请求都需要建立连接，会增加网络开销；WebSocket通过单个TCP连接进行通信，不需要频繁建立连接，提高了通信效率。

（3）服务端推送：HTTP是被动传输模式，只能由客户端发起请求来获取数据；WebSocket支持服务端主动推送数据给客户端，实现了实时通信。

（4）协议头大小：HTTP协议头较大，传输数据时占用较多带宽；WebSocket协议头相对精简，减少了数据传输时的开销。

4. WebSocket在前后端交互中的应用：

WebSocket在前后端交互中的应用越来越广泛，特别适用于需要实时通信的场景。以下是一些常见的WebSocket应用：

（1）在线聊天应用：通过WebSocket实现客户端和服务器之间的实时聊天交流。

（2）在线游戏：WebSocket可以提供即时的游戏数据传输，实现多人在线游戏。

（3）实时数据监控：通过WebSocket可以实时更新数据，监控系统状态变化。

（4）实时股票行情：WebSocket可以将股票行情实时推送给客户端，方便投资者实时监控市场变化。

WebSocket和HTTP在前后端交互中有着明显的区别，WebSocket提供了更高效、实时的通信方式，适用于需要实时通信的应用场景。在选择协议时，需要根据具体需求来确定使用HTTP还是WebSocket。

刨根问底HTTP和WebSocket协议(二）

上篇介绍了HTTP1.1协议的基本内容，这篇文章将继续分析WebSocket协议，然后对这两个进行简单的比较。

上一篇中提到WebSocket的目的就是解决网络传输中的双向通信的问题，HTTP1.1默认使用持久连接（persistent connection），在一个TCP连接上也可以传输多个Request/Response消息对，但是HTTP的基本模型还是一个Request对应一个Response。这在双向通信（客户端要向服务器传送数据，同时服务器也需要实时的向客户端传送信息，一个聊天系统就是典型的双向通信）时一般会使用这样几种解决方案：

WebSocket的目的是取代HTTP在双向通信场景下的使用，而且它的实现方式有些也是基于HTTP的（WS的默认端口是 80 和 443 ）。现有的网络环境（客户端、服务器、网络中间人、代理等）对HTTP都有很好的支持，所以这样做可以充分利用现有的HTTP的基础设施，有点向下兼容的意味。

简单来讲，WS协议有两部分组成：握手和数据传输。

出于兼容性的考虑，WS的握手使用HTTP来实现（此文档中提到未来有可能会使用专用的端口和方法来实现握手），客户端的握手消息就是一个「普通的，带有Upgrade头的，HTTP Request消息」。所以这一个小节到内容大部分都来自于RFC2616，这里只是它的一种应用形式，下面是RFC6455文档中给出的一个客户端握手消息示例：

可以看到，前两行跟HTTP的Request的起始行一模一样，而真正在WS的握手过程中起到作用的是下面几个header域。

如果服务器接受了这个请求，可能会发送如下这样的返回信息，这是一个标准的HTTP的Response消息。 101 表示服务器收到了客户端切换协议的请求，并且同意切换到此协议。RFC2616规定只有切换到的协议「比HTTP1.1更好」的时候才能同意切换。

ws协议默认使用 80 端口，wss协议默认使用 443 端口。

在握手之前，客户端首先要先建立连接，一个客户端对于一个相同的目标地址（通常是域名或者IP地址，不是资源地址）同一时刻只能有一个处于CONNECTING状态（就是正在建立连接）的连接。从建立连接到发送握手消息这个过程大致是这样的：

如果客户端没有处于代理环境中，它就要首先建立一个到达目标地址的直接的TCP连接。

服务端指的是所有参与处理WebSocket消息的基础设施，比如如果某服务器使用Nginx（A）来处理WebSocket，然后把处理后的消息传给响应的服务器（B），那么A和B都是这里要讨论的服务端的范畴。

如果请求是HTTPS，则首先要使用TLS进行握手，如果失败，则关闭连接，如果成功，则之后的数据都通过此通道进行发送。

之后服务端可以进行一些客户端验证步骤（包括对客户端header域的验证），如果需要，则按照RFC2616来进行错误码的返回。

如果一切都成功，则返回成功的Response握手消息。

此握手消息是一个标准的HTTP Response消息，同时它包含了以下几个部分：

一旦这个握手发出去，服务端就认为此WebSocket连接已经建立成功，处于OPEN状态。它就可以开始发送数据了。

Sec-WebSocket-Version可以被通信双方用来支持更多的协议的扩展，RFC6455中定义的值为 13 ，WebSocket的客户端和服务端可能回自定义更多的版本号来支持更多的功能。其使用方法如上文所述。

WebSocket中所有发送的数据使用帧的形式发送。客户端发送的数据帧都要经过掩码处理，服务端发送的所有数据帧都不能经过掩码处理。否则对方需要发送关闭帧。

一个帧包含一个帧类型的标识码，一个负载长度，和负载。负载包括扩展内容和应用内容。

帧类型是由一个4位长的叫Opcode的值表示，任何WebSocket的通信方收到一个位置的帧类型，都要以连接失败的方式断开此连接。 RFC6455中定义的帧类型如下所示：

具体的每一项代表什么意思在这里就不做详细的阐述了。

同样作为应用层的协议，WebSocket在现代的软件开发中被越来越多的实践，和HTTP有很多相似的地方，这里将它们简单的做一个纯个人、非权威的比较：

这一篇简单地将WebSocket协议介绍了一遍，篇幅有点长了，数据帧也没有来得及详述。下篇会继续深扒WebSocket帧传输，另外将通过实例探讨一些WebSocket协议实际使用中的问题。

刨根问底HTTP和WebSocket协议(一） WebSocket和Socket的区别（WebSocket外传） 刨根问底HTTP和WebSocket协议(三）

HTTP 和 WebSocket的区别

按照OSI网络分层模型，IP是网络层协议，TCP是传输层协议，而HTTP是应用层的协议。 在这三者之间，SPDY和WebSocket都是与HTTP相关的协议，而TCP是HTTP底层的协议。 WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。 本质上来说，WebSocket是不限于HTTP协议的，但是由于现存大量的HTTP基础设施，代理，过滤，身份认证等等，WebSocket借用HTTP和HTTPS的端口。 由于使用HTTP的端口，因此TCP连接建立后的握手消息是基于HTTP的，由服务器判断这是一个HTTP协议，还是WebSocket协议。 WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。 WebSocket也有自己一套帧协议。

websocket原理是什么？

WebSocket是一种与HTTP不同的协议。两者都位于OSI模型的应用层，并且都依赖于传输层的TCP协议。

虽然它们不同，但是RFC 6455中规定：it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries；

（WebSocket通过HTTP端口80和443进行工作，并支持HTTP代理和中介），从而使其与HTTP协议兼容。

为了实现兼容性，WebSocket握手使用HTTP Upgrade头从HTTP协议更改为WebSocket协议。

WebSocket协议支持Web浏览器（或其他客户端应用程序）与Web服务器之间的交互，具有较低的开销，便于实现客户端与服务器的实时数据传输。

服务器可以通过标准化的方式来实现，而无需客户端首先请求内容，并允许消息在保持连接打开的同时来回传递。

通过这种方式，可以在客户端和服务器之间进行双向持续对话。 通信通过TCP端口80或443完成，这在防火墙阻止非Web网络连接的环境下是有益的。另外，Comet之类的技术以非标准化的方式实现了类似的双向通信。

大多数浏览器都支持该协议，包括Google Chrome、Firefox、Safari、Microsoft Edge、Internet Explorer和Opera。

与HTTP不同，WebSocket提供全双工通信。此外，WebSocket还可以在TCP之上实现消息流。TCP单独处理字节流，没有固有的消息概念。

在WebSocket之前，使用Comet可以实现全双工通信。但是Comet存在TCP握手和HTTP头的开销，因此对于小消息来说效率很低。WebSocket协议旨在解决这些问题。

WebSocket协议规范将ws（WebSocket）和wss（WebSocket Secure）定义为两个新的统一资源标识符（URI）方案，分别对应明文和加密连接。除了方案名称和片段ID（不支持#）之外，其余的URI组件都被定义为此URI的通用语法。

使用浏览器开发人员工具，开发人员可以检查WebSocket握手以及WebSocket框架。

优点

1、较少的控制开销。在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。

在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。相对于HTTP请求每次都要携带完整的头部，此项开销显著减少了。

2、更强的实时性。由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。

3、保持连接状态。与HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。

4、更好的二进制支持。Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容。

5、可以支持扩展。Websocket定义了扩展，用户可以扩展协议、实现部分自定义的子协议。如部分浏览器支持压缩等。

6、更好的压缩效果。相对于HTTP压缩，Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。

若对本页面资源感兴趣，请点击下方或右方图片，注册登录后

搜索本页相关的【资源名】【软件名】【功能词】或有关的关键词，即可找到您想要的资源

如有其他疑问，请咨询右下角【在线客服】，谢谢支持！