【每日八股】计算机网络篇（四）：HTTP

HTTP 与 HTTPS 的区别？

• HTTP 明文传输，数据未经加密，安全性较差。HTTPS（SSL + HTTP）的数据传输过程是加密的，安全性较好。
• 使用 HTTPS 协议需要到 CA 申请证书。
• HTTP 的页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，而 HTTPS 除了 TCP 的三个包，还要加上 SSL 握手的消耗。
• HTTP 使用 80 端口，HTTPS 使用 443 端口。
• 实际上 HTTPS 就是构建在 SSL/TLS 之上的 HTTP 协议，所以 HTTPS 比 HTTP 更消耗服务器资源。

HTTPS 加密与认证的过程？

ClientHello

首先，由客户端向服务端发起加密通信请求，客户端主要向服务器发送：

• 客户端支持的 SSL/TLS 协议版本；
• 客户端产生的随机数（Client Random）；
• 客户端支持的密码套件列表。

ServerHello

服务器收到客户端的请求后，向客户端发出响应，服务端回应的内容如下：

• 确认 SSL/TLS 协议版本（如果浏览器不支持，则关闭加密通信）；
• 服务端产生的随机数（Server Random）；
• 确认的密码套件列表；
• 服务端的数字证书；

客户端回应

客户端收到服务端的回应之后，首先通过浏览器或 OS 中的 CA 公钥，确认服务端的数字证书的真实性，如果证书没问题，客户端会从数字证书中取出服务端的公钥，然后使用它加密报文，向服务端发送如下信息：

• 一个随机数，该随机数会被服务端公钥加密；
• 加密通信算法改变通知，表示随后的信息都将用会话密钥加密通信；
• 客户端握手结束通知，表示客户端的握手阶段已经结束；
• 为之前所有数据进行总结，供服务端校验；

至此，服务端和客户端共生成了三个随机数（客户端生成了两个，而服务端生成了一个），接着用双方协商的加密算法，各自生成本次通信的1会话密钥。

服务端回应

服务端收到客户端的第三个随机数之后，通过协商的加密算法，计算出本次通信的会话密钥。服务端向客户端发送最后的消息：

• 加密通信算法改变通知，表示随后的信息通过会话密钥加密通信；
• 服务端握手结束通知，表示服务端的握手阶段已经结束；
• 总结之前的内容，供客户端校验；

接下来，客户端与服务端进入加密通信，就完全是使用普通的 HTTP 协议了。

HTTPS 一定安全可靠吗？

HTTPS 协议到目前为止本身是没什么漏洞的。即使 HTTPS 成功被中间人攻击，本质上也是客户端的漏洞（浏览器在浏览证书非法的网站时，会提示用户确认，因为它识别出了证书是非法的，是由中间人伪造的，用户如果仍然继续访问，相当于用户接受了中间人伪造的证书），并不是 HTTPS 不够安全。

HTTPS 状态码的含义？

1. 100 类状态码属于提示信息，是协议处理的中间状态，实际用到的较少；
2. 200 类状态码表示服务器成功处理了客户端的请求；
3. 300 类状态码表示客户端请求的资源发生了变动，需要客户端使用新的 URL 重新发送请求获取资源，也就是重定向；
4. 400 类状态码表示客户端发送的报文有误，服务器无法处理；
5. 500 类状态码表示客户端请求报文正确，但服务器处理时内部发生了错误，属于服务器端的错误码。

HTTP 缓存有哪些实现方式？

• 强制缓存：强制缓存指的是只要浏览器判断缓存没过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在浏览器；
• 协商缓存：请求的响应码为 304，告诉浏览器可以使用本地缓存的资源，通过服务通知客户端是否可以使用缓存的方式是协商缓存。

HTTP 1.0、HTTP 1.1、HTTP 2.0 和 HTTP 3.0 的区别？

HTTP 1.0

• 无连接：每次请求都要建立连接，需要使用 keep-alive 参数建立长连接，建立连接非常消耗资源。
• 队头阻塞：HTTP 1.0 规定下一个请求必须在前一个请求响应到达前才能发送，假设前一个请求响应一直不到达，那么下一个请求就一直不发送，后面的请求就阻塞了。
• 缓存：在 HTTP 1.0 中主要使用 header 中的协商缓存 last-modified/if-modified-since，强缓存 Expires 来作为缓存判断的标准。

HTTP 1.1

• 长连接：好处在于减少了 TCP 连接的重复建立和断开连接所造成的额外开销，减轻了服务器端的负载。
• 支持管道（pipeline）网络传输：只要第一个请求发送出去了，不必等其回来，就可以发第二个请求出去，减少了整体的响应时间（对比 HTTP 1.0，1.0 需要在发送方接收到前一个请求的响应后才能发送下一个请求，可能产生队头阻塞）。
• 缓存处理：HTTP 1.1 引入了更多的缓存控制策略，有可供选择的缓存头来控制缓存策略。
• 断点续传：HTTP 1.1 在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由地选择以便于充分利用带宽和连接。

HTTP 2.0

• header 压缩：HTTP 1 系列的 header 带有大量信息，且每次都要重复发送，HTTP 2.0 使用 encoder 减少需要传输的 header 大小，通讯双方各自 cache 一份 header fields 表，避免了重复的 header 传输，减少了需要传输的数据包的大小。
• 多路复用：使用多路复用技术，做到同一个连接并发处理多个请求，且并发请求的数量比 HTTP 1.1 大好几个数量级。【补充，多路复用：多路复用（Multiplexing）是一种通信技术，旨在通过单一物理通信同时传输多路独立信号，从而高效利用通信资源，其核心思想是共享资源，分时/分频/分码传输】
• 新的二进制帧格式：HTTP 2.0 把请求在应用部分切分成二进制帧并标上序号，服务器收到二进制帧后组成请求进行处理，从而达到并发发送请求的效果，对于服务器端，响应可以通过序号确定是哪个请求，从而避免混乱的情况产生。
• 服务器推送：HTTP 2.0 引入了 server push，它允许服务端推送资源给浏览器，在浏览器明确地请求前，客户端可以不用再次创建连接请求从服务端获取已经推送给浏览器的资源。这样客户端可以直接在本地加载资源，不用通过网络。

HTTP 3.0（QUIC）

• HTTP 3.0（QUIC）直接弃用 TCP，将传输层协议改为 UDP，使用 UDP 实现可靠传输。
• 0-RTT：缓存当前会话的上下文，下次恢复会话的时候，只需要将之前的缓存传递给服务器，验证通过，就可以传输了（这是 QUIC 协议相比于 HTTP 2.0 协议惹眼最大的优势）。
• 多路复用：QUIC 基于 UDP，一个连接上的多个 stream 之间互相没有依赖，即使丢包也只需要发送丢失的包，而不需要重传整个连接；
• 更好的移动端表现：QUIC 在移动端的表现比 TCP 好，因为 TCP 是基于 IP 识别连接，而 QUIC 通过 ID 识别连接，无论网络环境如何变化，只要 ID 不变，就能迅速重连。
• 加密认证的报文：TCP 协议头没有经过任何加密和认证，在传输过程中很容易被中间网络设备篡改、注入和窃听。QUIC 的 packet 除了个别报文，所有报文头都是经过认证的，报文 Body 都是经过加密的，对 QUIC 进行的任何修改都可以在接收端及时发现，有效地降低了安全风险【即，虽然 UDP 的传输存在风险，但是 QUIC 报文经过加密认证，接收端可以在报文被修改的时候及时发现，极大程度上降低了基于 UDP 传输存在的风险】。
• 向前纠错机制：向前纠错（Foward Error Connec，FEC）指的是，每个数据包除了这个包本身的数据之外，还包括其他包的数据，因此少量的丢包可以通过其他包的荣誉数据直接组装而无需重传。向前纠错牺牲了每个数据包可以发送数据的上限，但是其带来的提升弥补了甚至效果比丢包导致的数据重传更好，因为数据重传会消耗更多的时间（包括确认数据包丢失、请求重传、等待新数据包等）。

QUIC 协议的概念和特点？

概念

QUIC（Quick UDP Internet Connections）是一种基于 UDP 的现代传输协议，具有类似 TCP 的连接管理、拥塞窗口、流量控制等网络特性，使得 UDP 协议更可靠【可以理解为，QUIC 是一个基于 UDP 的应用层协议，它使得 UDP 更可靠，其可靠性接近于 TCP】。

特点

基于 UDP 的高效传输

绕过 TCP 队头阻塞和握手延迟，利用 UDP 的无连接特性实现快速传输，同时在应用层实现可靠性机制（如丢包重传）。

极速连接建立

0-RTT/1-RTT握手：通过缓存密钥和会话信息，QUIC 建立首次连接仅需 1 次往返（1-RTT），后续连接可达到 0 次往返，显著降低延迟。

多路复用与无队头阻塞

单一连接支持多个独立数据流，各流之间互不阻塞。即使某个流丢包，其他流仍然正常传输，解决了 TCP 队头阻塞的问题。

内置加密与隐私增强

强制使用 TLS 1.3 加密，所有报文头部和载荷均加密，防止中间设备篡改或嗅探，提升隐私保护。

无缝连接迁移

使用连接 ID 而非 IP + 端口来标识连接，网络切换时（如 WIFI 转 5G）无需重连，保障移动场景下的连续性。

灵活拥塞控制

支持可插拔的拥塞控制算法（如 BBR），适用不同网络条件，优化吞吐量与公平性。

前向纠错（FEC）

早期版本通过冗余数据包减少重传，虽在标准中未保留，但设计理念仍在影响容错机制。

QUIC 如何实现可靠传输？

1. 有序交付和确认机制；
2. 只能重传策略；
3. 增强型拥塞控制；
4. 前向纠错；
5. 流与连接级可靠性；
6. 加密完整性验证；

HTTP 的 GET 和 POST 方法区别？

语义与用途

• GET：用于获取资源（幂等操作），不应对服务器状态产生副作用；
• POST：用于提交数据，通常会产生副作用（如创建新资源）；

参数传递

• GET：参数通过 URL 的查询字符串传递，比如example.com/search?q=keyword&page=2；
• POST：参数封装在请求体中传输；

数据限制

• GET：受 URL 长度限制（通常 2048 字符，因浏览器/服务器而异）；
• POST：理论上无限制，实际受服务器配置约束；

缓存与历史记录

• GET：可能被浏览器缓存，保存在历史记录中；
• POST：不会被缓存，刷新时浏览器重新提交；

安全性
POST 的安全性比 GET 高，因为 GET 请求提交的数据明文出现在 URL 中，而 POST 请求参数则被放在请求体中。

幂等性

• GET：幂等（多次执行结果相同）；
• POST：非幂等（可能产生不同结果）；

常见误区

• POST 并不比 GET 更安全（安全性依赖于 HTTPS）；
• POST 没有“隐藏参数”特性；
• 大数据传输推荐 POST，但 HTTP 规范未限制 GET 的请求体使用；

GET 请求可以带 body 吗？

RFC 规范并没有规定 GET 请求不能带 body。任何请求都可以带 body。 GET 请求是获取资源，所以根据这个语义，其实不需要用到 body。URL 中的查询参数也不是 GET 所独有的，POST 请求的 URL 中也可以有参数的。

既然有 HTTP 协议，为什么还要有 RPC？

定义：基于传输层的 TCP 协议，产生了应用层的 HTTP 协议和 RPC 协议（实际上 RPC 不能被称之为具体的协议，它其实是一种调用方式），本质上 HTTP 和 RPC 只是定义了不同格式的应用层协议而已。HTTP 是超文本传输协议，RPC 是远程过程调用。虽然大部分 RPC 协议的底层使用 TCP，但实际上 RPC 并不是一定要基于 TCP 进行传输，可以改用 UDP 或 HTTP。

服务发现：在使用 HTTP 时，只要知道服务的域名，就可以通过 DNS 服务去解析得到 IP 地址，默认 80 端口。RPC 一般有专门的中间服务去保存服务名和 IP 信息，比如 consul（服务发现）或 etcd，或 redis。想要访问某个服务，就去这些中间服务获取 IP 和端口信息。由于 DNS 也是服务发现的一种，所以也有基于 DNS 去做服务发现的组件，比如 CoreDNS。

底层连接方式：HTTP 协议默认在建立底层 TCP 连接后会一直保持连接（keep-alive），之后的请求和响应会复用连接。RPC 通过 TCP 长连接进行数据交互，但 RPC 一般还会建一个连接池，在请求量大的时候，建立多条连接放在池内，要发数据时从池里取一条连接出来，用完放回去，便于下次复用。

传输的内容：HTTP 设计初是用于做网页文本展示的，传输内容以字符串为主，有 header 和 body。在 body 这块，它使用 json 来序列化结构体数据，内容会有冗余。RPC 因为定制化程度更高，可以采用体积更小的 protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因【总结一下，抛弃 HTTP 改用 RPC 的主要原因是 RPC 的传输数据格式的定制化程度更高，不需要像 HTTP 那样考虑浏览器行为，因此性能更好】。

【协议效率差异：HTTP/1.1 文本协议中的 Header 包含冗余，比如 Cookie/UA 等无意义字段，ASCII 编码的体积较大；而 RPC 在编码时使用二进制，基于 Protobuf/Thrift 的编码体积可以缩小 50% 到 80%，序列化速度快 5 ~ 10 倍】

通信模型深度：HTTP 基于 Request 和 Response 进行单向通信，而 RPC 支持 Streaming、背压控制、元数据交换等高级且复杂的交互模式。

什么是 XSS 攻击？有什么解决办法？

XSS 是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到 web 页面中去，使别的用户访问时都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

什么是 CSRF 攻击？有什么解决办法？

CSRF 就是跨站请求伪造。比如，登录受信任网站 A，并在本地生成 Cookie，之后在不登出 A 的情况下，访问危险网站 B（利用了 A 的漏洞）。可以通过 Token 验证、隐藏 token 到 http head 中（隐藏令牌）、Referer 验证等方式防范。

什么是中间人攻击以及如何防范？

中间人攻击指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

可以通过使用HTTPS协议，禁用不安全的SSL协议，启用虚拟专用网（VPN）来防范。