目录
一、应用层协议原理
1. 进入应用层
2. 网络应用程序体系结构
（1）客户-服务器体系结构（client-server architecture）
（2） P2P 体系结构（P2P architecture）
3. 进程间通讯
（1）客户和服务器进程
（2）进程与计算机网络之间的接口
（3）进程寻址
二、Web 和 HTTP
1. 初识HTTP
2. 非持续连接和持续连接
（1）采用非持续连接的 HTTP
（2）采用持续连接的 HTTP
4. Web 缓存
三、因特网的目录服务（DNS）
1. 初识 DNS
2. DNS 工作机理
（1）分布式、层次数据库
① 根 DNS 服务器
② 顶级域（DNS）服务器
③ 权威 DNS服务器
（2）DNS 缓存
四、内容分发网
1. 初识内容分发网
2. CDN 的服务安置原则
（1）深入
（2）邀请做客
3. CDN 的操作
一、应用层协议原理
1. 进入应用层
研发 网络应用程序的 核心是 写出能够运行 在不同的 端系统和通过 网络彼此 通信的程序。
例如，在 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 报文请求 和 回答的机制。
3. 用户与服务器的交互（cookie）
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 一般 采用 专用的 集群选择 策略。
