[网络协议]应用层协议

归纳自《计算机网络 自顶向下方法》

应用层协议

原理

应用程序：

• 浏览器程序：运行在用户主机（台式电脑、笔记本、手机等）

• 服务器程序：运行在服务器上（阿里云、百度云等）

当研发新的应用程序时，你需要编写将在多台端系统上运行的软件

网络核心设备并不在应用层上起作用，而仅在较低层起作用，特别是在网络层及下面层次起作用。这种基本设计，即将应用软件限制在端系统的方法，促进了大量网络应用程序的迅速研发和部署。

网络应用程序体系结构

• 应用程序的体系结构不同于网络的体系结构
• 应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序

当前的两种主流体系结构：客户 - 服务器体系结构或对等体系结构

客户 - 服务器体系结构

由一个总是打开的服务器，多个客户机组成

客户机之间相互不能进行通信

著名例子有：淘宝、京东等电商平台（用户之间可以通信是因为结合了P2P体系），百度、谷歌等搜索引擎

若一个流行的社交网络站点如果仅有一台服务器来处理所有请求，将很快变得不堪重负而发生宕机，为此，配备大量主机的数据中心常被用于创建强大的虚拟服务器，这称为集群

P2P体系结构

应用程序在简介连接的主机对之间使用直接通信，这些主机对被称为对等方。

P2P体系结构的最引人入胜的特性之一是它们的自扩展性。在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方因为向其他对等方分发文件也为系统增加服务能力。因此不需要庞大的服务器基础设施和服务器带宽。

进程通信

运行在多个端系统上的程序进行通信实际上是进程间的通信

当多个进程运行在相同的端系统时，它们使用进程间通信机制相互通信。进程间通信的规则由端系统上的操作系统确定

两个不同端系统上的进程，通过跨越计算机网路交换报文而相互通信

客户和服务器进程

对于Web而言，浏览器是一个客户进程，Web服务器是一台服务器进程。对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方表示为服务器

定义：

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

进程与计算机网络之间的接口

进程通过一个称为套接字（Socket）的软件接口向网络发送报文和从网络接收报文，套接字也被称为应用程序和网络之间的应用程序接口（Application Programming Interface），开发者可以控制套接字在应用层端的一切，但对运输层端几乎没有控制权

开发者对于运输层的控制仅限于：

• 选择运输层协议
• 设定运输层参数，如最大缓存和最大报文段长度

进程寻址

在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要由一个地址。

为了标识该接收进程，需要定义两种信息：

• 主机的地址：IP地址
• 在目的地主机中指定接收进程的标识符：端口号

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

从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时、安全性

可靠数据传输

确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端，如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输

吞吐量

在沿着一条网络路径上的两个几次呢还给你之间的会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率

1. 带宽敏感的应用

   具有吞吐量要求的应用程序

2. 弹性应用

   根据当时可用的带宽或多或少地利用可供使用的吞吐量

定时

网络延迟

安全性

在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。这种服务将在发送和接收进程之间提供机密性，以防该数据以某种方式在这两个进程之间被观察到

因特网提供的运输服务

因特网（更一般的是TCP/IP网络）为应用程序提供两个运输层协议，即UDP和TCP。当你（作为一个软件开发者）为因特网创建一个新的应用时，首先要做出的决定是，选择UDP还是选择TCP。

TCP服务

TCP服务包括面向连接服务和可靠数据传输服务

• 面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息，这称为握手，在握手阶段后，一个TCP连接建立。这条连接时全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除连接。
• 可靠数据传输服务：通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。

TCP安全：

无论TCP还是UDP都没有提供任何加密机制，这就是说发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同，因为因特网界已经研制了TCP的加强版本，称为安全套接字层（（Secure Sockets Layer, SSL），用SSL加强后的TCP不仅能够做 传统的TCP所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密数据完整性和端点鉴别。

辨别网站是否增加了SSL：

http://
https://（增强）

UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。同时，UDP协议提供一种不可靠数据传输服务，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。

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

运输协议服务：可靠数据传输、吞吐量、定时和安全性。

TCP提供了可靠的端到端数据传送。并且我们也知道TCP在应用层可以很容易地用SSL来加强以提供安全服务。但什么协议提供对吞吐量或定时有要求的服务呢？很遗憾，目前的因特网运输协议并没有提供。即便如此，在因特网上运行时间敏感应用已经有多年了，这些应用经常工作得相当好。

虽然没法保证对吞吐量和定时的要求，但可以无限逼近这种保证，毕竟光速也是目前人类科学达不到的。

应用层服务

应用层协议定义了运行在不同端系统的应用程序上的应用程序进程如何相互传递报文：

• 交换的报文类型，例如请求报文和响应报文。
• 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
• 字段的语义，即这些字段中的信息的含义。
• 确定一个进程何时以及如何发送报文，对报文进行响应的规则。

区分网络应用和应用层协议

应用层协议只是网络应用的一部分

Web 和 HTTP

20世纪90年代以前，因特网的主要使用者还是研究人员、学者和大学生，他们登 录远程主机，在本地主机和远程主机之间传输文件，收发新闻，收发电子邮件。尽管这些应用非常有用（并且继续如此），但是因特网基本上不为学术界和研究界之外所知。到了 20世纪90年代初期，一个主要的新型应用即**万维网（WorldWideWeb）**登上了舞台 ［Berners-Lee 1994]。 Web是一个引起公众注意的因特网应用，它极大地改变了人们与工 作环境内外交流的方式。它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。

HTTP概况

Web的应用层协议是超文本传输协议（HyperText TransferProtocol, HTTP）,它是Web的核心。

HTTP 有两个程序实现：

• 用户程序
• 服务器程序

这两个程序分别运行在不同的端系统中，通过交换报文进行会话

web术语

Web页面（文档）是由对象组成的，一个对象只是一个文件，诸如一个HTML文件、一个JPEG图形，一个视频文件等，并且它们课通过一个URL地址寻址。多数Web页面含有一个**HTML基本文件（base HTML file）**以及几个引用对象，例如：如果一个Web页面包含HTML文本和5个JPEG图片，那么这个Web页面有6个对象。

HTML基本文件通过对象的URL地址引用页面中的其他对象。每个URL地址由两部分组成 存放对象的服务器主机名和对象的路径名。例如,URL地址：

https://www.baidu.com:443/img/PCtm_d9c8750bed0b3c7d089fa7d55720d6cf.png

• 协议：https://
• 主机名：www.baidu.com
• 端口号：443
• 图片路径：/img/PCtm_d9c8750bed0b3c7d089fa7d55720d6cf.png（不是服务器真实路径，还要经过一次转换）

Web服务器（Webserver）实现了 HTTP的服务器端，它用于存储Web对象，每个对象由URL寻址。国内著名云服务器厂商有：阿里云、腾讯云、百度云、华为云等。

http协议

HTTP定义了 Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。它的特点主要有：

• 使用TCP作为它的支撑运输协议。
• 只关心应用层的工作
• 是一个无状态协议（stateless protocol），假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。

非持续连接和可持续连接

往返时间（Round-Trip Time，RTT）

一个短分组从客户到服务器然后再返回客户所花费的时间

RTT 包括分组传播时延、分组在中间路由和交换机上排队时延以及分组处理时延

三次握手

客户向服务器发送一个小TCP报文段**（一），服务器用一个小TCP报文段做出确认和响应（二）, 最后，客户向服务器返回确认（三）**。

响应时间

三次握手中前两个部分所耗费的时间占用了一个RTT。完成了三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该TCP连接发 送一个HTTP请求报文。一旦该请求报文到达服务器，服务器就在该TCP连接上发送HTML文件。该HTTP请求/响应用去了另一个RTT。因此，粗略地讲，总的响应时间就是两个RTT加上服务器传输HTML文件的时间。

非持续连接

每个请求/响应是经一个单独的TCP连接发送

假设一个页面含有一个HTML基本文件和10个JPEG图片，并且这11个对象位于同一台服务器上，从服务器向客户传送一个Web页面：

• 发起TCP连接，这涉及三次握手
• HTTP客户经它的套接字向该服务器发送一个HTTP请求报文
• HTTP服务器进程经它的套接字接收该请求报文，并在HTTP响应报文中封装对象，并通过套接字向客户发送响应报文
• HTTP服务器进程通知TCP断开该TCP连接
• HTTP客户接收响应报文，TCP连接关闭
• 对每个引用的JPEG图形对象重复前4个步骤

可以看到，一次请求实际上进行了11次TCP连接

缺点：

• 必须为每一个请求的对象建立和维护一个全新的连接
• 每一个对象经受两倍RTT的交付时延

可持续性连接

所有的请求以及响应经相同的TCP连接发送，HTTP默认使用这种方式

HTTP报文

请求报文

书中的示例报文

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

第一行叫做请求行，后继行叫做首部行，或者我们习惯称之为请求头

请求行有三个字段：方法字段、URL字段和HTTP版本字段。方法字段可以取：GET、POST、HEAD、PUT、DELETE，这几个方法的具体作用这里不做过多赘述。

host：主机名

Connection：连接状态，close为非持续性连接，keep-alive为可持续性连接

User-agent：用户代理，一般指浏览器类型

Accept-language：语言

一般形式

其中**实体体（entity body）**当使用POST方法时才会使用（如表单提交）

响应报文

书中的示例报文

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 ???)

它有三个部分：一个初始状态行，6个首部行（请求头），然后是实体体。

实体体部分是报文的主要部分，即它包含了所请求的对象本身（表示为data data data data data -）。

状态行

状态行有3个字段，即协议本字段、状态码和相应状态信息。在这个例子中，状态行指示服务器正在使用HTTP/1.1,并且一切正常（即服务器已经找到并正在发送所请求的对象）

请求头

Connect：使用非持续性连接

Date：这个时间不是指对象创建或者最后修改的时间，而是服务器从它的文件系统中

检索到该对象，将该对象插入响应报文，并发送该响应报文的时间

Server：是由一台Apache Web服务器产生的，系统为Linux-CentOS

Last-Modified：对象创建或者最后修改的日期和时间

Content-Length：被发送对象中的 字节数

Content-Type：实体体中的对象是HTML文本

一般形式

一些常见的状态码和相关的短语：

• 200 OK：请求成功，信息在返回的响应报文中

• 301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应报

  文的Location:首部行中。客户软件将自动获取新的URL

• 400 Bad Request: 一个通用差错代码，指示该请求不能被服务器理解

• 404 Not Found:被请求的文档不在服务器上

• 505 HTTP Version Not Supported:服务器不支持请求报文使用的HTTP协议版本

不同浏览器对请求报文、响应报文的显示方式可能会有很大不同

cookie

cookie允许站点对用户进行跟踪

组成：

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

Web缓存

也称作代理服务器，能够代表初始Web服务器来满足HTTP请求的网络实体

部署缓存服务器后，请求一个站点将会发生如下情况：

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

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

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

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

为什么要使用缓存

1. Web缓存器可以大大减少对客户请求的响应时间。
2. Web缓存器能够大大减少一个机构的接入链路到因特网的通信量，进而降低了费用。

条件GET方法

尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。

GET /fruit/kiwi.gif HTTP/1.1
Host: www.exotiquecuisine.com
If-modified-since: Wed, 9 Sep 2015 09:23:24

请注意第三行，它所表达的信息是：如果这个对象在服务器端于 2015年9月9日09:23:24 后被修改，那么请给我响应修改后的对象。

因特网中的电子邮件

与普通邮件一样，电子邮件是一种异步通信媒介，即当人们方便时就可以收发邮件，不必与他人的计划进行协调。

与普通邮件相比，它的优点有：

• 更为快速
• 易于分发
• 价格便宜（甚至免费）

电子邮件主要由用户代理、邮件服务器、简单邮件传输协议组成，下面举例说明

Alice 要给 Bob 发送一封电子邮件
A：Alice调用她的邮件代理程序并提供Bob的邮件地址（例如bob@someschool.edu），
撰写报文，然后指示用户代理发送该报文。
A：Alice的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中。
A：运行在Alice的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，它就
创建一个到运行在Bob的邮件服务器上的SMTP服务器的TCP连接。
A：在经过一些初始SMTP握手后，SMTP客户通过该TCP连接发送Alice的报文。
B：在Bob的邮件服务器上，SMTP的服务器端接收该报文。Bob的邮件服务器然后将
该报文放入Bob的邮箱中。

如果Alice的服务器不能将邮件交付给Bob的服务器（系统故障、网路原因等）,Alice的邮件服务器在一个报文队列中保持该报文并在以后尝试再次发送。通常每30分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方（Alice）。

SMTP

因特网电子邮件中主要的应用层协议，包含两个部分：

• 运行在发送方邮件服务器的客户端
• 运行在接收方邮件服务器的服务器端

使用TCP连接，每台邮件服务器既运行客户端也运行服务器端，一般不使用中间邮件服务器发送邮件

与HTTP的对比

相同特性：

• 都用于从一台主机向另一台主机传送文件
• 持续的HTTP和SMTP都使用持续连接（TCP）

不同之处：

• HTTP是一个拉协议，从服务器拉取信息，SMTP是一个推协议，发送邮件服务器把文件推向接收邮件服务器。
• SMTP要求每个报文采用 7bit ASCLL码格式，HTTP则没有这种限制

邮件报文格式

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

每个首部行必须含有一个From和一个To，可能包含一个Subject

邮件访问协议

SMPTP是一个推协议，并不能从邮件服务器上获取报文！这需要其他协议来完成工作

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

• 第三版的邮局协议（PostOffice Protocol—Version 3 , POP3）
• 因特网邮件访问协议（Internet Mail Access Protocol,IMAP）
• HTTP

POP3

约束简单，功能有限

阶段一：特许

用户代理发送（以明文形式）用户名和口令以鉴别用户

阶段二：事务处理

用户代理取回报文，并对报文进行操作

阶段三：更新

出现在用户发出quit命令后，结束该POP3会话

缺陷

• 只能将邮件保存在本地设备，更换设备需要重新拉取邮件，这造成一定不便与数据冗余

IMAP

为用户建立远程服务器文件夹以及提供操作接口

基于Web的电子邮件

• 用户代理就是普通浏览器
• 用户和其他远程邮箱之间的通信则通过 HTTP 进行
• 用户代理之间的连接仍是 SMTP

DNS：因特网的目录服务

人类与机器区别主机的方式

如 www.facebook.com、www.baidu.com 这些名字（域名）更便于人脑记忆与接受，然而，机器无法从这些名字提取出足够的有效信息，因此，机器区别主机的方式为获取IP地址进行辨识

DNS提供的服务

为了折中，我们需要一种能进行主机名到IP地址转换的目录服务，这就是域名系统

DNS

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

解析

DNS通常式由其他应用层协议所使用，包括 HTTP、SMTP 和 FTP，将用户提供的主机名解析为 IP 地址

主机别名

有着复杂主机名的主机能拥有一个或多个别名，通常比主机名更好记忆，应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址

邮件服务器别名

通常的邮箱账号有 xxx@qq.com、xxx@outlook.com、xxx@yahoo.com 等，他们都有共同的特征，@符号跟的是一个主机名，电子邮件邮件应用程序可以调用 DNS，对提供的主机名别名进行解析。MX记录允许一个公司服务器和Web服务器使用相同的主机名（别名）

负载均衡

繁忙的站点（如cnn…com）被冗余分布在多台服务器上

DNS工作机理

单体式设计

只使用一个DNS服务器，该服务器包含所有的映射，这种集中式的问题有：

• 单点故障：如果该 DNS 服务器崩溃，整个因特网随之瘫痪
• 通信容量：单个DNS需要处理所有的 DNS 查询
• 远距离的集中式数据库：单个DNS服务器不可能“邻近”所有客户，一个请求也许会有不可接受的时延
• 维护：单个DNS 服务器不得不为所有的因特网主机保留记录，出了问题很难维护

分布式设计

为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内

共有四种类型的DNS服务器：

• 根 DNS 服务器：提供TLD服务器的IP地址
• 顶级域（TLD） DNS 服务器：对于每个顶级域（com、org、net）和所有国家域（uk、fr、ca），都有TLD服务器
• 权威 DNS 服务器：在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址
• 本地 DNS 服务器：并不处于 DNS 服务器的层次中，每个ISP都有一台本地DNS服务器，起到桥接的作用。当主机发出 DNS 请求时，该请求被发往本地 DNS 服务器，它起着代理的作用

? 如图所示，假设主机 cse.nyu.edu 想知道主机 gaia.cs.umass.edu 的IP地址。同时假设纽约大学（NYU）的 cse.nyu.edu 主机的本地DNS服务器为 dns. nyu. edu, 并且 gaia.cs.umass.edu 的权威DNS服务器为 dns.umass.eduo。 如图2 18所示，主机 cse.nyu.edu 首先向它的本地DNS服务器 dns.nyu.edu 发送一个DNS查 询报文。该查询报文含有被转换的主机 gaia.cs.umass.eduo 本地DNS服务器将该报文转发到根DNS服务器。该根DNS服务 器注意到其edu前缀并向本地DNS服务器返回负责edu的TLD的IP地址列表。该本 地DNS服务器则再次向这些TLD服务器之一发送查询报文。该TLD服务器注意到 umass. edu 前缀，并用权威DNS服务器的IP地址进行响应，该权威DNS服务器是负责马萨诸塞大学的 dns.umass.eduo 最后，本地DNS服务器直接向 dns.umass.edu 重发查询报文, dns.umass.edu用 gaia.cs.umass.edu 的IP地址进行响应。

不同于第一种方式，这种方式使用纯递归，第一种方式则是迭代递归公用

DNS缓存

为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术

在一个请求链中，当某 DNS 服务器接收一个 DNS 回答时，它能够将映射缓存在本地存储器中。由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后（通常设置为两天）将丢弃缓存的信息。

DNS记录和报文

共同实现 DNS 分布式数据库的所有 DNS 服务器存储了资源记录（Resource Record，RR），RR提供了主机名到IP地址的映射。

组成

• Type：A（提供主机名到IP地址的映射）、NS（沿着查询链来路由DNS查询）、CNAME（向查询的主机提供一个主机名对应的规范主机名）、MX（允许邮件服务器主机名具有简单的别名）
• Name：由Type决定，A -> 主机名（www.baidu.com），NS -> 域名（baidu.com）
• Value：由Type决定，A -> IP地址，NS -> 如何获取对应域名的主机名，CNAME -> 别名为 Name 的主机对用的规范的主机名，MX -> 别名为 Name 的邮件服务器的规范主机名
• TTL：该记录的生存时间

报文格式

DNS有查询和回答报文，它们具有相同的格式

插入数据

当注册域名时，需要提供主机名域IP地址，假设名字是 dns1.networkutopia.com 和 dns2.networkutopia.com 及 212.212.212.1 和 212.212.212.2。对这两个权威DNS服务器的每一个，注册登记机构确保将一个类型 NS 和一个类型 A 的记录输入 TLD com 服务器。

P2P文件分发

BitTorrent

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

用 BitTorrent 的术语来 讲，参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）。在一个洪流中的对等方彼此下载等长度的文件块，典型的块长度为256KB。当一个对等方首次加入一个洪流时，它没有块。随着时间的流逝，它累积了越来越多的块。当它下载块时，也为其他对等方上载了多个块。一旦某对等方获得了整个文件，它也许（自私地）离开洪流，或（大公无私地）留在该洪流中并继续向其他对等方上载块。同时，任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中。

追踪器

每个洪流具有一个基础设施节点，称为追踪器（tracker）。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟踪参与在洪流中的对等方。一个给定的洪流可能在任何时刻具有数以百计或数以千计的对等方。

其他细节不予赘述

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

因特网视频

在流式存储视频应用中，基础的媒体是预先录制的视频，它们放置在服务器上。

每个视频根据压缩的程度有多个分辨率版本，用户根据自己的网络状况自行选择一个分辨率进行观看

HTTP流和DASH

HTTP流

在 HTTP流 中，视频只是存储在 HTTP 服务器中作为一个普通的文件，每个文件有一个特定的URL。当用户要看该视频时，客户与服务器创建一个 TCP 连接并发送对该 URL的 HTTP GET 请求。服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个 HTTP 响应报文中发送该视频文件。在客户一侧，字节被收集在客户应用缓存中。一旦该 缓存中的字节数量超过预先设定的门限，客户应用程序就开始播放，特别是，流式视频应用程序周期性地从客户应用程序缓存中抓取帧，对这些帧解压缩并且在用户屏幕上展现。因此，流式视频应用接收到视频就进行播放，同时缓存该视频后面部分的帧

HTTP流的缺陷

所有用户接收到相同编码的视频

DASH

HTTP的动态适应性流（Dynamic Adaptive Streaming over HTTP，DASH)。在DASH中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应于不同的质量水平。客户动态地请求来自不同 本且长度为几秒的视频段数据块。

内容分发网（CDN）

为了应对向全世界的用户分发巨量时评数据的挑战，几乎所有主要的视频流公司都利用CDN

CDN管理分布在多个地理位置 上的服务器，在它的服务器中存储视频（和其他类型的Web内容，包括文档、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN（private CDN）,即它由内容提供商自己所拥有；例如，谷歌的 CDN 分发 YouTube 视频和其他类型的内容。另一种CDN可以是第三方CDN ，国内比较著名的有 七牛云、阿里云、百度云提供的CDN服务器租借。

CDN通常采用两种不同的服务器安置原则：

• 深入：通过在遍及全球的接入ISP中部署服务器集群来深入到 ISP 的接入网中
• 邀请做客：通过少量关键位置建造大集群来邀请到ISP做客

CDN没有将视频推入它们的集群，而是用一种简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频，向客户流式传输视频时的同时在本地存储一个副本。当某集群存储器变满时，它删除不经常请求的视频。

CDN操作

大多数CDN利用DNS来截获和重定向请求

假定一个内容提供商 NetCinema，租赁了第三方 CDN 公司 KingCDN 来向其客户分发视频。则用户进行访问需要6个步骤

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uKtsiGlR-1627397323379)(C:\Users\李星龙\Desktop\我的\计算机与网络\新建文本文档 (2)].assets\image-20210727223728685.png)

1. 用户访问位于 NetCinema 的Web网页
2. 当用户点击链接 http://video.netcinema.com/6Y7B23V 时，该用户主机发送了一个对于 video.netcinema.com 的DNS请求。
3. 用户的本地DNS服务器（Local DNS）将该DNS请求中继到一台权威DNS服务器，该服务器向LDNS返回一个 KingCDN 域的主机名
4. DNS 请求进入了 KingCND 专用 DNS 基础设施。此时LDNS发送第二个请求到KingCDN的服务器
5. LDNS 向用户主机转发内容服务 CDN 节点的IP地址
6. 一旦客户收到 KingCDN 服务器的IP地址，它与具有该IP地址的服务器创建了一条直接的TCP连接，并发出对该视频的 HTTP GET 请求。如果使用了 DASH,服务 器将首先向客户发送具有URL列表的告示文件，每个URL对应视频的每个版本，并且客户将动态地选择来自不同版本的块。

集群选择策略

CND 一般采用专用的集群策略

一种简单的策略是指派客户到**地理上最为邻近(geographically closest)**的集群。当从一个特殊的LDNS接收到一个DNS请求，CDN选择地理上最为接近的集群。

为了基于当前流量条件为客户决定最好的集群，CDN 能够对其集群和客户之间的时延和丢包性能执行周期性的**实时测量(real-time measurement)。**CDN 周期性地向全世界所有的 LDNS 发送探测分组。