2 应用层

应用层协议原理

网络应用程序体系结构

应用程序体系结构：规定了如何在各种端系统上组织应用程序

客户-服务器体系结构：服务器总是打开的，并且有固定的、周知的地址；（Web, FTP, Telnet, Email 等）
对等（P2P 体系结构）：应用程序在间断连接的主机对之间直接通信，主机对被称为对等方（文件共享 BitTorrent, P2P 协助下载, 视频会议等）

在一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。

进程与网络之间的接口

一个进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文
套接字是同一台主机内应用层与运输层之间的接口
由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface，API）
应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权
在因特网中，主机由其 IP 地址标识。除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程（接收套接字），目的地端口号用于这个目的
一些流行的服务比如 Web 服务器，邮件服务器进程等有特定的端口号

可供 APP 使用的运输服务

可靠数据传输：当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程
带宽敏感的应用：指对吞吐量有要求的应用
定时保证：可以做到发送方注入进套接字中的每个比特到达接收方的套接字不迟于 100 ms 这种
安全性：在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据

因特网提供的运输服务

TCP服务

包括面向连接服务和可靠数据传输服务，当某个应用程序调用 TCP 作为其运输协议时，该应用程序就能获得来自 TCP 的这两种服务
TCP 协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处

TCP 安全

无论TCP还是UDP都没有提供任何加密机制
发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同
因特网界已经研制了TCP的加强版本，称为安全套接字层（SSL）
SSL加强后的TCP提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别
SSL不是与TCP和UDP在相同层次上的第三种因特网运输协议，而是一种对TCP的加强，这种强化是在应用层上实现的
SSL有它自己的套接字API，这类似于传统的TCP套接字API

UDP服务

一种只提供必要服务的轻量级运输协议
UDP 是无连接的，因此在两个进程通信前没有握手过程
UDP 协议提供不可靠数据传送服务，既不保证送达，也不保证按序送达
UDP 没有拥塞控制，UDP 的发送端可以用它选定的任何速率向其下层（网络层）注入数据，但是实际速度受控于链路带宽
网络电话开发者通常愿意将该应用运行在 UDP 上，从而设法避开 TCP 的拥塞控制机制和分组开销。但因为许多防火墙被配置成阻挡（大多数类型的）UDP 流量，所以网络电话应用通常设计成如果 UDP 通信失败就使用 TCP 作为备份

因特网运输协议不提供的服务

现在的 TCP、UDP 不提供对吞吐量、定时的保证
但是它们已经被设计成尽最大可能对付这种保证的缺乏了，不然像微信电话这样的应用就不会运行的这么好了，但是不能说一定提供这种保证

应用层协议

应用层协议（application-layer protocol）定义了运行在不同端系统上的应用程序进程如何相互传递报文。

应用层协议有公有和私有之分
应用层协议是网络应用的一部分

Web 和 HTTP

概述

Web 页面（也叫文档）：由对象组成的

对象：一个文件，诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件，且可通过一个 URL 寻址

每个 URL 地址由两部分组成：存放对象的服务器主机名和对象的路径名。
例如：URL 地址 http://www.someSchool.edu/someDepartment/picture.gif，其中的 www.someSchool.edu 就是主机名，/someDepartment/picture.gif 就是路径名

HTTP 概况

HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web页面的方式。

HTTP 使用 TCP 作为支撑运输协议
HTTP 客户首先发起一个与服务器的 TCP 连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP
客户向它的套接字接口发送 HTTP 请求报文并从它的套接字接口接收 HTTP 响应报文
服务器从它的套接字接口接收 HTTP 请求报文和向它的套接字接口发送 HTTP 响应报文
TCP 为 HTTP 提供可靠数据传输服务。这意味着，一个客户进程发出的每个 HTTP 请求报文最终能完整地到达服务器；类似地，服务器进程发出的每个 HTTP 响应报文最终能完整地到达客户。这是分层体系结构的优点 ——HTTP 不用考虑数据丢失和乱序的问题
HTTP 服务器并不保存关于客户的任何信息，HTTP 是一个无状态协议

持续连接和非持续连接

非持续连接：每个请求/响应对是经一个单独的 TCP 连接发送，即每次请求和回复都要打开一个 TCP 连接

非持续连接的例子

事实上，用户能够配置现代浏览器来控制连接的并行度。在默认方式下，大部分浏览器打开5 ~ 10个并行的 TCP 连接，而每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置为 1，这样 10 条连接就会串行建立。使用并行连接可以缩短响应时间。

往返时间（Round-Trip Time, RTT）：指一个短分组从客户到服务器然后再返回客户所花费的时间。RTT 包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延
下面这个例子，粗略地讲，总的响应时间就是两个 RTT 加上服务器传输 HTML 文件的时间

非持续连接缺点1：必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配 TCP 的缓冲区和保持 TCP 变量，这给Web服务器带来了严重的负担
非持续连接缺点2：每一个对象经受两倍 RTT 的交付时延，即一个 RTT 用于创建 TCP，另一个 RTT 用于请求和接收一个对象

持续连接：所有的请求及其响应经相同的 TCP 连接发送

在采用 HTTP 1.1 持续连接的情况下，服务器在发送响应后保持该 TCP 连接打开
一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP 服务器就关闭该连接

HTTP 报文格式

HTTP 请求报文

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

请求行：HTTP 请求报文的第一行，有 3 个字段：方法字段、URL 字段和 HTTP 版本字段

方法字段可取：包括 GET、POST、HEAD、PUT、DELETE
当浏览器请求一个对象时，使用 GET 方法，在 URL 字段带有请求对象的标识

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: Tuer 18 Aug 2015 15:11:03 GMT 
Content-Length: 6821 
Content-Type: text/html 

(data data data data data ...)

一个 Web 站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来

Cookie 技术的四个组件：

在 HTTP 响应报文中的一个 cookie 首部行
在 HTTP 请求报文中的一个 cookie 首部行
用户端系统中保留有一个 cookie 文件，并由用户的浏览器进行管理
位于 Web 站点的一个后端数据库

Web 缓存

Web 缓存器也叫代理服务器，是能够代表初始 Web 服务器来满足 HTTP 请求的网络实体。

举例

假设浏览器正在请求对象 http://www.someschool.edu/campus.gif

1）浏览器创建一个到 Web 缓存器的 TCP 连接，并向 Web 缓存器中的对象发送一个 HTTP 请求

2）Web 缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web 缓存器就向客户浏览器用 HTTP 响应报文返回该对象

3）如果 Web 缓存器中没有该对象，它就打开一个与该对象的初始服务器的 TCP 连接。Web 缓存器则在这个缓存器到服务器的 TCP 连接上发送一个对该对象的 HTTP 请求。在收到该请求后，初始服务器向该 Web 缓存器发送具有该对象的 HTTP 响应

4）当 Web 缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用 HTTP 响应报文发送该副本（通过现有的客户浏览器和 Web 缓存器之间的 TCP 连接）

Web 缓存器既是服务器又是客户
Web 缓存器通常由 ISP 购买并安装
Web 缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与 Web 缓存器之间的瓶颈带宽时
Web 缓存器能够大大减少一个机构的接入链路到因特网的通信量。通过减少通信量，该机构（如一家公司或者一所大学）就不必急于增加带宽，因此降低了费用
内容分发网络（CDN）公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化

条件 GET

尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。HTTP 协议有一种机制，允许缓存器证实它的对象是最新的，即条件 GET 方法。

收到一个条件 GET 后：

缓存器向 Web 服务器确认
如果更改了，就需要重新获得，并更新缓存
如果没更改，Web 服务器将发送一个 304 Not Modified 空体报文

电子邮件

因特网电子邮件系统的主要组成部分：

用户代理：允许用户阅读、回复、转发、保存和撰写报文

当 Alice 完成邮件撰写时，她的邮件代理向其邮件服务器发送邮件，此时邮件放在邮件服务器的外出报文队列中
当 Bob 要阅读报文时，他的用户代理在其邮件服务器的邮箱中取得该报文

邮件服务器

典型邮件发送过程：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中
当 Bob 要在他的邮箱中读取该报文时，包含他邮箱的邮件服务器使用用户名和口令来鉴别 Bob 的身份
Alice 的邮箱须能处理 Bob 的邮件服务器的故障。如果Alice的服务器不能将邮件交付给Bob的服务器，Alice的邮件服务器在一个报文队列中保持该报文并在以后尝试再次发送。通常每30分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知 Alice

简单邮件传输协议（SMTP）

SMTP 是因特网电子邮件中主要的应用层协议
SMTP 使用 TCP 可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件
SMTP 有两个部分：运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端
每台邮件服务器上既运行 SMTP 的客户端也运行 SMTP 的服务器端

SMTP

SMTP 用于从发送方的邮件服务器发送报文到接收方的邮件服务器
在用 SMTP 传送邮件之前，需要将二进制多媒体数据编码为 ASCII 码，并且在使用 SMTP 传输后要求将相应的 ASCII 码邮件解码还原为多媒体数据（历史原因）

SMTP 的基本操作

假设Alice想给Bob发送一封简单的ASCII报文

1）Alice调用她的邮件代理程序并提供Bob的邮件地址，撰写报文，然后指示用户代理发送该报文

2）Alice的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中

3）运行在Alice的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，它就创建一个到运行在Bob的邮件服务器上的SMTP服务器的TCP连接

4）在经过一些初始SMTP握手后，SMTP客户通过该TCP连接发送Alice的报文

5）在Bob的邮件服务器上，SMTP的服务器端接收该报文。Bob的邮件服务器然后将该报文放入Bob的邮箱中

6）在Bob方便的时候，他调用用户代理阅读该报文

SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样
如果 Bob 的邮件服务器没有开机，该报文会保留在 Alice 的邮件服务器上并等待进行新的尝试，这意味着邮件并不在中间的某个邮件服务器存留

SMTP 与 HTTP 的对比

相同点：

这两个协议都用于从一台主机向另一台主机传送文件
当进行文件传送时，持续的 HTTP 和 SMTP 都使用持续连接

不同点：

HTTP 主要是一个 pull protocol（拉协议），TCP 连接是由想接受文件的机器发起的
SMTP 主要是一个 push protocol，TCP 连接是由要发送该文件的机器发起的
SMTP 报文必须按照 7 比特 ASCII 码进行编码，而 HTTP 数据没有这种限制
对一个既包含文本又包含图形（也可能是其他媒体类型）的文档，HTTP 把每个对象封装到其自己的 HTTP 响应报文中，而 SMTP 则把所有报文对象放在一个报文之中

邮件访问协议

为什么要将邮件代理和邮件服务器分离开？

—— 邮件服务器管理用户的邮箱，并且运行 SMTP 的客户端和服务器端。如果 Bob 的邮件服务器位于他的 PC 上，那么为了能够及时接收可能在任何时候到达的新邮件，他的 PC 需要总是不间断地运行着并一直保持在线。

Bob 的用户代理不能使用 SMTP 得到报文，因为取报文是一个拉操作，而 SMTP 协议是一个推协议。

—— 引入一个特殊的邮件访问协议来解决这个难题，该协议将 Bob 邮件服务器上的报文传送给他的本地 PC

目前流行的邮件访问协议：

第三版邮局协议（POP3）
因特网邮件访问协议（IMAP）
HTTP

DNS：因特网的目录服务

DNS（Domain Name System，域名系统）提供域名（主机名）到 IP 地址的映射

DNS 是：

由分层的 DNS 服务器实现的分布式数据库
一个使得主机能够查询分布式数据库的应用层协议
DNS 服务器通常是运行 BIND 软件的 UNIX 机器
DNS 协议运行在 UDP 之上，使用 53 号端口

使用 DNS 服务的例子

考虑运行在某用户主机上的一个浏览器（即一个HTTP客户）请求URL www.someschool.edu/index.html 页面时会发生什么现象。为了使用户的主机能够将一个HTTP请求报文发送到Web服务器 www.someschool.edu ，该用户主机必须获得www.someschool.edu 的IP地址。其做法如下。 1）同一台用户主机上运行着DNS应用的客户端。 2）浏览器从上述URL中抽取主机名www.someschool.edu ，并将这台主机名传给DNS应用的客户端。 3）DNS客户向DNS服务器发送一个包含主机名的请求。 4）DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址。 5）一旦浏览器接收到来自DNS的该IP地址，它能够向位于该IP地址80端口的HTTP服务器进程发起一个TCP连接。

从这个例子中，我们可以看到DNS给使用它的因特网应用带来了额外的时延，有时还相当可观。幸运的是，想获得的IP地址通常就缓存在一个附近的DNS服务器中，这有助于减少DNS的网络流量和DNS的平均时延。

DNS 提供的其他服务

举例：
    规范主机名：relay1.west-coast.enterprise.com
    主机别名：www.enterprise.com

主机别名

有着复杂主机名的主机能拥有一个或者多个别名
主机别名（当存在时）比主机规范名更加容易记忆
应用程序可以调用 DNS 来获得主机别名对应的规范主机名以及主机的 IP 地址

邮件服务器别名

电子邮件应用程序可以调用 DNS 主机别名进行解析以获得该主机的规范主机名及其 IP 地址
MX 记录允许一个公司的邮件服务器和 Web 服务器使用相同（别名化的）的主机名

负载分配

繁忙的站点被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上，每个都有着不同的 IP 地址，在这种情况下一个规范主机名与一个 IP 地址集合相联系
当客户对映射到某地址集合的名字发出一个 DNS 请求时，该服务器用 IP 地址的整个集合进行响应，但在每个回答中循环这些地址次序

DNS 工作机理

集中式设计的问题：

单点故障
通信容量：单个 DNS 服务器需要处理所有的 DNS 查询
远距离：低速、拥塞链路导致严重时延
维护：中央数据库庞大，需要频繁添加更新

分布式、层次式设计：

还有另一类重要的DNS服务器，称为本地DNS服务器（local DNS server）
严格说来，一个本地DNS服务器并不属于该服务器的层次结构，但它对DNS层次结构是至关重要的
每个ISP都有一台本地DNS服务器（也叫默认名字服务器）
当主机发DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将该请求转发到DNS服务器层次结构中

递归查询和迭代查询

区分递归查询和迭代查询

递归查询以自己的名义请求来获得该映射
迭代查询相当于帮别人请求
实践中，查询通常遵循左图模式：从请求主机到本地 DNS 服务器的查询是递归的，其余的查询是迭代的

DNS 缓存

在一个请求链中，当某DNS服务器接收一个DNS回答时，它能将映射缓存在本地存储器中
如果在DNS服务器缓存命中，该DNS服务器就能够提供所要求的IP地址，即使它不是该主机名的权威服务器
由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后（通常设置为两天）将丢弃缓存的信息
事实上，因为缓存，除了少数DNS查询以外，根服务器被绕过了

DNS 记录和报文

DNS 数据库以资源记录（Resource Record, RR）形式保存数据
每个 DNS 回答报文包含了一条或多条资源记录

资源记录是一个四元组：(name, value, type, TTL)

TTL：记录的生存时间，决定了这个 RR 应当从缓存中被删除的时间
Type：决定了 Name 和 Value 的值

Type	Name	Value
A	主机名	对应的 IP 地址
NS	域（如 foo.com）	知道这个域 IP 地址的权威 DNS 服务器的主机名（如 dns.foo.com）
CNAME	别名	规范主机名
MX	别名	邮件服务器的规范主机名

通过使用 MX 记录，一个公司的邮件服务器和其他服务器（如它的Web服务器）可以使用相同的别名：

为了获得邮件服务器的规范主机名，DNS 客户应当请求一条 MX 记录
为了获得其他服务器的规范主机名，DNS 客户应当请求 CNAME 记录

如果一台 DNS 服务器是用于特定主机名（比如 cs.foo.com）的权威 DNS 服务器：

DNS 服务器上有 A 记录

如果一台 DNS 服务器不是用于特定主机名的权威 DNS 服务器：

DNS 服务器上也可能有 cs.foo.com 的 A 记录缓存
DNS 服务器上有 NS 记录
DNS 服务器上有 NS 记录 Value 对应的 A 记录

DNS 报文

DNS 有查询和回答报文两种报文
查询和回答报文格式相同

P2P 文件分发

前面的应用采用 Client-Server 体系结构，依赖于总是打开的基础设施服务器。本节研究一个 P2P 体系结构应用：从单一服务器向大量主机（称为对等方）分发一个大文件。

在 P2P 文件分发中，每个对等方能够向任何其他对等方重新分发它已经收到的该文件的任何部分，从而在分发过程中协助服务器
到 2016 年止，最为流行的 P2P 文件分发协议是 BitTorrent

文件分发问题概述

符号	含义
$u_s$	服务器接入链路的上传速率
$u_i$	第 $i$ 个对等方的接入链路的上传速率
$d_i$	第 $i$ 个对等方的接入链路的下载速率
$d_{min}$	$\min\{d_1,...d_N\}$
$F$	被分发的文件长度（以比特计）
$N$	需要获得该文件副本的对等方数量
$D_{cs}$	使用客户-服务器架构的分发时间
$D_{P2P}$	使用 P2P 架构的分发时间

其他假设：

假设网络核心带宽足够，所有瓶颈都在接入链路
除了此任务外，没有其他任务占用上传和下载带宽

使用客户端-服务器架构传输文件

服务器向每一个对等方传输文件： $d_1=NF/u_s$
具有最小下载速率的对等方下载文件： $d_2=F/d_{min}$
所以： $D_{cs}\geqslant \max\{d_1,d_2\}$

使用 P2P 架构传输文件

服务器至少经过接入链路发送文件一次： $d_1=F/u_s$
具有最小下载速率的对等方下载文件： $d_2=F/d_{min}$
系统整体的总上载能力： $u=u_s+\sum_{i=1}^Nu_i$ ，系统总共上传 $NF$ 比特，所需时间至少是 $d_3=NF/u$
所以： $D_{P2P}\geqslant\max\{d_1,d_2,d_3\}$

如果我们认为一旦每个对等方接收到一个比特就能够重分发一个比特的话，则存在一个重新分发方案能实际取得这种下界。

使用 BitTorrent

BitTorrent 是一种用于文件分发的流行 P2P 协议。

BitTorrent 基础概念概述

参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）
在一个洪流中的对等方彼此下载等长度的文件块
当一个对等方首次加入一个洪流时，它没有块
随着时间的流逝，它累积了越来越多的块
当它下载块时，也为其他对等方上传一些块
一旦某对等方获得了整个文件，它也许离开洪流，或留在该洪流中并继续向其他对等方上载块
任何对等方可能在仅具有块的子集时就离开该洪流，并在以后重新加入该洪流中
每个洪流具有一个基础设施节点，称为追踪器
当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中，追踪器因此可跟踪参与在洪流中的对等方

BitTorrent 连接概述

当一个新的对等方 Alice 加入洪流时：

追踪器随机从参与对等方的集合中选择对等方的一个子集（比如，50 个）
追踪器将这 50 个对等方的 IP 地址发送给 Alice
Alice 持有对等方的这张列表，试图与该列表上的所有对等方创建并行的 TCP 连接

称所有这样与 Alice 成功地创建一个 TCP 连接的对等方为 “邻近对等方”（如图 2-23 中有 3 个临近对等方）

随着时间的流逝，这些对等方中的某些可能离开，其他对等方（最初 50 个以外的）可能试图与 Alice 创建 TCP 连接

结论：一个对等方的邻近对等方是随时间而改变的

在任何给定的时间，每个对等方具有文件的块的子集，并且不同的对等方具有不同的子集
Alice 周期性地（经TCP连接）询问每个邻近对等方它们所具有的块列表。如果 Alice 具有 $L$ 个不同的邻居，她将获得 $L$ 个块列表
有了这个信息，Alice 将对她当前还没有的块发出请求（仍通过TCP连接）

上述过程中两个问题：

Alice 应当从她的邻居请求哪些块呢？

Alice 使用最稀缺优先的技术
Alice 首先请求她没有的、且在所有邻居中数量最少（最稀缺）的块
最稀缺块得到更为迅速的重新分发，其目标是大致地均衡每个块在洪流中的副本数量

Alice 应当向哪些向她请求块的邻居发送块？

BitTorrent 使用了一种对换算法（“一报还一报”）来处理这个问题

Alice 对于她的每个邻居都持续地测量收到比特的速率，并确定以最高速率流入的 4 个邻居（BitTorrent 称这 4 个对等方为疏通）
Alice 根据当前能够以最高速率向她提供数据的邻居，给出其优先权
每过 10 秒，她重新计算该速率并可能修改这4个对等方的集合
每过 30 秒，她要随机地选择另外一个邻居（比如 Bob）并向其发送块
因为 Alice 正在向 Bob 发送数据，她可能成为 Bob 前 4 位上载者之一，这样的话 Bob 将开始向 Alice 发送数据。如果 Bob 向 Alice 发送数据的速率足够高，Bob 接下来也能成为 Alice 的前 4 位上载者
每过 30 秒 Alice 将随机地选择一名新的对换伴侣并开始与那位伴侣进行对换。如果这两名对等方都满足此对换，它们将对方放入其前 4 位列表中并继续与对方进行对换，直到该对等方之一发现了一个更好的伴侣为止
这种效果是对等方能够以趋向于找到彼此的协调的速率上载

视频流

视频是一系列的图像，通常以一种恒定的帧率来展现
一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素是由一些比特编码来表示亮度和颜色
图像编码技术利用图像的帧内冗余（空间冗余）和帧间冗余（时间冗余）来减少需要使用的比特数
视频的一个重要特征是它能够被压缩，因而可用比特率来权衡视频质量。今天现成的压缩算法能够将一个视频压缩成所希望的任何比特率。当然，比特率越高，图像质量越好
从网络的观点看，也许视频最为突出的特征是它的高比特率。压缩的因特网视频的比特率范围：

视频质量	比特率
低质量视频	100 kbps
流式高分辨率电影	超过 3 Mbps
4K 流式	超过 10 Mbps

对流式视频的最为重要的性能度量是平均端到端吞吐量
为了提供连续不断的布局，网络必须为流式应用提供平均吞吐量，这个流式应用至少与压缩视频的比特率一样大

流式视频存储

视频作为一个普通文件，保存在 HTTP 服务器中
服务器与客户建立 TCP 连接，发送文件
视频应用周期性地从应用缓存中取帧、解码、展示
问题：所有客户使用相同的编码速率（server video 相同，编码也相同）

流式多媒体：DASH

Dynamic, Adaptive Streaming over HTTP

服务器：

将视频文件划分成多个块
每个块以不同的码率编码和存储
元文件为不同的块提供URL

客户：

周期性地测量到服务器的网络带宽
查询元文件，每次请求一个块
选择当前带宽可支持的最大码率
不同时刻可以选择不同码率的块

客户端能够 “智能地” 确定：

什么时候请求块（避免缓存不足或溢出）
请求什么码率的块（获得当前最好的视频质量）
向谁请求块（离客户最近或具有最高带宽的URL）

如何将内容流式传输给同时在线的大量用户？

方法1：使用一个巨型服务器（不可行）

单点故障
网络拥塞点
远端用户传输距离长，跨多个 ISP，带宽低
同一条链路上传输多个视频拷贝，浪费带宽

方法2：在地理上分布的多个站点存储和提供服务 (CDN)

enter deep：将CDN服务器深入部署到大量接入网中，靠近用户
bring home：将少量（几十个）较大的集群部署在靠近接入网的 POP 中

内容分发网络

在多个CDN站点存储内容的拷贝

用户从CDN请求内容：

用户请求被定向到附近的站点，获取内容
网络拥塞时，可向不同的站点请求内容拷贝

CDN 例子

假定一个内容提供商 NetCinema
NetCinema 雇佣第三方 CDN 公司 KingCDN 来向其客户分发视频
在 NetCinema 的 Web 网页上每个视频都被指派了一个 URL，该 URL 包括了字符串 “video” 以及该视频本身的独特标识符（如 BV 号）

当用户访问位于 NetCinema 的 Web 网页 http://video.netcinema.com/6Y7B23V 时：

用户主机发送了一个对于 video.netcinema.com 的 DNS 请求
用户的本地 DNS 服务器（LDNS）将该 DNS 请求中继到一台用于 NetCinema 的权威 DNS 服务器
权威 DNS 服务器观察到主机名 video.netcinema.com 中的字符串 “video”，其向 LDNS 返回一个 KingCDN 域的主机名，如 a1105.kingcdn.com
DNS 请求进入了 KingCDN 专用 DNS 基础设施
用户的 LDNS 发送第二个请求，此时是对 a1105.kingcdn.com 的 DNS 请求
KingCDN 的 DNS 系统向 LDNS 返回 KingCDN 内容服务器的IP地址
LDNS 向用户主机转发内容服务 CDN 节点的 IP 地址
用户主机与具有该 IP 地址的服务器创建了一条直接的 TCP 连接，并且发出对该视频的HTTP GET请求

如果使用了 DASH，服务器将首先向客户发送具有 URL 列表的告示文件，每个 URL 对应视频的每个版本，并且客户将动态地选择来自不同版本的块

CDN 集群选择策略

指派客户到地理上最为邻近的集群

对于众多用户来说能够工作得相当好
但对某些客户，该解决方案可能执行的效果差
因为就网络路径的长度或跳数而言，地理最邻近的集群可能并不是最近的集群
所有基于 DNS 的方法都内在具有的问题是，某些端用户配置使用位于远地的 Local DNS，在这种情况下，LDNS 位置可能远离客户的位置
这种策略忽略了时延和可用带宽随因特网路径时间而变化，总是为特定的客户指派相同的集群

基于当前流量条件为客户决定最好的集群

CDN 能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量
一个缺点是许多 LDNS 被配置为不会响应这些探测

套接字编程

网络应用程序有两类：

由协议标准中所定义的操作的实现，这样的应用程序有时称为“开放”的，因为定义其操作的这些规则为人们所共知
专用的网络应用程序。客户和服务器程序应用的应用层协议没有公开。其他独立的开发者将不能开发出和该应用程序交互的代码

UDP 服务与 TCP 服务

UDP

报文传输服务
由于没有建立管道，应用程序发送每个报文必须给出远程进程地址
服务器使用一个进程和一个套接字为所有客户服务，一次请求-响应完成一次服务

TCP

字节流传输服务
由于建立了管道，应用程序只需向套接字中写入字节序列，不需指出远程进程地址
服务器为每个客户单独生成一个套接字和一个新进程，允许双方长时间通信

TCP 套接字编程

TCP 是一个面向连接的协议，客户和服务器能够开始互相发送数据之前先要握手和创建一个TCP连接
TCP 服务器在客户试图发起接触前必须作为进程运行起来
服务器程序必须具有一个特殊的套接字，用以欢迎来自运行在任意主机上的客户进程的某种初始接触
在三次握手期间，服务器会生成一个新套接字（连接套接字）用于这次客户请求的连接

本文阅读量