计算机网络基础系列(三)网络应用

文章目录

网络应用的基本原理
- 网络应用体系结构
- 网络应用进程通信
- 网络应用的需求与传输层服务
Web应用
- HTTP协议
- HTTP连接
- HTTP消息格式
- Cookie技术
- Web缓存技术
Email应用
- Email消息格式与pop协议
DNS应用
- DNS概述
- DNS记录和消息
P2P应用

Internet的整个体系结构，符合TCP/IP协议栈，应用层在协议栈的最上层。

本节主要知识点为：

网络应用的体系结构：网络应用有哪几种体系结构？(客户机/服务器、P2P、混合结构)和单机应用有哪些不一样的地方？
网络应用对底层，传输层、网络层、链路层以及物理层构成的网络基础设施有哪些服务方面的需求？(可靠性、带宽、时延等方面)。
Internet传输层服务模型提供了什么样的传输服务模型？(TCP/UDP)。
具体地介绍几个网络应用及协议(HTTP、SMTP、POP、IMAP、DNS、P2P)。
如何来开发网络应用？(Socket编程、TCP、UDP)。

网络应用的基本原理

网络应用体系结构

网络应用和单机应用相比有哪些本质性区别？

网络应用需要有网络的基础环境，有一部分软件跑在我们自己的计算机上，还有一部分软件和数据信息运行在互联网的某一个地方，这两部分软件又互相交互，才共同构成了一个网络应用。

既然网络应用由不同的部分构成的，那它应该采取什么样的体系结构呢？

网络应用经过这么多年的发展，基本形成以下三种体系结构：1. 客户机/服务器结构；2. 点对点结构；3. 混合结构

客户机服务器结构：称之为客户机服务器的原因在于功能决策上的划分，服务器对外提供服务，客户机使用服务器所提供的服务。

服务器：7*24小时提供服务；永久性访问地址/域名；利用大量服务器实现可扩展性。服务器往往要为成百上千万的客户机提供服务，并发用户数同时请求服务的可以达到几万，几十万，这往往需要大量的服务器，分布式的技术来实现。客户机：与服务器通信，使用服务器提供的服务；间歇性接入网络；可能使用动态ip地址；不会与其它客户机直接通信。

最直观的就是Web应用，服务器端使用Web软件，客户机使用浏览器。客户端向Web服务器发出请求，服务器将页面和对象封装成http响应发回客户端。

P2P：P2P的特点是：没有永远在线的服务器；任意端系统/节点之间可以直接通讯；节点间歇性接入网络；节点可能改变IP地址。P2P这种结构平时接触最多的就是文件共享BT。

P2P与Web相比有哪些优点和缺点？：P2P的最大的优点是高度可伸缩可扩展；缺点是难于实现和管理。

混合结构：能否将P2P和CS混合起来使用，使其能够结合两者的优点的同时规避两者的缺点？

在Napster中文件的传输使用P2P结构，而文件的搜索采用C/S结构，集中式。每个节点向中央服务器登记自己的内容，每个节点向中央服务器提交查询请求，查找感兴趣的内容。

网络应用进程通信

上一小节从宏观，体系结构上认识了网络应用。这一小节深入了解网络应用的构成。网络应用由不同的部分构成，有些运行在PC机上，有的运行在远端的服务器上。而两者显然需要正确的协作，才能够完成其功能，保证网络性能。这就需要本机的网络进程和服务器端的网络进程之间需要通信。这就是网络应用的核心，本质上是网络进程之间正确的通信，然后完成功能。

进程为主机上运行的程序。同一主机上运行的进程之间如何进行通信？这一块由操作系统进程间的通信机制提供。不同主机上运行的进程如何通信？这个依靠的是消息交换，或者称之为报文交换。在消息交换或报文交换中我们有客户机进程(发起通信的进程)、服务器进程(等待通信请求的进程)。那么在P2P架构的应用中是否存在客户机进程和服务器进程之分？也是有的，P2P中也会有消息交换，所以也会有发起通信的进程和等待通信请求的进程。不同的进程之间的通信实际上是依靠的一个叫套接字的机制(Socket)。这是操作系统提供的一种抽象，他把网络的硬件基础设施和网络协议栈(链路层、网络层、传输层)抽象为Socket。

进程通过套接字来使用下层协议栈所提供的服务，比如TCP。这样进程间的通信就通过Socket发送/接收消息。将其类比于寄信Socket就像是门一样，发送方将消息送到门外的某个信箱里面去，然后依赖于(门外的)传输基础设施，将消息传到接收方所在主机，并送到接收方门外，接收方从门外获取消息。

所以说传输基础设施是进程间通信所依赖的东西。它由网络协议栈构成，由操作系统提供，相当于是操作系统提供的网络编程API。如果我们要开发网络应用，我们就需要调用这些API，网络应用的开发也被称作Socket编程。Socket处理传输一些消息，还可以对底层网络协议进行一些选择和设置。

网络应用之间依靠的是消息传输。那消息发出去之后，底层的传输基础设施如何正确无误的送到目标进程？这里就会有一个进程的标识问题，可以称为寻址。

寻址问题：不同主机上的进程通信，那么每个进程必须拥有标识符。因为其是不同主机上的，所以第一步是标识主机，标识主机就是依靠一个叫IP地址的东西。因为主机上会跑很多网络应用，所以只依靠IP地址是不够的，我们还需要端口号，我们为主机上每一个需要通信的进程分配一个端口号。有一些端口号是被约定的，不能够随便用，比如说80端口被HTTP Server占用，Mail Server占用25号端口。所以IP地址+端口号唯一标识网络上的进程。

应用层协议

具体的消息交换的格式，什么样的顺序等等依靠的是应用层协议。网络应用都应该遵循应用层协议，但是并不是说网络应用只有应用层协议。比如说Web应用包括浏览器软件，包括服务器软件，还包括html文件等等，不止是一个http协议。但是这些软件是要符合http协议的。所以说网络应用需要符合应用层协议。

应用层协议有公开的协议RFC(Request For Comments)定义，用公开的协议目的是为了互操作。如果需要知道某个协议的所有信息就需要去都RFC文档。

除了公开的协议外还有些私有的协议，多数P2P文件共享应用考虑商业上的竞争就会采用私有协议。

内容

一个应用层协议会规定有几种消息，所以会规定消息的类型，比如有请求消息，有响应消息。他也会规定消息的语法(syntax)格式，比如消息当中有哪些字段(field)，每个字段是如何描述的。下图是HTTP请求消息的格式：

我们也可以规定字段的语意(semantics，字段中信息的含义)，也会做出关于规则的描述，比如进程应该何时发送/响应消息？又比如进程应该如何发送/响应消息？等等这些规定。

网络应用的需求与传输层服务

计算机网络应用依靠的是不同进程之间的消息交换，依靠的是遵循相同的应用层协议，然后正确进行消息交换，消息交换并不是应用层自己做的，按照TCP/IP的分层，它是由传输层、网络层、链路层等等共同来提供的传输的基础服务。

所以这里就会引出两个问题：1. 网络应用有这么多种，不同的应用显然对于消息传输的需求不一样，这种不一样如何衡量？2. 底层传输层到底为应用层提供了什么样的服务？

网络应用对传输服务的需求

第一个方面是关于数据丢失(data loss)和可靠性(reliability)方面的需求。

有一些网络应用是能够容忍一定的数据丢失，比如网络电话，又比如说在线看视频等等。但是有些网络应用要求100%可靠的数据传输，包括文件传输。

另外一个是关于时间方面的要求，有些应用只有在时延足够低的时候才有效，典型的就是网络电话/网络游戏。
第三个方面是关于带宽的要求，某些应用只有在带宽达到最低要求时才有效，比如网络视频，如果带宽比较低的话，就是卡的没法看。而某些应用能够适应任何带宽-弹性应用，像email。

Internet提供的传输服务

当我们知道了如何刻画网络应用的需求的时候，我们就可以来看internet提供了什么样的传输服务？Internet提供两类传输服务，TCP服务/UDP服务。

TCP服务

TCP是一种面向连接的服务，也就是说客户机和服务器两者在进行消息交换之前要建立一个连接，这个连接一旦建立起来就是一个全双工的。TCP是提供可靠的数据传输，它可以把底层的不可靠转变为可靠，能够把数据不丢包、不乱序地传输。TCP还提供了流量控制功能，能够控制发送方不会发送速度过快，超过接收方的处理能力。TCP还提供了拥塞控制，当网络负载过重时，能够限制发送方的发送速度。但是TCP并不提供誓言方面的保障/不提供最小带宽保障。

UDP服务

UDP服务是无连接的，也不提供可靠的数据传输，也不提供可靠性保障、流量控制、拥塞控制、延迟保障、带宽保障统统都不保证。这种方式给了应用层极大的发挥空间，给力我们掌控数据传输的一种能力。

Web应用

Web最基础的构成是网页，但是只有Web并不会有今天的互联网，另外一个重要的要素是网页之间的互相链接。网页(Web Page)包含多个对象(objects)，对象是HTML文件、JPEG图片、视频文件、动态脚本等。每个网页会有一个基本的HTML文件，在这个文件当中，会包含对其他对象引用的链接。有了这样一个机制，才有了今天的万维网。

在计算机里面，每一个文件都会有一个唯一的路径来区分，互联网上的文件我们也需要对其进行区分，这里就会涉及到对象的寻址(addressing)，也就是Web对象如何来寻址？如何来标识？依靠的是URL(Uniform Resoure Locator，统一资源定位器)。它有一个基本的格式：Scheme://host:port/path。协议+主机+端口号+路径。这样就能够使得所有的资源都有了唯一的标识符。

HTTP协议

Web应用所遵循的协议就是http协议，也叫超文本传输协议(hypertext transfer protocol)。这个协议采用的是客户机服务器架构。客户是浏览器，主要是请求Web对象，接收Web对象，解析Web对象，展示Web对象。另外一端就是服务器，也叫Web Server，能够响应客户的请求，生成响应消息，然后把对象发给客户。

最典型的Web服务器软件就是Apache软件。Http协议也有不同的版本。Http协议所使用的传输层协议是TCP传输协议。

使用TCP传输服务的流程如下：

服务器在80端口等待客户的请求；
浏览器发起到服务器的TCP连接(创建套接字Socket)；
服务器接受来自浏览器的TCP连接；
浏览器(HTTP客户端)与Web服务器(HTTP服务器)交换HTTP消息；
关闭TCP连接；

这里要注意：HTTP协议是一个无状态协议，服务器不维护任何有关客户端过去所发请求的消息。大体上都是使用无状态的协议，有状态的协议往往更复杂，需要维护状态(历史信息)；如果客户或服务器失效，会产生状态的不一致，解决这种不一致代价高。

HTTP连接

Web应用依靠Http协议，Http协议又依赖传输层的TCP协议。在TCP的使用上是有两种不同的使用方法的，我们将其称为不同的HTTP连接类型。1. 非持久性连接(Nonpersistent HTTP)：每个TCP连接最多允许传输一个对象。HTTP早起版本使用的方法。2. 持久性连接(Persistent HTTP)：每个TCP连接允许传输多个对象。

他们之间的区别是什么？二者的工作方式如下图所示：

如果网速比较慢的时候，就会出现先有了网页，然后再加载图片的过程。如果想要对其时间性能进行分析，建立一个简单的时间响应模型来衡量其性能，我们可以对其进行响应时间分析与建模。

开始分析之前先定义一个词，RTT(Round Trip Time)：从客户端发送一个很小的数据包到服务器并返回所经历的时间。那从浏览器开始，一直到最后得到文件，响应时间可以分解为：1. 发起、建立TCP连接：1个RTT；2. 发送HTTP请求消息到HTTP响应消息的前几个字节到达：1个RTT；3. 响应消息中所含的文件/对象传输时间；所以获得一个对象的时间是两倍的RTT+文件发送时间：

上述这种非持久性连接的问题：1. 每个对象需要两个RTT；2. 操作系统需要为每个TCP连接开销资源(overhead)，这对服务器来说是一个很大的负担；3.浏览器会打开多个并行的TCP连接以获取网页所需对象，这个时候给服务器端会造成很大的负担。

改进的办法就是将其改为持久性连接，思路就是发送响应后，服务器保持TCP连接的打开。细分的话又可以分为：1. 无流水(pipelining)的持久性连接：客户端只有收到前一个响应后才发送新的请求。每个被引用的对象耗时1个RTT。2. 有流水机制的持久性连接：HTTP1.1的默认选择，客户端只要遇到一个引用对象就尽快发出请求；理想情况下，收到所有的引用对象只需耗时约一个RTT；

HTTP消息格式

Http协议有两类消息，分别是请求消息(Request)和响应消息(Response)。

请求消息

请求消息是用ASCII码写的，人直接可读。

第一行称之为请求行。请求行的第一部分是请求的命令，Get是一个请求方法，除此之外还有POST、HEAD等等都可以。后面跟的是一个URL，和HTTP的版本。之后的几行称之为头部行，表明要访问的主机地址(这里都建立起了TCP连接了，这个地址还有用吗？在缓存的时候有用)。之后是浏览器类型，服务器会依据你的浏览器类型发送符合你的浏览器的版本。Connection表示发完这个可以把连接关闭了。之后定义为接受的语言。最后为一个回车，空行，表明消息结束了。通用格式如下图所示：

请求消息里面有时候也会带有数据，比如要登陆某个网站的时候，请求消息里面就会带有数据。向服务器中上传数据的方法有两种：

POST方法：在第一行中可以定义不同的方法，比如举例得到的GET方法。POST会将表格中的数据放到消息体(Entity body)中。然后传给服务器，服务器从这里面讲数据提取出来。
Get方法：我们称这种方法为URL方法，如果信息比较少的话，我们可以将其放到Request行的URL字段中。也就是方法不变，但是在URL中加一些信息。

方法类型：

HTTP 1.0里面有GET方法(我们从浏览器中获得的)；我们还有POST方法；还有一个HEAD方法，请求服务器不要将所请求的对象放入到响应消息中，只是返回头部的一些东西；

HTTP 1.1又增加了两种方法，分别是PUT和DELETE。PUT是将消息体中的文件上传到URL字段所指定的路径(此功能支持上传文件)。DELETE删除URL字段所指定的文件。

响应消息

同样是ASCII写的，第一行称为状态行(status line)，前面说的是使用的http版本1.1，返回的状态是200，后面跟一个解释OK。

接下来几行都是头部行(header lines)。Date是Web服务器生成响应消息的时间，Last-Modified是上次网页的修改时间，是1998年Jun 22。Server表示服务器使用的软件类型。之后再定义了文本的长度和文本类型。

这里要注意这个状态行，方便我们之后上网知道网页出错的原因：

200代表OK；
301代表这个网页被永久性的移走了；
400表示Bad Request；
404表示找不到；
505表示HTTP版本不支持；

Cookie技术

HTTP协议是一种无状态的，也就是服务器不记录客户的历史行为。这个时候就可能带来一些问题。比如网上购物，实现购物车等等，很多时候我们需要记录用户的会话。

Cookie技术是某些网站为了辨别用户身份，进行session跟踪而存储在用户本地终端上的数据(经常通过加密)。Cookie的RFC编号是6265。

Cookie是架设在HTTP上面的一个组件，首先是会在HTTP响应消息中增加cookie头部行，Cookie是后来才发展出来的，所以HTTP的头部行是可扩展的。请求消息中也会增加Cookie的头部行。然后在客户端的主机上会有一个Cookie文件，由浏览器管理。在服务器那头会建立一个后台的数据库。

那有了上述这些组件之后能不能解决无状态的这样一个问题呢？其工作原理如下：

客户端首先用常规的请求消息，不带Cookie头部向服务器发送消息，服务器一看是新访问的用户，就给它创建一个ID 1678，然后把ID号和客户信息放到数据库中去，记录下来。之后在返回的消息中，利用响应消息头部行，加一个Set Cookie 1678。

然后浏览器收到这一行消息之后，就会把这个行解析出来，在自己的Cookie文件中增加一行，再次访问的话，就会在常规的访问消息中增加Cookie 1678。此时服务器那一端就知道了这个用户，可以在数据库中对其资料进行查询，可以做出针对这个用户特定的动作。

所以Cookie可以用于身份认证、购物车、推荐系统、Web e-mail等。Cookie最大的问题就是隐私问题。

这一小节主要理解Cookie技术、有状态和无状态、以及如何在HTTP协议基础上如何去扩展新的技术，新的消息，以适应新的需求。

Web缓存技术

缓存，或者称之为Web服务器表示在不访问服务器的前提下满足客户端的HTTP请求。说得形象一点是如果学校或者公司有Web服务器的话，浏览网页可能就是它直接给你的，根本没有去访问目标地址。发明这种技术主要是从性能角度考虑，Cookie主要是从功能上考虑。

Web服务器能够缩短客户请求的响应时间；减少机构/组织的流量；在大范围内(Internet)实现有效的内容分发。

结构如上图所示，实际上就是在客户和服务器之间架设了一个代理服务器。架设完它之后，用户在访问Web的时候都访问这个代理服务器，而不是访问原始服务器。

如果所请求的对象在缓存服务器中有，缓存返回对象，否则，缓存服务器向原始服务器发送HTTP请求，获取对象，然后返回给客户端并保存该对象。缓存既充当客户端，也充当服务器，一般由ISP(Internet服务提供商)架设。

条件性GET方法

HTTP请求中有一个Last Modified。条件性GET的基本思想是，如果缓存有最新的版本，则不需要发送请求对象。在HTTP请求消息中声明所持有版本的日期。如果服务器那端收到条件性GET方法的时候，如果缓存的版本是最新的，则响应消息中不包含对象。

Email应用

Email由以下几部分构成：

邮件客户端(User Agent)：主要负责读、写Email消息，能够与服务器进行交互，收发Email。当使用浏览器的时候，浏览器本质上也是一种Web客户端。
邮件服务器：邮件服务器是Email的核心。用户向邮件服务器申请账号，之后服务器给用户开辟一个账号。当我们不在线的时候，收到的邮件存在邮件服务器中。邮件服务器中还会创建一个消息队列，存储我们要发送出去的邮件，然后会代替我们的PC机，确保将邮件发送到指定的地方。
SMTP协议(Simple Mail Transfer Protocol，简单邮件传输协议)：它是邮件服务器之间传输消息所使用的协议，传输过程中，客户端是发送消息的服务器，服务器是接收消息的服务器。

为什么我们需要邮件服务器？为什么我们需要这样一种架构？采用邮件服务器的好处在于：手机或者客户端不能保证7*24小时在线，邮件服务器就能确保邮件一直能够接收到。

SMTP是email应用的核心协议，可以参考RFC 2821。因为需要确保消息的可靠传输，所以需要使用TCP进行网络网络传输。它运行在25号端口上面，传输过程一般要经历三个阶段：握手、消息的传输、关闭。他采用的是一种命令/响应的交互模式(HTTP采用的是请求/响应的模式)。命令也是采用可读的模式(ASCII文本)，响应采用状态代码和语句的方式。由于Email比较古老，只有文本，没有多媒体，所以Email消息里面只能包含7位ASCII码。

Email应用是一个典型的异步应用，发送方和接收方不需要同时。这种方式是很方便的。在这背后SMTP协议是如何工作的？

SMTP协议交互示例

SMTP的命令和响应统统是用ASCII码构成的，我们可以直接阅读交互过程：

建立TCP连接之后，服务器发送域名，要发邮件的服务器发送hello先打个招呼，等等交互信息：

与HTTP协议进行一个对比：

HTTP是一个拉式的网络应用，需要从Web服务器将网页拉回本地。而SMTP是一种推式的这样一个协议，由发送方主动地建立连接，然后把消息推送到接收方，它们都是用了一种命令响应的交互模式，或者说是请求响应的交互模式，命令和状态代码都是ASCII。HTTP是每个对象封装在独立的响应消息中，SMTP是多个对象在由多个部分构成的消息中发送。

Email消息格式与pop协议

Email应用由邮件客户端、邮件服务器、SMTP协议三大部分构成。那SMTP传输的Email消息格式是什么样子的呢？由两部分构成：

消息头部行：Http协议里面也有消息的头部行，头部行里面有to、from、subject字段(发件人，收件人，邮件标题)，它与SMTP命令不同。
消息体：真正的内容在消息体中，只支持ASCII字符。二进制构成的、非ASCII字符的文件，通过多媒体邮件扩展(MIME)进行传输。通过在邮件头部增加额外的行以声明MIME的内容类型。声明邮件里面有多媒体内容、采用的编码格式等内容。

Email遵循SMTP的简单邮件传输协议，从服务器获取邮件的协议称为邮件访问协议。典型的为POP协议。这里使用了多个协议，是Email应用和Web应用一个很大的不同。

1. POP(Post Office Protocol，邮局协议)：两个阶段：1. 认证/授权阶段，确保是邮件的拥有者，另外是从邮件服务器下载邮件。2. 另外一个协议为IMAP(Internet Mail Access Protocol)协议，是一个比POP3更新的协议，其有更多的功能，实现起来也更加复杂。3. 第三类有HTTP协议：163、QQ Mail。基于Web应用里面的。

POP3协议有几个阶段：

认证阶段，采用的是命令、响应的一种模式。客户端命令：User声明用户名，Pass声明密码。基于此服务器端会给出OK，或者Error响应。
事务阶段：List列出消息数量；Retr用编号获取消息；Dele删除消息；Quit可以退出。

POP3协议有几种模式：

下载并删除模式：在这个模式下，用户如果换了客户端软件，则无法重读该邮件；
下载并保持模式：不同客户端都可以保留消息的拷贝。

POP3也是一个无状态的协议。

IMAP协议相比于POP3协议有很大的进步：1. 所有消息统一保存在一个地方：服务器。2. 允许用户利用文件夹组织消息；3. IMAP支持跨会话(Session)的用户状态，所以在服务器上建立文件夹，把消息放入文件夹中，之后在所有的客户端上都是一致的。所以说IMAP是一个有状态的协议。

DNS应用

DNS概述

DNS(Domain Name System)互联网上的一个核心服务，是一个庞大的应用。它解决的是互联网上的主机/路由器的识别问题。每个主机需要IP地址来辨识，IPV4版本是一组32位的数，IPV6版本是128的。IP地址本身是数字，对人类并不友好，所以日常生活中上网使用的是一些域名：www.csdn.com。采用这种方式就需要解决域名和IP地址之间的映射问题。负责做这个映射的系统就是DNS，也称作域名解析系统。

它是多层命名服务器构成的分布式数据库，能够将域名翻译成IP地址。它本身也是一个应用层协议，在应用层协议之上又有应用层软件，负责完成名字的解析。它所提供的服务是互联网的核心功能，但是用应用层协议实现。(为什么在应用层做呢？)

DNS最基本的服务是域名向IP地址的翻译；还有别名的服务，将不好记的名字变成一个好记的名字；邮件服务器的别名也可以做到；另外还可以做负载均衡，当域名向IP地址翻译的时候可以提供多个映射，没有新的服务的时候还可以调整地址的顺序。

为什么不采用集中式的DNS？

如果采用集中式的可能会遇到如下问题：1. 单点失败问题：如果我们使用集中式的服务器，一旦服务点坏掉了，整个互联网就坏掉了。2. 流量问题：几十亿台主机请求DNS的流量太大。3. 距离问题：不知道放在那里，时延严重；4. 维护性问题。

集中式的DNS是不可伸缩的。所以DNS采用的是分布式的层次式的数据库，这个服务器分布在全世界。

根服务器->顶级域名服务器->公司/学校的域名服务器。

如果客户端想要查询www.amazon.com的IP。客户端查询根服务器，找到com域名解析服务器；客户端查询com域名解析服务器，找到amazon.com域名解析服务器，客户端查询amazon.com域名解析服务器，获得www.amazon.com的IP地址。

但是分布式的也有代价，这里为了获得域名的查询，这里查询了三次。

根域名服务器：本地域名无法解析服务器时，就需要访问根域名服务器。如果根域名服务器知道，就直接给出；不知道的话就访问权威域名服务器，获得映射，向本地域名服务器返回映射。
顶级域名服务器(TLD，Top-Level Domain)：负责com，org，net，edu等顶级域名和国家顶级域名，例如cn，uk，fr等。这些顶级域名服务器由一些组织来维护，比如Network Solution维护com顶级域名服务器，Educause维护edu顶级域名服务器。
权威(Authoritative)域名服务器：组织的域名解析服务器，提供组织内部服务器的解析服务。由组织负责维护，或者委托提供商负责维护。
本地域名解析服务器：它并不严格属于层级体系，每个ISP有一个本地域名服务器，也称为默认域名解析服务器。当主机进行DNS查询时，查询被发送到本地域名服务器，然后本地域名服务器作为一个代理(proxy)，将查询转发给(层级式)域名解析服务器系统。

只要域名解析服务器获得了IP地址映射，他就要进行缓存。(一段时间过后，缓存条目失效)。本地域名服务器一般会缓存顶级域名服务器的映射，所以根域名服务器不经常被访问。

DNS记录和消息

DNS依赖的是一个分布式的，层次式的数据库。数据库中存的数据的格式是什么样子的呢？

DNS里面的记录，我们也称作资源记录(Resource Records RR)，是一个四元组(name value type ttl(关于时间有效性的一个字段))。不同类型中name和value的解释是不一样的。1. Type A：name是主机的类型，value是主机的IP地址；2. Type NS：name是域(edu.cn)，value是该域权威名解释服务器的主机域名。也就是指出了这个域的域名解析服务器是谁；3. Type CNAME：用于实现DNS的别名服务，name是某一真实域名的别名，value是真实域名；4. Type MX：这个是专门用来邮件服务器的，所以这个value是与name相对应的邮件服务器。

DNS是一个网络应用，自然也有它的协议，是一种查询(query)和回复(reply)性的协议。自然就会有查询回复的消息，这两种消息的格式是一样的。

它有消息的头部，identification，是一个16位的查询编码，回复使用相同的编号，这样就能够区分是哪一个查询的回复；flags字段是一些标志位，标识这个消息是一个查询消息还是回复消息，期望是一个递归吗？这个递归是否可用？这是否是一个权威回答等等。

如何注册域名？

在域名管理机构(如Network Solutions)注册域名(netXXX.com)，具体的，需要向域名管理机构提供你的权威域名解析服务器的名字和IP地址，域名管理机构向com顶级域名解析服务器中插入两条记录。

如果这个时候办了一个自己的邮件服务器，这个时候还需要在权威域名解析服务器中为www.netXXX.com中加入Type A记录，为net.XXX.com加入Type MX记录。

如果能上QQ，上不了网页，是因为解析不了域名，也就是DNS相关出了问题。
如果本地域名服务无缓存，当采用递归方法解析另一网络某主机域名时，用户主机、本地域名服务器发送的域名请求消息数分别为多少？

域名的解析过程分为两种情况：递归查询和迭代查询：

递归查询：客户机发送一条查询请求到本地域名服务器，发现缓存中没有主机名和IP地址对的信息，那么本地域名服务器就往上继续查询，发送一个查询报文，如果在某一级域名服务器找到了主机名和IP地址对信息，就直接返回。如果找不到，那么这个域名服务器又会作为客户机去请求上一级域名服务器，直至根域名服务器，根名称服务器收到DNS请求后，把所查询得到的所请求的DNS域名中发送给顶级域名服务器，让顶级域名服务器去往下级域名服务器请求查找，如果找到了就原路返回。某域名服务器-->...->顶级域名服务器-->根域名服务器-->下一级域名服务器-->...-->本地域名服务器-->客户机。
迭代查询：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所查询的IP地址，要么告诉本地域名服务器：“下一步应当向哪个域名服务器进行后续查询”，然后由本地域名服务器进行后续查询。然后，本地域名服务器查询多次。

所以如果是采用递归查询的话，用户主机和本地域名服务器发送的域名请求消息都为1次，如果是迭代查询的话，用户主机发送的请求消息为1次，但是本地域名服务器发送的域名请求消息为多次。

P2P应用

Web应用、Email应用、DNS应用主要都是C/S架构。这一小节主要介绍P2P架构。

P2P(Peer-to-Peer)没有服务器，没有7*24小时一直等待的服务器；任意端系统之间可以直接通信，P2P架构有很大的动态和随机性，节点具有随机性，也有可能动态更换IP地址等等。它的一个很重要的缺点就是，比较复杂，难以管理。

首先我们对P2P和客户机/服务器文件分发对比：

假设：服务器上传带宽为usu_{s}us，节点iii的上传带宽为uiu_{i}ui，节点iii的下载带宽为djd_{j}dj。所需要的时间可定义为：

服务器串行地发送NNN个副本，所需要的时间为NF/usNF/u_{s}NF/us，客户机iii需要F/diF/d_{i}F/di时间下载。整个文件分发的时间可表示为：

dcs=max{NF/us,F/min⁡i(di)}d_{cs} = max\{NF/u_{s}, F/\min_{i}(d_{i})\} dcs=max{NF/us,F/imin(di)}

对于较大的NNN来说，一般都前者比较大，并且随着NNN线性增长。

在P2P架构下，服务器至少要发送一个副本到互联网上，所需要的时间F/usF/u_{s}F/us。在P2P架构中，任何一个节点，只要持有文件的任何部分，他就可以分享给其它节点，互相之间可以分享。客户机iii需要F/diF/d_{i}F/di时间下载，总共需要NFNFNF个比特。最快的上传速率为us+∑uiu_{s} + \sum u_{i}us+∑ui。

dp2p=max{F/us，F/min⁡(di),NF/(us+∑ui)}d_{p2p} = max\{F/u_{s}，F/\min(d_{i}), NF/(u_{s} + \sum u_{i})\} dp2p=max{F/us，F/min(di),NF/(us+∑ui)}

索引技术

P2P中经常会需要搜索信息，索引是信息到节点位置(IP地址+端口号)的映射。比如文件共享中，我们需要利用索引动态跟踪节点所共享的文件位置，节点需要告诉索引它拥有哪些文件，节点搜索索引，从而获知能够得到哪些文件。

在即时消息中，索引负责将用户名映射到位置，当用户开启IM应用时，需要通知索引它的位置，节点检索索引，确定用户的IP地址。

那索引如何来设计呢？

集中式索引：在Napster中最早采用这种设计，任何节点加入时，都需要通知中央服务器它的IP地址，和它所持有的内容，当某一个节点需要查找时，只需要向中央服务器查找就可以了。找到之后直接就向另外的节点请求获取文件即可。

在集中式索引中，虽然内容和文件传输是分布式的，但是内容定位是高度集中式的，就会面临单点失效问题、并且这种集中式的会成为性能的瓶颈。

分布式索引系统：洪泛查询(Query flooding)，这个架构师完全的分布式架构，没有任何特殊的节点，每个节点负责对自己共享的文件进行索引，并且只索引自己的。那如何获取全局信息呢？

采用覆盖网络的方式进行检索，所谓的覆盖网络说的是：如果节点XXX与YYY之间有TCP连接，那么构成一个边，所有的活动节点和边构成覆盖网络，边为虚拟链路。

查询消息的时候通过已有的TCP连接去发送，任何收到查询消息的节点都继续转发这个查询消息。如果查询命中的话，则利用反向路径发回查询节点。

层次式覆盖网络：它是介于集中式索引和洪泛查询之间的一种方法，节点分为两种，普通节点和超级节点，节点和超级节点之间维持TCP连接，某些超级节点对之间维持TCP连接。

超级节点负责跟踪子节点的内容。