【网络篇】计算机网络——应用层详述（笔记）

例如，在 Web 应用程序中，有两个互相通信的不同的程序：一个是运行在用户主机（桌面机、平板电脑、智能电话等）上的浏览器程序；另一个是运行在 Web 服务器主机上的 Web 服务器程序。

另一个例子是 P2P 文件共享系统，在参与文件共享的社区中的每台主机中都有一个程序。在这种情况下，在各台主机中的这些程序可能都是类似的或相同的。

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

重要的是，不需要写在网络核心设备如路由器或链路层交换机上运行的软件。即使你要为网络核心设备写应用程序软件，也不能做到这一点。

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

2. 网络应用程序体系结构

从应用程序研发者的角度看，网络体系结构是固定的，并为应用程序提供了特定的服务集合。在另一方面，应用程序体系结构（application architecture）由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。

现代网络应用程序中所使用的两种主流体系结构为：++客户-服务器体系结构或对等（P2P）体系结构++。

（1）客户-服务器体系结构（client-server architecture）

在客户-服务器体系结构（client-server architecture）中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。一个典型的例子是 Web 应用程序，其中总是打开的 web 服务器服务于来自浏览器（运行在客户主机上）的请求。当 Web 服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应。

值得注意的是利用客户-服务器体系结构，客户相互之间不直接通信。客户-服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为 IP 地址。

因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的 IP 地址发送分组来与其联系。

在一个客户-服务器应用中，常常会出现一台单独的服务器主机跟不上它所有客户请求的情况，配备大量主机的数据中心（data center）常被用于创建强大的虚拟服务器。

（2） P2P 体系结构（P2P architecture）

在一个 P2P 体系结构（P2P architecture）中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。这些对等方并不为服务提供商所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。

因为这种对等方通信不必通过专门的服务器，该体系结构被称对等方到对等方的 。需要提及的是，某些应用具有混合的体系结构，它结合了客户-服务器和 P2P 的元素。

P2P 体系结构的最引人入胜的特性之一是它们的自扩展性（self-scalability）。例如，在一个 P2P 文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

3. 进程间通讯

用操作系统的术语来说，进行通信的实际上是进程（process）而不是程序。一个进程可以被认为是运行在端系统中的一个程序。

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

在两个不同端系统上的进程，通过跨越计算机网络交换 **报文（message）**而相互通信。发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过回送报文进行响应。

（1）客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。

例如，在 Web 应用程序中，一个客户浏览器进程与一台 Web 服务器进程交换报文。在一个 P2P 文件共享系统中，文件从一个对等方中的进程传输到另一个对等方中的进程。

对每对通信进程，我们通常将这两个进程之一标识为 客户（client） ，而另一个进程标识为服务器（server）。

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

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

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

多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。

考虑一个类比理解进程和套接字。

进程可类比于一座房子，而它的套接字可以类比于它的门。当一个进程想向位于另外一台主机上的另一个进程发送报文时，它把报文推出该门（套接字）。++该发送进程假定该门到另外一侧之间有运输的基础设施，该设施将把报文传送到目的进程的门口。++一旦该报文抵达目的主机，它通过接收进程的门（套接字）传递，然后接收进程对该报文进行处理。

如上图所示，套接字是同一台主机内应用层与运输层之间的接口。

由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为 应用程序和网络之间的应用程序编程接口（Application Programming Interface, API） 。应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。

应用程序开发者对于运输层的控制仅限于：

① 选择运输层协议；

② 也许能设定几个运输层参数，如最大缓存和最大报文段长度等。

一旦应用程序开发者选择了一个运输层协议（如果可供选择的话），则应用程序就建立在由该协议提供的运输层服务之上。

（3）进程寻址

为了向特定目的地发送邮政邮件，目的地需要有一个地址。类似地，在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。

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

① 主机的地址；

② 在目的主机中指定接收进程的标识符。

在因特网中，主机由其**IP 地址（IP address）**标识，IP 地址是一个 32 比特的量且它能够唯一地标识该主机。

除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程（更具体地说，接收套接字）。因为一般而言一台主机能够运行许多网络应用，这些信息是需要的。目的地端口号（port number）用于这个目的。

二、Web 和 HTTP

20 世纪 90 年代初期，一个主要的新型应用即万维网（World Wide Web）登上了舞台。Web 是一个引起公众注意的因特网应用，它极大地改变了人们与工作环境内外交流的方式。它将因特网从只是很多数据网之一的地位提升为仅有的一个数据网。

1. 初识HTTP

Web 的应用层协议是 超文本传输协议（HyperText Transfer Protocol, HTTP），它是 Web 的核心，在［RFC 1945］和［RFC 2616］中进行了定义。

HTTP 由两个程序实现：一个客户程序和一个服务器程序。

客户程序和服务器程序运行在不同的端系统中，通过交换 HTTP 报文进行会话。HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方式。

Web 页面（Web page）（也叫文档）是由对象组成的。一个对象（object）只是一个文件，诸如一个 HTML 文件、一个 JPEG 图形、一个 Java 小程序或一个视频片段这样的文件，且它们可通过一个 URL 地址寻址。

多数 Web 页面含有一个 HTML 基本文件（base HTMLfile）以及几个引用对象。例如，如果一个 Web 页面包含 HTML 文本和 5 个JPEG 图形，那么这个 Web 页面有 6 个对象：一个 HTML 基本文件加 5 个图形。

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

因 Web 浏览器（Web browser）实现了 HTTP 的客户端，所以在 Web 环境中我们经常交替使用**" 浏览器 " 和 " 客户 "**这两个术语。

Web 服务器（Web server）实现了 HTTP 的服务器端，它用于存储 Web 对象，每个对象由 URI 寻址。HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web 页面的方式。

流行的 Web 服务器有 Apache 和 Microsoft Internet Information Server（微软互联网信息服务器）。

上图中，当用户请求一个 Web 页面（如点击一个超链接）时，浏览器向服务器发出对该页面中所包含对象的 HTTP 请求报文，服务器接收到请求并用包含这些对象的 HTTP 响应报文进行响应。

HTTP 使用 TCP 作为它的支撑运输协议（而不是在 UDP 上运行）。

HTTP 客户首先发起一个与服务器的 TCP 连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP。

客户端的套接字接口是客户进程与 TCP 连接之间的门，在服务器端的套接字接口则是服务器进程与 TCP 连接之间的门。客户向它的套接字接口发送 HTTP 请求报文并从它的套接字接口接收 HTTP 响应报文。

类似地，服务器从它的套接字接口接收 HTTP 请求报文和向它的套接字接口发送 HTTP 响应报文。++一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入 TCP 的控制++。

TCP 为 HTTP 提供可靠数据传输服务。这意味着，一个客户进程发出的每个 HTTP 请求报文最终能完整地到达服务器；类似地，服务器进程发出的每个 HTTP 响应报文最终能完整地到达客户。

这里分层体系结构最大的优点，即 **HTTP 协议不用担心数据丢失，也不关注 TCP 从网络的数据丢失和乱序故障中恢复的细节。**那是 TCP 以及协议栈较低层协议的工作。

注意：

++服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。++ 假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。因 HTTP 服务器并不保存关于客户的任何信息，所以我们说 HTTP 是一个无状态协议（stateless protocol）。

2. 非持续连接和持续连接

在许多因特网应用程序中，客户和服务器在一个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。当这种客户-服务器的交互是经 TCP 进行的，应用程序的研制者就需要做一个重要决定，即 ++每个请求/响应对是经一个单独的 TCP 连接发送，还是所有的请求及其响应经相同的 TCP 连接发送。++

采用前一种方法，该应用程序被称为使用非持续连接（non-persistent connection）；采用后一种方法，该应用程序被称为使用持续连接（persistent connection）。

（1）采用非持续连接的 HTTP

在非持续连接情况下，从服务器向客户传送一个 Web 页面的步骤。

假设该页面含有一个 HTML 基本文件和 10 个 JPEC 图形，并且这 11 个对象位于同一台服务器上。进一步假设该 HTML 文件的 URL 为：

http://www.someSchool.edu/someDepartment/home.index。

① HTTP 客户进程在端口号 80 发起一个到服务器 www.someSchool.edu 的 TCP 连接，该端口号是 HTTP 的默认端口。在客户和服务器上分别有一个套接字与该连接相关联。

② HTTP 客户经它的套接字向该服务器发送一个 HTTP 请求报文。请求报文中包含了路径名 /someDepartment/home.index。

③ HTTP 服务器进程经它的套接字接收该请求报文，从其存储器（RAM 或磁盘）中检索出对象 www.someSchool.edu/someDepartment/home.index，在一个 HTTP 响应报文中封装对象，并通过其套接字向客户发送响应报文。

④ HTTP 服务器进程通知 TCP 断开该 TCP 连接。（但是直到 TCP 确认客户已经完整地收到响应报文为止，它才会实际中断连接）

⑤ HTTP 客户接收响应报文，TCP 连接关闭。该报文指出封装的对象是一个 HTML 文件，客户从响应报文中提取出该文件，检查该 HTML 文件，得到对 10 个 JPEG 图形的引用。

⑥ 对每个引用的 JPEG 图形对象重复前 4 个步骤。

当浏览器收到 Web 页面后，向用户显示该页面。两个不同的浏览器也许会以不同的方式解释（即向用户显示）该页面。HTTP 与客户如何解释一个 Web 页面毫无关系。HTTP 规范（［RFC 1945］和［RFC 2616］）仅定义了在 HTTP 客户程序与 HTTP 服务器程序之间的通信协议。

上述步骤中，++每个 TCP 连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。每个 TCP 连接只传输一个请求报文和一个响应报文。++ 因此这里，当用户请求该 Web 页面时，要产生 11 个 TCP 连接。

其他的，用户能够配置现代浏览器来控制连接的并行度。

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

这里来简单估算一下从客户请求 HTML 基本文件起到该客户收到整个文件止所花费的时间。为此给出 **往返时间（Round-Trip Time，RTT）**的定义，该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。

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

当用户点击超链接时，这引起浏览器在它和 Web 服务器之间发起一个 TCP 连接；这涉及一次 " 三次握手 " 过程，即客户向服务器发送一个小 TCP 报文段，服务器用一个小 TCP 报文段做出确认和响应，最后客户向服务器返回确认。三次握手中前两个部分所耗费的时间占用了一个 RTT。

完成了三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该 TCP 连接发送一个 HTTP 请求报文。一旦该请求报文到达服务器，服务器就在该 TCP 连接上发送 HTML 文件。该 HTTP 请求/响应用去了另一个 RTT。

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

（2）采用持续连接的 HTTP

非持续连接有一些缺点。

第一，必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配 TCP 的缓冲区和保持 TCP 变量，这给 Web 服务器带来了严重的负担，因为一台 Web 服务器可能同时服务于数以百计不同的客户的请求。

第二，每一个对象经受两倍 RTT 的交付时延，即一个 RTT 用于创建 TCP，另一个 RTT 用于请求和接收一个对象。

在采用 HTTP 1.1 持续连接的情况下，服务器在发送响应后保持该 TCP 连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。特别是一个完整的 Web 页面可以用单个持续 TCP 连接进行传送。

更有甚者，位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户时，可以在单个持续 TCP 连接上进行。

对对象的这些请求可以一个接一个地发出，而不必等待对未决请求（流水线）的回答。一般来说，++如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP 服务器就关闭该连接。HTTP 的默认模式是使用带流水线的持续连接++。

最近，HTTP/2［RFC 7540］是在 HTTP 1.1 基础上构建的，它允许在相同连接中多个请求和回答交错，并增加了在该连接中优化 HTTP 报文请求和回答的机制。

cookie 在［RFC 6265］中定义，它 允许站点对用户进行跟踪。目前大多数商务 Web 站点都使用了 cookie。

cookie 技术有 4 个组件：

① 在 HTTP 响应报文中的一个 cookie 首部行。

② 在 HTTP 请求报文中的一个 cookie 首部行。

③ 在用户端系统中保留有一个 cookie 文件，并由用户的浏览器进行管理。

④ 位于 Web 站点的一个后端数据库。

下面通过一个典型的例子看看 cookie 的工作过程。

假设 Susan 总是从家中 PC 使用 InternetExplorer 上网，她首次与 Amazon.com 联系。我们假定过去她已经访问过 eBay 站点。

当请求报文到达该 Amazon Web 服务器时，该 Web 站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。

接下来 Amazon Web 服务器用一个包含 Set-cookie 首部的 HTTP 响应报文对 Susan 的浏览器进行响应，其中 Set-cookie 首部含有该识别码。例如，该首部行可能是 Set-cookie：1678。

当 Susan 的浏览器收到了该 HTTP 响应报文时，它会看到该 Set-cookie 首部。该浏览器在它管理的特定 cookie 文件中添加一行，该行 包含服务器的主机名和在 Set-cookie 首部中的识别码。

值得注意的是该 cookie 文件已经有了用于 eBay 的表项，因为 Susan 过去访问过该站点。++当 Susan 继续浏览 Amazon 网站时，每请求一个 web 页面，其浏览器就会查询该 cookie 文件并抽取她对这个网站的识别码，并放到 HTTP 请求报文中包括识别码的 cookie 首部行中。++

特别是，发往该 Amazon 服务器的每个 HTTP 请求报文都包括首部行（Cookie: 1678）。在这种方式下，Amazon 服务器可以跟踪 Susan 在 Amazon 站点的活动。

尽管 Amazon Web 站点不必知道 Susan 的名字，但它确切地知道用户 1678 按照什么顺序、在什么时间、访问了哪些页面。
如果 Susan 再次访问 Amazon 站点，比如说一个星期后，她的浏览器会在其请求报文中继续放入首部行 cookie：1678。Amazon 将根据 Susan 过去在 Amazon 访问的网页向她推荐产品。如果 Susan 也在 Amazon 注册过，即提供了她的全名、电子邮件地址、邮政地址和信用卡账号，则 Amazon 能在其数据库中包括这些信息，将 Susan 的名字与识别码相关联（以及她在过去访问过的本站点的所有页面），即当 Susan 在后继的访问中选择购买某个物品时，她不必重新输入姓名、信用卡账号或者地址等信息了。

4. Web 缓存

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

Web 缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。可以配置用户的浏览器，使得用户的所有 HTTP 请求首先指向 Web 缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该 Web 缓存器。

举例来说，假设浏览器正在请求对象 http://www.someschool.edu/campus.gif，将会发生如下情况：

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

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

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

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

在因特网上部署 Web 缓存器有两个原因：

首先，web 缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与 Web 缓存器之间的瓶颈带宽时更是如此。如果在客户与 Web 缓存器之间有一个高速连接，并且如果用户所请求的对象在 Web 缓存器上，则web 缓存器可以迅速将该对象交付给用户。

其次，Web 缓存器能够大大减少一个机构的接人链路到因特网的通信量。通过减少通信量，该机构（如一家公司或者一所大学）就不必急于增加带宽，因此降低了费用。

此外，Web 缓存器能从整体上大大减低因特网上的 Web 流量，从而改善了所有应用的性能。

三、因特网的目录服务（DNS）

1. 初识 DNS

识别主机有两种方式，通过主机名或者 IP 地址。人们喜欢便于记忆的主机名标识方式，而路由器则喜欢定长的、有着层次结构的 IP 地址。

为了折中这些不同的偏好，我们需要一种能进行主机名到 IP 地址转换的目录服务。这就是 **域名系统（Domain Name System，DNS）**的主要任务。

DNS 是：

① 一个由分层的 DNS 服务器（DNSserver）实现的分布式数据库；

② 一个使得主机能够查询分布式数据库的应用层协议。
DNS服务器通常是运行 BIND（Berkeley Internet Name Domain）软件［BIND 2012］的 UNIX 机器。DNS 协议运行在 UDP 之上，使用 53 号端口。

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

举个例子，考虑运行在某用户主机上的一个浏览器（即一个 HTTP 客户）请求 URL www.someschool.edu/index.html 页面时会发生什么现象。为了使用户的主机能够将一个 HTTP 请求报文发送到 Web 服务器 www.someschool.edu，该用户主机必须获得 www.someschool.edu 的IP 地址。做法如下：

① 同一台用户主机上运行着 DNS 应用的客户端。

② 浏览器从上述 URL 中抽取出主机名 www.someschool.edu，并将这台主机名传给 DNS 应用的客户端。

③ DNS 客户向 DNS 服务器发送一个包含主机名的请求。

④ DNS 客户最终会收到一份回答报文，其中含有对应于该主机名的 IP 地址。

⑤ 一旦浏览器接收到来自 DNS 的该 IP 地址，它能够向位于该 IP 地址 80 端口的 HTTP 服务器进程发起一个 TCP 连接。

2. DNS 工作机理

DNS 的一种简单设计是在因特网上只使用一个 DNS 服务器，该服务器包含所有的映射。在这种集中式设计中，客户直接将所有查询直接发往单一的 DNS 服务器，同时该 DNS 服务器直接对所有的查询客户做出响应。

尽管这种设计的简单性非常具有吸引力，但它不适用于当今的因特网，因为因特网有着数量巨大（并持续增长）的主机。总的来说，在单一 DNS 服务器上运行集中式数据库完全没有可扩展能力。因此，DNS 采用了分布式的设计方案。

（1）分布式、层次数据库

为了处理扩展性问题，DNS 使用了大量的 DNS 服务器，它们以层次方式组织，并且分布在全世界范围内。没有一台 DNS 服务器拥有因特网上所有主机的映射。相反，这些映射分布在所有的 DNS 服务器上。

大致说来，有 3 种类型的 DNS服务器：根 DNS服务器、顶级域（Top-Level Domain，TLD）DNS 服务器和权威 DNS 服务器。

举个例子，假定一个 DNS 客户要决定主机名 www.amazon.com 的 IP 地址。粗略说来，将发生下列事件：

客户首先与根服务器之一联系，它将返回顶级域名 com 的 TLD 服务器的 IP 地址。该客户则与这些 TLD 服务器之一联系，它将为 amazon.com 返回权威服务器的 IP 地址。最后，该客户与 amazon.com 权威服务器之一联系，它为主机名 www.amazon.com 返回其 IP 地址。

① 根 DNS 服务器

有 400 多个根名字服务器遍及全世界。这些根名字服务器由 13 个不同的组织管理。根名字服务器提供 TLD 服务器的 IP 地址。

② 顶级域（DNS）服务器

对于每个顶级域（如 com、org、net、edu 和 gov）和所有国家的顶级域（如 uk、fr、ca 和 jp），都有 TLD 服务器（或服务器集群）。支持 TLD 的网络基础设施可能是大而复杂的。TLD 服务器提供了权威 DNS 服务器的 IP 地址。

③ 权威 DNS服务器

在因特网上具有公共可访问主机（如 Web 服务器和邮件服务器）的每个组织机构必须提供公共可访问的 DNS 记录，这些记录将这些主机的名字映射为 IP 地址。一个组织机构的权威 DNS 服务器收藏了这些 DNS 记录。一个组织机构能够选择实现它自己的权威 DNS 服务器以保存这些记录；另一种方法是，该组织能够支付费用，让这些记录存储在某个服务提供商的一个权威 DNS 服务器中。

还有另一类重要的 DNS 服务器，称为 本地 DNS 服务器（local DNS server）。严格说来，一个本地 DNS 服务器并不属于上述服务器的层次结构，但它对 DNS 层次结构是至关重要的。

每个 ISP（如一个居民区的 ISP 或一个机构的 ISP）都有一台本地 DNS 服务器（也叫默认名字服务器）。

当主机与某个 ISP 连接时，该 ISP 提供一台主机的 IP 地址，该主机具有一台或多台其本地 DNS 服务器的 IP 地址（通常通过 DHCP）。通过访问 Windows 或 UNIX 的网络状态窗口，用户能够容易地确定他的本地 DNS 服务器的 IP 地址。

主机的本地 DNS 服务器通常 " 邻近 " 本主机。对某机构 ISP 而言，本地 DNS 服务器可能就与主机在同一个局域网中；对于某居民区 ISP 来说，本地 DNS 服务器通常与主机相隔不超过几台路由器。当主机发出 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.edu。

如上图所示，主机 cse.nyu.edu 首先向它的本地 DNS 服务器 dns.nyu.edu 发送一个 DNS 查询报文。该查询报文含有被转换的主机名 gaia.cs.umass.edu。

本地 DNS 服务器将该报文转发到根 DNS 服务器。该根 DNS服务器注意到其 edu 前缀并向本地 DNS 服务器返回负责 edu 的 TLD 的 IP 地址列表。

该本地 DNS 服务器则再次向这些 TLD 服务器之一发送查询报文。该 TLD 服务器注意到umass.edu 前缀，并用权威 DNS服务器的 IP 地址进行响应，该权威 DNS 服务器是负责马萨诸塞大学的 dns.umass.edu。

最后，本地 DNS 服务器直接向 dns.umass.edu 重发查询报文，dns.umass.edu 用 gaia.cs.umass.edu的 IP 地址进行响应。

在本例中，为了获得一台主机名的映射，共发送了 8 份 DNS 报文：4 份查询报文和 4 份回答报文。

（2）DNS 缓存

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

DNS 缓存的原理非常简单。在一个请求链中，当某 DNS 服务器接收一个 DNS 回答（例如，包含某主机名到 IP 地址的映射）时，它能将映射缓存在本地存储器中。

每当本地 DNS 服务器 dns.nyu.edu 从某个 DNS 服务器接收到一个回答，它能够缓存包含在该回答中的任何信息。

如果在 DNS 服务器中缓存了一台主机名/IP 地址对，另一个对相同主机名的查询到达该DNS 服务器时，该 DNS 服务器就能够提供所要求的 IP 地址，即使它不是该主机名的权威服务器。

++由于主机和主机名与 IP 地址间的映射并不是永久的，DNS 服务器在一段时间后（通常设置两天）将丢弃缓存的信息++。

举个例子，假定主机 apricot.nyu.edu 向 dns.nyu.edu 查询主机名 cnn.com 的 IP 地址。此后，假定过了几个小时，纽约大学的另外一台主机如 kiwi.nyu.edu 也向 dns.nyu.edu 查询相同的主机名。

因为有了缓存，该本地 DNS 服务器可以立即返回 cnn.com 的 IP 地址，而不必查询任何其他 DNS 服务器。本地 DNS 服务器也能够缓存 TLD 服务器的 IP 地址，因而允许本地 DNS 绕过查询链中的根 DNS 服务器。事实上，++因为缓存，除了少数 DNS 查询以外，根服务器被绕过了。++

四、内容分发网

1. 初识内容分发网

今天，许多因特网视频公司日复一日地向数以百万计的用户按需分发每秒数兆比特的流。对于一个因特网视频公司，或许提供流式视频服务最为直接的方法是建立单一的大规模数据中心，在数据中心中存储其所有视频，并直接从该数据中心向世界范围的客户传输流式视频。

但是这种方法存在三个问题。

首先，如果客户远离数据中心，服务器到客户的分组将跨越许多通信链路并很可能通过许多 ISP，其中某些 ISP 可能位于不同的大洲。如果这些链路之一提供的吞吐量小于视频消耗速率，端到端吞吐量也将小于该消耗速率，给用户带来恼人的停滞时延。出现这种事件的可能性随着端到端路径中链路数量的增加而增加。

第二个缺陷是流行的视频很可能经过相同的通信链路发送许多次。这不仅浪费了网络带宽，因特网视频公司自己也将为向因特网反复发送相同的字节而向其 ISP 运营商（连接到数据中心）支付费用。

第三个问题是单个数据中心代表一个单点故障，如果数据中心或其通向因特网的链路崩溃，它将不能够分发任何视频流了。

为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网（Content Distribution Network, CDN） 。**++CDN 管理分布在多个地理位置上的服务器，在它的服务器中存储视频（和其他类型的 Web 内容，包括文档、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的 CDN 位置。++**CDN 可以是专用 CDN （private CDN），即它由内容提供商自己所拥有。

2. CDN 的服务安置原则

（1）深入

该原则是通过在遍及全球的接入 ISP 中部署服务器集群来深入到 ISP 的接人网中。Akamai 在大约 1700 个位置采用这种方法部署集群。其目标是靠近端用户，通过减少端用户和 CDN 集群之间（内容从这里收到）链路和路由器的数量，从而改善了用户感受的时延和吞吐量。因为这种高度分布式设计，维护和管理集群的任务成为挑战。

（2）邀请做客

该原则是通过在少量（例如10个）关键位置建造大集群来邀请到 ISP 做客。不是将集群放在接人 ISP 中，这些 CDN 通常将它们的集群放置在因特网交换点（IXP）。与深人设计原则相比，邀请做客设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。

3. CDN 的操作

当用户主机中的一个浏览器指令检索一个特定的视频（由 URL 标识）时，CDN 必须截获该请求，以便能够：① 确定此时适合用于该客户的 CDN 服务器集群：② 将客户的请求重定向到该集群的某台服务器。

现在考虑用一个简单的例子来说明通常是怎样涉及 DNS 的：

假定一个内容提供商 NetCinema，雇佣了第三方 CDN 公司 KingCDN 来向其客户分发视频。在 NetCinema 的 Web 网页上，它的每个视频都被指派了一个 URL，该 URL 包括了字符串 " video " 以及该视频本身的独特标识符；例如，转换器 7 可以指派力 http://video.netcinema.com/6Y7B23V。接下来出现上图步骤：

① 用户访问位于 NetCinema 的 Web 网页。

② 当用户点击链接 http://video.netcinema.com/6Y7B23V 时，该用户主机发送了一个对于 video.netcinema.com 的 DNS 请求。

③ 用户的本地 DNS服务器（LDNS）将该 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 部署，其核心是集群选择策略（cluster selection strategy），即动态地将客户定向到 CDN 中的某个服务器集群或数据中心的机制。如上述所述，经过客户的 DNS 查找，CDN 得知了该客户的 LDNS 服务器的 IP 地址。在得知该 IP 地址之后，CDN 需要基于该 IP 地址选择一个适当的集群。CDN 一般采用专用的集群选择策略。