-
WebSocket协议
-
特点:
- 有状态的持久连接
- 服务端可以主动推送消息
- 用 WebSocket 发送消息延迟比 HTTP 低
- WebSocket协议握手是从HTTP握手升级而来的,即建立WebSocket连接首先要先建立HTTP连接,然后双方协商后使用WebSocket进行通讯。
- WebSocket应用既不需要关心WebSocket连接,实际上是HTTP升级来的,又不需要关心如何生成一个可以升级到WebSocket的HTTP连接。只需关注来自服务端的消息以及根据自己的需求发送给服务端的消息。WebSocket应用在创建一个WebSocket连接后,监听服务端发来的消息,适时向服务端发送消息就可以了,完成应用的目的即可。
-
代码实例
-
服务器端:
const { WebSocketServer } = require('ws'); const wss = new WebSocketServer({ port: 8080 }); wss.on('connection', function connection (ws) { // 有新连接时监听来白客户端的消息 wS.on("message", function message(data) t // 打印收到的消息,再把消息原封不动地发回给客户端 console.log('received: %s', data); ws.send (data); }); });
-
-
三. 在HTTP之外还有什么影响网络服务表现的捏
-
CDN的好处:
-
你无法突破物理极限的 (速度)
(
- HTTP3快吗?
- 快!
- 那从美国到中国,HTTP 3要多久?150ms.
- 和北京到上海比,还快吗?
- 好像不够?
)
-
你的钱包够鼓吗?(成本)
(
- 流量多少钱一个 G?
- 1块
- 那我在北京给上海的人发一部10G 电影得 10块?
- 对!
- 发10次一样的电影要 100 块?
- 是的!
- 我都发到上海了,不能内部共享下吗?
)
-
你,够强大吗?(稳定)
(
- 我们有几台服务器?
- 1台
- 他能抗多少流量?
- 100G!
- 双十一峰值得 1000G 啊,扛得佳吗?
- 不一定,可能挂……
)
故从这三个方面来看,内容分发网络(CDN)便必不可少了
-
-
CDN带来的问题
-
通常域名解析服务会将一个域名对应解析为一个IP,而一个IP通常又只对应一台服务器 (当然这句话并不严谨,如果使用anycast任拨技术,是允许多台服务器共享一个IP的,Google的DNS服务8.8.8.8就是用到了该技术,如果你从世界上的不同区域ping这个IP,你会发现有着相近的延迟),那又该如何让不同地区的用户访问到不同的服务器捏
答案是DNS 劫持
-
域名解析一般由网站自己处理
-
要加速的域名则重定向到 CDN 厂商的域名解析服务处理
-
CDN厂商根据来源确定最近的 CDN 服务器的 IP
-
用户直接访问最近的 CDN 服务器
- (当然这里的最近,并不一定完全指的是物理距离,因为如果用户离两个CDN服务器的物理距离只差只有几十公里,稍远的那个相较于稍近的那个,所需经过的节点更少,但其实这种距离的传播时延,相较于转发实验是要更短的,所以这时候选择物理距离最短的就并不是最合理的选择了)
- (如果用户并不是使用当地网络服务提供商提供DNS服务,而是使用其它的DNS服务,比如谷歌提供的DNS服务就可能适得其反了)
- (CDN服务器的负载,服务器与用户之间的网络负载等因素,也都会影响到最终用户访问的速度和质量)
所以选择CDN服务器的策略是十分复杂的
-
-
如果一个网站将自己的所有内容资源都在各个CDN服务器上备份一遍,成本是巨大的,比如视频网站,所以大部分网站都会使用响应的策略,即只将部分内容分发在CDN,这样既保证了大部分用户的使用体验,也降低了成本。
-
拉策略 (用户导致的 CDN拷贝)
- 默认情况下什么也不做
- 谁需要了,先看看仓库有没有
- 有,直接给
- 没有,你等着,我去买个橘子
- (每隔几天)这都啥啊,丢了
-
推策略 (网站导致的 CDN拷贝)
- 大哥说今天你存这些,明天存那些
- 谁需要了,先看看仓库有没有
- 有,直接给
- 没有,你等着,我去买个橘子
- 大哥说这个、这个还有这个,丢了
-
热门资源使用推策略,冷门策略使用拉策略,CDN从物理层面解决了HTTP协议无法解决的问题,进而提升Web应用性能
-
-