SL Blog 技术探索 · 工程实践 · AI 时代思考
返回

从一次 ICP 备案，重新理解一次 HTTPS 请求是怎么到服务器的

文章目录
  1. 1. 先说这次备案经历
  2. 我的实际流程
  3. 2. 为什么备案前国外能访问，国内却不行？
  4. 3. 从浏览器输入域名，到 Spring Boot 收到请求
  5. 4. hosts 和 DNS：先解决 ” 服务器在哪 ”
  6. 4.1 hosts 是本机的静态映射
  7. 4.2 DNS 是分层、分布式的
  8. 5. TCP：解决 ” 怎么可靠地把字节送过去 ”
  9. 6. TLS：TCP 已经可靠了，为什么还不够？
  10. 7. 我现在怎么理解 TLS 1.3 的握手
  11. 7.1 ClientHello：我支持什么？
  12. 7.2 ServerHello：我们采用什么规则？
  13. 7.3 Certificate：你到底是谁？
  14. 7.4 CertificateVerify：有证书还不够
  15. 7.5 Finished：前面的协商真的一致吗？
  16. 8. TLS 并不是 ” 以后所有数据都用非对称加密 ”
  17. 9. HTTP 到底负责什么？
  18. 10. HTTP 和 HTTPS 的关系
  19. 11. 网络到底是 4 层还是 7 层？
  20. OSI 七层模型
  21. TCP/IP 四层模型
  22. 12. 最后，我现在脑子里的完整模型
  23. 参考资料

最近给一个域名接入腾讯云中国大陆服务器时，我碰到了一个很直观、但越想越有意思的问题：

域名和服务器都在腾讯云。备案前，国内网络访问异常；切到国外 VPN 出口却可以访问。完成 ICP 备案后，国内访问恢复正常。

本来只是一次备案，最后却把我重新带回了一个很基础的问题：在浏览器里输入一个 https://xxx.com，这个请求到底经历了什么？DNS、TCP、TLS、HTTP 又分别解决什么问题？

这篇文章不是协议手册，只记录==我从这次备案经历一路追下去后，对整条 Web 请求链路形成的一套理解。

1. 先说这次备案经历

我的场景很简单：

域名：腾讯云
DNS：腾讯云 DNSPod
服务器：腾讯云中国大陆 CVM
网站：已经部署完成

域名解析配置完成后，出现了一个比较反直觉的现象：

中国大陆网络        → 访问异常
国外 VPN 出口       → 可以访问

后来在腾讯云发起 ICP 备案。

我的实际流程

  1. 在腾讯云提交首次 ICP 备案。
  2. 备案审核期间暂停网站对应的 DNS 解析，让网站不能通过公网域名正常上线访问。
  3. 腾讯云完成初审后提交管局，并完成工信部短信核验。
  4. 我这次大约经历 7 个工作日；因为中间跨了周末，从自然日看大约 10 天 收到备案通过通知。
  5. 备案通过后重新开启 DNS 解析。
  6. 在网站底部加入 ICP 备案号，并链接到工信部备案查询页面。
  7. 随后继续办理公安联网备案。
  8. 这一步需要本人登录全国互联网安全管理服务平台，并进行实人/人脸认证，这部分 AI 不能替代我完成。
  9. 使用腾讯云同步生成的公安联网备案数据码（我当时理解为 ” 关联码 “）绑定备案信息，检查并补充资料后提交。
  10. 我这次公安联网备案大约 2 天左右 审核完成。
  11. 审核通过后下载公安备案图标、取得 ” 公网安备 ” 编号和链接代码，再把这些信息交给 AI 修改网页、构建和部署。

这里有个挺明显的分工：

必须由我本人完成：
身份登录 / 实人认证 / 人脸验证 / 最终提交

很适合交给 AI：
修改网页 Footer
加入 ICP 备案号
加入公安备案图标与链接
检查样式
构建部署

腾讯云当前官方说明也明确：首次备案、新增网站审核期间不能上线访问，可以通过暂停解析或关闭访问权限实现；ICP 备案通过后，需要在网站底部悬挂备案号并链接工信部备案系统。公安联网备案则应在网站开通后规定期限内完成，审核通过后还要把公安备案号和图标放到网站页面中。

时间说明：“7 个工作日 / 10 个自然日 ” 和 ” 公安备案约 2 天 ” 只是我这一次的实际耗时，不是官方承诺时限。

ICP备案前后访问控制示意

2. 为什么备案前国外能访问，国内却不行？

一开始我的直觉是：

是不是没备案，所以国内 DNS 根本不给我解析 IP？

继续查后发现，这个描述过于简单。

腾讯云官方明确公开的是：未备案或未完成腾讯云接入备案的域名，如果直接指向腾讯云中国境内云资源，会被腾讯云的未备案监测系统识别并阻断访问；HTTPS 同样会被阻断。

也就是说，备案不是 ” 工信部给域名发一个 IP”，而更像是一套中国大陆互联网服务的准入状态：

域名
  +
备案主体
  +
接入服务商（腾讯云）
  +
中国大陆云资源 / IP
  ↓
备案状态
  ↓
允许提供网站服务 / 阻断

而 VPN 会同时改变至少两个条件：

1. DNS 查询路径可能从国内 Resolver 变成境外 Resolver
2. TCP 连接源地址和网络入口从国内出口变成境外出口

所以 ” 国外 VPN 能访问 ” 并不能单独证明一定是 DNS 层放行，也可能是访问链路、接入控制策略发生了变化。

腾讯云没有公开它内部完整的备案拦截网络拓扑，因此我现在更愿意把这个现象描述为：

备案前，域名和服务器本身并没有消失；中国大陆这条访问链路没有取得对应的服务准入状态。备案信息同步到腾讯云以后，相关限制解除。

这个问题也成为了我继续往下追的起点：一个域名最终到底是怎么变成服务器上的一次 HTTP 请求的？

3. 从浏览器输入域名，到 Spring Boot 收到请求

假设我访问：

https://www.example.com/users/123

我现在会把整个过程拆成下面这条链：

URL
 ↓
本地 hosts / DNS
 ↓
得到目标 IP
 ↓
IP 路由
 ↓
TCP 建立可靠连接
 ↓
TLS 建立安全连接
 ↓
发送 HTTP 请求
 ↓
腾讯云入口 / 安全组 / Nginx
 ↓
Spring Boot
 ↓
Redis / MySQL / MQ ...
 ↓
HTTP Response
 ↓
TLS 加密
 ↓
TCP 返回
 ↓
浏览器渲染

一次 HTTPS 请求完整流程

这里最关键的是：每一层只解决自己的问题。

4. hosts 和 DNS：先解决 ” 服务器在哪 ”

浏览器知道的是：

www.example.com

真正建立网络连接时需要的是：

43.134.100.20

所以首先要做名称解析。

4.1 hosts 是本机的静态映射

比如：

43.134.100.20 www.example.com

如果本机名称解析命中 hosts，就可以直接得到 IP，不必继续查询公网 DNS。

所以我现在把 hosts 理解为：

电脑自己随身携带的一小份、优先级很高的静态 DNS 表。

它不是完整 DNS 系统，只影响当前机器，也没有 DNS 的分层、缓存、CNAME、MX、GeoDNS 等能力。

4.2 DNS 是分层、分布式的

如果本地没有答案，就交给递归 DNS Resolver。

以 www.example.com 为例，查询大致是：

本地 / 递归 DNS
      ↓
Root（.）
      ↓
.com 顶级域 DNS
      ↓
example.com 的权威 DNS
      ↓
DNSPod
      ↓
A 记录：43.134.100.20

所以 DNS 不是一台 ” 全球域名数据库服务器 “，而是一套分层委托系统。

DNSPod 在我的场景里扮演的主要角色就是：

example.com 的权威 DNS 服务。

它最终回答某个域名应该指向什么 IP。

DNS 完成以后，它这一次主要任务就结束了。

接下来浏览器真正要做的是：

连接 43.134.100.20:443

5. TCP：解决 ” 怎么可靠地把字节送过去 ”

TCP 是这次讨论里我最先想明白的一层。

我一开始把三次握手理解为：

双方想确认彼此都能正常收、正常发，需要至少经过 ” 我发给你 → 你回复我 → 我再确认 ” 这样一次完整的双向状态确认。

这个方向没问题，但还要补充一点：TCP 握手除了确认双向通信，还会同步双方的初始序列号，建立连接状态。

客户端                         服务端

SYN, Seq=x
----------------------------->

                 SYN+ACK
                 Seq=y
                 Ack=x+1
<-----------------------------

ACK
Seq=x+1
Ack=y+1
----------------------------->

          ESTABLISHED

其中：

  • SYN / ACK 是 TCP 控制标志，不是连接身份 ID。
  • 一条 TCP 连接主要通过 ” 源 IP + 源端口 + 目标 IP + 目标端口 ” 区分。
  • Seq / Ack 更像这条连接中字节流的坐标和签收进度。

我后来把 Seq / ACK 理解成：

Seq：我发送的是字节流中的哪一段
Ack：在这之前的数据我都收到了，下一字节我期待从哪里开始

因此它们主要保障的是：

不丢
不乱序
不重复
丢了可以重传

所以更准确的说法不是 “Seq 是身份标识 “，而是：

Seq / ACK 保证一条 TCP 字节流能够完整、有序、可靠地到达。

数据内容有没有在传输过程中产生比特错误，还有 TCP Checksum；而 ” 有没有被恶意篡改 ” 则已经是 TLS 的职责了。

6. TLS：TCP 已经可靠了，为什么还不够？

TCP 能保证：

我发出去的数据
尽量完整、有序地到达服务器

但 TCP 并不保证：

别人看不见
别人改不了
对面的服务器真的是我要找的网站

如果直接使用 HTTP：

POST /login
username=tom
password=123456

TCP 可以非常可靠地把这串数据送到服务器，但这串数据本身可能就是明文。

所以 HTTPS 在 HTTP 和 TCP 中间加了一层 TLS：

HTTP
 ↓
TLS
 ↓
TCP
 ↓
IP

TLS 的核心任务只有三个：

1. 身份认证：对面真的是 example.com 吗？
2. 密钥协商：双方如何得到只有彼此知道的共同秘密？
3. 加密与完整性：之后的数据不能被偷看，也不能被悄悄修改。

TCP、TLS 与网络分层

7. 我现在怎么理解 TLS 1.3 的握手

一开始 TLS 的 Certificate、KeyShare、Finished 看起来非常乱。

后来我发现可以把它压缩成 三个主要消息批次 来理解：

客户端                                        服务器

① ClientHello
“我支持这些 TLS 能力，
这是我的密钥协商材料。”
-------------------------------------------->

                         ② ServerHello
                         “我们就用这些规则。”

                         Certificate
                         “这是我的网站证书。”

                         CertificateVerify
                         “我证明证书对应的私钥在我手上。”

                         Finished
                         “我的握手状态确认完成。”
<--------------------------------------------

③ Client Finished
“证书验证成功，
共享秘密也计算成功，
前面的握手没有问题，开始加密通信。”
-------------------------------------------->

这和 TCP 三次握手有一种很有意思的相似性：

TCP：
建立双方都认可的“连接状态 + Seq 状态”

TLS：
建立双方都认可的“身份状态 + 密钥状态”

但不能简单理解成 ” 任何双方确认一件事都必须三次通信 “，只是 TLS 1.3 的常规完整握手恰好被压缩到了这样的消息往返结构。

TLS 握手详解

7.1 ClientHello：我支持什么？

客户端首先告诉服务器：

我支持 TLS 1.3
我支持哪些密码套件
我要访问 example.com（SNI）
这是我的临时 KeyShare

这一步不是在请求网页内容。

此时还没有：

GET /users/123

它只是在问：

我们能不能先建立一条安全通道？

7.2 ServerHello：我们采用什么规则？

服务器选择双方都支持的 TLS 参数，并返回自己的密钥协商材料。

现代 TLS 1.3 常见做法是 ECDHE。

最值得记住的不是数学细 [节，而是这个性质：

双方不需要把最终 Session Key 直接发到网络上，却可以各自在本地计算出相同的共享秘密。

客户端私有信息 + 服务器公开信息
                  ↓
             Shared Secret X

服务器私有信息 + 客户端公开信息
                  ↓
             Shared Secret X

监听网络的人虽然能看到公开交换的信息，却无法现实地计算出同一个 X。

7.3 Certificate：你到底是谁？

只有密钥协商还不够。

因为我可能确实和 ” 某个人 ” 建立了一条加密连接，但这个人是不是 example.com？

于是服务器发送证书：

Certificate
- 域名
- 公钥
- 有效期
- CA 签发信息
- 数字签名

浏览器再通过自己的可信 CA 体系验证：

证书有没有过期？
域名匹不匹配？
签发 CA 是否可信？
证书链是否成立？

7.4 CertificateVerify：有证书还不够

证书本身是公开的，任何人都能复制。

真正的服务器还持有：

Private Key

服务器通过私钥对握手数据签名，浏览器使用证书中的公钥验证签名。

于是证明：

对面不仅拿着 example.com 的公开证书，而且真的持有与这个证书匹配的私钥。

7.5 Finished：前面的协商真的一致吗？

双方最后通过 Finished 消息确认：

握手消息没有被中途篡改
双方确实得到了正确的握手密钥
双方准备进入正式加密通信

然后 TLS 安全通道建立完成。

8. TLS 并不是 ” 以后所有数据都用非对称加密 ”

这是我最开始容易误解的一点。

更准确的结构是：

握手阶段
ECDHE + 公钥/私钥 + 数字签名 + 证书
                ↓
        建立 Shared Secret
                ↓
          派生会话密钥

正式通信阶段
AES / ChaCha20 等对称加密
                ↓
       高速加密 HTTP 数据

为什么？

因为非对称密码学非常适合解决：

身份认证
密钥协商
数字签名

但不适合拿来高速加密大量网页、JSON、图片数据。

真正的数据传输最终还是使用双方协商出的对称密钥。

所以我现在把 TLS 概括成一句话：

先用非对称密码学解决 ” 你是谁 ” 和 ” 怎么安全地产生共同密钥 “，再用对称加密解决大量数据的高效安全传输。

9. HTTP 到底负责什么？

理解了 TCP 和 TLS 后，HTTP 反而最简单。

HTTP = HyperText Transfer Protocol，超文本传输协议。

我现在的理解是：

HTTP 主要定义客户端和服务器如何表达一次请求，以及服务器如何表达一次响应。

例如：

GET /users/123 HTTP/1.1
Host: example.com
Accept: application/json

表达的是：

我要获取 /users/123
目标 Host 是 example.com
希望返回 JSON

服务器：

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 123,
  "name": "Tom"
}

HTTP 关心：

GET / POST / PUT / DELETE
URL Path
Header
Cookie
Authorization
Body
Status Code
Content-Type

HTTP 不关心：

某个 TCP 包有没有丢
Seq 应该是多少
网络从哪个路由器走
TLS Session Key 是多少

这就是协议分层的价值。

10. HTTP 和 HTTPS 的关系

HTTPS 不是把 HTTP 全部推翻重做。

最简单的理解就是：

HTTP
────────────────
HTTP
 ↓
TCP


HTTPS
────────────────
HTTP
 ↓
TLS
 ↓
TCP

也就是：

HTTPS = HTTP over TLS。

HTTP 决定 ” 说什么 “；TLS 决定 ” 怎么安全地说 “；TCP 决定 ” 怎么可靠地送到 “。

11. 网络到底是 4 层还是 7 层？

两个都对，只是模型不同。

OSI 七层模型

7 应用层
6 表示层
5 会话层
4 传输层
3 网络层
2 数据链路层
1 物理层

它更适合解释 ” 每一类能力属于什么职责 “。

TCP/IP 四层模型

工程实践里更常用：

应用层
传输层
网际层
网络接口层

对应关系可以粗略记成：

OSI 7/6/5  → TCP/IP 应用层
OSI 4      → TCP/IP 传输层
OSI 3      → TCP/IP 网际层
OSI 2/1    → TCP/IP 网络接口层

把这篇文章中的东西放进去：

应用层：HTTP、DNS、TLS（工程上通常归在这里讨论）
传输层：TCP、UDP
网际层：IP、ICMP、路由
接口层：Ethernet、Wi-Fi、MAC、物理介质

所以我以后做开发和排障，更倾向先使用 TCP/IP 四层模型；需要解释协议职责时，再拿 OSI 七层做细分参考。

12. 最后，我现在脑子里的完整模型

以后再看到：

https://www.example.com/users/123

我不会再把它当成 ” 浏览器访问一个网站 ” 这么简单，而是会自动拆成：

① URL
浏览器知道我要访问什么

② hosts / DNS
www.example.com → IP
解决“服务器在哪”

③ IP / 路由
解决“数据从哪条路走到目标机器”

④ TCP
建立可靠字节流
Seq / ACK / 重传 / 顺序
解决“怎么可靠送”

⑤ TLS
证书 + 私钥证明身份
ECDHE 协商共享秘密
Finished 确认握手一致
对称密钥加密数据
解决“怎么安全送、对面到底是谁”

⑥ HTTP
GET /users/123
Header / Body / Status Code
解决“双方到底在表达什么”

⑦ Nginx / Spring Boot
真正处理请求

⑧ MySQL / Redis / MQ
完成业务和数据访问

⑨ HTTP Response
沿原来的安全连接返回

⑩ 浏览器
解析 HTML / CSS / JS，最终把页面显示出来

如果再把它压缩成四句话：

DNS：服务器在哪？
TCP：怎么可靠送？
TLS：怎么安全送，而且怎么证明对方是谁？
HTTP：我们到底要说什么？

这大概就是这次 ICP 备案给我带来的最大额外收获。

原本只是一个 ” 为什么国内打不开、国外 VPN 却能访问 ” 的问题，最后却把域名解析、TCP、TLS、HTTP 和网络分层重新串成了一条完整链路。

很多基础知识单独看都不难。真正有价值的，是把它们放回一次真实请求里，知道每一个协议为什么存在、解决的是上一层无法解决的哪个问题。

参考资料

本文中的备案流程和规则说明主要参考腾讯云 2026 年文档，个人耗时和操作体验则来自本次实际备案过程：

备案政策、平台流程和各地管局要求会调整，实际办理时应以当时的工信部、公安机关和接入服务商页面为准。

分享这篇文章：
分享到 Whatsapp 分享到 Facebook 分享到 X 分享到 Telegram 分享到 Pinterest 通过邮件分享这篇文章

RAG 智能问答

针对本文继续提问：《从一次 ICP 备案，重新理解一次 HTTPS 请求是怎么到服务器的》

上一篇
提高与 AI 的协作效率：把判断留给人，把重复交给 AI
下一篇
两天、60 美元、第一课仍未交付：一次 Codex 教学任务失控复盘

相关文章