计算机网络基础(二) --- TCP/IP网络结构(应用层)

引言:

当下国际上所采用的 TCP/IP网络结构基于全球网络互联标准(OSI)而来, 是实际采用的通用网络模型, 通过此系列文章熟悉该结构各层面的基本内容以及实战案例, 我所参考的文献: 第七版 <<计算机网络 --- 自顶向下方法>> -- (James F.Kurose / Keith W.Ross) 本系列文章的结构与本书编写思路基本相同, 在学习基础理论时可以翻看参考.

应用层:

1. 应用层协议原理

  • 核心思想: 应用层协议定义了运行在不同主机上的应用程序进程之间通信的规则
复制代码
### 1.1 谁是主角?

* 1. 不是主机本身,而是运行在主机上的应用程序进程在通信 :比如,你的浏览器进程(客户端)和某个网站的Web服务器进程(服务器)在对话;你的邮件客户端进程和邮件服务器进程在对话。
* 2. **应用层协议就是这些进程之间对话的语言和规则手册, 它规定了:**
  > * a. **消息类型:** 进程可以发送哪些类型的消息?(例如,HTTP中的`GET`请求、`POST`请求、`200 OK`响应)
  > * b. **消息语法(格式):** 消息具体长什么样?各部分代表什么意思?(例如,HTTP请求的第一行是`方法 URL 版本`,后面跟着`头字段: 值`,然后是空行和可选的`消息体`)
  > * c. **消息语义:** 每种类型的消息代表什么意思?收到消息后应该做什么?(例如,服务器收到`GET /index.html HTTP/1.1`意味着客户端请求`index.html`文件,服务器应该查找该文件并返回它或错误信息)
  > * d. **交互时序:**消息发送和响应的顺序是怎样的?
  > * e. **错误处理:** 出现问题时怎么办?(例如,HTTP定义了`404 Not Found`, `500 Internal Server Error`等状态码;DNS定义了特定的错误响应码)
复制代码
### 1.2 依赖的基础设施 - 传输层服务

* 应用层协议本身**不负责** 在网络上实际搬运比特流。它依赖底层的**传输层协议**(主要是TCP或UDP)来完成繁重的数据传输工作。

* **选择哪种传输服务是设计应用层协议的关键决策:**

  * **a. TCP (传输控制协议):**

    > * **连接导向:** 通信前需要建立连接(三次握手)。
    >
    > * **可靠数据传输:** 保证数据不丢失、不重复、按序到达。通过确认、重传、序列号、流量控制、拥塞控制等机制实现。
    >
    > * **面向字节流:** 没有消息边界(应用层需要自己处理"粘包/拆包")。
    >
    > * **典型应用:** Web (HTTP/HTTPS), 电子邮件 (SMTP, POP3, IMAP), 文件传输 (FTP, SFTP), 远程登录 (SSH)。**需要可靠性的场景。**

  * **b** . **UDP (用户数据报协议):**

    > * **无连接:** 无需建立连接,直接发送数据报。
    >
    > * **尽力而为交付:** 不保证数据一定到达、不保证顺序、不保证不重复。没有重传机制。
    >
    > * **面向数据报:** 每个`send`操作对应一个完整的数据报,接收方一次`recv`收到一个完整数据报(有明确边界)。
    >
    > * **低开销、低延迟:** 没有连接管理、可靠性保证的开销。
    >
    > * **支持广播/组播:** 可以向多个接收者同时发送。
    >
    > * **典型应用:** DNS查询, 实时音视频通话 (VoIP, WebRTC), 在线游戏, 简单网络管理 (SNMP), 动态主机配置 (DHCP)。**能容忍少量丢包、对延迟极度敏感、或需要广播/组播的场景**
复制代码
### 1.3 架构模式

* 应用层进程协作主要有两种经典模式:
*

  #### **1.3.1 客户端-服务器 (Client-Server, CS):**

  > * **a. 角色清晰:**
  >   * **服务器 (Server):** 长期运行,拥有固定的、众所周知的IP地址和端口号。被动等待来自客户端的连接请求。提供核心服务(如Web页面、邮件存储转发、文件存储)。
  >   * **客户端 (Client):** 可以是间歇性运行的。主动发起与服务器的通信。通常使用动态分配的临时端口。不直接与其他客户端通信。
  >
  > * **b. 优点:** 管理集中,安全性相对可控,易于部署和维护。
  >
  > * **c. 缺点:** 服务器是性能和可靠性的瓶颈(单点故障),扩展成本高(需要升级服务器)。
  >
  > * **d. 例子:** Web浏览, 电子邮件收发, 文件下载(FTP)。

*

  #### **1.3.2 对等网络 (Peer-to-Peer, P2P):**

  > * **a.** **角色平等:** 没有永久性的、专门的服务器。参与通信的主机(称为`对等方`或`Peer`)既是客户端(请求服务)又是服务器(提供服务)。
  >
  > * **b. 自组织性:** Peers之间直接通信。新Peer加入需要某种机制(如联系一个引导节点或查询分布式数据库)来发现其他Peer。
  >
  > * **c. 优点:** 高度可扩展**:** 用户(Peer)越多,整个系统的资源(带宽、存储、计算)就越多,服务能力越强。抗单点故障: 没有中心服务器,系统健壮性更高。
  >
  > * **d. 缺点:** 管理复杂(安全性、资源协调、Peer的加入/离开/不可靠性)。ISP友好性(可能产生大量跨ISP流量)。版权合规性挑战。
  >
  > * **e. 例子:** 文件共享 (BitTorrent), 区块链网络 (比特币, 以太坊), 某些即时通讯和VoIP应用的底层传输 (如早期Skype)。
复制代码
### 1.4 通信端点寻址

> * **需求:**为了让运行在不同主机上的两个进程能够通信,需要一种方法来唯一标识通信的端点。
>
> * **解决方案:套接字接口 (Socket Interface)**
>
>   * 这是操作系统提供给应用程序进行网络编程的API(应用程序编程接口)。进程通过创建套接字 **(Socket)** 来使用网络通信能力。
>
>   * **套接字地址 = IP地址 + 端口号**
>
>     * **a.** **IP地址:** 标识目标主机(或源主机)。
>
>     * **b** . **端口号 (Port Number):** 一个16位的数字(0-65535),标识主机上运行的特定应用程序进程。
>
>     * **c. 组合 (IP:Port):** 唯一标识了互联网上某个主机上的某个进程。例如,`203.0.113.5:80` 表示IP为`203.0.113.5`的主机上监听Web服务(通常端口80)的进程;`198.51.100.2:49152` 表示IP为`198.51.100.2`的主机上某个临时客户端进程。
>
>   * 注意: 应用层协议通常约定好服务器监听的知名端口号 (Well-Known Ports, 0-1023),方便客户端连接(如HTTP:80, HTTPS:443, SMTP:25, DNS:53)。客户端端口号通常由操作系统临时分配(动态端口,49152-65535)。

2. Web 和 HTTP

复制代码
### 2.1 Web 的核心要素

* **核心概念:Web 是一个基于超文本的、全球性的信息空间。**
*

  #### **2.1.1 超文本 (Hypertext):**

  > * a**.**包含指向其他文本(或资源)链接的文本。
  > * b. HTML (HyperText Markup Language): 用于构建和链接 Web 页面的标准标记语言。`<a href="...">` 标签是超链接的核心。
*

  #### **2.1.2 资源 (Resources):**

  *
    > Web 上可被标识和访问的任何内容:HTML 文件、CSS 样式表、JavaScript 代码、图片、视频、音频、PDF 文档等。
*

  #### **2.1.3 统一资源定位符 (URL - Uniform Resource Locator):**

  > * Web 上资源的**唯一地址** 。格式:`<协议>://<主机名>[:端口]/<路径>[?查询参数][#片段标识符]`
  >
  > * 例如:`https://www.example.com:443/products/index.html?category=books#chapter2`
  >
  >   * `https://`:协议(HTTP Secure)
  >
  >   * `www.example.com`:主机名(域名)
  >
  >   * `:443 `端口(HTTPS 默认端口,通常省略)
  >
  >   * `/products/index.html`:资源在服务器上的路径
  >
  >   * `?category=books`:查询参数(传递给服务器的额外信息)
  >
  >   * `#chapter2`:片段标识符(指向页面内特定位置)

* **4. Web 浏览器 (Browser):**

  *
    > 客户端软件,负责:
    > * a. 向服务器发送 HTTP 请求。
    >
    > * b. 接收 HTTP 响应。
    >
    > * c. 解析和渲染 HTML/CSS。
    >
    > * d. 执行 JavaScript。
    >
    > * e. 为用户提供交互界面。

* **5** . **Web 服务器 (Server):**

  > * 存储 Web 资源(HTML文件、图片等)的软件/硬件。
  >
  > * 监听特定端口(HTTP 默认 80, HTTPS 默认 443)。
  >
  > * 接收客户端(浏览器)的 HTTP 请求。
  >
  > * 处理请求(查找资源、执行业务逻辑)。
  >
  > * 向客户端发送 HTTP 响应(包含请求的资源或状态信息)。
复制代码
### 2.2 HTTP:Web 的通信语言

* HTTP 定义了浏览器和服务器之间**请求(Request)** 和 **响应(Response)** 的格式与规则。
*

  #### 2.2.1 **基本特性:**

  > * a. **应用层协议:** 运行在 TCP/IP 之上(通常使用 TCP 保证可靠性)
  > * b. **请求/响应模型:** 客户端(浏览器)发起请求,服务器返回响应。服务器不会主动向客户端推送数据(HTTP/2 和 WebSocket 改变了这点)
  > * c. **无状态 (Stateless):** 服务器默认不保留之前请求的任何信息。 每个请求都被视为独立的。这是为了简化服务器设计,提高可扩展性(服务器崩溃后恢复容易)。Cookie/Session 等技术用于克服无状态性,实现状态管理(如用户登录)。
  > * d. **可扩展:** 通过自定义的头部字段(Headers)可以添加新功能。
  > * e. **支持中介:** HTTP 请求/响应可以经过代理服务器、缓存服务器(CDN 边缘节点)等中介。
*

  #### **2.2.2 HTTP 消息结构:**

  > * **a. HTTP 请求消息:**
  > *
  >
  >   ```html
  >   GET /index.html HTTP/1.1             // 请求行:方法 + URL路径 + HTTP版本
  >   Host: www.example.com                 // 必需的头,指定主机名(虚拟主机支持)
  >   User-Agent: Mozilla/5.0...           // 客户端标识(浏览器类型)
  >   Accept: text/html,application/xhtml+xml // 客户端可接受的响应类型
  >   Accept-Language: en-US                // 客户端接受的语言
  >   Connection: keep-alive                // 请求使用持久连接
  >   (空行)                                // 头结束标志
  >   (可选的请求体 - GET 通常没有,POST 有)  // 例如表单数据、上传文件内容
  >   ```
  >
  > * **b. 请求方法 (Method):** 定义客户端希望服务器对资源执行的操作。
  >   * `GET`:请求一个资源(获取数据)。**最常用。**
  >
  >   * `POST`:提交数据到服务器(创建资源或触发处理)。**最常用。**
  >
  >   * `HEAD`:只请求资源的头部信息(用于检查资源是否存在、获取元数据)。
  >
  >   * `PUT`:上传资源到指定位置(完全替换)。
  >
  >   * `DELETE`:删除指定资源。
  >
  >   * `PATCH`:对资源进行部分修改。
  >
  >   * `OPTIONS`:获取服务器支持的通信选项(CORS 预检请求)。
  >
  > * **c. HTTP 响应消息:**
  > *
  >
  >   ```html
  >   HTTP/1.1 200 OK                       // 状态行:HTTP版本 + 状态码 + 状态短语
  >   Date: Mon, 27 Mar 2023 12:28:53 GMT   // 响应生成时间
  >   Server: Apache/2.4.1                  // 服务器软件信息
  >   Last-Modified: Wed, 22 Mar 2023...    // 资源最后修改时间(用于缓存)
  >   Content-Length: 1234                  // 响应体长度(字节)
  >   Content-Type: text/html; charset=UTF-8 // 响应体类型(MIME类型)和编码
  >   Set-Cookie: sessionid=1234; Path=/    // 设置Cookie(状态管理关键!)
  >   (空行)                                // 头结束标志
  >   <!DOCTYPE html>                       // 响应体(Body)
  >   <html>                                // 请求的实际资源内容(HTML、图片数据等)
  >   ...                                   //
  >   </html>                               //
  >   ```
  >
  >   **​​​​**
  >   * **1.** **状态码 (Status Code):** 3 位数字,告知请求结果。关键分类:
  >     * `1xx`:信息性状态码(很少见)。
  >
  >     * `2xx`:**成功** 。`200 OK`(成功获取资源)、`201 Created`(资源创建成功)、`204 No Content`(成功但无返回内容)。
  >
  >     * `3xx`:**重定向** 。需要客户端进一步操作。`301 Moved Permanently`(永久重定向)、`302 Found`(临时重定向)、`304 Not Modified`(资源未修改,使用缓存)。
  >
  >     * `4xx`:**客户端错误** 。`400 Bad Request`(请求语法错误)、`401 Unauthorized`(需要认证)、`403 Forbidden`(无权限)、`404 Not Found`(资源不存在)。**最常见错误。**
  >
  >     * `5xx`:**服务器错误** 。`500 Internal Server Error`(服务器内部错误)、`502 Bad Gateway`(网关错误)、`503 Service Unavailable`(服务不可用)。
  >
  >   * **2. 状态短语:** 对状态码的简短文字描述(如 `OK`, `Not Found`)。
  >
  >   * **3** . **响应头 (Headers):** 提供关于响应的元信息(服务器类型、内容类型、内容长度、缓存指令、Cookie、安全策略等)
  >
  >   * **4.** **响应体 (Body):** 包含请求的实际资源内容(HTML、JSON、图片数据等)。对于 `HEAD` 请求或某些状态码(如 `204`、`304`),响应体为空。

*

  #### **2.2.3 Cookie:克服无状态性的关键技术**

  > * **问题:** HTTP 无状态,但很多应用(如购物车、登录)需要记住用户。
  >
  > * **解决方案:Cookie**
  >
  >   * **服务器发送:** 在响应头中包含 `Set-Cookie: name=value; [attributes]`。
  >
  >     * 属性:`Expires`/`Max-Age`(有效期)、`Domain`(作用域)、`Path`(路径)、`Secure`(仅HTTPS发送)、`HttpOnly`(JS脚本无法访问,防XSS窃取)。
  >
  >   * **客户端存储:** 浏览器将 Cookie(名称、值、属性)存储在本地。
  >
  >   * **后续请求携带:** 浏览器在后续对该域和路径的请求头中自动添加 `Cookie: name=value; name2=value2`。
  >
  >   * **作用:** 服务器通过读取请求中的 Cookie,就能识别出用户或会话状态。常用于会话管理(Session ID)、个性化设置、追踪分析。

*

  #### **2.2.4** **连接管理:性能的关键**

  > * **a.** **早期 HTTP/1.0:非持久连接 (Non-persistent)**
  >   * 每个请求/响应对都需要建立一个新的 TCP 连接(三次握手),传输完成后立即关闭。
  >
  >   * **缺点:** 建立/关闭连接开销巨大(延迟、CPU/内存消耗),严重限制页面加载速度(一个页面包含多个资源)。
  >
  > * **b.** **HTTP/1.1:持久连接 (Persistent Connection / Keep-Alive) - 默认**
  >   * 一个 TCP 连接可以用于发送/接收多个 HTTP 请求/响应。
  >
  >   * 通过 `Connection: keep-alive` 头(HTTP/1.1 默认开启)。
  >
  >   * **优点:** 显著减少了 TCP 连接建立/关闭的开销,提高了页面加载效率。
  >
  >   * **问题:队头阻塞 (Head-of-Line Blocking - HOLB):** 在同一个 TCP 连接上,请求必须按顺序发送和接收响应。如果第一个请求处理很慢,会阻塞后面所有请求(即使它们资源已准备好)。
  >
  > * **c.** **HTTP/2:多路复用 (Multiplexing)**
  >   * 在**一个** TCP 连接上,**同时**传输多个请求和响应消息(二进制分帧)。
  >
  >   * 请求和响应被分解成更小的**帧 (Frames)** ,打上**流 (Stream) ID** 标签。
  >
  >   * 不同流的帧可以交错发送和组装。
  >
  >   * **优点:** 彻底解决了 HTTP/1.1 的队头阻塞问题,极大提升并发效率和连接利用率。还支持头部压缩(HPACK)、服务器推送(Server Push - 服务器主动推送资源给客户端缓存)等优化。
  >
  > * **d.** **HTTP/3:基于 QUIC (Quick UDP Internet Connections)**
  >   * 将传输层协议从 TCP 换成了基于 UDP 的 **QUIC**。
  >
  >   * **核心优势:**
  >
  >     * **解决 TCP 队头阻塞:** QUIC 在应用层实现了自己的可靠传输和流多路复用,即使单个流的数据包丢失,也不会阻塞其他流的数据传输(TCP 是在传输层阻塞整个连接)。
  >
  >     * **更快的连接建立:** 通常实现 **0-RTT** 或 **1-RTT** 连接建立(尤其对之前连接过的服务器),显著降低初始连接延迟(HTTPS 的 TCP+TLS 握手通常需要 1-3 RTT)。
  >
  >     * **连接迁移:** 当客户端网络切换(如 WiFi 切 4G)时,由于 QUIC 连接使用 Connection ID 而非 IP+Port+协议四元组标识,连接可以无缝迁移而不断开。
  >
  >     * **内置加密:** QUIC 默认强制加密(TLS 1.3),安全性更高。
  >
  >   * **现状:** 正在被广泛部署(Cloudflare, Google, Facebook 等),是未来发展方向。浏览器和服务器需支持。

*

  #### **2.2.5** **HTTPS:安全的 HTTP**

  > * **HTTPS 在 HTTP 之下增加了一个 SSL/TLS 加密层:**
  >   * **加密 (Encryption):** 传输内容(请求和响应体)被加密,防止窃听。
  >   * **身份认证 (Authentication):** 服务器(有时也包括客户端)通过数字证书证明其身份,防止冒充(钓鱼网站)。
  >
  >   * **数据完整性 (Integrity):** 防止数据在传输过程中被篡改。
  >
  > * **工作流程(简化):**
  >   * **1** . 客户端发起 HTTPS 请求(连接到服务器 443 端口)。
  >   * **2.** **TLS 握手:**
  >     * 协商加密套件。
  >
  >     * 服务器发送其数字证书(包含公钥)。
  >
  >     * 客户端验证证书有效性(是否可信、域名匹配、未过期)。
  >
  >     * 客户端生成一个会话密钥 (Session Key),用服务器的公钥加密后发送给服务器。
  >
  >     * 服务器用自己的私钥解密得到会话密钥。
  >
  >   * **3.** **关键:** 证书由受信任的**证书颁发机构 (CA)** 签发。浏览器和操作系统内置了信任的 CA 根证书列表

3. Internet中的电子邮件

复制代码
### 3.1 **关键角色与协议**

> * **1.** **邮件用户代理 (MUA):** 你用的邮箱软件/网页(如Outlook, Gmail网页版)。负责写、读、管理邮件。
> * **2** . **邮件传输代理 (MTA):** 邮箱服务商的服务器软件(如Postfix)。核心协议:
>   * **SMTP (简单邮件传输协议):** 发送邮件。端口:25 (不推荐), 465 (SMTPS), 587 (STARTTLS)。
>
> * **3.** **邮件访问代理 (MAA):** 收件方邮箱服务器软件(如Dovecot)。核心协议:
>   * **POP3 (邮局协议):**下载邮件到本地设备(默认删除服务器副本)。单设备适用。端口:110, 995 (POP3S)。
>
>   * **IMAP (互联网消息访问协议):** 在服务器管理邮件(阅读、移动、标记)。多设备同步首选。端口:143, 993 (IMAPS)。
>
> * **4.** **IMAP vs POP3 关键区别:**
>   * ![](https://i-blog.csdnimg.cn/direct/8977e24f3a5445bc958d387c1879ee76.png)
复制代码
### 3.2 **邮件旅程(简化)**

> * a. **发件 (Alice):** MUA → SMTP → Alice的MSA/MTA (如Gmail服务器)。
> * b. **传输:** Alice的MTA 查询DNS MX记录 → 通过 SMTP 路由 → Bob的MTA (如公司邮件服务器)。
> * c. **投递:** Bob的MTA → 存储到Bob的邮箱。
> * d. **收件 (Bob):** Bob的MUA → IMAP/POP3 → 从服务器读取/下载邮件。
复制代码
### 3.3 **邮件格式**

> * **信封 (Envelope):** SMTP传输用(发件人 `MAIL FROM`,收件人 `RCPT TO`)。用户不可见。
> * **内容 (Message):** 用户可见部分:
>
>   * **头部 (Headers):** `From:`, `To:`, `Subject:`, `Date:`, `Content-Type:` (类型)。
>
>   * **正文 (Body):** 文字内容。
>
>   * **附件:** 通过 **MIME** 标准编码嵌入(`Content-Type` 标识类型如 `image/jpeg`)
复制代码
### 3.4 **重要补充**

> * **安全必备:** 始终使用**加密端口** (465, 587, 993, 995) 保护账号和内容。
> * **垃圾邮件防御:** 依赖 SPF, DKIM, DMARC 认证及内容过滤。
>
> * **现代选择:** **IMAP** 是多设备用户标准方案;**Webmail** (如Gmail) 后端仍使用标准协议。
  • 总结:

    • 1. 发邮件用 SMTP(端口465/587)。

    • 2. 收邮件用 IMAP (端口993,多设备同步)或 POP3(端口995,单设备下载)。

    • 3. 邮件 = 信封(传输信息) + 内容(头+正文+附件)

    • 4. 强制加密端口! 避免明文传输风险。

    • 5. IMAP 是现代邮箱同步的基石。

4. DNS: 域名到 IP 的翻译

  • 核心:

    • 输入: 人类友好的域名(如 www.example.com

    • 输出: 机器使用的 IP 地址(如 192.0.2.1

    • 为什么需要? IP 地址难记易变,域名稳定易用。

复制代码
### 4.1 **关键设计:分布式与层级化**

* DNS 的强大之处在于它不是由一个中心机构管理的巨型数据库,而是:
  > * 1. **分布式数据库:** 数据分散在全球无数台服务器上。
  > * 2. **树状层级结构 (域名空间):** 像一棵倒挂的树:
  >   * **顶级域 (TLD - Top-Level Domain):**
  >
  >     * **通用顶级域 (gTLD):** `.com`, `.org`, `.net`, `.edu`, `.gov` 等。
  >
  >     * **国家代码顶级域 (ccTLD):** `.cn` (中国), `.uk` (英国), `.jp` (日本) 等。
  >
  >     * **新顶级域:** `.app`, `.blog`, `.io` 等。
  >
  >     * **职责:** 管理其下注册的二级域名(如 `.com` TLD 服务器知道 `example.com` 的权威服务器在哪)。
  >
  >   * **二级域:** 你在注册商处购买的域名部分(如 `example` in `example.com`)。你是这个域名的拥有者。
  >
  >   * **子域:** 域名拥有者在其二级域下自行创建的分支(如 `www.example.com`, `mail.example.com`, `blog.example.com`)。`www` 通常是一个子域。
复制代码
### 4.2 **核心角色:谁参与了 DNS 查询?**

* 1. **DNS 解析器:**

  > * **你的"代问官"。** 通常由你的 ISP (网络运营商)、公司网络或公共 DNS 服务商提供 (如 `8.8.8.8` Google, `1.1.1.1` Cloudflare)。
  >
  > * **任务:**
  >
  >   * 接收你设备 (电脑/手机) 的查询请求。
  >
  >   * 代替你的设备,向层级中的各级 DNS 服务器发起查询,直到找到答案。
  >
  >   * 将最终结果 (IP 地址) 返回给你的设备。
  >
  >   * 缓存查询结果一段时间 (根据记录的 TTL),加速后续相同查询。

* 2. **权威 DNS 服务器:**

  > * **域名的"官方发言人"。** 由域名拥有者配置和管理 (或委托给域名注册商/托管商管理)。
  >
  > * **任务:** 存储并提供其所负责域名区域 (`zone`) 的 **最终、官方、准确** 的 DNS 记录。
  >
  > * **如何知道谁是权威?** 上级域名的 `NS` 记录指明了其下域名的权威服务器 (如 `.com` 的 TLD 服务器存有 `example.com` 的 `NS` 记录)。

* 3. **本地缓存:**

  > * 存在于你的**设备操作系统** 和**浏览器** 中,以及**DNS 解析器**中。
  >
  > * **任务:** 临时存储最近查询过的 DNS 结果。
  >
  > * **好处:** 大幅提升后续访问相同域名的速度,减少网络流量和 DNS 服务器负载。
  >
  > * **有效期:** 由 DNS 记录中的 **TTL (Time-To-Live)** 值决定 (单位是秒)。缓存到期后,会重新查询。
复制代码
### 4.3 **DNS 查询过程详解(一次完整的"寻址之旅")**

* 假设你在浏览器输入 `www.example.com` 后按回车:

  > * **1. 本地缓存检查:** 你的设备操作系统先检查自己的 DNS 缓存,看是否有 `www.example.com` 的记录且未过期 (TTL \> 0)。如果有,直接使用,过程结束
  >
  > * **2. 询问解析器:** 如果本地缓存没有(或过期),你的设备向配置的 **DNS 解析器** 发出查询请求:"`www.example.com` 的 IP 地址是多少?"
  >
  > * **3. 解析器的工作(核心):** 解析器开始"代问"之旅。它通常执行 **递归查询**,意味着它会负责到底,直到拿到最终答案或报错。
  >
  >   * a. **解析器缓存检查:** 解析器先查自己的缓存。
  >
  >   * b. **查询根提示服务器:** 无缓存结果。解析器知道根服务器的地址(内置列表)。它向某个根服务器发送 **迭代查询** (根服务器不会递归查询,只给下一步提示): "`.com` 的顶级域 (TLD) 服务器在哪里?"
  >
  >   * c. **根服务器响应:** 根服务器回复: "负责 `.com` 的 TLD 服务器的 IP 地址是 `X.X.X.X` 和 `Y.Y.Y.Y`" (返回 `.com` 域的 `NS` 记录及其对应的 `A`/`AAAA` 记录)。
  >
  >   * d. **查询 TLD 服务器:** 解析器选择其中一个 `.com` TLD 服务器询问: "`example.com` 的权威 DNS 服务器在哪里?"
  >
  >   * e. **TLD 服务器响应:** `.com` TLD 服务器回复: "负责 `example.com` 的权威服务器的域名是 `ns1.example.com` 和 `ns2.example.com`,它们的 IP 地址是 `A.A.A.A` 和 `B.B.B.B`" (返回 `example.com` 的 `NS` 记录及其对应的 `A`/`AAAA` 记录)。
  >
  >   * f. **查询权威服务器:** 解析器选择其中一个 `example.com` 的权威服务器 (如 `ns1.example.com`) 询问: "`www.example.com` 的 IP 地址是多少?"
  >
  >   * g. **权威服务器响应:** 权威服务器 `ns1.example.com` 查找自己的记录:
  >
  >     * 如果 `www` 是主机记录 (`A`/`AAAA`),直接返回 IP。
  >
  >     * 如果 `www` 是别名 (`CNAME`),则返回别名指向的真实域名 (如 `example.com`),解析器可能需要重新发起对这个真实域名的查询(过程类似)。
  >
  >     * 最终返回 `www.example.com` 的 `A` 记录 (IPv4) 或 `AAAA` 记录 (IPv6),例如 `192.0.2.1`。
  >
  > * 4. **解析器返回结果 \& 缓存:**
  >
  >   * 解析器拿到最终 IP 地址后:
  >
  >   * 将结果返回给你的设备
  >
  >   * 将查询结果 (包括各级 `NS` 记录和最终的 `A`/`AAAA` 记录) 按照各自的 TTL 缓存起来
  >
  > * 5. **设备建立连接:** 你的设备拿到 `192.0.2.1`,使用这个 IP 地址与 `www.example.com` 的服务器建立 TCP 连接,开始传输网页数据。
  >
  > * **关键点: 用户设备只与 DNS 解析器交互一次。解析器承担了复杂的、多步骤的查询工作(递归),并向各级服务器发起迭代查询获取线索。**
复制代码
### 4.4 **核心 DNS 记录类型("电话簿"里的条目)**

* 权威服务器存储着域名的各种"记录",常见的有:
*

  |    记录类型     |          全称           |                                作用                                |                                       示例值                                       |
  |-------------|-----------------------|------------------------------------------------------------------|---------------------------------------------------------------------------------|
  | **`A`**     | Address               | **将域名映射到 IPv4 地址。** 最基础记录。                                       | `#www.example.com A 192.0.2.1`                                                  |
  | **`AAAA`**  | Quad A (IPv6 Address) | **将域名映射到 IPv6 地址。**                                              | `#www.example.com AAAA 2001:db8::1`                                             |
  | **`CNAME`** | Canonical Name        | **为域名设置一个别名(指向另一个域名)。** 查询别名最终会解析到目标域名的 IP。 *不能与其它记录类型共存(如 MX)。* | `#www.example.com CNAME example.com` `#mail.example.com CNAME mailprovider.com` |
  | **`MX`**    | Mail Exchange         | **指定接收该域名电子邮件的邮件服务器地址。** *优先级数值小的优先。*                            | `#example.com MX 10 mail1.example.com` `#example.com MX 20 mail2.example.com`   |
  | **`NS`**    | Name Server           | **指定负责该域名(或其子域)的权威 DNS 服务器。**                                    | `#example.com NS ns1.example.com` `#example.com NS ns2.example.com`             |
  | **`TXT`**   | Text                  | **存储任意文本信息。** 常用于验证域名所有权、SPF(防垃圾邮件)、DKIM、DMARC 等。                | `#example.com TXT "v=spf1 #include:_spf.google.com ~all"`                       |
  | **`SOA`**   | Start of Authority    | **存储关于该域名区域(zone)的重要管理信息。** 如主权威服务器、管理员邮箱、序列号(用于同步)、刷新/重试/过期时间等。 | *(通常由服务器管理界面配置)*                                                                |

  **​​​​​**
复制代码
### 4.5 **重要补充与特性**

* **​​​​​​​1. 端口与协议:**
  > * **​​​​​​​** 主要使用 **UDP 协议,端口 53**。UDP 快速高效,适合小查询。
  > * 当响应数据太大(超过 512 字节)或进行区域传输(主从服务器同步数据)时,会使用 **TCP 协议,端口 53**。TCP 可靠,能传输大数据。

* **2. TTL (Time-To-Live):**

  > * 每条 DNS 记录都带有一个 **TTL 值(秒)**。
  >
  > * **​​​​​​​​​​​​​​** 它告诉解析器和各级缓存 **该记录可以保存多久**。
  >
  > * TTL 到期后,缓存会被清除,下次查询需要重新走完整流程。
  >
  > * **作用:** 在变更生效速度(调低 TTL)和减少服务器负载/提升速度(调高 TTL)之间做平衡。

* **3.** **安全与隐私:**

  > * **​​​​​​​** **DNSSEC (DNS Security Extensions):** 为 DNS 记录提供**数字签名** ,防止记录在传输过程中被**篡改** 或**伪造** (如钓鱼网站)。它**不加密** 查询内容本身。**​​​​​​​**
  >
  > * **DoH (DNS over HTTPS) / DoT (DNS over TLS):** 将传统的明文 DNS 查询和响应,封装在加密的 **HTTPS** 或 **TLS** 连接中进行传输。主要解决:
  >
  >   * **隐私保护:** 防止网络窃听者(如 ISP、公共 WiFi 提供者)知道你访问了哪些网站。
  >
  >   * **防篡改/劫持:** 防止中间网络设备(如运营商)劫持或篡改你的 DNS 响应(例如插入广告)。

* 4. **智能解析 (负载均衡/CDN):**

  > * 权威 DNS 服务器可以根据查询**来源 IP 的地理位置** ,返回**不同的 IP 地址**。
  >
  > * **目的:**
  >
  >   * **CDN (内容分发网络):** 让用户访问到离他**最近**的 CDN 边缘节点服务器,加速内容传输。
  >
  >   * **负载均衡:** 将用户请求分配到不同的服务器 IP,避免单台服务器过载。
  >
  >   * **高可用/灾备:** 当某个服务器或数据中心故障时,返回备用 IP。
  • 比喻加深理解: 想象你想给"张三"打电话,但只记得他住"某市某区某街道123号"(域名)。DNS 就像:

    • 先查全国电话总局(根)问"某市"归哪里管(TLD)。

    • 再问"某市"电话局(TLD)问"某区某街道"归哪个分局管(权威 NS)。

    • 最后问"某街道分局"(权威)查到"123号"的电话号码(IP)。

    • 拿到号码(IP)后,你就能直接打给张三(访问网站)了。DNS 解析器就是替你跑完这些步骤的助手。

5. P2P 文件分发

  • 核心思想: 抛弃中心服务器,文件片段直接在用户设备之间(Peers) 相互传输。
复制代码
### 5.1 **关键机制(以 BitTorrent 为代表):**

* **​​​​​​​1. .torrent 文件 / 磁力链接:**
  > * 包含文件元数据:文件名、大小、哈希值(校验完整性)、**Tracker 地址** 或 **DHT 网络信息**。
  >
  > * 是下载的"地图"和"钥匙",**不含实际文件内容**。

* 2. **Tracker / DHT (分布式哈希表):**
  > * **​​​​​​​** **Tracker (可选):** 中心服务器(但只做协调),记录哪些 Peer 拥有文件或片段。新 Peer 向其查询当前活跃 Peer 列表。
  > * **DHT (主流):** 完全去中心化。Peer 自组织成网络,相互查询谁有文件片段。无单点故障。

* 3. **文件分块:**

  > * **​​​​​​​** 大文件被切成固定大小的小**块 (Piece)**。
  >
  > * Peer 可以独立下载和验证每个块(通过哈希值)。

6. 视频流和内容分发网

  • s
  • s
  • s
  • s
  • s
  • s
  • s
  • s
  • s
相关推荐
程序员良辰10 分钟前
Spring与SpringBoot:从手动挡到自动挡的Java开发进化论
java·spring boot·spring
鹦鹉00713 分钟前
SpringAOP实现
java·服务器·前端·spring
练习时长两年半的程序员小胡1 小时前
JVM 性能调优实战:让系统性能 “飞” 起来的核心策略
java·jvm·性能调优·jvm调优
崎岖Qiu1 小时前
【JVM篇11】:分代回收与GC回收范围的分类详解
java·jvm·后端·面试
27669582923 小时前
东方航空 m端 wasm req res分析
java·python·node·wasm·东方航空·东航·东方航空m端
许苑向上3 小时前
Spring Boot 自动装配底层源码实现详解
java·spring boot·后端
喵叔哟4 小时前
31.【.NET8 实战--孢子记账--从单体到微服务--转向微服务】--单体转微服务--财务服务--收支分类
java·微服务·.net
codu4u13144 小时前
Maven中的bom和父依赖
java·linux·maven
呦呦鹿鸣Rzh4 小时前
微服务快速入门
java·微服务·架构
_Rookie._4 小时前
http触发预检请求条件
网络·网络协议·http