当前位置：首页 > news >正文

【计算机网络笔记】第二章应用层 (Application Layer)

news 2025/10/25 7:27:21

一、Principles of Network Applications

五层因特网协议栈是因特网通信的核心分层架构，包含应用层、传输层、网络层、链路层和物理层。

“应用层”这一节是理解所有网络应用的基础，它解释了应用程序是如何在网络上被构建和工作的，而不涉及任何特定的协议。其核心内容可以概括为以下四个关键问题：

网络应用采用何种体系结构？
网络中的进程如何通信？
传输层为应用提供了哪些服务？
应用层协议具体规定了什么？

1.1 网络应用体系结构 (Application Architectures)

应用程序的体系结构定义了应用程序在端系统上的组织方式。

a) 客户端-服务器架构 (Client-Server Architecture)

核心特征：有一个总是打开的主机，称为服务器，它提供服务。许多其他主机，称为客户端，向服务器请求并接收服务。
服务器特点：
- 永久性IP地址。
- 始终在线，总是开机。
- 通常位于数据中心，以便扩展（处理大量请求）。
客户端特点：
- 可能与服务器间歇性连接。
- 可能使用动态IP地址。
- 彼此之间不直接通信。
典型例子：Web、FTP、电子邮件。

b) 对等架构 (P2P Architecture)

核心特征：没有（或极少依赖）专门的服务器。应用程序在间断连接的主机（称为对等方）之间直接通信。任意的终端系统直接通信，在请求服务的同时也提供服务。
优点：
- 自扩展性：每个新加入的对等方既增加了服务需求，也带来了新的服务能力（如带宽、存储空间）。
挑战：
- 管理复杂：对等方可能随时加入或离开网络。(对等节点间歇性连接且频繁更换IP地址)
- 安全性问题：难以集中控制。
典型例子：BitTorrent（文件共享）、Skype（早期版本）。

Client-Server Architecture	P2P Architecture

c) 混合架构 (Hybrid of Client-Server and P2P)

架构逻辑：以 C/S 架构为核心管控层，P2P 架构为分布式传输层，平衡 “集中管理” 与 “高效传输” 的需求。
- 管控层（C/S）：服务器负责用户认证、文件索引管理、权限控制（如判断用户是否有权限下载文件）。
- P2P：认证通过后，用户终端之间直接建立连接传输文件，减轻服务器带宽压力，提升大文件传输速度。
典型例子：迅雷下载、腾讯微云（部分大文件传输场景），服务器仅提供文件元数据，实际数据通过用户节点间的 P2P 网络分发。

1.2 进程通信 (Processes Communicating)

应用程序的本质是进程之间的通信。

进程：在端系统上运行的程序。同一主机进程间通信使用操作系统定义的方式（管道，信号量，共享内存）；不同端系统（主机）上的进程通过计算机网络交换报文来通信。
客户与服务器进程：
- 客户进程：通信会话中发起连接的进程。
- 服务器进程：通信会话中等待连接请求的进程。
- 注意：在P2P应用中，一个进程可能同时是客户和服务器。
套接字接口 (The Socket Interface)
- 这是应用层原理中最核心的概念之一。不同端系统的进程通过socket进行通信。
- 定义：套接字是同一台主机内应用层与传输层之间的接口，也称为应用程序编程接口（API）。
- 作用：应用程序开发者通过套接字向网络发送或接收报文。可以将进程比作房子，而套接字就是房子的“门”。
- 开发者控制权：开发者可以控制套接字在应用层端的一切（如选择传输协议、设置报文内容），但对套接字的传输层端几乎无控制权（传输层的具体操作由操作系统内核实现）。
进程寻址 (Addressing Processes)
- 为了向特定进程发送报文，需要两个信息：
  1. 主机的地址：IP地址（32位，唯一标识主机）。
  2. 主机上的特定进程：端口号（Port Number）。例如，Web服务器使用80端口，邮件服务器使用25端口。

1.3 可供应用程序使用的传输服务 (Transport Services Available to Applications)

应用程序对数据传输有特定的需求。传输层协议（主要是TCP和UDP）以服务的形式满足这些需求。

服务需求	描述	典型应用
可靠数据传输 (Reliable Data Transfer)	保证数据无差错、完整地送达。	文件传输、Web交易、电子邮件（不能丢失数据）。
吞吐量 (Throughput)	保证可用的数据传输速率。	多媒体应用（需要最小带宽才能“有效”）。
定时 (Timing)	保证数据在特定延迟内送达。	网络电话、互动游戏（要求低延迟）。
安全性 (Security)	提供加密、数据完整性、身份认证等。	所有需要保密的通信（如网上银行、安全邮件）。

1.4 因特网提供的传输服务 (Transport Services Provided by the Internet)

因特网主要提供了两种传输层协议：

a) TCP 服务

面向连接：在数据传输前，客户和服务器需要先进行“三次握手”以建立连接。（握手的目的是建立连接）
可靠数据传输：通过流量控制、序列号、确认和重传机制，确保数据正确、有序地送达。
拥塞控制：当网络拥塞时，会抑制发送方的速率，为整个互联网带来利益。
不提供：定时保证、最小吞吐量保证、安全保证（但可通过SSL/TLS增强安全）。

b) UDP 服务

无连接：通信前无需握手。
不可靠数据传输：不保证数据送达，也不保证顺序。
轻量、简单：没有建立连接的延迟，也没有拥塞控制机制。
不提供：可靠性、流量控制、拥塞控制、定时、吞吐量保证、安全性。

应用如何选择？

需要高可靠性的应用（如Web、邮件、文件传输）选择TCP。
能容忍部分数据丢失、但对延迟敏感的应用（如流媒体、网络电话、DNS查询）通常选择UDP，以规避TCP的连接建立开销和拥塞控制带来的延迟。

1.5 应用层协议 (Application-Layer Protocols)

定义：应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。它精确规定了：
- 报文类型：如请求报文和响应报文。
- 报文语法：报文中的字段及其描述方式。
- 字段语义：字段中信息的含义。
- 规则：进程何时以及如何发送/响应报文。
公开与专用：有些协议是公开标准（如HTTP、SMTP，由RFC定义），有些是专用的（如Skype使用的协议）。

总结

网络应用原理的核心思想是：网络应用由分布在端系统上的进程通过交换报文实现通信。开发者选择一种应用体系结构（C/S或P2P），并利用传输层（TCP或UDP）通过套接字接口提供的服务，按照特定的应用层协议规则来构建应用程序。

理解这些基本原理是学习后续具体应用协议（如HTTP、SMTP、DNS等）的基础。

二、Web and HTTP

本节全面介绍了万维网（World Wide Web）的应用层协议——超文本传输协议hypertext transfer protocol（HTTP）。其核心内容是理解 HTTP 如何通过请求/响应模型在客户端（浏览器）和服务器之间传输 Web 对象。

2.1 HTTP 概述

Web 页面的构成：
- Web 页面 是由多个对象组成的。
- 对象可以是 HTML 文件、JPEG 图像、JavaScript 文件、CSS 文件、视频片段等任何可通过 URL 寻址的文件。
- 一个典型的页面包含一个 基本 HTML 文件，该文件通过 URL 引用了页面中的其他所有对象。
URLs (Uniform Resource Locators)：统一资源定位器
HTTP 的角色：
- HTTP 是 Web 的应用层协议，它定义了客户端和服务器之间交换的报文格式和交换规则。
- 客户端（浏览器）：发起 HTTP 请求。
- 服务器：响应请求，发送被请求的对象。
传输层基础：
- HTTP 使用 TCP 作为其支撑的传输层协议。
- 流程：客户端首先发起一个到服务器的 TCP 连接（默认端口 80），连接建立后，客户端和服务器进程通过各自的套接字（Socket） 发送和接收 HTTP 报文。
- 关键好处：由于 TCP 提供可靠数据传输，HTTP 无需关心数据丢失、乱序等问题，可以专注于应用层的逻辑。
HTTP 是无状态的：
- 服务器不保存任何关于客户端过去请求的任何信息。
- 优点：简化了服务器设计，易于维护。缺点：对于需要“记忆”用户状态的应用（如购物车），需要额外机制（即 Cookie）来实现。

2.2 HTTP 连接 (HTTP Connections)

文档重点对比了两种连接策略：

非持续连接：
- 每个 TCP 连接只传输一个请求报文和一个响应报文。
- 流程：建立 TCP 连接 -> 请求/响应一个对象 -> 关闭连接。如需多个对象，则重复此过程。
- 缺点：
  - 响应时间慢：每个对象需要 2个RTT（Round-Trip Time，往返时间）——1个RTT用于建立TCP连接，1个RTT用于请求和接收对象。
  - 服务器负担重：需要为每个对象建立和维护新的 TCP 连接。
- HTTP/1.0 默认使用非持续连接。
持续连接：
- 服务器在发送响应后保持 TCP 连接打开，后续对同一服务器的请求和响应可以通过这个相同的连接进行。
- 优点：
  - 减少响应时间：所有对象（如基本HTML文件和所有图片）仅需 1个RTT（忽略传输时间）。因为连接已建立，后续请求可立即发出。
  - 减轻负担：减少了服务器和网络的开销。
- HTTP/1.1 默认使用带流水线的持续连接，即客户端可以连续发送多个请求，而不必等待每个响应，服务器按序返回响应。

2.3 HTTP 报文格式 (HTTP Message Format)

报文由三个部分组成，即开始行、首部行和实体主体。

2.3.1 HTTP 请求报文

在请求报文中，开始行就是请求行。

结构：
- 请求行：包含方法（GET, POST, HEAD, PUT, DELETE）、URL（所请求资源的URL）、HTTP 版本。
- 首部行：包含向服务器提供的附加信息，如 Host:（必需）、Connection: close（指示使用非持续连接）、User-agent:（浏览器类型）、Accept-language:（语言偏好）等。
- 实体体：通常为空，但在使用 POST 方法提交表单时包含用户输入的数据。

常用方法：（以下方法在http1.1版本中全部实现）

方法或操作	含义
OPTION	请求一些选项的信息
GET	请求读取由 URL所标志的信息
HEAD	请求读取由 URL所标志的信息的首部
POST	给添加信息（例如，注释）
PUT	向服务器上传文件（在指明的 URL下存储一个文档）
DELETE	删除服务器上的文件（删除指明的 URL所标志的资源）
TRACE	用来进行环回测试的请求报文
CONNECT	用于代理服务器

2.3.2 HTTP 响应报文

结构：
- 状态行：包含 HTTP 版本、状态码、状态短语。
- 首部行：包含关于服务器的信息和被发送的对象，如 Connection: close、Date:、Server:、Last-Modified:（用于缓存验证）、Content-Length:、Content-Type:。
- 实体体：包含所请求的对象本身（如 HTML 文件、图片数据）。
常见状态码：
- 200 OK：请求成功。
- 301 Moved Permanently：请求的对象已被永久转移（新的 URL 在 Location: 首部中指明）。
- 400 Bad Request：请求报文不能被服务器理解。
- 404 Not Found：被请求的文档不在服务器上。
- 505 HTTP Version Not Supported：服务器不支持请求的 HTTP 协议版本。

2.4 用户与服务器的交互：Cookie

目的：在无状态的 HTTP 协议之上，为服务器提供一种跟踪用户状态、识别用户的机制。
四个组件：
1. HTTP 响应报文中的 Set-cookie: 首部行。
2. HTTP 请求报文中的 Cookie: 首部行。
3. 用户端系统中由浏览器管理的 Cookie 文件。
4. 服务器端的后端数据库。
工作流程：服务器为用户生成唯一 ID 并存入数据库 -> 通过 Set-cookie 发给浏览器 -> 浏览器保存 ID -> 后续所有请求都通过 Cookie 头携带此 ID -> 服务器通过 ID 在数据库中查询和更新该用户的信息（如购物车内容、登录状态）。
应用：购物车、用户登录、内容推荐、会话管理。
争议：涉及用户隐私问题，因为网站可以跟踪用户的浏览行为。
Cookies一般包含5个字段：
- 域指明Cookie来自何方，每个域为每个客户分配Cookie有数量限制
- 路径标明服务器的文件树中哪些部分可以使用该Cookie：
- 内容采用“名字=值”的形式，是Cookie存放内容的地方，可以达到4K容量，内容只是字符串，不是可执行程序
- 安全指示浏览器只向使用安全传输连接的服务器返回Cookie

Cookie机制实现方法4个要点：
1. HTTP响应报文中的cookie首部行；
2. HTTP请求报文中的cookie首部行；
3. 客户端保留cookie文件，由用户浏览器进行管理；
4. 服务器端保留cookie到数据库。

2.5 Web 缓存 (Web Caching)

定义：Web 缓存（也叫代理服务器 proxy server）是一个网络实体，它能代表初始 Web 服务器来满足 HTTP 请求。
目标：在不涉及源服务器的情况下满足客户端请求。
工作原理：
1. 浏览器被配置为将所有 HTTP 请求首先发送到缓存器。
2. 如果缓存器中有被请求对象的副本，则直接返回给浏览器。
3. 如果没有，缓存器会代表浏览器向初始服务器请求该对象，接收后存入本地，同时返回给浏览器。
问：描述Web缓存器是如何减少接收被请求对象的时延的。Web缓存器将减少一个用户请求的所有对象或只是其中的某些对象的时延吗？为什么？

答：Web缓存器设置在用户和初始服务器之间，当用户要向初始服务器发起请求时，浏览器会先将请求定位到Web缓存器上，如果缓存器上有请求对象的副本则直接将该副本响应给客户。如果缓存器中没有，则从Web缓存器向初始服务器发起对该对象的请求，Web缓存器收到来自初始服务器的响应对象后，自己会保留一份该对象的副本，然后再响应给用户。因此，Web缓存器只能减少缓存过的对象的时延。
作用：
- 减少客户请求的响应时间：特别是当缓存器离客户很近（如在同一机构网络内）时。
- 减少一个机构的接入链路流量：节省带宽费用，并降低整个互联网的流量。
举例说明：

一个机构网络的用户以 15 请求/秒 的速度访问互联网资源（平均对象大小 100Kb），产生 1.5 Mbps 的出口流量。但其接入互联网的 接入链路带宽仅为 1.54 Mbps，导致：

接入链路利用率高达 99%，引发严重的网络拥堵。

总延迟极高，在 2 秒的互联网延迟基础上，增加了分钟级的排队延迟，用户体验极差。

方案一：升级带宽（昂贵）

方案：将接入链路带宽从 1.54 Mbps 提升至 154 Mbps。

结果：

利用率降至 0.9%，排队延迟消失。

总延迟降至约 2 秒。

结论：问题解决，但成本极高。

方案二：安装本地缓存（廉价高效）

方案：在内网部署缓存服务器，假设缓存命中率为 40%。

结果计算：

流量计算：仅 60% 的请求需要访问外网，出口流量降为 0.6 * 1.5 Mbps = 0.9 Mbps。

利用率计算：0.9 / 1.54 ≈ 58%。利用率从 99% 降至 58%，排队延迟大幅降低。

延迟计算：

缓存命中请求：延迟约几毫秒。

缓存未命中请求：延迟约 2.01 秒。

平均总延迟：0.4 * (~0秒) + 0.6 * (~2.01秒) ≈ 1.2 秒。

结论：以更低成本，将延迟从分钟级降至 约1.2秒，效果优于方案一。

2.6 条件 GET 方法 (Conditional GET)

目的：让缓存器能够验证其保存的对象副本是否是最新的，避免向客户端返回过时的内容。
机制：
- 缓存器在向初始服务器请求对象时，在请求报文中包含 If-Modified-Since: 首部行，其值为该副本在缓存器中的最后修改日期。
- 服务器检查对象在此日期后是否被修改过：
  - 如果没有修改，则发送一个响应报文，状态码为 304 Not Modified，且不包含对象主体。节省了带宽。
  - 如果已修改，则发送一个正常的 200 OK 响应报文，包含最新的对象。

总结

2.2 Web and HTTP 这一节系统地阐述了 HTTP 协议如何作为 Web 应用的基石工作。它从基本概念出发，逐步深入到连接管理、报文细节、状态跟踪（Cookie）、性能优化（缓存与条件GET）等关键技术和设计思想，完整地描绘了 Web 客户端与服务器交互的全貌。理解这些内容是掌握应用层协议设计原则的典范。

三、Electronic mail

电子邮件系统主要由三个核心组件构成，其总体结构和工作流程如上图所示。

用户代理 (User Agent, UA)：
- 用户与电子邮件系统的接口，即电子邮件客户端软件（如 Outlook、Thunderbird、手机上的邮件 App 或 Gmail 等网页界面）。
- 功能：允许用户撰写、阅读、回复、转发、保存邮件。
邮件服务器 (Mail Server)：
- 电子邮件系统的核心。每个接收方在某个邮件服务器上有一个邮箱 (Mailbox)，用于管理和维护发送给他的邮件。
- 邮件服务器维护一个报文队列 (Message Queue)，存放待发送的邮件。如果目标服务器暂时不可达，它会周期性地（如每30分钟）尝试重发。
邮件传输/访问协议：
- SMTP：用于邮件服务器之间发送（推，Push）邮件。
- POP3/IMAP：用于用户代理从邮件服务器读取（拉，Pull）邮件。

典型邮件发送流程（Alice 发送给 Bob）：

Alice 用她的 UA 撰写邮件并发送。
Alice 的 UA 将邮件发送到她的邮件服务器，邮件被放入报文队列。
Alice 邮件服务器上的 SMTP 客户端与 Bob 邮件服务器上的 SMTP 服务器端建立 TCP 连接（端口 25）。
SMTP 客户端通过该连接将 Alice 的邮件发送给 Bob 的邮件服务器。
Bob 的邮件服务器将邮件放入 Bob 的邮箱。
Bob 在方便时，用他的 UA 从邮件服务器读取邮件。

3.1 SMTP（简单邮件传输协议）

SMTP 是互联网电子邮件发送的核心应用层协议，用于从发送方邮件服务器推（Push）邮件到接收方邮件服务器。

3.1.1 核心特点

使用 TCP：在端口 25 上提供可靠的数据传输。
直接传输：一般不使用中间邮件服务器进行中继，而是直接从发送方服务器到接收方服务器。
三个阶段：连接建立（握手）、邮件传输（传输）、连接释放（关闭）。
命令/响应交互：与 HTTP 类似，使用命令和状态码进行交互（如 220, 250, 354）。
7-bit ASCII 限制：协议要求报文（首部和主体）必须使用 7-bit ASCII 码。这也是为什么需要 MIME 协议来支持附件和多媒体内容。

3.1.2 SMTP 交互示例

举一个具体的SMTP交互例子：

Alice uses UA to compose message “to” bob@someschool.edu.
Alice’s UA sends message to her mail server; message placed in message queue.
Client side of SMTP opens TCP connection with Bob’s mail server.
SMTP client sends Alice’s message over the TCP connection
Bob’s mail server places the message in Bob’s mailbox.
Bob invokes his user agent to read message.

以下是一个以命令行形式给出的典型的 SMTP 会话过程：

 S: 220 hamburger.edu          // 服务器就绪C: HELO crepes.fr             // 客户端问候S: 250 Hello crepes.fr, pleased to meet youC: MAIL FROM: <alice@crepes.fr>  // 声明发件人S: 250 ... Sender okC: RCPT TO: <bob@hamburger.edu>  // 声明收件人S: 250 ... Recipient okC: DATA                       // 开始传输数据S: 354 Enter mail, end with "." on a line by itselfC: Do you like ketchup?       // 邮件正文C: How about pickles?C: .                          // 以单独一行的 "." 结束正文S: 250 Message accepted for deliveryC: QUIT                       // 退出S: 221 hamburger.edu closing connection

3.1.3 SMTP 与 HTTP 的对比

特性	SMTP	HTTP
通信模式	推 (Push)	拉 (Pull)
数据格式	7-bit ASCII（严格限制）	不受限制，可传输任意数据
报文封装	多个对象（如文本、附件）可在一个报文中发送	每个对象封装在独立的响应报文中
连接方式	持久连接	持久/非持久连接

3.2 邮件访问协议：POP3 与 IMAP

SMTP 负责将邮件交付到接收方的邮件服务器。但用户如何从邮件服务器读取邮件呢？这需要使用邮件访问协议，因为 SMTP 是一个“推”协议，而读取邮件是一个“拉”操作。

3.2.1 POP3（邮局协议版本 3）（Post Office Protocol）[RFC 1939]

POP3 是一个非常简单的协议，用于将邮件从服务器下载到用户的本地计算机。

工作流程：
1. 认证阶段：客户端使用 USER 和 PASS 命令进行登录。
2. 事务阶段：客户端可以执行以下操作：
  - LIST：列出邮件列表和大小。
  - RETR：检索（下载）特定编号的邮件。
  - DELE：删除服务器上的邮件。
两种模式：
- “下载并删除”模式：邮件被下载到本地后，从服务器上删除。缺点：用户不能从另一台设备再次访问该邮件。
- “下载并保留”模式：邮件下载后，在服务器上保留副本。允许用户从多个设备访问邮件。
特点：无状态协议。服务器不会维护用户对邮件的操作状态（如已读、移动文件夹等）。

3.2.2 IMAP（因特网邮件访问协议）（Internet Mail Access Protocol） [RFC 1730]

IMAP 比 POP3 功能更强大，它将邮件服务器视为一个远程文件系统。

核心思想：所有邮件及其状态都永久保存在服务器上。
关键特性：
1. 状态维护：IMAP 服务器会维护用户操作的状态，例如哪些邮件已读、已回复、已删除，以及用户创建的文件夹结构。
2. 联机操作：用户代理就像是服务器的远程终端。用户可以在服务器上直接管理邮件（移动、删除、创建文件夹）。
3. 允许只获取部分内容：例如，可以先只下载邮件首部（主题、发件人）进行预览，然后再决定是否下载整个邮件或附件，节省时间和带宽。
优势：用户可以在任何地方、使用任何设备访问完整的邮件状态和归档。
缺点：用户需要始终与服务器保持连接以进行操作。

以下是一个邮件服务器之间的通信的例子：

3.3 基于 Web 的电子邮件

如今许多电子邮件服务（如 Gmail、Hotmail、Yahoo! Mail等）采用基于 Web 的架构。

通信模式：
- 用户代理与邮件服务器之间使用 HTTP（通过浏览器）。
- 邮件服务器之间仍然使用 SMTP。
优势：用户无需安装专门的邮件客户端，在任何能上网的地方都能通过浏览器访问邮箱。

总结

协议	角色	通信方向	特点
SMTP	邮件服务器到邮件服务器	推 (Push)	使用 TCP，端口 25，7-bit ASCII，命令/响应交互
POP3	用户代理从邮件服务器	拉 (Pull)	简单，无状态，主要功能是下载和删除/保留邮件
IMAP	用户代理从邮件服务器	拉 (Pull)	复杂，有状态，在服务器上管理邮件，支持多设备同步
HTTP	(用于 Webmail) 用户代理与邮件服务器	拉/推	通过浏览器访问，方便快捷

这三个协议（SMTP, POP3, IMAP）与用户代理、邮件服务器共同协作，构成了现代互联网电子邮件系统的基石。

问：为什么HTTP、SMTP及POP3都运行在TCP，而不是UDP上？

答：首先要知道TCP几个重要的特性，即面向连接, 保证数据完整性, 保证数据有序到达, 有拥塞控制功能. 而上述功能UDP都没有。再来看HTTP, 用户通过浏览器以HTTP协议向服务器发起请求, 如果这个请求数据不完整, 服务器将无法给出正确响应, 用户也得不到想要的结果。 SMTP和POP3两个邮件协议也需要保证数据的完整性, 并且要保证按照一定的顺序交付, 所以选择TCP。

四、DNS（域名系统）

DNS是互联网的核心基础设施之一，其作用类似于一个巨大的、分布式的电话簿。

4.1 DNS 提供的服务与核心概念

1. 为什么需要 DNS？

互联网主机有两种标识方式：

主机名（Hostname）：如 www.google.com。对人类友好，易于记忆，但不提供位置信息，且长度可变，路由器难以处理。
IP 地址（IP Address）：如 142.250.190.78。定长的、具有层次结构的数字，便于路由器处理，但对人类不友好。

DNS 的主要任务就是在这两种标识之间进行转换：将主机名解析为对应的 IP 地址。

2. DNS 的关键服务

主机名到 IP 地址的转换：这是最核心的功能。
主机别名（Host Aliasing）：一台主机可以有多个别名。例如，主机 relay1.west-coast.enterprise.com 可能有两个别名：enterprise.com 和 www.enterprise.com。DNS 可以返回规范主机名（Canonical Hostname）及其 IP 地址。
邮件服务器别名（Mail Server Aliasing）：电子邮件地址（如 alice@yahoo.com）中的域名同样需要解析。DNS 中的 MX 记录 专门用于将邮件服务器别名映射为规范主机名及其 IP 地址。
负载分配（Load Distribution）：一个繁忙的网站（如 cnn.com）通常由多台服务器托管，每个服务器有不同的 IP 地址。DNS 数据库中可以为一个主机名存储多个 IP 地址。当客户端查询时，DNS 服务器会轮询（Round-robin） 返回这些 IP 地址的顺序，从而将访问请求分布到不同的服务器上，实现负载均衡。

4.2 DNS 的工作机理：一种分布式、层次化的数据库

DNS 的设计非常精妙，它没有采用单一的、集中式的数据库，因为那会存在单点故障、流量集中、延迟巨大、维护困难等问题。

4.2.1 DNS 的层次化结构

DNS 使用了大量的 DNS 服务器，以层次方式组织，形成一个巨大的分布式数据库。这种层次结构类似于文件系统的目录树。

根域名服务器（Root DNS Servers）：层次结构的最高层。全球有 13 个逻辑根服务器（每个逻辑根由分布在全球的多个物理服务器集群构成）。它知道所有顶级域（TLD）服务器的地址。
顶级域域名服务器（Top-Level Domain, TLD Servers）：负责管理像 .com, .org, .net, .edu 这样的通用顶级域，以及像 .cn, .uk 这样的国家代码顶级域。它知道管理这些域名的权威服务器的地址。
权威域名服务器（Authoritative DNS Servers）：每个组织（如大学、公司）都至少有一个权威服务器，用于提供其管辖范围内（如 google.com）主机名到 IP 地址的权威映射。这些服务器通常由组织自身或服务提供商管理。

此外，还有一个不属于层次结构但至关重要的服务器：

本地域名服务器（Local DNS Server / Default Name Server）：也称为递归解析器（Recursive Resolver）。每个 ISP（如家庭宽带、大学网络）都有一个本地 DNS 服务器。当主机发出 DNS 查询请求时，该请求首先被发送到本地 DNS 服务器。它充当了代理（Proxy）的角色，代替主机在 DNS 层次结构中完成查询。

4.2.2 DNS 查询的两种方式

迭代查询	递归查询

示例场景：主机 cis.poly.edu 想获取 gaia.cs.umass.edu 的 IP 地址。

a) 迭代查询（Iterative Query）

过程：
1. 主机向其本地 DNS 服务器发送递归查询。
2. 本地 DNS 服务器向根服务器发送迭代查询。
3. 根服务器返回它所知的 .edu TLD 服务器的地址。
4. 本地 DNS 服务器向 .edu TLD 服务器发送迭代查询。
5. TLD 服务器返回管理 umass.edu 的权威服务器的地址。
6. 本地 DNS 服务器向 umass.edu 的权威服务器发送迭代查询。
7. 权威服务器返回 gaia.cs.umass.edu 的 IP 地址。
8. 本地 DNS 服务器将最终结果返回给主机。
特点：被查询的服务器（如根、TLD）不直接去查找答案，而是告诉查询者“下一步应该去问谁”。查询负担主要在本地 DNS 服务器上。

b) 递归查询（Recursive Query）

过程：
1. 主机向其本地 DNS 服务器发送递归查询。
2. 本地 DNS 服务器向根服务器发送递归查询。
3. 根服务器承担起查询责任，它向 .edu TLD 服务器发送查询，并等待结果。
4. TLD 服务器再向权威服务器发送查询。
5. 权威服务器将 IP 地址返回给 TLD 服务器。
6. TLD 服务器将结果返回给根服务器。
7. 根服务器将最终结果返回给本地 DNS 服务器。
8. 本地 DNS 服务器将结果返回给主机。
特点：被查询的服务器（如根、TLD）代表查询者完成整个查询过程。查询负担被转移到上层服务器，这在实践中会给根服务器带来巨大压力，因此根服务器通常只执行迭代查询。

实际中的混合查询：最常见的模式是 “递归-迭代”混合查询。

主机向本地 DNS 服务器发出递归查询。
本地 DNS 服务器依次向根、TLD、权威服务器发出迭代查询。
本地 DNS 服务器将最终结果递归地返回给主机。

4.3.3 DNS 缓存与 TTL

为了极大提升效率并减少 DNS 流量，DNS 广泛使用了缓存（Caching） 机制。

工作原理：一旦某个 DNS 服务器（尤其是本地 DNS 服务器）学习到一个主机名的映射，它就会将该映射缓存一段时间。
生存时间（TTL）：每个缓存记录都有一个生存时间，过期后会被丢弃。
好处：
- 减少延迟：后续对相同主机名的查询可以直接从缓存中获取答案，无需再次遍历整个层次结构。
- 减少网络流量：减少了向上级服务器的查询次数。
- 减轻根服务器压力：由于 TLD 服务器的地址经常被缓存，对根服务器的查询大大减少。

4.3 DNS 记录和报文

DNS 分布式数据库存储的是资源记录（Resource Records, RR）。

4.3.1 DNS 资源记录格式

每个 RR 是一个包含以下字段的四元组：(Name, Value, Type, TTL)

TTL 决定记录的生存时间。
Type 决定了 Name 和 Value 的含义。最重要的类型有：

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

注意：MX 记录允许邮件服务器主机名与 Web 服务器等其他服务的主机名不同。而 NS 和 MX 记录中的 Value 字段是一个主机名，为了找到该主机名的 IP 地址，通常还需要一条对应的 A 记录。

4.3.2 DNS 报文格式

DNS 查询和响应报文采用相同的格式，如下图所示）： DNS 报文主要包含以下字段：

首部区域（Header）：
- 标识符（identification）（16位）：用于匹配查询和响应。
- 标志位（Flags）：包含若干重要信息，如：
  - 查询/响应（QR）：0 表示查询，1 表示响应。
  - opcode：定义查询或响应的类型(若为0则表示是标准的，若为1则是反向的，若为2则是服务器状态请求)。
  - 权威回答（AA）：1 表示响应来自权威服务器。
  - TC：截断标志位，1表示响应已超过512字节并已被截断（这个截断和UDP有关)
  - 递归期望（RD）：1 表示客户端希望服务器递归查询。
  - 递归可用（RA）：1 表示服务器支持递归查询。
  - zero：0，保留字段。
  - 返回码（Rcode）：表示响应状态（如 0=无错误，3=名字错误）。
问题区域（Question Section）：包含正在进行的查询信息（查询名、查询类型）。
回答区域（Answer Section）：包含对查询的资源记录（RR）。
权威区域（Authority Section）：包含其他权威服务器的记录。
附加信息区域（Additional Section）：包含其他可能有用的记录（如 MX 记录中对应的 A 记录）。

4.4 DNS 的安全性

DDoS 攻击：向根服务器或 TLD 服务器发送大量流量。
重定向攻击/中间人攻击：向 DNS 服务器发送伪造的响应，将用户引导到恶意网站（DNS 欺骗/缓存投毒）。

总结

DNS 是一个设计极其精妙的系统，它通过分布式、层次化的架构解决了互联网规模下的名字解析问题，并通过缓存机制和高效的查询策略保证了其高性能和高可用性。它是互联网能够“以人为中心”顺畅运行的关键所在。

五、P2P applications

P2P（对等）架构是应用层两大核心架构之一，与客户-服务器（C/S）架构形成鲜明对比。本节重点阐述了 P2P 的核心思想、优势，并通过文件分发和 BitTorrent 案例进行了深入分析。

5.1 P2P 架构的核心思想与特点

1. 核心思想

去中心化：P2P 应用不依赖（或最小化依赖）总是打开的核心服务器。
对等直接通信：应用程序在间歇性连接的主机（称为对等方，Peers） 之间使用直接通信。
自服务：每个对等方在消费服务（如下载文件）的同时，也为其他对等方提供服务（如上传文件）。

2. 与 C/S 架构的对比

特性	客户-服务器 (C/S) 架构	对等 (P2P) 架构
服务器	需要强大的、总是打开的中央服务器	没有总是打开的核心服务器
资源位置	资源集中在服务器上	资源分散在对等方之间
扩展性	服务器可能成为瓶颈，难以扩展	高度可扩展，新对等方加入带来新能力
成本	服务器基础设施和带宽成本高	成本效益高，利用对等方的资源
管理/安全	易于管理，安全性相对可控	管理复杂，安全性挑战大

P2P 架构最引人人胜的特性是其自扩展性（Self-scalability）。在文件共享应用中，每个对等方在请求文件时产生工作负载，但同时也通过为其他对等方分发文件内容而增加了系统的服务能力。

5.2 P2P 文件分发：一个量化的优势

通过一个严谨的数学模型，对比 C/S 和 P2P 架构在分发一个大文件给大量用户时所需的时间。

场景设定：

一个服务器拥有一个大小为 F 比特的文件。
有 N 个客户端（对等方）想要获取该文件。
服务器上传速率为 u_s，每个对等方的上传速率为 u，下载速率为 d（且 d 通常远大于 u）。

A. 客户-服务器架构的分发时间

在 C/S 模式下，服务器必须将文件的每个比特发送给每个客户端。

服务器发送：服务器需要传输 $N \times F$ 比特。其上传能力是瓶颈，时间至少为 $NF/u_s$ 。
最慢客户端下载：最慢的客户端下载文件需要时间 $F/d_{\min}$ 。因此，C/S 架构的分发时间 $D_{cs}$ 受限于两者中的最大值： $D_{cs} \geq \max \left\{ \frac{NF}{u_s}, \frac{F}{d_{\min}} \right\}$ 结论：分发时间 $D_{cs}$ 随着客户端数量 N 线性增长。当 N 非常大时，服务器上传链路将成为严重瓶颈。

B. P2P 架构的分发时间

在 P2P 模式下，文件的分发来源是多元的：不仅来自服务器，也来自已经下载了文件部分或全部内容的其他对等方。

服务器发送：服务器至少需要发送一个完整的文件副本，时间至少为 $F/u_s$ 。
最慢客户端下载：最慢的客户端下载时间仍为 $F/d_{\min}$ 。
系统总上传能力：这是关键点。整个系统必须合力上传 NF 比特的总数据。系统的总上传能力是服务器的上传速率加上所有 N 个对等方的上传速率之和，即 $u_s + \sum u_i \approx u_s + Nu$ （假设对等方上传速率相同）。因此，总上传时间受限于 $NF/(u_s + Nu)$ 。

因此，P2P 架构的分发时间 $D_{P2P}$ 受限于以下三个因素的最大值： $D_{P2P} \geq \max \left\{ \frac{F}{u_s}, \frac{F}{d_{\min}}, \frac{NF}{u_s + Nu} \right\}$ 结论：随着 N 的增加，公式中的第三项 $NF/(u_s + Nu)$ 会趋近于 $F/u$ （一个常数），而不会无限增长。因此，P2P 架构的分发时间随着用户数量的增长，其增长速度远低于 C/S 架构。这正是 P2P 自扩展性的数学体现。

示例：假设 $F/u = 1$ 小时， $u_s = 10u$ 。当 N 增大到 1000 时，C/S 架构需要几千小时，而 P2P 架构仅需几小时，优势极其明显。

2.5.3 BitTorrent：一个成功的 P2P 文件分发协议

BitTorrent 是 P2P 思想最成功和著名的实践之一。

1. 核心概念

洪流（Torrent）：参与一个特定文件分发的所有对等方的集合。
文件块（Chunks）：文件被划分为多个较小的数据块（如 256KB），对等方之间交换的是这些块。
追踪器（Tracker）：每个洪流有一个基础设施节点，它不存储文件本身，但跟踪记录当前参与该洪流的所有对等方的 IP 地址。新对等方加入时，首先联系追踪器获取对等方列表。

2. 对等方加入与文件交换

加入：新对等方 Alice 联系追踪器 Tracker，获得一个参与对等方的子集列表。
建立连接：Alice 尝试与列表中的对等方建立 TCP 连接。这些相邻的对等方称为"邻居"。
交换块：Alice 周期性地向每个邻居询问他们拥有哪些块（请求块列表）。然后，她请求她所缺失的块。
- 最稀缺优先（Rarest First）：在请求缺失块时，Alice 会优先请求在邻居中副本数量最少的块。这有助于快速增加稀有块的分布，提高系统健壮性。
上传策略：一报还一报（Tit-for-Tat）
- 这是 BitTorrent 的核心激励机制，旨在惩罚"只下载不上传"的自私者，鼓励合作。
- 原则：Alice 持续测量所有邻居向她发送数据的速率。她总是优先为当前向她提供数据速率最高的前 4 个邻居提供服务（即上传块给它们）。
- 定期评估：每 10 秒重新评估这 4个"已疏通"（Unchoked）的邻居。
- 乐观疏通（Optimistic Unchoking）：每 30 秒，Alice 会随机选择一个不在 top 4 中的邻居进行"乐观疏通"，即也向其上传数据。
  - 目的：发现那些可能成为新的优质合作伙伴的对等方（例如，对方刚加入，尚未开始上传，但有能力）。如果这个被乐观疏通的对等方向 Alice 提供了良好的下载速率，它就有可能在下次评估中进入 top 4。

3. 激励机制的效果

这种"一报还一报"的策略创造了一个"善有善报"的环境：一个对等方的上传速率越高，它就越有可能从其他对等方那里获得更快的下载速率，从而更快地完成文件下载。

总结

P2P 应用架构的核心优势在于其去中心化和自扩展性。通过让终端用户（对等方）在消费服务的同时也贡献资源，它巧妙地解决了 C/S 架构中服务器的瓶颈问题。BitTorrent 作为 P2P 的典范，通过文件分块、追踪器协调、最稀缺优先的请求策略以及一报还一报的激励机制，高效地实现了大规模文件的快速分发，展示了 P2P 模式在实践中的强大生命力。

六、Video Streaming and Content Distribution Networks (CDNs)（了解）

本节阐述了互联网视频分发的核心挑战以及现代解决方案：HTTP流媒体、DASH和内容分发网络（CDN）。

6.1 互联网视频的挑战

视频流量是互联网带宽的主要消费者（如Netflix、YouTube）。分发视频面临两大核心挑战：

规模性（Scale）：
- 如何将视频内容（尤其是热门内容）分发给全球数亿用户？
- 单一大型服务器（Mega-Server）方案不可行：它会成为单点故障、网络拥塞的瓶颈，并且对远距离用户延迟高，无法扩展。
异构性（Heterogeneity）：
- 用户设备多样（手机、平板、电视），网络环境不同（高速Wi-Fi、移动网络），其带宽和处理能力差异巨大。
- 解决方案需要能动态适应不同用户的网络条件。

解决方案：采用分布式的、应用层的基础设施，即内容分发网络（CDN） 结合自适应的流媒体协议（如DASH）。

6.2 视频编码与流媒体

1. 视频编码基础

视频是由一系列图像（帧）组成的，以恒定速率播放（如24/30帧/秒）。
每张数字图像是像素阵列。为减少传输数据量，视频会进行压缩编码，利用两种冗余：
- 空间冗余（Spatial Coding）：压缩单帧图像内相邻像素的冗余信息（例如，一大片蓝色天空）。
- 时间冗余（Temporal Coding）：压缩连续帧之间的冗余信息（例如，背景不变，只编码运动物体的变化）。
码率（Bit Rate）：
- 固定码率（CBR）：编码速率固定。
- 可变码率（VBR）：编码速率随场景复杂度变化（动作场景码率高，静态场景码率低）。

2. 从简单流媒体到DASH

简单场景：客户端直接从视频服务器顺序下载并播放视频文件。
问题：如果网络带宽波动，会导致卡顿（缓存数据用完） 或重新缓冲。
解决方案：DASH（Dynamic Adaptive Streaming over HTTP，基于HTTP的动态自适应流媒体）

3. DASH 的工作原理

DASH是一种智能的客户端驱动流媒体技术。

服务器端准备：
1. 将视频文件分割成多个小片段（Chunks），每个片段包含几秒钟的视频。
2. 将每个片段编码成多种不同的码率/分辨率版本（如480p, 720p, 1080p, 4K）。
3. 创建一个清单文件（Manifest File），该文件为每个视频片段提供所有不同码率版本的URL。
客户端智能控制：
1. 客户端首先下载并解析清单文件。
2. 周期性地测量从服务器到客户端的可用带宽。
3. 逐个片段地请求视频数据。对于下一个要请求的片段，客户端根据当前测量的可用带宽，从清单文件中选择最合适的码率版本。
  - 带宽好时，选择高码率（高清）版本。
  - 带宽差时，选择低码率（流畅）版本。
4. 这种选择是动态的，在整个播放过程中会根据网络状况实时调整，以提供尽可能平滑的观看体验。

DASH的优势：

智能在客户端：客户端自行决定请求哪个版本，服务器只需简单地存储和提供文件，无需管理复杂会话状态。
适应性强：能很好地应对网络拥塞和波动。
基于HTTP：可以轻松通过防火墙和缓存（如CDN缓存）。

6.3 内容分发网络（CDN）

CDN是应对视频分发规模性挑战的核心技术。

1. CDN的概念

CDN公司在全球各地部署了大量缓存服务器（CDN节点），将视频等内容提前缓存到离用户更近的地方。

2. CDN的两种部署策略

深入部署（Enter Deep）：
- 将CDN服务器集群部署到尽可能多的接入网中（如大学、住宅ISP内部）。
- 目标：极度靠近终端用户。
- 代表：Akamai（拥有全球数十万台服务器）。
邀请入驻（Bring Home）：
- 在较少的关键位置（如互联网交换中心IXP）部署较大规模的服务器集群。
- 目标：在区域层面靠近用户群。
- 代表：Limelight。

3. CDN的工作流程案例

以下案例说明了用户观看视频《Mad Men》时CDN的工作流程：

视频托管：Netflix将《Mad Men》的视频文件上传到CDN提供商（如Akamai）的服务器上。
用户请求：用户Bob在Netflix网站上点击播放《Mad Men》。
DNS重定向（关键步骤）：
- Bob的浏览器需要获取视频数据。视频URL可能是 http://netcinema.com/6Y7B23V。
- Bob的本地DNS服务器会查询 netcinema.com 的权威DNS服务器。
- Netcinema的权威DNS服务器不直接返回视频服务器的IP，而是返回一个重定向的URL，如 http://kingcdn.com/NetC6y&B23V。这个URL指向了CDN网络。
- 接着，通过查询 kingcdn.com 的权威DNS（由CDN管理），CDN的DNS系统会智能地将Bob引导到离他网络位置最近、负载较轻的CDN节点服务器，并返回该服务器的IP地址。
直接获取内容：Bob的浏览器直接从这个最近的CDN节点请求视频片段，享受高速、低延迟的播放体验。

4. CDN集群选择策略

CDN如何为用户选择“最佳”的集群节点？常用方法包括：

基于DNS：如上述案例，根据用户本地DNS服务器的IP地址的地理位置进行判断。
实时探测：让用户从少量候选节点下载一个测量文件，选择响应最快的节点。

6.4 案例研究：Netflix

Netflix是一个典型的OTT（Over-The-Top）服务案例。

内容准备：Netflix将视频内容上传到云存储（如Amazon S3）。
内容处理与分发：使用云计算服务进行编码、格式转换，然后分发给CDN（Netflix有自己的专用CDN——Open Connect）。
用户交互：
- 用户与Netflix的Web服务器交互（管理账户、浏览影片）。
- 当用户播放视频时，客户端会收到一个清单文件（Manifest File）。
- 客户端根据DASH原理，直接从最近的CDN节点请求视频片段。

OTT（Over-The-Top）服务：指像Netflix、Skype这样的服务，它们在网络运营商提供的基础网络之上直接为用户提供应用服务。网络运营商更像是“管道”，不参与具体服务内容的提供。

总结

视频流媒体和CDN共同解决了互联网视频分发的核心难题：

CDN 通过地理分布式的缓存节点解决了规模性问题，将内容推送到网络边缘，降低延迟，减少骨干网压力。
DASH 通过客户端自适应的码率选择解决了异构性问题，使流媒体能够智能适应复杂多变的网络环境。

两者结合（CDN存储多版本视频文件，客户端通过DASH协议从CDN获取内容）构成了现代互联网高质量视频点播服务的基石。

七、Socket Programming with UDP and TCP

7.1 应用进程通信方式

这部分内容解释了网络应用的本质和基本模型，是理解后续所有协议和编程实践的前提。

7.1.1 网络通信的本质：进程间的通信

计算机网络中通信的真正实体是应用进程。

纠正一个常见误解：我们常说“主机A和主机B在通信”，这种说法并不精确。更准确的说法是：运行在主机A上的某个应用进程与运行在主机B上的另一个应用进程在进行通信。
例如：当我们用浏览器访问百度时，是我们电脑上的浏览器进程正在与百度服务器上的Web服务器进程（如Nginx、Apache） 进行通信。

7.1.2 网络应用体系结构

应用程序在端系统上组织起来进行通信的方式，决定了其应用体系结构。文档主要介绍了三种主流的体系结构：

CS架构	BS架构	P2P架构

A. 客户-服务器体系结构（CS架构）

核心特征：有一个总是打开的主机，称为服务器，它服务于来自许多其他称为客户的主机的请求。
服务器特点：
- 永久性：具有永久、公开的IP地址。
- 高性能：通常位于强大的数据中心，具备强大的计算和带宽能力。
- 被动性：持续运行，被动地等待并响应客户的请求。
客户特点：
- 间歇性：可能间歇性地与网络连接，IP地址可能动态获取。
- 主动性：主动向服务器发起通信会话。
- 彼此不直接通信：客户之间不直接通信，所有通信都通过服务器中转。
典型例子：Web、FTP、电子邮件、网上银行等。

BS架构可以看成CS架构的一个特例，B/S方式通常采取3层架构实现：

数据层：由数据库服务器承担数据处理逻辑，其任务是接受Web服务器对数据库服务器提出的数据操作请求，然后由数据库服务器进行数据处理并把处理结果返回给web服务器

处理层：由Web服务器承担业务处理逻辑和页面存储管理，接受客户浏览器的任务请求，执行相应的事务处理

表现层：浏览器仅承担网页信息的浏览功能, 以超文本格式实现信息的输入和浏览

（实际部署时也可以把数据库服务器和web服务器部署在同一台设备上）

BS架构的特点是：

界面统一，使用简单。客户端只需要安装浏览器软件

易于维护。对应用系统升级时，只需更新服务器端的软件，减轻了系统维护和升级的成本

可扩展性好。采用标准的TCP/IP和HTTP协议，具有良好的扩展性

信息共享度高。HTML是数据格式的一个开放标准，目前大多数流行的软件均支持HTML

需要注意的是，在一种浏览器环境下开发的界面在另一种浏览器环境下可能有不完全适配的情况，这时需要安装对应的浏览器

B. 对等体系结构

核心特征：最小化或完全不再需要总是打开的服务器。应用程序在间断连接的主机对（称为对等方，Peers）之间使用直接通信。
自扩展性：对等方在消费服务的同时也为系统贡献资源（如带宽、存储空间、计算能力）。新对等方的加入不仅增加服务需求，也增加了服务能力。
挑战：管理复杂、安全性较差（难以控制）。
典型例子：文件共享（如BitTorrent）、P2P流媒体、即时通讯等。

C. 客户-服务器与P2P混合体系结构

结合两者的优点，以平衡“集中管理”和“高效传输”。
常见模式：以C/S架构作为核心管控层，P2P架构作为分布式传输层。
- 管控层（C/S）：服务器负责用户认证、资源索引、权限控制等需要中心化管理的功能。
- 传输层（P2P）：一旦认证通过，实际的数传输（如下载大文件）在用户终端之间直接进行，减轻服务器负担，提高效率。
典型例子：迅雷下载、腾讯微云等。服务器只提供文件元数据（如有哪些分块、在哪），实际数据块通过用户节点间的P2P网络分发。

7.2 服务器进程的工作方式

在确定了C/S或混合体系结构后，服务器端如何高效地处理来自多个客户的并发请求，是下一个关键问题。

7.2.1 循环方式

工作模式：服务器一次只处理一个客户请求。当有多个请求到达时，它们在一个队列中排队，服务器按顺序处理。
特点：
- 简单易实现。
- 效率低。如果当前请求处理缓慢，后续所有请求都必须等待，无法实现并发。
适用场景：通常与无连接的运输协议（如UDP）配合使用。

举例：无连接循环方式服务
- 使用无连接的UDP服务进程通常都工作在循环方式，即一个服务进程在同一时间只能向一个客户进程提供服务。(顺序服务)
- 服务进程收到客户进程的请求后，就发送UDP用户数据报响应该客户
- 对其他客户进程发来的请求则暂时不予理睬，这些请求都在服务端的队列中排队等候服务进程的处理
- 当服务进程处理完毕一个请求时，就从队列中读取来自下一个客户进程的请求，然后继续处理

7.2.2 并发方式

工作模式：服务器可以同时处理多个客户请求。
实现机制（以面向连接的TCP为例）：
1. 存在一个主服务器进程，在熟知端口上运行，被动等待连接请求。
2. 当有客户请求连接时，主进程创建一个新的从属进程（或线程） 来处理这个特定客户的请求。
3. 主进程立即返回，继续在熟知端口上监听新的连接请求，而新创建的从属进程负责与对应的客户进行后续的所有数据交换。
特点：
- 高效，可同时服务多个客户。
- 实现相对复杂。
适用场景：必须与面向连接的运输协议（如TCP）配合使用。

举例：面向连接的并发方式服务
- 面向连接的TCP服务进程通常都工作在并发服务方式，服务进程在同一时间可同时向多个客户进程提供服务。(并发服务)
- 在TCP服务进程与多个客户进程之间必须建立多条TCP连接，每条TCP连接在其数据传送完毕后释放
- 一个TCP连接对应一个（熟知）服务端口
- 主服务进程在熟知端口等待客户进程发出的请求。一旦收到客户的请求，就创建一个从属服务进程，并指明从属服务进程使用临时套接字与该客户建立TCP连接，然后主服务进程继续在原来的熟知端口等待向其他客户提供服务

类比理解：

循环方式 就像银行只有一个柜台，大家排一队，一个一个办理业务。
并发方式 就像银行有多个柜台（从属进程），一个接待员（主进程）在门口引导客户到空闲的柜台，从而实现同时为多人服务。

7.3 Socket 核心概念

本节是应用层学习的实践环节，旨在说明如何利用传输层提供的服务（Socket接口）来实际编写网络应用程序。Socket（套接字）是应用进程与操作系统传输层协议之间的编程接口（API），是网络应用程序的基石。

7.3.1 什么是 Socket？

一个Socket 形象的比喻是进程与网络之间的“门”。

发送进程将报文推过这扇“门”。
发送进程依赖“门”另一侧的运输基础设施将报文传送到接收进程的“门”。
接收进程通过其“门”接收报文并进行处理。
位置：Socket 位于应用层和传输层之间，是应用程序控制网络通信的端点。

7.3.2 两种主要的 Socket 类型

传输层提供两种主要服务，对应两种 Socket：

UDP Socket：对应无连接、不可靠的数据报服务。通信前无需握手。
TCP Socket：对应面向连接、可靠的字节流服务。通信前需建立 TCP 连接。

下面具体说明两个 Socket类型，统一使用以下例子：

客户端-服务器大写转换服务

客户端：从键盘读取一行字符串，并通过网络发送给服务器。
服务器：接收该字符串，将其转换为大写字母。
服务器：将修改后的字符串发送回客户端。
客户端：接收并显示修改后的字符串。

7.3.2.1 UDP Socket 编程

UDP 提供无连接服务。发送方在发送每个报文时，必须显式指定目的地的 IP 地址和端口号。

1. UDP 通信流程

客户端流程：

创建客户端 Socket。
构造服务器地址（IP 和端口号）。
将字符串发送到该地址。
等待并接收服务器的回复。
打印回复并关闭 Socket。

服务器端流程：

创建服务器 Socket，并将其绑定（Bind） 到一个众所周知的端口号。
进入无限循环，等待接收来自客户端的数据报。
收到数据报后，处理数据（转换为大写）。
从接收到的数据报中提取客户端地址，并将处理后的数据发送回该地址。

2. Python 代码示例分析

UDP 客户端

 from socket import *  # 导入 socket 库serverName = 'hostname'  # 服务器主机名或IP地址serverPort = 12000      # 服务器端口号# 创建客户端Socket。AF_INET表示IPv4，SOCK_DGRAM表示UDPclientSocket = socket(AF_INET, SOCK_DGRAM)message = raw_input('Input lowercase sentence:')  # 获取用户输入# 将消息发送到指定的服务器和端口。需要将字符串编码为字节clientSocket.sendto(message.encode(), (serverName, serverPort))# 接收来自服务器的回复。2048是缓冲区大小modifiedMessage, serverAddress = clientSocket.recvfrom(2048)print(modifiedMessage.decode())  # 打印回复，解码字节为字符串clientSocket.close()             # 关闭Socket

UDP 服务器

 from socket import *serverPort = 12000# 创建服务器SocketserverSocket = socket(AF_INET, SOCK_DGRAM)# 将Socket绑定到本地地址和端口号''表示监听所有网络接口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)# 注意：此服务器循环不会关闭Socket

UDP 特点小结：

无连接：每个数据报独立发送，需附带目标地址。
可能丢失、乱序：应用程序需处理可靠性问题。
速度快：无连接建立开销。

7.3.2.2 TCP Socket 编程

TCP 提供面向连接的可靠字节流服务。通信前必须在客户端和服务器之间建立一条 TCP 连接。

1. TCP 通信流程

服务器端（先运行）流程：

创建一个欢迎Socket（Welcome Socket），绑定到特定端口，并开始监听（Listen） 连接请求。
当客户端请求连接时，调用 accept() 方法。该方法阻塞，直到有客户端连接。
客户端连接时，accept() 返回一个新的专用连接Socket（Connection Socket），用于与该特定客户端通信。欢迎Socket继续监听新的连接。
通过连接Socket与客户端进行双向数据交换（读/写）。
通信结束后，关闭连接Socket。

客户端流程：

创建客户端 Socket，并发起连接（Connect） 到服务器。
连接建立后，通过 Socket 进行双向数据交换（发送/接收）。
通信结束后，关闭Socket，从而关闭连接。

2. Python 代码示例分析

TCP 客户端

 from socket import *serverName = 'servername'serverPort = 12000# 创建客户端Socket。SOCK_STREAM表示TCPclientSocket = socket(AF_INET, SOCK_STREAM)# 主动发起与服务器的连接clientSocket.connect((serverName, serverPort))sentence = raw_input('Input lowercase sentence:')# 发送数据。注意：TCP不需要指定目标地址，因为连接已建立clientSocket.send(sentence.encode())# 接收服务器发回的数据modifiedSentence = clientSocket.recv(1024)print('From Server:', modifiedSentence.decode())clientSocket.close()  # 关闭连接

TCP 服务器

 from socket import *serverPort = 12000# 创建欢迎SocketserverSocket = socket(AF_INET, SOCK_STREAM)# 绑定端口serverSocket.bind(('', serverPort))# 开始监听，参数1表示最多允许1个连接在队列中等待acceptserverSocket.listen(1)print('The server is ready to receive')while True:# 等待客户端连接。connectionSocket是用于通信的新Socket，addr是客户端地址connectionSocket, addr = serverSocket.accept()# 从连接Socket读取数据sentence = connectionSocket.recv(1024).decode()# 处理数据capitalizedSentence = sentence.upper()# 通过连接Socket发送数据回客户端connectionSocket.send(capitalizedSentence.encode())# 关闭与该客户端的连接Socket，但欢迎SocketserverSocket仍然开放connectionSocket.close()

TCP 特点小结：