计算机网络-应用层总结

应用层协议原理

首先，我们要了解应用程序体系结构的概念。应用程序体系结构规定了如何在各种端系统上组织该应用程序。一般来说有两种体系结构：客户-服务器体系结构(client-server architecture)和对等(P2P)体系结构。

Client-server architecture

在这个结构中，有一个总是打开的主机称为服务器，它会处理来自许多客户的主机的请求。一个典型的例子是 Web 应用程序，我们请求网页，网页处理请求，在把内容响应给我们。如下图所示：

我们发现，客户相互之间是不直接通信的。

此外，客户-服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为IP地址。

具有客户-服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet 和电子邮件。

配得大量主机的数据中心常被用于创建强大的虚拟服务器。最流行的因特网服务：如搜索引擎(Bing,Google) , 电商 (Amazon , e-bay ) ，基于Web的电子邮件(Gmail)等就应用了一个或者多个数据中心。

P2P architecture

在这个架构中，应用程序在间断连接的主机对之间使用直接通信。这些应用包括文件共享(BitTorrent)，下载器(迅雷)，因特网电话和视频会议(Skype)等。

因特网提供的运输服务

TCP

当某个程序调用TCP作为其运输协议时，该应用程序就能获得来自TCP的两种服务

面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器通过握手过程，提醒客户和服务器让它们为大量分组的到来做好准备。在握手截断后，一个TCP连接就在两个进程的套接字之间建立了。当应用程序结束发送报文时，必须拆除该连接
可靠的数据传送服务：通信进程能够依靠TCP，无差错，按适当顺序交付所有发送的数据。当应用程序的一端将字节流传入socket时，它能一开TCP将相同的字节流交付给接收方的socket，没有字节的丢失或者冗余

TCP还具有拥塞控制，当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程

UDP

UDP 是无连接的，在两个进程通信前没有握手的过程。
UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个保温发送金UDP套接字时，UDP协议并不能保证该报文将到达接收进程。
UDP没有拥塞机制。所以UDP的发送端可以用它选定的任何速率向其下层注入数据。

HTTP: Web

HTTP概况

Web的应用层协议是HTTP(超文本传输协议)，它是Web的核心。超文本传输协议可以进行文字分割：超文本（Hypertext）、传输（Transfer）、协议（Protocol），它们之间的关系如下

按照范围的大小协议 > 传输 > 超文本。下面就分别对这三个名次做一个解释。

什么是超文本

在互联网早期的时候，我们输入的信息只能保存在本地，无法和其他电脑进行交互。我们保存的信息通常都以文本即简单字符的形式存在，文本是一种能够被计算机解析的有意义的二进制数据包。而随着互联网的高速发展，两台电脑之间能够进行数据的传输后，人们不满足只能在两台电脑之间传输文字，还想要传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转，那么文本的语义就被扩大了，这种语义扩大后的文本就被称为超文本(Hypertext)。

什么是传输

那么我们上面说到，两台计算机之间会形成互联关系进行通信，我们存储的超文本会被解析成为二进制数据包，由传输载体（例如同轴电缆，电话线，光缆）负责把二进制数据包由计算机终端传输到另一个终端的过程称为传输(transfer)。

HTTP由两个程序实现：一个客户程序和一个服务器程序。两者运行在不同的端系统中，通过交换HTTP报文进行会话。它们之间的关系如下：

什么是协议

协议这个名词不仅局限于互联网范畴，也体现在日常生活中，比如情侣双方约定好在哪个地点吃饭，这个约定也是一种协议，比如你应聘成功了，企业会和你签订劳动合同，这种双方的雇佣关系也是一种 协议。注意自己一个人对自己的约定不能成为协议，协议的前提条件必须是多人约定。

那么网络协议是什么呢？

网络协议就是网络中(包括互联网)传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样，计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为网络协议。

没有网络协议的互联网是混乱的，就和人类社会一样，人不能想怎么样就怎么样，你的行为约束是受到法律的约束的；那么互联网中的端系统也不能自己想发什么发什么，也是需要受到通信协议约束的。

那么我们就可以总结一下，什么是 HTTP？可以用下面这个经典的总结回答一下： HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范

Web页面是由多个对象组成的，一个对象只是一个文件比如一个HTML文件，一个JPEG图形等，它们可以通过一个URL寻址。

HTTP定义了Web客户向Web服务器请求Web页面的方式：

当用户请求一个Web页面时，浏览器想服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应

HTTP使用TCP作为支撑运输的协议，而TCP为HTTP提供可靠数据传输服务。这意味着，每一个请求报文和响应报文都能送达目的端。因此，HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。

HTTP是一个无状态协议。其表现为：假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不在做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前做过的一样，服务器并不保存关于客户的任何信息。

非持续连接和持续连接

非持续连接：每个请求/响应对是经一个单独的TCP连接发送的

持续连接：每个请求/响应对是经相同的TCP连接发送的

现在我们来细致地讨论一下持续连接和非持续连接的优缺点。

非持续连接

假如一个Web含有一个HTML 基本文件和10个JPEG 图形，并且这11个对象位于同一台服务器上。假设该HTML文件的URL为： http://www.someSchool.edu/someDepartment/home.index

那么整个传输过程如下：

HTTP Client 发起一个到服务器www.someSchool.edu的TCP连接。
HTTP Client 客户经它的套接字向该服务器发送一个HTTP请求报文，包含了路径名 /someDepartment/home.index
HTTP Server 收到请求报文，检索处对象 http://www.someSchool.edu/someDepartment/home.index ，在一个HTTP响应报文中封装对象，并通过其Socket向客户发送响应报文
HTTP Server通知TCP断开TCP连接，直到TCP Client已经完整收到响应报文，才会实际中断连接
HTTP Client 收到响应报文，TCP连接关闭，Client 检查HTML文件，得到对10个JPEG文件的引用
对10个JPEG文件重复前面四个步骤。

因此，Web中有几个对象，就要产生几个TCP连接。

RTT 的概念

RTT(Round-Trip Time) 往返时间指的是一个段分组从客户到服务器然后再返回客户所花费的时间。我们尝试用RTT来表示客户点击超链接后页面出现的时间，如下图所示：

粗略地讲，总的响应时间就是两个RTT 再加上服务器传输HTML文件的时间

持续连接

上面讲的非持续连接有一些缺点

必须为每一个请求的对象建立和维护一个全新的连接。这给Web服务器带来了严重的负担
每一个对象经受两倍RTT的交付时延，累计起来是一个很大的数字

采用持续连接，服务器在发送响应后应该保持该TCP连接打开。在相同的客户与服务器之间，后续请求和响应报文可以通过相同的连接进行传送。

HTTP报文

详见我的博客： HTTP协议

cookie 允许站点对用户进行跟踪，把内容与用户身份联系起来。

cookie 技术有4个组件：

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

原理如下图所示

当客户端请求服务器时，如果服务器需要记录该用户状态，就在响应头中向客户端浏览器颁发一个Cookie，而客户端浏览器会把cookie保存起来。当再次请求该网站时，浏览器把请求的网站连同该cookie一起提交给服务器，服务器会检查该cookie，以此来辨认用户状态。

Web 缓存

Web缓存器也叫代理服务器，其模式如下图所示：

代理服务器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。这时，假设浏览器正在请求对象 http://www.someschool.com/campus.gif对象，将会发生一下情况：

浏览器创建一个到代理服务器的TCP连接，并向代理服务器发送一个HTTP请求
代理服务器收到请求后，看看本地是否存储了该对象副本。如果有，Web缓存器就向客户的浏览器用HTTP响应报文返回该对象
如果Web缓存器没有该对象，就打开一个与该对象的初始服务器的TCP连接并发送HTTP请求。收到请求后，出事服务器向该Web缓存器发送具有该对象的HTTP响应
当Web缓存器接收到该对象时，他在本地存储空间存储一份副本，并向客户的浏览器发送该副本

所以说，一个Web缓存器既是服务器又是客户。当他接收浏览器的请求并发回响应时，是一个服务器。它向初始服务器发送请求并接收响应时它是一个客户。

SMTP: 电子邮件

下图给出了电子邮件系统的总体情况，我们可以看到它有3个主要的组成部分：用户代理、邮件服务器、SMTP

用户代理比如说：Foxmail，Outlook ，Apple Mail 这类的软件

邮件服务器：qq邮箱，163邮箱，Gmail之类的邮件服务

SMTP则是简单邮件传输协议。

SMTP是因特网电子邮件的核心。它使用TCP可靠数据传输服务。每台邮件服务器上既运行着SMTP的客户端也运行着SMTP的服务器端。当一个邮件服务器向其他邮件服务器发送邮件时，他就是SMTP的客户；当邮件服务器从其他邮件服务器上接收邮件时，他就表现为一个SMTP的服务器。

假设Alice 想给 Bob发送一份简单的报文。

Alice调用它的邮件代理程序并提供Bob的邮件地址，撰写报文，然后指示用户代理发送该报文
Alice的用户代理把报文发给她的邮件服务器，在那里，该报文被放在报文队列中
运行在Alice的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，他就创建一个到运行在Bob的邮件服务器上的SMTP服务器的TCP连接
在经过一些初始的SMTP握手后，SMTP客户通过该TCP连接发送Alice的报文。
在Bob的邮件服务器上，SMTP的服务器端接收该报文。Bob的邮件服务器然后将该报文放入Bob的邮箱中。
在Bob有时间的时候，它调用用户代理阅读该报文。

注意：SMTP 一般不适用中间邮件服务器发送邮件，如果Bob的邮件服务器没有开机，该报文会保留在ALice的邮件服务器上并等待新的尝试。

现在你知道了两台邮件服务器邮件发送的大体过程，那么，SMTP 是如何将邮件从 Alice 邮件服务器发送到 Bob 的邮件服务器的呢？主要分为下面三个阶段

建立连接：在这一阶段，SMTP 客户请求与服务器的25端口建立一个 TCP 连接。一旦连接建立，SMTP 服务器和客户就开始相互通告自己的域名，同时确认对方的域名。
邮件传送：一旦连接建立后，就开始邮件传输。SMTP 依靠 TCP 能够将邮件准确无误地传输到接收方的邮件服务器中。SMTP 客户将邮件的源地址、目的地址和邮件的具体内容传递给 SMTP 服务器，SMTP 服务器进行相应的响应并接收邮件。
连接释放：SMTP 客户发出退出命令，服务器在处理命令后进行响应，随后关闭 TCP 连接。

与HTTP的对比

相同点

HTTP 是从Web服务器向Web客户传送文件；SMTP事一个邮件服务器向另一个邮件服务器传送文件
当进行文件传送时，持续的HTTP和SMTP都采用持续连接

不同点

HTTP主要是 拉协议(pull protocol)，即用户使用HTTP从该服务器拉取信息;而SMTP基本上是一个推协议(push protocol)，及发送邮件服务器把文件推向接收邮件服务器
SMTP要求每个报文采用 7 比特的ASCII 码格式。HTTP数据则不受这些限制
HTTP把每个对象分装到它自己的HTTP响应报文中去，而SMTP则把所有报文对象放在一个报文之中。

报文格式

详见我的博客 WireShark 抓取SMTP 数据包

因特网邮件访问协议

Bob的用户代理不能使用SMTP得到报文，因为获取报文是一个拉操作，而SMTP协议是一个推协议。这就需要引入一个特殊的邮件访问协议来解决，该协议将Bob邮件服务器上的报文传送给他本地的PC。目前有一些流行的访问协议：POP3、IMAP以及HTTP

POP3

POP3 是一个极为简单的邮件访问协议。POP3按照三个阶段进行工作：

Authorization(特许)，用户代理发送用户名和口令以鉴别用户
事务处理阶段，用户代理取回报文。同时还能进行如下操作：对报文做删除标记，取消报文删除标记，获取邮件统计信息
更新阶段，出现在客户发出了quit命令之后，目的是结束该POP3会话。这时，该邮件服务器会删除那些被标记为删除的报文

在POP3的事务处理过程中，用户代理的回答可能有OK(正常)和-ERR(出现差错)

在事务处理阶段，POP3的用户代理通常被配置为”下载并删除”或者“下载并保留”方式。

下载并删除

这种方式存在的问题是，邮件接收方Bob可能是移动的，可能希望从多个不同的机器访问他的邮件报文，如从办公室的PC和笔记本来访问邮件。那么，如果Bob先在办公室的PC上收取了一条邮件，那么晚上当他在家里时，他便不能再通过笔记本收取该邮件

下载并保留

用户代理下载某邮件之后该邮件仍然保留在邮件服务器上。这样Bob就能通过不同的及其重新读取这些邮件

IMAP

IMAP 是另一个邮件访问协议，它比 POP3具有更多的特色，不过也比POP3复杂得多。 POP3 会对移动用户带来问题。IMAP更喜欢使用一个在远程服务器上的层次文件夹，这样他可以从任何一台机器上对所有报文进行访问，但是POP3协议并没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。

IMAP服务器把每个报文与一个文件夹联系起来，当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联。收件人作为能够把邮件移到一个新的用户创建的文件夹中来阅读邮件、删除邮件等。
IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令
IMAP 还为用户提供了在远程文件夹中查询邮件的命令
IMAP 服务器维护了IMAP会话的用户状态信息
IMAP 具有允许用户代理获取报文某些部分的命令。例如，一个用户代理可以只读取一个报文的首部。

基于Web的电子邮件

比如网页端的QQ邮箱，网易邮箱。使用这种服务，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信通过HTTP进行：

收件人从邮箱中访问一个报文时，该电子邮件报文从Bob的邮件服务器发送到他的浏览器，使用的是HTTP而不是POP3或者IMAP协议
当发件人要发送一封电子邮件报文时，该电子邮件豹纹从浏览器发送到邮件服务器使用的是HTTP报文而不是SMTP
但是，邮件服务器之间发送和接收邮件时，仍然使用SMTP

DNS: 因特网的目录服务

首先我们要搞清楚主机名和IP地址的关系。

主机名如：facebook.com、google.com 等但是，主机名几乎没有提供关于主机在因特网中位置的信息，这让路由器难以处理

IP 地址：由4个字节组成，并有着严格的层次结构。例如 121.7.106.83 这样一个 IP 地址，其中的每个字节都可以用 . 进行分割，表示了 0 - 255 的十进制数字。

我们需要一种进行主机名到IP地址转换的目录服务，这就是DNS的主要任务。DNS是：

一个由分层的DNS服务器实现的分布式数据库
一个使得主机能够查询分布式数据库的应用层协议

如下图所示：

总的来说，在单一DNS服务器上运行集中式数据库完全没有可扩展能力。因此，DNS采用了分布式设计方案。

DNS工作机理概述

DNS 是一个复杂的系统，我们在这里只是就其运行的主要方面进行学习，下面给出一个 DNS 工作过程的总体概述

假设运行在用户主机上的某些应用程序（如 Web 浏览器或邮件阅读器）需要将主机名转换为 IP 地址。这些应用程序将调用 DNS 的客户端，并指明需要被转换的主机名。用户主机上的 DNS 收到后，会使用 UDP 通过 53 端口向网络上发送一个 DNS 查询报文，经过一段时间后，用户主机上的 DNS 会收到一个主机名对应的 DNS 回答报文。因此，从用户主机的角度来看，DNS 就像是一个黑盒子，其内部的操作你无法看到。但是实际上，实现 DNS 这个服务的黑盒子非常复杂，它由分布于全球的大量 DNS 服务器以及定义了 DNS 服务器与查询主机通信方式的应用层协议组成。

DNS 最早的一种简单设计只是在因特网上使用一个 DNS 服务器。该服务器会包含所有的映射。这是一种集中式的设计，这种设计并不适用于当今的互联网，因为互联网有着数量巨大并且持续增长的主机，这种集中式的设计会存在以下几个问题

单点故障(a single point of failure)，如果 DNS 服务器崩溃，那么整个网络随之瘫痪。
通信容量(traaffic volume)，单个 DNS 服务器不得不处理所有的 DNS 查询，这种查询级别可能是上百万上千万级
远距离集中式数据库(distant centralized database)，单个 DNS 服务器不可能 邻近 所有的用户，假设在美国的 DNS 服务器不可能临近让澳大利亚的查询使用，其中查询请求势必会经过低速和拥堵的链路，造成严重的时延。
维护(maintenance)，维护成本巨大，而且还需要频繁更新。

所以 DNS 不可能集中式设计，它完全没有可扩展能力，因此采用分布式设计，所以这种设计的特点如下

分布式、层次数据库

没有一台DNS服务器拥有因特网上所有主机的映射。大致来说，有3种类型的DNS服务器：根DNS服务器、顶级域DNS服务器和权威DNS服务器。

根DNS服务器

有400多个根服务器遍及全世界。根名字服务器提供TLD服务器的IP地址

顶级域DNS服务器。

对于每个顶级域(如com、org、edu) 和所有国家的顶级域(uk,cn)等，都有TLD(Top-Level Domain)服务器. TLD服务器提供了权威DNS服务器的IP地址

权威DNS服务器

一个组织机构的权威DNS收藏了DNS记录。另一种方法是，该组织能够支付费用，让这些记录存储在某个服务提供商的一个权威DNS服务器中。多数大学和大公司实现和维护他们自己基本和备份的权威DNS服务器。

查询方式

第一个步骤是本机向本地域名服务器发出一个DNS请求报文，报文里携带需要查询的域名；第二个步骤是本地域名服务器向本机回应一个DNS响应报文，里面包含域名对应的IP地址或者别名等。由两种查询方法：

递归查询：本机向本地域名服务器发出一次查询请求，就静待最终的结果。如果本地域名服务器无法解析，自己会以DNS客户机的身份向其它域名服务器查询，直到得到最终的IP地址告诉本机

迭代查询：本地域名服务器向根域名服务器查询，根域名服务器告诉它下一步到哪里去查询，然后它再去查，每次它都是以客户机的身份去各个服务器查询

注意：理论上，任何DNS查询机可以是迭代的也可以是递归的。在实践中，第一个步骤从主机到本地域名服务器是递归查询；第二大步骤中采用的是迭代查询，其实是包含了很多小步骤的，如下图所示。

DNS报文分析

详见博客： DNS协议

P2P

当一个单一服务器向大量主机分发一个大文件时，就必须向每个对等方发送该文件的一个副本。折让服务器承受了极大地负担，消耗了大量服务器带块。而使用P2P结构，每个对等方能够向任何其他对等方重新分发他已经收到的该文件的任何部分，从而在分发的过程中协助该服务器。

P2P 体系结构的扩展性

如下图所示，服务器和对等方使用接入链路与因特网相连。其中

$u_s$ 表示服务器接入链路的上载速率

$u_i$表示第i对等方接入链路的上载速率

$d_i$ 表示第i 对等方接入链路的下载速率

$F$表示备份发的文件长度(bit)

$N$表示要获得的该文件副本的对等方数量

我们可以这样来定义分发时间： 是所有N个对等方得到该文件的副本所需要的时间。

首先我们假设因特网核心具有足够的带宽，这样所有瓶颈都在网络接入链路。还假设服务器和客户没有参与任何其他网络应用，因此他们的所有上传和下载访问贷款能被全部用于分发该文件。

对于客户-服务器体系结构

我们将客户服务器体系结构的分发时间记为 $D_{cs}$

服务器必须向N个对等方传输该文件的一个副本。因此服务器必须传输NF 比特。因为该服务器上载的速度是 $u_s$, 分发该文件的时间必定是至少为 $NF/u_s$
令$d{\min}$ 表示具有最小下载速率的对等方的下载速率，即 $d{\min}=\min{d1,\cdots,d_N }$,具有最小下载速率的对等方至少需要 $F/d{\min}$ 的时间内获得F比特。因此最小分发的时间至少为 $F/d_{\min}$

结合两者，我们得到：

$D_{cs} \geq \max\{\frac{NF}{u_s},\frac{F}{d_{\min}}\}$

我们可以直接取其下界。也就是$D{cs} = \max{\frac{NF}{u_s},\frac{F}{d{\min}}}$

那么，对于足够大的N，客户-服务器分发时间为 $\frac{NF}{u_s}$ 。这和用户的数量成线性增加的关系。

对于P2P 体系结构

在P2P体系结构中，每个对等方(用户)能够帮助服务器分发该群文件。特别的，当一个对等方接收到某些文件数据时，能够使用自己的上载能力重新将数据分发给其他对等方。

在分发的开始，只有服务器具有稳健。因此该服务器必须接入链路发送该文件的每个比特1次。因此最小的分发时间为 $\frac{F}{u_s}$
与客户-服务器体系结构相同，具有最小下载速率的对等方至少需要 $F/d{\min}$ 的时间内获得F比特。因此最小分发的时间至少为 $F/d{\min}$
最后，观察到系统整体的总上载能力等于服务器的上载速率加上每个单独的对等方上载速率。即：$u_{total} = u_s+u_1+\cdots+u_N$ 。系统必须总共交付NF bit。因此，最小的分发时间最小是： $NF/(u_s+u_1+\cdots+u_N)$

将这三个观察放在一起，我们获得了对P2P的最小分发时间，表示为 $D_{P2P}$

$D_{P2P}\geq \max\{\frac{F}{u_s},\frac{F}{d_{\min}},\frac{NF}{u_s+u_1+\cdots+u_N}\}$

同样的我们可取其下界。$D{P2P}= \max{\frac{F}{u_s},\frac{F}{d{\min}},\frac{NF}{u_s+u_1+\cdots+u_N}}$

我们假设$F/u=1h,us=10\mu,d{\min}\geq u_s$ 并画出图像如下图

我们发现具有P2P 体系结构的应用程序可以自扩展。

视频流和内容分发网

因特网视频

在流式存储视频应用中，最基础的媒体是预先录制的视频例如电影、电视节目、录制好的体育事件或者用户生成的视频。这些预先录制好的视频会放置在服务器上，用户按需向服务器发送请求来观看视频。许多因特网公司现在提供流式视频，这些公司包括 Netflix、YouTube 、亚马逊和优酷等。

视频式一系列的图像，通常会以一种恒定的速率（如每秒 24 或 30 张图像）来展现。一幅未压缩、数字编码的图像由像素阵列组成，其中每个像素又一些比特编码来表示亮度和颜色。视频的一个重要特征是它能够被压缩、因而可用比特率来权衡视频质量。

HTTP 流和 DASH

在 HTTP 流中，视频只是存储在 HTTP 服务器中的一个文件，每个文件有特定的 URL。当用户想要看视频时，客户与服务器创建一个 TCP 连接并发送该 URL 的 HTTP GET 请求。服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个 HTTP 响应中发送该文件视频。

尽管 HTTP 流在实践中已经得到广泛部署，但是它由严重缺陷，即所有客户接收到相同编码的视频，但是对于客户而言，带宽时动态变化的，在不同的时间，带宽大小有很大不同。这种情况导致了一种新型 HTTP 流的研发，它常常被称为 经 HTTP 的动态适应性流(Dynamic Adaptive Streaming over HTTP, DASH)。在 DASH 中，视频编码为几个不同的版本，每个版本对应不同的比特率。

DASH 允许客户使用不同的以太网接入速率流失播放具有不同编码速率的视频。使用 3G 连接的客户能够接受一个低比特率的版本，使用光纤能够接受高比特率的版本。

使用 DASH 后，每个视频版本存储在 HTTP 中，每个版本都有一个不同的 URL。HTTP 服务器也会有一个 告示文件(manifest file)，为每个版本提供了一个 URL 及其比特率。

内容分发网

现如今，许多因特网视频公司日复一日地向数以百万计的用户按需分发每秒数兆比特的流。对于一个因特网视频公司，或许提供流式视频服务最为直接的方法是建立一个单一的超大规模的数据中心。在数据中心内部存储所有视频，然后把视频返回到全世界范围内的客户。这种方式存在三个问题

如果客户远离数据中心，服务器到客户的分组将跨越许多通信链路并可能通过很多 ISP，造成通信延迟
流式视频可能经过相同的链路发送了许多次，造成带宽和资源浪费。
单点问题，如果单一结点故障，这可能是灾难性的。

为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用 内容分发网(Content Distribution Network, CDN)。 CDN 管理分布在多个地理位置上的服务器，在它的服务器上存储视频副本，并且所有试图将每个用户请求定向到一个提供最好用户体验的 CDN 位置。那么服务器如何选址呢？事实上有两种服务器安置原则

深入，它的主要目标是靠近用户，通过减少端用户和 CDN 集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量。
邀请做客，这个原则是通过在少量（例如 10 个）关键位置建造大集群来邀请 ISP 来做客，这些CDN集群通常放在因特网交换结点(IXP). 与深入设计原则相比，好处是产生较低的维护和管理开销. 缺点是以对端用户的较高时延和较低吞吐量为代价.

CDN 可以是专用 CDN(private CDN), 即它由内容提供商自己所拥有；另一种 CDN 是 第三方 CDN(third-party CDN)，它代表多个内容提供商分发内容。

除了如时延, 丢包和带宽性能等网络相关的考虑外, 设计一种CDN服务器选择策略时还有其他重要因素. 它们是什么?

还要考虑它分发的内容.

CDN 分发过程

上面我们探讨了一下 CDN 的选址过程，那么 CDN 是如何工作的呢？

当用户主机中的一个浏览器指令检索一个特定的视频（由 URL 标识）时，CDN 必须能够截获请求，来进行下面的操作

确定此时适用于该客户的 CDN 服务器集群
将客户的请求重定向到集群中的某台服务器上

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

下面是 CDN 的具体工作流程

假设一个内容提供商 NetCinema ，雇用了第三方 CDN 公司 KingCDN 来向它的客户分发视频。在 NetCinema 的 Web 网页上，它的每个视频都被指派了一个 URL，该 URL 包括了字符串 video 以及视频本身的标识符。下面要访问 http://video.netcinema.com/6Y7B23V ，它的工作过程如下

用户访问位于 NetCinema 的 Web 网页
当用户点击链接 http://video.netcinema.com/6Y7B23V 时，该用户主机发送了对于 video.netcinema.com的 DNS 请求
用户本地 DNS 服务器(LDNS， Local DNS) 将该 DNS 请求中继到一台用于 NetCinema 的权威 DNS 服务器，该服务器观察到主机名 video.netcinema.com 中的字符串 video。为了将该 DNS 请求移交给 KingCDN，NetCinema 权威 DNS 服务器并不返回一个 IP 地址，而是向 LDNS 返回一个 KingCDN 域的主机名，如 a1105.kingcdn.com
从此时起，DNS 请求就会进入 KingCDN 专用 DNS 基础设施，用户的 LDNS 则发送第二个请求，此时是对 a1105.kingcdn.com 的 DNS 请求，KingCDN 的 DNS 系统最终向 LDNS 返回 KingCDN 内容服务器的 IP 地址。所以正是这里，在 KingCDN 的 DNS 系统中，指定了 CDN 服务器，客户将能够从这台服务器接收它的内容
LDNS 向用户主机转发内容服务 CDN 节点的 IP 地址
一旦客户收到 KingCDN 内容服务器的 IP 地址，它与具有该 IP 地址的服务器创建一条 TCP 连接，并且发出对该视频的 HTTP GET 请求。如果使用了 DASH，服务器将首先向客户发送具有 URL 列表的告示文件，每个 URL 对应视频的每个版本，并且客户将动态的选择来自不同版本的块。

CDN 的集群选择策略

任何 CDN 的部署，其核心是 集群选择策略(cluster selection strategy)，即动态的将客户定向到 CDN 中某个服务器集群或数据中心的机制。一种简单的策略是指派客户到 地理上最为临近(geographically closest) 的集群。这种选择策略忽略了时延和可用带宽随因特网路径时间而变化，总是为特定的客户指派相同的集群；还有一种选择策略是 实时测量(real-time measurement)，该机制是基于集群和客户之间的时延和丢包性能执行周期性检查。

总结

应用层协议分类

域名系统(Domain Name System, DNS)：用于实现网络设备名字到 IP 地址映射的网络服务。
文件传输协议(File Transfer Protocol，FTP)：用于实现交互式文件传输功能。
邮件传送协议(Simple Mail Transfer Protocol, SMTP)：用于实现电子邮箱传送功能。
超文本传输协议(HyperText Transfer Protocol，HTTP)：用于实现 Web 服务。
远程登录协议(Telnet)：用于实现远程登录功能。

复习题

R26 2.7节中所描述的UDP服务器仅需要一个套接字, 而TCP服务器需要两个套接字. 为什么? 如果TCP服务器支持n个并行连接, 每条连接来自不同的客户主机, 那么TCP服务器需要多少个套接字.

因为UDP是面向无连接的, 它的服务器只需要有一个套接字用于接收和发送, 并且可以接收来自不同地址主机的UDP包. 而TCP是面向连接的, 除了接收访问的套接字, 每和一个客户连接就要创建一个专用的套接字，称之为连接套接字
n+1个.

R27 对于2.7节所描述的运行在TCP之上的客户-服务器应用程序, 服务器程序为什么必须先于客户程序运行? 对于运行在UDP之上的客户-服务器应用程序, 客户程序为什么可以先于服务器程序运行.

建立TCP连接需要经过一个3次握手的过程, 如果服务器没有启动根本无法握手, 从而无法创建连接.
UDP是面向无连接的, 就算服务器没有启动, 客户程序照样可以把UDP发出去, 但服务器可能就收不到了.