HTTP , Websocket

Http历史

http 0.9

这个版本的http协议只有请求行。 接着服务器返回一个HTML文件。采用ASCII编码

• 极其简单：只支持GET方法

• 只有请求行：GET /index.html（没有HTTP版本号）

• 没有请求头：不能指定接收格式等信息

• 只返回HTML：无法传输其他类型文件

http 1.0

这时候开始，协议加入了请求头请求体，例如可以在请求头中指定发送文件的格式，接收文件的格式。并且引入了状态码。

• 新增方法：增加了POST和HEAD方法

• 引入状态码：如200(成功)、404(未找到)等

• 支持多种文件类型：通过Content-Type指定

http1.1

这时用户量激增，每次请求都需要建立握手挥手的过程，太麻烦了。于是引入了长连接机制，能够多次请求复用同一个连接。

还引入了管线化机制，多次请求可以同时按顺序发送，不用等前一个请求的响应完成，但是接收响应必须按照发送请求的顺序来接收，这样就会导致队头堵塞问题。

流式输出

HTTP2.0

采用了二进制分帧，将请求分成很多个二进制帧，分为首部帧和数据帧。这样虽然传输的总时长不变，但是更小的请求能更快到达。每个帧有一个并且多个请求的请求头往往高度一致，采用了头部压缩算法，减少传输体积。

多路复用机制：

单一的TCP连接被分为多条数据流，每个帧有标识。接收方根据表示重新组装成整的数据。

• 一条高速公路有多个双向车道

• 每个车道都被分成两部分：上行道和下行道

• 上行道的车流不会影响下行道的车流

• 不同车道之间也互不影响

还有一个服务器主动推送机制。服务器可以主动推送多个文件给客户端。

HTTP 3.0

• 基于UDP的QUIC协议，而非TCP

• 改进的多路复用，彻底解决队头阻塞

• 更快的连接建立（0-RTT）

• 内置加密（TLS 1.3）

常用HTTP响应码

• 100 用于接收到请求头，客户端可以继续发送请求体。

• 101 协议升级 用于websocket或HTTP/2升级

• 102 接收到了正在处理，防止客户端超时

• 200 成功

• 204 请求成功，没有返回体，如预检请求。

• 301 资源移动到新的url

• 304 资源未更改

• 307 临时重定向

• 308 永久重定向

• 400 请求参数错误

• 401 未授权

• 404 notFound

• 500 服务器代码异常

• 505 客户端使用过旧或过新HTTP版本

TLS

最开始内容是明文处理，这时候任何人都能对内容进行处理。后来就引入了对称加密。我们先把密钥发出去，接着密钥给内容上锁，服务器用密钥解锁。但是中间人也能拦截密钥，用密钥解锁，整个过程如同虚设。

非对称加密： 服务器先把公钥发过去。这时候客户端使用公钥对内容加密，再发送给服务器。中间人用公钥打不开，服务端有私钥可以解密内容。

但是攻击者可以掉包服务端的公钥，把自己的公钥替换成服务器的，这时候客户端以为是服务端的公钥，毫不犹豫的加密，攻击者就可以用自己的私钥解密，同时用服务端的公钥加密内容返回给服务器，这就是中间人攻击。

服务端把自己的域名，公钥等信息发送给CA机构，CA审核后用非对称加密的方式加密，加密的内容就变成了证书，之后肉身送给服务端（是通过电话，电子邮件，物理邮件等多种信道降低中间人攻击的风险），又把CA公钥运送给客户端。

HTTP缓存

浏览器首先会去检查有没有强缓存，没有再去检查协商缓存。

强缓存

当服务器返回响应头 Expires,Cache-Control中的一个，会触发强缓存。ctrl + f5 强制刷新。 Expires是设置缓存日期，cache-Control 可以设置缓存时间max-age ,no-cache 等。因为可能会出现服务器与客户端时间不一致的情况。 paragma： 设置no-cache 跟上面的效果一致，不过优先级最高。

协商缓存

就是客户端去询问一下资源有没有变化。服务器对比，不变则返回304状态码更改则返回更改后的资源。 ETags（优先级高） 根据文件内容生成hash值。 Last-modified 文件最后修改时间

当文件修改频率为秒级别，这样会出现漏判，并且当文件修改但是内容不发生变化，也会失去缓存。

1. ETag类型：

• 强ETag：ETag: "abc123"（字节级完全匹配）

• 弱ETag：ETag: W/"abc123"（语义上相同即可）

1. 请求头匹配：

• ETag对应If-None-Match请求头

• Last-Modified对应If-Modified-Since请求头

问题:

1. 针对以下状态码，解释它们的具体含义和使用场景：401 vs 403、307 vs 308。

401（未授权） vs 403（无权访问）、307（内容暂时迁移） vs 308（内容永久迁移）。

3. 在实际项目中，你如何优化缓存策略来提高性能同时确保内容及时更新？ 静态资源（图片，css，js）通过长期的强缓存来设置，HTML文档通过协商缓存，API响应根据数据变化合理设置强缓存。

Websocket

websocket 是全双工通信协议，他是基于基于TCP协议的。协议标识符为ws，如果加密就为wss。

大家可能会想，http2也能进行主动推送啊，有什么区别吗？

1. 服务器只能在收到客户端初始请求后才能推送相关资源，不能完全主动发起通信。

1. 推送内容有限：主要用于推送静态资源（如CSS、JS文件），不适合推送动态生成的数据

1. 缺乏真正的实时性：不是为持续的实时通信设计的

连接过程

客户端发起http请求，进行三次握手。

发送的信息中存在协议升级的信息。例如connection:upgrade upgrade:websocket websocket-version

客户端收到信息后返回http协议：101状态码表示协议升级，

心跳检测

步骤： 客户端他会去向服务端发送一个数据包，同时设置一个定时器 服务器向客户端返回一个数据包。 假如客户端到定时器到时了还没收到数据包，就证明连接断开了。 假如用户收到了消息，就把旧的定时器清除。

• 建议值：20-60秒，视应用场景而定
• 尽量小：减少网络负担

已经有了onclose和onerror 事件，仍然需要心跳检测，例如防止网络突然中断：双方无法进行tcp关闭。

断线重连

当监听到onclose事件onerror或者心跳检测不到，这时候就会进行断线重连。我们通常会设置重连的次数，以及重连时间间隔（退避指数算法）。接着自己去进行数据的恢复，例如给每条信息设置ID，接着根据ID继续上传，确认消息的幂等性，安全性。

问题：

1. WebSocket的关闭握手（Close Handshake）是如何工作的？不同的关闭码（Close Code）代表什么？

任一方（客户端或服务器）可以通过发送包含关闭码和可选关闭原因的关闭帧来启动关闭

确认关闭：接收方收到关闭帧后，会回复一个关闭帧作为确认

终止TCP连接：完成关闭帧交换后，发起方负责关闭底层TCP连接

完成关闭：接收方检测到TCP连接关闭后，也关闭自己的连接

3. 如何实现WebSocket的身份验证？ websocket只有在最开始握手使用http协议，有请求头。后续是没有请求头的。我们可以通过先使用http进行身份验证，然后进行协议升级。或者URL直接传递token过去。

4. 跨域WebSocket连接是如何处理的？与HTTP CORS有何不同？ 在握手阶段跟HTTP请求完全一致，，利用这个时间进行检查。 但是后续的消息发送不会跨域。

5. WebSocket连接和代理服务器。 代理服务器确实同时与客户端和服务器建立两个TCP连接，然后在这两个连接之间转发数

6. WebSocket是全双工通信，这和HTTP/2的多路复用有什么本质区别？

全双工通信是同一个tcp连接有来回两条信道，请求和响应互不影响，就像汽车的双行道。多路复用是一个tcp连接创建多个数据流，实现并行通信，就像有多条赛道，每条赛道有着双行道。但是仍然遵守着请求响应模式。