WebSocket/HTTP - 学习/实践_websocket转http

主要用于在浏览器和服务器之间建立一个不受限的双向通信的通道。

比如说，服务器可以在任意时刻发送消息给浏览器。

1. 文档

WebSocket - 廖雪峰的官方网站

使用ws - 廖雪峰的官方网站

编写聊天室 - 廖雪峰的官方网站

<<PHP核心技术与最佳实践>>

03 | 换个角度解决问题：服务端推送技术-极客时间 --  涉及到服务端主动推送消息

微信,QQ这类IM app怎么做——谈谈Websocket - 任淏 - 博客园

swoole入门到实战_哔哩哔哩_bilibili -- 主要是开发直播，聊天室 -- websocket 推荐学习

视频教程 -- 推荐，当你看文档看不下去的时候，推荐看看视频「选择适合自己的倍速」

WebSocket打造在线聊天室【完结】_哔哩哔哩_bilibili

【全网首发:已完结】『WebSocket』从JS到Vue2/3系列课程合集【业务必备】_哔哩哔哩_bilibili

2. 整理输出

1.介绍

WebSocket是 HTML5 新增的协议，它的目的是在浏览器和服务器之间建立一个不受限的双向通信的通道。

比如说，服务器可以在任意时刻发送消息给浏览器。

出现历史原因

为什么传统的HTTP协议不能做到WebSocket实现的功能？

这是因为HTTP协议是一个请求－响应协议，请求必须先由浏览器发给服务器，服务器才能响应这个请求，再把数据发送给浏览器。

换句话说，浏览器不主动请求，服务器是没法主动发数据给浏览器的。

这样一来，要在浏览器中搞一个实时聊天，在线炒股（不鼓励），或者在线多人游戏的话就没法实现了，只能借助Flash这些插件。

也有人说，HTTP协议其实也能实现啊，比如用轮询或者Comet。

轮询是指浏览器通过JavaScript启动一个定时器，然后以固定的间隔给服务器发请求，询问服务器有没有新消息。这个机制的缺点一是实时性不够，二是频繁的请求会给服务器带来极大的压力。

Comet本质上也是轮询，但是在没有消息的情况下，服务器先拖一段时间，等到有消息了再回复。

这个机制暂时地解决了实时性问题，但是它带来了新的问题：以多线程模式运行的服务器会让大部分线程大部分时间都处于挂起状态，极大地浪费服务器资源。另外，一个HTTP连接在长时间没有数据传输的情况下，链路上的任何一个网关都可能关闭这个连接，而网关是我们不可控的，这就要求Comet连接必须定期发一些ping数据表示连接“正常工作”。

以上两种机制都治标不治本，所以，HTML5推出了WebSocket标准，让浏览器和服务器之间可以建立无限制的全双工通信，任何一方都可以主动发消息给对方。

问题：

服务器不能直接请求客户端吗？

既然HTTP被设计成请求&响应的通信模型，而且从客户端请求服务端，服务端响应客户端，就知道，通信通道是存在的，并且可行的。

那么是否可以让服务端请求客户端呢，「客户端和服务端本来就是相对而言」

这里的客户端指的是用户的浏览器，服务器则是提供鼓舞的服务器

可以，比如两台服务器，自然可以由其中一台服务器「此时为客户端」主动发起请求，另外一台服务器「身份为服务端」接收请求，然后处理，响应。 

但是如果是用户的浏览器，则通常不可行，因为服务器没办法找到客户端，客户端首先要解决的是，如何让别人能够在公网上找到自己，但是普通用户的浏览器/电脑，通常没有公网IP，服务器也不知道客户端的公网IP，而且客户端的公网IP还可能是动态的，并不是固定的，域名更不用说了，没域名「作为服务器，要么通过域名访问，要么通过IP访问，还有端口，不论哪个，都要求是固定的，不然客户端也找不到服务端」

所以，可以知道，连接一定是由不确定的一方主动连接连接确定的一方「如果两者的通信地址都是确定，当然更可以」

那么有衍生出了问题：

在客户端主动连接了服务端后，并且是保持长连接，这里使用的是HTTP长连接。

「HTTP的长连接和短连接本质上，是TCP长连接和短连接」

那么，为什么不能服务端主动发送请求，或者说主动推送消息？

网上搜到的答案：

多是如下：

「HTTP协议遵循经典的客户端-服务器模型，客户端发送一个请求，然后等待服务器端的响应，服务器端只能在接收到客户端的请求之后进行响应，不能主动的发送数据到客户端。」

大致可以理解为：HTTP协议规定的就是这样，规定就是规定，没办法修改或者说修改的代价太大了。
 

不如重新创建一种新的通信协议，如：websocket

我想websocket就是这样出来的，因为存在理论上分析的可能，那么websocket的出现是必然的结果。「马克思主义基本原理中的知识， 这东西很有用，只是上学的时候，不觉得有什么用」

WebSocket协议

WebSocket并不是全新的协议，而是利用了HTTP协议来建立连接。

我们来看看WebSocket连接是如何创建的。

首先，WebSocket连接必须由浏览器发起，因为请求协议是一个标准的HTTP请求，格式如下：

GET ws://localhost:3000/ws/chat HTTP/1.1
Host: localhost
Upgrade: websocket
Connection: Upgrade
Origin: http://localhost:3000
Sec-WebSocket-Key: client-random-string // 客户端随机字符串
Sec-WebSocket-Version: 13

该请求和普通的HTTP请求有几点不同：

1. GET请求的地址不是类似/path/，而是以ws://开头的地址；
2. 请求头Upgrade: websocket， Connection: Upgrade表示这个连接将要被转换为WebSocket连接；
3. Sec-WebSocket-Key是用于标识这个连接，并非用于加密数据；
4. Sec-WebSocket-Version指定了WebSocket的协议版本。 

随后，服务器如果接受该请求，就会返回如下响应：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: server-random-string  // 服务端随机字符串

该响应代码101表示本次连接的HTTP协议即将被更改，更改后的协议就是Upgrade: websocket指定的WebSocket协议。

版本号和子协议规定了双方能理解的数据格式，以及是否支持压缩等等。如果仅使用WebSocket的API，就不需要关心这些。

现在，一个WebSocket连接就建立成功，浏览器和服务器就可以随时主动发送消息给对方。

消息种类

消息有两种，一种是文本，一种是二进制数据。

通常，我们可以发送JSON格式的文本，这样，在浏览器处理起来就十分容易。

为什么WebSocket连接可以实现全双工通信而HTTP连接不行呢？

实际上HTTP协议是建立在TCP协议之上的，TCP协议本身就实现了全双工通信，但是HTTP协议的请求－应答机制 限制 了全双工通信。

WebSocket连接建立以后，其实只是简单规定了一下：接下来，咱们通信就不使用HTTP协议了，直接互相发数据吧。

安全的WebSocket连接机制和HTTPS类似。

首先，浏览器用ws://xxx创建WebSocket连接时，会先通过HTTPS创建安全的连接，然后，该HTTPS连接升级为WebSocket连接，底层通信走的仍然是安全的SSL/TLS协议。

2.实现

浏览器

很显然，要支持WebSocket通信，浏览器得支持这个协议，这样才能发出ws://xxx的请求。

目前，支持WebSocket的主流浏览器如下：

Chrome

Firefox

IE >= 10

Sarafi >= 6

Android >= 4.4

iOS >= 8

服务器

由于WebSocket是一个协议，服务器具体怎么实现，取决于所用编程语言和框架本身。

Node.js本身支持的协议包括TCP协议和HTTP协议，要支持WebSocket协议，需要对Node.js提供的HTTPServer做额外的开发。已经有若干基于Node.js的稳定可靠的WebSocket实现，我们直接用npm安装使用即可。

PHP 支持的协议如下：

也可以操作TCP协议，但是需要安装扩展php_socket

PHP编程实现的TCP服务端和客户端的功能-php教程-PHP中文网

这里简单使用socket进行客户端服务端通信

支持的协议与封装协议/tcp-and-udp

1. 启动服务器

2. 启动客户端

3. 客户端发起消息请求

可以看到客户端，立刻收到服务端响应

服务端，则收到了客户端的请求消息，并回复～

上面不论是客户端，还是服务端只要有一个断掉，连接就会断掉，如server断掉，client 请求，程序出现报错～

3.个人实践

后端语言

nodeJS/PHP 各实现一个

nodeJS

聊天室：

GitHub - ningxiaofa/talking-room: Use websocket and koa to build a demo project -- talking room   // 有些库已经被摒弃，后面修复

效果如下：

分别开不同浏览器窗口【或者chrome的无痕窗口】，输入 localhost:3000 回车即可

可以看到可以相互通信～

后续补充

...

1. 所以不论是传统的http协议客户端主动发请求还是websocket服务端主动发起通信 都是先由客户端向服务端发起连接请求，先建立连接？

回答：

是的

对于HTTP协议来说，客户端需要先向服务端发送请求才能建立连接。每个HTTP请求都需要需要包含完整的报文头和请求体，其中报文头中会包含一些关于请求的信息，比如请求URL、请求方法、请求头等。

而对于WebSocket协议来说，则是由客户端向服务端发起握手请求，通过握手过程来建立连接。在握手过程中，客户端会向服务端发送一个HTTP请求，然后服务端返回一个包含特定的响应头信息的HTTP响应数据包。如果握手成功，连接就建立完成了。

在WebSocket连接建立之后，服务端可以通过WebSocket协议主动向客户端发送消息。这种方式相对于HTTP协议来说更加灵活，同时也更适合实时通信场景下的数据传输。

2. 服务端能否主动向客户端发起连接请求？

在一般的网络通信场景中，服务端是不能主动向客户端发送连接请求的，因为在大多数情况下，客户端处于一个比较安全的内网环境中，不会暴露在公网上。而服务端则通常处于公网或者云服务器等位置，有公网IP地址可以被客户端访问到。

因此，在大多数情况下，只有客户端才能主动向服务端发起连接请求。当然，也有一些特殊情况，例如在使用VPN、内网穿透等技术的情况下，服务端也可以通过一些手段实现向客户端发起连接请求的功能。但这种情况属于特殊情况，并不是一般的网络通信方式。

3. 浏览器请求服务器，服务器收到请求，返回响应给客户端，是如何找到位于内网中的浏览器的？

在一般的网络环境下，位于内网中的浏览器无法直接被服务器访问，因为内网通常是一个相对封闭的网络环境，不会直接暴露在公网上。

为了实现在公网上访问内网中的资源，一般可以使用一些技术手段，例如：

1. NAT(Network Address Translation)：通过配置路由器等设备，将内网中的IP地址和端口号映射到公网IP地址和端口号上，使得公网用户可以通过访问公网IP地址和端口号来访问内网资源。

2. VPN(Virtual Private Network)：通过建立VPN连接，在公网上创建一个虚拟的私有网络，使得公网用户可以通过VPN连接到内网，并访问内网中的资源。

3. 内网穿透技术：通过一些开源软件或者第三方平台提供的服务，实现将内网应用程序映射到公网上，使得公网用户可以通过访问公网地址和端口号来访问内网中的资源。

无论是哪种方式，都需要在配置时指定要访问的内网机器的IP地址和端口号。当浏览器向服务器发起请求时，请求中携带了目标服务器的IP地址和端口号，服务器就可以将响应发送到目标IP地址和端口号对应的设备上。如果该设备是内网中的浏览器，就可以将响应返回给内网中的浏览器了。

4. 所以，服务端将响应返回给客户端浏览器也是要通过NAT技术进行IP的转换才行？

是的，当客户端浏览器处于内网中，而服务器在公网上时，服务端返回响应给客户端浏览器也需要经过NAT(Network Address Translation)技术进行IP地址的转换才能实现。因为只有通过NAT技术将内网中浏览器的IP地址和端口映射到公网的IP地址和端口上，才能保证公网用户能够通过正确的IP地址和端口访问到内网中的浏览器，从而完成服务端向客户端的数据传输。

在这个过程中，还需要注意一些安全性问题，比如防止内网机器被恶意攻击等。因此，在配置NAT规则时需要谨慎设置，避免出现安全漏洞。同时，也需要保证网络环境的稳定性和质量，以确保数据传输的可靠性和性能。

5. websocket是基于http长连接或者说是基于tcp的长连接？

WebSocket是基于TCP协议的长连接技术，不是基于HTTP长连接。

在WebSocket中，客户端和服务端通过HTTP协议进行握手，之后协议会从HTTP协议切换到WebSocket协议。这种方式相对于传统的HTTP请求-响应模式更加高效，因为在建立WebSocket连接之后，通信双方可以直接互相发送数据，而不需要像HTTP那样每次都要建立新的连接。

WebSocket的长连接特性可以有效降低网络开销，并且支持双向实时通信，能够满足很多实时性要求较高的应用场景。由于基于TCP协议的长连接具有较高的可靠性和稳定性，所以WebSocket也被广泛应用于一些在线游戏、聊天室等实时通信场景中。

6. 除了浏览器支持websocket协议吗 还有哪些？

WebSocket协议并不仅仅是浏览器所支持的，它还可以被其他客户端或者服务器端应用程序使用。

一般来说，只要是基于TCP协议的网络应用程序都可以使用WebSocket协议。例如，在Java中，可以使用Java WebSocket API、Tomcat WebSocket等技术实现WebSocket协议；在Python中，可以使用Tornado、websockets等库实现WebSocket协议；在Node.js中，也有多个WebSocket库可供选择，比如ws、socket.io等。

此外，许多著名的Web框架和应用服务器，如Spring Framework、Netty、Jetty、Apache httpd等也提供了对WebSocket的支持。这些工具和框架封装了底层的WebSocket实现细节，使得开发者可以方便地集成WebSocket功能到自己的应用程序中，而且能够更加高效地处理连接管理、数据传输等问题。

总之，WebSocket协议是一个通用的协议标准，不仅限于浏览器，各种客户端和服务器端应用程序都可以使用。

7. 有哪些常见APP是基于websocket进行通信的？列出出来

WebSocket协议作为一种高效、实时的双向通信技术，被广泛应用于各种手机APP场景中。

以下是一些常见的基于WebSocket协议进行通信的APP：

1. 微信：微信的聊天功能使用了WebSocket协议，可以实时地在不同设备之间同步聊天记录。

2. 钉钉：钉钉的即时通讯功能也采用了WebSocket协议，可以快速地发送和接收消息。

3. Slack：Slack是一款办公场景的即时通讯工具，其聊天和通知功能也使用了WebSocket协议。

4. Telegram：Telegram是一个加密的即时通讯应用程序，支持多设备同步，而且也使用了WebSocket协议。

5. Zoom：Zoom是一款在线视频会议软件，在数据传输方面采用了WebSocket协议，可提供更加流畅的音视频体验。

除了上述应用之外，很多其他的社交、游戏、在线教育等应用程序也采用了WebSocket协议来实现实时或低延迟通信。WebSocket在移动端应用场景中具有较好的传输性能和用户体验，大大提升了移动应用程序的交互性和实时性。

额外问题

微信的音视频通话功能使用的是什么技术？什么通信协议？

微信的音视频通话功能使用了WebRTC技术进行实现，通信协议是基于UDP的SRTP协议。

WebRTC是一个开源的应用程序接口(API)，可以在网页和移动应用程序中实现实时通信功能，包括音频、视频、数据传输等。WebRTC通过P2P技术建立点对点连接，不需要经过服务器进行中转，大大降低了通信的延迟和网络带宽的消耗。

在微信中，当用户发起音视频通话请求时，客户端会通过WebRTC建立点对点连接，并使用基于UDP的SRTP协议进行音视频数据传输。SRTP采用了加密和认证机制，可以保证数据的安全性和可靠性。同时，WebRTC还支持众多的编解码器和网络传输协议，可以根据不同的场景需求进行选择和配置，提供最优的音视频体验。

总之，WebRTC是一种成熟的音视频通信技术，由于其低延迟、高质量的特点，得到了越来越广泛的应用。

“WebRTC通过P2P技术建立点对点连接，不需要经过服务器进行中转，” 什么意思 比如微信，难道不经过微信服务器进行中转，甚至数据存储？

对于WebRTC建立点对点连接的过程，通常需要经历三个阶段，包括信令传递、NAT穿透和媒体传输。其中，在信令传递阶段中，需要借助服务器进行协商和中转。

在微信等实时通信应用中，WebRTC也不例外，因为这些应用需要对用户的网络环境进行检测、数据传输进行控制和管理、安全性保护等操作。因此，这些应用会提供一些服务器支持，例如用于信令传递、NAT穿透、媒体转发等功能。

具体来说，在进行WebRTC通信时，客户端需要通过服务器进行信令传递，以协商双方的ICE（Interactive Connectivity Establishment）信息，包括IP地址和端口号等信息。在这个过程中，服务器起到了中转和协调作用，但并不负责音视频数据传输和存储。

当点对点连接建立完成后，数据将直接在两个终端之间传输，而不需要经过服务器中转。

因此，可以说，WebRTC是一种P2P技术，但实际应用场景中需要依赖服务器的支持。与传统的CS架构相比，WebRTC更加注重点对点传输的优化，减少了服务器的中转和带宽消耗，从而提高了通信的性能和质量。

为什么微信的聊天功能使用了WebSocket协议 但是音视频通话功能使用基于UDP的SRTP协议？

微信的聊天功能和音视频通话功能使用不同的协议，主要是因为它们面对的场景和需求不同。

WebSocket协议适用于长连接、低延迟、数据量小的通信场景，例如即时消息（IM）、推送消息等。相比于HTTP请求-响应模式，WebSocket建立了持久性的双向连接，可以实现实时交互以及更快速地传输数据。在微信的聊天功能中，由于消息体积较小且需要实时传输，采用WebSocket协议可以更好地满足这种需求。

实际上，WebSocket协议适用于需要保持实时通信的场景，包括在线游戏、聊天室、股票行情等。这些场景中，需要客户端和服务端之间能够实时地交换数据，而且连接需要进行长时间维持。

相比于基于HTTP的长轮询或者短轮询方式，WebSocket协议具有更低的延迟、更高的效率和更好的性能表现。虽然WebSocket协议也可以传输大量数据，但由于它需要使用一定的带宽资源，因此在传输大量数据时，可能会导致网络负荷过大，从而影响性能。因此，一般来说，WebSocket协议更适合数据量小、频繁传输、需要实时通信的场景。

而音视频通话则需要高质量的音视频传输效果，包括低延迟、高带宽、稳定性等。相比于TCP协议，UDP协议具有更低的延迟和更高的传输效率，尤其是在多媒体数据传输方面表现得更优秀。因此，在微信的音视频通话中，采用基于UDP的SRTP协议，可以更好地保障音视频数据的传输质量和实时性。

总之，WebSocket协议和基于UDP的SRTP协议都有各自的优势和适用场景。微信根据不同的业务需求选择不同的通信协议，从而提供更优质的用户体验。