计算机网络（自顶向下）第二章总结

计算机网络

第二章：应用层

2.1 应用层协议原理

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

重要的是，你不需要写在网络核心设备如路由器或链路层交换机上运行的软件。网**络核心设备并不在应用层上起作用，而仅较低层起作用，特别是在网络层及下面层次起作用。**这种基本设计，即将应用软件限制在端系统（如图所示）的方法，促进了大量的网络应用程序的迅速研发和部署。

2.1.1 网络应用程序体系结构

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

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

• 客户-服务器体系结构

  • 有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。当Web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应。值得注意的是利用客户-服务器体系结构，客户相互之间不直接通信；
  • 该服务器具有固定的、周知的地址，该地址称为IP地址。客户总是能够通过向该服务器的IP地址发送分组来与其联系。
  • 具有客户-服务器体系结构的非常著名的应用程序包括Web、FTP、Telnet和电子邮件。
  • 一个流行的社交网络站点如果仅有一台服务器来处理所有请求，将很快变得不堪重负。为此，配备大量主机的数据中心（data center）常被用于创建强大的虚拟服务器。

• P2P体系结构

  • **对位于数据中心的专用服务器有最小的 （或者没有）依赖。**应用程序在间断连接的主机对之间使用直接通信，这些主机对

    被称为对等方。这些对等方并不为服务提供商所有，因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。

  • 目前流行的、流量密集型应用都是P2P体系结构的。这些应用包括文件共享（例如BitTorrent） x对等方协助下载加速器（例如迅

    雷）、因特网电话和视频会议（例如Skype）。

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

  • P2P体系结构也是有成本效率的, 因为它们通常不需要庞大的服务器基础设施和服务器带宽。

  • 面临的问题：

    • ISP友好。大多数住宅ISP受制于非对称带宽应用，也就是下载比上传要多得多。但是P2P视频和文件分发应用改变了从服务器到住宅ISP的上载流量，因而给ISP带来压力；
    • 安全性。因为其高度的分布和开放式，P2P应用也可能给安全带来挑战；
    • 激励。如何说服用户资源向应用提供带宽、存储和计算资源？这是一个问题；

  

2.1.2 进程通信

操作系统中，进行通信的实际上是进程（process）而不是程序。

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

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

• 客户和服务器进程

  • 网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。我们通常将这两个进程之一标识为客户（client）,而另一个进程标识为服务器（server）。对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方标识为服务器。
  • 在一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。

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

  • 进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。更为准确的说，套接字是同一台主机内应用层和运输层之间的接口。

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

    控制权。应用程序开发者对于运输层的控制仅限于 ①选择运输层协议；②也许能设定几个运输层参数。

    

• 进程寻址

  • 在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了标识该接收进程，需要定义两种信息 ①主机的地址；②在目的主机中指定接收进程的标识符。
  • 在因特网中，主机由其IP地址(IP address)标识。IP地址是一个32比特的量且它能够唯一地标识该主机。而接收进程（或者说是其对应的套接字）使用端口号标记。一些常用的应用程序有着固定的端口号，比如Web服务器使用80端口、邮件服务器（运行SMTP协议）使用25端口等。

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

一个运输层协议能够为调用它的应用程序提供什么样的服务呢？我们大体能够从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。

• 可靠数据传输
  • 确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。
  • 当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用(loss-tolerant application)所接受。
• 吞吐量
  • 可用吞吐量就是发送进程能够向接收进程交付比特的速率。因为其他会话将共享沿着该网络路径的带宽，并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动。这就导致另一种自然的服务，即运输层协议能够提供确切的可用吞吐量。使用这种服务时，应用程序就能以明确的速度接收数据，并且运输层应当保证可用吞吐量必须总是至少为该速度。
  • 具有吞吐量要求的应用程序被称为带宽敏感的应用 （bandwidth-sensitive application）。带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic application） 能够根据当时可用的带宽或多或少地利用可供使用的吞吐量。
• 定时
  • 运输层协议也能提供定时保证。如同具有吞吐量保证那样，定时保证能够以多种形式实现。一个保证的例子如 发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。如因特网电话、虚拟环境、电话会议和多方游戏，所有这些服务为了有效性而要求数据交付有严格的时间限制。
• 安全性
  • 运输层可以提供一些安全服务，以防止传输的数据以某种方式在这两个进程之间被察觉到。这些安全服务包括：数据的加解密、数据的完整性和端点鉴别等。

2.1.4 因特网提供的传输层服务

因特网（更一般的是TCP/IP网络）为应用程序提供两个运输层协议，即UDP和TCP。当你（作为一个软件开发者）为因特网创建一个新的

应用时，首先要做出的决定是，选择UDP还是选择TCP。每个协议为调用它们的应用程序提供了不同的服务集合。

• TCP服务

  • 面向连接的服务：在应用层数据报文开始流动之前，TCP让客户和服务器互相交换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组的到来做好准备。在握手阶段后，一个TCP连接（TCP connection）就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。
  • 可靠的数据传送服务：通信进程能够依靠TCP,无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。
  • TCP协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为 因特网带来整体好处。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程（客户或服务器）。
  • TCP安全：无论TCP还是UDP都没有提供任何加密机制，这就是说发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同。因为隐私和其他安全问题对许多应用而言已经成为至关重要的问题，所以因特网界已经研制了 TCP的加强版本，称为安全套接字层（Secure Sockets Layer, SSL）。

• UDP服务

  • UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。
  • UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层 （网络层）注入数据。（然而，值得注意的是实际端到端吞吐量可能小于该速率，这可能是因为中间链路的带宽受限或因为拥塞而造成的。）

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

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

  

2.1.5 应用层协议

应用层协议（application-layer protocol ）定义了运行在不同端系统上的应用程序进程如何相互传递报文。

• 特别是应用层协议定义了：
  • 交换的报文类型，例如请求报文和响应报文。
  • 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
  • 字段的语义，即这些字段中的信息的含义。
  • 确定一个进程何时以及如何发送报文，对报文进行响应的规则。
• 有些应用层协议是由RFC文档定义的，因此它们位于公共域中。例如，Web的应用层协议HTTP就作为一个RFC可供使用。如果浏览器开发者遵从HTTP RFC规则，所开发出的浏览器就能访问任何遵从该文档标准的Web服务器并获取相应Web页面。还有很多别的应用层协议是专用的，有意不为公共域使用。例如,Skype使用了专用的应用层协议。
• 应用层协议只是网络应用的一部分。

2.2 Web 和 HTTP

20世纪90年代初期，一个主要的新型应用即万维网（WorldWideWeb）登上了舞台也许对大多数用户来说，最具有吸引力的就是Web的按需操作。当用户需要时，就 能得到所想要的内容。这不同于无线电广播和电视，它们迫使用户只能收听、收看内容提供者提供的节目。

2.1.1 HTTP 概况

• Web的应用层协议是超文本传输协议（HyperText Transfer Protocol, HTTP）,它是Web的核心。HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。

• Web页面（Webpage）也叫文档是由对象组成的。一个对象（object）只是一个文件，它们通过一个URL地址进行寻址。客户和服务器交互的核心思想是客户通过HTTP请求对服务器发出对Web页面的请求报文，服务器收到该报文后将返回包含该对象的HTTP响应报文。URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

• HTTP定义了Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。

• HTTP使用TCP作为它的支撑运输协议(而不是在UDP上运行)。HTTP客户首先发起一个与服务器的TCP连接，需要注意的是，服务器根据请求作出响应，但是不存储任何关于该客户的状态信息。也正因为这样，HTTP被称为无状态协议。同时，Web使用了客户端-服务器的应用体系结构。其中web服务器总是开着的。

  

2.2.2 非持续连接和持续连接

客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。当这种客 户-服务器的交互是经TCP进行的，应用程序的研制者就需要做一个重要决定，即每个请求/响应对是经一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送呢？采用前一种方法，该应用程序被称为使用非持续连接(non-persistent connection)；采用后一种方法，该应用程序被称为使用持续连接(persistent connection)。

• 采用非持续连接的HTTP

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

• 采用持续连接的HTTP

  • 从上面可以看出，非持续连接必须为每个请求新建一个TCP连接，而每个TCP连接将占用系统资源，包括缓冲区和变量等，这样服务器的负担就很重了。第二，一个对象将通过两个RTT的时延才能交付。
  • 如果使用持续连接，那么服务器在发送响应报文后将保持该TCP打开，后续客户端可以使用该连接来向服务器发出请求。不但一个完整的页面可以通过同一个连接传送，同一台服务器上的多个页面也可以通过同一个连接发送。这就提高了效率。
  • 一般来说，如果一条连接在一定的时间间隔后没被使用的话，就会被关闭。HTTP默认使用的是带流水线的持续连接。

  

2.2.3 HTTP报文格式

• HTTP请求报文

  • 一般报文：

  

  • HTTP请求报文的第一行叫作请求行（request line）,其后继的行叫作首部行（header line）。

  • 请求行有3个字段方法字段、URL字段和HTTP版本字段。

  • 方法字段可以取几种：GET、POST、HEAD、PUT和DELETE。

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

  • 首部行：

    • 首部行Host： www. someschool. edu指明了对象所在的主机。
    • User-agent:首部行用来指明用户代理，即向服务器发送请求的浏览器的类型。
    • Accept-language：首部行表示用户想得到该对象的法语版本。

  • 通用格式：

    

    • 实体体：使用GET方法时实体体为空，而使用POST方法时才使用该实体体。当用户提交表单时，HTTP客户常常使用POST方法，实体体中包含的就是用户在表单字段中的输入值。

• HTTP响应报文

  • 一般报文：

    

  • 它有三个部分 一个初始状态行（status line） , 6个首部行（headerline）,然后是实体体（entity body）。实体体部分是报文的主要部分，即它包含了所请求的对象本身（表示为data data data data data -）。

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

  • 这里的Date是从文件系统中检索到该对象，插入到响应报文，并发送该响应报文的时间。

  • 通用格式：

    

  • 状态码相关信息：

    • 200 0K：请求成功，信息在返回的响应报文中。
    • 301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应报文的Location:首部行中。客户软件将自动获取新的URL。
    • 400 Bad Request: 一个通用差错代码，指示该请求不能被服务器理解。
    • 404 Not Found:被请求的文档不在服务器上。
    • 505 HTTP Version Not Supported:服务器不支持请求报文使用的HTTP协议版本。

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

前面提到，HTTP是无状态协议，但是Web站点为了识别用户身份或者限制用户访问的时间或者将用户访问的内容同用户身份相关联，Web站点可以使用Cookie技术；

• cookie技术有4个组件：

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

  

• 当客户第一次访问一个Web服务器，请求报文到达服务器时，该Web站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。接下来Web服务器用一个包含Set-cookie：首部的HTTP响应报文对客户的浏览器进行响应，其中Set-cookie：首部含有该识别码。如：

  

  当客户的浏览器收到了该HTTP响应报文时，它会看到该Set-cookie：首部。该浏览器在它管理的特定cookie文件中添加一行，该行包含服务器的主机名和在Set-cookie:首部中的识别码。当客户继续浏览网站时，每请求一个Web页面，其浏览器就会查询该cookie文件并抽取她对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。

  

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

2.2.5 Web 缓存

• Web缓存器（Web cache）也叫代理服务器（ proxy server）,它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间,并在存储空间中保存最近请求过的对象的副本。

• 可以配置用户的浏览器，使得用户的所有HTTP请求首先指向Web缓存器。

• 当代理服务器收到一个HTTP请求后，它将检查本地是否缓存过该对象，如果缓存过该对象，将检查是否过期，如果没有过期，则直接将该对象返回给浏览器；如果本地不存在或者存在已过期，则代理服务器将根据请求报文里的Host首部行以及请求行里的URL字段向初始服务器发出请求，然后将响应对象返回给浏览器并缓存在本地。

• Web缓存器既是服务器又是客户。

• 通常，代理服务器与客户端的通信速度要快于初始服务器与客户端的连接速度。Web代理服务器可以大起大减少对客户请求的响应时间。而且，缓存器能从整体上大大降低因特网上的web流量，从而有助于提高所有应用程序的性能。

• 通过使用内容分发网络（Content Distribution Network），Web缓存器正在因特网中发挥越来越重要的作用。

  

2.2.6 条件GET方法

• 保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。HTTP协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是条件GET （conditional GET）方法。

  • 请求报文使用GET方法。
  • 请求报文中包含一个“ If Modified-Since ”首部行。

• 缓存器在将对象转发到请求的浏览器的同时，也在本地缓存了该对象。重要的是, 缓存器在存储该对象时也存储了最后修改日期。在过了一段时间后，如果有用户再来访问该对象，由于对象可能更新了，该缓存器通过发送一个条件GET执行最新检查。

  

  值得注意的是If Modified-Since：首部行的值正好等于缓存前服务器发送的响应报文中的Last-Modified:首部行的值。该条件GET报文告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。否则服务器将返回一个包含空实体体的报文。

  

  状态行中为304 Not Modified,它告诉缓存器可以使用该对象，能向请求的浏览器转发它（该代理缓存器）缓存的该对象副本。

2.3 因特网中的电子邮件

• 电子邮件是一种异步通信媒介，即当人们方便时就可以收发邮件,不必与他人的计划进行协调。

• 有3个主要组成部分用户代理（ user agent）、邮件服务器（mail server）和简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）。

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

• 过程：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。当Bob要在他的邮箱中读取该报文时，包含他邮箱的邮件服务器（使用用户名和口令）来鉴别Bob。Alice的邮箱也必须能处理Bob的邮件服务器的故障。如果Alice的服务器不能将邮件交付给Bob的服务器,Alice的邮件服务器在一个报文队列（message queue ）中保持该报文并在以后尝试再次发送。

  

2.3.1 SMTP

• 传输的三个阶段：握手、传输、关闭连接。

• SMTP用于从发送方的邮件服务器发送报文到接收方的邮件服务器。它限制所有邮件报文的体部分（不只是其首部）只能采用简单的7比特ASCII表示。SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。
• 客户SMTP 运行在发送邮件服务器主机上在25号端口建立一个到服务器SMTP （运行在接收邮件服务器主机上）的TCP连接。如果服务器没有开机，客户会在稍后继续尝试连接。一旦连接建立，服务器和客户执行某些应用层的握手。在SMTP握手的阶段，SMTP客户指示发送方的邮件地址（产生报文的那个人） 和接收方的邮件地址。一旦该SMTP客户和服务器彼此介绍之后，客户发送该报文。SMTP能依赖TCP提供的可靠数据传输无差错地将邮件投递到接收服务器。该客户如果有另外的报文要发送到该服务器，就在该相同的TCP连接上重复这种处理；否则,它指示TCP关闭连接。

2.3.2 与HTTP的对比

• HTTP从Web服务器向Web客户（通常是一个浏览器）传送文件（也称为对象）。SMTP从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）。当进行文件传送时，持续的HTTP和SMTP都使用持续连接。
• 第一个区别HTTP被设计为一个推协议（pull protocol）而SMTP被设计为一个拉协议（push protocol）。即用户通过HTTP主动向服务器请求内容，而SMTP则是客户将内容推向服务器端。
• 第二个区别就是HTTP传输的数据不一定是用ASCII字符，但是SMTP则只能使用ASCII字符。
• 第三个重要区别就是，HTTP将每个对象封装在自己的响应报文里，而SMTP则将所有的报文对象放到一个报文之中。

2.3.3 邮件报文格式

• 报文由两部分组成：一个包含环境信息的首部和一个包含邮件内容的报文体。首部和报文体之间使用空行分开；首部行的格式为关键字：及其值；每个首部必须包含一个From和To首部行。首部也可以包含其它信息，比如Subject等。这与2.4.1中接触的SMTP命令不同，那节中的命令是握手协议的一部分；本节中研究的内容是邮件报文自身的一部分。

  

2.3.4 邮件访问协议

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

• POP3
  • POP3是一个极为简单的邮件访问协议。因为该协议非常简单，故其功能相当有限。当用户代理（客户）打开了一个到邮件服务器（服务器）端口 110上的TCP连接后，POP3就开始工作了。POP3按照三个阶段进行工作特许（authorization）、事务处理以及更新。
    • 特许阶段：用户代理发送（以明文形式）用户名和口令以鉴别用户。
    • 事务处理阶段：用户代理取回报文。同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。
    • 更新阶段：它出现在客户发出了 quit命令之后，目的是结束该POP3会话；这时，该邮件服务器删除那些被标记为删除的报文。
  • POP3用户代理可以使用两种事务处理模式：一种是下载并删除，另一种是下载并保留；POP3代理发出的命令和其工作模式相关；下载并删除的方法存在的问题是，如果用户在一台设备上查看了邮件（下载了邮件）后，邮件将被删除，那么在其他设备上将无法查看邮件；这给用户带来一定的不便。使用下载并保存方式，则用户下载邮件后，邮件还在服务器上。
  • 在用户代理与邮箱服务器之间的POP3会话期间，该POP3服务器保留了一些状态信息，特别是标记了哪些用户报文被标记为删除了。但是POP3服务器并不在POP3绘画过程中携带状态信息，大大简化了POP3的服务。
• IMAP
  • IMAP服务器把每个报文与一个文件夹联系起来；当报文第一次到达服务器时，它 与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。
  • 与POP3不同，IMAP服务器维护了 IMAP会话的用户状态信息。
  • IMAP协议还允许用户代理获取报文组件而不是报文整体。
• 基于Web的电子邮件
  • 这种方式主要是指，用户使用HTTP协议和邮件服务器通信。用户代理就是普通的浏览器，但是，邮件服务器之间还是使用SMTP协议的。

2.4 DNS**：**因特网的目录服务

因特网上的主机和人类一样，可以使用多种方式进行标识。主机的一种标识方法是用 它的主机名 （hostname ），如 www. facebook, com、www. google, com等，这些名字便于记忆也乐于被人们接受。然而，主机名几乎没有提供 （即使有也很少）关于主机在因特网中位置的信息。主机也可以使用所谓IP地址（IP address）进行标识。 IP地址具有层次结构，是因为当我们从左至右扫描它时，我们会得到越来越具体的关于主机位于因特网何处的信息（即在众多网络的哪个网络里）。

2.4.1 DNS提供的服务

• 识别主机有两种方式，通过主机名或者IP地址。我们需要一种能进行主机名到IP地址转换的目录服务。这就是域名系统

  （Domain Name System, DNS）的主要任务。

• DNS是：

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

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

• 除了进行主机名到IP地址的转换外，DNS还提供了一些重要的服务：

  • 主机别名（host aliasing）。有着复杂主机名的主机能拥有一个或者多个别名。主机别名（当存在时）比主机规范名更加容易记忆。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址。
  • 邮件服务器别名（mail server aliasing）。DNS同样也提供邮件服务器主机名和别名的转换服务，实际上，公司的邮件服务器和Web服务器可以使用相同的主机别名；MX记录允许一个公司的邮件服务器和Web服务器使用相同的主机名。
  • 负载分配（load distribution）。DNS也用于在冗余的服务器（如冗余的Web服务器等）之间进行负载分配。繁忙的站点（如cnn. com）被冗余分布在多台服务器上,每台服务器均运行在不同的端系统上，每个都有着不同的IP地址。但是它们都和同一个主机名相关联，也就是一个IP地址集合同一个规范主机名相联系；当某个DNS服务器收到DNS请求时，该服务器将使用IP地址的整个集合作为响应，但是在每个应答中，循环这些地址的次序。因为客户端通常都是使用IP地址集合的首个元素，所以DNS就在冗余的Web服务器之间分配了负载。同理，多个邮件服务器可以具有相同的别名。

2.4.2 DNS工作机理概述

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

  • 单点故障（a single point of failure）。如果该DNS服务器崩溃，整个因特网随之瘫痪！
  • 通信容量（traffic volume）。单个DNS服务器不得不处理所有的DNS査询。
  • 远距离的集中式数据库(distant centralized database) 。单个DNS服务器不可能 “邻近”所有查询客户。
  • 维护(maintenance)。单个DNS服务器将不得不为所有的因特网主机保留记录。

• 分布式、层次数据库

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

  • 有3种类型的DNS服务器根DNS服务器、顶级域(Top Level Domain, TLD) DNS服务器和权威DNS服务器。

    

    • 根DNS服务器：有400多个根名字服务器遍及全世界。根名字服务器提供TLD服务器的IP地址。

    • 顶级域(DNS)服务器：对于每个顶级域(如com、org、net、edu和gov)和所有家的顶级域(如uk、fr、ca和jp),都有TLD服务器(或服务器集群)。

    • 权威DNS服务器：在因特网上具有公共可访问主机（如Web服务器和邮件服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。

    • 本地DNS服务器：本地DNS服务器并不属于该服务器的层次结构。每 个ISP （如一个居民区的1SP或一个机构的ISP）都有一台本地DNS服务器（也叫默认名字服务器）主机的本地DNS服务器通常“邻近”本主机。当主机发岀DNS请求时，该请求被发往本地DNS服务器，它起着代理的作用，并将该请求转发 到DNS服务器层次结构中。

      

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

• DNS缓存

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

    服务器接收一个DNS回答(例如，包含某 主机名到IP地址的映射)时，它能将映射缓存在本地存储器中。

  • 由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后(通常设置为两天)将丢弃缓存的信息。事实上，因为缓存，除了少数DNS查询以 外，根服务器被绕过了。

2.4.3 DNS记录和报文

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

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

  

  • TTL是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。
  • Name和Value的值取决于Type：
    • 如果Type = A,则Name是主机名，Value是该主机名对应的IP地址。
    • 如果Type = NS,则Name是个域(如foo. com),而Value是个知道如何获得该域中主机IP地址的权威DNS服务器的主机名。
    • 如果Type=CNAME，贝lj Value是另9名为Name的主机对应的规范主机名。
    • 如果Type = MX,则Value是个别名为Name的邮件服务器的规范主机名。

• DNS报文

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

    

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

  • 问题区域包含着正在进行的查询信息。

  • 在来自DNS服务器的回答中，回答区域包含了对最初请求的名字的资源记录。

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

  • 附加区域包含了其他有帮助的记录。

• 在DNS数据库中插入记录

  • 注册登记机构（registrar）是一个商业实体,它验证该域名的唯一性，将该域名输入DNS数据库（如下面所讨论的那样）。当你向某些注册登记机构注册域名networkutopia, com时，需要向该机构提供你的基本和辅助权威DNS服务器的名字和IP地址。
  • 你还必须确保用于Web服务器www. networkutopia, com的类型A资源记录和用于邮件服务器mail, networkutopia, com的类型MX资源记录被输入你的权威DNS服务器中。

2.5 P2P文件分发

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

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

• BitTorrent

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

  • 每个洪流具有一个基础设施节点，称为追踪器（tracker）。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方 式，追踪器跟踪参与在洪流中的对等方。一个给定的洪流可能在任何时刻具有数以百计或数以千计的对等方。

  • 如图2 23所示，当一个新的对等方Alice加入该洪流时，追踪器随机地从参与对等方的集合中选择对等方的一个子集，并将这等方的IP地址发送给Aliceo Alice持有对等方的这张列表，试图与该列表上的所有对等方创建并行的TCP连接。我们称所有这样与Alice成功地创建一个TCP连接的对等方为“邻近对等方”。随着时间的流逝，这些对等方中的某些可能离开，其他对等方可能试图与Alice创建TCP连接。因此一个对等方的邻近对等方将随时间而波动。

    

  • Alice使用一种称为最稀缺优先（rarest Erst）的技术。这种技术的思路是，针对她没有的块在她的邻居中决定最稀缺的块（最稀缺的块就是那些在她的邻居中副本数量最少的块），并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是（大致地）均衡每个块在洪流中的副本数量。

  • BitTorrent使用一种算法，Alice优先从像她传时速度最快的邻居（4个，每10s修改一次）那里获取文件块。每过30s，Alice也要随机选择另外一个对等方Bob，向他发送块。若Alice是Bob最快的前四快，Bob也是Alice的前4快，则Bob和Alice互相发送据。 每过30s换一个新的对象，互相交换数据（一报还一报），为了使对等方能够找到彼此协调的速率上传。

2.6 视频流和内容分发网

2.6.1 因特网视频

• 在流式存储视频应用中，基础的媒体是预先录制的视频，例如电影、电视节目、录制 好的体育事件或录制好的用户生成的视频（如通常在YouTube上可见的那些）。这些预先录制好的视频放置在服务器上，用户按需向这些服务器发送请求来观看视频。
• 视频的一个重要特征是它能够被压缩，因而可用比特率来权衡视频质量。
• 从网络的观点看，也许视频最为突出的特征是它的高比特率。对流式视频的最为重要的性能度量是平均端到端吞吐量。为了提供连续不断的布局，网络必须为流式应用提供平均吞吐量，这个流式应用至少与压缩视频的比特率一样大。

2.6.2 HTTP 流和 DASH

• 在HTTP流中，视频只是存储在HTTP服务器中作为一个普通的文件，每个文件有一 个特定的URL。当用户要看该视频时，客户与服务器创建一个TCP连接并发送对该URL的HTTP GET请求。服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个HTTP响应报文中发送该视频文件。

• 流式视频应用程序周期性地从客户应用程序缓存中抓取帧，对这些帧解压缩并且在用户屏幕上展现。流式视频应用接收到视频就进行播放，同时缓存该视频后面部分的帧。

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

• DASH允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频。

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

  客户自由地在不同的质量等级之间切换。

2.6.3 内容分发网

• 对于一个因特网视频公司，或许提供流式视频服务最为直接的方法是建立单一的大规模数据中心缺陷：
  • 首先，如果客户远离数据中心，服务器到客户的分组将跨越许多通信链路并很可能通过许多ISP,其中某些ISP可能位于不同的大洲。
  • 第二个缺陷是流行的视频很可能经过相同的通信链路发送许多次。
  • 第三个问题是单个数据中心代表一个单点故障，如果数据中心或其通向因特网的链路崩溃，它将不能够分发任何视频流了。
• CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频（和其他类型的Web内容，包括文档、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN （private CDN）,即它由内容提供商自己所拥有；
• CDN通常采用两种不同的服务器安置原则：
  • 深入：该原则是通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。
  • 邀请做客：该原则是通过在少量（例如10个）关键位置建造大集群来邀请到ISP做客。不是将集群放在接入ISP中，这些CDN通常将它们的集群放置在因特网交换点（IXP）。
• CDN操作
  • 当用 户主机中的一个浏览器指令检索一个特定的视频（由URL标识）时，CDN必须截获该请求，以便能够 ①确定此时适合用于该客户的CDN服务器集群；②将客户的请求重定向到该集群的某台服务器。
  • 大多数CDN利用DNS来截获和重定向请求；
• 集群选择策略
  • 任何CDN部署，其核心是集群选择策略(cluster selection strategy),即动态地将客户定向到CDN中的某个服务器集群或数据中心的机制。
  • 一种简单的策略是指派客户到地理上最为邻近(geographically closest)的集群。地理最邻近的集群可能并不是最近的集群。这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化,总是为特定的客户指派相同的集群。
  • 为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量(real-time measurement)。

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

• 当用 户主机中的一个浏览器指令检索一个特定的视频（由URL标识）时，CDN必须截获该请求，以便能够 ①确定此时适合用于该客户的CDN服务器集群；②将客户的请求重定向到该集群的某台服务器。
  • 大多数CDN利用DNS来截获和重定向请求；
• 集群选择策略
  • 任何CDN部署，其核心是集群选择策略(cluster selection strategy),即动态地将客户定向到CDN中的某个服务器集群或数据中心的机制。
  • 一种简单的策略是指派客户到地理上最为邻近(geographically closest)的集群。地理最邻近的集群可能并不是最近的集群。这种简单的策略忽略了时延和可用带宽随因特网路径时间而变化,总是为特定的客户指派相同的集群。
  • 为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量(real-time measurement)。

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