其他应用层协议

本文内容基于 2025 秋季《计算机网络》课程讲述，如有差错，欢迎指正

P2P#

P2P 基本概念#

之前提到过，在应用层，实体之间一般有两种组织方式

• 客户-服务器模式（Client-Server Model）
• 对等体模式（Peer-to-Peer Model, P2P）

在P2P中，我们把每个实体称为对等节点(Peer) ，它是一种去中心化的组织方式，不需要长期在线的服务器，各个 节点可以自由加入和退出，在系统中也可以根据自己的需要来改变IP地址

典型例子：

• P2P文件分享(BitTorrent)
• 视频流(PPLive)
• VoIP(Skype)

P2P可以避免单一服务器的性能瓶颈，可扩展性强。随着节点增多，虽然下载需求增加，但上传能力（服务能力）也线性增加

• C/S 架构：分发时间随用户数线性增长，瓶颈在服务器上传带宽
• P2P 架构：分发时间趋于常数（理想情况下），因为每个 Peer 都在贡献带宽

P2P 索引#

给定了某一资源，如何查找到拥有该资源的 Peer ，以及如何在P2P的组织特点（随时加入退出，更改IP）之下 解决这个问题，就需要索引发挥作用。

如何实现索引？

中心化索引

使用中心化的索引服务器，所有 Peer 加入系统时需要告知服务器自身IP和拥有的内容。 用户在需要下载文件时先向索引服务器查询，获取拥有该文件的 Peer 列表，然后直接与这些 Peer 进行通信下载文件。

这种方式有着所有中心化系统都具有的问题（类比DNS）：单点故障、性能瓶颈。因此人们自然想到了可以使用去中心化的方法

洪泛请求

每个peer独立建立索引，记录自身拥有的资源，peer之间用TCP建立连接（一般小于10个），形成Overlay网络

当某个节点需要查找某个资源时，向其连接的peer（邻居）发送请求，如果邻居没有该资源，则邻居会向自身邻居递归查询， 直到某个节点反馈含有该资源，然后按照路径把自己的信息发给请求节点。之后，请求节点直接与拥有资源的节点连接下载资源

缺点：产生大量网络流量（需要遍历图），可扩展性受限

混合索引

介于中心化索引与洪泛索引之间，将Overlay网络组织为层次化结构。

引入超级节点，普通节点连接到至少一个超级节点，超级节点之间任意连接。超级节点扮演中心化索引的角色，记录连接到 自己的普通节点的信息，超级节点之间采用洪泛方式查询

P2P 实例#

Gnutella 协议

早期的一个纯P2P协议，使用洪泛请求方式查找资源

建立TCP连接时也采用洪泛过程：

• 新加入结点Alice通过candidate peers列表，找到其他peers
• Alice遍历列表里每个peer，直到与某个peer Bob建立TCP连接
• Alice通过洪泛PING消息发现邻居节点，邻居节点回复PONG消息
• 收到PONG消息后，Alice可以与这些节点建立新的连接

BitTorrent

不是纯P2P协议，使用混合索引方式查找资源，每个文件被划分为多个256KB的文件块(Chunk)，Peer之间交换文件块

几个定义：

• Torrent (种子)：正在交换文件的 Peer 集合
• Tracker (跟踪器)：中心化组件，一个独立服务器，维护种子中所有活跃的节点，以及节点所拥有的文件块信息。负责帮助节点获取其他节点的信息

新节点加入种子时，先向 Tracker 注册自己，并获取其他节点的信息，然后与这些节点建立连接，开始交换文件块。下载 完成后，节点可以选择继续留在种子中，也可以退出

有时候一些人下载完成后会选择退出，这时候需要有一些策略能让各个节点愿意留在系统中，这样系统才能健康运行

Peer节点优化策略：

• 稀有文件块有优先，优先下载拥有的人少的文件块
• 互惠原则，优先给那些向自己发送速度最快的节点发送文件块（预期：贡献越大，回报越大）
  • 优先向上传速度最快的前4个节点发送文件块，暂时不给其他peer发送，每十秒钟重新评估一次
  • 每隔30秒随机选择一个节点发送文件块，选择相信该节点，期望得到回报（成为 top 4）

Skype

基于P2P的即时通讯，私有的应用层协议，通过逆向推断其原理。

采用混合索引方法，存在超级节点，另有一个登录服务器，节点登录时先连接登录服务器获取分配的超级节点，然后与超级节点建立连接

分布式哈希表 DHT

如果没有中心化的 Tracker ，如何实现P2P？

核心挑战： 如何管理key -> value 映射关系

Chord 协议:

基本思想：

• 对于对等节点和资源信息，计算一个哈希值然后取模
• 把哈希值放在一个圆环上
• 每个key由圆环上顺时针方向下一个节点负责维护
• 查询时，沿着圆环顺时针方向查找，直到找到负责该key的节点

流媒体#

音视频传输对性能的要求较高，传输需要保持顺序性，对错误有一定程度的容忍性，且对延迟敏感

如何选择传输层协议？

• UDP 不保证可靠性（丢包）
• TCP 无法保证带宽和时延（抖动）

核心机制：客户端缓存

• 通过在接收端建立缓冲区，平滑网络抖动
• 推迟播放：数据到达后先存入缓存，几秒后再播放，避免因网络波动导致的卡顿 。

一些编码标准#

视频编码标准：H.264，H.265，VP9，AV1等

• H.264：最主流的编码；支持不同分辨率、比特率；兼容性好
• H.265：H.264的升级，视频内容压缩50%；硬件成本高，专利许可费高
• VP9：Google开源视频编码标准，与H.265相当性能，无许可费
• AV1：开源标准，比H.265与VP9性能更好，开源免费

音频编码标准：AAC，MP3，Opus等

媒体容器格式：封装视频与音频

• MP4：支持多种视频编码与音频编码，兼容性最好
• MKV：多音轨、多字幕，适合电影电视剧；兼容性不如MP4
• FLV：支持编码最少；早期因为跨平台、交互性好，用于网络流媒体，现逐渐淘汰

流媒体协议#

RTP与RTCP —— 最基础的流媒体协议

RTP是建立于UDP上的流媒体传输协议，自身不对服务质量提供保障

RTCP是RTP的控制协议，也建立与UDP上，负责监控传输质量，向发送端反馈信息

这两个协议很少直接使用，大多作为其他流媒体协议的基础

RTSP —— 控制播放过程

RTSP本身并不传送数据，是一个多媒体播放控制协议

对播放情况进行控制，如：暂停/继续、后退、前进等，又称为“互联网遥控协议”，是有状态的协议

既可基于TCP，也可基于UDP(RTP,RTCP)

RTCP和RTSP的区别：

• 控制目的
  • RTSP：对用户可见（暂停、继续播放等）
  • RTCP：对用户不可见（质量反馈等）
• 实现
  • RTSP：UDP或TCP
  • RTCP：UDP

DASH协议

现在很多主流的流媒体协议都是基于HTTP的，DASH是其中一个典型代表

DASH (Dynamic Adaptive Streaming over HTTP)

• 原理：将视频切成小片段 (segment)，每个片段编码为多种码率；视频片段与其对应的元文件（URL）一同存放于DASH服务器； 客户端基于网络条件、缓冲大小等，对每个视频片段，自适应选择合适的视频码率来下载
• ABR算法 (自适应码率)：客户端根据当前网络带宽，主动选择请求哪个码率的片段
  • 基于吞吐量的算法：使用滑动窗口平均估计未来吞吐量，选择不高于估计值的最大码率视频
  • 基于缓冲的算法：使用缓冲区满的级别来决定下一个视频块的请求码率
  • 放弃请求规则：在下载视频块的过程中，如果算法检测到下载该视频块的过程有卡顿，则终止当前请求，转而重新下载相应的低码率视频块

内容分发网络 CDN#

如何将内容分发给网络上大量的用户？

单个、大型的服务器容易出现单点故障、网络拥塞等问题，且大型服务器一般离用户较远，传输延迟较长

CDN的优势：

• 降低响应时延，避免网络拥塞
• 避免原始服务器过载及防止DDoS攻击
• 分布式架构，具有良好的可扩展性
• 对用户透明，无需用户感知

核心原理#

缓存：将内容（如视频、图片）复制到分布在全球边缘网络的服务器上，让用户就近获取 。

资源选择：如何让用户的请求导向最近的 CDN 节点？

• 客户端选择：客户端获取拷贝“清单”，根据清单选取节点
• 服务器选择
  • HTTP重定向：CDN边缘服务器接收到用户请求后，返回重定向响应，引导用户访问最近节点
  • DNS重定向：CDN提供商控制域名解析，根据用户位置返回最近节点IP

几个经典的应用层协议#

这里简单带过一下，不详细讲了