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

2.1 应用层协议原理

2.1.1 网络应用程序体系结构

• 现代网络应用程序中使用的两种主流体系结构：客户-服务器（CS）体系结构或对等（P2P）体系结构
• 在客户-服务器体系结构（client-server architecture）中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。另一个特征是，服务器具有一个固定的、周知的IP地址。
• 配备大量主机的数据中心常被用于创建强大的虚拟服务器。
• 在P2P体系结构中（P2P architecture）中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。
• P2P2体系最引人入胜的特性之一是它们的自扩展性。P2P体系结构也是成本有效的，因为它们通常不需要庞大的服务器基础设施和服务器带宽。

2.1.2 进程通信

1. 客户和服务器进程

• 网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。
• 在给定的一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。

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

• 进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。
• 套接字是同一台主机内应用层与运输层之间的接口。
• 套接字对运输层端几乎没有控制权。应用程序开发者对于运输层的控制仅限于：

1. 选择运输层协议
2. 也许能设定几个运输层参数，如最大缓存和最大报文段长度等。

3. 进程寻址

• 在一台主机上运行的进程为了向另一台主机上运行的进程发送分组，接收进程需要有一个地址
• 在因特网中，主机由其IP地址（IP Adress）标识。端口号指向该主机内的发送进程或接受进程。

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

• 对应用程序服务进行分类：可靠数据传输、吞吐量、定时、安全性

1. 可靠数据传输

• 如果一个协议提供了确保数据交付服务，就认为提供了可靠数据传输（reliable data transfer）

2. 吞吐量

• 在沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。
• 具有吞吐量要求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application）
• 带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic application）能够根据情况或多或少地利用可供使用的吞吐量。

3. 定时

• 运输层协议也能提供定时保证。比如，发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms。（其实应该就是时延）

4. 安全性

• 运输协议能够为应用程序提供一种或多种安全性的服务。

2.1.4 因特网提供的运输服务

• 某些所选的应用程序的服务要求

  应用	数据丢失	带宽	时间敏感
  文件传输	不能丢失	弹性	不
  电子邮件	不能丢失	弹性	不
  Web文档	不能丢失	弹性（几kbps）	不
  因特网电话/视频会议	容忍丢失	音频（几kbps-1Mbps）视频（10kbps-5Mbps）	是，100ms
  存储音频/视频	容忍丢失	同上	是，几秒
  交互式游戏	容忍丢失	几kbps-10kbps	是，100ms
  即时讯息	不能丢失	弹性	是和不是

1. TCP服务

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

2. UDP服务

• UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
• UDP是无连接的，因此在两个进程通信前没有握手过程。
• UDP协议提供一种不可靠数据传送服务。
• UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

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

2.1.5 应用层协议

• 应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。特别是应用层协议定义了：
  • 交换的报文类型，例如请求报文和响应报文
  • 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
  • 字段的语法，即这些字段中包含的信息的含义。
  • 一个进程何时以及如何发送报文，对报文进行响应的规则。
• 网络层协议只是网络应用的一部分。
• Web是一种客户-服务器应用，它允许客户按照需求从Web服务器获得文档。该Web应用有很多组成部分，包括文档格式的标准（即HTML）、Web浏览器（如Firefox）、Web服务器（如Apache），以及一个应用层协议。
• Web的应用层协议是HTTP，它定义了在浏览器和Web服务器之间传输的报文格式和序列。
• 用于电子邮件的主要应用层协议就是SMTP。

2.2 Web和HTTP

2.2.1 HTTP概况

• HTTP 的请求-响应行为
  
• Web的应用层协议是超文本传输协议（HyperText Transfer Protocol, HTTP），它是Web的核心。
• HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。
• HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。
• Web页面（Web Page）是由对象组成的。诸如一个HTML文件、一个JPEG图形、一个Java小程序或一个视频片段这样的文件，且它们可通过一个URL地址寻址。
• 多数Web页面含有一个HTML基本文件（base HTML file）以及几个引用对象。
• Web浏览器（Web Browser）实现了HTTP的客户端，Web服务器（Web Server）实现了HTTP的服务端，它用于存储Web对象，每个对象由URL寻址。
• HTTP使用TCP作为它的支撑运输协议。HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。
• 服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。HTTP服务器并不保存关于客户的任何信息，所以我们说HTTP是一个无状态协议。
• Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自数以百万计的不同浏览器请求。

2.2.2 非持续连接和持续连接

• 非持续连接（non-persistent connection）：每个请求/响应对是经一个单独的TCP连续发送
• 持续连接（persistent connection ）：所有的请求及其响应经相同的TCP连接发送

1. 采用非持续连接的HTTP

• 每个TCP连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。
• 非持续连接有一些缺点。
  • 必须为每个请求的对象建立和维护一个全新的连接。对于这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这给Web服务器带来了严重的负担。
  • 每一个对象经受两倍RTT的交付时延，即一个RTT用于创建TCP，另一个RTT用于请求和接收一个对象。

2. 采用持续连接的HTTP

• 在采用持续连接的情况下，服务器在发送响应后保持该TCP连接打开。
• 在相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。特别的，一个完整的Web页面（HTML+多个图形）可以用单个持续TCP连接进行传送。
• 更有甚者，位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续TCP连接上进行。
• 如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。

2.2.3 HTTP报文格式

1. HTTP请求报文

• 一个HTTP请求报文的通用格式
  
• 典型的HTTP请求报文

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

• HTTP请求报文段第一行，请求行（request line）；其后继的行叫做首部行（Header line）
• 请求行有3个字段：方法字段、URL字段和HTTP字段
  • 方法字段：可以取几种值，GET、POST、HEAD、PUT、DELETE。大部分请求报文采用GET
  • URL字段：带有对象的标识
  • HTTP字段：HTTP版本
• 首部行：
  • Host：表明对象所在的主机
  • Connection：如果选择close，表示非持续连接
  • User-agent：首部行用来指明用户代理，即向服务器发送请求的浏览器的类型。可以根据不同的用户代理发送不同的版本
  • Accept-language：首部行表示用户想得到该对象的语言版本。
• 实体体（entity body）：使用GET方法时实体体为空，而使用POST方法时才使用实体体。
• 使用POST报文时，用户仍可以向服务器请求一个Web页面，但Web页面的特定内容依赖于用户在表单字段中输入的内容。如果方法字段的值为POST时，则实体体中包含的就是用户在表单字段中的输入值。
• HEAD方法：类似于GET方法。当服务器收到使用HEAD方法的请求时，将会用一个HTTP报文进行响应，但是并不返回请求对象。应用程序开发者常用HEAD方法进行调试跟踪。
• PUT方法常与Web发行工具联合使用，它允许用户上传对象到指定的Web服务器上指定的路径。PUT方法也被那些需要向Web服务器上传对象的应用程序使用。
• DELETE方法：允许用户或者应用程序删除Web服务器上的对象。

2. HTTP响应报文

• 一个HTTP响应报文的通用格式
  
• 典型的HTTP响应报文

  HTTP/1.1 200 OK
  Connection: close
  Date: Tue, 09 Aug 2011 15:44:04 GMT
  Server:Apache/2.2.3 (Centos)
  Last-Modified: Tue, 09 Aug 2011 15:11:03 GMT
  Contend-Length：6821
  Content-Type：text/html
  

• 响应报文有三个部分：初始状态行（status line）、首部行（header line）、实体体（entity body）
• 状态行：有3个字段，协议版本字段、状态码和相应状态信息。
• 首部行
  • Date：指示服务器产生并发送该响应报文的时间。
  • Server：指示该报文来自什么样的一台服务器
  • Last-Modified：指示了对象创建或者最后修改的日期和时间。对既可能在本地客户也可能在网络缓存服务器上的对象缓存来说非常重要。
  • Contend-Length：指示了被发送对象中的字节数。
  • Content-Type：指示了实体体中的对象是HTML文本
• 常见的状态码和相关的短语：
  • 200 OK：请求成功，信息在返回的响应报文中
  • 301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应报文的Location：首部行中。客户软件将自动获取新的URL。
  • 400 Bad Request：一个通用差错代码，指示该请求不能被服务器理解。
  • 404 Not Found：被请求的文档不在服务器上。
  • 505 HTTP Version Not Supported：服务器不支持请求报文使用的HTTP协议版本

2.2.4 用户与服务器交互：cookie

• 一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用了cookie
  
• cookie技术有4个组件：
  • 在HTTP响应报文中的一个cookie首部行
  • 在HTTP请求报文中的一个cookie首部行
  • 在用户端系统中保留有一个cookie文件，并由用户的浏览器管理
  • 位于Web站点的一个后端数据库。
• cookie工作过程，举例：
  • 访问某个购物网站时，服务器将产生一个唯一识别码，并以此作为索引在后端数据库中产生一个表项。在响应的时候，添加一个首部行Set-cookie，含有之前生成的识别码。如Set-cookie: 1678
  • 浏览器收到响应报文时，看到了Set-cookie: 1678报文，并在它管理的特定cookie文件中添加一行，该行包含服务器主机名、Set-cookie首部中的识别码。
  • 当继续浏览该网站相关的一些网站时，都会浏览器都会从cookie文件中获取对这个网站的那个识别码，并放到HTTP请求报文中。
  • 在这种方式，Amazon服务器就可以跟踪用户在站点的活动。
• cookie可以用于标识一个用户。浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户，因此cookie可以在无状态的HTTP之上建立一个用户会话层。因此可以实现，动态地针对不同的用户，显示不同的内容。

2.2.5 Web缓存

• Web缓存器（Web Cache）也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络实体。
• Web缓存器由自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。
• 可以配置用户的浏览器，使得用户的所有HTTP请求都首先指向Web缓存器。工作过程如下：
  • 浏览器向Web缓存器建立一个TCP连接，并发送一个HTTP请求
  • Web缓存器进行检查，看看本地是否存储了该对象的副本，如果有，就直接返回该对象。
  • 如果没有，就向HTTP请求的那个URL发出一个HTTP请求
  • 当Web缓存器收到该对象时，它在本地存储一个副本，并向客户的浏览器用HTTP响应报文发送该副本。
• Web缓存器既是服务器又是客户
  
• 在因特网部署Web缓存有两个原因；
  • Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此。
  • Web缓存器可以大大减少一个机构的接入链路到因特网的通信量。
• 内容分发网络（Content Distribution Network, CDN），公司在因特网上安装了许多地理上分散的缓存器，因而使大量流量实现了本地化。

2.2.6 条件GET方法

• 为了保证缓存器中的内容是最新的，有一种机制叫条件GET（conditional GET）方法。
• 如果请求报文中使用GET方法，并且请求报文中含一个If-Modified-Since:首部行。那么，这个HTTP请求报文就是一个条件GET请求报文。
• Web缓存器缓存了某个对象。当隔了一段时间之后，用户再次访问该网站的时候，Web缓存器就发送一个包含If-Modified-Since:请求行的请求到服务器，确认本地版本是否为最新版本。

  GET /fruit/kiwi.git HTTP/1.1
  HOST: www.exotiquecuisine.com
  If-Modified-Since: Wed, 7 Sep 2011  09:23:24
  

• 如果有被修改过，就发送一个新的对象回来。否则，就返回一个空实体体的响应回来。

  HTTP/1.1 304 Not Modified
  Date: Sat, 15 Oct 2011 15:39:29
  Server: apache/1.3.0(Unix)
  
  (empty entity body)
  

2.3 文件传输协议：FTP

• 用户坐在一台主机（本地主机）前面，向一台远程主机传输（或接收来自远程主机的）文件。
• 用户通过一个FTP用户代理与FTP交互。该用户首先提供远程主机的主机名，使本地主机的FTP客户进程建立一个到远程主机FTP服务器进程的TCP连接。
• 接着，提供用户标识和口令（也就是账户密码），作为FTP命令的一部分在该TCP连接上传送。
• 一旦该服务器向该用户授权，用户可以将存放在本地文件系统中的一个或者多个文件复制到远程文件系统。
• FTP使用了两个并行的TCP连接来传输文件，一个是控制连接（control connection），一个是数据连接（data connection）
  
• 控制连接用于在两个主机之间传输控制信息，如用户标识、口令、改变远程目录的命令以及“存放（put）”和“获取”（get）文件的命令。
• 数据连接用于实际发送一个文件
• 因此，FTP的控制信息是带外（out-of-band）传送的，HTTP可以说是带内（in-band）发送控制信息的
• 开始时，客户端向远程主机发起一个用于发送控制信息的TCP连接。
• 当FTP的服务器端收到一个文件传输的命令时，就发起一个向客户端的TCP数据连接。
• 在同一个会话期间，如果用户还需要传输另一个文件，FTP则打开另一个数据连接。
• 控制连接是持续的，数据连接是非持续的，每一个文件都会建立一个新的连接，传输结束之后就会关闭。

FTP命令和回答

• 从客户到服务器的命令和从服务器到客户的回答，都是以7比特ASCII格式在控制连接上传送的
• 常见命令
  1. USER username：用于向服务器传送用户标识
  2. PASS password：用于向服务器发送用户口令
  3. LIST：用于请求服务器回送当前目录的文件列表。通过数据连接传送。
  4. RETR filename：用于从远程主机当前目录检索（即get）文件
  5. STOR filename：用于在远程主机的当前目录上存放（即put）文件
• 常见回答
  1. 331 Username OK, Password required：用户名OK，需要口令
  2. 125 Data connection already open; transfer starting：数据连接已经打开，开始传送
  3. 425 Can't open data connection：无法打开连接
  4. 452 Error writing file：写文件差错

2.4 因特网中的电子邮件

• 因特网电子邮件系统，有三个组成部分：用户代理（user agent）、邮件服务器（mail server）和简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）
  
• 邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮箱。
• 邮件发送过程
  1. 从发送方的用户代理开始
  2. 传输到发送方的邮件服务器
  3. 再传输到接收方的邮件服务器
  4. 分发到接收方的邮箱中
  5. 接收方打开邮箱时，通过用户名和口令进行校验。在邮箱中读取到自己的邮件。
• 如果发送方服务器不能将邮件交付给接收方的服务器，发送方的邮件服务器中有一个报文队列（message queue）用于保持该报文并在以后尝试再次发送。
• SMTP是因特网电子邮件中主要的应用层协议。它使用TCP可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。

2.4.1 SMTP

• SMTP一般不使用中间邮件服务器发送邮件。

2.4.2 与HTTP的对比

• 两个协议都用于从一台主机向另一台主机传送文件：HTTP从Web服务器向Web客户传送文件。SMTP从一个邮件服务器向另一个邮件服务器传送文件。
• 当进行文件传送时，持续的HTTP和SMTP都使用持续连接
• HTTP是一个拉协议（pull protocol），即在方便的时候，某些人在Web服务器上装载信息，用户使用HTTP从服务器拉取这些信息。SMTP是一个推协议（push protocol），即发送邮件服务器把文件推向接受邮件服务器。
• 在处理一个既包含文本又包含图形的文档时，HTTP把每个对象封装到它自己的HTTP响应报文中，而SMTP则把所有报文对象放在一个报文之中。

2.4.3 邮件报文格式和MIME

• 每个首部必须包含一个From：首部行和一个To：首部行，可能包含一个Subject：首部行以及其他可选的首部行

  From: alice@crepes.fr
  To: bob@hamburger.edu
  Subject: Searching for the meaning of life.
  

2.4.4 邮件访问协议

• SMTP是一个推操作，而用户查邮件是一个拉操作，因此需要一个额外的协议支撑。
• 目前有一些流行的邮件访问协议，包括第三版的邮局协议（Post Office Protocol, POP3）、因特网邮件访问协议（Internet Mail Access Protocol, IMAP）以及HTTP
• SMTP用来将邮件从发送方的邮件服务器传送到接受方的邮件服务器；SMTP也将邮件从发送方的用户代理传送到发送方的邮件服务器；POP3这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理。
  

1. POP3

• 用户代理（客户）打开了一个到邮件服务器（服务端）端口110上的TCP连接后，POP3就开始工作了。
• 按照以下三个阶段进行工作：
  • 特许阶段：用户代理发送（以明文形式）用户名和口令以鉴别用户。（其实也就是登录？）
  • 事务处理阶段：首先，用户代理取回报文（查邮件）；对报文做删除标记（删邮件）、取消报文删除标记（回收站取回）、获取邮件的统计信息
  • 更新阶段：在客户发送quit命令之后，结束POP3会话；邮件服务器删除被标记删除的邮件
• 事务处理阶段，服务器会发出两种应答：+OK指示前面的命令是正常的；-ERR指示前面的命令出现了差错
• 使用POP3的用户代理通常被用户配置为“下载并删除”或“下载并保留”两种方式。
• 使用POP3访问时，一旦邮件下载到本地后，就能建立邮件文件夹，并将下载的邮件放入该文件夹中。可以在本地删除、移动报文。（但仅限于本地，远程服务器无法完成）

2. IMAP

• IMAP服务器把每个报文与一个文件夹联系起来：当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件、删除邮件等。
• IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。
• IMAP的另一个重要特性：具有允许用户代理获取报文组件的命令。用户代理可以只读取一个报文的报文首部，或只是一个多部分MIME报文的一部分。

3. 基于Web的电子邮件

• 用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过HTTP进行。

2.5 DNS：因特网的目录服务

2.5.1 DNS提供的服务

• 识别主机有两种方式：通过主机名或者IP地址
• 通过一种能进行主机名到IP地址转换的目录服务，实现用户通过输入主机名，让路由器通过IP地址寻找指定的主机。
• 这就是域名系统（Domain Name System，DNS）的主要任务。
• DNS是：
  • 一个由分层的DNS服务器实现的分布式数据库
  • 一个使得主机能够查询分布式数据库的应用层协议
• DNS服务器通常是运行BIND（Berkeley Internet Name Domain）软件的UNIX机器。
• DNS协议运行在UDP之上，使用53端口
• 用户主机在浏览器请求URL页面时，有以下操作：
  • 同一台用户主机上运行着DNS应用的客户端
  • 浏览器从URL中抽取出主机名，并将这台主机名传给DNS应用的客户端
  • DNS客户向DNS服务器发送一个包含主机名的请求
  • DNS客户端最终会收到一份回答报文，其中含有对应于该主机名的IP地址
  • 浏览器收到该IP地址之后，它向该IP地址80端口的HTTP服务器进程发起一个TCP连接
• DNS还提供了一些重要的服务
  • 主机别名（host aliasing）：有着复杂主机名的主机能拥有一个或者多个别名。复杂的原主机名又叫规范主机名。应用程序可以调用DNS来获得主机别名对应的规范主机名以及主机的IP地址
  • 邮件服务器别名（mail server aliasing）：电子邮件应用程序可以调用DNS，对提供的邮件服务器别名进行解析，以获得该主机的规范主机名以及IP地址。
  • 负载分配（load distribution）：DNS也用于冗余的服务器之间进行负载分配。繁忙的站点被冗余分布在多台服务器上，每台服务器均运行在不同的端系统上，每个都有着不同的IP地址。当客户对映射到某个地址集合的名字发出一个DNS请求时，该服务器用IP地址的整个集合进行响应，但在每个回答中循环这些地址次序。

2.5.2 DNS工作机理概述

• DNS由分布于全球的大量DNS服务器以及定义了DNS服务器与查询主机通信方式的应用层协议组成。
• DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含所有的映射。但这种集中式设计的问题包括：
  • 单点故障：如果该DNS服务器崩溃，整个因特网随之瘫痪
  • 通信容量：单个DNS服务器不得不处理所有DNS查询（太多了，承受不住呀）
  • 远距离的集中式数据库：距离远的查询中间经过低俗、拥塞的链路，将会导致严重的时延
  • 维护：单个DNS服务器将不得不为所有因特网主机保留记录。数据量太庞大了，而且需要频繁更新。
• DNS服务器的部分层次结构
  

1. 分布式、层次数据库

• 为了处理拓展性问题，DNS使用了大量的DNS服务器，它们以层次方式组织，并且分布在全世界范围内。
• 大致来说，有3种类型的DNS服务器：根DNS服务器、顶级域（Top-Level Domain，TLD）DNS服务器和权威DNS服务器。
  • 根DNS服务器：在因特网上有13个根DNS服务器（标号为A到M），它们大部分位于北美洲。
  • 顶级域（DNS）服务器：这些服务器负责顶级域名，如com、org、net、edu、gov；以及所有国家的顶级域名，如uk、fr、ca和jp。
  • 权威DNS服务器：每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。一个组织机构能够选择实现它自己的权威DNS服务器以保存这些记录；另一种方法是，将记录存储在某个服务提供上的一个权威DNS服务器中。
• 另一类重要的DNS，称为本地DNS服务器。每个ISP（如一个大学、一个系、一个公司或一个居民区的ISP）都有一台本地DNS服务器。当主机与某个ISP连接时，该ISP提供一台主机的IP地址，该主机具有一台或多台其本地DNS服务器的IP地址。通过访问Windows或UNIX的网络状态窗口，能够容易地确定本地DNS服务器的IP地址。
• 当发起DNS请求时，该请求会被发往本地DNS服务器，它起着代理的作用，并将该请求转发到DNS服务器层次结构中。
• 各种DNS服务器的交互
  
• 工作流程
  1. 主机cis.poly.edu首先向它的本地DNS服务器dns.poly.edu发送一个DNS查询报文
  2. 本地DNS服务器将该报文转发到根DNS服务器
  3. 该根DNS服务器注意到edu前缀，并向本地DNS服务器返回负责edu的TLD的IP地址列表
  4. 本地DNS服务器再次向这些TLD服务器之一发送查询报文
  5. 该TLD服务器注意到umass.edu前缀，并用权威DNS服务器的IP地址进行反馈
  6. 本地DNS服务器向dns.umass.edu的权威DNS服务器重发查询报文
  7. 权威DNS服务器用gaia.cs.umass.edu的IP地址进行响应
  8. 本地DNS向请求主机返回IP地址
• 另一种查询流程（递归查询）
  

2. DNS缓存

• 为了改善时延性能并减少在因特网上到处传输的DNS报文数量，DNS广泛使用了缓存技术
• 在一个请求链中，当某DNS服务器接收一个DNS回答（包含主机名到IP地址的映射）时，它能将该回答中的信息缓存在本地存储器中。
• 如果在DNS服务器中缓存了一台主机名/IP地址对，另一个对相同主机名的查询到达该DNS服务器时，该DNS服务器就能够提供所要求的IP地址。
• 由于主机和主机名与IP地址间的映射并不是永久的，DNS服务器在一段时间后（通常设置为2天）将丢弃缓存的消息。

2.5.3 DNS记录和报文

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

  (Name, Value, Type, TTL)
  

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

1. DNS报文

• DNS报文格式
  

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

• 如何将自己的域名插入到DNS数据库中
• 注册登记机构（registrar）是一个商业实体，它验证该域名的唯一性，将该域名输入DNS数据库，对提供的服务收取少量费用。

2.6 P2P应用

• 两种不同的特别适合于P2P设计的应用。第一种应用是文件分发，其中应用程序从单个源向大量的对等方分发一个文件。第二种是分布在大型对等方社区中的数据库。对于这个应用，将探讨分布式散列表的概念。

2.6.1 P2P文件分发

• 在P2P文件分发中，每个对等方能够重新分发它所有的该文件的任何部分，从而在分发过程中协助该服务器。
• 最为流行的P2P文件共享协议是BitTorrent
• 文件分发环境中的P2P体系结构具有自拓展性

1. P2P体系结构的拓展性

2. BitTorrent

2.6.2 分布式散列表

2.7 TCP套接字编程

2.7.1 UDP套接字编程

2.7.2 TCP套接字编程