GQ-计算机网络

HTTP 1.0 和 2.0 有什么区别？

HTTP/1.0（最早期版本）

  • 每次请求都要重新建立 TCP 连接，效率很低。
  • 只能串行传输，一个请求一个响应。
  • 支持一些基本方法，比如 GET、POST、HEAD。
  • 响应只能传输文本，扩展性差。

HTTP 1.0 就像每次买东西都要重新开个柜台，只能一手交钱一手交货，效率特别低。

HTTP/1.1（最广泛使用的版本）

  • 引入 持久连接（keep-alive），一个 TCP 连接可以处理多个请求。
  • 支持 管道化（pipeline）：可以连续发多个请求，但响应仍需按顺序返回。
  • 加入 分块传输（chunked），支持动态内容输出。
  • 新增 Host 头部，支持同一 IP 部署多个域名。
  • 支持缓存控制、带宽优化等功能。

HTTP 1.1 就像开了一个‘批发通道’，一次连接可以传多批货，但货还是得按顺序来，后面的要等前面的收完。

HTTP/2.0（革命性升级）

  • 二进制分帧：数据以二进制格式传输，更高效。
  • 多路复用（Multiplexing）：一个 TCP 连接里可以并行传多个请求，不再互相阻塞。
  • 头部压缩（HPACK）：减少重复头部字段，节省带宽。
  • 服务器推送（Server Push）：服务器可主动给客户端推资源。

HTTP 2.0 就像开了一个‘多车道高速公路’，多辆车（请求）能同时跑，还能压缩货物（头部压缩），服务器甚至能提前帮你送货（Server Push）。

小结

HTTP 1.0 是最早版本，每次请求都要重新建立连接；
HTTP 1.1 加入了长连接、Host、分块传输等功能，提升了效率；
而 HTTP 2.0 则彻底优化了协议层，引入多路复用、二进制传输和头部压缩，
让同一个连接可以同时传多个请求，延迟更低、速度更快

HTTP/2.0 和 HTTP/3.0 的区别

传输层协议不同

  • HTTP/2：基于 TCP，用“二进制分帧层”实现多路复用。
  • HTTP/3：基于 UDP，使用 QUIC 协议（Quick UDP Internet Connections）。QUIC 在 UDP 上封装了可靠传输、拥塞控制等机制，效果类似 TCP，但更快。

“可以理解成 HTTP/3 把原本跑在 TCP 上的‘货运火车’，换成了基于 UDP 的‘高速快递车’，速度更快，还不容易堵车。

性能与可靠性差异

  • HTTP/2：虽然解决了 HTTP/1.x 的队头阻塞，但仍受 TCP 层队头阻塞影响。
    • 一旦丢包，整个连接的所有请求都会卡住。
  • HTTP/3：由于 QUIC 在 UDP 层自带多路复用和重传机制，
    • 丢包只影响一个流，不会卡死整个连接，在高延迟或弱网环境下性能更优。

HTTP/2 一辆车爆胎，全线堵；HTTP/3 每辆车独立走，互不影响。

安全性区别

  • HTTP/2：可以使用 TLS（通常是 HTTPS），但不是强制的。
  • HTTP/3：默认内置 TLS 1.3，加密是强制开启的，安全性更高。

HTTP/3 是自带加密的‘全程护送快递’，安全性能更强。

连接建立速度

  • HTTP/2：需要经历 TCP 三次握手 + TLS 握手，连接建立慢。
  • HTTP/3：QUIC 协议将握手和加密合并，一次握手即可建立安全连接，速度更快，尤其在移动网络中优势明显。

HTTP/2 要两次握手才能上高速；HTTP/3 一次就能起飞。

对比项 HTTP/2 HTTP/3
传输层协议 TCP UDP（基于 QUIC）
队头阻塞 有（TCP 层阻塞） 无（QUIC 层独立流）
加密机制 TLS（可选） 内置 TLS 1.3（强制）
连接速度 慢（需多次握手） 快（一次握手）
性能 受限于 TCP 稳定且高效
兼容性 浏览器和服务器广泛支持 新协议，逐步推广中

小结

HTTP/2 基于 TCP，实现了多路复用，但还是会受 TCP 队头阻塞影响；
HTTP/3 改用 UDP 上的 QUIC 协议，彻底解决队头阻塞，
而且连接更快、内置 TLS 1.3 更安全，特别适合移动和弱网环境。

常见的 HTTP 状态码有哪些？

HTTP 状态码用来表示服务器对请求的处理结果，按照首位数字可以分为五大类：信息响应、成功、重定向、客户端错误和服务器错误

1xx —— 信息响应（Informational）

表示请求已被接收，正在继续处理。

  • 100 Continue：客户端可以继续发送请求（常见于大文件上传）。
  • 101 Switching Protocols：服务器同意协议切换，比如从 HTTP 切到 WebSocket。

这类状态码基本是个‘中间信号’，告诉客户端：我收到了，继续发吧。

2xx —— 成功（Success）

请求被正常处理完成。

  • 200 OK：请求成功并返回了数据（最常见）
  • 201 Created：请求成功并创建了资源（常见于 POST）。
  • 204 No Content：请求成功但无返回内容（常用于删除操作）。
  • 206 Partial Content：返回部分数据（断点续传用）。

看到 2 开头的状态码就代表一切正常，比如 200 就是‘OK，搞定了’。

3xx —— 重定向（Redirection）

资源位置发生了变化，客户端需要用新的地址访问。

  • 301 Moved Permanently：永久重定向（资源位置变了）。
  • 302 Found：临时重定向（还可能再变）。
  • 304 Not Modified：资源未修改，客户端可直接使用缓存。

“3xx 就是告诉浏览器：‘别找我了，换个地儿访问。’”

4xx —— 客户端错误（Client Error）

请求有问题，服务器无法处理。

  • 400 Bad Request：请求语法错误。
  • 401 Unauthorized：缺少或无效的认证。
  • 403 Forbidden：拒绝访问（权限问题）。
  • 404 Not Found：资源不存在（最常见）。

4xx 基本就是‘你客户端的问题’，比如 404 就是‘找不到页面’。

5xx —— 服务器错误（Server Error）

请求是对的，但服务器出错了。

  • 500 Internal Server Error：服务器内部错误。
  • 502 Bad Gateway：网关或代理收到无效响应。
  • 503 Service Unavailable：服务器暂时不可用（超载或维护）。

5xx 则是‘我（服务器）自己出问题了’，不是你的锅。

小结

HTTP 状态码分五类：1xx 是信息响应，比如 100；
2xx 表示成功，比如最常见的 200；
3xx 是重定向，比如 301、302；
4xx 是客户端错误，比如 404 找不到页面；
5xx 是服务器错误，比如 500 内部错误。
看到 2 开头一般就说明一切正常，其它都是异常信号。

HTTP 请求包含哪些内容，请求头和请求体有哪些类型？

HTTP：Hyper Text Transfer Protocol (超文本传输协议)，规定了浏览器与服务器之间数据传输的规则。

  • http 是互联网上应用最为广泛的一种网络协议
  • http 协议要求：浏览器在向服务器发送请求数据时，或是服务器在向浏览器发送响应数据时，都必须按照固定的格式进行数据传输

HTTP 协议的特点

  • 基于 TCP 协议: 面向连接，安全

TCP 是一种面向连接的 (建立连接之前是需要经过三次握手)、可靠的、基于字节流的传输层通信协议，在数据传输方面更安全

  • 基于请求 - 响应模型: 一次请求对应一次响应（先请求后响应）

请求和响应是一一对应关系，没有请求，就没有响应

  • HTTP 协议是无状态协议: 对于数据没有记忆能力。每次请求 - 响应都是独立的

无状态指的是客户端发送 HTTP 请求给服务端之后，服务端根据请求响应数据，响应完后，不会记录任何信息。

  • 缺点：多次请求间不能共享数据

  • 优点：速度快

  • 请求之间无法共享数据会引发的问题：

    • 如：京东购物。加入购物车和去购物车结算是两次请求
    • 由于 HTTP 协议的无状态特性，加入购物车请求响应结束后，并未记录加入购物车是何商品
    • 发起去购物车结算的请求后，因为无法获取哪些商品加入了购物车，会导致此次请求无法正确展示数据

  • 具体使用的时候，我们发现京东是可以正常展示数据的，原因是 Java 早已考虑到这个问题，并提出了使用会话技术 (Cookie、Session) 来解决这个问题。

HTTP 协议又分为：请求协议和响应协议

请求协议：浏览器将数据以请求格式发送到服务器。包括：请求行、请求头 、空行、请求体

HTTP 请求的组成部分

组成部分 作用说明
请求行（Request Line） 包含请求方法（如 GET、POST）、请求的资源路径（如 /index.html）和 HTTP 版本号（如 HTTP/1.1）。
请求头（Request Headers） 以键值对形式传递客户端环境、认证信息、请求内容等。
空行（Blank Line） 用来分隔请求头和请求体。
请求体（Request Body） 存在于 POST、PUT 等请求中，用于发送数据给服务器，比如表单、JSON、文件等。

简单说，HTTP 请求就像一封信：
请求行是信封上的地址，请求头是寄件人信息，请求体就是信的正文内容。

常见的请求头类型

类型 说明 示例
通用头部（General Headers） 请求和响应都能用 Cache-Control, Connection
请求头部（Request Headers） 只在请求中使用 Host, User-Agent, Accept, Authorization
实体头部（Entity Headers） 描述请求体内容 Content-Type, Content-Length

比如登录接口就会带上 Authorization，而提交 JSON 数据时会带 Content-Type: application/json。

常见请求体类型

类型 Content-Type 值 使用场景
表单数据（Form Data） application/x-www-form-urlencoded 提交普通表单数据
多部分数据（Multipart Data） multipart/form-data 文件上传或复杂表单
JSON 数据 application/json 提交 JSON 格式内容（REST 接口最常见）
XML 数据 application/xml 提交 XML 格式数据（SOAP 协议常见）
文本数据 text/plain 传输纯文本内容

比如前端调用接口提交 JSON，用的就是 application/json；而文件上传表单用的是 multipart/form-data。

小结

HTTP 请求主要分四部分：请求行、请求头、空行和请求体。

请求行里有方法、路径、协议版本；请求头携带各种信息；空行用于分隔请求头和请求体；请求体是要发给服务器的数据。

常见的请求头像 User-Agent、Content-Type、Authorization，而请求体的格式有表单、JSON、XML、文件上传等，取决于业务场景。

HTTP 和 HTTPS 有什么区别？

数据传输安全性

  • HTTP：明文传输，数据直接在网络中暴露，容易被窃听、篡改或伪造。
  • HTTPS：通过 SSL/TLS 协议 对数据进行加密， 提供了三大安全保障：1️ 加密（防窃听）2️ 身份验证（防伪造）3️ 数据完整性（防篡改）

HTTP 像明信片，谁都能看到内容；HTTPS 就像密封信封，只有收件人能看。

端口号区别

  • HTTP：默认使用 80 端口
  • HTTPS：默认使用 443 端口

所以浏览器里如果你看到网址以 ‘https://’ 开头，就说明它走的是 443 端口，数据是加密传输的。

性能差异

以前 HTTPS 比 HTTP 慢，现在基本没差了。尤其用了 HTTP/2、HTTP/3 后更快。

SEO（搜索引擎）影响

  • HTTP：搜索引擎通常认为不安全，排名会被压低。
  • HTTPS：谷歌、百度等搜索引擎会优先展示 HTTPS 网站，用户浏览器也会显示“安全锁”标识。

小结

HTTP 是明文传输，不安全，容易被劫持或篡改；
HTTPS 在 HTTP 上加了 SSL/TLS 加密，保证数据安全和完整；
它用 443 端口，虽然早期稍慢，但现在性能差距不大，
而且更受搜索引擎信任，几乎所有网站都在用 HTTPS。

HTTP 中 GET 和 POST 的区别是什么？

GET 是“拿数据”，POST 是“交数据”。
GET 用来从服务器获取资源，而 POST 用来向服务器提交数据。它们在参数传递、安全性、幂等性等方面都有区别。

定义区别

方法 说明
GET 用于获取资源，一般是查询数据，不会改变服务器状态。
POST 用于提交数据到服务器，比如创建、更新或触发某种操作。

“GET 就像是查数据，不动库；POST 就像是写数据，可能会改库。”

参数传递方式

对比项 GET POST
参数位置 拼接在 URL 上（如 /user?id=1） 放在请求体（body）中
是否可见 参数会显示在浏览器地址栏中 参数不会显示，比较隐蔽
长度限制 有限制（取决于浏览器或服务器） 理论上无限制，适合传大数据

“GET 的参数写在地址上，看得见；POST 的参数放在包里，看不见。”

安全性区别

项目 GET POST
是否安全 安全性低，容易被浏览器缓存、记录或篡改 安全性相对高，但仍需配合 HTTPS 使用
适用场景 查询公开数据 提交敏感数据（如登录表单、上传文件）

“GET 像明信片，所有人都能看到内容；POST 像信封，虽然看不到，但仍要加密才真正安全。”

幂等性（Idempotent）

方法 是否幂等 含义
GET 是 多次请求结果相同，不会改变服务器数据。
POST 否 多次请求可能创建多条数据或多次执行操作。

“GET 请求发十次结果一样；POST 发十次可能插十条数据。”

小结

GET 和 POST 最大的区别在于作用和传参方式。
GET 一般用来获取数据，参数拼在 URL 上，可见且长度有限；
POST 用来提交数据，参数放在请求体里，适合传大文件或敏感信息。
GET 是幂等的，多次请求不会改变数据；POST 不是幂等的，可能会新增或修改数据。

TCP 是用来解决什么问题？

TCP 的核心作用是——在不可靠的 IP 网络上实现可靠传输。

它主要解决了四个问题：

  • 可靠性传输：通过确认（ACK）、重传、序列号机制，保证数据不丢、不重、不乱序。
  • 流量控制：用滑动窗口调节发送速度，防止把接收方“冲爆”。
  • 拥塞控制：用慢启动、拥塞避免、快速重传等算法，防止网络过载。
  • 连接管理：通过三次握手、四次挥手来建立和断开连接，保证通信双方状态一致。

TCP 解决的是“数据传得又稳又准”的问题。

TCP 和 UDP 有什么区别？

TCP 和 UDP 都是传输层协议，最大的区别就在于：
TCP 是面向连接、可靠传输的；UDP 是无连接、不保证可靠的。

连接方式不同

  • TCP 是“面向连接”的，在传数据之前要先三次握手，建立可靠连接；传完后还要四次挥手断开。
  • UDP 是“无连接”的，发数据之前不需要建立连接，直接发——就像发快递不打电话确认，对方收不收不管，发出去就完。

可靠性不同

  • TCP 会通过确认应答、重传机制、滑动窗口、流量控制等手段来保证数据一定能到、顺序也对。
  • UDP 就是“尽力而为”，不保证一定送到，也不保证顺序正确。

所以 TCP 可靠但慢，UDP 不可靠但快。

数据传输方式

  • TCP 是字节流传输，像一条连续的水流，数据之间没有明显边界；
  • UDP 是报文传输，每次发送就是一个独立的数据包，收多少发多少，不会粘包。

头部大小

  • TCP 头部大（至少 20 字节），带了序号、确认号、窗口等字段；
  • UDP 头部只有 8 字节，更轻量。

性能与应用场景

TCP 传输更可靠但延迟高，适合对准确性要求高的应用，比如：文件传输、邮件、网页、数据库通信。

UDP 延迟低，传输效率高，适合对实时性要求高的，比如：语音、视频通话、直播、游戏、物联网通信。

小结

  • TCP 是面向连接、可靠传输的协议，会通过三次握手建立连接，保证数据不丢、不乱序、可重传，适合对可靠性要求高的场景，比如文件传输、邮件、网页通信。
  • UDP 是无连接、面向报文的协议，不保证可靠性，但传输效率高、延迟低，适合对实时性要求高的应用，比如语音、视频、游戏、直播。

TCP 稳但慢，UDP 快但不保证到。

TCP 的粘包和拆包能说说吗？

TCP 粘包和拆包问题，其实是因为 TCP 是面向字节流的协议，它不会帮你区分每条消息的边界。

所以在发送和接收时，可能会出现两种情况：

  • 粘包：多个小数据包被合并在一起接收，接收方分不清哪条消息是哪个。
  • 拆包：一个完整消息被拆成多段接收，导致接收方收到的不是一整条。
image.png

解决方案

1️ 固定长度：每个消息固定字节数；
2️ 特殊分隔符：用 \n 或其他符号区分消息；
3️ 消息头 + 消息体：头部带上消息长度字段；
4️ 自定义协议：封装统一的消息格式。

说说 TCP 的三次握手？

TCP 建立连接要经过三次握手（Three-way Handshake），它的目的就是让客户端和服务端都确认彼此的接收和发送能力正常。

TCP 三次握手就是：

  • 第一次，客户端发 SYN(同步序列编号)，告诉服务端“我要建立连接，这是我的初始序号”；
  • 第二次，服务端回 SYN + ACK（同步序列编号-确认），表示“我收到了，也告诉你我的初始序号”；
  • 第三次，客户端再回 ACK（确认），确认收到。

客户端 “打招呼” → 服务端 “回应并问好” → 客户端 “确认收到”，这样双方都确认对方在线且状态正常，连接才算真正建立。

为什么要三次？
防止旧连接误触发、保证双方序列号同步。

三次握手就是互相确认，确保双方都准备好再正式通信

说说 TCP 的四次挥手？

TCP 的四次挥手是断开连接的过程，用来确保双方都能安全地结束通信并释放资源。

整个过程分四步：

1️ 第一次挥手（FIN → ACK）：
客户端先说“我不发数据了”，发一个 FIN 包，进入 FIN_WAIT_1 状态。

2️ 第二次挥手（ACK）：
服务器收到后回复 ACK，表示“我知道了”，进入 CLOSE_WAIT 状态。
客户端进入 FIN_WAIT_2 状态。

3️ 第三次挥手（FIN → ACK）：
服务器等自己数据发完，再发一个 FIN 包，表示“我也发完了”，进入 LAST_ACK 状态。

4️ 第四次挥手（ACK）：
客户端收到后再发一个 ACK 确认，进入 TIME_WAIT 状态，等待 2MSL 确保最后的 ACK 不丢失。
等待完毕后彻底关闭连接。

TCP 四次挥手就是：两次关闭、两次确认，确保双方数据都传完、连接安全释放。

什么适合只有三次挥手？
当服务器端收到FIN包时没有数据要发送，就会把FIN和ACK一起发送给客户端，这个时候就是三次挥手。

为什么 TCP 挥手需要有 TIME_WAIT 状态?

  • 确保最后的ACK被成功接收
  • 防止旧的重复分段干扰新连接

说说 TCP 拥塞控制的步骤？

TCP 拥塞控制的目标，是防止网络中因为发送太快而导致拥塞和丢包。它通过控制发送方的速率，让网络保持在高效但不过载的状态。
整个过程分为 四个阶段
1️ 慢启动（Slow Start）
连接刚建立时，TCP 会从很小的速率开始传输。
初始拥塞窗口（cwnd）一般是 1 MSS，每收到一个 ACK，就把 cwnd 加倍，也就是指数增长，直到达到阈值（ssthresh）。

2️ 拥塞避免（Congestion Avoidance）
当 cwnd 达到阈值后，就进入拥塞避免阶段。
这时增长速度放慢，从指数变为线性增长，每个 RTT 只增加 1 MSS，用来防止网络过载。

3️ 快重传（Fast Retransmit）
当发送方收到 3 个重复的 ACK，就认为有包丢失了，会立即重传这个包，不用等待超时，从而更快恢复传输。

4️ 快恢复（Fast Recovery）
进入快恢复时，不会重新回到慢启动。
TCP 会把 cwnd 减半（防止继续拥塞），同时从这个新值开始线性增长，逐步恢复正常速率。

TCP 拥塞控制就是“慢启动、线性加、丢包快重传、恢复快增长”，既保证效率又避免拥塞。

TCP/IP 四层模型是什么？

TCP/IP 四层模型是计算机网络中最常用的通信模型，它把整个网络通信过程划分为 四层：
网络接口层、网络层、传输层、应用层。

网络接口层（Network Interface Layer）

负责在计算机和网络硬件之间传输数据，处理底层的物理连接，比如以太网、Wi-Fi、PPP 等协议。

重点在“数据怎么发出去、怎么收进来”。

网络层（Internet Layer）

核心协议是 IP（IPv4/IPv6），主要负责寻址和路由转发，让数据知道该往哪台机器发。

你可以理解为“帮数据找路走”。

传输层（Transport Layer）

主要是 TCP 和 UDP。
TCP 负责可靠传输（确认、重传、顺序），UDP 则追求速度。

“决定数据怎么送、要不要保证送到”。

应用层（Application Layer）

直接面向用户，比如 HTTP、HTTPS、FTP、SMTP、DNS 等协议。

“让应用程序之间能真正通信”，比如浏览器访问网页用 HTTP。

对比一下 OSI 七层模型

TCP/IP 四层模型可以看作是 OSI 七层模型的简化版。

  • OSI 有七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
  • TCP/IP 把其中的物理层和数据链路层合并成“网络接口层”，又把会话层、表示层和应用层合并成一个“应用层”。

所以它更简洁、更贴近实际网络的实现。

小结

TCP/IP 四层模型是：网络接口层、网络层、传输层、应用层。它让数据“有路走、有序发、有确认、有结果”，是互联网通信的核心基础。

Cookie、Session、Token 之间有什么区别？

我们在做登录认证或状态管理时，常常会用到 Cookie、Session、和 Token。它们的区别主要体现在 存储位置、作用机制、安全性、以及适用场景上。

Cookie 是浏览器端的用来保存用户状态的小型数据文件，比如登录状态、用户偏好或行为记录。
关键点是：数据存在浏览器端。
它每次请求时会自动带到服务器上，用来识别用户是谁。

特点：

  • 存储位置：浏览器端
  • 安全性：容易被篡改，一般要加密
  • 大小限制：单个 Cookie 通常不超过 4KB
  • 适用场景：保存轻量级状态，比如“记住我”、“最近浏览记录”

Session

Session 是服务器端保存用户状态的机制，每个用户会话都会分配一个唯一的 Session ID。
浏览器通过 Cookie 存储这个 ID，下次请求时带上它，服务器根据 ID 找到对应的用户状态。

特点：

  • 存储位置：服务器端（更安全）
  • 安全性：比 Cookie 高，因为数据不暴露给客户端
  • 性能：用户多时，服务器要维护大量 Session，资源消耗较大
  • 适用场景：需要保存较多用户会话信息，比如购物车、登录状态

Token

Token 是一种加密字符串，常用于身份认证和授权。
它一般由服务器生成，用户登录后拿到 Token，以后每次访问接口都带上它，服务端通过验证 Token 判断身份。
Token 通常存在客户端（浏览器、App、本地存储等）。

特点：

  • 存储位置：客户端（不像 Session 一定要依赖服务器内存）
  • 安全性：通过签名防篡改，比如 JWT（Json Web Token）
  • 适用场景：无状态认证，尤其是跨服务、分布式或移动端系统

比如微服务架构中，Token 比 Session 更方便扩展

Cookie 存在浏览器，用来保存轻量状态；
Session 存在服务器，用来保存用户会话；
Token 存在客户端，用来做分布式认证。

简单理解：

  • Cookie/Session：适合单体应用中的登录管理
  • Token（尤其是 JWT）：适合分布式、微服务、跨端登录场景

JWT Token 能说说吗？

JWT Token是用户登录后, 服务器生成JWT并返回给客户端,客户端在后续的请求中通过HTTP头部验证用户身份验证 主要是有Header、Payoad、Signatur 它的优点是包含了所有必要的信息, 所以在验证时不需要查询数据库, 并且跨语言, 几乎所有编程语言都支持它的生成和解析 缺点就是因为JWT是无状态的, 如何废除JWT是个问题, 所以在使用JWT Token时, 要根据具体的应用场景和安全需求来进行权衡

从网络角度来看，用户从输入网址到网页显示，期间发生了什么？

这个问题其实考察的是整个「浏览器发请求到网页渲染」的网络过程。

  1. 浏览器解析 URL
    当用户输入网址后，浏览器首先会解析这个 URL，判断协议（HTTP/HTTPS）、主机名、端口号、路径等信息，准备发起请求。

  2. DNS 解析
    接下来，浏览器需要把域名转换成 IP 地址。
    它会先查本地缓存 → 系统缓存 → 路由器缓存 → DNS 服务器。
    如果本地都没有，就会去 DNS 服务器递归或迭代查询，最终拿到目标服务器的 IP 地址。

  3. 建立 TCP 连接（可能含 HTTPS 握手）
    拿到 IP 后，浏览器和服务器之间会建立 TCP 连接。
    如果是 HTTPS，还要先进行 TLS/SSL 握手来建立加密通道。

TCP 连接建立靠“三次握手”，目的是确认双方通信没问题。

  1. 发送 HTTP 请求
    浏览器根据 URL 生成 HTTP 请求报文（包含方法、请求头、Cookie 等），
    请求会经过应用层 → 传输层（加 TCP 头） → 网络层（加 IP 头） → 数据链路层（加 MAC 头） → 物理层（通过网卡发出去）。

  2. 网络传输
    数据包经过交换机、路由器等网络设备，一层层转发，最终到达目标服务器。
    路由器根据 IP 地址判断下一个目标节点，直到数据到达目标主机。

  3. 服务器处理请求
    服务器接收到请求后，进入后端程序处理逻辑，比如查询数据库、执行业务逻辑，然后生成响应报文返回。

  4. 浏览器接收响应
    浏览器收到响应后，会先解析 HTTP 头，再解析响应体内容。
    如果返回的是 HTML，会继续请求里面的 CSS、JS、图片等资源（这时还会走 DNS、TCP、HTTP 流程）。

  5. 渲染页面
    浏览器解析 HTML 构建 DOM 树，解析 CSS 构建 CSSOM 树，再结合生成渲染树（Render Tree），
    然后布局（Layout）和绘制（Paint），执行 JS，最后页面显示给用户。

小结

浏览器解析 URL → DNS 解析 IP → 建立 TCP/HTTPS 连接 → 发送 HTTP 请求 →
网络层层转发 → 服务器处理返回响应 → 浏览器接收响应并渲染页面。