3.1 HTTP常见面试题
1、HTTP基本概念：
- 超文本传输协议：在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」
- HTTP常见的状态码 [[Pasted image 20250705140705.png]]
- HTTP常见字段
- Host 字段：客户端发送请求时，用来指定服务器的域名
- Content-Length 字段：服务器在返回数据时本次回应的数据长度。HTTP协议通过设置回车符、换行符作为HTTP header的边界，通过Content-Length字段作为HTTP body的边界，这两个方式都是为了解决“粘包”的问题。
- Connection 字段：常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用
- Content-Type 字段：用于服务器回应时，告诉客户端，本次数据是什么格式。（客户端请求的时候，可以使用
Accept字段声明自己可以接受哪些数据格式。） - Content-Encoding 字段：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式（客户端在请求时，用
Accept-Encoding字段说明自己可以接受哪些压缩方法）
2、GET 与 POST
- GET 的语义是从服务器获取指定的资源，比如打开浏览器文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。GET 请求的参数位置一般是写在 URL 中[[Pasted image 20250705143554.png]]
- POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，在文章底部留言后点击「提交」，浏览器就会执行一次POST请求，把你的留言文字放进了报文body里，然后拼接好POST请求头，通过TCP协议发送给服务器。POST 请求携带数据的位置一般是写在报文 body 中[[Pasted image 20250705143636.png]]
- GET 和 POST 请求都是明文的，避免被窃取就要用HTTPS协议 [[Pasted image 20250705144047.png]]
3、HTTP缓存技术 - 强制缓存：只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段Cache-Control和Expires实现[[Pasted image 20250705144933.png]]
- 协商缓存：当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。Etag实现协商缓存的过程：[[Pasted image 20250705150930.png]]
4、HTTP特性 - HTTP/1.1 优点「简单、灵活和易于扩展、应用广泛和跨平台」
- 1. 简单
- 2. 灵活和易于扩展
-
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
-
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
-
- 3. 应用广泛和跨平台
- HTTP/1.1 缺点「无状态、明文传输」，同时还有一大缺点「不安全」
- 1. 无状态双刃剑：不需要额外记录状态信息，减轻服务器负担，但服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行
- 2. 明文传输双刃剑：抓包调试方便，但信息裸奔
- 3. 不安全：明文不加密，不验证通信方身份，无法证明报文完整性（可能被篡改）。可用HTTPS解决，加入SSL/TLS层
- HTTP/1.1 性能
- 1. 长连接：减少TCP重复建立和断开的额外开销
- 2. 管道网络传输：长连接使得管道传输成为可能，即可在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
- 3. 队头阻塞：顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了
5、HTTP 与 HTTPS
- HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
- 如何解决HTTP的缺点
- 1. 混合加密：采用的是对称加密和非对称加密结合的「混合加密」方式，解决明文窃听问题。
- 在通信建立前采用非对称加密的方式交换「会话秘钥」
- 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据
- 2. 摘要算法 + 数字签名：解决内容篡改
- 用摘要算法（哈希函数）来计算出内容的哈希值
- 非对称加密算法（数字前面算法）：通过「私钥加密，公钥解密」的方式，来确认消息的身份[[Pasted image 20250705161048.png]]
- 3. 数字证书：将服务器公钥放在数字证书（由数字证书认证机构颁发）中，实现身份验证环节
- 1. 混合加密：采用的是对称加密和非对称加密结合的「混合加密」方式，解决明文窃听问题。
- HTTPS 是如何建立连接的（这部分不太懂）
- TLS 协议建立的详细流程
- 客户端校验数字证书的流程
- HTTPS的应用数据是如何保证完整性的（这部分不太懂）
- TLS 记录协议负责保护应用程序数据并验证其完整性和来源
- HTTPS 一定安全可靠吗
6、HTTP/1.1、HTTP/2、HTTP/3 演变 [[Pasted image 20250705172849.png]] - HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
-
- 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来
-
- HTTP/2 做了什么优化？
- HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
- 1. 头部压缩：
HPACK算法，在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表 - 2. 二进制格式：不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式
- 3. 并发传输：引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接
- 4. 服务器推送：服务端不再是被动地响应，可以主动向客户端发送消息
- HTTP/3 做了哪些优化？
- HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
- 基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。QUIC 有以下 3 个特点。
- 1、无队头阻塞：当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响
- 2、更快的连接建立：QUIC 内部包含了 TLS
- 3、连接迁移： QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点
3.2 HTTP/1.1 如何优化
1、下面这三种优化思路来优化 HTTP/1.1 协议：
- 尽量避免发送HTTP请求;
- 在需要发送HTTP请求时，考虑如何减少请求次数；
- 减少服务器的HTTP响应的数据大小；
2、尽量避免发送HTTP请求：缓存技术 [[Pasted image 20250706112045.png]] [[Pasted image 20250705150930.png]]
3、考虑如何减少请求次数 - 减少重定向请求次数：重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了
- 合并请求：把多个访问小文件的请求合并成一个大的请求，减少了重复发送的 HTTP 头部。
- 延迟发送请求：通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数
4、减少服务器的HTTP响应的数据大小 - 无损压缩：资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。（对原始资源建立统计模型，利用这个统计模型，将常出现的数据用较短的二进制比特序列表示，将不常出现的数据用较长的二进制比特序列表示）客户端支持的压缩算法，会在 HTTP 请求中通过头部中的
Accept-Encoding字段 - 有损压缩：解压的数据会与原始数据不同但是非常接近。HTTP 请求头部中的
Accept字段里的「 q 质量因子」，告诉服务器期望的资源质量。
3.3 HTTPS RSA握手解析
1、HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。[[Pasted image 20250706133549.png]]
2、TLS 握手过程，不同的密钥交换算法，TLS 的握手过程可能会有一些区别。密钥交换算法，因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。（最简单的 RSA 密钥交换算法）
- 经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延（RTT（Round-Trip Time）时延是指数据从发送端到接收端并返回发送端所需的总时间，即一次完整的“往返”通信延迟）
3、RSA 握手过程 - 在RSA密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对
称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥（服务端就得到客户端生成的随机秘钥），再用它加密应用消息。 - 使用RSA密钥协商算法的最大问题是不支持前向保密。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有TLS通讯密文都会被破解。为了解决这个问题，后面就出现了 ECDHE 密钥协商算法
3.4 HTTPS ECDHE 握手解析
1、HTTPS 常用的密钥交换算法有两种，分别是 RSA 和 ECDHE 算法。ECDHE秘钥交换算法[[Pasted image 20250706153243.png]]
3.5 HTTPS 如何优化
3.6 HTTP/2 牛逼在哪？
1、HTTP/2 出来的目的是为了改善 HTTP 的性能
- 兼容 HTTP/ 1.1
- HPACK 算法压缩头部：客户端和服务器两端都会建立和维护「字典」，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。
- 二进制帧：将 HTTP/1 的文本格式改成二进制格式传输数据，极大提高了 HTTP 传输效率
- 并发传输：HTTP/2 通过 Stream 实现的并发
- 服务器主动推送资源
3.7 HTTP/3 强势来袭
1、HTTP/2 的缺点
- 队头阻塞：当 TCP 丢包时，整个 TCP 都要等待重传
- TCP 与 TLS 的握手时延迟：发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手
- 网络迁移需要重新连接：IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手（比如 4G 网络环境切换成 WiFi）
2、HTTP/3 QUIC协议：将传输协议替换成了 UDP，还基于 UDP 协议在「应用层」实现了 QUIC 协议[[Pasted image 20250706191606.png]] - 无队头阻塞
- 更快的连接建立
- 连接迁移
3.8 HTTP 和 RPC 的区别
1、服务发现：在 HTTP 中，你知道服务的域名，就可以通过 DNS 服务去解析得到它背后的 IP 地址；而 RPC 的话，就有些区别，一般会有专门的中间服务去保存服务名和IP信息
2、底层连接形式：RPC 协议一般还会再建个连接池
3、传输的内容。
- 将结构体转为二进制数组的过程就叫序列化，反过来将二进制数组复原成结构体的过程叫反序列化
RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。如果现在这不是个本地方法，而是个远端服务器暴露出来的一个方法
remoteFunc，如果我们还能像调用本地方法那样去调用它，这样就可以屏蔽掉一些网络细节
HTTP 和 WebSocker
1、HTTP协议设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应就够了，根本就没考虑网页游戏这种，客户端和服务器之间都要互相主动发大量数据的场景。所以，为了更好的支持这样的场景，我们需要另外一个基于TCP的新协议，新的应用层协议WebSocket就被设计出来了。
2、浏览器在 TCP 三次握手建立连接之后，都统一使用 HTTP 协议先进行一次通信。
- 如果这时候是想建立 WebSocket 连接，就会在 HTTP 请求里带上一些特殊的header 头 [[Pasted image 20250706201759.png]]
3、WebSocker的消息格式 [[QQ_1751804965426.png]] - 数据包在WebSocket中被叫做帧
- 适用于需要服务器和客户端（浏览器）频繁交互的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件
我们知道TCP连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。而现在使用最广泛的HTTP/1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。[[Pasted image 20250706203228.png]]
3.1 HTTP常见面试题
1、HTTP基本概念：
- 超文本传输协议：在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」
- HTTP常见的状态码 [[Pasted image 20250705140705.png]]
- HTTP常见字段
- Host 字段：客户端发送请求时，用来指定服务器的域名
- Content-Length 字段：服务器在返回数据时本次回应的数据长度。HTTP协议通过设置回车符、换行符作为HTTP header的边界，通过Content-Length字段作为HTTP body的边界，这两个方式都是为了解决“粘包”的问题。
- Connection 字段：常用于客户端要求服务器使用「HTTP 长连接」机制，以便其他请求复用
- Content-Type 字段：用于服务器回应时，告诉客户端，本次数据是什么格式。（客户端请求的时候，可以使用
Accept字段声明自己可以接受哪些数据格式。） - Content-Encoding 字段：说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式（客户端在请求时，用
Accept-Encoding字段说明自己可以接受哪些压缩方法）
2、GET 与 POST
- GET 的语义是从服务器获取指定的资源，比如打开浏览器文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。GET 请求的参数位置一般是写在 URL 中[[Pasted image 20250705143554.png]]
- POST 的语义是根据请求负荷（报文body）对指定的资源做出处理，在文章底部留言后点击「提交」，浏览器就会执行一次POST请求，把你的留言文字放进了报文body里，然后拼接好POST请求头，通过TCP协议发送给服务器。POST 请求携带数据的位置一般是写在报文 body 中[[Pasted image 20250705143636.png]]
- GET 和 POST 请求都是明文的，避免被窃取就要用HTTPS协议 [[Pasted image 20250705144047.png]]
3、HTTP缓存技术 - 强制缓存：只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段Cache-Control和Expires实现[[Pasted image 20250705144933.png]]
- 协商缓存：当我们在浏览器使用开发者工具的时候，你可能会看到过某些请求的响应码是304，这个是告诉浏览器可以使用本地缓存的资源，通常这种通过服务端告知客户端是否可以使用缓存的方式被称为协商缓存。Etag实现协商缓存的过程：[[Pasted image 20250705150930.png]]
4、HTTP特性 - HTTP/1.1 优点「简单、灵活和易于扩展、应用广泛和跨平台」
- 1. 简单
- 2. 灵活和易于扩展
-
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
-
- HTTPS 就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
-
- 3. 应用广泛和跨平台
- HTTP/1.1 缺点「无状态、明文传输」，同时还有一大缺点「不安全」
- 1. 无状态双刃剑：不需要额外记录状态信息，减轻服务器负担，但服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行
- 2. 明文传输双刃剑：抓包调试方便，但信息裸奔
- 3. 不安全：明文不加密，不验证通信方身份，无法证明报文完整性（可能被篡改）。可用HTTPS解决，加入SSL/TLS层
- HTTP/1.1 性能
- 1. 长连接：减少TCP重复建立和断开的额外开销
- 2. 管道网络传输：长连接使得管道传输成为可能，即可在同一个TCP连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
- 3. 队头阻塞：顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了
5、HTTP 与 HTTPS
- HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
- 如何解决HTTP的缺点
- 1. 混合加密：采用的是对称加密和非对称加密结合的「混合加密」方式，解决明文窃听问题。
- 在通信建立前采用非对称加密的方式交换「会话秘钥」
- 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据
- 2. 摘要算法 + 数字签名：解决内容篡改
- 用摘要算法（哈希函数）来计算出内容的哈希值
- 非对称加密算法（数字前面算法）：通过「私钥加密，公钥解密」的方式，来确认消息的身份[[Pasted image 20250705161048.png]]
- 3. 数字证书：将服务器公钥放在数字证书（由数字证书认证机构颁发）中，实现身份验证环节
- 1. 混合加密：采用的是对称加密和非对称加密结合的「混合加密」方式，解决明文窃听问题。
- HTTPS 是如何建立连接的（这部分不太懂）
- TLS 协议建立的详细流程
- 客户端校验数字证书的流程
- HTTPS的应用数据是如何保证完整性的（这部分不太懂）
- TLS 记录协议负责保护应用程序数据并验证其完整性和来源
- HTTPS 一定安全可靠吗
6、HTTP/1.1、HTTP/2、HTTP/3 演变 [[Pasted image 20250705172849.png]] - HTTP/1.1 相比 HTTP/1.0 提高了什么性能？
-
- 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
- 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来
-
- HTTP/2 做了什么优化？
- HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的。
- 1. 头部压缩：
HPACK算法，在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表 - 2. 二进制格式：不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式
- 3. 并发传输：引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接
- 4. 服务器推送：服务端不再是被动地响应，可以主动向客户端发送消息
- HTTP/3 做了哪些优化？
- HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
- 基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。QUIC 有以下 3 个特点。
- 1、无队头阻塞：当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响
- 2、更快的连接建立：QUIC 内部包含了 TLS
- 3、连接迁移： QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID 来标记通信的两个端点
3.2 HTTP/1.1 如何优化
1、下面这三种优化思路来优化 HTTP/1.1 协议：
- 尽量避免发送HTTP请求;
- 在需要发送HTTP请求时，考虑如何减少请求次数；
- 减少服务器的HTTP响应的数据大小；
2、尽量避免发送HTTP请求：缓存技术 [[Pasted image 20250706112045.png]] [[Pasted image 20250705150930.png]]
3、考虑如何减少请求次数 - 减少重定向请求次数：重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了
- 合并请求：把多个访问小文件的请求合并成一个大的请求，减少了重复发送的 HTTP 头部。
- 延迟发送请求：通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数
4、减少服务器的HTTP响应的数据大小 - 无损压缩：资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。（对原始资源建立统计模型，利用这个统计模型，将常出现的数据用较短的二进制比特序列表示，将不常出现的数据用较长的二进制比特序列表示）客户端支持的压缩算法，会在 HTTP 请求中通过头部中的
Accept-Encoding字段 - 有损压缩：解压的数据会与原始数据不同但是非常接近。HTTP 请求头部中的
Accept字段里的「 q 质量因子」，告诉服务器期望的资源质量。
3.3 HTTPS RSA握手解析
1、HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。[[Pasted image 20250706133549.png]]
2、TLS 握手过程，不同的密钥交换算法，TLS 的握手过程可能会有一些区别。密钥交换算法，因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。（最简单的 RSA 密钥交换算法）
- 经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延（RTT（Round-Trip Time）时延是指数据从发送端到接收端并返回发送端所需的总时间，即一次完整的“往返”通信延迟）
3、RSA 握手过程 - 在RSA密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对
称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥（服务端就得到客户端生成的随机秘钥），再用它加密应用消息。 - 使用RSA密钥协商算法的最大问题是不支持前向保密。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有TLS通讯密文都会被破解。为了解决这个问题，后面就出现了 ECDHE 密钥协商算法
3.4 HTTPS ECDHE 握手解析
1、HTTPS 常用的密钥交换算法有两种，分别是 RSA 和 ECDHE 算法。ECDHE秘钥交换算法[[Pasted image 20250706153243.png]]
3.5 HTTPS 如何优化
3.6 HTTP/2 牛逼在哪？
1、HTTP/2 出来的目的是为了改善 HTTP 的性能
- 兼容 HTTP/ 1.1
- HPACK 算法压缩头部：客户端和服务器两端都会建立和维护「字典」，用长度较小的索引号表示重复的字符串，再用 Huffman 编码压缩数据，可达到 50%~90% 的高压缩率。
- 二进制帧：将 HTTP/1 的文本格式改成二进制格式传输数据，极大提高了 HTTP 传输效率
- 并发传输：HTTP/2 通过 Stream 实现的并发
- 服务器主动推送资源
3.7 HTTP/3 强势来袭
1、HTTP/2 的缺点
- 队头阻塞：当 TCP 丢包时，整个 TCP 都要等待重传
- TCP 与 TLS 的握手时延迟：发起 HTTP 请求时，需要经过 TCP 三次握手和 TLS 四次握手
- 网络迁移需要重新连接：IP 地址或者端口变动了，就会导致需要 TCP 与 TLS 重新握手（比如 4G 网络环境切换成 WiFi）
2、HTTP/3 QUIC协议：将传输协议替换成了 UDP，还基于 UDP 协议在「应用层」实现了 QUIC 协议[[Pasted image 20250706191606.png]] - 无队头阻塞
- 更快的连接建立
- 连接迁移
3.8 HTTP 和 RPC 的区别
1、服务发现：在 HTTP 中，你知道服务的域名，就可以通过 DNS 服务去解析得到它背后的 IP 地址；而 RPC 的话，就有些区别，一般会有专门的中间服务去保存服务名和IP信息
2、底层连接形式：RPC 协议一般还会再建个连接池
3、传输的内容。
- 将结构体转为二进制数组的过程就叫序列化，反过来将二进制数组复原成结构体的过程叫反序列化
RPC（Remote Procedure Call），又叫做远程过程调用。它本身并不是一个具体的协议，而是一种调用方式。如果现在这不是个本地方法，而是个远端服务器暴露出来的一个方法
remoteFunc，如果我们还能像调用本地方法那样去调用它，这样就可以屏蔽掉一些网络细节
HTTP 和 WebSocker
1、HTTP协议设计之初，考虑的是看看网页文本的场景，能做到客户端发起请求再由服务器响应就够了，根本就没考虑网页游戏这种，客户端和服务器之间都要互相主动发大量数据的场景。所以，为了更好的支持这样的场景，我们需要另外一个基于TCP的新协议，新的应用层协议WebSocket就被设计出来了。
2、浏览器在 TCP 三次握手建立连接之后，都统一使用 HTTP 协议先进行一次通信。
- 如果这时候是想建立 WebSocket 连接，就会在 HTTP 请求里带上一些特殊的header 头 [[Pasted image 20250706201759.png]]
3、WebSocker的消息格式 [[QQ_1751804965426.png]] - 数据包在WebSocket中被叫做帧
- 适用于需要服务器和客户端（浏览器）频繁交互的大部分场景，比如网页/小程序游戏，网页聊天室，以及一些类似飞书这样的网页协同办公软件
我们知道TCP连接的两端，同一时间里，双方都可以主动向对方发送数据。这就是所谓的全双工。而现在使用最广泛的HTTP/1.1，也是基于TCP协议的，同一时间里，客户端和服务器只能有一方主动发数据，这就是所谓的半双工。[[Pasted image 20250706203228.png]]