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

WebSocket是一种在Web应用程序中实现实时双向通信的协议，其与传统的HTTP通信方式有着显著的区别。本文将从WebSocket与HTTP的区别、WebSocket的优势、前后端交互的基本过程等方面展开详细分析。

WebSocket与HTTP的区别

WebSocket与HTTP最大的区别在于通信方式不同。HTTP是一种无状态协议，即每次请求都是独立的，服务器收到请求后返回响应就断开连接；而WebSocket是基于TCP协议的全双工通信方式，一旦建立连接，客户端与服务器端之间可以实现双向通信，不需要每次都重新建立连接。

HTTP通信是基于请求-响应模式的，每次通信都需要客户端发送请求，服务器接收并返回响应，这种方式适用于传统的Web页面加载、数据交互等操作。而WebSocket更适合于需要实时性、非阻塞的数据通信场景，比如在线聊天、实时数据监控等。

WebSocket的优势

WebSocket相对于HTTP有以下几个明显的优势：

1. 实时性：WebSocket可以实现实时的双向通信，无需频繁建立连接，传输速度更快。

2. 减少网络流量：由于WebSocket建立一次连接后可以持续通信，避免了每次请求都需要携带HTTP头的开销，减少了网络流量。

3. 节省服务器资源：WebSocket的连接是持久的，不同于HTTP每次请求都需要服务器开启新的连接，可以减少服务器的资源消耗。

4. 适应性强：WebSocket可以在浏览器和服务器之间建立双向通信，支持复杂的应用场景。

前后端交互的基本过程

在使用WebSocket进行前后端交互时，通常会经过以下基本过程：

1. 建立连接：客户端通过WebSocket协议与服务器端建立连接，一般是通过ws://或wss://开头的URL来建立连接。

2. 握手阶段：在建立连接后，客户端和服务器会进行握手协议，确认连接的有效性。

3. 数据交互：连接建立后，客户端和服务器可以进行双向通信，可以发送和接收数据，实现实时交互。

4. 关闭连接：通信结束后，客户端或服务器可以发送关闭连接的请求，结束通信。

在实际应用中，前端通常会使用JavaScript提供的WebSocket API来创建WebSocket对象，建立与服务器端的连接，并通过该对象发送和接收数据。后端需要实现WebSocket协议，处理客户端的连接请求，接收和发送数据。

总结

通过以上分析可见，WebSocket与HTTP在通信方式、实时性、网络流量等方面有着显著的区别，WebSocket更适合实时性要求高、双向通信需求较大的场景。了解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也有自己一套帧协议。

刨根问底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协议(三）

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在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。

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

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

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