【USTC 计算机网络】第二章：应用层 - P2P、CDN

本文首先介绍了网络架构中的另一大模式：P2P，主要介绍了结构化 P2P 与非结构化 P2P，以及如何通过集中式目录或查询洪泛方法查找资源，接着介绍了流媒体传输技术 DASH 与内容分发网络 CDN，通过 CDN 能够实现快速、稳定、安全内容传输的网络架构。

1. P2P

1.1 介绍

之前所介绍的应用程序都是基于 C/S 架构的，所有的数据交换和服务请求都依赖于一个或多个中央服务器。P2P（Peer-to-Peer，对等网络或点对点技术）是一种分布式网络架构，其核心思想是让网络中的每个节点既扮演客户端的角色，也扮演服务器的角色，直接与其他节点进行通信和资源交换，而不依赖于一个集中式的服务器。

P2P 中的每个节点称为对等体，这种模式使得每个节点既可以请求数据，也可以提供数据，从而实现真正的去中心化。

P2P 架构的优缺点如下：

• 优点
  • 高扩展性：随着更多节点加入，网络整体资源（带宽、存储、算力）也随之增长，系统性能不会因节点增多而显著下降。
  • 健壮性与容错性：去中心化结构避免了单点故障，即使部分节点失效，整体网络仍能正常运作。
  • 低成本：无需昂贵的集中式服务器，资源由网络中各个普通节点共享。
  • 隐私保护：某些 P2P 系统支持匿名通信，降低用户信息泄露风险。
• 缺点
  • 架构复杂性：节点发现、连接建立、数据传输等需要复杂的协议支持，如 NAT 穿透等技术。
  • 安全风险：易受恶意节点、中毒攻击、拒绝服务攻击等威胁，需要加强安全和验证机制。
  • 搜索效率：非结构化 P2P 网络在大规模环境下的搜索效率较低，容易产生广播风暴。
  • 法律风险：文件共享中涉及版权问题，部分 P2P 应用曾因侵权遭遇法律制裁。

1.2 资源查找

按网络拓扑结构可以将 P2P 分为结构化与非结构化的 P2P：

• 结构化 P2P：结构化 P2P 网络通过预先设计的规则组织整个网络的拓扑结构，通常采用分布式哈希表 （DHT）来为节点和资源分配"位置"或"键"。每个节点负责管理一部分键值空间，从而使得文件或资源的存储和查找都有确定的规则。当一个节点需要查找某个资源时，可以通过 DHT 算法快速定位到负责该键的节点，查找过程通常只需经过对数级的跳数。
• 非结构化 P2P：非结构化 P2P 网络中，节点之间的连接是随机的或根据用户自主选择形成的，并没有预先定义的全局结构或规则。这类网络常常依赖洪泛（flooding）或随机游走等方法来查找资源。当节点需要查找资源时，它会向邻居节点发出请求，并由这些邻居再转发请求。这种"广播式"或"洪泛式"搜索方法在查找热门资源时比较有效，但对于冷门或稀缺资源，成功率较低且会产生大量网络流量。

结构化 P2P 查询速度快且具有确定性，网络规模扩大时，每个节点的负载相对平衡，但是维护 DHT 和路由表需要较复杂的协议；非结构化 P2P 无需维护全局索引或复杂的数据结构，容易实现，但是洪泛搜索会消耗大量带宽，且搜索结果可能不完全可靠，随着网络规模的增大，广播带来的网络负载会显著增加，影响整体性能。

在 P2P 网络中，资源发现是一个关键问题，主要有两种典型方法：集中式目录和查询洪泛。

（1）集中式目录

集中式目录的工作原理为节点在加入网络后，会将自己共享的资源信息注册到一个或多个中央服务器 上，这些服务器充当全局目录或索引，记录所有节点所共享的文件或资源。其他节点在需要查找某个资源时，只需向该目录服务器查询，就能快速定位到拥有该资源的节点。

其优点是查询速度快，因目录信息集中管理，搜索开销较小，且实现简单，适用于早期或规模较小的 P2P 系统（如 Napster）。但是这种方法存在单点故障风险，目录服务器若出现故障，整个系统的资源发现能力将受到影响，并且容易受到攻击和法律监管，也就是中央目录服务器成为被攻击或监管的目标。

（2）查询洪泛

在无中心目录的非结构化 P2P 网络中，每个节点通过与邻居节点随机连接 构成网络。当一个节点需要查找某个资源时，它会向所有直接相连的邻居节点发送查询请求，这些邻居节点再将请求转发给它们的邻居，如此"洪泛"整个网络，直到查询达到预设的跳数（TTL）限制为止，如果某个节点拥有该资源，就会向发起查询的节点返回响应，这个过程其实就是广度优先搜索（BFS）。

其优点是完全去中心化，没有单点故障，网络更为健壮，节点可以自由加入和退出，适应性强。缺点是查询效率低，尤其是在大规模网络中，洪泛式搜索会产生大量重复消息，占用大量带宽和计算资源，对于冷门资源，查询成功率较低，因为请求消息在网络中可能因 TTL 限制而无法覆盖到拥有该资源的节点。

Gnutella 是最早的纯去中心化的 P2P 文件共享协议之一：

在 Gnutella 网络中，一个新的节点（对等方）加入的过程大致如下：

1. 引导与启动：由于 Gnutella 本身没有中央服务器，客户端通常会预先配置一份引导节点的列表（这些节点是网络中已知且在线的对等方）。新节点启动时会先尝试与这些已知节点建立连接。
2. 节点发现
   • Ping 消息：新节点建立初步连接后，会向它连接的邻居节点发送 Ping 消息。
   • Pong 回复：收到 Ping 消息的节点会向自己的邻居转发这个 Ping 消息并向发送来 Ping 消息的节点返回 Pong 消息，其中包含自身的 IP 地址、端口和一些基本的状态信息。
   • 邻居列表构建：新节点通过接收到的 Pong 消息，构建自己的邻居列表，从而逐步融入整个网络中。
3. 网络整合：通过不断发送 Ping 以及其他查询消息，新加入的节点逐步了解网络中的其他节点，并可以参与资源搜索、共享文件等操作。整个过程基于消息洪泛机制，因此网络中每个节点在搜索或传播信息时，都会将消息转发给它的所有邻居（通常会有 TTL 限制，防止无限传播）。

这种无中心、基于洪泛的节点加入方式虽然简单、完全去中心化，但在大规模网络中也可能带来消息冗余和网络负载较高的问题。

KaZaA 是一款曾风靡一时的 P2P 文件共享软件，与 Gnutella 不同，KaZaA 采用了混合式或半中心化的架构。每个对等方要么是一个组长，要么隶属于一个组长，对等方与其组长之间有 TCP 连接，组长对之间也有 TCP 连接，组长会跟踪其所有的孩子的内容，组长能够转发查询到其他组长，或者获得其他组长的数据拷贝。

KaZaA 查询文件时每个文件有一个散列标识码和一个描述符，客户端向其组长发送关键字查询，组长匹配数据：元数据、散列标识码和 IP 地址后进行响应，如果组长将查询转发给其他组长，其他组长也以匹配进行响应，最后客户端选择要下载的文件（向拥有文件的对等方发送一个带散列标识码的 HTTP 请求）。

1.3 BitTorrent

BitTorrent 是一种用于大文件高效分发的点对点（P2P）文件共享协议，采用的是去中心化的"多对多"传输模式，使得每个用户在下载文件的同时，也在上传自己已经下载的数据块，从而充分利用整个网络的带宽资源。

BitTorrent 协议将文件分为许多小的"块"或"片段"（piece），每个片段都有独立的 SHA1 校验码以保证数据完整性。文件的元数据（即 .torrent 文件）采用 Bencoding 格式编码，里面包含文件（或文件集合）的基本信息（名称、大小、分片长度、各片段的哈希列表等）与 Tracker 的 URL（用于初步发现其他对等节点）。

• .torrent 文件称为种子文件，是一种很小的文件，它充当了"索引"的角色，指明了目标文件如何被切分，以及应该联系哪个 Tracker 来寻找其他共享该文件的用户。
• Tracker 是一个专门的服务器，它不传输文件内容，只负责记录和向请求者返回当前在下载（或上传）该文件的其他用户（即 Peer）的 IP 地址和端口。通过 Tracker，新的节点能够快速加入到文件的 "Swarm"（群组）中。

为了降低对 Tracker 的依赖，BitTorrent 后期引入了 DHT（分布式哈希表）技术。通过 DHT，每个支持的客户端都在网络中维护一部分路由表，允许在 Tracker 不可用的情况下，节点之间仍能互相发现并交换数据。

BitTorrent 工作原理如下：

• 文件发布与种子生成：发布者使用 BitTorrent 客户端将要共享的文件（或文件夹）制作成一个 .torrent 文件。这个文件中记录了文件的所有基本信息、分块方式、每个块的 SHA1 哈希值以及 Tracker 的地址。
• 文件分块与校验：文件在下载前会被虚拟地切分为固定大小的块（例如 256KB、512KB 或 1MB），每个块下载完成后，客户端会根据种子中提供的哈希值进行校验，确保数据没有损坏。
• 节点加入与 Tracker 通信：下载者先从网络上获取 .torrent 文件，然后通过该文件中的 Tracker 地址与 Tracker 建立连接。Tracker 返回当前正在共享该文件的其他节点列表，新节点便由此加入到共享 "Swarm" 中。
• 数据交换与"最稀缺优先"策略：客户端在连接上其他节点后，会互相交换 "have" 消息，告知彼此已经拥有的片段。BitTorrent 协议采用"最稀缺优先"策略，即优先下载在整个网络中数量较少的片段，确保所有片段都能迅速复制，防止某些片段因资源不足而导致下载瓶颈。
• Choke/Unchoke 策略：为了鼓励上传（分享）行为，BitTorrent 使用了一种"阻塞算法"。每个客户端只会同时向有限数量的（通常是 4 个）其他节点发送数据，并会定期评估各个连接的传输速度。表现好的节点会被优先"解阻塞"（unchoke），而其他节点则暂时"阻塞"（choke），从而实现"你给我多，我就给你多"的公平交换机制。
• End Game 模式：当下载接近完成时，客户端会进入 End Game 模式，对尚未收到的最后几个数据块同时向所有可能的节点请求，以避免因为某些节点响应缓慢导致整体下载停滞。

2. CDN

2.1 多媒体流化服务 DASH

多媒体流化可以理解为将音视频、动画、图像等多媒体内容处理成一种连续、实时传输的"流"形式，使用户无需等待整个文件下载完成，就能即时播放和互动。

DASH（Dynamic Adaptive Streaming over HTTP，基于 HTTP 的动态自适应流），也称 MPEG-DASH，是一种国际标准的流媒体传输技术。它的核心思想在于将一个长的视频或音频文件预先编码成多种不同质量（码率、分辨率、帧率等）的版本，然后将每个版本切割成若干个短小的、固定时长的片段（Segment），并通过标准的 HTTP 服务器进行分发。

当用户开始播放时，客户端播放器首先下载一个描述文件（MPD，Media Presentation Description），该文件包含了所有流版本的信息和各个片段的地址，播放器随后根据当前的网络带宽和终端设备能力，动态选择最适合的版本进行播放，同时客户端还会周期性地测量服务器到客户端的带宽，可在播放过程中根据网络条件无缝切换到更高或更低质量的版本，如果带宽足够，选择最大码率的视频块，这样能够最大限度地减少缓冲和卡顿现象。

2.2 CDN 介绍

仅仅依赖 DASH 技术进行流媒体传输，并不能解决所有传输问题，它本身主要解决的是内容切片、编码和自适应播放的问题，而不涉及如何高效、低延迟地将内容分发到全球各地用户手中。可能存在以下问题：

• 单点服务器压力大：如果只有一个或少量源站服务器负责提供 DASH 切片，当用户数量增加时，这些服务器会面临巨大的并发请求，导致带宽和处理能力不足，从而引起延迟、缓冲甚至服务中断。
• 全球覆盖不足：DASH 协议本身并不包含内容分发机制。对于全球范围内的用户来说，如果所有请求都指向位于单一地区的服务器，远距离用户会面临更高的延迟和较差的观看体验（服务器到客户端路径上跳数较多）。
• 网络拥堵与延时：仅使用 DASH 技术时，所有流量集中于源服务器所在的网络路径上，在遇到高峰流量或网络故障时，容易出现拥堵，导致播放卡顿或重缓冲。
• 抗攻击能力不足：单一或少量服务器容易成为 DDoS 攻击的目标。没有分布式架构支撑，攻击者可能通过大流量请求使服务器瘫痪，从而影响所有用户的正常观看。

CDN（Content Delivery Network，内容分发网络），是一种利用分布在全球各地的服务器群体，将网站或应用的静态和部分动态内容缓存到离终端用户更近的节点上，从而实现快速、稳定、安全内容传输的网络架构。

CDN 通过在全球多个战略性位置部署边缘节点 （也称为缓存服务器），将源站（原始服务器）上的内容复制并缓存。当用户访问网站时，其请求将被路由到最近的边缘节点，从而减少跨境或长距离传输所带来的延迟和网络拥堵。这样不仅能提升用户访问速度，还能减轻源站的负载，降低带宽成本，同时增强网站的抗攻击能力和可靠性。

CDN 一般由三个主要部分构成：

• DNS 调度层：利用 DNS 解析技术，将用户请求智能分发到最优的 CDN 节点。
• 缓存层（边缘节点）：存储经过预先缓存的静态资源（如图片、CSS、JavaScript、视频等），若缓存命中则直接返回给用户；若未命中，则向源站请求数据，并将结果缓存以备后续使用。
• 中心管理平台：负责监控各节点状态、调度流量、更新缓存及进行全局负载均衡管理。

2.3 缓存节点部署策略

CDN 中缓存节点部署策略分为两种："enter deep" 与 "bring home"：

• enter deep：指的是将 CDN 服务器深入部署在各个接入网内部，也就是部署在各个 ISP（互联网服务提供商）或局域网络内部。这样做的优点是节点更接近最终用户，可以进一步降低网络延时，提升用户体验；由于部署的节点数量较多，能够覆盖更多区域并提供更细粒度的加速服务。但缺点也很明显，管理这些大量节点成本较高、维护较为复杂。
• bring home：指的是将 CDN 服务器部署在少数关键位置，比如部署在主要互联网交换点（IXP）或 POP（Point of Presence）附近。这种策略的优点是节点数量少，便于集中管理和维护，运营成本较低；可以通过租用高速线路将这些关键节点连接起来，保证较高的传输能力。缺点是节点相对较少，可能导致部分用户与 CDN 服务器之间的网络路径较长，从而略微增加延时。

2.4 CDN 工作原理

CDN 工作流程分为以下几个步骤：

• DNS 解析与流量调度：当用户在浏览器中输入网站域名后，首先经过 DNS 进行域名解析重定向过程。网站通常会将自己的域名通过 CNAME 记录指向 CDN 提供的加速域名。经过解析后，用户的请求会被引导到离用户最近或最优的 CDN 节点。这种就近访问大大降低了传输延迟。
• 缓存与回源机制：用户向 CDN 节点发起资源请求后根据缓存是否命中分为以下两种情况，这种机制既减少了对源站的压力，又能有效分散流量，提升整体服务的稳定性和可扩展性：
  • 缓存命中：如果该节点已缓存所需资源，则直接返回给用户，响应速度极快。
  • 缓存未命中：节点会向源站（或其他节点）发起回源请求，获取资源后既返回给用户，又将该内容缓存起来，便于后续请求直接响应。
• 负载均衡与智能调度：CDN 通过实时监控各节点的健康状态、负载情况和网络延迟等指标，利用多种算法（例如基于地理位置、延迟、带宽等因素）来智能分配用户请求，使用户总能从最优的节点获取数据，确保访问速度和服务质量。

2.5 Name Server Lookup

Name Server Lookup 是一种命令行工具，用于查询域名系统（DNS）信息。通过 nslookup 命令，你可以获得某个域名对应的 IP 地址、邮件服务器（MX 记录）、名称服务器（NS 记录）等 DNS 记录信息。这对于排查网络问题、验证 DNS 配置以及了解域名解析过程非常有帮助。

例如我们执行以下命令：

nslookup www.bilibili.com

返回的结果如下：

服务器:  public1.alidns.com
Address:  223.5.5.5

非权威应答:
名称:    a.w.bilicdn1.com
Addresses:  2408:872f:20:b::14
          2408:8726:1100:100::2:12
          2408:8726:1100:100::2:17
          2408:8726:1100:100::2:18
          2408:8726:1100:100::2:19
          2408:8726:1100:100::2:20
          2408:8726:1100:100::2:21
          2408:872f:20:b::13
          221.204.56.92
          221.204.56.93
          221.204.56.94
          221.204.56.95
          218.60.18.13
          218.60.18.14
          218.60.18.15
          218.60.18.16
          218.60.18.17
          218.60.18.18
          221.204.56.86
Aliases:  www.bilibili.com

这个 nslookup 结果展示了以下几个关键信息：

（1）查询使用的 DNS 服务器

服务器: public1.alidns.com
Address: 223.5.5.5

这表示你的查询是由阿里云公共 DNS 服务器（public1.alidns.com，IP 为 223.5.5.5）处理的。这是你系统配置的默认 DNS 服务器，它负责解析域名到相应的 IP 地址。

（2）非权威应答

非权威应答表示返回的 DNS 信息不是直接来自 bilibili.com 的权威 DNS 服务器，而是来自你所查询 DNS 服务器的缓存数据。虽然数据不是权威数据，但通常是准确的。

（3）域名别名和解析结果

名称: a.w.bilicdn1.com
...
Aliases: www.bilibili.com

这说明实际解析出来的域名是 a.w.bilicdn1.com，而不是直接的 www.bilibili.com。这通常表明 www.bilibili.com 通过 CNAME 记录指向了 a.w.bilicdn1.com，这个域名通常由 Bilibili 用于其 CDN 服务。Aliases 字段说明 www.bilibili.com 是 a.w.bilicdn1.com 的别名。

（4）多个 IP 地址

返回结果列出了多个 IPv6 和 IPv4 地址，这些地址通常是由 CDN 提供的负载均衡策略所决定的。CDN 会在全球或区域内部署许多节点，用户请求时会根据网络状况和地理位置分配到最合适的节点。返回多个地址正是为了分散流量、降低延时并提升可靠性。

因此整个流程为：当我访问 www.bilibili.com 时，计算机会首先向默认配置的 DNS 服务器发送域名解析请求。DNS 服务器收到请求后，根据 Bilibili 的 DNS 记录返回一个 CNAME 记录，指向 Bilibili 的 CDN 域名 a.w.bilicdn1.com，并提供一组对应的 IP 地址（包含 IPv6 和 IPv4 地址），这些 IP 地址就是 CDN 的多个节点。浏览器（或客户端）接收到这些解析结果后，会根据当前的网络路由、延时、负载等因素，从返回的多个 IP 地址中选择一个建立连接，然后向该 CDN 节点请求资源。

那么我能找出我最后是与哪个 CDN 节点建立连接了吗？我们可以先找出我们电脑建立的所有 TCP 连接：

netstat -an | findstr ESTABLISHED

返回结果如下：

  TCP    127.0.0.1:1042         127.0.0.1:54695        ESTABLISHED
  ...
  TCP    192.168.xx.xx:57670    49.7.253.214:8080      ESTABLISHED
  ...
  TCP    192.168.xx.xx:57703    221.204.56.86:443      ESTABLISHED
  ...

其中左侧的 IP 为我们主机的 IP 地址，右侧的为目标 IP 地址，我们使用浏览器连接 Bilibili，根据 HTTPS 协议可知端口号为 443，因此我们锁定端口号为 443 的目标地址查找，发现了 221.204.56.86:443 的 IP 地址出现在之前 nslookup 的结果中，因此可以确定我们最后建立连接的 CDN 服务器 IP 为 221.204.56.86。