[网络协议]计算机网络读书笔记（二）

一.应用层

1.1 应用层协议原理

在Web应用程序中，有两个互相通信的不同的程序：一个是运行在用户主机上的浏览器程序；另一个是运行在Web服务器主机上的Web服务器程序。这里采用的是C/S体系结构，即服务端的服务器一直运行，有固定的IP地址和端口号，扩展性差；客户端则主动与服务器通信，与互联网有间歇性的连接，可能有间歇性的连接，可能是动态的IP地址。另一个例子是P2P文件共享系统，在参与文件共享的社区中的每台主机中都有一个程序。在对等体(P2P)体系结构下，几乎没有一直运行的服务器，任意端系统之间可以通信，每一个结点即是客户端又是服务器并且可以改变IP地址。

1.1.1 网络应用程序体系结构
应用程序的体系结构不同于网络的体系结构。从应用程序研发者的角度来看，网络体系结构是固定的，并为应用程序提供特定的服务集合；应用程序体系结构由应用程序研发者设计，规定了如何在端系统上组织该应用程序。有两种主流体系结构：客户-服务器体系结构或对等(P2P)体系结构。

1. 客户服务器体系结构：
   在客户-服务器体系结构中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求，该服务器拥有固定的、周知的地址，该地址称为IP地址。并且在客户-服务器体系结构中，常常会出现一台单独的服务器主机跟不上它所有客户请求的情况，为此，配置大量主机的数据中心常被用于创建强大的虚拟服务器。

2. 对等(P2P)体系结构：
   对数据中心的专用服务器有最小的依赖，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方，P2P还有一个特性是它们的自扩展性，比如在文件共享应用中，对等方可能通过向文件的原始拥有者发出请求而产生工作量，但是对等方也有可能通过为其他对等方传送文件而为原始拥有者分担压力；P2P体系结构也是成本有效的，因为他通常不需要庞大的服务器基础设施和服务带宽。

1.1.2 进程通信
用操作系统的术语来说，进行通信的实际上是进程而不是程序，一个进程可以被认定是运行在端系统中的一个程序。在两个不同端系统上的进程，通过跨越计算机网络交换报文而相互通信。发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过回送报文进行相应。

1. 客户和服务器进程
   对每对通信进程，我们常常将这两个进程之一标识为客户，而另一个进程标识为服务器，对于Web而言，浏览器是一个客户进程，Web服务器是一个服务器进程；对于P2P文件共享的某些应用中，一个进程既能是客户端也能使服务器。所以从进程所扮演的角色来区分是客户进程还是服务器进程不够精确，所以我们从发起通信的顺序来定义它们：在给定的一对进城之间，首先发起通信的进程被标记为客户进程，在会话开始时等待联系的进程被称为服务器进程。

2. 进程与计算机网络之间的接口
   进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文；套接字是同一台主机内应用层与传输层之间的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也成为应用程序和网络之间的应用程序编程接口。一旦应用程序的开发者选择了一个传输层协议，则应用程序就建立在由该协议提供的运输层服务之上。

3. 进程寻址
   在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了标识该接收进程，需要定义两种信息：主机的地址和在目的主机中指定接收进程的标识符。在因特网中主机由其IP地址标识。除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程(接收套接字)，目的地端口号就是用于这个目的。

1.1.3 可供应用程序使用的传输服务
我们大致能够从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。
1.可靠数据传输
通过做一些工作以确保由应用程序的一端发送的数据正确、完全的交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个传输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据能无差错地到达接收进程。

当传输层不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程，这类可以被适用于多媒体应用。

2.吞吐量
在一条网络路径上的两个进程之间的通信会话中，可用吞吐量就是指能够向接收进程交付比特的速率。因为会有其他会话共享该网络的路径的带宽，并且因为这些会话的到来和离开，可用吞吐量将发生变化；这就导致另一种自然的服务，即运输层协议能够提供确切的可用吞吐量。使用这种服务时，应用程序就能以明确的速度接收数据，并且运输层应当保证可用吞吐量必须总是至少为该速度；

对吞吐量有明确要求的应用程序被称为带宽敏感的应用。许多多媒体应用是带宽敏感的（尽管某些多媒体应用程序可能采用自适应编码技术对数字视频和音频以与当前可用带宽相匹配的速度加解码。），比如因特网电话。而弹性应用则对吞吐量没有严格的要求。这类应用包括：电子邮件、文件传输以及web传送等。值得注意的是，吞吐量当然是越多越好了。

3.定时
定时和吞吐量都是关于速度的。一个提供定时服务的例子是：发送方注入套接字中的每个比特到达接收方的套接字不迟于100ms。也就是说，定时是对数据从发送到到达所需时间的要求，而吞吐量是对数据交付速度的要求。打个比方，吞吐量是指一个小时内经过某个收费站的汽车数目，而定时则是第一辆车从出发到进入收费站的时间。有些应用为了服务的有效性而对数据到达时间有严格的要求，常见的应用有：因特网电话、多方在线游戏等；

4.安全性
运输层可以提供一些安全服务，以防止传输的数据以某种方式在这两个进程之间被察觉到。这些安全服务包括：数据的加解密、数据的完整性和端点鉴别等

1.1.4 因特网提供的运输服务
因特网为应用程序提供两个运输层协议，即UDP和TCP。
1.TCP服务
TCP服务模型包括面向连接服务和可靠数据传输服务。

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

TCP协议还具有拥塞控制机制，它能够为因特网带来整体好处。

2.UDP服务
UDP是一种不提供不必要服务的轻量级运输协议，它提供最小的服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，也就是不保证完整送达，也不保证顺序正确。UDP没有拥塞控制机制。

3.因特网运输协议所不提供的服务
从可靠数据传输、吞吐量、定时、安全性等四个角度来看运输层提供的服务，我们发现，运输层无法对吞吐量和定时做出保证。但是，今天的因特网能够为时间敏感的应用提供满意的服务，尽管它并不提供任何定时或者带宽保证；

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

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

1.2 Web和HTTP

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

Web网页是由对象组成的。一个对象只是一个文件，他们可以通过URL地址寻址。多数Web页面含有一个HTML基本文件以及几个引用对象。HTTP定义了Web客户向Web服务器请求Web页面的方式以及服务器向客户传送Web页面的方式。当用户请求一个Web页面时，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP相应报文进行相应。

HTTP使用TCP作为它的支撑运输协议。HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文，服务器类似的。一旦客户向它的套接字接口发送一个请求报文，该报文就脱离了客户控制并进入TCP的控制。

注意到服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。若一个特定的客户短时间内两次请求同一个对象，服务器会重新发送对象。也就是说，HTTP是不保存关于客户的任何信息的，是一个无状态协议。

1.2.2 非持续连接和持续连接
在许多的因特网应用程序中，客户和服务器在一个相当长的时间范围内通信。当客户-服务器的交互是经TCP进行的，应用程序的研制者就需要做决定，即每个请求/响应对是经过一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送。采用前一种方法，该应用程序被称为非持续连接，采用后一种方法，该应用程序被称为持续链接。HTTP默认使用持续链接，但是也可以配置成非持续连接。

1. 采用非持续连接的HTTP
   使用非持续连接时，每个TCP连接在服务器发送一个对象后就会关闭，也就是每个TCP只传送一个请求报文和响应报文；

   为了描述持续连接和非持续连接的特点，我们引入RTT(Round-Trip Time)。RTT指的是，一个短分组从客户端到服务器，然后再返回客户端所用的时间。RTT包括分组的传播时延、排队时延、处理时延（因为是短分组，所以其传输时延可不计）；因为客户端和服务器建立TCP连接的时候，会通过一个三次握手的过程来交换传输控制信息。三次握手的前两次占用了一个RTT，客户结合第三次握手通信会通过该连接发送一个HTTP请求报文，一旦该分组到达服务器，服务器便开始使用TCP传输HTML对象。因此，粗略地说，响应时间是两个RTT加上传输HTML的时间（不是传播）

2. 采用持续连接的HTTP
   非持续连接必须为每个请求新建一个TCP连接，而每个TCP连接将占用系统资源，包括缓冲区和变量等，这样服务器的负担就很重了。第二，一个对象将通过两个RTT的时延才能交付。

   如果使用持续连接，那么服务器在发送响应报文后将保持该TCP打开，后续客户端可以使用该连接来向服务器发出请求。不但一个完整的页面可以通过同一个连接传送，同一台服务器上的多个页面也可以通过同一个连接发送。这就提高了效率；

一般来说，如果一条连接在一定的时间间隔后没被使用的话，就会被关闭。HTTP默认使用的是带流水线的持续连接。
在连接建立后，传输数据分为两种，分别是流水线式和非流水线式。非流水线式就是每次发送一个请求，等待得到所需要的数据后在发出下一个请求，而流水线式则直接将所有请求以此发出，不需要等待数据接收后再发出。

1.2.3 HTTP报文格式
1.HTTP请求报文

一个请求报文能够具有最少一行的内容，HTTP请求报文的第一行叫做请求行，其后继行叫做首部行。请求行有3个字段：请求方法、URL字段和HTTP版本字段，方法字段可以取不同的值，包括GET、POST、HEAD、PUT、DELETE.绝大部分的HTTP请求报文使用GET方法。当浏览器请求一个对象时，使用GET方法，在URL字段带有的请求对象的标识。

首部行包含是否在发送完响应报文后关闭TCP连接的Connection（也就是持续性以及非持续的控制）；请求的主机地址（该头部信息被Web高速缓存所要求）；浏览器版本；可接受的语言等头部信息；

在首部行之后一个空行，之后便是请求的“实体体”(包含了所请求的对象本身)。该实体体可以在POST方法里传递Form表单内容或者传递其它一些二进制流数据等。值得注意的是，表单也不一定必须使用POST方法。如果使用get,实体体为空，会显示在url中。

Head类似于get方法，将会用一个http报文进行响应，但是不返回请求对象，经常用作调试跟踪。put方法允许用户上传对象到指定的Web服务器上指定的路径。Delete方法允许用户或应用程序删除Web服务器上的对象。

2.HTTP响应报文

响应报文总体上也分三个部分，第一部分是状态行，包含HTTP版本、状态以及状态信息等内容；第二部分是首部行，包含发送日期、服务器类型、上一次修改请求资源的时间、内容的类型等内容。第三部分是实体体。实体体包含请求对象本身。
这里的Date是从文件系统中检索到该对象，插入到响应报文，并发送该响应报文的时间。

常见状态码
200：请求成功 处理方式：获得响应的内容，进行处理
301：请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源 处理方式：重定向到分配的URL
400：非法请求 处理方式：丢弃
404：没有找到 处理方式：丢弃
505：服务器不支持请求报文使用的http版本。

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

HTTP服务器是无状态的，这简化了设计。然而一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者是因为它希望把内容与用户身份联系起来，为此HTTP使用了cookie。

cookie有四个组件：

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

也就是说，作为服务器端，需要做的就是当第一次收到一个HTTP请求的时候，会在后端数据库中建立一个唯一识别码，并以此建立索引，然后将该索引放入到HTTP响应报文中返回响应报文，用户浏览器就会将该cookie以及服务器主机名存放在特定的cookie文件中。当用户之后持续访问的时候，每次请求一个Web页面，浏览器就会查询该特定的cookie文件并且抽取它对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。这样子，服务器就能根据cookie来知道用户的活动。

1.2.5 Web缓存
Web缓存器也叫做代理服务器，他是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。可以通过配置用户的浏览器，使得用户的所有HTTP请求首先指向Web缓存器。
这样的话，当代理服务器收到一个HTTP请求后，它将检查本地是否缓存过该对象，假如在缓存中存在对象并且没有过期，那么缓存直接返回；如果不在缓存中的的话，缓存服务器将根据请求报文里的Host首部行以及请求行里的URL字段请求原始服务器，然后再将对象返回至客户端。因此，Web缓存器即是服务器又是客户，当他接收浏览器的请求并发回响应时，他是一个服务器，当他向初始服务器发出请求并接收响应时，他是一个客户。
通常，代理服务器与客户端的通信速度要快于初始服务器与客户端的连接速度；Web代理服务器可以大起大减少对客户请求的响应时间；而且，缓存器能从整体上大大降低因特网上的web流量，从而有助于提高所有应用程序的性能；

1.2.6 条件GET方法
高速缓存能减少用户感受到的响应时间，但是存放在缓存服务器中的对象副本可能是陈旧的，也就是说保存在服务器中的对象自该副本缓存在客户上以后可能被修改了。因此HTTP协议采用一种机制允许缓存器证识它的对象是最新的。这种机制就是条件GET方法。如果请求报文使用GET方法并且请求报文包含一个‘If-Modified-Since’首部行，那么这个HTTP请求报文就是一个条件GET请求报文。

用户在首次向Web服务器请求某一个对象的时候，缓存器会保存下该对象的内容以及最后修改日期，当有用户再次访问相同的对象时，该对象仍然在这个缓存器时，他就会向Web服务器发送一个条件GET执行最新检查以此来确认是否在Web服务器上对象发生改变，如果发生改变就将回复一个响应报文，并且在响应报文的数据段包含所请求的对象，如果没有改变的话，则在状态行中回复304 Not Modified，它告诉缓存器可以使用该对象。

1.3 因特网中的电子邮件

电子邮件是一种异步通信媒介，即当人们方便时就可以收发邮件，不与他人的计划进行协调。与普通邮件相比，电子邮件更为快速并且易于分发，而且价格便宜。电子邮件系统有三个主要部分构成：用户代理、邮件服务器和简单邮件传输协议(SMTP)。

邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮件。一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送发的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中，当接收方用户要在他的邮箱中读取该报文时，他的邮件服务器需要进行验证。

SMTP是因特网电子邮件中主要的应用层协议，它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。SMTP分为两部分：运行在发送发邮件服务器的客户端和运行在接收方邮件服务器的服务端。每台邮件服务器即运行SMTP的客户端也运行SMTP的服务端。当一个邮件服务器向其他邮件服务器发送邮件时，他就就是客户端，反之则是服务器。

1.3.1 SMTP
SMTP的基本步骤如下所示：

1. 发送方调用其邮件代理程序并提供接收方的邮件地址撰写报文，然后指示用户代理发送该报文
2. 发送方的用户代理把报文发给它的邮件服务器，在那里该报文被放在报文队列中。
3. 运行在发送方的邮件服务器上的SMTP客户端发现了报文队列中的这个报文，它就创建一个到运行在接收方的邮件服务器上的SMTP服务器的TCP连接。
4. 在经过一些初始SMTP握手后，SMTP客户通过该TCP连接发送发送方的报文。
5. 在接收方的邮件服务器上，SMTP的服务端接受该报文。接收方的邮件服务器然后将该报文放入接收方的邮箱。
6. 接收方验证后调用用户代理阅读该报文。

由上可知，SMTP一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器为于地球的两端也是这样的，也就是邮件不会在中间某个邮件服务器保留；在SMTP握手阶段，SMTP客户端将介绍发送方和接收方的邮箱地址；一旦介绍完毕后，SMTP客户端将开始发送报文。

1.3.2 与HTTP的对比
两个协议都是从一台主机向另一台主机传送文件：HTTP从Web服务器向Web用户传送文件；SMTP从一个邮件服务器向另一个邮件服务器传送文件。当进行文件传送时，持续的HTTP和SMTP都使用持续连接，但是也有一些重要的区别：

8. HTTP主要是一个拉协议，即在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息；SMTP基本上是一个推协议，即发送邮件服务器把文件推向接收邮件服务器。
9. SMTP要求每个报文采用7比特ASCII码格式，如果报文包含了非7比特ASCII字符或二进制数据，则该报文必须按照7比他ASCII码进行编码。HTTP数据则不受这种限制。
10. HTTP将不同的对象(例如包含文本以及图形的对象)封装到自己的HTTP响应报文中，而SMTP则把所有报文对象放在一个报文中。

1.3.3 邮件报文格式
当一个人给另一个发送电子邮件时，一个包含环境信息的首部位于报文体前面，这些环境信息包括在一系列首部行中，由RFC 5322定义。首部行和该报文的题用空行进行分隔。RFC 5322定义了邮件首部行和它们的语义解释的精确格式。每个首部必须含有一个From；首部行和一个To；首部行；一个首部也许包含一个subject；首部行以及其他可选的首部行。

1.3.4 邮件访问协议
SMTP是邮件服务器之间发送邮件报文的协议，并不是用户通过代理和邮件服务器之间通信的协议；用户代理使用邮件访问协议来从邮件服务器上获取邮件信息；目前常用的邮件访问协议有POP3（Post Office Protocol-Version 3）、因特网邮件访问协议（IMAP，Internet Mail Access protocol）和HTTP。

1.3.4.1.POP3
POP3是一种极为简单的邮件访问协议，由RFC 1939进行定义。POP3按照三个阶段进行工作：特许、事务处理以及更新：
在第一个阶段即特许阶段，用户代理发送(以明文形式)用户名和口令以鉴别用户。
在第二个阶段即事务处理阶段，用户代理取回报文，同时在这个阶段用户代理还能进行如下操作，对报文进行删除标记，取消报文删除标记以及获取邮件的统计信息。
在第三个阶段即更新阶段，它出现在客户发出了quit命令后，目的是结束该POP3会话，此时该邮件服务器删除那些被标记为删除的报文。

一个需要注意的是，POP3用户代理可以使用两种事务处理模式：一种是下载并删除，另一种是下载保留；POP3代理发出的命令和其工作模式相关；下载并删除的方法存在的问题是，如果用户在一台设备上查看了邮件（下载了邮件）后，邮件将被删除，那么在其他设备上将无法查看邮件；这给用户带来一定的不便。使用下载保存方式，则用户下载邮件后，邮件还在服务器上。

在用户代理与邮箱服务器之间的POP3会话期间，该POP3服务器保留了一些状态信息，特别是标记了哪些用户报文被标记为删除了。但是POP3服务器并不在POP3会话过程中携带状态信息，大大简化了POP3的服务。

1.3.4.2.IMAP

POP3协议无法为用户提供邮件分类管理的功能，虽然用户可以通过将邮件下载到本地，然后由用户代理程序做分类管理，但是处理的结果是无法同步到其他查看设备上的。为了解决这一问题，IMAP诞生了。IMAP是一个邮件访问协议，比POP3要复杂的多，当然也就有更多的特色了。

（远程）IMAP将每一份邮件和一个一个文件夹联系起来，当报文第一次到达服务器时，它与收件人的INBOX相关联。收件人可以将邮件移到新创建的文件夹，阅读邮件，删除邮件等。IMAP允许用户在不同文件夹里移动邮件并且查询邮件。值得注意的是，IMAP服务器维护了IMAP会话的用户状态信息，但是POP3并不；IMAP协议还允许用户代理获取报文组件而不是报文整体。

1.3.4.3.基于Web的电子邮件
这种方式主要是指，用户使用HTTP协议和邮件服务器通信。用户代理就是普通的浏览器，但是，邮件服务器之间还是使用SMTP协议的。

1.4 DNS：英特网的目录服务

DNS的必要性：IP地址标识主机，路由器，但是IP地址不好记忆，不便于人们使用，存在着字符串-ip地址转换的重要性，因此由DNS负责将IP地址转化为二进制的网络地址。

1.4.1 DNS提供的服务
通过主机名或者是IP地址可以识别主机，但是对于人们而言更喜欢主机名标识方式，而路由器则喜欢定长的、有着层次结构的IP地址。为了折中这些不同的偏好，我们需要一种能进行主机名到IP地址转化的目录服务。这就是域名系统的主要任务。
DNS是：
①一个由分层的DNS服务器实现的分布式数据库
②一个使得主机能够查询分布式数据库的应用层协议
DNS服务器通常是运行BIND软件上的UNIX软件，DNS协议运行在UDP之上，使用53号端口。DNS是为因特网上的用户应用程序以及其他软件提供一种核心功能，即将主机名转化为其背后的IP地址。

举个例子，当某个用户主机上的一个浏览器请求URL页面时★：
①同一台用户主机上运行着DNS应用的客户端。
②浏览器从上述URL中抽取出主机名www.xxxxxx.edu，并将这台主机名传给DNS应用的客户端。
③DNS客户向DNS服务器发送一个包含主机名的请求
④DNS客户最终会收到一份回答报文，其中含有对应于该主机名的IP地址。
⑤一旦浏览器接收到来自DNS的该IP地址，它能够向为于该IP地址80端口的HTTP服务器进程发起一个TCP连接。

DNS还提供一些重要的服务：
主机别名：比起主机规范名更加容易记忆，应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址
邮件服务器别名：电子邮件应用程序可以调用DNS，对提供的主机名别名进行解析，以获得该主机的规范主机名以及IP地址。
负载分配：DNS也被用在冗余的服务器之间分配负载。每个服务器有着不同的IP地址，但是它们都和同一个主机名相关联，也就是一个IP地址集合同一个规范主机名相联系；当某个DNS服务器收到DNS请求时，该服务器奖使用IP地址的整个集合作为相应，但是在每个应答中，循环这些地址的次序。因为客户端通常都是使用IP地址集合的首个元素，所以DNS就在冗余的Web服务器之间分配了负载。同理，多个邮件服务器可以具有相同的别名。

1.4.2 DNS的工作机理概述
首先，DNS使用UDP作为其传输层协议；DNS服务使用53端口；当主机上的DNS客户端收到一个转换请求需要将主机名转化为IP地址，客户端将向网络发送一个DNS查询报文，然后客户端将收到一个包含相关信息的DNS回答报文，这个报文里有客户端想要的内容，之后DNS客户端将IP地址返回给请求的提出者即可。从使用DNS服务的请求者来看，DNS就像一个简单的提供直接转换服务的黑盒子，实际上这个黑盒子非常复杂，由分布在全球的大量DNS服务器以及定义DNS服务器和查询主机之间如何通信的应用层协议组成。

集中式设计的DNS服务器具有以下缺点：
①.单点故障：如果集中式的DNS服务器崩溃，整个因特网随之瘫痪
②.通信容量：单个DNS服务器不得不处理所有的DNS查询(用于为上亿太主机产生的所有HTTP请求报文和电子邮件报文服务)。
③.远距离的集中式数据库：存在严重的时延。
④.维护：每新添加一个主机就要进行频繁的更新

1. 分布式、层次数据库
   根DNS服务器、顶级域DNS服务器和权威DNS服务器；举例说明，其工作的普遍流程：一个DNS客户端，希望获得www.baidu.com的IP地址，粗略的说，DNS客户端首先和根DNS服务器取得联系，它将返回负责解析顶级域名com的服务器的IP地址（或者其集合），客户将同这些服务器之一取得联系，然后顶级域DNS服务器建返回baidu.com的权威服务器的IP集合，客户端通过与这些服务器之一取得联系，获得www.baidu.com的IP地址。

   根DNS服务器：因特网上有13个根DNS服务器，大部分分布在北美洲，尽管我们可以将这13个根DNS服务器视为单个的服务器，但是每台服务器实际上是一个冗余的计算机网络以提供安全性和可靠性；
   顶级域DNS服务器：负责顶级域名，如com，org，net，edu，gov以及各个国家的顶级域名的转换。
   权威DNS服务器：因特网上，具有公共可访问主机的每个组织机构必须公共可访问的DNS记录，这些记录将主机名映射为IP地址。一个组织的权威DNS服务器收藏了这些DNS记录，多数大学和大公司实现和维护它们自己的基本和辅助（备份）权威DNS服务器；当然，也可以通过付费的方式，将相关的信息插入到其它权威服务器中；

   除了上面三种DNS服务器，还有一种不在DNS层次结构之中，但是很重要的DNS，是本地DNS服务器。本地DNS服务器通常邻近其所在网络的其他主机。当主机发出DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将请求转发到DNS服务器层次结构中。

   DNS查询有两种，一种是递归查询一种是迭代查询；实践中，查询通常满足这样的模式：从请求主机到本地DNS服务器的查询是递归的，其余查询是迭代的。所谓迭代就是，如果请求的接收者不知道所请求的内容，那么接收者将扮演请求者，发出有关请求，直到获得所需要的内容，然后将内容返回给最初的请求者。也就是说，在递归查询中，一定要给请求者想要的答案；迭代查询则是指，如果接收者没有请求者所需要的准确内容，接收者将告诉请求者，如何去获得，但是自己并不去发出请求。
   递归查询：名字解析负担都放在当前联络的名字服务器上。
   迭代查询：本地DNS服务器查询根DNS服务器，根服务器不知道但可以将其子域返回，即告诉本地DNS服务器根DNS服务器的子域，以此迭代。

2. DNS缓存
   DNS缓存实际上是为了盖上时延性能并且减少在因特网上传输的DNS报文数量而引入的。DNS缓存原理十分简单，每当DNS服务器发出请求后收到回答时，就将回答的内容缓存在它自己的主机空间上。这样，如果有相同的请求到达时，就不需要再去发出请求，直接使用缓存即可；因为有了缓存，本地DNS就可以直接提供一些经常被访问的主机名所对应的IP地址，而不需要询问根DNS服务器了。需要注意的是，缓存不可避免的一个问题：有效时间。如果缓存过时而未得到更新，那么就会导致一些请求失败。

2.4.3 DNS记录和报文

• DNS记录
  共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(RR)，RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。
  资源记录是一个包含了下列字段的四元组：
  (Name, Value, Type, TTL)
  TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。Name和Value的值取决于Type，对应不同的Type四元组的意义不同：

1. type=A：则name为主机名，value为对应的IP地址；

2. type=NS：则name为域，value为如何获得该域下主机IP地址的权威DNS服务器的主机名；

3. type=CNAME：则value为name（本身为主机别名）所对应的主机的规范主机名；

4. type=MX：则value为那么所对应的邮件服务器的规范主机名；

   如果为了获得邮件服务器的规范主机名，请求一条MX记录；为了获得其它服务器的规范主机名，请求一条CNAME记录，所以如果一条记录为type=A，则它直接包含了需要的信息；如果是NS，需要进一步得到权威DNS服务器的IP地址（同时返回一条NS记录，并返回一条以该NS记录的value值为name的A记录）希望得到一条A记录；而type=CNAME和MX的记录则实现了主机别名到主机规范名的转换，可以通过该规范名继续构建查询链条，直到获得希望的IP地址；

• DNS报文
  DNS报文有两种，即查询报文和回答报文，并且两种报文有着相同的结构
  

  前12字节为首部区域。标识符是一个用来标记该查询的16比特数。该标志符会被复制到相应的回答报文里，以便匹配请求和回答；

  标志字段有若干标志，用来指出报文的类型（请求还是响应）、查询类型（递归还是迭代）、是否是所请求名字的权威DNS服务器、以及4个有关数量的字段，用来指示4类数据区域出现的数量；

  问题区域包含了正在进行的查询信息，包括名字字段、查询类型；

  回答区域包含了对最初请求的名字的资源记录，回答报文的回答区域可以包含多条RR，因此一个主机名能有多个IP地址；

  权威区域包含了其他权威服务器的信息；

  附加区域包含了其它有帮助的记录，比如在对于一个MX类型的请求回答报文里，回答区域里指出了邮件服务器的规范主机名，而附加区域里就有可能包含一个类型为A的关于该规范主机名的的IP地址；

• 向DNS数据库中插入数据
  需要在注册登记机构(registrar)完成这一任务，当你注册一个域名时，需要向该机构提供你的基本和辅助DNS服务器的名字和IP地址；该注册机构将确保一个类型为NS和类型为A的记录输入对应的顶级域名服务器；这样就完成了插入数据

1.5 P2P文件分发

P2P模式适用于一下模式:对总是打开的基础设施服务器没有依赖，成对间歇连接的主机之间相互通信。

有两种典型因特网应用十分适合P2P体系结构，一种是文件分发（BitTorrent)，另一种是大型对等方社区中的数据库；我们将探讨分布式散列表的概念。P2P体系结构有着良好的自扩展性。这种扩展性的直接成因是：对等方除了比特的消费者之外还是他们的重新分发者。

• BitTorrent
  BitTorrent 是一种用于文件分发的流行P2P协议；用BitTorrent的术语来说，参与一个特定文件分发的所有对等方的集合被称为一个洪流；在一个洪流中的对等方彼此下载等长度的文件块；当一个对等方下载文件块的时候，也向其他对等方发送了多个块；一旦某对等方获得了完整文件，就可以自私地离开洪流或者大公无私地留下来继续向其他对等方发送文件.

  P2P文件共享协议，参与一个特定文件分发的所有对等方结合被称为一个洪流（torrent），在一个洪流的对等方彼此下载等长度的文件块，可以随时离开洪流，也可继续向其他对等方上载。每个洪流都有一个追踪器。
  Alice加入某洪流时，会在追踪器里进行注册，周期性通知追踪器它仍在洪流中。我们称所有与ALICE成功的创建了一个TCP链接的对等方成为邻近对等方。
  洪流随机从参与对等方的结合中选择一个子集，将他们的IP地址发给Alice，Alice维护这张对等方列表，试图与所有对等方建立并行的TCP连接。
  Alice周期询问每个邻近对等方（连上的）他们有的文件块列表，她随时知道邻居有哪些文件块
  Alice使用最稀缺优先技术，首先请求那些邻居们副本数量最少的块，使该文件块迅速分发，以均衡每个块在洪流中的副本数量
  BitTorrent使用一种算法，Alice优先从像她传时速度最快的邻居（4个，每10s修改一次）那里获取文件块。
  每过30s，Alice也要随机选择另外一个对等方Bob，向他发送块。若Alice是Bob最快的前四快，Bob也是Alice的前4快，则Bob和Alice互相发送数据。
  每过30s换一个新的对象，互相交换数据（一报还一报），为了使对等方能够找到彼此协调的速率上传

1.6 视频流和内容分发网

1.6.1 因特网视频
视频是一系列的图像，通常以一种恒定的速率来展现。一幅未压缩，数字编码的图像由像素阵列组成，其中每个像素是由一些比特编码来表示亮度和颜色。视频的一个重要特征是它能够被压缩，因而可以用比特率来衡量视频质量。比特率越高，图像质量越好。到目前为止，对流式视频的最为重要的性能度量是平均端到端吞吐量。为了提供连续不断的布局，网络必须为流式应用提供平均吞吐量，这个流式应用至少与压缩视频的比特率一样大。

1.6.2 HTTP流和DASH
在HTTP流中，视频只是存储在HTTP服务器中作为一个普通的文件，每个文件有一个特定的URL。当用户要看该视频时，客户与服务器创建一个TCP连接并发送对该URL的HTTP GET请求。服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个HTTP响应中发送该视频文件。在客户端，一旦该缓存中的字节数量超过预先设定的门限，客户应用程序就开始播放。

存在的问题就是所有客户接收到相同编码的视频，因此导致一种新型基于HTTP的流的研发，它常常被称为经HTTP的动态适应性流(DASH)，在DASH中，视频编码分为几个不同的版本，每个版本有不同的比特率，对应于不同的质量水平。使用DASH后，每个视频版本存储在HTTP服务器中，每个版本都有一个不同的URL。HTTP服务器也有一个告示文件，为每个版本提供了一个URL及其比特率，以此来根据测量的接受带宽选择不同速率的版本。

1.6.3 内容分发网
为了应对向分布于全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网(CDN)。CDN管理分布在多个地理位置上的服务器，在他的服务器上存储视频(和其他类型的Web内容)的副本，并且所有试图将每个用户请求定向到一个将提最好的用户体验的CDN位置。

CDN可以是专用CDN，即它由内容提供商自己所拥有；另一种CDN可以是第三方CDN，它代表多个内容提供商分布内容。

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

1. 深入
   其目标是靠近端用户，通过减少端用户和CDN集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量。
2. 邀请做客
   通过在少量关键位置建造大集群来邀请到ISP做客，此设计通常产生较低的维护和管理开销，可能以对端用户的较高时延和较低吞吐量为代价。

1.6.3.1 CDN操作
当用户主机中的一个浏览器指令检索一个特定的视频(由URL标识)时，CDN必须截取获该请求，以便能：
①确定此时适合用于该用户的CDN服务器集群；
②将客户的请求重定向到该集群的某台服务器。
大多数CDN利用DNS来截获和重定向请求，如下所示：

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

1.6.3.2 集群选择策略
任何CDN部署，其核心是集群选择策略，即动态地将客户定向到CDN中的某个服务器集群或数据中心的机制。
一种简单的策略是指派客户到地理上最为临近的集群，每个LDNS IP地址都映射到一个地理位置。但是对于某些客户，该方案可能效果比较差，因为就网络路径的长度或跳数而言，地理最邻近的集群可能并不是最近的集群。
另一种所有基于DNS的方法都内在具有的问题是，某些端用户配置使用位与远地的LDNS，在这种情况下,LDNS位置可能远离客户的位置，此外这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化，总是为特定的用户指派相同的集群。
为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量。