当你打开电脑，双击浏览器，在地址栏输入 www.baidu.com 并按下回车，这个过程中到底发生了什么？ 页面似乎在一瞬间加载完成，你看到了熟悉的搜索框，但在背后，计算机和网络世界中却发生了一系列复杂而精妙的动作。
这就是计算机网络的魅力：它让全球数十亿台计算机可以“说同一种语言”，把信息从地球的一端传到另一端，就像一封信件能从你手中出发，跨越千里万里，最终送到正确的收件人手里。
对于一名大一新生来说，计算机网络听起来或许有点抽象：协议、分层、端口、IP……这些陌生的名词似乎离你很远。 但事实上，它们和我们的生活息息相关：
- 你发微信，其实就是客户端与服务器之间的一次 消息传输。
- 你在线看视频，本质上是数据通过 不同的协议 在网络中持续流动。
- 你打游戏，角色的移动与语音通话，背后依赖的是 不同层次的网络协议。
换句话说，理解网络，就是理解我们每天所依赖的数字世界是如何运转的。
这份扫盲材料的目标并不是要把你训练成网络专家，而是帮助你：
- 建立直观的网络概念 —— 知道“层”和“协议”是怎么回事；
- 理解核心协议的作用 —— TCP、UDP、IP、HTTP、HTTPS；
- 用实际问题串联知识 —— 每个章节都会从一个真实生活中的问题切入，再解释背后的网络原理；
- 打下前后端开发的网络基础 —— 当你写程序、调试接口、部署服务时，能够理解常见的报错和现象。
- 本文会尽量少用公式和纯理论，多用 生活类比（例如快递运输、门牌号、打电话）。
- 每一章都会配上 示意图或流程图，帮助你在脑海中建立清晰的图景。
- 推荐你在阅读过程中，尝试使用一些简单的工具（例如浏览器开发者工具、
ping命令），亲自感受网络的运行。
在日常生活中，我们早已离不开网络：
- 打开微信，和朋友发消息；
- 登录网课平台，观看视频；
- 打开淘宝下单；
- 晚上打几局网络游戏；
- 甚至在宿舍打开电脑，浏览各种学习资料。
这些操作看起来只是“点一下”“输个网址”，但背后却涉及了大量的计算机通信。 我们通常说的“网络”，就是一整套让计算机之间能够交换数据的 规则 + 通道 + 服务 的组合。
想象一下，如果没有统一的规则，每个人发消息的方式都不一样，会发生什么？
- 有人用英语写信；
- 有人用中文语音留言；
- 有人干脆画张图寄过去。
这样一来，即使消息送到了，收件人也可能看不懂。
在计算机的世界里，也存在类似问题。不同品牌、不同系统、不同年代的设备如何保证 互相能理解彼此的数据？ 答案就是：协议（Protocol）。
协议就是一套约定好的规则：
- 什么时候开始通信；
- 用什么格式表达内容；
- 遇到错误该怎么处理。
如果把网络比作快递运输，那么协议就像快递公司统一的包装和单据规则，保证无论你寄的是什么物品，快递员都知道该怎么处理。
现实中的邮政系统有清晰的分工：
- 你写信，负责内容；
- 快递员负责揽收；
- 中转站负责分拣；
- 卡车、飞机负责运输；
- 最后邮递员送到收件人手里。
计算机网络也采用类似的分工思路 —— 分层结构。 这样做的好处是：
- 每一层只管自己的任务，不必关心其他层如何实现。
- 不同厂商可以在各自负责的层次改进，而不会破坏整体兼容性。
在学网络时，最经典的就是 OSI 七层模型 和 TCP/IP 四层模型。
-
OSI 七层模型：理论上最完整的分层体系，包括物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
-
TCP/IP 四层模型：更贴近现实应用，主要分为：
- 网络接口层（物理传输）
- 网络层（IP）
- 传输层（TCP/UDP）
- 应用层（HTTP、DNS 等）
在本书中，我们会重点关注 网络层、传输层、应用层，因为它们和日常开发、使用网络最相关。
-
图 1.1：邮政系统与网络分层对比图
- 左边：写信 → 快递员 → 中转站 → 运输 → 投递员 → 收件人
- 右边：应用层 → 传输层 → 网络层 → 数据链路层 → 物理层 → 目标主机
邮政系统: 网络分层:
+----------+ +----------+
| 写信 | | 应用层 |
+----------+ +----------+
| |
v v
+----------+ +----------+
| 快递员收件 | --> | 传输层 |
+----------+ +----------+
| |
v v
+----------+ +----------+
| 中转分拣 | --> | 网络层 |
+----------+ +----------+
| |
v v
+----------+ +----------+
| 运输车辆 | --> | 数据链路层|
+----------+ +----------+
| |
v v
+----------+ +----------+
| 投递员 | --> | 物理层 |
+----------+ +----------+
| |
v v
+----------+ +----------+
| 收件人 | --> | 目标主机 |
+----------+ +----------+
-
图 1.2：OSI 七层模型与 TCP/IP 四层模型对照表
- 用表格形式展示：每一层的名称、作用、典型协议（如 HTTP、TCP、IP）。
+------------------+--------------------+----------------+
| OSI 七层模型 | TCP/IP 四层模型 | 典型协议 |
+------------------+--------------------+----------------+
| 应用层 | 应用层 | HTTP, DNS, SMTP|
| 表示层 | | |
| 会话层 | | |
+------------------+--------------------+----------------+
| 传输层 | 传输层 | TCP, UDP |
+------------------+--------------------+----------------+
| 网络层 | 网络层 | IP, ICMP |
+------------------+--------------------+----------------+
| 数据链路层 | 网络接口层 | 以太网, WiFi |
| 物理层 | | |
+------------------+--------------------+----------------+
本章我们建立了对计算机网络的初步认识：
- 网络就是让计算机交换数据的体系；
- 协议是沟通规则，保证数据能够正确理解；
- 分层结构让复杂问题变得可管理，不同层次各司其职；
- 我们学习时主要采用 TCP/IP 四层模型，并重点关注网络层、传输层、应用层。
在接下来的章节里，我们会逐层展开，看看数据在网络层是如何找到方向的，在传输层如何实现可靠传输，又在应用层如何最终呈现为用户可见的网页或应用功能。
在网络世界中，每一台设备（电脑、手机、服务器）都需要有一个“门牌号”，否则数据根本找不到目的地。这个“门牌号”就是 IP 地址（Internet Protocol Address）。
- IPv4：最常见的格式是
192.168.1.1，由四段数字组成，每段范围是 0–255。 - IPv6：由于 IPv4 地址已经不够用，新的 IPv6 使用更长的地址（例如
2408:4003:10:1234::1），可以支撑未来几十年的发展。
类比现实生活：
- IP 地址 = 家庭住址
- 数据包 = 快递包裹
- 没有 IP 地址，包裹根本无法送到收件人手中。
你可能听说过 内网 IP 和 公网 IP。
- 公网 IP：全球唯一，就像一个标准邮政地址，互联网上任何人都能找到你。
- 内网 IP：只在局域网内有效，常见于宿舍、办公室、家庭路由器分配的地址。
为什么要区分？ 因为公网 IP 数量有限，每个家庭或公司通常只分到一个公网 IP，然后路由器再通过 NAT（网络地址转换） 给内部设备分配内网 IP。
举个例子：
- 你的宿舍可能有 4 台电脑、6 部手机，但对外访问时，它们看起来都来自同一个公网 IP。
知道了地址，还需要有人负责“送货”。在网络中，这个角色就是 路由器（Router）。
-
路由器的任务：检查数据包的目的 IP 地址，决定下一步要把它转发到哪里。
-
转发过程：
- 数据包进入路由器。
- 路由器查找“路由表”。
- 根据目的地址，选择最佳路径，转交给下一个节点。
你可以把它类比为邮政系统中的中转站：信件在全国的分拣中心之间跳转，最终送达正确的城市和街道。
假设你在宿舍打开电脑，输入 www.baidu.com：
- 电脑先通过 DNS 解析得到百度服务器的 IP 地址，比如
220.181.38.148。 - 数据包从你的电脑发出，交给宿舍路由器。
- 宿舍路由器发现目的 IP 不在局域网内，于是把包转发到校园网出口。
- 校园网的核心路由器再判断应该走向哪个运营商网络。
- 数据包可能经过十几个甚至几十个路由器，最终抵达百度服务器。
整个过程就像一封信从寝室信箱 → 学校邮局 → 城市邮局 → 国家邮政 → 收件人手里。
你可能发现：访问国内网站很快，但访问国外网站（比如美国的某个学校官网）会很慢。 这是因为：
- 数据包要经过更多的路由器，中间路径更长；
- 跨境链路带宽有限，容易拥堵；
- 国际路由协议可能选择了“不是最短但更稳定的路径”。
这就像国内寄信只需要两三天，而寄到国外可能需要一两周。
-
图 2.1：IPv4 与 IPv6 对比图
- 左边：IPv4 格式（如
192.168.0.1），32 位地址； - 右边：IPv6 格式（如
2408:4003:10:1234::1），128 位地址。
- 左边：IPv4 格式（如
IPv4 (32位地址): IPv6 (128位地址):
+----------------+ +------------------------------+
| 192.168.1.100 | | 2408:4003:10:1234::1 |
+----------------+ +------------------------------+
| 四段数字表示 | | 八组十六进制数表示 |
| 每段0-255 | | 更大的地址空间 |
+----------------+ +------------------------------+
| 约43亿个地址 | | 约340万亿亿亿亿个地址 |
+----------------+ +------------------------------+
-
图 2.2：公网 IP 与内网 IP 示意图
- 外网：1 个公网 IP；
- 路由器：NAT 转换；
- 内网：多台设备拥有不同的私有地址。
互联网
|
+-----------------+
| 公网IP地址 |
| 202.96.209.133 | (例如)
+-----------------+
|
+-----------------+ NAT转换表
| 路由器/网关 | +---------+---------+
| | |内网IP:端口|外网IP:端口|
| NAT转换功能 | |192.168.1| |
| | |.100:1234|202.96. |
| PPPoE拨号 | |192.168.1| 209.133:|
| DHCP服务 | |.101:5678| 5678 |
+-----------------+ +---------+---------+
|
+----------+----------+
| | |
+-------+ +-------+ +-------+
| PC1 | | 手机 | | 平板 |
|192.168| |192.168| |192.168|
|.1.100 | |.1.101 | |.1.102 |
|:8080 | |:9000 | |:7000 |
+-------+ +-------+ +-------+
(内网IP) (内网IP) (内网IP)
(私有地址) (私有地址) (私有地址)
数据流向示例:
内网设备(192.168.1.100:8080) -> 路由器NAT转换 -> 外网(202.96.209.133:1234)
-
图 2.3：数据包在网络中的传输路径
- 电脑 → 宿舍路由器 → 校园网核心路由器 → 运营商骨干网 → 目标服务器。
源设备 局域网 广域网 目标服务器
+----------+ +--------+ +-----------+ +------------+
| 电脑 | -IP包-> | 路由器 | -> | 核心路由 | - -> | 百度服务器 |
|192.168. | | | | 器/交换机 | |220.181.38.|
|.1.100 | | | | | | 148 |
+----------+ +--------+ +-----------+ +------------+
| | | |
v v v v
封装数据包 路由转发 多级路由转发 解封装数据包
添加MAC头 根据IP地址 根据路由表 提交给应用
添加IP头 查找路由表 转发到下一跳 (HTTP服务)
在本章中，我们学习了：
- IP 地址是网络通信的“门牌号”；
- 公网 IP和内网 IP的区别，以及 NAT 的作用；
- 路由器就像邮政分拣中心，负责把数据一步步送到正确的位置；
- 访问国外网站慢，往往和路径更长、带宽受限有关。
在接下来的章节里，我们将进一步学习 传输层 —— 数据到达目标之后，如何确保它不会丢失、不会重复，并且按照正确的顺序送到应用程序手中。
在上一章中，我们学会了“如何找到目标地址”。 但是，单单知道目标还不够。想象一下：
- 快递送到你家，但箱子破了，东西缺了一半；
- 信件虽然到了，但内容顺序乱了；
- 甚至邮递员直接没把信送来。
在网络中，IP 层只负责“把包裹送到目的地”，但它并不保证：
- 包裹（数据）一定会完整送达；
- 包裹顺序正确；
- 包裹不会丢失。
于是，传输层（Transport Layer）登场，解决的是 “如何让数据完整可靠地传递到应用程序” 的问题。
TCP（Transmission Control Protocol，传输控制协议） 是最常用的传输层协议。它的核心任务是：
- 建立连接（确保双方准备就绪）；
- 保证数据不丢失、不重复；
- 按顺序传递数据。
TCP 在传输数据之前，需要确保双方建立一条“可靠的通道”。这就像打电话前需要确认对方接听。 流程是这样的：
- 客户端说：“我想连接你”（SYN）。
- 服务器说：“好的，我准备好了，你呢？”（SYN + ACK）。
- 客户端说：“我也准备好了！”（ACK）。
至此，连接建立完成。
客户端 服务器
| |
| -------- SYN -----------> | (1) 客户端请求连接
| |
| <--- SYN + ACK ---------- | (2) 服务器确认并请求连接
| |
| -------- ACK -----------> | (3) 客户端确认连接
| |
v v
连接建立
在传输过程中，TCP 会：
- 给每个数据分配一个编号（序列号）；
- 接收方收到后发送确认（ACK）；
- 如果发送方迟迟收不到确认，就会重传。
这就像快递员每送一个包裹，收件人都要签收。如果快递员没收到签收信息，就会再次派送。
当数据传输结束后，TCP 需要优雅地关闭连接：
- 客户端说：“我没有数据要发了，可以结束了。”（FIN）。
- 服务器说：“我知道了。”（ACK）。
- 服务器说：“我也发完了，可以结束了。”（FIN）。
- 客户端说：“收到，拜拜。”（ACK）。
客户端 服务器
| |
| -------- FIN -----------> | (1) 客户端请求断开
| |
| <------- ACK ------------ | (2) 服务器确认收到断开请求
| |
| <------- FIN ------------ | (3) 服务器也请求断开
| |
| -------- ACK -----------> | (4) 客户端确认断开
| |
v v
连接完全断开
与 TCP 不同，UDP（User Datagram Protocol，用户数据报协议） 更像是“直接往门口扔快递”。
特点：
- 无连接：不需要三次握手。
- 不保证可靠性：不管丢不丢、顺序乱不乱。
- 速度快：因为省去了握手、确认等过程。
常见应用场景：
- 视频会议、直播：丢几个包不会影响整体体验，但延迟必须尽量低；
- 网络游戏：即使丢失几次位置更新，下一次传输也能纠正。
+-------+----------+----------+-------+--------------+
| 协议 | 是否连接 | 是否可靠 | 速度 | 典型应用场景 |
+-------+----------+----------+-------+--------------+
| TCP | 需要 | 是 | 较慢 | HTTP, HTTPS, |
| | 三次握手| | | 文件传输 |
+-------+----------+----------+-------+--------------+
| UDP | 无 | 否 | 快 | 视频直播, |
| | 连接 | | | 在线游戏 |
+-------+----------+----------+-------+--------------+
这往往是因为 TCP 连接中某些数据包丢失，导致后续数据必须等待重传，页面就会卡住。
因为游戏和语音可能使用不同协议：
- 游戏数据可能走 TCP（要求一致性和顺序）。
- 语音通话多用 UDP（允许丢失少量数据，优先保证实时性）。
所以，即使游戏掉线，语音还能继续保持。
-
图 3.1：TCP 三次握手流程图（客户端与服务器三条箭头交互）。
-
图 3.2：TCP 四次挥手流程图（客户端与服务器四条箭头交互）。
-
图 3.3：TCP vs UDP 对比表
- 列：协议、是否有连接、是否可靠、速度、应用场景。
- 行：TCP、UDP。
在本章中，我们学习了：
- TCP 通过三次握手、确认机制、四次挥手，保证了数据传输的可靠性；
- UDP 更快但不可靠，适合实时性要求高的场景；
- 传输层让数据从“能送到目标地址”升级为“能完整、正确地送到应用程序”。
接下来，我们将进入对用户最直观的部分 —— 应用层。在这里，协议直接决定了你能否打开网页、能否访问接口，以及能否保证传输的安全性。
到目前为止，我们已经知道：
- IP 层负责找到目标地址；
- **传输层（TCP/UDP）**负责让数据完整可靠地送达。
但对于普通用户来说，他们并不关心“分组有没有重传”或者“握没握手”。 用户关心的是：
- 能不能打开百度首页？
- 能不能顺利发邮件？
- 微信消息能不能秒送到？
而这些，都属于 应用层（Application Layer） 的范畴。应用层是网络协议栈中最贴近用户的部分，也是我们日常最常打交道的。
HTTP（HyperText Transfer Protocol，超文本传输协议）是万维网的基石。
- 用户在浏览器输入网址，实际上就是在发起一个 HTTP 请求；
- 服务器会返回一个 HTTP 响应，其中包含网页内容。
HTTP 本身是不加密的，信息在传输过程中可能被窃听或篡改。 HTTPS = HTTP + TLS/SSL 加密。
- 优点：数据加密、防止中间人攻击；
- 缺点：需要证书，建立连接时比 HTTP 慢一点。
插图 4.1：HTTP vs HTTPS 对比图（明文传输 vs 加密传输）。
我们记住的是“baidu.com”，但计算机只认 IP 地址。 DNS（Domain Name System，域名系统）就像一本网络电话簿：
- 输入域名，DNS 会帮你查到对应的 IP 地址。
- 没有 DNS，用户就得记住一长串 IP，非常不方便。
插图 4.2：用户输入“baidu.com” → DNS 服务器 → 返回 IP 地址 → 访问百度。
电子邮件的收发涉及不同协议：
-
SMTP（Simple Mail Transfer Protocol）：负责发送邮件；
-
POP3/IMAP：负责接收邮件。
- POP3：邮件下载到本地后，服务器上的副本会被删除；
- IMAP：邮件保留在服务器，可以多端同步。
这就解释了为什么有时你用手机收过邮件，在电脑上却看不到（因为 POP3 把服务器副本删了）。
在云盘还没普及之前，FTP（File Transfer Protocol）是常见的文件分享方式。 特点：
- 可以上传和下载文件；
- 安全性较差（明文传输），现在多用更安全的 SFTP（基于 SSH 的文件传输）。
- SSH：远程登录服务器；
- MQTT：轻量级消息传输协议，常见于物联网（IoT）；
- WebSocket：浏览器与服务器之间的全双工通信，常用于实时聊天、在线协作。
- DNS 解析失败 → 无法找到 IP 地址；
- 服务器 HTTP/HTTPS 服务挂了 → 无法返回内容；
- TCP 连接失败 → 数据无法可靠传输。
这也说明了，应用层问题常常和下层协议有关。
- DNS 查询耗时：尤其是没有缓存时；
- HTTPS 握手耗时：加密需要额外的协商步骤；
- 服务器距离远或拥堵：导致响应延迟。
因为邮件收发是分开的：
- SMTP 负责发；
- IMAP/POP3 负责收。 不同服务商的配置不同，所以客户端必须指定清楚。
-
图 4.1：HTTP vs HTTPS 对比图
- 左边：HTTP（明文，容易被窃听）；
- 右边：HTTPS（加密，安全传输）。
HTTP (明文传输):
浏览器 服务器
| |
| -- 请求 (用户名/密码未加密) -----------> |
| |
| <-- 响应 (网页内容未加密) ---------------- |
| |
v v
数据在传输过程中可能被窃听或篡改
HTTPS (加密传输):
浏览器 服务器
| |
| -- 加密请求 (握手/交换密钥) ------------> |
| |
| <-- 服务器证书/密钥确认 ------------------ |
| |
| -- 加密数据 (用户名/密码加密) -----------> |
| |
| <-- 加密响应 (网页内容加密) -------------- |
| |
v v
数据在传输过程中即使被截获也无法轻易读取
-
图 4.2：DNS 查询过程
- 用户输入域名 → DNS 服务器 → 返回 IP → 用户访问目标网站。
用户输入: www.baidu.com
|
v
DNS 查询
|
v
DNS 服务器返回 IP 地址
|
v
220.181.38.148
|
v
访问百度服务器
-
图 4.3：电子邮件收发流程
- 客户端 → SMTP → 邮件服务器 → POP3/IMAP → 客户端。
发送邮件:
客户端 --SMTP--> 邮件服务器
接收邮件:
客户端 <--POP3/IMAP-- 邮件服务器
在本章中，我们学习了：
- HTTP/HTTPS：浏览网页的核心协议，HTTPS 提供了安全性；
- DNS：域名与 IP 之间的“翻译官”；
- SMTP/POP3/IMAP：负责邮件的发送与接收；
- FTP/SSH/WebSocket：不同场景下的常见协议；
- 应用层协议直接影响用户体验，是我们日常最能感受到的网络部分。
到此，网络分层模型的主要层次（链路层、网络层、传输层、应用层）我们已经依次讲解完毕。 下一章，我们将进入 第五章：网络安全与防护 —— 如何保证数据不被窃取和篡改。
设想几个日常场景：
- 你在校园网里登录网银，输入了银行卡号和密码；
- 你在咖啡店的 Wi-Fi 上，准备提交一份实习申请表格；
- 你在登录某个购物网站时，突然提示账号异常。
如果没有安全机制，你的账号密码、聊天记录、甚至银行卡信息都可能被恶意窃取。网络安全的核心目标是：
- 机密性：数据不能被未授权的人看到；
- 完整性：数据不能被篡改；
- 可用性：服务能稳定提供，不轻易被攻击中断。
在未加密的通信中，黑客只需监听网络通道，就能看到明文数据。
- 窃听：被动获取信息。
- 中间人攻击（MITM）：黑客伪装成中间节点，篡改或冒充双方通信。
插图 5.1：用户 → 中间人（冒充服务器）→ 真实服务器。
攻击者拦截数据后，修改其中的内容再转发。比如：
- 网页下载链接被篡改为木马程序；
- 转账金额被篡改。
- 钓鱼网站（伪造成银行、购物网站）；
- 伪造邮件（冒充老师/公司 HR）。
这类攻击主要利用用户的信任漏洞。
攻击者向目标服务器发送海量请求，使其资源耗尽，导致正常用户无法访问。 大型网站经常会面临 DDoS 攻击。
- 对称加密：加密和解密用同一个密钥，速度快，但密钥分发困难。
- 非对称加密：使用公钥和私钥，适合建立安全连接。
- 混合加密：HTTPS 的常见做法，先用非对称加密交换对称密钥，再用对称加密传输数据。
插图 5.2：客户端用服务器公钥加密 → 服务器用私钥解密。
为防止中间人伪造身份，HTTPS 采用 数字证书 来证明服务器的真实性。
- 证书由权威机构（CA）颁发；
- 浏览器会校验证书是否合法；
- 如果证书无效，用户会看到“此网站不安全”的警告。
常见算法：MD5、SHA-256。 原理：对数据进行计算，得到一个固定长度的摘要；如果数据被篡改，摘要就会不同。
- 下载软件时，经常会看到“校验码”，就是为了防止文件被替换。
- 防火墙：像一堵墙，过滤掉可疑的访问。
- IDS/IPS（入侵检测/防御系统）：监控流量，发现异常行为。
技术再强大，也无法弥补用户的不小心：
- 不随便点来历不明的链接；
- 不在公共 Wi-Fi 上登录敏感账号；
- 开启两步验证；
- 定期更新软件和补丁。
说明该网站可能：
- 使用了过期证书；
- 证书不是正规机构签发的；
- 或者有人试图冒充网站。 用户在这种情况下继续访问，存在信息泄露的风险。
验证码（CAPTCHA）不是为了折磨用户，而是为了防止自动化攻击程序（如刷票、暴力破解）。
因为攻击者可能替换掉安装包。如果校验码一致，说明文件未被篡改。
- 图 5.1：中间人攻击示意图（用户以为在和服务器通信，其实中间人伪装成服务器）。
正常通信 (用户直接连接服务器):
用户 <---> 服务器
中间人攻击 (攻击者插入中间):
用户 <---> 攻击者 <---> 服务器
(用户以为直接连接服务器，实际与攻击者通信)
- 图 5.2：非对称加密过程（客户端用公钥加密 → 服务器用私钥解密）。
客户端 服务器
| |
| <-- 分发公钥 ---------- | 服务器将公钥分发给客户端
| |
| -- 用公钥加密数据 ----> | 客户端用服务器公钥加密数据
| |
| -- 发送加密数据 ------> | 传输加密数据
| |
| <-- 服务器用私钥解密 -- | 服务器使用私钥解密数据
| |
v v
只有拥有私钥的服务器能解密
- 图 5.3：HTTPS 建立连接流程（浏览器验证证书 → 交换密钥 → 加密通信）。
客户端(浏览器) 服务器
| |
| ---- Client Hello ------> | 1. 客户端问候，提出加密方案
| |
| <--- Server Hello ------- | 2. 服务器回应，确认加密方案
| |
| <--- 证书(含公钥) -------- | 3. 服务器发送数字证书
| |
| -- 验证证书有效性 -------- | 4. 客户端验证服务器证书
| |
| -- 生成会话密钥 --------> | 5. 客户端生成对称密钥并加密发送
| |
| -- 加密数据交换 --------> | 6. 双方使用对称密钥加密通信
| <----- 加密数据 -------- |
| |
v v
安全的HTTPS加密通信建立
在本章中，我们了解了：
- 网络安全的三个核心目标：机密性、完整性、可用性；
- 常见攻击方式：窃听、中间人、数据篡改、身份伪造、拒绝服务；
- 防护手段：加密、数字证书、完整性校验、防火墙，以及用户安全意识。
安全不是网络的附加功能，而是网络设计中不可或缺的一部分。 只有在确保安全的前提下，网络服务才能真正可靠地运行。
在下一章（第六章），我们将走出“概念层面”，看看网络在前后端开发中是如何实际被使用的，并结合常见开发问题来讲解。
无论是前端还是后端开发，几乎所有应用都离不开网络：
- 前端：浏览器要向服务器请求数据（Ajax、Fetch、Axios）。
- 后端：处理请求、与数据库交互、再把结果返回前端。
- 移动端/桌面端：也通过 HTTP/HTTPS 调用后端接口。
如果不了解基本的网络概念，开发过程中就会遇到各种“玄学问题”：
- 前端明明写了请求，为什么收不到数据？
- 后端明明返回了结果，为什么前端报错？
- 为什么同一个 API 在本地好好的，上线后就变慢甚至报错？
这些问题的答案，大多藏在网络协议的细节里。
前端与后端最常见的交互方式就是 HTTP 请求。一个完整的 HTTP 请求包含：
- 请求行（GET/POST + URL）；
- 请求头（Headers，比如
Content-Type）； - 请求体（Body，用于传输数据）。
服务器返回响应：
- 状态码（200 表示成功，404 表示未找到，500 表示服务器错误）；
- 响应头（响应类型、长度、缓存策略等）；
- 响应体（实际数据，如 JSON、HTML）。
插图 6.1：浏览器请求 API → 服务器响应 JSON。
开发中常见错误：CORS（跨域资源共享）。
- 浏览器安全策略规定，前端只能访问与自己同源的资源；
- 解决办法：后端在响应头中添加
Access-Control-Allow-Origin，明确允许哪些源访问。
在聊天室、股票行情、在线协作等场景，HTTP 不够灵活（它是请求-响应模式）。 WebSocket 可以让浏览器与服务器保持长连接，实现实时消息推送。
当并发量很大时，如果每个请求都重新建立 TCP 连接，代价过高。 后端通常会使用 连接池，重复利用已有的连接，提高性能。
当用户量上升时，单个服务器无法承受压力。 负载均衡器（如 Nginx、LVS）会把请求分发到多台服务器，保证系统稳定。
- 502 Bad Gateway：通常是代理服务器和后端服务通信失败；
- 504 Gateway Timeout：请求超时，可能是后端处理过慢；
- 连接数过多：可能是 TCP 连接未及时释放，或数据库连接池不足。
可能原因：
- 线上环境开启了 HTTPS，而本地是 HTTP；
- 线上域名不同，触发了跨域问题；
- 线上服务器有防火墙策略，阻止了某些请求。
可能原因：
- DNS 解析慢；
- TCP 三次握手/SSL 握手耗时；
- 服务器压力大；
- 数据库查询慢。
可能原因：
- 前端少写了
Content-Type: application/json； - 参数被 URL 编码丢失；
- 请求方法写错（本应 POST 却写成 GET）。
- 图 6.1：前端与后端交互过程（浏览器发起请求 → API 网关 → 应用服务器 → 数据库 → 返回响应）。
前端(浏览器) 后端服务
| |
| -- HTTP请求 --------> | 1. 浏览器发起API请求
| | (如: GET /api/users)
| |
| | +--------------+
| | | API网关 |
| | +--------------+
| | |
| | +--------------+
| | | 应用服务器 |
| | +--------------+
| | |
| | +--------------+
| | | 数据库 |
| | +--------------+
| |
| <-- 响应数据 -------- | 2. 服务处理后返回JSON数据
| | (如: {"users": [...]})
v v
显示页面内容 完成数据处理
- 图 6.2：负载均衡示意图（多台服务器共同处理请求）。
客户端请求
|
+--------------+
| 负载均衡器 |
+--------------+
|
+-------+-------+-------+
| | | |
+-------+ +-------+ +-------+
| 服 1 | | 服 2 | | 服 3 |
+-------+ +-------+ +-------+
|应用 | |应用 | |应用 |
|服务 | |服务 | |服务 |
+-------+ +-------+ +-------+
| | |
v v v
+-------+ +-------+ +-------+
| 数 1 | | 数 2 | | 数 3 |
+-------+ +-------+ +-------+
- 图 6.3：WebSocket 与 HTTP 对比（HTTP：一次请求一次响应；WebSocket：双向实时通信）。
HTTP 请求-响应模式:
客户端 服务器
| |
| -- 请求 --------> | #1 请求
| <-- 响应 -------- | #1 响应
| |
| -- 请求 --------> | #2 请求
| <-- 响应 -------- | #2 响应
| |
v v
每次通信都需要建立新连接
WebSocket 持久连接模式:
客户端 服务器
| |
| -- 握手 --------> | 建立WebSocket连接
| <-- 确认 -------- |
| |
| -- 数据 --------> | 客户端发送数据
| <-- 数据 -------- | 服务器推送数据
| <-- 数据 -------- | 服务器主动推送
| -- 数据 --------> | 客户端发送数据
| |
v v
连接建立后可双向实时通信
在本章中，我们站在开发者的角度，理解了网络在实际项目中的作用：
- 前端常见问题：HTTP 请求、跨域、实时通信；
- 后端常见问题：连接池、负载均衡、错误排查；
- 前后端协作常见问题：环境差异、延迟过高、参数传递错误。
网络协议并不是书本上的抽象知识，而是开发过程中绕不开的必备技能。 理解它们，能帮助我们快速定位问题、优化性能、提升系统的可靠性。