《计算机网络 自顶向下方法》读书笔记 第2章 应用层

第2章 应用层

2.1应用层协议原理

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

2.在客户-服务器体系结构中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。

3.在P2P体系结构中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在尖端连接的主机之间使用直接通信，这些主机对被称为对等方。P2P体系结构的特性之一是自扩展性。例如，在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

4.在多个端系统之间进行通信的程序称为进程。对每队通信进程，通常将这两个进程之一标识为客户，而另一个进程标识为服务器。在一对进程之间的通信会话场景中，发起通信（即在会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。

5.进程通过一个被称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。套接字是同一台主机内应用层与运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface, API）。应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层几乎没有控制权。应用程序开发者对运输层的控制仅限于选择运输层协议和设定运输层参数。

6.在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了标识该接收进程，需要定义两种信息：主机的地址；在目的主机中指定接收进程的标识符。IP地址用于指定目的地的主机地址。端口号用于指定运行在接收主机上的接收进程。

7.一个运输层协议能够为调用它的应用程序提供以下4种服务：

​ 可靠数据传输。如果一个协议提供了确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端这样的确保数据交付服务，就认为提供了可靠数据传输。当一个运输层协议不提供可靠数据传输是时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用所接受。如多媒体应用和交谈式音频/视频。

​ 吞吐量。运输层协议能够以某种特定的速率提供确保的可用吞吐量。具有吞吐量要求的应用程序被称为带宽敏感的应用。弹性应用能够根据当时可用的带框或多或少地利用可供使用的吞吐量。

​ 定时。运输层协议也能提供定时保证。如同具有吞吐量保证那样，定时保证能够以多种形式实现。例如，发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。

​ 安全性。运输层协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。

8.因特网为应用程序提供两个运输层协议，即UDP和TCP。

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

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

TCP协议还具有拥塞控制机制。当发送方和接收方之间的网络出现拥塞时，TCP的拥塞控制机制会抑制发送进程。

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

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

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

2.2 Web和HTTP

1.Web的应用层协议是超文本传输协议（HyperText Transfer Protocol, HTTP），它是Web的核心。

2.Web页面是由对象组成的。一个对象只是一个文件，诸如一个HTML文件、一个JPEG文件、一个Java小程序或一个视频片段这样的文件，且它们可以通过一个URL地址寻址，多数Web页面包含HTML基本文件以及几个引用对象。

3.每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。

4.HTTP使用TCP作为它的支撑运输协议（而不是在UDP上运行）。

5.因为HTTP服务器并不保存关于客户的任何信息，所以说HTTP是一个无状态协议。

6.在许多因特网应用程序中，客户和服务器在一个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。如果每个请求/响应对是经一个单独的TCP连接发送，该应用程序被称为使用非持续连接。如果所有的请求及其响应经相同的TCP连接发送，该应用程序被称为使用持续连接。HTTP在默认方式下使用持续连接。

​ 使用非持续连接时，每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。使用非持续连接的总的响应时间是两个往返时间（Round-Trip Time, RTT，指一个短分组从客户到服务器然后再返回客户所花费的时间）加上服务器传输HTML文件的时间。非持续连接的缺点：第一，必须为每一个请求的对象建立和维护一个全新的连接。第二，每一个对象经受两倍RTT的交付时延。

​ 在采用HTTP1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）任未被使用，HTTP的服务器就关闭该连接。

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

​ HTTP请求报文的通用格式如图2-1所示。

图2-1 HTTP请求报文的通用格式

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

请求行有3个字段：方法字段、URL字段和HTTP版本字段。方法字段可以取几种不同的值，包括GET、POST、HEAD、PUT和DELETE。绝大部分的HTTP请求报文使用GET方法。使用GET方法时实体体为空，而使用POST方法时才使用实体体。当用户提交表单时，HTTP客户常常使用POST方法。HEAD方法类似于GET方法。当服务器收到一个使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行试跟踪。PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径。PUT方法也被哪些需要向Web服务器上传对象的应用程序使用。DELETE方法允许用户或者应用程序删除Web服务器上的对象。

下面是一个HTTP请求报文的实例。

GET /somedir.page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

首部行Host: www.someschool.edu指明了对象所在的主机。通过包含Connection: close首部行，浏览器告诉服务器不要麻烦地使用持续连接，它要求服务器在发送完被请求的对象后就关闭这条连接。User-agent:首部行用来指明用户代理，即向服务器发送请求的浏览器类型。Accept-language:首部行表示用户想得到该对象的语言版本（如果服务器中有这样的对象的话）。

HTTP响应报文的通用格式如图2-2所示。

图2-2 HTTP响应报文的通用格式

响应报文分为三个部分：状态行、首部行和实体体。

状态行有3个字段：协议版本字段、状态码和相应状态信息。状态码及其响应的短语指示了请求的结果。一些常见的状态码和相关的短语包括：

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

下面是一个HTTP响应报文的实例。

HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data ...)

服务器用Connection: close首部行告诉客户，发送完报文后将关闭该TCP连接。Date:首部行指示服务器产生并发送该响应报文的日期和时间。这个时间不是指对象创建或者最后修改的时间，而是服务器从它的文件系统中检索到该对象，将该对象插入响应报文，并发送该响应报文的时间。Server:首部行指示该报文是由一台Apache Web服务器产生的。Last-Modified:首部行指示了对象创建或者最后修改的日期和时间。Content-Length:首部行指示了被发送对象中的字节数。Content-Type:首部行指示了实体体中的对象是HTML文本。

8.Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用了cookie。cookie可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识。在后继会话中，浏览器想服务器传递一个cookie首部，从而向该服务器标识了用户。

9.Web缓存器也叫代理服务器，它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间保存最近请求过的对象的副本。在因特网上部署Web的原因有，首先，Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此。其次，Web缓存器能够大大减少一个机构的接入链路到因特网的通信量。此外，Web缓存器能够从整体上大大减低因特网上的Web流量，从而改善了所有应用的性能。

10.HTTP协议有一种机制，允许缓存器证实他的对象是最新的。这种方法就是条件GET方法。如果请求报文使用GET方法，并且请求报文中包含一个“If-Modified-Since:”首部行。那么这个HTTP请求报文就是一个条件GTE请求报文。

2.3因特网中的电子邮件

1.因特网电子邮件系统有3个主要组成部分：用户代理、邮件服务器、和简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）。邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮箱。典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，在传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。SMTP是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务。

2.SMTP一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器距离很远。

3.SMTP与HTTP的区别：

• HTTP主要是一个拉协议，即在方便的时候，某些人在Web上装载信息，用户使用HTTP从该服务器拉取信息。TCP连接是由想接收文件的及其发起的。SMTP基本上是一个推协议，即发送邮件服务器把文件推向接收邮件服务器。这个TCP连接是由发送该文件的及其发起的。
• SMTP要求每个报文采用7比特ASCII码格式。HTTP数据则不受这种限制。
• 对于一个既包含文本又包含图形的文档，HTTP把每个对象封装到它自己的HTTP响应报文中，而SMTP则把所有报文对象放在一个报文之中。

4.一个人给另一个人发送电子邮件时，一个包含环境信息的首部要位于报文体前面。这些环境信息包括在一系列首部中。首部行和该报文的体用空行进行分隔。每个首部必须含有一个From:首部行和一个To:首部行。也许会包含一个Subject:首部行以及其他可选的首部行。下面是一个典型的报文首部：

From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.

5.在接收方代理向接收方邮件服务器获取邮件的过程中，用户代理不能使用SMTP得到报文，因为取报文是一个拉操作，而SMTP协议是一个推协议。通过引入一个特殊的邮件访问协议来解决这个问题，该协议将接收方邮件服务器上的报文传送给他的本地PC。目前有一些流行的邮件访问协议，包括第三版的邮局协议（Office Protocal-Version 3, POP3）、因特网邮件访问协议（Internet Mail Access Protocal, IMAP）以及HTTP。

​ POP3是一个极为简单的邮件访问协议。随着建立TCP连接，POP3按照三个阶段进行工作：特许、事务处理以及更新。在特许阶段，用户代理发送（以明文形式）用户名和口令以鉴别用户。在事务处理阶段，用户代理取回报文；同时在这个阶段用户代理还能对报文做删除标记、取消报文删除标记以及获取邮件的统计信息。在更新阶段，它出现在客户发出了quit命令之后，目的是结束该POP3会话；这时，该邮件服务器删除那些被标记为删除的报文。

​ 在POP3的事务处理过程中，用户代理发出一些命令，服务器对每个命令做出回答。回答可能有两种：+OK（有时后面还跟有服务器到客户的数据），被服务器用来指示前面的命令是正常的；-ERR，被服务器用来指示前面的命令出现了某些差错。

​ POP3协议没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法。IMAP服务器把每个报文与一个文件夹联系起来；当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。与POP3不同，IMAP维护了IMAP会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联。IMAP另一个重要特性是它具有允许用户代理获取报文某些部分的命令。

​ 使用Web浏览器收发电子邮件，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。

2.4 DNS：因特网的目录服务

1.域名系统（Domain Name System, DNS）是一种能进行主机名到IP地址转换的目录服务。DNS是：①一个由分层的DNS服务器实现的分布式数据库；②一个使得主机能够查询分布式数据库的应用层协议。DNS服务器通常是运行BIND（Berkeley Internet Name Domain）软件的UNIX机器。DNS协议运行在UDP之上，使用53号端口。

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

• 主机别名。有着复杂主机名的主机能拥有一个或者多个别名，主机别名比主机规范名更加容易记忆。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址
• 邮件服务器别名。电子邮件应用程序可以调用DNS，对提供的主机名别名进行解析，以获得该主机的规范主机名及其IP地址。
• 负载分配。DNS也用于在冗余的服务器之间进行负载分配。繁忙的站点被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上，每个都有着不同的IP地址。DNS数据库中存储着这些IP地址集合。当客户对映射到某地址集合的名字发出一个DNS请求时，该服务器用IP地址的整个集合进行响应，但在每个回答中循环这些地址次序。因为客户通常总是向IP地址排在最前面的服务器发送HTTP请求报文，所以DNS就在所有这些冗余的Web服务器之间循环分配了负载。DNS循环同样可以用于邮件服务器。

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

4.在单一DNS服务器上运行集中是数据库的问题包括：

• 单点故障。如果该DNS服务器崩溃，整个因特网随之瘫痪。
• 通信容量。单个DNS服务器不得不处理所有的DNS查询。
• 远距离的集中式数据库。单个DNS服务器不可能“临近”所有查询客户。
• 维护。单个DNS服务器将不得不为所有的因特网主机保留记录。这不仅将使这个中央数据库庞大，而且它还不得不为解决每个新添加的主机频繁更新。

5.为了处理扩展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。大致说来，有3种类型的DNS服务器：根DNS服务器、顶级域（Top-Level Domain, TLD）DNS服务器和权威DNS服务器。

• 根DNS服务器。根DNS服务器提供TLD服务器的IP地址。
• 顶级域DNS服务器。对于每个顶级域（如com、org、net、edu、和gov）和所有国家的顶级域（如uk、fr、ca和jp），都有TLD服务器（或服务器集群）。
• 权威DNS服务器。在因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。组织机构的权威DNS服务器收藏了这些DNS记录。
• 本地DNS服务器。本地DNS服务器起着代理作用，并将请求转发到DNS服务器层次结构中。

6.任何DNS查询既可以是迭代的也可能是递归的。通常，从请求主机到本地DNS服务器的查询时递归的，其余的查询时迭代的。

7.为了改善时延性能并减少在因特网上导出传播的DNS报文数量，DNS使用了DNS缓存。在一个请求链中，当某DNS服务器接收一个DNS回答时，它能将映射缓存在本地存储器中。由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后将丢弃缓存的信息。

8.共同实现DNS分布式数据库的所有DNS服务器存储了资源记录（Resource Record, RR），RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或多条资源记录。资源记录是一个包含了下列字段的4元组：

​ (Name, Value, Type, TTL)

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

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

l 如果Type = MX，则Value是别名为Name的邮件服务器的规范主机名。

9.DNS有两种报文：查询报文和回答报文。查询和回答报文有着相同的格式，如图2-3所示。

• 前12个字节是首部区域，其中有几个字段。第一个字段（标识符）是一个16比特的数，用于标识该查询。这个标识符会被复制到对查询的回答报文中，以便让客户用它来匹配发送的请求和接收到的回答。标志字段中含有若干标志。1比特的“查询/回答”标志位支出报文是查询报文（0）还是回答报文（1）。
• 问题区域包含着正在进行的查询信息。该区域包括：①名字字段，包含正在被查询的主机名字；类型字段，指出有关该名字的正被询问的问题类型。
• 在来自DNS服务器的回答中，回答区域包含了对最初请求的名字的资源记录。回答区域中可以包含多条RR。
• 权威区域包含了其他权威服务器的记录。
• 附加区域包含了其他有帮助的记录。

2.5 P2P文件分发

1.P2P体系结构中的每个对等方能够帮助服务器分发该文件。当一个对等方接收到某些文件数据，他能够使用自己的上载能力重新将数据分发给其他对等方。对等方除了是比特的消费者外还是它们的分发者。

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

​ 每个洪流具有一个基础设施节点，称为追踪器。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在洪流中。

2.6视频流和内容分发网

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

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

3.为了应对向分布与全世界的用户分发巨量视频数据的挑战，几乎所有主要的视频流公司都利用内容分发网（Content Distribution Network, CDN）。CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频（和其他类型的Web内容，包括文档、图片和音频）的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置。CDN可以是专用CDN，即它由内容提供商自己所拥有。另一种CDN是第三方CDN，它代表多个内容提供商分发内容。

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

• 深入。通过在遍及全球的接入ISP中部署服务器集群来深入到ISP的接入网中。
• 邀请做客。通过在少量关键位置建造大集群来邀请到ISP做客。

5.事实上，许多CDN没有将视频推入它们的集群，而是使用一种简单的拉策略：如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频（从某中心仓库或者从另一个集群），向客户流式传输视频时的同时在本地存储一个副本。当某集群存储器变满时，它删除不经常请求的视频。

6.当用户主机中的一个浏览器指令检索一个特定的视频时，CDN必须截获该请求，以便能够：①确定此时适合用于该客户的CDN服务器集群；②将客户的请求重定向到该集群的某台服务器。

7.任何CDN部署，其核心是集群选择策略，即动态地将客户定向到CDN中的某个服务器集群或数据中心的机制。一种简单的策略是指派客户到地理上最为邻近的集群。使用商用地理位置数据库，每个本地DNS服务器（LDNS）IP地址都映射到一个地理位置。当从一个特殊的LDNS接收到一个DNS请求时，CDN选择地理上最为接近的集群。但对于某些客户，该解决方案可能执行的效果差，因为就网络路径的长度或条数而言，地理最邻近的集群可能并不是最近的集群。为了基于当前流量条件为客户决定最好的集群，SYN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量。

2.7(第6版2.3)文件传输协议：FTP

这个部分在第7版中被删掉了，在第6版的2.3中还有

1.在一个典型的FTP会话中，用户坐在一台主机（本地主机）前面，向一台远程主机传输（或接收来自远程主机的）文件。为使用户能访问他的远程账户，用户必须提供一个用户标识和口令。在提供了这种授权信息后，用户就能从本地文件系统向远程主机文件系统传送文件，反之亦然。

2.FTP和HTTP都是文件传输协议，它们都运行在TCP上。然而，FTP使用了两个并行的TCP连接来传输文件，一个是控制连接，一个是数据连接。控制连接用于在两主机之间传输控制信息，如用户标识、口令、改变远程目录的命令以及“存放”和“获取”文件的命令。数据连接用于实际发送一个文件。因为FTP协议使用一个独立的控制连接，所以称FTP的控制信息是带外（out-of-band）传送的。HTTP协议是在传输文件的同一个TCP连接中发送请求和响应首部行的。因此，HTTP也可以说是带内（in-band）发送控制信息的。

3.对FTP而言，控制连接贯穿了整个用户会话期间，但是对会话中的每一次文件传输都需要建立一个新的数据连接（即数据连接是非持续的）。

4.FTP服务器必须在整个会话期间保留用户的状态。特别是，服务器必须把特定的用户账户与控制连接联系起来，随着用户在远程目录树上徘徊，服务器必须追踪用户在远程目录树上的当前位置。对每个进行中的用户会话的状态信息进行追踪，大大限制了FTP同时维持的会话总助。而另一方面，HTTP是无状态的，即它不必对任何用户状态进行跟踪。

5.从客户到服务器的命令和从服务器到客户的回答，都是以7比特ASCII格式在控制连接上传送的。较为常用的命令如下：

• USER username ：用于向服务器传送用户标识。
• PASS password ：用于向服务器发送用户口令。
• LIST ：用于请求服务器回送当前远程目录中的所有文件列表。该文件列表是经一个（新建且非持续连接）数据连接传送的，而不是在控制TCP连接上传送。
• RETR filename ：用于从远程主机当前目录检索（即get）文件。该命令引起远程主机发起一个数据连接，并经该数据连接发送所请求的文件。
• STOR filename ：用于在远程主机的当前目录上存放（即put）文件。

贯穿控制连接，在用户发出的命令和FTP发送的命令之间通常有一一对应关系。每个命令都对应着一个从服务器发向客户的回答。回答时一个3位的数字，后跟一个可选信息。一些典型的回答连同它们可能的报文如下所示：

• 33 Username OK, Password requied（用户名OK，需要口令）。
• 123 Data connection already open; transfer starting（数据连接已经打开，开始传送）。
• 425 Can’t open data connection（无法打开数据连接）。
• 452 Error writing file（写文件差错）。