1. 网络通信分层模型

1.1. OSI七层模型

由 ISO 组织制定，是法律上的国际标准。它将网络通信划分为非常细致的七层，但在实际商业应用中并未获得完全成功。

  • 应用层 (Application)：为应用程序提供网络服务（如 HTTP, FTP）。

  • 表示层 (Presentation)：处理数据的格式、加密和压缩。

  • 会话层 (Session)：管理主机间的会话连接。

  • 传输层 (Transport)：端到端的可靠/不可靠数据传输（TCP/UDP）。

  • 网络层 (Network)：负责路由选择和逻辑寻址（IP）。

  • 数据链路层 (Data Link)：将数据组装成帧，并在物理层上进行点对点传输。

  • 物理层 (Physical)：定义物理传输介质（电缆、比特流）。

OSI 7-layer model diagram，AI 生成

1.2. TCP/IP四层模型

这是事实上的工业标准。它将 OSI 的应用层、表示层和会话层合并为一层，将底层也进行了简化。

  • 应用层 (Application)：涵盖了所有的应用协议（如 DNS, SMTP, HTTP）。

  • 传输层 (Transport)：负责进程间的通信（TCP, UDP）。

  • 网际层 (Internet)：核心协议是 IP，负责将数据包从源主机发送到目的主机。

  • 网络接口层 (Network Interface)：负责具体的传输介质访问（以太网、WiFi 等）。

2. TCP与UDP

在网络传输层中，TCP（传输控制协议）和 UDP（用户数据报协议）是两个最核心的协议。它们就像两种不同的“物流方式”：TCP 是挂号信/快递，确保安全送达；而 UDP 是普通平信/广播，只管发出，不管对方是否收到。

2.1. TCP

传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。

建立连接（三次握手）：在发送数据前，双方必须先建立连接，确认彼此都有收发能力。

  • 第一次握手：客户端 to 服务端

    • 客户端发送连接请求报文，标志位 SYN = 1，随机产生一个序列号 seq = x。

    • 此时客户端进入 SYN_SENT 状态。

    • 意义：服务端知道客户端有发送能力。

  • 第二次握手：服务端 to 客户端

    • 服务端收到请求，同意连接，发送响应报文：标志位 SYN = 1, ACK = 1。

    • 确认号 ack = x + 1，同时自己也随机产生一个序列号 seq = y。

    • 此时服务端进入 SYN_RCVD 状态。

    • 意义：客户端知道服务端有收发能力，且知道服务端已收到自己的请求。

  • 第三次握手：客户端 to 服务端

    • 客户端收到后，检查 ack 是否正确，发送确认报文：标志位 ACK = 1。

    • 确认号 ack = y + 1，自己的序列号 seq = x + 1。

    • 发送完后，客户端进入 ESTABLISHED 状态，服务端收到后也进入 ESTABLISHED 状态。

    • 意义：服务端知道客户端有接收能力，且知道客户端已收到自己的响应。

断开连接（四次挥手）：由于 TCP 是全双工的（双方都可以同时收发），所以每个方向的连接都必须单独关闭。

  • 第一次挥手：客户端 to 服务端

    • 客户端发送释放连接报文，标志位 FIN = 1，序列号 seq = u。

    • 客户端进入 FIN_WAIT_1 状态。表示客户端没有数据要发了。

  • 第二次挥手：服务端 to 客户端

    • 服务端收到后回复 ACK = 1，确认号 ack = u + 1。

    • 服务端进入 CLOSE_WAIT 状态。

    • 此时 TCP 连接处于半关闭状态：客户端不发数据了，但如果服务端还有没发完的数据，可以继续发，客户端仍需接收。

  • 第三次挥手：服务端 to 客户端

    • 服务端数据发完了，发送 FIN = 1, ACK = 1，序列号 seq = v。

    • 服务端进入 LAST_ACK 状态。

  • 第四次挥手：客户端 to 服务端

    • 客户端收到后，回复 ACK = 1，确认号 ack = v + 1。

    • 客户端进入 TIME_WAIT 状态，经过 2MSL（最大报文生存时间）后正式关闭。

    • 服务端收到 ACK 后立即进入 CLOSED 状态。

可靠性保证：

  • 确认应答（ACK）：每收到一个包，接收方都要回传一个确认。

  • 超时重传：如果发送方没收到 ACK，会认为丢包了，重新发送。

  • 错误校验：通过校验和发现数据损坏会丢弃并要求重传。

流量控制与拥塞控制：利用“滑动窗口”控制发送速率，防止由于网络拥堵或接收端处理不过来导致崩溃。

有序性：即便数据包由于路径不同到达顺序乱了，TCP 也会根据序列号在接收端重新组装成原始顺序。

2.2. UDP

用户数据报协议是一种无连接的、不可靠的、基于报文的传输层协议。

  • 无连接：发送数据前不需要建立连接，想发就发，直接把数据打包丢给网络。

  • 尽力而为：不保证数据一定到达，不保证顺序，也不负责重传。

  • 头部开销小：TCP 头部通常有 20 字节，而 UDP 头部只有 8 字节，处理速度非常快。

  • 支持广播和多播：可以一对多传输。

2.3. 对比

特性

TCP

UDP

连接状态

面向连接（需三次握手）

无连接

可靠性

可靠（保证不丢包、不乱序）

不可靠（可能丢包、乱序）

传输方式

字节流（像自来水，无边界）

报文（像包裹，有明确边界）

传输速度

较慢（由于复杂的确认机制）

极快（实时性强）

双工性

全双工一对一

支持一对一、一对多（广播/多播）

资源消耗

较大

较小

首部大小

20 ~ 60 字节

固定 8 字节

当对准确性要求高于速度时，必须使用 TCP。

  • Web 浏览 (HTTP/HTTPS)：网页内容不能缺一块。

  • 文件传输 (FTP)：下载的文件不能有一位错误。

  • 邮件 (SMTP/IMAP)：邮件内容必须完整。

  • 数据库连接：确保事务操作的指令准确无误。

当对实时性要求极高，且允许少量丢包时，首选 UDP。

  • 视频会议/直播：偶尔卡一下（丢一帧）比画面延迟 10 秒要好。

  • 在线游戏：瞬时的位置信息需要立刻同步，过时的包丢了也没关系。

  • 语音通话 (VoIP)：短暂的杂音（丢包）比通话中断或严重滞后更能接受。

  • DNS 查询：追求极速响应，如果失败了应用层再重试一次即可。

3. HTTP与HTTPS

3.1. HTTP

超文本传输协议是用于从万维网服务器传输超文本到本地浏览器的传送协议。

  • 无状态 (Stateless)：协议对事务处理没有记忆能力。如果你连续发两次请求，服务器并不知道你是同一个人（通常靠 Cookie/Session 解决）。

  • 明文传输：数据在网络中以字符串形式传输，不经过加密。

    • 风险：中间人（如非法 Wi-Fi 热点）可以轻易截获并读取你的账号密码。

  • 端口：默认使用 80 端口。

  • 连接方式：基于 TCP，每次请求响应都需要经历三次握手（HTTP/1.1 引入了长连接 Keep-Alive 来优化）。

3.2. HTTPS

超文本传输安全协议，它并不是一个全新的协议，而是 HTTP + SSL/TLS。它在 HTTP 的应用层和 TCP 的传输层之间插入了一个安全层。

  • 内容加密：建立一个信息安全通道，保证数据传输的机密性。

  • 身份认证：确认网站的真实性（通过数字证书）。

  • 数据完整性：防止内容被第三方冒充或篡改。

  • 端口：默认使用 443 端口。

HTTPS 能够实现加密，依靠的是对称加密（效率高，用于传数据）和非对称加密（安全，用于传密钥）的结合。

  1. 客户端发起请求：告知服务端自己支持的加密算法版本。

  2. 服务端下发证书：包含服务端的公钥和数字签名。

  3. 客户端验证证书：检查证书是否由权威机构颁发、是否过期。

  4. 传送对称密钥：

    • 客户端生成一个随机数（对称密钥）。

    • 用证书里的公钥加密这个随机数，发给服务端。

  5. 服务端解密：服务端用自己的私钥解密，得到对称密钥。

  6. 开始加密传输：此后双方都用这个对称密钥进行加密通信。

4. DNS

在网络世界里，设备之间通信靠的是 IP 地址（比如 14.215.177.38），但人类更擅长记忆 域名（比如 baidu.com）。DNS 的作用就是把人类可读的域名“翻译”成机器可读的 IP 地址。

4.1. DNS解析

DNS 解析是指从用户输入域名到获取对应 IP 地址的具体过程。这个过程通常在几毫秒到几百毫秒内完成，对用户几乎是透明的。

DNS 并不是一台服务器，而是一个分布式、分层级的系统：

  1. 根域名服务器 (.)：最高层级，知道所有顶级域名服务器（如 .com, .cn）的位置。

  2. 顶级域名服务器 (TLD, 如 .com)：管理该后缀下所有的二级域名。

  3. 权威域名服务器：保存着该域名真正的 IP 地址记录（由域名注册商提供）。

4.2. DNS 解析的具体步骤

当你打开浏览器输入 www.example.com 时，背后发生了以下故事：

  1. 浏览器缓存 & 操作系统缓存：首先检查你自己电脑里有没有记过这个地址（Hosts 文件或之前的访问记录）。

  2. 本地 DNS 服务器 (LDNS)：如果没有，电脑会问你的网络运营商（电信、联通等）的 DNS 服务器：“你知道这个 IP 吗？”

  3. 根域名服务器：本地 DNS 如果也不知道，它会去问“根”：“帮我找找 .com 在哪？”

  4. 顶级域名服务器：根服务器说：“我不知道具体的，但我知道 .com 的管家在哪。”本地 DNS 接着去问 .com 的管家。

  5. 权威域名服务器：.com 的管家说：“example.com 的具体记录在它的权威服务器上，你去那问。”

  6. 获取结果：本地 DNS 拿到最终 IP，存入自己的缓存，并告诉你的浏览器：“找到了，是 93.184.216.34。”

4.3. 常见的 DNS 记录类型

在配置域名或排查网络问题时，你会经常见到这些名词：

  • A 记录 (Address)：最常用，将域名指向一个 IPv4 地址。

  • AAAA 记录：将域名指向一个 IPv6 地址。

  • CNAME (Canonical Name)：别名记录，将一个域名指向另一个域名（常用于 CDN 加速）。

  • MX 记录 (Mail Exchanger)：邮件交换记录，指定该域名的邮件服务器。

  • NS 记录 (Name Server)：指定该域名由哪个 DNS 服务器来解析。

  • TXT 记录：通常用于域名所有权验证（如配置企业邮箱或 SSL 证书）。

5. 浏览器地址栏输入url到显示主页过程

DNS 解析：浏览器发起一个 DNS 请求到 DNS 服务器，将域名解析为服务器的 IP 地址。
TCP 连接：浏览器通过解析得到的 IP 地址与服务器建立 TCP 连接（通常是通过 443 端口进行 SSL 加密的 HTTPS 连接）。这一步涉及到 TCP 的三次握手过程，确保双方都准备好进行数据传输。
发送 HTTP 请求：浏览器构建 HTTP 请求消息，包括请求行（如 GET / HTTP/1.1）、请求头（包含用户代理、接受的内容类型等信息）和请求体（如果有）；将请求发送到服务器。
服务器处理请求：服务器接收到 HTTP 请求后，根据请求的资源路径，经过后端处理（可能包括数据库查询等），生成 HTTP 响应消息；响应消息包括状态行（如 HTTP/1.1 200 OK）、响应头（内容类型、缓存控制等信息）和响应体（请求的资源内容）。
浏览器接收 HTTP 响应：浏览器接收到服务器返回的 HTTP 响应数据，开始解析响应体中的 HTML 内容；然后构建 DOM 树、解析 CSS 和 JavaScript 文件等，最终渲染页面。
断开连接：TCP 四次挥手，连接结束