常见面试题

基本概念

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。HTTP 协议是一个双向协议,是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。是超越了普通文本的文本，它是文字、图片、视频等的混合体，最关键有超链接，能从一个超文本跳转到另外一个超文本。

1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

• 「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
• 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

• 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。
• 「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。
• 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

• 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。
• 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。
• 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

• 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。
• 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。
• 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
• 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

Host 字段：客户端发送请求时，用来指定服务器的域名。
服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。HTTP 协议通过设置回车符、换行符作为 HTTP header 的边界，通过 Content-Length 字段作为 HTTP body 的边界，这两个方式都是为了解决“粘包”的问题。
Connection 字段最常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用。HTTP 长连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。HTTP/1.1 版本的默认连接都是长连接，但为了兼容老版本的 HTTP，需要指定 Connection 首部字段的值为 Keep-Alive。
Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。
Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式。客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。

GET 与 POST

根据 RFC 规范，GET 的语义是从服务器获取指定的资源，GET 请求的参数位置一般是写在 URL 中，URL 规定只能支持 ASCII，所以 GET 请求的参数只允许 ASCII 字符 ，而且浏览器会对 URL 的长度有限制（HTTP协议本身对 URL长度并没有做任何规定）。

根据 RFC 规范，POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 请求携带数据的位置一般是写在报文 body 中，body 中的数据可以是任意格式的数据，只要客户端与服务端协商好即可，而且浏览器不会对 body 大小做限制。

安全和幂等的概念：

• 在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
• 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。

从 RFC 规范定义来看：

• GET 的语义是请求获取指定的资源。GET 方法是安全、幂等、可被缓存的。
• POST 的语义是根据请求负荷（报文主体）对指定的资源做出处理，具体的处理方式视资源类型而不同。POST 不安全，不幂等，（大部分实现）不可缓存。

具体来看，新增删除数据使用 GET 方法，这样 GET 就不是安全幂等的；同理，查询数据使用 POST，那么 POST 是安全幂等的，这需要看开发者自行开发的方法。 这里注意，HTTP 传输的内容都是明文的，虽然在浏览器地址拦看不到 POST 提交的 body 数据，但是只要抓个包就都能看到了。所以，要避免传输过程中数据被窃取，就要使用 HTTPS 协议，这样所有 HTTP 的数据都会被加密传输。

理论上，任何请求都可以带 body 的。所以之前说的 GET 也可以带 body，只是 RFC 规范下 GET 不需要用到 body。

HTTP 缓存

避免发送 HTTP 请求的方法就是通过缓存技术，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

• 强制缓存

只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。

强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期：

• Cache-Control， 是一个相对时间；
• Expires，是一个绝对时间；

Cache-Control 的优先级高于 Expires 。且该字段选项更多更精细。使用时，第一次请求访问的时候就会初始化该字段设置好过期时间，之后再次请求，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，同时会更新 Cache-Control。

• 协商缓存

某些请求的响应码是 304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。

可以基于两种头部来实现。

第一种：可以基于两种头部来实现。

第一种：请求头部中的 If-Modified-Since 字段与响应头部中的 Last-Modified 字段实现，这两个字段的意思是：

• 响应头部中的 Last-Modified：标示这个响应资源的最后修改时间；
• 请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。

第二种：请求头部中的 If-None-Match 字段与响应头部中的 ETag 字段，这两个字段的意思是：

• 响应头部中 Etag：唯一标识响应资源；
• 请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头 If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的；后者会更加靠谱。如果在第一次请求资源的时候，服务端返回的 HTTP 响应头部同时有 Etag 和 Last-Modified 字段，那么客户端再下一次请求的时候，如果带上了 ETag 和 Last-Modified 字段信息给服务端，这时 Etag 的优先级更高。

注意，协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

HTTP 特性

HTTP 常见到版本有 HTTP/1.1，HTTP/2.0，HTTP/3.0，不同版本的 HTTP 特性是不一样的。

这一节主要针对 HTTP/1.1 展开，最突出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。缺点分别是「无状态、明文传输」，同时还有一大缺点「不安全」。

对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了。

HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

HTTP 协议是基于 TCP/IP，并且使用了「请求 - 应答」的通信模式，所以性能的关键就在这两点里。

HTTP/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。同时也因为长连接，使得管道（pipeline）网络传输成为可能，可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。

如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。这里注意，HTTP/1.1 管道技术默认不开启且浏览器基本不支持该功能。

HTTP 与 HTTPS

HTTPS 在 TCP 三次握手后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。HTTP 默认端口号是 80，HTTPS 默认端口号是 443。同时，HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

HTTPS通过混合加密、摘要算法以及身份证书，来完成对 HTTP 传递明文的内容完成加密。

• 混合加密

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

• 摘要算法 + 数字签名

在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。如果哈希值相同则可证明内容未被篡改。但是该算法并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

为了判断消息是否来自于服务端，会用非对称加密算法来解决，共有两个密钥：

• 一个是公钥，这个是可以公开给所有人的；
• 一个是私钥，这个必须由本人管理，不可泄露。

这两个密钥可以双向加解密：公钥加密私钥解密则可保证内容传输的安全；私钥加密公钥解密则保证消息不会被冒充。非对称加密的用途主要在于通过「私钥加密，公钥解密」的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。

私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

• 数字证书

CA 通过自己的私钥把服务端的公钥做了数字签名，把「个人信息 + 公钥 + 数字签名」打包成一个数字证书；客户端使用时会通过 CA 验证数字证书是否合法，CA 验证成功后就可以证明服务端的公钥合法，完成身份验证。

SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

前两步就是 TLS 握手阶段，涉及四次通信，使用不同的密钥交换算法，TLS 握手流程也会不一样的，现在常用的密钥交换算法有两种：RSA 算法和 ECDHE 算法。其中 RSA 算法相对容易。

以下会进行具体分析：

• ClientHello

首先会客户端向服务器发起加密通信请求，这里需要发送客户端的 TLS 版本，产生的随机数（Client Random，用于生成「会话秘钥」条件之一），以及支持的密码套件列表（如 RSA 算法）。

• ServerHello

服务器收到客户端请求后，向客户端发出响应，包含确认 TLS 版本，服务器生成的随机数（Server Random，用于生产「会话秘钥」条件之一），确认的密码套件列表以及服务器的数字证书。这里就是三个确认+ CA。

• 客户端回应

客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：一个随机数（pre-master key，会被服务器公钥加密）；加密通信算法改变通知，表示之后信息用「会话秘钥」加密通信；客户端握手结束通知，会把之前的数据做摘要供服务端校验。

服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

• 服务器最后回应

计算得到「会话秘钥」，发送最后的信息：加密通信算法改变通知，表示之后都用「会话秘钥」加密通信；服务器握手结束通知，会把之前数据做摘要供客户端校验。

TLS 至此全部结束，接下来证实进入加密通信，就是完全的 HTTP 协议，只不过用「会话秘钥」加密内容。

这里在学一下 CA 具体的签发和验证流程。

签发证书：

• CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
• 通过自己的私钥将 Hash 值加密，生成 Certificate Signature，也就是签名；
• 将 Certificate Signature 添加在文件证书上，形成数字证书。

校验证书：

• 使用同样 Hash 算法获取该证书 Hash 值 H1；
• 通过浏览器和操作系统中集成的 CA 公钥，解密 Certificate Signature 内容，得到 Hash 值 H2；
• 比较 H1 和 H2，相同则为可信赖证书。

证书的验证过程中还存在一个证书信任链的问题，操作系统会内置一些根证书，通过根证书的信任一层层到中间证书再到服务器证书。搞证书链是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。

TLS 在实现上分为握手协议和记录协议两层：

• TLS 握手协议就是我们前面说的 TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据（即 HTTP 数据）；
• TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议。

记录协议，及时现将消息分割切片并压缩后，在压缩片段后加上消息认证码（MAC 值，这个是通过哈希算法生成的），这是为了保证完整性，并进行数据的认证。之后会将加上消息认证码的报文一起通过对称密码加密，并在加密数据前加上数据类型、版本号以及压缩后长度完成最终的报文数据。

HTTPS 协议本身到目前为止还是没有任何漏洞的，即使你成功进行中间人攻击，本质上是利用了客户端的漏洞（用户点击继续访问或者被恶意导入伪造的根证书），并不是 HTTPS 不够安全。为了解决这种问题，可以通过 HTTPS 双向认证来避免。

HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

• 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应。

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 安全性是有保障的。那 HTTP/2 相比 HTTP/1.1 性能上的改进主要有四个方面。

• 头部压缩

HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。这里就是用了 HPACK 算法，客户端和服务端同时维护一个头信息表，只需要发送索引号作为头。

• 二进制格式

全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。这样就可以在收到报文后直接解析二进制，增加数据传输效率。

• 并发传输

引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。Stream 里可以包含 1 个或多个 Message，Message 对应 HTTP/1 中的请求或响应，由 HTTP 头部和包体构成。Message 里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和包体）。

针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。

• 服务器推送

服务端不再是被动地响应，可以主动向客户端发送消息。客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

虽然 HTTP/2 解决了 HTTP/1 队头阻塞问题，但是 TCP 层面仍有问题。HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。也就是说，一旦丢包，那么在这个 TCP 连接中所有 HTTP 请求都必须等待丢失包重传回来。

HTTP/3 为了解决 HTTP/2 的 TCP 层面的队头阻塞问题，把 HTTP 下层的 TCP 协议改成了 UDP。

虽然 UDP 是不可靠传输，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

• 无队头阻塞

可以在同一条连接上并发传输多个 Stream，Stream 可以认为就是一条 HTTP 请求。QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。

• 更快的连接建立

对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。

HTTP/3 在传输数据前虽然需要 QUIC 协议握手，但是这个握手过程只需要 1 RTT，握手的目的是为确认双方的「连接 ID」，连接迁移就是基于连接 ID 实现的。但是 HTTP/3 的 QUIC 协议并不是与 TLS 分层，而是 QUIC 内部包含了 TLS，它在自己的帧会携带 TLS 里的“记录”，再加上 QUIC 使用的是 TLS/1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与密钥协商。

• 连接迁移

当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。因为 TCP 传输的 HTTP 协议是通过四元组（源 IP，源端口，目的 IP，目的端口）完成连接的，IP 变了就要重新 TCP 三次握手和 TLS 四次握手。

QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。但是 QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题，因为有的网络设备是会丢掉 UDP 包的，而 QUIC 是基于 UDP 实现的，那么如果网络设备无法识别这个是 QUIC 包，那么就会当作 UDP包，然后被丢弃。

HTTP/1.1 如何优化

• 避免发送 HTTP 请求

对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，通过缓存技术减少请求次数。

客户端会把第一次请求以及响应的数据保存在本地磁盘上，其中将请求的 URL 作为 key，而响应作为 value，两者形成映射关系。之后再发起相同请求，就在本地磁盘查找 key 对应的 value，直接本地读取响应。

首先，服务器发送 HTTP 响应会估算过期时间并发送给客户端，客户端发现未超时就会直接使用本地；如果过期了，客户端重新发送请求，并在请求的 Etag 头部带上第一次请求时响应头部的摘要，服务器会比较服务器本地资源，如果是一样的，仅返回不含有包体的 304 Not Modified 响应来减少传输延时，如果不一样那就传输最新资源。

• 减少 HTTP 请求次数

减少重定向请求次数。重定向请求就是服务器的资源从 url1 迁移到 url2，那么请求 url1 之后就会返回 302 响应码以及对应的 Location 头部。要知道的是服务器也有多级，一般客户端与代理服务器沟通，而代理服务器再去源服务器请求资源；那么重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了

把多个访问小文件的请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。同时为了防止 HTTP/1.1 的队头阻塞问题，一般浏览器会同时发起 5-6 个请求，每一个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因而省去了 TCP 握手和慢启动过程耗费的时间。合并请求的方式就是合并资源，以一个大资源的请求替换多个小资源的请求。但是这样的合并请求会带来新的问题，当大资源中的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件，这显然带来了额外的网络消耗。

延迟发送请求。可以通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数。

• 减少 HTTP 响应的数据大小

无损压缩，资源压缩后信息不被破坏，仍能还原到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。

无损压缩，就可以在客户端请求的时候通过头部中的 Accept-Encoding 字段告诉服务器：

Accept-Encoding: gzip, deflate, br

服务器收到后压缩，最后通过响应头部的Content-Encoding 字段告诉客户端该资源使用的压缩算法。

Content-Encoding: gzip

有损压缩，解压的数据就会与原始数据有不同，但非常接近。有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。

可以通过 HTTP 请求头部中的 Accept 字段里的「 q 质量因子」，告诉服务器期望的资源质量。

Accept: audio/*; q=0.2, audio/basic

目前压缩比较高的是 Google 推出的 WebP 格式。常用于压缩图片。如果是音视频，会通过在一个静态的关键帧，使用增量数据来表达后续的帧来压缩。对于视频常见的编码格式有 H264、H265 等，音频常见的编码格式有 AAC、AC3。

HTTPS RSA 握手解析

每一个「框」都是一个记录（record），记录是 TLS 收发数据的基本单位，多个记录可以组合成一个 TCP 包发送，所以通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

TLS 握手

传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件其实就是服务端的公钥，会在 TLS 握手阶段传递给客户端，而服务端的私钥则一直留在服务端，一定要确保私钥不能被窃取。

在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息。

TLS 第一次握手

客户端首先会发一个「Client Hello」消息，抓包消息如下：

发送的是 TLS 版本号，支持的密码套件列表，以及生成的随机数（Client Random）。

TLS 第二次握手

当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数（Server Random）。

接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

密码套件是有固定格式的：基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」。

这里已经互相发了两个随机数，是之后生成「会话密钥」的条件，也就是对称加密密钥。

然后，服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。

最后会发送「Server Hello Done」消息，表明发送完毕。

客户端验证证书

这里在之前已经很具体的记录学习过了，如果复习的时候往上翻笔记不好找就直接进链接：CA 验证

TLS 第三次握手

客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Client Key Exchange」消息传给服务端。

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完「会话密钥」后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。

客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。这里注意，这一步之前的都是明文数据，在这之后就都是对称密钥加密的密文。

TLS 第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

RSA 缺陷

使用 RSA 密钥协商算法的最大问题是不支持前向保密。

客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

HTTPS ECDHE 握手解析

这一部分比较多，如果之后还有时间再来看，直接贴个链接：ECDHE 握手

HTTPS 优化

HTTPS 相比 HTTP 协议多一个 TLS 协议握手过程，目的是为了通过非对称加密握手协商或者交换出对称加密密钥，这个过程最长可以花费掉 2 RTT，接着后续传输的应用数据都得使用对称加密密钥来加密/解密。

分析性能损耗

主要有两个环节：

• TLS 协议握手过程
• 握手后的对称加密报文传输

对于第二环节，现在主流的对称加密算法 AES、ChaCha20 性能都是不错的，而且一些 CPU 厂商还针对它们做了硬件级别的优化，因此这个环节的性能消耗可以说非常地小。

第一个环节，会增加网络延时（最长 2 个 RTT），且有性能损耗：

• 对于 ECDHE 密钥协商算法，握手过程中会客户端和服务端都需要临时生成椭圆曲线公私钥；
• 客户端验证证书时，会访问 CA 获取 CRL 或者 OCSP，目的是验证服务器的证书是否有被吊销；
• 双方计算 Pre-Master，也就是对称加密密钥；

硬件优化

HTTPS 协议是计算密集型，而不是 I/O 密集型，所以主要的硬件升级应该在 CPU 上。如果可以，应该选择可以支持 AES-NI 特性的 CPU，因为这种款式的 CPU 能在指令级别优化了 AES 算法，这样便加速了数据的加解密传输过程。

软件优化

一个是软件升级，一个是协议优化。

软件升级简单，就是升级软件版本，例如升级 Linux 内核，升级 OpenSSL，但这个会造成一些风险，所以更多应该放在协议优化上。

协议优化

• 密钥交换算法优化

使用 RSA 密钥交换算法的 TLS 握手过程，不仅慢，而且安全性也不高。

尽量选用 ECDHE 密钥交换算法替换 RSA 算法，因为该算法由于支持「False Start」，它是“抢跑”的意思，客户端可以在 TLS 协议的第 3 次握手后，第 4 次握手前，发送加密的应用数据，以此将 TLS 握手的消息往返由 2 RTT 减少到 1 RTT，而且安全性也高，具备前向安全性。

ECDHE 算法是基于椭圆曲线实现的，不同的椭圆曲线性能也不同，应该尽量选择 x25519 曲线，该曲线是目前最快的椭圆曲线。

对称加密算法方面，如果对安全性不是特别高的要求，可以选用 AES_128_GCM，它比 AES_256_GCM 快一些，因为密钥的长度短一些。

• TLS 升级

直接把 TLS 1.2 升级成 TLS 1.3，TLS 1.3 大幅度简化了握手的步骤，完成 TLS 握手只要 1 RTT，而且安全性更高。

TLS 1.3 把 Hello 和公钥交换这两个消息合并成了一个消息，于是这样就减少到只需 1 RTT 就能完成 TLS 握手。TLS1.3 对密码套件进行“减肥”了， 对于密钥交换算法，废除了不支持前向安全性的 RSA 和 DH 算法，只支持 ECDHE 算法。

证书优化

优化方向也有两个，一个是证书传输，一个是证书验证。

• 证书传输

减少证书的大小，这样可以节约带宽，也能减少客户端的运算量。所以，对于服务器的证书应该选择椭圆曲线（ECDSA）证书，而不是 RSA 证书，因为在相同安全强度下， ECC 密钥长度比 RSA 短的多。

• 证书验证

验证是个复杂过程，会走证书链逐级验证，验证的过程不仅需要「用 CA 公钥解密证书」以及「用签名算法验证证书的完整性」，而且为了知道证书是否被 CA 吊销，客户端有时还会再去访问 CA， 下载 CRL 或者 OCSP 数据，以此确认证书的有效性。

CRL 称为证书吊销列表（Certificate Revocation List），这个列表是由 CA 定期更新，如果证书再次列表就证明证书过期，反之则是有效。但是 CRL 是定期更新的，所以实时性比较差；同时随着吊销证书的增多，列表会越来越大，下载的速度就会越慢，下载完还需要遍历列表会导致时间很长。

由于 CRL 的以上问题，现在多采用 OCSP，名为在线证书状态协议（Online Certificate Status Protocol）来查询证书的有效性，它的工作方式是向 CA 发送查询请求，让 CA 返回证书的有效状态。但也因为是在线的，所以网络状态不好就会导致耗时长。

为了解决网络开销，就出现了 OCSP Stapling，其原理是：服务器向 CA 周期性地查询证书状态，获得一个带有时间戳和签名的响应结果并缓存它。

会话复用

相当于一个缓存机制，把第一次的 TLS 握手协商的对称加密密钥缓存下来，下次就直接「复用」这个密钥。分成两种方法，一种是 Session ID，一种是Session Ticket。

• Session ID

客户端和服务器首次 TLS 握手连接后，双方会在内存缓存会话密钥，并用唯一的 Session ID 来标识，Session ID 和会话密钥相当于 key-value 的关系。再次连接，hello 消息就会带上 Session ID，服务器直接在内存中找，找到该 ID 就会直接复用。但也因为是缓存，客户端增多就会导致服务器的内存消耗过大；一般现在都是多台服务器通过负载来均衡提供服务，客户端再次连接未必是上次的服务器。

• Session Ticket

服务器不再缓存每个客户端的会话密钥，而是把缓存的工作交给了客户端，类似于 HTTP 的 Cookie。首次建立连接时，服务器会加密「会话密钥」作为 Ticket 发给客户端，交给客户端缓存该 Ticket。客户端再次连接服务器时，客户端会发送 Ticket，服务器解密后就可以获取上一次的会话密钥，然后验证有效期，如果没问题，就可以恢复会话了，开始加密通信。

对于集群服务器的话，要确保每台服务器加密 「会话密钥」的密钥是一致的，这样客户端携带 Ticket 访问任意一台服务器时，都能恢复会话。

但是，会话复用都不具备前向安全性，应对重放攻击也很困难（中间方截取之前的密码从而完成通讯），避免的方法就是设置会话密钥的合理过期时间。

• Pre-shared Key

TLS 1.3 有了重大改进，之前的两个方法都需要 1 RTT 来恢复通化，而 TLS 1.3 重连只需要 0 RTT，只不过重连需要客户端把 Ticket 和 HTTP 请求一同发送给服务端，这就是 Pre-shared Key。

但同样的，该方法也有重放攻击的问题。

HTTP/2

HTTP/1.1 性能问题

HTTP/1.1 的最大问题就是高延迟，主要原因如下：

• 延迟难以下降，虽然现在网络的「带宽」相比以前变多了，但是延迟降到一定幅度后，就很难再下降了，说白了就是到达了延迟的下限；
• 并发连接有限，谷歌浏览器最大并发连接数是 6 个，而且每一个连接都要经过 TCP 和 TLS 握手耗时，以及 TCP 慢启动过程给流量带来的影响；
• 队头阻塞问题，同一连接只能在完成一个 HTTP 事务（请求和响应）后，才能处理下一个事务；
• HTTP 头部巨大且重复，由于 HTTP 协议是无状态的，每一个请求都得携带 HTTP 头部，特别是对于有携带 Cookie 的头部，而 Cookie 的大小通常很大；
• 不支持服务器推送消息，因此当客户端需要获取通知时，只能通过定时器不断地拉取消息，这无疑浪费大量了带宽和服务器资源。

之前也有说过一些优化举措：对多个小请求合并成大请求；将二进制数据通过 Base64 编码嵌入 HTML 请求；将同一个页面的资源分散到不同域名，提升并发连接上限。

但因为 HTTP/1.1 的底层协议，关键的地方是没办法优化的，比如请求-响应模型、头部巨大且重复、并发连接耗时、服务器不能主动推送等，要改变这些必须重新设计 HTTP 协议，于是 HTTP/2 就出来了！

兼容 HTTP/1.1

第一点，HTTP/2 没有在 URI 里引入新的协议名，仍然用「http://」表示明文协议，用「https://」表示加密协议，于是只需要浏览器和服务器在背后自动升级协议，这样可以让用户意识不到协议的升级，很好的实现了协议的平滑升级。

第二点，只在应用层做了改变，还是基于 TCP 协议传输，应用层方面为了保持功能上的兼容，HTTP/2 把 HTTP 分解成了「语义」和「语法」两个部分，「语义」层不做改动，与 HTTP/1.1 完全一致，比如请求方法、状态码、头字段等规则保留不变。

头部压缩

HTTP 协议的报文是由「Header + Body」构成的，对于 Body 部分，HTTP/1.1 协议可以使用头字段 「Content-Encoding」指定 Body 的压缩方式，比如用 gzip 压缩，这样可以节约带宽，但报文中的另外一部分 Header，是没有针对它的优化手段。Header 问题如下：

• 含很多固定的字段，比如 Cookie、User Agent、Accept 等，这些字段加起来也高达几百字节甚至上千字节，所以有必要压缩；
• 大量的请求和响应的报文里有很多字段值都是重复的，这样会使得大量带宽被这些冗余的数据占用了，所以有必须要避免重复性；
• 字段是 ASCII 编码的，虽然易于人类观察，但效率低，所以有必要改成二进制编码；

针对以上问题，HTTP/2 做了大量改进，开发了 HPACK 算法来压缩头部，包含了三个组成部分：静态字典、动态字典、Huffman 编码（压缩算法）。

客户端和服务器两端都会建立和维护「字典」，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。

• 静态表编码

HTTP/2 为高频出现在头部的字符串和字段建立了一张静态表，它是写入到 HTTP/2 框架里的，不会变化的，静态表里共有 61 组。这些表中的 Index 索引对应的就是 Header Value 来发送，如果没有则说明 Value 并非固定不变，要经过 Huffman 编码再行发送。

头部字段属于静态表范围，并且 Value 是变化，那么它的 HTTP/2 头部前 2 位固定为 01，所以整个头部格式如下图：

HTTP/2 头部由于基于二进制编码，改用表示字符串长度（Value Length）来分割 Index 和 Value。之后的 H 处，如果是 1 就表示经过 Huffman 编码，之后则表示整个传递字符的长度。之后就是通过差汇总啊到静态 Huffman 表把要传递的字符用对应的二进制拼起来并补位。

• 动态表编码

不在静态表范围内的头部字符串就要自行构建动态表，它的 Index 从 62 起步，会在编码解码的时候随时更新。

使得动态表生效有一个前提：必须同一个连接上，重复传输完全相同的 HTTP 头部。如果消息字段在 1 个连接上只发送了 1 次，或者重复传输时，字段总是略有变化，动态表就无法被充分利用了。

然后就是缓存的通病，占用内存过大。为了解决这个问题， Web 服务器都会提供类似 http2_max_requests 的配置，用于限制一个连接上能够传输的请求数量，避免动态表无限增大，请求数量到达上限后，就会关闭 HTTP/2 连接来释放内存。

二进制帧

HTTP/2 把响应报文划分成了两类帧（Frame），图中的 HEADERS（首部）和 DATA（消息负载） 是帧的类型，也就是说一条 HTTP 响应，划分成了两类帧来传输，并且采用二进制来编码。

HTTP/2 二进制帧结构如下：

帧类型，在 HTTP/2 中定义了 10 种类型，一般分为数据帧和控制帧。标志位可以保存 8 个，携带简单的控制信息。

并发传输

通过 Stream 这个设计，多个 Stream 复用一条 TCP 连接，达到并发的效果，解决了 HTTP/1.1 队头阻塞的问题，提高了 HTTP 传输的吞吐量。

多个 Stream 跑在一条 TCP 连接，同一个 HTTP 请求与响应是跑在同一个 Stream 中，HTTP 消息可以由多个 Frame 构成， 一个 Frame 可以由多个 TCP 报文构成。同时 TCP 连接可包含多个 Stream，一个 Stream 可包含多个 Message，一个 Message 可包含多个 Frame。

不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。

同一个连接中的 Stream ID 是不能复用的，只能顺序递增，所以当 Stream ID 耗尽时，需要发一个控制帧 GOAWAY，用来关闭 TCP 连接。在 Nginx 中，可以通过 http2_max_concurrent_Streams 配置来设置 Stream 的上限，默认是 128 个。

可以对每个 Stream 设置不同优先级，帧头中的**「标志位」可以设置优先级**。

服务器主动推送资源

客户端发起的请求，必须使用的是奇数号 Stream，服务器主动的推送，使用的是偶数号 Stream。服务器在推送资源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。

HTTP/3

这个目前应该还是很新的协议，应该不会多问，没太多时间看，暂时跳过，有时间再来学：HTTP/3 知识点

RPC 协议

TCP 是有三个特点，面向连接、可靠、基于字节流。纯粹的 TCP 协议发送的就是二进制数据，这些数据没有边界，无法辨析如何切分，就会发生粘包。所以为了使用，需要一些自定义规则来区分消息边界。自定义的贵咋，大多数就是加入一个消息头，然后把真正的数据作为消息体，这就是所谓的协议。于是就有了基于 TCP 的很多协议，如 HTTP、RPC。

HTTP 和 RPC

TCP 是传输层的协议，而基于 TCP 造出来的 HTTP 和各类 RPC 协议，它们都只是定义了不同消息格式的应用层协议而已。

RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。虽然大部分 RPC 协议底层使用 TCP，但实际上它们不一定非得使用 TCP，改用 UDP 或者 HTTP，其实也可以做到类似的功能。

TCP 在 70 年代被使用，而 HTTP 直到 90 年代才流行，刚学到的裸 TCP 会有问题于是有很多自定义协议，就包括了 80 年代的 RPC。

各种联网软件，比如 xx管家，xx卫士，它们都作为客户端（Client）需要跟服务端（Server）建立连接收发消息，此时都会用到应用层协议，在这种 Client/Server (C/S) 架构下，它们可以使用自家造的 RPC 协议，因为它只管连自己公司的服务器就 ok 了。

浏览器（Browser），不管是 Chrome 还是 IE，它们不仅要能访问自家公司的服务器（Server），还需要访问其他公司的网站服务器，因此它们需要有个统一的标准，不然大家没法交流。于是，HTTP 就是那个时代用于统一 Browser/Server (B/S) 的协议。

HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。很多软件同时支持多端，比如某度云盘，既要支持网页版，还要支持手机端和 PC 端，如果通信协议都用 HTTP 的话，那服务器只用同一套就够了。而 RPC 就开始退居幕后，一般用于公司内部集群里，各个微服务之间的通讯。

HTTP 和 RPC 区别

• 服务发现

建立连接的前提是，你得知道 IP 地址和端口。这个找到服务对应的 IP 端口的过程，其实就是服务发现。

HTTP 中，知道服务域名，就可以通过 DNS 服务解析 IP地址，默认端口 80。

RPC 的话，就有些区别，一般会有专门的中间服务去保存服务名和IP信息，比如 Consul 或者 Etcd，甚至是 Redis。想要访问某个服务，就去这些中间服务去获得 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如CoreDNS。

• 底层连接形式

主流的 HTTP/1.1 协议为例，其默认在建立底层 TCP 连接之后会一直保持这个连接（Keep Alive），之后的请求和响应都会复用这条连接。

而 RPC 协议，也跟 HTTP 类似，也是通过建立 TCP 长链接进行数据交互，但不同的地方在于，RPC 协议一般还会再建个连接池，在请求量大的时候，建立多条连接放在池内，要发数据的时候就从池里取一条连接出来，用完放回去，下次再复用，可以说非常环保。

由于连接池有利于提升网络请求性能，所以不少编程语言的网络库里都会给 HTTP 加个连接池，比如 Go 就是这么干的。

但是这里两者的区别也并不大。

• 传输内容

Header 是用于标记一些特殊信息，其中最重要的是消息体长度。

Body 则是放我们真正需要传输的内容，而这些内容只能是二进制 01 串。传输字符串可以简单转换，但结构体也得想个办法将它也转为二进制 01 串，这样的方案现在也有很多现成的，比如 Json，Protobuf。

这个将结构体转为二进制数组的过程就叫序列化，反过来将二进制数组复原成结构体的过程叫反序列化。

HTTP 设计初是用于做网页文本展示的，所以它传的内容以字符串为主。Header 和 Body 都是如此。在 Body 这块，它使用 Json 来序列化结构体数据。看 HTTP/1.1 的问题，前面也反复提到，在 Header 中的信息一直重复，眼中影响传输效率。

RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。

当然，如果是 HTTP/2，因为做了许多改进，性能可能比很多 RPC 协议好，且 gRPC 底层就是直接用 HTTP/2。（之所以还是 RPC 协议作为很多内部的传输协议，是因为 HTTP/2 出的很晚，在2015 年）

需要 WebSocket 的原因

HTTP 不断轮询

怎么样才能在用户不做任何操作的情况下，网页能收到消息并发生变更。

最常见的解决方案是，网页的前端代码里不断定时发 HTTP 请求到服务器，服务器收到请求后给客户端响应消息。

这种方式的应用场景很多，例如扫码登录，前端网页不知道用户是否扫描，只能不断询问后端服务器。当这种方式就会有两个比较明显的问题：

• F12 打开页面，会看到很多 HTTP 请求，会增加服务器负担；
• 最坏情况下，就会有延迟，有明显卡顿。

长轮询

如果 HTTP 请求将超时设置的很大，比如 30 秒，在这 30 秒内只要服务器收到了扫码请求，就立马返回给客户端网页。如果超时，那就立马发起下一次请求。通过这种方法，减少 HTTP 请求个数，且能及时响应。

像这种发起一个请求，在较长时间内等待服务器响应的机制，就是所谓的长轮询机制。我们常用的消息队列 RocketMQ 中，消费者去取数据时，也用到了这种方式。

以上两种方法，本质上还是客户端主动请求数据。

WebSocket

TCP 连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。然而最常用的 HTTP/1.1 只能有一方主动发送数据，是半双工。

新的应用层协议 WebSocket就被设计出来，就是为了满足全双工的需求。

浏览器在 TCP 三次握手建立连接之后，都统一使用 HTTP 协议先进行一次通信。

• 如果此时是普通的 HTTP 请求，那后续双方就还是老样子继续用普通 HTTP 协议进行交互，这点没啥疑问。
• 如果这时候是想建立 WebSocket 连接，就会在 HTTP 请求里带上一些特殊的 header 头。

Connection: Upgrade Upgrade: WebSocket Sec-WebSocket-Key: T2a6wZlAwhgQNqruZ2YUyg==\r\n

浏览器想升级协议（Connection: Upgrade），并且想升级成 WebSocket 协议（Upgrade: WebSocket）。同时带上一段随机生成的 base64 码（Sec-WebSocket-Key），发给服务器。如果服务器支持，就会通过 WebSocket 握手流程，并根据客户端的 base64 码用某个公开算法变成另一个字符串，放在 HTTP 响应的 Sec-WebSocket-Accept 头里，同时带上 101 状态码，发回给浏览器。

HTTP/1.1 101 Switching Protocols\r\n Sec-WebSocket-Accept: iBJKv/ALIW2DobfoA4dmr3JHBCY=\r\n Upgrade: WebSocket\r\n Connection: Upgrade\r\n

最终，客户端也用相同公开算法解析 base64 码，如果与回传的字符串相同那么久通过验证，建立 WebSocket 连接。

总的来说，就是经历了三次TCP握手之后，利用 HTTP 协议升级为 WebSocket 协议。WebSocket只有在建立连接时才用到了HTTP，升级完成之后就跟HTTP没有任何关系了。

关注的是如下几个数据：

• opcode字段：这个是用来标志这是个什么类型的数据帧。
• payload字段：存放的是我们真正想要传输的数据的长度，单位是字节。这里要注意，payload 长度可以只有 7 bit，也可以是 7 + 16 bit，也可以是7 + 64 bit，具体怎么读就是先读一开始的 7bit，如果是 0-125 范围内，那就是读完了；126（0x7E）那就是再读 16 bit；127（0x7F）就是再读 64 bit。
• payload data字段：这里存放的就是真正要传输的数据，在知道了上面的payload长度后，就可以根据这个值去截取对应的数据。

WebSocket完美继承了 TCP 协议的全双工能力，并且还贴心的提供了解决粘包的方案。它适用于需要服务器和客户端（浏览器）频繁交互的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件。