第2章：应用层 — 知识要点与架构

---

一、全章架构总览

第 2 章以"自顶向下"的视角，从协议栈最顶层出发，系统性地讲解网络应用的设计原理与核心协议。其逻辑链条如下：

2.1 网络应用原理（体系结构、进程通信、运输服务）
    │
    ├──→ 2.2 Web和HTTP
    │       ├── HTTP/1.1（持续/非持续连接、报文格式、cookie、缓存）
    │       └── HTTP/2（成帧、多路复用、服务器推送）、HTTP/3
    │
    ├──→ 2.3 电子邮件
    │       ├── SMTP（邮件传输协议）
    │       ├── 邮件报文格式（RFC 5322）
    │       └── 邮件访问协议（IMAP、HTTP）
    │
    ├──→ 2.4 DNS：因特网的目录服务
    │       ├── 层次化分布式数据库（根/TLD/权威服务器）
    │       ├── DNS缓存
    │       └── DNS记录类型与报文格式
    │
    ├──→ 2.5 P2P文件分发
    │       ├── P2P与客户-服务器的扩展性量化对比
    │       └── BitTorrent协议（追踪器、最稀缺优先、一报还一报）
    │
    ├──→ 2.6 视频流和内容分发网（CDN）
    │       ├── DASH动态适应性流
    │       ├── CDN原理（深入 vs 邀请做客）
    │       └── 案例：Netflix、YouTube
    │
    └──→ 2.7 套接字编程：生成网络应用
            ├── UDP套接字编程
            └── TCP套接字编程

核心洞察：应用层是网络协议栈的最顶层，也是用户感知网络的"窗口"。网络应用的核心是编写运行在不同端系统上、能够通过网络交换报文的程序。关键设计决策包括：选择应用体系结构（客户-服务器 vs P2P）、选择运输层协议（TCP vs UDP）、定义应用层协议（报文类型与语法语义）。HTTP/2引入的成帧机制、CDN对内容分发的革命性影响、DNS作为分布式数据库的精妙设计、BitTorrent的激励机制，均展示了应用层丰富的设计智慧。

---

二、2.1 网络应用原理

2.1 核心内容

研发网络应用程序的核心是编写能够运行在不同端系统上、通过网络彼此通信的程序。重要的根本认识是：应用程序运行在端系统上，网络核心设备（路由器、链路层交换机）不在应用层起作用。这种"将应用软件限制在边缘"的设计促进了大量网络应用的快速研发和部署。

2.1.1 网络应用体系结构

两种主流体系结构：

┌──────────────────────────────────────────────────────────────┐
│                    网络应用体系结构                            │
├────────────────────────────┬─────────────────────────────────┤
│   客户-服务器体系结构        │    P2P体系结构                   │
│   (Client-Server)          │    (Peer-to-Peer)               │
├────────────────────────────┼─────────────────────────────────┤
│ • 总是打开的服务器           │ • 间歇连接的主机对等方直接通信     │
│ • 服务器有固定IP地址        │ • 不依赖专用服务器               │
│ • 客户之间不直接通信         │ • 自扩展性：对等方既是消费者      │
│ • 数据中心提供强大虚拟服务器  │   也是重新分发者                │
│ • 例子：Web、FTP、Telnet、   │ • 成本效率高（无需庞大服务器     │
│   电子邮件                  │   基础设施）                    │
│                            │ • 例子：BitTorrent              │
└────────────────────────────┴─────────────────────────────────┘

关键概念定义：

• 客户-服务器体系结构：有一个总是打开的主机（服务器），服务于来自许多客户主机的请求。客户之间不直接通信。
• P2P体系结构 ：端系统（对等方）之间直接通信，每个对等方请求文件时产生工作负载，但也通过向其他对等方分发文件为系统增加服务能力（自扩展性）。
• 数据中心：托管大量主机的设施，创建强大的虚拟服务器。谷歌有分布于全世界的19个数据中心。

2.1.2 进程通信

关键概念定义：

• 进程 ：运行在端系统中的一个程序。在不同端系统上的进程通过跨越计算机网络交换报文来通信。
• 客户进程：在通信会话场景中，发起通信的进程。
• 服务器进程：在通信会话场景中，等待联系的进程。
• 套接字（socket） ：进程与计算机网络之间的接口，也称为应用编程接口（API）。类比：进程 = 房子，套接字 = 门。
• IP地址：32比特量，唯一标识因特网上的主机（第4章详述）。
• 端口号（port number）：用于标识目的主机中的接收进程（更具体地说，接收套接字）。例如：Web服务器用端口号80，SMTP用端口号25。

进程寻址的两种信息：

1. 主机的地址（IP地址）
2. 目的主机中指定接收进程的标识符（端口号）

2.1.3 可供应用程序使用的运输服务

四个维度的服务分类：

服务维度	含义	相关概念
可靠数据传输	确保由一端发送的数据正确、完全地交付给另一端	容忍丢失的应用（loss-tolerant）：如音频/视频，能承受少量数据丢失
吞吐量	发送进程向接收进程交付比特的速率	带宽敏感的应用 （如因特网电话，需要最低速率）vs 弹性应用（如文件传输、Web，能利用任何可用带宽）
定时	数据交付的时间保证（如每个比特在100ms内到达）	对交互式实时应用（电话、虚拟环境、多方游戏）至关重要
安全性	加密、数据完整性、端点鉴别	TLS在应用层实现，强化TCP的安全性（第8章详述）

2.1.4 因特网提供的运输服务

TCP 服务模型（两个核心服务）：

TCP服务
├── 面向连接的服务
│   ├── 握手（握手阶段提醒双方准备）
│   ├── TCP连接建立（在两个进程的套接字之间）
│   ├── 全双工通信（双方可同时收发）
│   └── 需要拆除连接
│
├── 可靠数据传输服务
│   ├── 无差错交付
│   └── 按序交付所有数据（无丢失、无冗余）
│
└── 拥塞控制机制
    ├── 网络拥塞时抑制发送进程
    └── 公平共享网络带宽

TCP vs UDP 对比：

维度	TCP	UDP
连接	面向连接（握手）	无连接
可靠性	可靠数据传输	不可靠（不保证到达、可能乱序）
拥塞控制	有	无（可用任意速率发送）
适用场景	电子邮件、Web、文件传输	因特网电话（Skype等）
安全增强	TLS可在应用层加强	无内置安全机制
先运行的时延	需要握手	不需要握手

因特网运输协议不提供的服务：吞吐量保证和定时保证。目前的因特网没有提供这些，但时间敏感应用（如VoIP）通过"最佳适应"设计仍然运行得相当好。

流行的因特网应用及其支撑运输协议：

应用	应用层协议	运输协议
电子邮件	SMTP	TCP
远程终端访问	Telnet	TCP
Web	HTTP	TCP
文件传输	FTP	TCP
流式多媒体	HTTP（如YouTube）、DASH	TCP
因特网电话	SIP、RTP或专用（如Skype）	UDP或TCP

TLS（运输层安全）：TCP的加强版本，在应用层实现。提供加密、数据完整性和端点鉴别。发送进程通过TLS套接字发送明文，TLS加密后经过TCP套接字传输，接收方TLS解密后交付给接收进程（第8章详述）。

2.1.5 应用层协议

应用层协议定义：

应用层协议定义了什么？
├── 交换的报文类型（请求报文、响应报文）
├── 各种报文类型的语法（报文字段及其描述方式）
├── 字段的语义（字段中信息的含义）
└── 规则（进程何时、如何发送报文及响应）

关键区分 ：网络应用不等于应用层协议。应用层协议只是网络应用的一部分。例如，Web应用 包括HTML格式标准、Web浏览器、Web服务器和HTTP协议；Netflix包括存储/传输视频的服务器、客户端、DASH协议等。

协议分类：

• 公共域协议：由RFC定义，如HTTP RFC 7230、SMTP RFC 5321
• 专用协议：不公开，如Skype使用的协议

2.1.6 本书涉及的网络应用

本章详细讨论的应用：Web、电子邮件、DNS（目录服务）、流式视频和P2P。DNS不同于其他应用------它不直接与用户打交道，而是为其他应用提供核心的"主机名到IP地址"转换功能。

---

三、2.2 Web和HTTP

3.1 HTTP概述（2.2.1节）

核心内容 ：HTTP（超文本传输协议）是Web的应用层协议，使用TCP作为支撑运输层协议。HTTP是一个无状态协议------服务器不保存关于客户的任何状态信息。

关键概念定义：

• Web页面（文档）：由对象组成的文件。一个对象是一个文件（HTML文件、JPEG图形、JavaScript文件、CSS样式表文件或视频片段），可通过URL寻址。
• HTML基本文件：大部分Web页面包含一个HTML基本文件和几个引用对象。
• URL ：由两部分组成------存放对象的服务器主机名 + 对象的路径名。例如：http://www.someSchool.edu/someDepartment/picture.gif
• Web浏览器：实现HTTP客户端的程序（如Chrome、Firefox）。
• Web服务器：实现HTTP服务器端，存储Web对象，每个对象由URL寻址（如Apache、IIS）。

HTTP协议版本历史：

• HTTP/1.0：20世纪90年代早期 RFC 1945
• HTTP/1.1：长期主流版本 RFC 7230
• HTTP/2：2015年标准化 RFC 7540，2020年超过40%的Top 1000万Web站点支持
• HTTP/3：基于QUIC，2020年处于因特网草案阶段

3.2 非持续连接和持续连接（2.2.2节）

非持续连接 vs 持续连接对比：

┌─────────────────────────────────────────────────────────────┐
│                HTTP连接方式对比                               │
├──────────────────────────────┬──────────────────────────────┤
│   非持续连接                  │   持续连接                    │
│   (Non-persistent)           │   (Persistent)               │
├──────────────────────────────┼──────────────────────────────┤
│ • HTTP/1.0默认               │ • HTTP/1.1默认               │
│ • 每个TCP连接只传输一个对象    │ • 服务器发送响应后保持TCP连接  │
│ • 每对象需要建连→2个RTT时延   │   打开                      │
│ • 服务器负担重（大量TCP缓冲区  │ • 一个完整的Web页面通过单个   │
│   和变量）                   │   TCP连接传输                 │
│                              │ • 支持流水线（不必等待未决    │
│                              │   请求的回答）               │
└──────────────────────────────┴──────────────────────────────┘

非持续连接的步骤（如1个HTML + 10个JPEG）：

1）客户在端口80发起TCP连接到服务器
2）客户经套接字发送HTTP请求报文
3）服务器检索对象，封装进HTTP响应，通过套接字发送
4）服务器通知TCP断开连接
5）客户接收响应，TCP连接关闭
6）对每个JPEG重复步骤1~5（共11个TCP连接）

关键数字：

• RTT（往返时间）：短分组从客户到服务器再返回的时间
• 非持续连接的总响应时间 ≈ 2个RTT + 服务器传输文件时间（三次握手中前两部分占1个RTT，请求/响应占1个RTT）

3.3 HTTP报文格式（2.2.3节）

HTTP请求报文格式：

请求行     ← 方法(GET/POST/HEAD/PUT/DELETE) + URL + HTTP版本
首部行     ← Host、Connection、User-agent、Accept-language等
空行
实体体     ← POST方法中存放表单输入数据

HTTP请求报文实例：

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

HTTP方法：

方法	用途
GET	请求对象，绝大部分请求使用，实体体为空
POST	提交表单数据，实体体包含用户输入
HEAD	类似于GET，但服务器不返回请求对象（用于调试）
PUT	上传对象到Web服务器指定路径
DELETE	删除Web服务器上的对象

HTTP响应报文格式：

状态行     ← HTTP版本 + 状态码 + 状态信息
首部行     ← Connection、Date、Server、Last-Modified、Content-Length、Content-Type等
空行
实体体     ← 所请求的对象本身

HTTP响应报文实例：

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

常见状态码：

状态码	含义
200 OK	请求成功
301 Moved Permanently	对象永久转移，新URL在Location首部
400 Bad Request	服务器不能理解请求
404 Not Found	请求的文档不在服务器上
505 HTTP Version Not Supported	不支持的HTTP版本

3.4 Cookie（2.2.4节）

核心内容 ：HTTP是无状态的，但Web站点通常需要识别用户。cookie允许站点在无状态的HTTP之上建立一个用户会话层。

cookie技术的四个组件：

1. HTTP响应报文中的cookie首部行（Set-cookie:）
2. HTTP请求报文中的cookie首部行（Cookie:）
3. 用户端系统中的cookie文件（浏览器管理）
4. Web站点的后端数据库

cookie工作流程：

用户首次访问 Amazon
    │
    ▼
Amazon服务器生成唯一识别码（如1678）
    │
    ▼
响应报文: Set-cookie: 1678
    │
    ▼
浏览器在cookie文件中记录：amazon.com → 1678
    │
    ▼
后续每个请求报文自动附带: Cookie: 1678
    │
    ▼
服务器根据1678跟踪用户活动、维护购物车、个性化推荐

后继访问：即使过了一周，浏览器仍会在请求中放入Cookie: 1678，Amazon根据历史记录推荐产品。如果用户注册了账户信息（姓名、地址、信用卡），则可实现"一键购物"。

3.5 Web缓存（2.2.5节）

核心内容：Web缓存器（也叫代理服务器）是代表初始Web服务器来满足HTTP请求的网络实体，有自己的磁盘存储且保存最近请求过的对象副本。

Web缓存器工作流程：

浏览器请求对象 http://www.someschool.edu/campus.gif
    │
    ▼
浏览器 → Web缓存器（建立TCP连接，发送HTTP请求）
    │
    ├── 缓存命中 → 直接返回对象副本
    │
    └── 缓存未命中 → 向初始服务器请求 → 收到后本地存储副本 → 返回给客户

身份双面性 ：Web缓存器既是服务器又是客户。接收浏览器请求时是服务器，向初始服务器请求时是客户。

部署Web缓存器的两大原因：

1. 显著减少对客户请求的响应时间（特别是缓存器与客户间有高速连接时）
2. 大幅减少机构接入链路到因特网的通信量（降低费用）

数值例子（缓存效益计算）：

• 条件：100Mbps局域网，15Mbps接入链路，每秒15个请求，对象平均1Mb，因特网时延2s
• 无缓存：接入链路流量强度 = (15×1Mb) / 15Mbps = 1.0 → 时延非常大（分钟级）
• 有缓存（命中率0.4）：流量强度降至0.6 → 平均时延 ≈ 0.4×(0.01s) + 0.6×(2.01s) ≈ 1.2s（甚至比升级到100Mbps链路更好！）

条件GET方法：

• 使用If-modified-since:首部行的GET请求
• 如对象未修改，服务器返回304 Not Modified（不包含对象，节省带宽）
• 缓存器据此验证本地副本是否最新

CDN：CDN公司（如Akamai、Limelight）在因特网上安装许多地理上分散的缓存器，使大量流量本地化。

3.6 HTTP/2（2.2.6节）

核心内容 ：HTTP/2（2015年标准化）的主要目标是减小感知时延 。手段：经单一TCP连接使请求与响应多路复用 、提供请求优先次序 和服务器推 、提供HTTP首部字段的有效压缩。HTTP/2不改变HTTP方法、状态码、URL或首部字段，而是改变数据格式化方法和传输方式。

HTTP/1.1的问题------HOL阻塞：

队首阻塞（Head of Line blocking）示意图：
    
    大视频片段（前面） → [████████████████████]  → 瓶颈链路
    小对象（后面）     → [■■■■■■■■■■■■■■■■]  → 被阻塞！
    
    视频通过瓶颈链路花费很长时间，小对象在后面等待延迟。
    HTTP/1.1的解决方法：打开多个并行TCP连接（通常6条）。

HTTP/2成帧（关键的改进）：

HTTP/2成帧机制：

    大视频片段（1000帧）：[V1][V2][V3][V4]...[V1000]
    小对象1（2帧）：       [O1_1][O1_2]
    小对象2（2帧）：       [O2_1][O2_2]
      ...
    
    交错发送：
    [V1][O1_1][O2_1]...[O8_1][V2][O1_2][O2_2]...[O8_2][V3][V4]... 
    
    结果：仅需18帧就发送完所有小对象！
    无交错：需要1016帧。

HTTP/2核心特性：

特性	说明
成帧（Framing）	将HTTP报文划分为独立的帧，交错发送，在接收端装配。使用二进制编码（更高效、更不容易出错）
多路复用	经单一TCP连接交错发送多个请求和响应的帧
请求优先权	客户为每个报文分配1~256的权重，服务器优先发送高优先权响应的帧
服务器推	服务器可主动推送额外对象（如HTML页引用的图片），无需客户额外请求
首部压缩	有效压缩HTTP首部字段，减少开销

3.7 HTTP/3

核心内容 ：HTTP/3设计在QUIC协议之上运行。QUIC在应用层中UDP之上实现，具有报文复用（交错）、每流流控和低时延连接创建等特征。2020年处于因特网草案阶段。

3.8 HTTP/1.1 vs HTTP/2 vs HTTP/3 对比总表

维度	HTTP/1.1	HTTP/2	HTTP/3
标准化时间	1997年	2015年	草案阶段（2020）
底层协议	TCP	TCP	QUIC（UDP之上）
传输方式	持续连接，可流水线	二进制成帧，多路复用	多路复用（基于QUIC）
HOL阻塞	存在（多用并行TCP缓解）	通过帧交错解决	通过QUIC每流机制解决
首部编码	文本	二进制压缩	继承HTTP/2设计
服务器推送	不支持	支持	支持
连接创建	TCP三次握手	TCP三次握手	QUIC低时延（0-RTT）

---

四、2.3 因特网中的电子邮件

4.1 电子邮件系统架构

三个主要组件：

┌──────────────────────────────────────────────────────────────┐
│                    电子邮件系统架构                            │
├──────────────┬──────────────────┬────────────────────────────┤
│  用户代理     │   邮件服务器       │   SMTP                     │
│  (UA)        │   (Mail Server)   │   (Simple Mail Transfer)   │
├──────────────┼──────────────────┼────────────────────────────┤
│ 阅读、回复、  │ 核心：每个接收方     │ 因特网电子邮件的核心应用     │
│ 转发、保存和  │ 在邮件服务器上有一   │ 层协议                      │
│ 撰写报文      │ 个邮箱（mailbox）  │ 使用TCP可靠数据传输         │
│ Outlook、    │ 管理维护发送给用户   │ 从发送方邮件服务器发送到     │
│ Apple Mail、 │ 的报文             │ 接收方邮件服务器            │
│ Gmail客户端  │ 重试机制：约每30分钟 │ 端口号：25                  │
│              │ 尝试，几天后放弃     │                            │
└──────────────┴──────────────────┴────────────────────────────┘

邮件传输总体流程：

Alice发送 → Bob接收

Alice的用户代理 ──SMTP/HTTP──▶ Alice的邮件服务器
                                    │
                              SMTP（客户端→服务器端）
                                    │
                                    ▼
                              Bob的邮件服务器
                                    │
                     ┌──────────────┼──────────────┐
                     ▼                             ▼
              Bob的用户代理                    Bob的用户代理
              (HTTP方式，如Gmail Web)          (IMAP方式，如Outlook)

4.2 SMTP（2.3.1节）

核心内容 ：SMTP（简单邮件传输协议）是因特网电子邮件的核心，使用TCP协议。它限制所有邮件报文的体部分只能采用7比特ASCII表示（这是历史遗留的约束，在用SMTP传送前需将二进制多媒体数据编码为ASCII码）。

SMTP命令与回答示例：

TCP连接建立后（端口25）

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburger.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection

SMTP关键特性：

• 持续连接：如多个报文发往同一服务器，通过同一TCP连接发送
• 直连传输：一般不使用中间邮件服务器，直接从发送方→接收方服务器
• 重试机制：如果Bob的服务器未开机，报文留在Alice的服务器上等待重试（不存留在中间服务器）
• 报文结束标识 ：单行句点CRLF.CRLF

SMTP vs HTTP 对比：

维度	SMTP	HTTP
通信模式	推协议（发送方主动推）	主要是拉协议（客户请求拉取）
数据格式	仅7比特ASCII（历史约束）	无此限制，可直接传输多媒体
报文封装	将所有报文对象放进一个报文	每个对象封装在各自独立的响应中
连接	持续连接	HTTP/1.1默认持续
命令/响应	命令为文本关键词（HELO、MAIL FROM等）	方法关键词（GET、POST等）
端口	25	80

4.3 邮件报文格式（2.3.2节）

RFC 5322定义的邮件报文格式：

首部行     ← From:、To:（必需）、Subject:（可选）等
空行       ← 回车和换行
报文体     ← ASCII格式

报文首部示例：

From: alice@crepes.fr
To: bob@hamburger.edu
Subject: Searching for the meaning of life.

SMTP命令 vs 报文首部：它们在词汇上有重叠（如from和to），但属于不同层面------SMTP命令是握手协议的一部分，首部行是邮件报文自身的一部分。

4.4 邮件访问协议（2.3.3节）

核心问题 ：SMTP是推协议 ，而接收者获取邮件是拉操作。因此Bob的用户代理不能使用SMTP从邮件服务器取回邮件。

邮件访问的两种方法：

┌─────────────────────────────────────────────────────────────┐
│              邮件访问协议                                     │
├───────────────────────┬─────────────────────────────────────┤
│  HTTP（基于Web的邮件）   │  IMAP（因特网邮件访问协议）          │
├───────────────────────┼─────────────────────────────────────┤
│ • 如Gmail Web界面       │ • RFC 3501定义                      │
│ • 用户代理使用HTTP取回   │ • 通常用于Outlook等客户端            │
│   邮件                  │ • 支持文件夹管理（移动、删除、        │
│ • 邮件服务器需HTTP接口   │   标记为重要等）                    │
│   + SMTP接口           │                                     │
└───────────────────────┴─────────────────────────────────────┘

邮件传输完整路径图：

     推（SMTP/HTTP）      推（SMTP）        拉（HTTP/IMAP）
Alice UA ──────────▶ Alice的服务器 ───▶ Bob的服务器 ───▶ Bob UA

为什么要分两步？
→ 如果直接推：Alice的UA到Bob服务器可能不可达（Bob服务器关机）
→ 两步方案：Alice服务器可以重复尝试（约每30分钟），直到Bob服务器可运行为止

---

五、2.4 DNS：因特网的目录服务

5.1 DNS提供的服务（2.4.1节）

核心内容 ：DNS（域名系统）是一个由分层的DNS服务器实现的分布式数据库 ，也是一个允许主机查询分布式数据库的应用层协议 。DNS协议运行在UDP之上，使用53号端口。

主机名的两种标识方式：

标识方式	举例	特点
主机名	www.facebook.com, gaia.cs.umass.edu	便于记忆，但几乎没有位置信息，不定长字符
IP地址	121.7.106.83	4字节，严格层次结构，路由器易处理

DNS提供的三类服务：

服务	说明	示例
主机别名	将易记别名映射为规范主机名及IP地址	enterprise.com → relay1.west-coast.enterprise.com
邮件服务器别名	通过MX记录，邮件服务器和Web服务器可使用相同的别名	bob@yahoo.com（别名）→ 实际的邮件服务器主机名
负载分配	一个主机名对应多个IP地址，DNS循环排列次序分发	cnn.com对应冗余Web服务器的IP集合，每次回答循环次序

DNS交互流程（与HTTP配合）：

浏览器请求 www.someschool.edu/index.html
    │
    ▼
(1) DNS客户端提取主机名 www.someschool.edu
    │
    ▼
(2) DNS客户 → DNS服务器：查询 www.someschool.edu 的IP地址
    │
    ▼
(3) DNS服务器 → DNS客户：返回IP地址
    │
    ▼
(4) 浏览器 → 该IP地址的80端口：发起TCP连接 + HTTP GET请求

5.2 DNS工作机理（2.4.2节）

集中式设计的不可行性：

• 单点故障（一个服务器崩溃，整个因特网瘫痪）
• 通信容量（处理数亿主机的所有DNS查询）
• 远距离集中式（澳大利亚查询纽约服务器，严重时延）
• 维护（为所有主机保留记录，数据库无比庞大）

三类DNS服务器层次结构：

┌──────────────────────────────────────────┐
│         DNS 层次结构                       │
│                                           │
│    ┌────────────┐                         │
│    │  根DNS服务器 │  >1000个实体（13个根     │
│    │  (Root)     │   服务器的副本），        │
│    └─────┬──────┘   由12个不同组织管理       │
│          │ 返回TLD服务器IP地址              │
│    ┌─────▼──────┐                         │
│    │ TLD DNS    │ 每顶级域（com,org,net,   │
│    │ 服务器      │ edu,gov等）和国家域      │
│    └─────┬──────┘ （uk,fr,ca,jp等）一个    │
│          │ 返回权威DNS服务器IP地址          │
│    ┌─────▼──────┐                         │
│    │ 权威DNS    │ 每个具有公共主机访问的    │
│    │ 服务器      │ 组织机构维护自己的记录    │
│    └────────────┘                         │
│                                           │
│    ┌────────────┐                         │
│    │ 本地DNS    │ 每个ISP一台，不属于层次   │
│    │ 服务器      │ 结构但至关重要，起代理作用 │
│    └────────────┘                         │
└──────────────────────────────────────────┘

DNS查询过程（迭代查询示例）：

主机cse.nyu.edu查询gaia.cs.umass.edu的IP地址

cse.nyu.edu
    │
    │ ①递归查询
    ▼
本地DNS dns.nyu.edu
    │
    │ ②迭代查询                       ③回答（edu TLD服务器的IP）
    ├─────────────────────────▶ 根DNS服务器
    │
    │ ④迭代查询                       ⑤回答（dns.umass.edu的IP）
    ├─────────────────────────▶ edu TLD服务器
    │
    │ ⑥迭代查询                       ⑦回答（gaia.cs.umass.edu的IP）
    └─────────────────────────▶ dns.umass.edu权威服务器
    
共8份DNS报文：4份查询 + 4份回答

查询类型：

• 递归查询：请求方要求DNS服务器以自己的名义获取映射（cse.nyu.edu → dns.nyu.edu）
• 迭代查询：DNS服务器返回下一级服务器的地址，由请求方继续查询（图中②④⑥）
• 实践中：从请求主机到本地DNS服务器的查询是递归的，其余是迭代的

DNS缓存：

• 每个DNS回答中的映射在本地存储器中缓存
• TTL（生存时间）：通常设置为两天，超时后丢弃
• 缓存使得除少数DNS查询外，根服务器被绕过
• 本地DNS服务器也可缓存TLD服务器的IP地址

5.3 DNS记录和报文（2.4.3节）

资源记录（Resource Record，RR）格式：

(Name, Value, Type, TTL)

四种DNS记录类型：

类型	Name含义	Value含义	示例
A	主机名	该主机名对应的IP地址	(relay1.bar.foo.com, 145.37.93.126, A)
NS	域（如foo.com）	权威DNS服务器的主机名	(foo.com, dns.foo.com, NS)
CNAME	主机别名	规范主机名	(foo.com, relay1.bar.foo.com, CNAME)
MX	邮件服务器别名	邮件服务器的规范主机名	(foo.com, mail.bar.foo.com, MX)

DNS报文格式（查询和回答报文格式相同）：

┌────────────────────────────────────────────────────────────┐
│                    首部区域（12字节）                         │
│  ├── 标识符（16bit）：标识查询，复制到回答中供匹配           │
│  ├── 标志字段                                               │
│  │   ├── 查询/回答标志（1bit）：0=查询，1=回答               │
│  │   ├── 权威的标志（1bit）：权威DNS服务器置位               │
│  │   ├── 希望递归标志（1bit）                                │
│  │   └── 递归可用标志（1bit）                                │
│  └── 4个数量字段：指出后续4类区域的条目数量                  │
├────────────────────────────────────────────────────────────┤
│                    问题区域                                  │
│  ├── 名字字段：正在查询的主机名                              │
│  └── 类型字段：被询问的问题类型（A、MX等）                   │
├────────────────────────────────────────────────────────────┤
│                    回答区域                                  │
│  └── 包含对初始请求的RR（可含多条RR，一个主机名可有多个IP）   │
├────────────────────────────────────────────────────────────┤
│                    权威区域                                  │
│  └── 其他权威服务器的记录                                    │
├────────────────────────────────────────────────────────────┤
│                    附加信息区域                              │
│  └── "有帮助的"记录（如MX请求的回答含类型A记录）              │
└────────────────────────────────────────────────────────────┘

域名注册过程（DNS数据库插入记录）：

注册域名 networkutopia.com

1）向注册登记机构（registrar，如Network Solutions）提供权威DNS服务器的名字和IP
   例如：dns1.networkutopia.com → 212.212.212.1

2）注册登记机构在TLD com服务器中插入：
   (networkutopia.com, dns1.networkutopia.com, NS)
   (dns1.networkutopia.com, 212.212.212.1, A)

3）在你的权威DNS服务器中配置：
   www.networkutopia.com 的类型A记录
   mail.networkutopia.com 的类型MX记录

5.4 DNS安全性

DNS攻击类型：

攻击类型	说明	历史事件
DDoS带宽洪泛	向根服务器发送大量分组	2002.10.21攻击13个根服务器（大损伤很小，有分组过滤器和缓存保护）
DDoS对TLD服务器	向顶级域服务器发送大量DNS请求（更难过滤）	2016.10.21攻击.com TLD提供商（Mirai恶意软件，十万+物联网设备），影响亚马逊、推特、Netflix
中间人攻击	截获请求并返回伪造回答
DNS投毒	向DNS服务器发送伪造回答，诱使缓存接收伪造记录

防御措施：DNSSEC（DNS安全扩展）RFC 4033，提供源鉴别和数据完整性验证。

---

六、2.5 P2P文件分发

6.1 P2P体系结构的扩展性（量化分析）

分发时间模型（P2P vs 客户-服务器）：

关键符号：
  F = 文件长度（bit）
  N = 对等方数量
  u_s = 服务器上载速率
  u_i = 第i个对等方上载速率
  d_i = 第i个对等方下载速率
  d_min = min{d_1, d_2, ..., d_N}

客户-服务器分发时间：

Dcs=max⁡{NFus,Fdmin⁡}D_{cs} = \max\left\{\frac{NF}{u_s}, \frac{F}{d_{\min}}\right\}Dcs=max{usNF,dminF}

P2P分发时间：

DP2P=max⁡{Fus,Fdmin⁡,NFus+∑i=1Nui}D_{P2P} = \max\left\{\frac{F}{u_s}, \frac{F}{d_{\min}}, \frac{NF}{u_s + \sum_{i=1}^{N} u_i}\right\}DP2P=max{usF,dminF,us+∑i=1NuiNF}

关键对比结论：

客户-服务器：分发时间随N线性增长（N倍增长 → N倍时间）
P2P：分发时间有界！对任意N，始终小于一个文件的最小时延（F/u_s 或 F/d_min）

数值例子（F/u=1小时, u_s=10u, d_min≥u_s）：
  N=1000时：P2P ≈ 0.1小时，C/S ≈ 100小时
  N=1000000时：P2P ≈ 0.1小时，C/S ≈ 100000小时

自扩展性的直接成因：对等方除了是比特的消费者外，
                    还是它们的重新分发者。

三种条件的含义解释：

1. F/u_s：服务器至少发送文件的每个比特一次
2. F/d_min：下载最慢的对等方的最快接收时间
3. NF/(u_s+Σu_i)：系统总上载能力的限制（所有对等方必须接收NF bit）

6.2 BitTorrent协议

核心概念定义：

术语	定义
洪流（torrent）	参与特定文件分发的所有对等方的集合
块（chunk）	对等方下载的等长度文件片，典型长度256KB
追踪器（tracker）	每个洪流的基础设施节点，跟踪参与的对等方

BitTorrent工作流程：

┌────────────────────────────────────────────────────────────────┐
│                    BitTorrent 工作流程                           │
├────────────────────────────────────────────────────────────────┤
│                                                                 │
│ 1）新对等方Alice加入洪流                                         │
│    │                                                             │
│    ▼                                                             │
│ 2）向追踪器注册，追踪器返回50个对等方IP子集                       │
│    │                                                             │
│    ▼                                                             │
│ 3）Alice尝试与列表上所有对等方创建并行TCP连接                     │
│    → 成功创建的称"邻近对等方"                                     │
│    │                                                             │
│    ▼                                                             │
│ 4）周期性询问每个邻近对等方的块列表                               │
│    │                                                             │
│    ▼                                                             │
│ 5）块请求决策：使用最稀缺优先（rarest first）                     │
│    → 针对没有的块，优先请求邻居中副本数量最少的块                  │
│    → 目标：均衡每个块在洪流中的副本数量                           │
│    │                                                             │
│    ▼                                                             │
│ 6）上载决策：使用一报还一报（tit-for-tat）对换算法               │
│    → 确定向Alice提供数据速率最高的4个邻居 → "疏通"（unchoked）    │
│    → 每10秒重新计算速率                                         │
│    → 每30秒随机选择额外1个邻居上载（"乐观疏通"）                  │
│    → 其余邻居被"阻塞"，不能接收任何块                            │
│    │                                                             │
│    ▼                                                             │
│ 7）对等方可能在任何时间离开或重新加入洪流                         │
│                                                                 │
└────────────────────────────────────────────────────────────────┘

最稀缺优先（Rarest First） ：对于她没有的块，在邻居中确定被重复最少的块（最稀缺的块），并首先请求这些块。目标是（大致）均衡每个块在洪流中的副本数量。

"一报还一报"（Tit-for-tat）激励机制：

• Alice根据向自己提供最高速率的邻居给出优先权
• 每10秒重新计算并修改前4位"疏通"对等方集合
• 每30秒随机选择一个额外邻居发送块（"乐观疏通"）
• 随机选择使新对等方能获得块以开始交换，并以趋于彼此协调的速率上载
• 如果没有这种机制，大多数用户将成为搭便车者，BitTorrent将不复存在

DHT（分布式散列表）：简单的数据库，记录分布在P2P系统的多个对等方上，在BitTorrent中得到广泛实现。

---

七、2.6 视频流和内容分发网（CDN）

7.1 因特网视频（2.6.1节）

核心内容 ：流式视频大约占2020年因特网流量的80% 。压缩的因特网视频典型比特率范围从100kbps（低质量）到超过4Mbps（高清电影）再到超过10Mbps（4K）。

关键数字：

指标	数值
低质量视频	100kbps
高清电影	超过4Mbps
4K在线播放	超过10Mbps
单一2Mbps视频67分钟	约1GB存储和流量
最重要的性能度量	平均端到端吞吐量
视频帧率	每秒24或30张图像

多版本编码：利用压缩可生成相同视频的多个版本（如300kbps、1Mbps、3Mbps），用户根据当前可用带宽选择观看版本。

7.2 HTTP流和DASH（2.6.2节）

HTTP流：视频作为普通HTTP对象存储（每个视频有URL），客户发送HTTP GET请求，服务器以尽可能快的速率发送。客户缓存视频后进行播放。

DASH（经HTTP的动态适应性流）：

┌─────────────────────────────────────────────────────────────┐
│                  DASH 工作流程                                │
│                                                              │
│  视频编码为多个版本（不同比特率，不同质量）                     │
│  每个版本存储在HTTP服务器中（各有不同URL）                      │
│                                                              │
│  请求流程：                                                   │
│  1）客户请求告示文件（manifest file）                         │
│     → 获取所有版本的URL列表及比特率                           │
│                                                              │
│  2）客户按照HTTP GET分段请求视频块（每次几秒）                 │
│     → 指定URL + 字节范围                                      │
│                                                              │
│  3）客户同时测量接收带宽                                      │
│     → 运行速率决定算法                                        │
│     → 带宽高 → 选高速率版本                                   │
│     → 带宽低 → 选低速率版本                                   │
│                                                              │
│  特性：允许在会话过程中动态适应可用带宽变化                     │
│        （对移动用户特别重要）                                  │
└─────────────────────────────────────────────────────────────┘

7.3 内容分发网（2.6.3节）

单一数据中心的问题：

1. 远端客户时延大（端到端路径链路多，瓶颈风险高）
2. 流行视频经相同链路多次发送（浪费带宽，支付更多ISP费用）
3. 单点故障（数据中心或链路崩溃则全部不可用）

CDN（内容分发网）：管理分布在多个地理位置的服务器，存储视频（和其他Web内容）的副本，将每个用户请求定向到提供最好用户体验的CDN位置。

两种CDN类型：

类型	说明	例子
专用CDN	内容提供商自己拥有	谷歌CDN（分发YouTube等）
第三方CDN	代表多个内容提供商分发内容	Akamai、Limelight、Level-3

谷歌的CDN基础设施（三级架构）：

层级	数量	服务器规模	用途
兆数据中心	约19个	数万台~十万台级	动态内容（搜索结果、Gmail）
IXP集群	约90个	数百台	静态内容（YouTube视频）
深入服务器缓存	数百个	数十台（在一个机架上）	静态内容（搜索结果网页的静态部分），执行TCP分岔

两种CDN服务器安置原则：

┌─────────────────────────────────────────────────────────────┐
│              CDN服务器安置策略对比                             │
├────────────────────────────┬────────────────────────────────┤
│  深入（Enter Deep）         │  邀请做客（Bring Home）          │
│  Akamai首创                │  Limelight等采用                 │
├────────────────────────────┼────────────────────────────────┤
│ • 在遍及全球的接入ISP中      │ • 在少量（约10个）关键位置      │
│   部署服务器集群             │   建造大集群                    │
│ • Akamai在1000+位置部署     │ • 将集群放在IXP中               │
│ • 靠近端用户                 │ • 维护开销低                    │
│ • 减少链路和路由器数量       │ • 可能时延更高、吞吐量更低      │
│ • 维护管理任务艰巨           │                                 │
└────────────────────────────┴────────────────────────────────┘

CDN操作（DNS重定向流程）：

内容提供商NetCinema雇用第三方CDN KingCDN

URL: http://video.netcinema.com/6Y7B23V

流程：
1）用户点击链接 → 发送对video.netcinema.com的DNS请求
2）LDNS → NetCinema权威DNS服务器（识别字符串"video"）
3）NetCinema权威DNS → 返回KingCDN主机名（如a1105.kingcdn.com）
4）LDNS → KingCDN DNS系统（第二次DNS请求）
5）KingCDN DNS → 选择"最好"的CDN服务器，返回其IP地址
6）LDNS → 用户主机（转发CDN服务器IP）
7）用户 → CDN服务器：直接TCP连接 + HTTP GET请求
   （如使用DASH，先获得告示文件，然后动态选择视频版本块）

集群选择策略：

策略	方法	优点	缺点
地理最邻近	使用GeoIP数据库映射LDNS位置，选择距离最近的集群	对大部分用户工作良好	忽略网络路径长度、时延和带宽变化
实时测量	集群周期性地对LDNS发送探测分组（ping/DNS请求）	基于当前流量条件	许多LDNS不响应探测

内容复制策略 ：大多数CDN使用拉策略（而非推策略）------客户向未缓存该视频的集群请求时，集群检索视频、流式传输给客户并在本地存储副本。当存储满时，删除不常请求的视频。

7.4 Netflix和YouTube案例（2.6.4节）

Netflix体系结构：

┌───────────────────────────────────────────────────────────┐
│                Netflix 视频流平台                           │
├───────────────────────────────┬───────────────────────────┤
│     亚马逊云（AWS）            │    专用CDN                  │
├───────────────────────────────┼───────────────────────────┤
│ • Web网站（注册/登录/计费）     │ • 在200+个IXP位置有服务器机架│
│ • 电影目录/浏览/搜索           │ • 数百个ISP位置有服务器机架  │
│ • 推荐系统                    │ • 每台服务器：              │
│ • 内容摄取（接收母带）         │   - 几个10Gbps以太网端口    │
│ • 内容处理（生成不同格式/版本） │   - 超过100TB存储          │
│ • 向CDN上载版本               │ • 使用推高速缓存（非高峰时段）│
│                               │ • 大机架：整个视频库        │
│                               │ • 小机架：仅流行视频        │
└───────────────────────────────┴───────────────────────────┘

Netflix关键设计决策：

• 不使用DNS重定向：Netflix软件（运行在AWS上）直接告知客户使用特定CDN服务器
• 推高速缓存：非高峰时段预先推入CDN服务器，而非拉高速缓存
• 专用DASH：使用约4秒长的块，客户测量吞吐量并运行速率决定算法
• 服务器选择：优先选择客户所在ISP中的Netflix机架服务器，其次选择邻近IXP服务器

YouTube特征：

特征	YouTube实现
CDN	谷歌专用CDN，在几百个IXP和ISP位置安装服务器集群
缓存策略	使用拉高速缓存（CDN服务器未命中时检索并缓存）
重定向	使用DNS重定向
集群选择	主要基于最低RTT定向客户，有时定向到更远集群以平衡负载
流式协议	HTTP流（不使用DASH），提供少量不同比特率版本
版本选择	人工选择（而非自动适应性切换）
流量控制	使用HTTP字节范围请求限制数据流（节省带宽）
上载	经HTTP从客户到服务器上载，处理在谷歌数据中心完成

---

八、2.7 套接字编程：生成网络应用

8.1 UDP套接字编程（2.7.1节）

UDP通信特性 ：发送前不需要握手。发送时，必须在分组上附上目的地地址（目的IP + 目的端口号）。源地址（源IP + 源端口号）由操作系统自动附加。

UDP套接字编程关键API调用：

┌──────────────────────────────────────────────────────────────┐
│                  UDP套接字编程流程                              │
├───────────────────┬──────────────────────────────────────────┤
│      客户          │              服务器                       │
├───────────────────┼──────────────────────────────────────────┤
│                    │      socket(AF_INET, SOCK_DGRAM)         │
│                    │      bind(('', serverPort))              │
│                    │                                          │
│ socket(AF_INET,    │                                          │
│   SOCK_DGRAM)      │                                          │
│                    │                                          │
│ sendto(message.encode(),                                     │
│   (serverName,     │                                          │
│    serverPort))    │                                          │
│       │            │      recvfrom(2048) ← 等待接收           │
│       └───────────→│      upper()        ← 处理               │
│                    │      sendto(modified, clientAddress)     │
│ recvfrom(2048) ←───┘      │                                    │
│                    │                                          │
│ close()            │                                          │
└───────────────────┴──────────────────────────────────────────┘

UDP客户代码（UDPClient.py）：

from socket import *
serverName = 'hostname'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)        # 创建UDP套接字
message = input('Input lowercase sentence:')
clientSocket.sendto(message.encode(), (serverName, serverPort))
modifiedMessage, serverAddress = clientSocket.recvfrom(2048)
print(modifiedMessage.decode())
clientSocket.close()

UDP服务器代码（UDPServer.py）：

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM)        # 创建UDP套接字
serverSocket.bind(('', serverPort))               # 绑定端口号
print("The server is ready to receive")
while True:
    message, clientAddress = serverSocket.recvfrom(2048)
    modifiedMessage = message.decode().upper()
    serverSocket.sendto(modifiedMessage.encode(), clientAddress)

8.2 TCP套接字编程（2.7.2节）

TCP通信特性 ：面向连接。客户和服务器在数据交换前必须先握手并创建TCP连接 。一旦连接建立，双方可直接写入TCP管道 （无需每次附上目的地址）。TCP保证数据按序、可靠交付。

TCP"两扇门"模型（重要理解）：

服务器有两类套接字：
┌─────────────────────────────────────┐
│  ① 欢迎套接字（welcome socket）      │
│     serverSocket                   │
│     → 用于接受所有客户的初始连接请求 │
│     → "敲欢迎之门"                  │
│                                     │
│  ② 连接套接字（connection socket）   │
│     connectionSocket               │
│     → 为每个客户专门创建            │
│     → 用于与该特定客户的数据通信    │
│     → 管道模式：一端写入，另一端收到 │
└─────────────────────────────────────┘

TCP套接字编程关键API调用流程：

┌──────────────────────────────────────────────────────────────┐
│                  TCP套接字编程流程                              │
├───────────────────┬──────────────────────────────────────────┤
│      客户          │              服务器                       │
├───────────────────┼──────────────────────────────────────────┤
│                    │  socket(AF_INET, SOCK_STREAM)            │
│                    │  bind(('', serverPort))                  │
│                    │  listen(1)          ← 聆听连接请求        │
│                    │                                          │
│ socket(AF_INET,    │                                          │
│   SOCK_STREAM)     │                                          │
│ connect((serverName,                                          │
│   serverPort))     │                                          │
│       │            │  accept() → connectionSocket, addr       │
│       │ ┌────三次握手───┐          │                           │
│       │ └────── OK ────┘          │                           │
│       │            │                                          │
│ send(sentence.encode())                                       │
│       │            │  recv(1024)   ← 从连接套接字接收          │
│       └───────────→│  upper()      ← 处理                     │
│                    │  connectionSocket.send(modified)         │
│ recv(1024) ←───────┘  │                                        │
│       │            │  connectionSocket.close() ← 关闭连接套接字│
│ close()            │  # serverSocket 保持打开，等待下一个客户  │
└───────────────────┴──────────────────────────────────────────┘

TCP客户代码（TCPClient.py）：

from socket import *
serverName = 'servername'
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)      # 创建TCP套接字
clientSocket.connect((serverName, serverPort))    # 发起TCP连接（三次握手）
sentence = input('Input lowercase sentence:')
clientSocket.send(sentence.encode())             # 直接发送（无需地址）
modifiedSentence = clientSocket.recv(2048)
print('From Server: ', modifiedSentence.decode())
clientSocket.close()                             # 关闭连接

TCP服务器代码（TCPServer.py）：

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_STREAM)     # 创建TCP欢迎套接字
serverSocket.bind(('', serverPort))
serverSocket.listen(1)                           # 聆听连接
print('The server is ready to receive')
while True:
    connectionSocket, addr = serverSocket.accept()  # 创建新连接套接字
    sentence = connectionSocket.recv(1024).decode()
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence.encode())
    connectionSocket.close()                     # 关闭此客户的连接套接字

8.3 TCP套接字 vs UDP套接字 对比总表

维度	UDP套接字	TCP套接字
套接字类型	SOCK_DGRAM	SOCK_STREAM
连接	无连接，直接发送	面向连接，需connect()和accept()
握手	无	三次握手（透明进行）
服务器套接字数	1个（所有客户共享）	每个客户2个（1个欢迎套接字 + N个连接套接字）
数据发送方式	sendto()，每次需附上目的地址	send()，通过已建立的连接直接发送
数据接收方式	recvfrom()，返回数据和源地址	recv()，从连接套接字接收
可靠性	不可靠（可能丢失、乱序）	可靠（保证按序完整交付）
程序启动顺序	客户可先于服务器运行	服务器必须先于客户运行
数据边界	识别报文边界（独立数据报）	面向字节流（不保留报文边界）
最佳理解模型	分组通过门投递（每次附地址）	客户与服务器的"管道"（全双工双向）

---

九、2.8 小结

核心要点：

• 学习了网络应用的概念和实现两方面
• 客户-服务器模式在HTTP、SMTP、DNS等协议中的应用
• P2P体系结构与客户-服务器体系结构的对比
• 流式视频和CDN的工作原理
• TCP和UDP套接字编程基础

前后呼应：

• 第1章1.1.3节的"协议"定义，经过本章对HTTP、SMTP、DNS的细致学习，加入了"实质性的内容"
• 2.1节描述的TCP/UDP服务模型将在第3章（运输层）深入探讨其"如何工作"及"为什么要这么做"
• 本章学完应用层后，继续沿协议栈向下，进入运输层（第3章）

---

十、核心公式速查

公式	含义	位置
Dcs=max⁡{NFus,Fdmin⁡}D_{cs} = \max\left\{\frac{NF}{u_s}, \frac{F}{d_{\min}}\right\}Dcs=max{usNF,dminF}	客户-服务器最小分发时间	2.5节 式(2-1)
DP2P=max⁡{Fus,Fdmin⁡,NFus+∑i=1Nui}D_{P2P} = \max\left\{\frac{F}{u_s}, \frac{F}{d_{\min}}, \frac{NF}{u_s + \sum_{i=1}^{N}u_i}\right\}DP2P=max{usF,dminF,us+∑i=1NuiNF}	P2P最小分发时间	2.5节 式(2-3)
RTT（往返时间）	短分组从客户到服务器再返回的时间	2.2.2节
非持续HTTP响应时间 ≈ 2RTT + 传输时间	估算HTML对象获取时延	2.2.2节
接入链路流量强度 = (请求率 × 对象长度) / 链路速率	Web缓存效益分析	2.2.5节
缓存后平均时延 = 命中率×(本地延迟) + (1-命中率)×(远程延迟)	Web缓存效益计算	2.2.5节
utotal=us+∑uiu_{\text{total}} = u_s + \sum u_iutotal=us+∑ui	P2P系统总上载能力	2.5节

---

十一、核心概念词汇表

术语	英文	定义
应用体系结构	Application Architecture	应用程序研发者设计的、规定如何在端系统上组织应用的方案
套接字	Socket	应用层与运输层之间的接口，即应用编程接口（API）
客户进程	Client Process	在一对进程通信会话中，发起通信的进程
服务器进程	Server Process	在一对进程通信会话中，等待联系的进程
可靠数据传输	Reliable Data Transfer	确保数据正确、完全地由一端交付给另一端
带宽敏感应用	Bandwidth-Sensitive Application	具有特定吞吐量要求的应用（如因特网电话）
弹性应用	Elastic Application	能够根据可用带宽多少或多或少利用吞吐量的应用
TLS	Transport Layer Security	运输层安全，在应用层实现，加强TCP的安全性服务
无状态协议	Stateless Protocol	服务器不保存关于任何客户的状态信息（如HTTP）
往返时间	Round-Trip Time (RTT)	短分组从客户到服务器再返回客户的时间
非持续连接	Non-Persistent Connection	每个请求/响应对经单独的TCP连接发送
持续连接	Persistent Connection	所有请求及其响应经相同的TCP连接发送
流水线	Pipelining	在持续连接上，不必等待未决请求的回答即可接连发出请求
队首阻塞	Head Of Line (HOL) Blocking	前面的报文阻塞后面报文的传输
成帧	Framing	HTTP/2将报文划分为独立的帧，交错发送后在接收端装配
多路复用	Multiplexing	经单一TCP连接交错发送多个请求和响应的帧
服务器推	Server Push	HTTP/2中服务器可主动推送额外对象，无需客户请求
Web缓存器	Web Cache / Proxy Server	代表初始Web服务器满足HTTP请求的网络实体
条件GET	Conditional GET	使用If-modified-since:首部行的GET请求，验证缓存对象是否最新
用户代理	User Agent (UA)	允许用户阅读、回复、转发、保存和撰写报文的程序
邮件服务器	Mail Server	电子邮件体系结构的核心，管理用户邮箱
SMTP	Simple Mail Transfer Protocol	因特网电子邮件的核心应用层协议（推协议）
IMAP	Internet Mail Access Protocol	因特网邮件访问协议（拉协议），RFC 3501
DNS	Domain Name System	域名系统：由分层的DNS服务器实现的分布式数据库 + 应用层协议
根DNS服务器	Root DNS Server	层次结构最顶层，提供TLD服务器的IP地址（13个根服务器的1000+副本）
TLD服务器	Top-Level Domain Server	顶级域服务器（com/org/net/edu/gov等），提供权威DNS服务器的IP地址
权威DNS服务器	Authoritative DNS Server	持有组织机构的主机名到IP地址映射记录的服务器
本地DNS服务器	Local DNS Server	每个ISP提供的默认名字服务器，起代理作用
递归查询	Recursive Query	要求DNS服务器以自己的名义获取映射
迭代查询	Iterative Query	DNS服务器返回下一级服务器的地址，由查询方继续
资源记录	Resource Record (RR)	DNS存储的基本数据单元，4元组：(Name, Value, Type, TTL)
P2P	Peer-to-Peer	对等方之间直接通信，不依赖专用服务器
洪流	Torrent	参与特定文件分发的所有BitTorrent对等方的集合
块	Chunk	BitTorrent中等长度的文件片，典型256KB
追踪器	Tracker	每个洪流的基础设施节点，跟踪参与的对等方
最稀缺优先	Rarest First	优先请求在邻居中副本数量最少的块
一报还一报	Tit-for-tat	BitTorrent的激励机制：对提供高上载速率的邻居优先上载
疏通	Unchoked	BitTorrent前4位高上载速率的对等方可接收数据
DASH	Dynamic Adaptive Streaming over HTTP	HTTP动态适应性流：视频多版本，客户依带宽动态切换
CDN	Content Distribution Network	内容分发网：管理分布在多个地理位置的服务器，定向用户请求到最佳位置
告示文件	Manifest File	DASH中提供所有视频版本的URL及对应比特率的文件
深入	Enter Deep	CDN服务器在接入ISP中部署，靠近端用户的策略（Akamai）
邀请做客	Bring Home	CDN服务器在少量关键位置（IXP）建大集群的策略（Limelight）
专用CDN	Private CDN	内容提供商自有的CDN（如谷歌、Netflix）
第三方CDN	Third-party CDN	代表多个内容提供商分发内容的CDN（如Akamai）
DDoS	Distributed Denial of Service	分布式拒绝服务攻击（对DNS等基础设施的威胁）
DNSSEC	DNS Security Extensions	DNS安全扩展，防范DNS投毒等攻击
SOCK_DGRAM	Socket Datagram	UDP套接字类型
SOCK_STREAM	Socket Stream	TCP套接字类型
欢迎套接字	Welcome Socket	TCP服务器用于接受客户初始连接的套接字
连接套接字	Connection Socket	TCP服务器为每个客户专门创建的套接字

---

十二、全书知识地图 -- 第2章在各章中的定位

第1章（计算机网络基础概念和协议分层框架）
    │
    ▼
第2章（本章 -- 应用层）
    │ 放大1.5节的应用层概念
    │ ├── 2.1 网络应用原理（体系结构、运输服务选择）
    │ ├── 2.2 Web和HTTP（含HTTP/2和HTTP/3）
    │ ├── 2.3 电子邮件（SMTP、IMAP）
    │ ├── 2.4 DNS（分布式数据库 + 协议）
    │ ├── 2.5 P2P文件分发（BitTorrent）
    │ ├── 2.6 视频流和CDN（Netflix、YouTube案例）
    │ └── 2.7 套接字编程（TCP/UDP API）
    │
    │ "我们已完成了在分层网络体系结构中的向下之旅的第一步"
    │
    ├──→ 第3章 运输层
    │     深入探讨TCP/UDP如何提供可靠数据传输、
    │     拥塞控制等服务的具体实现机制
    │     （TCP CUBIC、BBR、QUIC协议）
    │
    ├──→ 第4章 网络层：数据平面
    │     IP地址的详细讨论（2.1节中提及的32比特IP地址）
    │
    ├──→ 第5章 网络层：控制平面
    │     路由选择协议（贯穿各层的核心机制）
    │
    ├──→ 第6章 链路层
    │     聚焦较低层的数据传输机制
    │
    ├──→ 第7章 无线网络和移动网络
    │     移动用户带宽波动对DASH适应性流的影响
    │
    └──→ 第8章 安全
          放大TLS、DNS安全（DNSSEC）、DDoS攻击等内容