计算机网络——第二章 应用层

第二章 应用层

2.1应用层协议原理

研发网络应用程序的核心是写出能够运行在不同端系统和通过网络彼此通信的程序。

2.1.1网络应用程序体系结构

应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序中所使用的两种主流体系结构之一：客户-服务器体系结构或对等（P2P）体系结构。

客户-服务器体系结构中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。客户之间并不直接通信。另一个特征是该服务器具有特定的、周知的地址称为IP地址。一台主机常常会跟不上它所有的客户请求，为此，配备大量主机的数据中心常被用于创建强大的虚拟服务器。

P2P体系结构中对位于数据中心的专用服务器有最小（或者没有）依赖，相反，应用程序在间断连接的主机对之间使用直接通信。这些主 机对被称为对等方。这些对等方并不为服务提供商所有而为用户控制的桌面机所有。因为这种对等方通讯不必通过专门的服务器，该体系结构被称为对等方到对等方的。某些应用具有混合体系，例如对于许多即时通讯应用而言，服务器被用来追踪IP地址，但用户到用户的报文在主机之间直接发送。它还具有自扩展性，例如在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

2.1.2进程通信

运行在多个端系统中程序相互通信，但实际上进行通讯的是进程，在两个不同端系统上的进程通过跨越计算机网络交换报文而相互通讯。

1.客户和服务器进程

我们通常将两个进程之一标识为客户（发起通信的进程），另一个标识为服务器（在会话开始时等待联系的进程）。

2.进程和计算机网络之间的接口

进程通过一个称为套接字（应用层和运输层直接的接口）的软件接口向网络发送报文和从网络接受报文。由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（API）。应用程序的开发者可以控制套接字在应用层端的一切，但是对运输层端几乎没有控制权。应用程序开发者对于运输层的控制权限仅限于：①选择运输层协议②在目的主机中指定接收进程的标识符。

主机由其IP地址标识，它是一个32比特的量且它能够唯一的标识该主机。除了知道报文发送目的地的主机地址外，发送进程还必须指定在接收主机上的接收进程（更具体的说，接收套接字）。目的地端口号用于这个目的。已经给流行的应用分配了特定的端口号。Web服务器用80，邮件服务器进程用25。用于所有因特网标准协议的周知端口号的列表能够在https://www.iana.org处找到。

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

在套接字的运输层一侧怎么从众多的运输层协议当中选择一种呢，我们需要了解各自能够提供的服务。大体能够四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。

1.可靠数据传输

必须做一些工作以确保由应用程序的一端发送的数据正确、完全的交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。运输层协议能够潜在的向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据能无差错的到达接收进程。

当一个运输层协议不提供可靠数据传输时，也就是说数据可能无法完整的从进程到进程传输。但是可以被容忍丢失的应用所接受，比如多媒体应用，它们能够承受一定量的数据丢失而引起的音频/视频出现小干扰。

2.吞吐量

在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。因为其他会话的共享并且随着它们的到达和离开，所有可用吞吐量会随着时间波动。这就导致另一种自然的服务，即运输层协议能够以某种特定的速率提供确保的可用吞吐量。使用这种服务，该应用程序能够请求r比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是至少为r比特/秒。具有吞吐量要求的应用程序被称为带宽敏感的应用，与之对应的是弹性应用，能够根据当时可用的带宽或多或少的利用可供使用的吞吐量。

3.定时

一个保证的例子如：发送方注入进套接字的每个比特到达到达接收方的套接字不迟于100ms。

4.安全性

例如：在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在数据交付给接收进程之前解密这些数据。

2.1.4因特网提供的运输服务

因特网为应用程序提供两个运输层协议：UDP和TCP。当你创建一个新的应用时首先就要决定用哪个。

1.TCP服务

TCP服务模型包括面向连接服务和可靠数据传输服务，当某个应用程序调用TCP作为其运输协议时，该应用程序就能获得来自TCP的这两种服务。

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

TCP协议还具有拥塞控制协议，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程（客户或服务器）。他也会试图限制每个TCP连接，使它们达到公平共享网络带宽的目的。

2.UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。

UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。（然而值得注意的是实际端到端吞吐量可能小于该速率，这可能是因为中间链路的带宽受限或因为拥塞而造成的。）

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

对吞吐量和定时保证的服务目前的因特网运输协议并没有提供。今天的因特网通常能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。

2.1.5应用层协议

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

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

2.2Web和HTTP

Web的应用层协议是超文本传输协议（http）由两个程序实现：一个客户程序和一个服务器程序，它们运行在不同的端系统中通过交互http报文进行会话。

Web页面（也叫文档）是由对象组成的。一个对象只是一个文件，可以通过一个URL地址寻址。多数Web页面含有一个HTML基本文件以及几个引用对象。每个URL地址由两个部分组成：存放对象的服务器主机名和对象的路径名。

HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。HTTP使用TCP作为它的支撑运输协议（而不是UDP）。HTTP客户首先发起一个于服务器建立的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP，客户端的套接字接口是客户进程与TCP连接之间的门。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文，服务器端也类似。一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP的控制。TCP为HTTP提供了可靠数据传输服务。这里我们看到了分层体系结构最大的优点，即HTTP协议不用担心数据丢失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。

请注意：服务器向客户端发送被请求的文件，也不存储任何关于该客户的任何信息。（也就是说如果同一个客户在很短时间内连续两次向服务器端请求文件，服务器第二次依然会发送文件，而不是因为刚才发过一遍就忽略第二次请求），正因如此我们说HTTP是一个无状态协议。我们同时也注意到Web使用了客户-服务器应用程序体系结构。Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自于数以百万计的不同浏览器的请求。

2.2.2非持续连接和持续连接

客户-服务器交互是通过TCP进行时，应用程序的研制者需要做出一个决定：每个请求/响应对是经一个单独的TCP连接发送，还是所有的请求/响应对都经过相同的TCP连接发送。前一种称为使用非持续连接，后一种称为使用持续连接。HTTP两者都能用，默认使用持续链接。

1.采用非持续连接的HTTP

以服务器向客户传送一个Web页面为例，假设该页面含有一个HTML基本文件和10个JPEG图形，并且这十一个对象位于同一台服务器上。

• 1）HTTP客户进程在端口号80（HTTP的默认端口号）发起一个到服务器URL的TCP连接。在客户和服务器上分别有一个套接字与该连接相关联。
• 2）HTTP客户经它的套接字向该服务器发送一个HTTP请求报文。（该报文包含了路径名
• 3）HTTP服务器进程经它的套接字接收该请求报文，从其储存器（RAM或磁盘）中检索出URL对应的对象，并在一个HTTP响应报文中封装它，通过套接字向客户发送响应报文。
• 4）HTTP服务器进程通知TCP断开该TCP连接。（实际上只有TCP确认客户进程完整的接收到响应报文为止它才会中断连接
• 5）HTTP客户接收响应报文，TCP连接关闭。该报文指出封装的对象是一个HTML基本文件，客户从响应报文中提取并检查该文件，得到10个JPEG文件的引用。
• 6）对每个JPEG文件重复前4个步骤。

每个TCP只传输一个请求报文和响应报文，因此上述例子需要11个TCP连接

HTTP与客户如何解释一个Web页面毫无关系（两种浏览器也许会以不同的方式解释该页面），HTTP仅定义了在HTTP客户程序与HTTP服务器程序之间的通讯协议。

在上述例子中，10个JPEG对象并没有说是并行的TCP还是串行的TCP，或是某些对象使用了并行的TCP连接，实际上用户能够配置现代浏览器来控制连接的并行度，大部分浏览器默认打开5~10个并行的TCP连接。（最大设置为1就是串行的了）

往返时间（RTT），该时间是指一个短分组从客户到服务器再返回客户的时间。它包括分组传播时延、分组在中间路由器和交换机上的排队时延和分组处理时延。

“三次握手”：客户向服务器发送一个小TCP报文段，服务器用一个小TCP报文段做出确认和响应，最后客户向服务器返回确认。前两个握手部分占用一个RTT，此后，客户结合第三次握手部分向该TCP连接发送一个HTTP请求报文，一旦该请求报文到达服务器，服务器就在该TCP连接上发送HTML文件，该HTTP请求/响应用去另一个RTT。因此粗略地讲，总的响应时间就是两个RTT加上服务器传输HTML文件的时间。

2.采用持续连接的HTTP

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

在采用HTTP1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户和服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。特别是一个完整的Web页面（例如上面例子中一个HTML基本文件和10个JPEG图片）可以用单个持续的TCP连接上进行。对对象的这些请求可以一个接一个的发出，而不必等待未决请求（流水线）的回答。一般来说，如果一条连接一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务就关闭该连接。HTTP的默认模式是使用带流水线的持续连接。

2.2.3HTTP报文格式

HTTP有两种报文：请求报文和响应报文。

1.HTTP请求报文

GET /some/page.html HTTP/1.1

Host : www.someschool.edu //指明对象所在的主机

Connection : close //该浏览器告诉服务器不要麻烦的使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接

User-agent : Mozilla/5.0 //用户代理，即浏览器类型，这里的也就是Firefox及其版本

Accept-language : fr //用户想得到该对象的法语版本（如果服务器中有的话），否则会发送默认版本

是用普通的ASCII文本书写的，每行由一个回车和换行符结束。最后一行后再附加一个回车换行符。

请求报文的第一行叫请求行，后继的行叫做首部行。

请求行有3个字段：方法字段、URL字段和HTTP版本字段。方法字段可以取不同的值，包括GET、POST、HEAD、PUT和DELETE。版本字段是自解释的。

2.HTTP响应报文

HTTP/1.1 200 OK

Connection : close //发完报文后关闭该TCP连接

Date : Tue, 18 Aug 2015 15:44:04 GMT //响应报文的日期和时间（服务器从它的文件系统中检索到该对象，将该对象插入响应报 文并发送该响应报文的时间

Server : Apache/2.2.3 (CentOS) //该报文是由一台ApacheWeb服务器产生的

Last-Modified : Tue, 18 Aug 2015 15:11:03 GMT //该对象创建或最后修改的时间

Content-Length : 6821 //被发送对象的字节数

Content-Type : text/html //对象是html文本

这个报文包括1个初始状态行，6个首部行，然后是实体体。

状态行有3个字段：协议版本字段、状态码和相应状态信息。

2.2.4用户与服务器的交互：cookie

cookie允许站点对用户进行跟踪，有四个组件：①在HTTP的响应报文中的一个cookie首部行②在HTTP请求报文中的一个cookie首部行③在用户端系统中保留一个cookie文件，并由用户的浏览器进行管理④位于Web站点的一个后端数据库。

2.2.5Web缓存

Web缓存器也叫代理服务器

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

举例来说，浏览器请求一个URL：

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

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

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

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

Web缓存器既是客户又是服务器，通常由ISP购买并安装，比如一个学校可以在校园网上安装一个缓存器并将校园网上的所有用户浏览器配置为指向它。

Web缓存器可以大大减少对用户请求的响应时间，并且如果客户请求的对象存在于缓存器上，那么它可以迅速将对象交付给用户。Web缓存器还可以大大减少一个机构的接入链路到因特网的通信量，这个机构就不必急于增加带宽从而降低了费用。

2.2.6条件GET方法

HTTP协议的此方法能够保证用户在Web缓存器中得到的副本是最新的。如果：①请求报文使用GET方法②请求报文中包含一个"If-Modified-Since:"首部行。那么，这个HTTP请求报文就是一个条件GET请求报文。

大概作用就是在以后的用户请求中web缓存器在发送给用户副本之前会先问一下服务器该对象有没有变过（通过前一次的交谈日子确认）。

2.3因特网中的电子邮件

因特网电子邮件系统主要包括：用户代理、邮件服务器、简单邮件传输协议（SMTP）。SMTP是因特网电子邮件中一个主要的应用层协议，它使用TCP可靠数据传输服务从发送方的邮件服务器向接收方的邮件服务器中发送邮件。

2.3.1SMTP

SMTP一般不使用中间邮件服务器发送邮件。交流时首先客户SMTP在25号端口建立一个到服务器SMTP的TCP连接。握手阶段指示双方的邮件地址，紧接着便发送报文。SMTP能够依赖TCP的可靠数据传输服务将信息毫无差错的传送给接收服务器（如果有另外的报文要发给该服务器就在这个TCP连接上重复这种处理，否则将指示关闭这条连接。）

2.3.2与HTTP的对比

HTTP：从web服务器向web客户（通常是浏览器）传送文件（或称为对象）。

SMTP：从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）。

它们都使用持续连接。

不同点：

HTTP主要是一个拉协议：某些人方便的时候在web服务器上装载信息，用户用HTTP协议从该服务器上拉取信息。特别是TCP连接是由想接收文件的机器发起的。

SMTP主要是一个推协议：即发送邮件服务器想把文件推向邮件接收服务器。特别是，这个TCP连接是由要发送该文件的机器发起的。

SMTP要求每个报文采用7比特ASCII码格式。如果某报文包含了非7比特ASCII码字符或二进制数据（如图形文件），则该报文必须按照7比特ASCII码进行编码。HTTP则不受这种限制。

HTTP是把每个对象封装在各自的（不同）HTTP响应消息中。SMTP是把同一个邮件内的各个对象置于同一个邮件消息中。

2.3.3邮件报文格式

每个首部必须包含一个From：首部行和一个To：首部行，也许包含一个Subject：首部行。

2.3.4邮件访问协议

SMTP用来将邮件从发送方的邮件服务器传输到接收方的邮件服务器，也用于将邮件从发送方的用户代理传送到发送方的邮件服务器。如POP3(第三版的邮局协议)、IMAP（因特网邮件访问协议）这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理。（为什么接收方的用户代理无法直接通过SMTP从接收方的邮件服务器中获取邮件呢？因为获取邮件是一个拉操作，而SMTP是一个推协议）

1.POP3

当用户代理打开一个到邮件服务器端口110上的TCP连接，POP3就开始工作了，它按照以下三个阶段进行：

第一个阶段：特许阶段，用户代理以明文形式用户名和口令以鉴别用户。

第二个阶段：事务处理阶段，用户代理取回报文；同时在这个阶段用户代理还可以对邮件做/取消删除标记，以及获取邮件的统计信息。

第三个阶段：更新阶段，出现在用户发出quit命令之后，目的是能结束该POP3对话；这时该邮件服务器删除那些被标记为删除的报文。

服务器会对每个用户代理发出的命令进行回答：+OK或者-ERR。

特许阶段有两个重要的命令：user 和pass 。

使用POP3的用户代理通常被用户配置为“下载并删除”或者“下载并保留”方式。在会话过程中服务器保留状态信息，但并不在POP3会话过程中携带状态信息。

2.IMAP

该方法为用户提供了远程在服务器中创建、移动、查询甚至查看邮件部分内容的功能。

3.基于web的电子邮件

只有用户代理和邮件服务器之间使用HTTP，邮件服务器和邮件服务器之间使用的仍然时SMTP。

2.4DNS：因特网的目录服务

因特网主机可以通过主机名或者IP地址来标识。

2.4.1DNS提供的服务

我们需要一种能进行主机名到IP地址转换的目录服务，这就是**域名系统（DNS）**的主要任务。

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

DNS通常是由其他应用层协议所使用的，包括HTTP、SMTP和FTP,将用户提供的主机名解析为IP地址，例如某用户向一个URL请求页面时，该主机需要该目的IP地址：

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

2）浏览器从上述URL中抽取出主机名xxx.xxxxx.xxx并将这台主机名传给DNS应用的客户端

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

4）DNS客户最终会受到一条回答报文，其中包括了该主机名对应的IP地址

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

显然这个过程会带来额外的时延，有时还相当可观，但有时常用的IP地址通常缓存在一个“附近的”DNS服务器中，这有助于减少DNS的网络流量和平均时延。

除此之外DNS还提供一些重要的服务：

• 主机别名：有时有着复杂主机名的主机能拥有很多主机名，但主机别名（如果存在）有时候更加容易记忆，DNS就能够帮助获取主机别名对应的主机规范名和IP地址
• 邮件服务器别名：电子邮件应用程序也可以调用DNS；事实上一个公司的邮件服务器和Web服务器使用相同的（别名化的）的主机名，这是被允许的。
• 负载分配：DNS也用于在冗余的服务器之间进行负载分配。繁忙的站点被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上，每个都有不同的IP地址。由于这些冗余的Web服务器，一个IP地址集合因此与同一个规范主机名相联系。DNS数据库中存储着这些IP地址集合。当客户对映射到某地址集合的名字发出一个DNS请求时，该服务器用IP地址的整个集合进行响应，但是在每个回答中循环这些地址次序（因为通常客户总是对IP地址排在前面的服务器发送HTTP请求），从而实现了负载分配。

2.4.2DNS工作机理概述

DNS的一种设计是整个地球只用一台DNS服务器，该服务器包含所有映射，但是这个设计明显肾虚：

• 单点故障：如果该DNS服务器崩溃，整个因特网将随之瘫痪。
• 通信容量：单个DNS服务器不得不处理所有的DNS查询（用于为上亿台主机产生的所有HTTP请求报文和电子邮件报文服务）
• 远距离的集中式数据库：单个DNS服务器不可能“临近”所用查询客户。
• 维护：单个DNS服务器将不得不为所有因特网主机保留记录，这不仅将使单个数据库庞大，而且它还不得不为解决每个新添加的主机而频繁更新。

事实上，DNS是一个在因特网上实现分布式数据库的精彩范例。

1.分布式、层次数据库

大致来说有三种类型的DNS服务器：根服务器、顶级域（TLD）DNS服务器和权威DNS服务器。

• 根DNS服务器：400多个根DNS服务器遍及世界并且由13个组织管理。根名字服务器提供TLD服务器的IP地址。
• 顶级域DNS服务器：每个顶级域（如com、org、net、edu和gov）和所有国家的顶级域（如uk、fr、ca和jp），都有TLD服务器。TLD服务器提供了权威DNS服务器的IP地址。
• 权威DNS服务器：在因特网上具有公共可访问主机的每个组织机构都必须提供可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。一个组织机构的权威DNS服务器收藏了这些DNS记录。

这三个构成了DNS服务器的层次结构。还有一种被称为本地DNS服务器，每个ISP都有一台本地DNS服务器。当主机与某个ISP连接时，该ISP提供一台主机的IP地址，该主机具有一台或多台其本地DNS服务器的IP地址。通过访问windows或者unix的网络状态窗口，用户能确定他的本地DNS服务器的IP地址。本地的DNS服务器通常“邻近”本主机，对某机构而言这两个可能就在同一个局域网中。对于某居民区ISP而言，这两个相隔通常不过几台路由器。当主机发出DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并且将请求发送到DNS服务器。

实际查询中一般用迭代查询和递归查询。

2.DNS缓存

在一个请求链中当某DNS服务器接收一个DNS回答时，它能将映射缓存到本地储存器中，另一个对相同主机名的查询到达该服务器DNS服务器时，该DNS服务器就能提供所要求的IP地址，即使他不是该主机名的权威服务器。由于主机和IP地址之间的映射并不是永久的，DNS服务器通常在一段时间后（通常设置为两天）将丢失缓存的信息。

2.4.3DNS记录和报文

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

资源记录是一个包含了下列字段的4元组：

（Name，Value，Type，TTL）

TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。Name和Value的值取决于Type：

• 如果Type是A，则Name是主机名Value是该主机名对应的IP地址。因此一条类型为A的资源记录提供了标准的主机名到IP地址的映射。
• 如果Type为NS，则Name是个域（如foo.com），而Value是个知道如何获取该域中主机IP地址的权威DNS的主机名。这个记录用来沿着查询链来路由DNS查询。
• 如果Type=CANME，则Value是别名为Name的主机对应的规范主机名。
• 如果Type=MX，则Value是别名为Name的邮件服务器的规范主机名。

如果一台DNS服务器是用于某特定的主机名的权威DNS服务器，那么该DNS服务器会有一条包含于该主机名类型的A记录。

如果不是，那么该服务器包含将包含一条类型NS记录，对应于包含主机名的域；它还将包含一条类型A记录，该记录提供了在NS记录的Value字段中的DNS服务器的IP地址。

1.DNS报文

DNS只有查询和回答这两种报文。并且有着相同的格式：

• 前12个字节是首部区域，其中有几个字段。标识符是一个16比特的数，用于标识该查询，这玩意会被复制到回答报文中，以便让客户用它来匹配发送的请求和接收到的回答。标志字段中含有若干标志。1比特的“查询/回答”标志位指出该报文是查询报文（0）还是回答报文（1）。当某DNS服务器是做请求的名字的权威服务器时，1比特的“权威的”标志位被置在回答报文中。如果客户（主机或者DNS服务器）在该DNS服务器没有记录时希望执行递归查询，将设置1比特的“希望递归”标志位。如果该服务器支持递归查询，在回答报文中会对1比特的“递归可用”标志位置位。在该首部中还有4个有关数量的字段，指出了在首部后四类数据区域出现的数量。
• 问题区域包含着正在进行的查询信息。该区域包括：①名字字段，包含正在查询的主机名字②类型字段，指出有关该名字正被问询的问题类型，例如主机地址是与一个名字相关联（A）还是与某个名字的邮件服务器相关联（MX）。
• 在来自DNS服务器的回答中，回答区域包含了对最初请求的名字的资源记录，回答区域中可以包含多条资源记录（RR），因此一个主机名能有多个IP地址。
• 权威区域包含了其他权威服务器的记录。
• 附加区域包含了其他有帮助的记录。 例如对于一个MX请求的回答报文包含了一条资源记录，该记录提供了邮件服务器的规范主机名，该附加区域包含了一个类型A记录，该记录提供了用于该邮件服务器的规范主机名的IP地址。

2.在DNS数据库中插入记录

注册登记机构是一个商业实体，它验证域名的唯一性，将该域名输入DNS数据库。因特网名字和地址分配机构（ICANN）向各种注册登记机构授权。

当你要登记某域名时需要提供基本和辅助权威DNS服务器的名字和IP地址。该注册登记机构确保将一个类型NS和类型A的记录输入TLD com服务器（假如）。还必须确保用于web服务器和用于邮件服务器的类型MX资源记录被输入你的权威DNS服务器中。

2.5P2P文件分发

P2P结构对总是打开的基础设施服务器有最小的依赖。成对间隙的主机（称为对等方）彼此直接通信。这些对等方并不为服务商所有，而是受用户的控制。

1.P2P体系结构的扩展性

我们研究一下单一服务器向大量对等方分发一个大文件。

首先我们考虑客户-服务器体系结构：

服务器和对等方使用接入链路与因特网相连。Us表示服务器接入链路的上载速率，Ui表示第i对等方接入链路的上载速率，di表示第i对等方接入链路的下载速率。F表示分发文件的文件长度，N表示要获得该文件副本的对等方的数量。分发时间是所有N个对等方得到该文件的副本所需要的时间。

首先我们来确定对于客户-服务器体系结构的分发时间，用Dcs来表示，这个结构中没有对等方参与来分发文件。

• 服务器必须向N个对等方的每个传输该文件的一个副本，因此该服务器必须传输NF比特因为该服务器上载速率时Us，分发该文件的时间必定至少为NF/Us。
• 令dmin表示具有最小下载速率的对等方的下载速率，即dmin=min{d1，d2…dN}。最小分发时间为F/dmin。

综上我们得到：

​ Dcs >= max{NF/Us,F/dmin}

该式提供了客户-服务器体系结构最小分发时间的下界，取这个下界作为实际分发时间

​ Dcs = max{NF/Us,F/dmin}

可以看到，对于足够大的N，客户-服务器分发时间由前者决定，随着N增大而线性增加。

再来看一下P2P结构：

每个对等方在接收到某些文件后都能够用自己的上载能力帮助服务器分发给其他对等方。

• 在开始的时候只有服务器具有文件，所以文件的每个比特必须至少经服务器发送一次，因此最小分发时间是F/u。（与客户-服务器不一样，由服务器发送过的问价可能不必由服务器再次发送而由其他对等方发送）
• 与之相同的为所有对等方不能以小于F/dmin的时间获得所有F比特，所以最小分发时间仍为F/dmin。
• 系统总体上载能力等于服务器的上载速率加上每个单独的对等方的上载速率，即utotal=us+u1+u2+…+uN。系统总共交付NF比特不能快于utotal的时间，所以最小分发时间是NF/（us+u1+u2+…+nN）

综上，P2P的最小分发时间为DP2P

​ DP2P >= max{F/us，F/dmin，NF/（us+u1+u2+…+nN）}

依然取下界作为实际最小分发时间

​ DP2P = max{F/us，F/dmin，NF/（us+u1+u2+…+nN）}

2.BitTorrent

BitTorrent是一种用于文件分发的流行P2P协议，术语来讲，参与一个文件分发的所有对等方集合称为一个洪流，在一个洪流当中对等方彼此下载等长度的文件块，典型长度为256KB，当一个对等方首次加入一个洪流时是没有块的，随着时间流失他会积累越来越多的块，当他下载块时也为其他对等方上载了块。一旦对等方获取了某个完整的文件后，它可以选择自己自私的离开洪流，也可以大公无私的留在洪流中继续向其他对等方上载块，同时任何对等方可以在任何时候仅具有块的子集就离开洪流，并且在以后重新加入该洪流。

每个洪流具有一个基础设施节点称为追踪器，当一个对等方加入某洪流时要向追踪器注册自己，并且周期性的告诉追踪器他还在这个洪流中。

当一个对等方A加入洪流时要向追踪器注册自己，同时追踪器会随机的从所有对等方中选择一个对等方的子集，并且将子集中对等方的IP地址发送给这个A对等方，A会尝试与这些对等方建立TCP连接，称所有这样与A建立CTP连接的对等方为“临近对等方”，随着时间流逝，对等方中间的某些可能会离开，一开始子集之外的对等方可能会与A建立TCP连接，所以这些连接是随着时间波动的。

在任何给定的时间，每个对等方都有来自该文件的块的子集，而且每个对等方拥有的子集都是不一样的，所以A周期性的询问临近对等方他们所拥有的块列表，如果A有L个临近对等方，那么A就会有L个块列表，有了这个信息A就可以对特定的临近对等方发出A自己还没有的块的请求。（这个整个过程都是通过TCP连接）

所以A要做的就是决定从哪些邻居中获得哪些块，A使用一种最稀缺优先的技术，也就是优先请求那些在邻居中副本最少的块，这样一来稀缺的块得以被重新分发，来保证各个块的数量在洪流中大致平衡。

更重要的是，每过 30s，我的主机也要 随机地 选择另外一个邻居（假设叫 bingo）并向其发送块，如果 我的主机 通过发送块，成为了 bingo 主机的前 4 位上载者，bingo 也会开始向我的主机发送块，这样 bingo 的主机也可能成为了我的主机的前 4 位上载者。每过 30s 会再次随机选择一名新的对换伴侣并开始与这位对换伴侣进行对换，我们希望找到更好 的对换伴侣，使对等方能够以趋向于找到彼此的协调的速率上载。

随机选择邻居也允许新的对等方得到块。

除了这 5 个对等方的所有其它相邻对等方均被 “阻塞 ” ，既它们不能从我的主机接收任何块。这种交换激励机制又被称为 “一报还一报”。 已经证实这种激励方案能够被回避。但是 BitTorrent 依旧取得了广泛的成功。

2.6视频流和内容分发网

2.6.1因特网视频

目前来讲对流式视频最为重要的性能是平均端到端吞吐量，网络必须为流式应用提供平均吞吐量。

2.6.2HTTP流与DASH

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

HTTP流也有严重缺陷，所有客户接收到相同编码的视频，尽管对于不同的客户或者对于相同的客户的不同时间而言，客户可用的带宽大小有很大不同。导致了一种新型的基于HTTP的流的研发，被称为经HTTP的动态适应性流（DASH）。在DASH中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应不同的质量水平客户动态的请求来自不同版本且长度为几秒的视频段数据块。客户用HTTP GET请求报文一次选择不同的块。

DASH允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频。如果端到端带宽在会话过程中改变的话，DASH允许客户适应可用带宽。

使用DASH后每个视频版本储存在HTTP服务器中，每个版本都有一个不同的URL。HTTP服务器也有一个告示文件，为每个版本提供了一个URL及其比特率。客户首先请求该告示文件并且得知各种各样的版本。然后客户通过在HTTP GET请求报文中对每块指定一个URL和一个字节范围，一次选择一块。在下载块的同时客户也测量接收带宽并运行一个速率决定算法来选择下次请求的块。也就是说DASH允许用户自由的在不同的质量等级之间切换。

2.6.3内容分发网

对于一个因特网视频公司需要向大量用户发送大量视频，最简单的方法是建立一个大规模的数据中心储存所有视频然后向世界范围内的客户传输流式视频，但是这种方法存在三个问题：第一，如果客户远离数据中心，服务器到客户的分组将跨越许多通讯链路并很可能通过许多ISP，其中某些甚至还可能位于不同的大洲。如果这些链路之一提供的吞吐量小于视频消耗速率，端到端吞吐量也将小于该消耗速率，给用户带来恼人的停滞时延。（因为一条流的端到端吞吐量由瓶颈链路的吞吐量所决定）。出现这种时间的可能性随着端到端路径中链路数量的增加而增加。第二，流行的视频可能经过相同的通讯链路发送了许多次。这不仅浪费了网络带宽，因特网视频公司自己也将因为向因特网反复发送相同的字节而向其ISP支付费用。第三，如果这个数据中心或其向因特网的链路崩溃，他将不能发送任何视频流了。

为了应对这些问题，几乎所有的主要的视频流公司都利用内容发布网（CDN）。CDN管理分布在多个地理位置上的服务器，在他的服务器中存储视频（和其他类型的web内容诸如文档和图片等）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN（为某一内容提供商所有）也可以是第三方CDN（代表多个内容提供商分发内容）。

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

• 深入：在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。通过靠近端用户，减少端用户和CDN集群间的链路和路由器数量来减少时延，因为这种高分布式的做法，维护和管理集群成为了挑战。
• 邀请做客：通过在少量（例如10个）关键位置建造大集群来邀请接入到ISP做客，不是将集群放置在接入ISP中，而是通常放置在因特网交换点（IXP）。与上一种相比，通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。

一旦CDN集群准备就绪，它就可以跨集群复制内容。CDN可能不希望每个视频的副本放置在每个集群中，因为这些副本可能仅有一些用户观看或者在某些国家地区流行。事实上，CDN没有将视频推入他们的集群，而是采用一种简单的拉策略：当用户向某个未储存该视频的集群发送请求时，该集群检索（从其他集群或者中央仓库），并且向用户流式传递该视频的同时在本地缓存一个副本，某集群储存器变满时删除不经常请求的视频。

1.CDN细节

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

大多数CDN用DNS来截获和重定向请求。这个例子中有客户，内容提供商netcinema，第三方CDN公司kcdn。

在netcinema网页上的每个视频都被指派了一个URL，该URL包含一个特殊字符串video以及该视频本身特殊的标识符。

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

2.集群选择策略

任何CDN部署，其核心是集群选择策略，即动态的将客户定向到CDN中的某个服务器集群或数据中心的机制。CDN一般采用专用的集群选择策略。

一种简单的策略是指派用户到地理上最为邻近的集群，这个方案并不是每次都能工作的相当好，因为地理邻近可能并不是最近的集群，某些端用户也可能配置使用位于远地的LDNS，而且这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化，为了基于当前流量条件为客户选择最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量。例如，CDN能够让他的每个集群周期性的向位于全世界的所有LDNS发送探测分组（ping报文或DNS请求）。这个方法的缺陷为一些LDNS配置为不会响应这些探测。