计算机网络自顶向下第二章应用层笔记

计算机网络自顶向下第二章应用层笔记

乌乌

来自本人研读几晚和笔记几晚的成果记录，记录计网成长

1.网络应用是计算机网络存在的理由。研发网络应用程序的核心是写出能运行在不同的端系统和通过网络彼此通信的程序。

2.在Web应用程序中，有两个互相通信的不同的程序：一个是运行在用户主机上的浏览器程序；另一个是运行在Web服务器主机 上的Web服务器程序。另一个例子是P2P文件共享系统，在参与文件共享的社区中的每台主机中都有一个程序。

3.网络核心设备并不在应用层上起作用，而仅在较低层起作用，特别是在网络层及下面层次起作用。这种基本设计，即将应用软件限制在端系统。

4.记住应用程序的体系结构明显不同于网络的体系结构。网络体系结构是固定的，并为应用程序提供了特定的服务集合。应用程序体系结构由应用程序研发者设计, 规定了如何在各种端系统上组织该应用程序。

5.两种主流体系结构：客户-服务器体系结构或对等（P2P）体系结构。

客户-服务器体系结构中，有一个总是打开的主机称为 服务器，它服务于来自许多其他称为客户的主机的请求。利用客户-服务器体系结构，客户相互之间不直接通信

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

在一个客户-服务器应用中，常常会出现一台单独的服务器主机跟不上它所有客户请求的情况。配备大量主机的数据中心常被用于创建强大的虚拟 服务器。搜索引擎因特网商务基于Web的电子邮件，应用了一个或多个数据中心。

一个数据中心能够有数十万台服务器，它们必须要供电和维护。服务提供商必须支付互联和带宽费用，以发送和接收到达/来自数据中心的数据。

P2P 体系结构中，对位于数据中心的专用服务器有最小的 依赖。应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方.这些对等方为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。

因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。许多目前流行的、流量密集型应用都是P2P体系结构的。包括文件共享 ,对等方协助下载加速器、因特网电话和视频会议（例如Skype）。

某些应用具有混合的体系结构，它结合了客户-服务器和P2P的元素。例如，对于许多即时讯息应用而言，服务器被用于跟踪用户的IP地址，但用户到用户的报文在用 户主机之间（无须通过中间服务器）直接发送.

自扩展性：尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。P2P体系结构成本效率高,不需要庞大的服务器基础设施和服务器带宽。然而，未来P2P应用由于高度非集中式结构，面临安全性，性能和可靠性等挑战。

6.进行通信的实际上是进程而不是程序。一个进程可以被认为是运行在端系统中的一个程序。当多个进程运行在相同的端系统上时，它们使用进程间通信机制相互通信。进程间通信的规则由端系统上的操作系统确定。在两个不同端系统上的进程，通过跨越计算机网络交换报文而相互通信。 发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过回送报文进行响 应。

7.客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。通常将两个进程之一标识为客户,而另一个进程标识为服务器。 在P2P文件共享的某些应用中，一个进程能够既是客户又是服务器。

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

8.进程与计算机网络之间的接口

两个进程互相发送报文。进程通过一个称为套接字(socket）的软件接口向网络发送报文和从网络接收报文。进程可类比于一座房子，而它的套接字可以类比于它的门。当一个进程想向位于另外一台主机上的另一个进程发送报文时，它把报文推出该门（套接字）。该发送进程假定该门到另外一侧之间有运输的基础设施，该设施将把报文传送到目的进程的门口。 一旦该报文抵达目的主机，它通过接收进程的门（套接字）传递，然后接收进程对该报文进行处理。 套接字是同一台主机内应用 层与运输层之间的接口。套接字也 称为应用程序和网络之间的应用程序编程接口。

应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。应用程序开发者对于运输层的控制仅限于：①选择运输层协议；②也许能设定几 个运输层参数，如最大缓存和最大报文段长度等（将在第3章中涉及）。

9.进程寻址

为了向特定目的地发送邮政邮件，目的地需要有一个地址。为了标识该接收进程：①主机的地址；②在目的主机中指定接收进程的标识符在因特网中，主机由其IP地址标识。发送进程还必须指定运行在接收主机上的接收套接字==目的地端口号。Web服务器用端口号80来标识。邮件服务器进程(使用SMTP协议)用端口号25来标识。

10.套接字是应用程序进程和运输层协议之间的接口。在发送端的应用程序将报文推进该套接字。在该套接字的另一侧，运输层协议负责从接收进程的套接字得到该报文。运输层协议能够为调用它的应用程序提供四个方面服务：可靠数据传输、吞吐量、定时和安全性。

1.可靠数据传输

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

当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用所接受，最值得注意的是多媒体应用，如交谈式音频/视频，它们能够承受一定量的数据丢失。在这些多媒体应用中，丢失的数据引起播放的音频/视频出现小干扰。

2.吞吐量

在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。可用吞吐量将随时间波动。这些观察导致另一种自然的服务，即运输层协议能够以某种特定的速率提供确

保的可用吞吐量。具有吞吐量要求的应用程序被称为带宽敏感的应用。许多当前的多媒体应用是带宽敏感的，带宽敏感的应用具有特定的吞吐量要求，而弹性应用能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。电子邮件、文件传输以及Web传送 都属于弹性应用。当然，吞吐量是越多越好。

3.定时

定时保证能够以多种形式实现。对于非实时的应用，较低的时延总比较高的时延好，但对端到端的时延没有严格的约束。

4.安全性

最后，运输协议能够为应用程序提供一种或多种安全性服务。在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。这种服务将在发送和接收进程之间提供机密性，以防该数据以某种方式在这两个进程之间被观察到。运输协议还能提供数据完整性和端点鉴别。

11.因特网（更一般的是TCP/IP网络）为应用程序提供两个运输层协议，即UDP和TCP。每个协议为调用它们的应用程序 提供了不同的服务集合。

1.TCP服务

TCP服务模型包括面向连接服务和可靠数据传输服务。

**•面向连接的服务：**在应用层数据报文开始流动之前，TCP让客户和服务器互相交 换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组 的到来做好准备。在握手阶段后，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。

**•可靠的数据传送服务：**通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的 字节流交付给接收方的套接字，而没有字节的丢失和冗余。

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

12.TCP的加强版本，称为安全套接字层。用SSL加强后的TCP不仅能够做 传统的TCP所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别。SSL是一种对TCP的加强，这种强化是在应用层上实现的。如果一个应用程序要使用SSL的服务，它需要在该应用程序的客户端和服务器端包括SSL代码 。SSL有它自己的套接字API,这类似于传统的TCP。

**套接字API：**当一个应用使用SSL时，发送进程向SSL套接字传递明文数据；在发送主机中的SSL则加密该数据并将加密的数据传递给TCP套接字。加密的数据经因特网传送 到接收进程中的TCP套接字。该接收套接字将加密数据传递给SSL,由其进行解密。最 后，SSL通过它的SSL套接字将明文数据传递给接收进程。

13.UDP服务

UDP是一种不提供不必要服务仅提供最小服务的轻量级运输协议。UDP是无连接的，没有握手过程。UDP协议提供一种不可靠数据传送服务，UDP协议并不保证该报文将到达接收进程。报文也可能是乱序到达的。UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层 （网络层）注入数据。实际端到端吞吐量可能小于该速率。

14.我们已经从4个方面组织了运输协议服务：可靠数据传输、吞吐量、定时和安全性。总之，今天的因特网通常能够为时间敏感应用提供满意的 服务，但它不能提供任何定时或带宽保证。 电子邮件、远程终端访问、Web文件传输都使用了 TCP。这些应用选择TCP的最主要原因是TCP提供了可靠数据传输服务，确保所有数据最终到达目的地。

因为因特网电话应用（如Skype）通 常能够容忍某些丢失但要求达到一定的最小速率才能有效工作，将该应用运行在UDP上，从而设法避开TCP的拥塞控制机制和分组开销。 但因为许多防火墙被配置成阻挡（大多数类型的）UDP流量，所以因特网电话应用通常设计成如果UDP通信失败就使用TCP作为备份

应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。特别是应用层协议定义了 ：交换的报文类型，例如请求报文和响应报文。

•各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。

•字段的语义，即这些字段中的信息的含义。

•确定一个进程何时以及如何发送报文，对报文进行响应的规则。

RFC文档位于公共域中。还有很多别的应用层协议是专用的，有意不为公共域使用。应用层协议只是网络应用的一部分。

Web的应用层协议是超文本传输协议HTTP,它是Web的核心，在RFC 中进行了定义。HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。HTML基本文件通过对象的URL地址引用页面中的其他对象。每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

因为 Web 浏览器实现了 HTTP 的客户端，它用于存储Web对象，每个对象由URL寻址。HTTP定义了 Web客户向Web服务器请求Web页面的方式，以及服务器向客户传 送Web页面的方式。当用户请求一个Web页面，浏览器向服务器发出对该页面中所包含对象的HTTP请求报文，服务器接收到请求并用包含这些对象的HTTP响应报文进行响应。

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

TCP为HTTP提供可靠数据传输服务。这意味着，一个客户进程发出的每个HTTP请求报文最终能完整地到达服务器；类似地，服务器进程发出的每个HTTP响应报文最终能完整地到达客户。分层体系结构最大的优点：HTTP协议不用担心数据丢 失，也不关注TCP从网络的数据丢失和乱序故障中恢复的细节。那是TCP以及协议栈较低层协议的工作。

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

因为HTTP服务器并不保存关于客户的任何信息，HTTP是一个无状态协议。Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自数以百万计的不同浏览器的请求。

当客户-服务器的交互是经TCP进行的，即每个请求/响应对是经一个单独的TCP连接发送，该应用程序被称为使用非持续连接。所有的请求及其响应经相同的TCP连接发 送被称为使用持续连接。

HTTP既能够使用非持续连接，也能够使用持续连接。尽管HTTP在其默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接。

1.采用非持续连接的HTTP

其中每个TCP连接在服务器发送一个对象后 关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。

往返时间（ RTF）的定义指一个短分组从客户到服务器然后再返回客户所花费的时间。RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。

三次握手中前两个部分所耗费的时间占用了一个RTT。完成了三次握手的前两个部分后，客户结合三次握手的第三部分（确认）向该TCP连接发 送一个HTTP请求报文。一旦该请求报文到达服务器，服务器就在该TCP连接上发送HTML文件。该HTTP请求/响应用去了另一个RTT。因此，粗略地讲，总的响应时间就是两个RTT加上服务器传输HTML文件的时间。

2.采用持续连接的HTTP

非持续连接有一些缺点。

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

第二，就像我们刚描述的那样，每一个对象经受两倍RTT的交付时延,即一个RTT用于创建TCP,另一个RTT用于请求和接收一个对象。

在采用HTTP 1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在 相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行。对对象的这些请求可以一个接一个地发出，而不必等待对未决请求（流水线）的回答。如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。

HTTP 规范包含了对HTTP 报文格式的定义。HTTP报文有两种：请求报文和响应报文。

1.HTTP请求报文

报文是用普通的ASCII文本书写的，每行由一个回车和换行符结束。最后一行后再附加一个回车换行符。一个请求报文能够具有更多的行或者至少为一行。

HTTP请求报文的第一行叫作请求行,其后继的行叫作首部行。请求行有3个字段：方法字段、URL字段和HTTP版本字段。

方法字段包括GET、POST、HEAD、PUT和DELETE。绝大部分的HTTP请求报文使用GET方法。在首部行（和附加的回车和换行）后有一个“实体体” 。使用GET方法时实体体为空，而使用POST方法时才使用该实体体。如果方法字段的值为POST时， 则实体体中包含的就是用户在表单字段中的输入值。

HEAD方法类似于GET方法。当服务器收到一个使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径（目录）。PUT方法也被那些需要向Web服务器上传对象的应用程序使用。DELETE方法允许用户或者应用程序删除Web服务器上的对象。

2.HTTP响应报文

一条典型的HTTP响应报文有三个部分：一个初始状态行 , 6个首部行,然后是实体体。实体体部分是报文的主要部分，即它包含了所请求的对象本身。状态行有3个字段：协议版本字段、状态码和相应状态信息。

我们现在来看看首部行。

Connection： close首部行告诉客户，发送完报文后 将关闭该TCP连接。

Date：首部行指示服务器产生并发送该响应报文的日期和时间。这个时间是服务器从它的文件系统中 检索到该对象，将该对象插入响应报文，并发送该响应报文的时间。

Server:首部行指示该报文是由一台Apache Web服务器产生的，它类似于HTTP请求报文中的User-agent:首部行。

Last-Modified:首部行指示了对象创建或者最后修改的日期和时间。Last- Modified:首部行对既可能在本地客户也可能在网络缓存服务器上的对象缓存来说非常重要。

Content-Length： 首部行指示了被发送对象中的字节数。Content-Type:首部行指示了实体体中的对象是HTML文本。（该对象类型应该正式地由Content-Type:首部行而不是用文件扩展名来指示。）

一些常见的状态码和相关的短语包括：

• 2000K：请求成功，信息在返回的响应报文中。

• 301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应报

文的Location:首部行中。客户软件将自动获取新的URL。

• 400 Bad Request: 一个通用差错代码，指示该请求不能被服务器理解。

• 404 Not Found:被请求的文档不在服务器上。

• 505 HTTP Version Not Supported:服务器不支持请求报文使用的HTTP协议版本。

浏览器产生的首部行与很多因素有关。包括浏览器的类型和协议版本（例如，HTTP/1. 0浏览器将不会产生任何1.1版本的首部行）、浏览器的用户配置（如喜好的语言）、浏览器当前是否有一个缓存的但是可能超期的对象版本。Web服务器的表现也类似：在产品、版本和配置上都有差异，所有这些都会影响响应报文中包含的首部行。

19.cookie

HTTP服务器是无状态的。一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者它希望把内容与 用户身份联系起来。为此，HTTP使用了 cookie。cookie在［RFC 6265 ］中定义，它允许站点对用户进行跟踪。

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

cookie可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识。在后继会话中，浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。

它的使用仍具有争议，因为它们被认为是对用户隐私的一种侵害。结合cookie和用户提供的账户信息,Web站点可以知道许多有关用户的信息，并可能将这些信息卖给第三方。

20.web缓存

Web缓存器也叫代理服务器,它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本。所有HTTP请求首先指向Web缓存器，一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该Web缓存器。

值得注意的是Web缓存器既是服务器又是客户。当它接收浏览器的请求并发回响应时，它是一个服务器。当它向初始服务器发出请求并接收响应时，它是一个客户。

Web缓存器通常由ISP购买并安装。例如，一所大学可能在它的校园网上安装一台缓 存器，并且将所有校园网上的用户浏览器配置为指向它。或者，一个主要的住宅ISP可能在它的网络上安装一台或多台Web缓存器，并且预先配置其配套的浏览器指向这些缓存器。

在因特网上部署Web缓存器有三个原因。

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

2 Web缓存器能够大大减少一个机构的接入链路到因特网的通信量。通过减少通信量，该机构就不必急于增加带宽，因此降低了费用。

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

总的响应时间，即从浏览器请求一个对象到接 收到该对象为止的时间，是局域网时延、接入时延（即两台路由器之间的时延）和因特网时延之和。

如果流量强度接近1， 链路上的时延会变得非常大并且无限增长。满足请求的平均响应时间将在分钟的量级上。显然，必须想办法来改进时间响应特性。

1 增加接入链路的速率, 这可以将接入链路上 的流量强度减少，两台路由器之间的链路时延也可以忽略了。总的响应时间将大约为2秒，即为因特网时延。但这种解决方案也意味着将它的接入链路由升级 , 这是一种代价很高的方案。

2 在机构网络中安装一个Web缓存器。实践中的命中率（即 由一个缓存器所满足的请求的比率）通常在0.2〜0.7之间。一般而言，在15Mbps链路上，当流量强度小于0.8时对应的时延较小, 约为几十毫秒。这个时延与2秒因特网时延相比是微不足道的。

第二种解决方案提供的响应时延甚至比第一种解决方案更低，也不需要该机构升级它到因特网的链路。该机构理所当然地要购买和安装Web缓存器。其成本较低，很多缓存器使用了运行在廉价PC上的公共域软件。

通过使用内容分发网络（CDN） , Web缓存器正在因特网中越来越重要。CDN公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化。有多个共享的CDN 和专用的CDN。

21.条件GET方法

尽管高速缓存能减少用户感受到的响应时间，存放在缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。幸运的是，HTTP协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是条件GET 方法。

条件GET请求报文：①请求报文使用GET方法；②请求报文中包含一个“ If Modified-Since： ”首部行。

该缓存器在将对象转发到请求的浏览器的同时，也在本地缓存了该对象。缓存器在存储该对象时也存储了最后修改日期。一个星期后，另一个用户经过该缓存器请求同一个对象，该对象仍在这个缓存器中。在过去的一个星期中位于Web服务器上的该对象可能已经被修改了，该缓存器通过发送一个条件GET执行最新检查。

该条件GET报文告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。作为对该条件GET方法的响应，该Web服务器仍发送一个响应报文，但并没有在该响应报文中包含所请求的对象。包含该对象只会浪费带宽，并增加用户感受到的响应时间。

22.因特网中的电子邮件

因特网电子邮件系统的总体情况：3个主要组成部分：用户代理、邮件服务器和简单邮件传输协议。用户代理允许用户阅读、回复、转 发、保存和撰写报文。

当Alice完成邮件撰写时，她的邮件代理向其邮件服务器发送邮件，此时邮件放在邮件 服务器的外出报文队列中。当Bob要阅读报文时，他的用户代理在其邮件服务器的邮箱中取得该报文。 Bob的邮箱管理和维护着发送给他的报文。如果Alice的服务器不能将邮件交付给Bob的服务器,Alice的邮件服务器在一个报文队列中保持该报文并在以后尝试再次发 送。通常每30分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方。

邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮箱。

邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。当Bob要在他的邮箱中读取该报文时，包含他邮箱的邮件服务器（使用用户名和口令）来鉴别Bob。Alice的邮箱也必须能处理Bob的邮件服务器的故障。

SMTP是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。

SMTP有两个部分：运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端。 每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。当一个邮件服务器向其他邮件服务器发送邮件时，它就表现为SMTP的客户；当邮件服务器从其他邮件服务器上接收邮件时，它就表现为一个SMTP的服务器。

23.SMTP

RFC 5321给出了 SMTP的定义。SMTP是因特网电子邮件的核心。

SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器。SMTP问世的时 间比HTTP要长得多。它所具有的某种陈旧特征表明它仍然是一种继承的技术。例如，它限制所有邮件报文的体部分（不只是其首部）只能采用简单的7比特ASCII表示。即在用SMTP传送邮件之前,需要将二进制多媒体数据编码为ASCII码，并且在使用SMTP传输后要求将相应的应用层 ASCII码邮件解码还原为多媒体数据。使用HTTP传送前不需要将多媒体数据编码为ASCII码。

SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。特别是，如果接收方的邮件服务器没有开机，该报文会保留在发送方的邮件服务器上并等待进行新的尝试，这意味着邮件并不在中间的某个邮件服务器存留。

客户SMTP （运行在发送邮件服务器主机上）在25号端口建立一个到服务器SMTP （运行在接收邮件服务器主机上）的TCP连接。如果服务器没有开机，客户会 在稍后继续尝试连接。一旦连接建立，服务器和客户执行某些应用层的握手。在SMTP握手的阶段，SMTP客户指示发送方的邮件地址（产生报文的那个人） 和接收方的邮件地址。一旦该SMTP客户和服务器彼此介绍之后，客户发送该报文。

SMTP能依赖TCP提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户如果有另外的报文要发送到该服务器，就在该相同的TCP连接上重复这种处理；否则,它指示TCP关闭连接。

24.与HTTP的对比

共同特征：

SMTP和HTTP这两个协议都用于从一台主机向另一台主机传送文件：HTTP从Web服务器向Web客户传送文件；SMTP从一个邮件服务器向另一个邮件服务器传送文件。当进行文件传送时，持续的HTTP和SMTP都使用持续连接。因此，这两个协议有一些。

区别：

1 HTTP主要是一个拉协议, 在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息。特别是TCP连接是由想接收文件的机器发起的。SMTP基本上是一个推 协议,即发送邮件服务器把文件推向接收邮件服务器。特别是，这个TCP连接是由要发送该文件的机器发起的。

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

3 如何处理一个既包含文本又包含图形（也可能是其他媒体类型）的文档。HTTP把每个对象封装到它自己的HTTP响应报文中,而SMTP则把所有报文对象放在一个报文之中。

25.邮件报文格式

当一个人给另一个人发送电子邮件时，一个包含环境信息的首部位于报文体前面。这些环境信息包括在一系列首部行中，这些行由RFC 5322定义。首部行和该报文的体用空行进行分隔。RFC 5322定义了邮件首部行和它们的语义解释的精确格式。如同HTTP协议, 每个首部行包含了可读的文本，是由关键词后跟冒号及其值组成的。

每个首部必须含有一个From：首部行和一个To：首部行；一个首部也许包含一个Subject：首部行以及其他可选的首部行。这些首部行不同于SMTP命令，那节中的命令是SMTP握手协议的一部分；本节中考察的首部行则是邮件报文自身的一部分。

26.邮件访问协议

一旦SMTP将邮件报文从Alice的邮件服务器交付给Bob的邮件服务器，该报文就被放入了 Bob的邮箱中。假定Bob是通过登录到服务器主机，并直接在该主机上运行一个邮件阅读程序来阅读他的邮件的。在今天，邮件访问使用了一种客户-服务器体系结构，即典型的用户通过在用户端系统上运行的客户程序来阅读电子邮件，通过在本地主机上运行邮件客户程序。假设接收方在其本地PC运行用户代理程序，考虑在他的本地PC也放置一个邮件服务器是自然而然的事。在这种情况下，Alice的邮件服务器就能直接与Bob的PC进行对话了。

前面讲过邮件服务器管理用户的邮箱，并且运行SMTP的客户端和服务器端。如果Bob的邮件服务器位于他的PC上，那么为了能够及时接收可能在任何时候到达的新邮件，他的PC必须总是不间断 地运行着并一直保持在线。典型的用户通常在本地PC上运行一个用户代理程序，而它访问存储在总是保持开机的共享邮 件服务器上的邮箱。该邮件服务器与其他用户共享，并且通常由用户的ISP进行维护 。

现在我们考虑当从Alice向Bob发送一个电子邮件报文时所取的路径。我们刚才已经知道，在沿着该路径的某些点上，需要将电子邮件报文存放在Bob的邮件服务器上。通过让Alice的用户代理直接向Bob的邮件服务器发送报文，就能够做到这一点。这能够由SMTP来完成：实际上，SMTP被设计成将电子邮件从一台主机推到另一台主机。Alice的用户代理用SMTP将电子邮件报文推入她的邮件服务器，接着她的 邮件服务器再用SMTP将该邮件中继到Bob的邮件服务器。主要是因为不通过Alice的邮件服务器进行中继，Alice的用户代 理将没有任何办法到达一个不可达的目的地接收服务器。通过首先将邮件存放在自己的邮件服务器中，Alice的邮件服务器可以重复地尝试向Bob的邮件服务器发送该报文，如每30分钟一次，直到Bob的邮件服务器变得运行为止。如果Alice的邮件服务器关机, 她则能向系统管理员进行申告！

Bob的用户代理不能使用SMTP得到报文，因为取报文是一个拉操作，而SMTP协议是一个推协议。通过引入一个特殊的邮件访问协议来解决这个难题，该协议将Bob邮件服务器上的报文传送给他的本地PC。第三版的邮局协议、因特网邮件访问协议以及 HTTP。

SMTP用来将邮件从发送方的邮件 服务器传输到接收方的邮件服务器；SMTP也用来将邮件从发送方的用户代理传送到发送 方的邮件服务器。如POP3这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理。

27.POP3

POP3是一个极为简单的邮件访问协议，由RFC 1939进行定义。文档RFC 1939简短且可读性强。该协议非常简单，功能相当有限。当（客户）打开了一个到（服务器）端口 110上的TCP连接后，POP3就开始工作。

POP3按照三个阶段进行工作：特许、事务处理以及更新。

1 在特许阶段，用户代理发送（以明文形式）用户名和口令以鉴别用户。

2 在事务处理阶段，用户代理取回报文；同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。

3 在更新阶段，它出现在客户发出了 quit命令之后，目的是结束该POP3会话；这时，该邮件服务器删除那些被标记为删除的报文。

事务处理过程中，服务器对每个命令做出回答。 回答可能有两种：+0K ，被服务器用来指示前面的命令是正常的；-ERR,被服务器用来指示前面的命令出现了某些差错。特许阶段有两个主要的命令：user < user name >和pass < password >.

事务处理过程中使用POP3的用户代理通常被用户配置为“下载并删除”或者“下载并保留”**方式。POP3用户代理发岀的命令序列取决于用户代理程序被配置为这两种工作方式的哪一种。使用下载并删除方式，用户代理发出list、retr和dele命令。语法定义在RFC 1939中。

1 使用下载并删除方式存在的问题是，邮件接收方Bob可能是移动的，可能希望从多个不同的机器访问他的邮件报文，如果Bob最先是在他办公室的PC上收取了一条邮件，那么晚上当他在家里时，通过他的便携机将不能再收取该邮件。

2 使用下载并保留方式，用户代理下载某邮件后，该邮件仍保留在邮件服务器上。这时，Bob就能通过不同的机器重新读取这些邮件；他能在工作时收取一封报文，而在工作回家后再次访问它。

在用户代理与邮件服务器之间的POP3会话期间，该POP3服务器保留了一些状态信 息；记录了哪些用户报文被标记为删除了。然而，POP3服务器并不在POP3会话过程中携带状态信息。会话中不包括状态信息大大简化了 POP3服务的实现

28.IMAP

使用POP3访问时，一旦Bob将邮件下载到本地主机后，他就能建立邮件文件夹,并将下载的邮件放入该文件夹中。这种文件夹和报文存放在本地主机上的方式，会给移动用户带来问题，无法使用一个在远程服务器上的层次文件夹从任何一台机器上对所有报文进行访问。

由RFC 3501定义的因特网邮件访问协议 （IMAP）应运而生。和POP3 —样，IMAP是一个邮件访问协议，具有更多的特色复杂得多。（因此客户和服务器端的实现也都复杂得多。）

1 MAP服务器把每个报文与一个文件夹联系起来；当报文第一次到达服务器时，它 与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。IMAP还为用户提供了在远程文件夹中查询邮件 的命令，按指定条件去查询匹配的邮件。值得注意的是，IMAP服务器维护了 IMAP会话的用户状态信息，

2 它具有允许用户代理获取报文某些部分的命令。一 个用户代理可以只读取一个报文的报文首部，或只是一个多部分MIME报文的一部分。 使用低带宽连接（如一个低速调制解调器链路）， 特性非常有用。使用这种低带宽连接时，用户可能并不想取回他邮箱中的所有邮件，其要避免可能包含如音频或视频片断的大邮件。

29.DNS：因特网的目录服务

在特定环境下，某种识别方法可能比另一种方法更为适合。例主机的一种标识方法是用它的主机名 然而，主机名几乎没有提供 关于主机在因特网中位置的信息。因为主机名可能由不定长的字母数字组成，路由器难以处理。由于这些原因，主机也可以使用所谓IP地址进行标识。

一 个IP地址由4个字节组成，并有着严格的层次结构。其中的每个字节都被句点分隔开来，表示了 0~255的十进制数字。我们说IP地址具有层次结构，是因为当我们从左至右扫描它时，我们会得到越来越具体的关于主机位于因特网何处的信息（即在众多网络的哪个网络里）。

30.DNS：通过客户-服务器模式提供的重要网络功能

DNS协议是应用层协议，其原因在于：①使用客户-服务器模式运行在通信的端系统之间；②在通信的端系统之间通过下面的端到端运输协议来传送DNS报文。

DNS的作用非常不同于Web应用、 文件传输应用以及电子邮件应用。不同之处在于，DNS不是一个直接和用户打交道的应用，DNS是为因特网上的用户应用程序以及其他软件提供一种核 心功能，即将主机名转换为其背后的IP地址。DNS通过采用了位于网络边缘的客户和服务器,实现了关键的名字到地址转换功能。

31. DNS提供的服务

我们刚刚看到了识别主机有两种方式，通过主机名或者IP地址。人们喜欢主机名，而路由器则喜欢定长的层次结构的IP地址。为了折中偏好，我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统（DNS）的主要任务。

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

DNS 服务器通常是运行 BIND软件的UNIX机器。DNS协议运行在UDP之上，使用53号端口。

DNS通常是由其他应用层协议所使用的，包括HTTP、SMTP和FTP,将用户提供的主 机名解析为IP地址。DNS给使用它的因特网应用带来了额外的时延，有时还相当可观。幸运的是，如我们下面讨论的那样，想获得的IP地址通常就缓存在一个附近的” DNS服务器中，这有助于减少DNS的网络流量和DNS的平均时延。

DNS提供一些重要的服务：

•进行主机名到IP地址的转换。

•主机别名：有着复杂主机名的主机能拥有一个或者多个别名。主机别名（当存在时）比主机规范名更 加容易记忆。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机 的IP地址。

•邮件服务器别名。电子邮件应用程序可以调用DNS,对提供的主机名别名进行解析，以获得 该主机的规范主机名及其IP地址。MX记录允许一个公司的邮件服务器和Web服务器使用相同（别名化的）的主机名。

•负载分配：DNS也用于在冗余的服务器之间进行负载分配。繁忙的站点（被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上，每个都有着不同的IP地址。由于这些冗余的Web服务器，一个IP地址集合因此与同一个规范主机名相联系。DNS数据库中 存储着这些IP地址集合。当客户对映射到某地址集合的名字发出一个DNS请求 时，该服务器用IP地址的整个集合进行响应，但在每个回答中循环这些地址次序。因为客户通常总是向IP地址排在最前面的服务器发送HTTP请求报文，所以DNS就在所有这些冗余的Web服务器之间循环分配了负载。DNS的循环同样可以用于邮件服务器，

DNS由RFC 1034和RFC 1035定义，并且在几个附加的RFC中进行了更新。

32.DNS工作机理概述

假设运行在用户主机上的某些应用程序需要将主机名转换为IP地址。这些应用程序将调用DNS的客户端，并指明需要被转换的主机名用户主机上的DNS接收到后，向网络中发送一个DNS查询报文。所有的DNS请求和 回答报文使用UDP数据报经端口 53发送。经过时延后，用户主 机上的DNS接收到一个提供所希望映射的DNS回答报文。这个映射结果则被传递到调用DNS的应用程序。

DNS是一个提供简单、直接的转换服务的黑盒子实现这个服务的黑盒子非常复杂，它 由分布于全球的大量DNS服务器以及定义了 DNS服务器与查询主机通信方式的应用层协议组成。

DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含所有的映 射。在这种集中式设计中，客户直接将所有查询直接发往单一的DNS服务器，同时该DNS服务器直接对所有的查询客户做出响应。它不适用于当加粗样式今的因特网，因为因特网有着数量巨大（并持续增长）的主机。

这种集中式设计的问题包括:

•单点故障：如果该DNS服务器崩溃，整个因特网随之瘫痪！

•通信容量：单个DNS服务器不得不处理所有的DNS査询（用于为上亿台主机产生的所有HTTP请求报文和电子邮件报文服务）。

•远距离的集中式数据库：单个DNS服务器不可能 “邻近”所有查询客户。如果单台DNS服务器和来自远方的查询必须传播到地球的另一边，中间也许还要经过低速和拥塞的链路，这将导致严重的时延。

•维护：单个DNS服务器将不得不为所有的因特网主机保留记录。 这不仅将使这个中央数据库庞大，而且它还不得不为解决每个新添加的主机而频繁更新。

在单一 DNS服务器上运行集中式数据库完全没有可扩展能力。因此，DNS采用了分布式的设计方案。DNS是一个实现分布式数据库的精彩范例。

33.分布式、层次数据库

为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。这些映射分布在所有的DNS服务器上。大致说来，有3种类型的DNS服务器：根DNS服务器、顶级域DNS服务器和权威DNS服务器。

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

•顶级域(DNS)服务器。对于每个顶级域和所有家的顶级域,都有TLD服务器。Verisign Global Registry Services公司维护com顶级域的TLD服务器，Educause公司维护edu顶级域的TLD服务器。支持TLD的网络基础设施可能是大而复杂的。

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

根、TLD和权威DNS服务器都处在该DNS服务器的层次结构中。还有另一类重要称为本地DNS服务器。严格说来，一个本地DNS服务器并不属于该服务器的层次结构，但它对DNS层次结构是至关重要的。每个ISP （如一个居民区的1SP或一个机构的ISP）都有一台本地DNS服务器（也叫默认名字服务器）。当主机与某个ISP连接时，该ISP提供一台主机的IP地址，该主机具有一台或多台其本地DNS服务器的IP地址。通过访问Windows或UNIX的网络状态窗口，用户能够容易地确定他的本地DNS服务器的IP地址。 主机的本地DNS服务器通常“邻近”本主 机。当主机发岀DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将该请求转发 到DNS服务器层次结构中.

•递归查询：该查询以自己的名义请求url来获得该映射。

•迭代查询：所有的回答都是直接返回给目标url。

任何DNS查询既可以是迭代的也能是递归的。实践中，查询通常遵循：从请求主机到本地DNS服务器的查询是递归的，其余的查询 是迭代的。

34.DNS缓存

DNS缓存：为了改善时延性能并减少在因特网上到处传输的DNS报文数量。

DNS缓存的原理非常简单。在一个请求链中，当某DNS服务器接收一个DNS回答时，它能将映射缓存在本地存储器中。如果在DNS服务器中缓存了一台主机名/IP地址对，另一个对相同主机名的查询到达该DNS服务器时，该DNS服务器就能够提供所要求的IP地址，即使它不是该主机名的权威服务器。由于主机和主机名与IP地址间的 映射并不是永久的，DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息。事实上，因为缓存，除了少数DNS查询以外，根服务器被绕过了。

35.DNS记录和报文

共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(RR), RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。

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

(Name, Valuer, Type,TTL)

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

•如果Type = A,则Name是主机名，Value是该主机名对应的IP地址。一条类型为A的资源记录提供了标准的主机名到IP地址的映射。

•如果Type = NS,则Name是个域,而Value是个知道如何获得该域中主机IP地址的权威DNS服务器的主机名。这个记录用于沿着查询链来路由DNS查询。

•如果Type=CNAME，则 Value是别名为Name的主机对应的规范主机名。该记录 能够向査询的主机提供一个主机名对应的规范主机名。

•如果Type = MX,则Value是个别名为Name的邮件服务器的规范主机名。MX记录允许邮件服务器主机名具有简单的别名。通过使用MX记录，一个公司的邮件服务器和其他服务器可以使用相同的别名。为了获得邮件服务器的规范主机名，DNS客户应当请求一条MX记录；而为了获得其他服务 器的规范主机名，DNS客户应当请求CNAME记录。

如果一台DNS服务器是用于某特定主机名的权威DNS服务器，那么该DNS服务器会有一条包含用于该主机名的类型A记录(即使该DNS服务器不是其权威DNS服务器，它也可能在缓存中包含有一条类型A记录)。如果服务器不是用于某主机名的权威服务器,那么该服务器将包含一条类型NS记录，该记录对应于包含主机名的域；它还将包括一条 类型A记录，该记录提供了在NS记录的Value字段中的DNS服务器的IP地址

36.DNS报文

DNS只有这两种报文：DNS查询和回答报文并且，查询和回答报文有着相同的格式DNS报文中各字段的语义如下：

•前12个字节是首部区域，其中有几个字段。第一个字段（标识符）是一个16比特的数，用于标识该查询。这个标识符会被复制到对查询的回答报文中，以便让客户用它来匹配发送的请求和接收到的回答。 标志字段中含有若干标志。1比特的“查询/回答”标志位指出报文是查询报文 （0）还是回答报文（1）

•问题区域包含着正在进行的查询信息。该区域包括：①名字字段，包含正在被查询 的主机名字；②类型字段，指出有关该名字的正被询问的问题类型，

•在来自DNS服务器的回答中，回答区域包含了对最初请求的名字的资源记录。每个资源记录中有Type （如A、NS、CNAME和MX）字段、Value字段和TTL字段。在回答报文的回答区域中可以包含多条RR,因此一个主机名能够有多个IP地址。

•权威区域包含了其他权威服务器的记录。

•附加区域包含了其他有帮助的记录。该附加区域包含一个类型A记录，该记录提供了用于该邮件服务器的规范主机名的IP地址。

从正在工作的主机直接向某些DNS服务器发送一个DNS查询报文使用nslookup程序能够容易地做到这一点，这对于多数Windows和UNIX平台，nslookup程序是可用的。在调用nslookup后，你能够向任何DNS服务器（根、TLD或权威）发送DNS查询。在接收到来自DNS服务器的回答后，nslookup将显示 包括在该回答中的记录。

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

验证该域名的唯一性，将该域名输入DNS数据库，对提供的服务收取少量费用。1999年前，唯一的注册登记机构是Nework Solution,它独家经营对于com. net和org域名的注册。但是现在有许多注册登记机构竞争客户，因特网名字和地址分配机构（ICANN）向各种注册登记机构授权。

当你向某些注册登记机构注册域名networkutopia, com时，需要向该机构提供你的基本和辅助权威DNS服务器的名字和IP地址。一旦完成所有这些步骤，人们将能够访问你的Web站点，并向你公司的雇员发送电子邮件。

38.DNS脆弱性

想到的第一种针对DNS服务的攻击是分布式拒绝服务（DDoS）带宽洪泛攻击。

1某攻击者能够试图向每个DNS根服务器发送大量的分组，使得大多数合法DNS请求得不到回答。这种对DNS根服务器的DDoS大规模攻击实际发生在2002年10月21日。幸运的是，这种大规模攻击对用户的因特网体验几乎没有或根本没有影响。攻击者的确成功地将大量的分组指向了根服务器，1但许多DNS根服务器受到了分组过滤器的保护，配置的分组过滤器阻挡了报文。2大多数本地DNS服务器缓存了顶级域名服务器的IP地址，使得这些请求过程通常绕过了 DNS根服务器

对DNS的潜在更为有效的DDoS攻击将是向顶级域名服务器发送大量的DNS请求。过滤指向DNS服务器的DNS请求将更为 困难，并且顶级域名服务器不像根服务器那样容易绕过。但是这种攻击的严重性通过本地DNS服务器中的缓存技术可将部分地被缓解。DNS能够潜在地以其他方式被攻击。在中间人攻击中，攻击者截获来自主机的请求并返回伪造的回答。

在DNS毒害攻击中，攻击者向一台DNS服务器发送伪造的回答, 诱使服务器在它的缓存中接收伪造的记录。这些攻击中的任一种，都能够将毫无疑虑的Web用户重定向到攻击者的Web站点。这些攻击难以实现，因为它们要求截获 分组或扼制住服务器。

DNS自身已经显示了对抗攻击的令人惊讶的健壮性。至今为止，还没有一个攻击已经成功地妨碍了 DNS服务.

39.P2P文件分发

客户-服务器体系结构极大地依赖于总是打开的基础设施服务器。P2P体系结构，对总是打开的基础设施服务器有最小的（或者没有）依赖。这些对等方并不为服务提供商所拥有，而是受用户控制的桌面计算机和膝上计算机。

一个非常自然的P2P应用从单一服务器向大量主机（称为对等方）分发一个大文件。在客户-服务 器文件分发中，该服务器必须向每个对等方发送该文件的一个副本，即服务器承受了极大的负担，并且消耗了大量的服务器带宽。在P2P文件分发中，每个对等方能够向任何其他对等方重新分发它已经收到的该文件的任何部分，从而在分发过程中协助该服务器。

最为流行的P2P文件分发协议是BitTorrento，该应用程序现在有许多不同的独立且符合BitTorrent协议的BitTorrent客户，就像有许多符合HTTP协议的Web浏览器客户一样。

40.P2P体系结构的扩展性

P2P的内在自扩展性, 将一个文件分发给一个固定对等方集合。服务器和对等方使用接入链路与因特网相连。当一个对等方接收到某些文件数据，它能够使用自己的上载能力重新将数据分发给其他对等方。

具有P2P体系结构的应用程序能够 是自扩展的。这种扩展性的直接成因是: 对等方除了是比特的消费者外还是它们的重新分发者。

41.BitTorrent

BitToiTent是一种用于文件分发的流行P2P协议。参与一个特定文件分发的所有对等方的集合被称为一个洪流。在一个洪流中的对等方彼此下载等长度的文件块，典型的块长度为256KB。当一个对等方首次加入一个洪流时，它没有块。随着时间的流逝，它累积了越来越多的块。当它下载块时，也为其他对等方上载了多个块。一旦某对等方获得了整个文件，它也许（自私地）离开洪流，或（大公无私地）留在该洪流中并继续向其他对等方上载块。同时，任何对等方 可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中。

BitTorrent是一个相当复杂的协议，仅描述它最重要的机制，每个洪流具有一个基础设施节点，称为追踪器（tracker）。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟踪参与在洪流中的对等方。一个给定的洪流可能在任何时刻具有数以千计的对等方。

在任何给定的时间，每个对等方将具有来自该文件的块的子集，并且不同的对等方具 有不同的子集。在决定请求哪些块的过程中，最稀缺优先的技术：这种技术的思路是，针对她没有的块在她的邻居中决定 最稀缺的块（最稀缺的块就是那些在她的邻居中副本数量最少的块），并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是（大致地）均衡每个块在洪流中的副本数量。

为了决定她响应哪个请求，BitTorrent使用了一种机灵的对换算法。其基本想法是,Alice根据当前能够以最高速率向她提供数据的邻居，给出其优先权。特别是，Alice对于 她的每个邻居都持续地测量接收到比特的速率，并确定以最高速率流入的4个邻居。每过10秒，她重新计算该速率并可能修改这4个对等方的集合。用BitTorrent术语来说，这4 个对等方被称为疏通。重要的是，每过30秒，她也要随机地选择另外一个邻居并向其发送块。我们将这个被随机选择的对等方称为Bob。每过30秒Alice将随机地选择一名新的对换伴侣并开始与那位伴侣进行对换。如果这两名对等方都满足此对换，它们将对方放入其前4位列表中并继续与对方进行对换，直到该对 等方之一发现了一个更好的伴侣为止。这种效果是对等方能够以趋向于找到彼此的协调的速率上载。

BitTorrent有一些有趣的机制没有在这里讨论, 包括片（小块）、流水线、随机优先选择、残局模型和反怠慢 。刚刚描述的关于交换的激励机制常被称为“一报还一报”，无论如何,BitTorrent “生态系统”取得了广泛成功，数以百万计的并发对等方在数十万条洪流中积极地共享文件。

我们简要地提下分布式散列表（DHT）。分布式散列表是一种简单的数据库，其数据库记录分布在一个P2P系统的多个对等方上。DHT得到了广泛实现，并成为大量研究的主题。

42.视频流和内容分发网

使用应用层协议和以像高速缓存那样方式运行的服务器。

因特网视频在流式存储视频应用中，基础的媒体是预先录制的视频，这些预先录制好的视频放置在服务器上，用户按需向这些服务器发送请求来观看视频。许多因特网公司现在提供流式视频。

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

从网络的观点看，也许视频最为突出的特征是它的高比特率。压缩的因特网视频的比特率范围从100kbps到超过3Mbps再到用于4K流式展望的超过10Mbps。对流式视频的最为重要的性能度量是平均端到端吞吐量。为了提供连续不断的布局，网络必须为流式应用提供平均吞吐量，这个流式应用至少与压缩视频的比特率一样大。 我们也能使用压缩生成相同视频的多个版本，每个版本有不同的质量等级。根据当前可用带宽来决定观看哪个版本。

43.HTTP流和DASH

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

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

DASH允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频。如果端到端带宽在会话过程中改变的话，DASH允许客户适应可用带宽。这种特色对于移动用户特别重要，当移动用户相对于基站移动时，通常他们能感受到其可用带宽的波动。

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

44.内容分发网

向位于全世界的所有用户流式传输所有流量同时提供连续播放和高交互性显然是一项有挑战性的任务。 或许提供流式视频服务最为直接的方法是建立单一的大规模数据中心，在数据中心中存储其所有视频，并直接从该数据中心向世界范围的客户传输流式视频。但是这种方法存在三个问题

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

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

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

几乎所有主要的视频流公司都利用内容分发网（CDN）。 CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。1CDN可以是专用CDN ,即它由内容提供商自己所拥有；2CDN可以是第三方CDN ,它代表多个内容提供商分发内容

45.谷歌的网络基础设施

为了支持谷歌的巨量云服务阵列，谷歌已经部署了一个广泛的专用网和CDN基础设施。谷歌的CDN基础设施具有三个等级的服务器集群：

• 14个“百万数据中心”，每个数据中心具有10万台量级的服务器。这些“百万数据中心”负责服务于动态的（并且经常是个性化的）内容.

•在IXP中大约50个集群分布于全球，其中每个集群由100-500台服务器组成

•数以百计的“深入 集群位于一个接入ISP中。这里一个集群由位于一个机架上的数十台服务器组成。这些“深入服务器”执行TCP分岔并服务于静态内容。

所有这些数据中心和集群位置与谷歌自己的专用网连接在一起。当某用户进行搜索 请求时，该请求常常先经过本地ISP发送到邻近的“深入服务器”缓存中，从这里检索 静态内容；同时将该静态内容提供给客户，邻近的缓存也经谷歌的专用网将请求转发给 “大型数据中心”，从这里检索个性化的搜索结果。谷歌云服务在很大程度上是由独立于公共因特网的网络基础设施提供的。

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

•深入。该原则是通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。其目标是靠近端用户，通过减少端用户和CDN集群之间链路和路由器的数量，从而改善了用户感受的时延和吞吐量。因为高度分布式设计，维护和管理集群的任务成为挑战。

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

一旦CDN的集群准备就绪，它就可以跨集群复制内容。CDN可能不希望将每个视频的副本放置在每个集群中，因为某些视频很少观看或仅在某些国家中流行。许多CDN使用一种简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频，向客户流式传输视频时的同时在本地存储一个副本。当 某集群存储器变满时，它删除不经常请求的视频。

47.CDN操作

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

48.集群选择策略

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

一种简单的策略是指派客户到地理上最为邻近的集群。使用商用地理位置数据库,每个LDNS IP地址都映射到一个地理位置。当从一个特殊的LDNS接收到一个DNS请求时,CDN选择地理上最为接近的集群，即离LDNS最少几千米远的集群。

这样的解决方案对于众多用户来说能够工作得相当好。

1 就网络路径的长度或跳数而言，地理最邻近的集群可能并不是最近的集群。

2 某些端用户配置使用位于远地的LDNS ,在这种情况下，LDNS位置可能远离客户的位置。

3 这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化,总是为特定的客户指派相同的集群。

为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量.

CDN能够让它的每个集群周期性地向位于全世界的所有LDNS发送探测分组。这种方法的一个缺点是许多LDNS被配置为不会响应这些探测。

49.学习案例：Netflix、YouTube 和 “看看”

1. Netflix

视频分发具有两个主要部件：亚马逊云和它自己的专用CDN基础设施。

Netflix有一个Web网站来处理包括用户注册和登录、计费、用于 浏览和搜索的电影目录以及一个电影推荐系统。这个Web网站完全运行在亚马逊云中的亚马逊服务器上。此外，亚马逊云处理下列关键功能:

•内容摄取。

•内容处理。

•向其CDN上载版本。

Netflix创建了自己专用的CDN,现在它从这些专用CDN发送它所有的视频。（Netflix仍使用Akamai来分发它的Web网页。）为了创建它自 己的CDN, Netflix在IXP和它们自己的住宅ISP中安装了服务器机架。在机架中每台服务器具有几个lOGbps以太网端口和超过100TB的存储。在一个机架中服务器的数量是变化的:IXP安装通常有数十台服务器并包含整个Netflix流式视频库（包括多个版本的视频以支持DASH）；

Netflix在非高峰时段通过推将这些视频分发给它的CDN服务器。浏览Netflix视频库的Web网页由亚马逊云中的服务器提供服务。一旦Netflix确定了交付内容的CDN服务器，它向该客户发送特定服务器的IP地址以 及资源配置文件，该文件具有所请求电影的不同版本的URL。该客户和那台CDN服务器则使用专用版本的DASH进行交互。该客户使用HTTP GET请求报文中的字节范围首部，以请求来自电影的不同版本的块。Netflix使用大约4秒长的块。随着这些块的下载，客户测量收到的吞吐量并且运行一个速率确定算法来确定下一个要请求块的质量。

Neftlix包含了适应性流和CDN分发。Netflix已经能够简化并定制其CDN设计。Netflix软件（运行在亚马逊云中）直接告知该客户使用一台特定的CDN服务器。此外，Netflix CDN使用推高速缓存。内容在非高峰时段的预定时间被推入服务器，而不是在高速缓存未命中时动态地被推入。

2. YouTube

YouTube于2006年11月被谷歌公司收购。YouTube广泛地利用CDN技术来分发它的视频,谷歌使用其专用CDN来分发YouTube视频，并且已经在几百个不同的IXP和ISP位置安装了服务器集群。从这些位置以及从它的巨大数据中心，谷歌分发YouTube视频。谷歌使用拉高速缓存和DNS重定向。在大部分时间，谷歌的集群选择策略将客户定向到某个集群，使得客户与集群之间的RTT是最低的。然而，为了平衡流经集群的负载，有时客户被定向（经DNS）到一个更远的集群。

YouTube应用HTTP流，经常使少量的不同版本为一个视频可用，每个具有不同的比特率和对应的质量等级。YouTube没有应用适应性流（例如DASH）,而要求用户人工选择一个版本。为了节省那些将被重定位或提前终止而浪费的带宽和服务器资源，YouTube在获取视频的目标量之后，使用HTTP字节范围请求来限制传输的数据流。

YouTube处理它收到的每个视频，将它转换为YouTube视频格式并且创建具有不同比特率的多个 版本。这种处理完全发生在谷歌数据中心。

​ 3.看看

Netflix和YouTube这些服务的规模和它们消耗的带宽量，这种CDN部署的代价可能是很高的。

看看经因特网大规模地按需提供视频，这是一种允许服务提供商极大地减少其基础设施和带宽成本的方法。这种方法使用P2P交付。

从高层面看，P2P流式视频非常类似于BitTorrent文件下载。当一个对等方要看一 个视频时，它联系一个跟踪器，以发现在系统中具有该视频副本的其他对等方。这个请求的对等方则并行地从具有该文件的其他对等方请求该视频的块。

不同于使用BitTorrent下载，请求被优先地给予那些即将播放的块，以确保连续播放。看看近期已经向混合CDN-P2P流式系统迁移。特别是，看看目前在中国部署了数以百计的服务器并且将视频内容推向这些服务器。在大多数场合，客户请求来自CDN服务器的内容的开头部分,并且并行地从对等方请求内容。当P2P总流量满足视频播放时，该客户将从CDN停止流并仅从对等方获得流。但如果P2P流的流量不充分，该客户重新启动CDN连接并且返回到混合CDN-P2P流模式。以这种方式，看看能够确保短启动时延，与此同时最小地依赖成本高的基础设施服务器和带宽。

50.套接字编程：生成网络应用

网络应用是由一对程序（即客户程序和服务器程序）组成的, 它们位于两个不同的端系统中。当运行这两个程序时，创建了一个客户进程和一个服务器进程，同时它们通过从套接字读出和写入数据在彼此之间进行通信。

网络应用程序有两类。

一类是由协议标准中所定义的操作的实现；这样的应用程序有时称为“开放”的，因为定义其操作的这些规则为人们所共知。这样的实现客户程序和服务器程序必须遵守由该RFC所规定的规则。完全遵从RFC能够交互 。

另一类网络应用程序是专用的网络应用程序。在这种情况下，由客户和服务器程序应用的应用层协议没有公开发布在某RFC中或其他地方。某单独的开发者（或开发团队） 产生了客户和服务器程序，并且该开发者用他的代码完全控制该代码的功能。没有开放不能交互。

TCP是面向连接的，并且为两个端系统之间的数据流动提供可靠的字节流通道。UDP是无连接的，从一个端系统向另一个端系统发送独立的数据分组，不对交付提供任何保证。前面也讲过当客户或服务器程序实现了一个由某RFC定义的协议时，它应当使用与该协议关联的周知端口号；与之相反，当研发一个专用应用程序时，研发者必须注意避免使用这些周知端口号。

用Python 3，Java、C或 C ++来呈现这些简单的TCP和UDP程序。

60.UDP套接字编程

每个进程好比是一座房子，该进程的套接字则好比是一扇门。应用程序位于房子中门 的一侧；运输层位于该门朝外的另一侧。应用程序开发者在套接字的应用层一侧可以控制所有东西；它几乎无法控制运输层一侧。

在发送进程能够将数据分组推出套接字之门之前，当使用UDP时，必须先将目的地址附在该分组之上。在该分组传过发送方的套接字之后，因特网将使用该目的地址通过因特网为该分组选路到接收进程的套接字。当分组到达接收套接字时，接收进程将通过该套接字取回分组，然后检查分组的内容并采取适当的动作。

主机的IP地址是目的地址的一部分。通过在分组中包括目的地的IP地址，因特网中的路由器将能够通过因特网将分组选路到目的主机。但是因为一台主机可能运行许多网络应用进程，每个进程具有一个或多个套接字，所以在目的主机指定特定的套接字也是必要的。当生成一个套接字时，就为它分配一个称为端口号的标识符。因此,

发送进程为分组附上目的地址，该目的地址是由目的主机的IP地址和目的地套接字的端口号组成的，源地址也要附在分组之上，由底层操作系统自动完成的。

70.TCP套接字编程

TCP是一个面向连接的协议。这意味着在客户和服务器能够开始互相发送数据之前，它们先要握手和创建一个TCP连接。TCP连接的一端与客户套接字相联系，另一端与服务器套接字相联系。当创建该TCP连接时，我们将其与客户套接字地址（ IP地址和端口号）和服务器套接字地址（IP地址和端口号）关联起来。使用创建的TCP连接，当一侧要向另一侧发送数据时，它只需经过其套接字将数据丢进TCP连接。

服务器必须已经准备好。

第一，与在UDP中的情况一样，TCP服务器在客户试图发起接触前必须作为进程运行起来。

第二，服务器程序必须具有一扇特殊的门，更精确地说是一个特殊的套接字，该门欢迎来自运行在任意主机上的客户进程的某种初始接触。

生成其套接字后，客户发起了一个三次握手并创建与服务器的一个TCP连接。发生在运输层的三次握手，对于客户和服务器程序是完全透明的。

在三次握手期间，客户进程敲服务器进程的欢迎之门。当该服务器“听”到敲门声 时，它将生成一个新套接字，它专门用于特定的客户。

专门对客户进行连接的新生成的套接字，称为连接套接字。客户套接字和服务器连接套接字直接通过一根管道连接。客户进程可以向它的套接字按发送的顺序接收发送任意字节。

期待自己第345678章的内容笔记呜呜，计网要努力┭┮﹏┭┮