计算机网络基础之六：应用层

前言

应用层的作用是将通信服务是提供给应用进程。但不同的网络应用的应用进程之间，还需要有不同的通信规则。因此在运输层协议之上，还需要有应用层协议(application layer protocol)。每个应用层协议都是为了解决某一类应用问题（例如域名、文件传输、邮箱等等），这必须通过位于不同主机中的多个应用进程之间的通信和协同工作来完成。应用层的具体内容就是精确定义这些通信规则。

由于篇幅所限，所以在本文中，我将仅介绍域名系统DNS、万维网WWW、动态主机配置协议DHCP、简单网络管理协议SNMP、应用进程跨越网络的通信 这几部分知识。有关文件传输协议FTP、远程终端协议TELNET、电子邮件、P2P应用 的相关知识有兴趣可自行查阅。

域名系统 DNS

域名系统概述

DNS（Domain Name System，域名系统），万维网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过域名，最终得到该域名对应的IP地址的过程叫做域名解析（或主机名解析）。DNS协议运行在UDP协议之上，使用端口号53。

许多应用层软件经常直接使用域名系统DNS。虽然计算机的用户只是间接而不是直接使用域名系统，但DNS却为互联网的各种网络应用提供了核心服务。

互联网的域名系统DNS被设计成为一个联机分布式数据库系统，并采用客户服务器方式。DNS使大多数名字都在本地进行解析(resolve），仅少量解析需要在互联网上通信，因此DNS系统的效率很高。由于DNS是分布式系统，即使单个计算机出了故障，也不会妨碍整个DNS系统的正常运行。

域名到IP地址的解析是由分布在互联网上的许多域名服务器程序(可简称为域名服务器)共同完成的。域名服务器程序在专设的结点上运行，而人们也常把运行域名服务器程序的机器称为域名服务器。

互联网的域名结构

域名用来表示一个单位、机构或可以利用个人在Internet上的确定的名称或位置。域名是惟一的。客户可以利用这个名字找寻有关的产品和服务信息。
从技术角度来看，域名是在Internet上用于解决IP地址的一种方法。一个完整的域名由2个或2个以上的部分组成，各部分之间用英文的句号“.”来分隔，最后一个“.”的右边部分称为顶级域名(TLD，也称为一级域名)，最后一个“.”的左边部分称为二级域名(SLD)，二级域名的左边部分称为三级域名，以此类推，每一级的域名控制它下一级域名的分配。

DNS规定，域名中的标号都由英文字母和数字组成，每一个标号不超过63个字符(但为了记忆方便，最好不要超过12个字符)，也不区分大小写字母(例如，CCTV或CCri在域名中是等效的)。标号中除连字符C)外不能使用其他的标点符号。级别最低的域名写在最左边，而级别最高的顶级域名则写在最右边。由多个标号组成的完整域名总共不超过255个字符。DNS既不规定一个域名需要包含多少个下级域名，也不规定每一级的域名代表什么意思。各级域名由其上一级的域名管理机构管理，而最高的顶级域名则由ICANN进行管理。用这种方法可使每一个域名在整个互联网范围内是唯一的，并且也容易设计出一种查找域名的机制。

需要注意的是，域名只是个逻辑概念，并不代表计算机所在的物理地点。变长的域名和使用有助记忆的字符串，是为了便于人使用。

域名服务器

一个域名服务器所负责管辖的(或有权限的)范围叫做区(zone)。各单位根据具体情况来划分自己管辖范围的区。但在一个区中的所有节点必须是能够连通的。每一个区设置相应的权限域名服务器(authoritative name server)，用来保存该区中的所有主机的域名到IP地址的映射，以进行域名(domain name)和与之相对应的IP地址 (IP address)转换，解析域名。

总之，DNS服务器的管辖范围不是以“域”为单位，而是以“区”为单位。区是DNS服务器实际管辖的范围。区可能等于或小于域，但一定不能大于域。

在上图中的每一个域名服务器都能够进行部分域名到IP地址的解析。当某个DNS服务器不能进行域名到IP地址的转换时，它就设法找互联网上别的域名服务器进行解析。

从上图可看出，互联网上的DNS域名服务器也是按照层次安排的。每一个域名服务器都只对域名体系中的一部分进行管辖。

主机向本地域名服务器的查询一般都是采用递归查询(recursive query)，如上图(b)。特点就是，询问者和答复者一层一层构成递归，注意看上图步骤顺序（按数字编号）。而本地域名服务器向根域名服务器的查询通常是采用迭代查询(iterative query)，如上图(a)。特点就是，询问者不停的询问可能的答复者，注意看上图步骤顺序（按数字编号）。

为了提高DNS查询效率，并减轻根域名服务器的负荷和减少互联网上的DNS查询报文数量，在域名服务器中广泛地使用了高速缓存(有时也称为高速缓存域名服务器)。高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

万维网 WWW

万维网概述

WWW 是环球信息网的缩写，（亦作“Web”、“WWW”、“‘W3’”，英文全称为“World Wide Web”），中文名字为“万维网”，"环球网"等，常简称为Web。分为Web客户端和Web服务器程序。应当强调的是，万维网并不等同计算机网络，万维网只是计算机网络所能提供的服务其中之一，是靠着计算机网络运行的一项应用。

万维网以客户服务器方式工作。浏览器就是在用户主机上的万维网客户程序。万维网文档所驻留的主机则运行服务器程序，因此这台主机也称为万维网服务器。**客户程序向服务器程序发出请求，服务器程序向客户程序送回客户所要的万维网文档。**在一个客户程序主窗口上显示出的万维网文档称为页面(page)。

为了实现上述功能，首先，万维网使用统一资源定位符URL (Uniform Resource Locator)来标志万维网上的各种文档，并使每一个文档在整个互联网的范围内具有唯一的标识符URL；其次，万维网客户程序与万维网服务器程序之间的交互遵守严格的协议，这就是超文本传送协议HTTP (HyperText Transfer Protocol)。HTTP是一个应用层协议，它使用TCP连接进行可靠的传送；最后，万维网使用超文本标记语言HTML (HyperText Markup Language)，使得万维网页面的设计者可以很方便地用链接从本页面的某处链接到互联网上的任何一个万维网页面，并且能够在自己的主机屏幕上将这些页面显示出来。

统一资源定位符 URL

URL 的格式
统一资源定位符 URL 是用来表示从互联网上得到的资源位置和访问这些资源的方法。URL 定位，给资源的位置提供一种抽象的识别方法，并用这种方法给资源定位。只要能够对资源系统就可以对资源进行各种操作，如存取、更新、替换和查找其属性。由此可见，URL 实际上就是在互联网上的资源的地址。只有知道了这个资源在互联网上的什么地方，才能对它进行操作。显然，互联网上的所有资源，都有一个唯一确定的URL 。

这里所说的“资源”是指在互联网上可以被访问的任何对象，包括文件目录、文件、文档址和、图像、声音等，以及与互联网相连的任何形式的数据。URL 相当于一个文件名在网络范围的扩展。因此，URL是与互联网相连的机器上的任何可访问对象的一个指针。由于访问不同对象所使用的协议不同，所以URL还指出读取某个对象时所使用的协议。URL的一般形式由以下四个部分组成：

<协议>://<主机>:<端口>/<路径>

URL的第一部分是最左边的<协议>。这里的<协议>就是指出使用什么协议来获取该万维网文档。现在最常用的协议就是http(超文本传送协议HTTP )以及https(简单讲是HTTP的安全版)，其次是ftp(文件传送协议FTP)。在<协议>后面的://是规定的格式，: 也是固定格式。它的右边是第二部分<主机>，它指出这个万维网文档是在哪一台主机上。这里的<主机>就是指该主机在互联网上的域名。再后面是第三和第四部分<端口>和<路径>，有时可省略。
使用 HTTP 的 URL

对于万维网的网点的访问要使用HTTP协议。HTTP的URL的一般形式是：

http://<主机>:<端口>/<路径>

HTTP的默认端口号是80，通常可省略。若再省略文件的<路径>项，则URL就指到互联网上的某个主页(home page)。主页是个很重要的概念。

URL里面的字母不分大小写，但为了便于阅读，有时故意使用一些大写字母。

超文本传送协议 HTTP

HTTP的操作过程

HTTP 协议定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。从层次的角度看，HTTP是面向事务的(transaction-oriented)应用层协议，它是万维网上能够可靠地交换文件(包括文本、声音、图像等各种多媒体文件)的重要基础。请注意，HTTP不仅传送完成超文本跳转所必需的信息，而且也传送任何可从互联网上得到的信息，如文本、超文本、声音和图像等。

万维网的大致工作过程如下图所示：

HTTP使用了面向连接的TCP作为运输层协议，保证了数据的可靠传输。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，HTTP协议本身是无连接的。这就是说，虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。

HTTP协议是无状态的(stateless)。也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时的相同(假定现在服务器还没有把该页面更新)，因为服务器并不记得曾经访问过的这个客户，也不记得为该客户曾经服务过多少次。HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。
代理服务器

代理服务器(proxy server)是一种网络实体，它又称为万维网高速缓存(Web cache)。代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时，若代理服务器发现这个请求与暂时存放的请求相同，就返回暂存的响应，而不需要按URL的地址再次去互联网访问该资源。代理服务器可在客户端或服务器端工作，也可在中间系统上工作。

我们有时候需要清空浏览器缓存来刷新网络请求，也是因为我们现在用的浏览器也具有这个功能。如果服务器页面已更新，但是客户端请求到的页面没有改变，可能就需要清空一下缓存了。
HTTP的报文结构

HTTP有两类报文：
1. 请求报文——从客户向服务器发送请求报文，见下图(a)
2. 响应报文——从服务器到客户的回答，见图下图(b)
由于HTTP 是面向文本的((text-oriented)，因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。

HTTP请求报文和响应报文都是由三个部分组成的。可以看出，这两种报文格式的区别就是开始行不同。
1. 开始行，用于区分是请求报文还是响应报文。在请求报文中的开始行叫做请求行(Request-Line)，而在响应报文中的开始行叫做状态行(Status-Line)。在开始行的三个字段之间都以空格分隔开，最后的“CR”和“LF”分别代表“回车”和“换行”。
2. 首部行，用来说明浏览器、服务器或报文主体的一些信息。首部可以有好几行，但也可以不使用。在每一个首部行中都有首部字段名和它的值，每一行在结束的地方都要有“回车”和“换行”。整个首部行结束时，还有一空行将首部行和后面的实体主体分开。
3. 实体主体(entity body)，在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。
下面先介绍HTTP请求报文的一些主要特点。

请求报文的第一行“请求行”只有三个内容，即方法，请求资源的URL，以及HTTP的版本（有兴趣自行查阅）。

请注意：这里的名词**“方法”(method)是面向对象技术中使用的专门名词。所谓“方法”就是对所请求的对象进行的操作，这些方法实际上也就是一些命令**。因此，请求报文的类型是由它所采用的方法决定的。下表给出了请求报文中常用的几种方法。

下面是HTTP的请求报文的开始行(即请求行)的格式。请注意，在GET后面有一个空格，接着是某个完整的URL，其后面又有一个空格，最后是HTTP/ 1.1。

GET http://www.xvz.edu.cn/dir/index.htm HTTP/1.1

下面是一个完整的HTTP请求报文的例子：

在请求行使用了相对URL(即省略了主机的域名)是因为下面的首部行(第2行)给出了主机的域名。第3行是告诉服务器不使用持续连接，表示浏览器希望服务器在传送完所请求的对象后即关闭TCP连接。这个请求报文没有实体主体。

每一个请求报文发出后，都能收到一个响应报文。响应报文的第一行就是状态行。状态行包括三项内容，即HTTP的版本，状态码，以及解释状态码的简单短语。

**状态码(Status-Code)**都是三位数字的，分为5大类，原先有33种[RFC 2616],后来又增加了几种[RFC 6585]。这5大类的状态码都是以不同的数字开头的。
- 1xx 表示通知信息，如请求收到了或正在进行处理。
- 2xx 表示成功，如接受或知道了。
- 3xx 表示重定向，如要完成请求还必须采取进一步的行动。
- 4xx 表示客户的差错，如请求中有错误的语法或不能完成。
- 5xx 表示服务器的差错，如服务器失效无法完成请求。
在服务器上存放用户的信息

在RFC 6265中对Cookie进行了定义，规定万维网站点可以使用Cookie来跟踪用户。Cookie原意是“小甜饼”(广东人用方言音译为“曲奇”)，目前尚无标准译名，在这里Cookie表示为了辨别用户身份、进行 session 跟踪而储存在用户本地终端上的数据（通常经过加密）。现在很多网站都已广泛使用Cookie。

Cookie是这样工作的。当用户A浏览某个使用Cookie的网站时，该网站的服务器就为A产生一个唯一的识别码，并以此作为索引在服务器的后端数据库中产生一个项目。接着在给A的HTTP响应报文中添加一个叫做Set-cookie的首部行。这里的“首部字段名”就是"Set-cookie"，而后面的“值”就是赋予该用户的“识别码”。例如这个首部行是这样的：

Set-cookie:31d4d96e407aad42

当A收到这个响应时，其浏览器就在它管理的特定Cookie文件中添加一行，其中包括这个服务器的主机名和Set-cookie后面给出的识别码。当A继续浏览这个网站时，每发送一个HTTP请求报文，其浏览器就会从其Cookie文件中取出这个网站的识别码，并放到HTTP请求报文的Cookie首部行中：

Cookie:31d4d96e407aad42

于是，这个网站就能够跟踪用户31d4d96e407aad42(用户A)在该网站的活动。需要注意的是，服务器并不需要知道这个用户的真实姓名以及其他的信息。但服务器能够知道用户31d4d96e407aad42在什么时间访问了哪些页面，以及访问这些页面的顺序。如果A是在网上购物，那么这个服务器可以为A维护一个所购物品的列表，使A在结束这次购物时可以一起付费。

如果A在几天后再次访问这个网站，那么他的浏览器会在其HTTP请求报文中继续使用首部行Cookie:31d4d96e407aad42，而这个网站服务器根据他过去的访问记录可以向他推荐商品。这样，当A继续在该网站购物时，只要还使用同一个电脑上网，由于浏览器产生的HTTP请求报文中都携带了同样的Cookie首部行，服务器就可利用Cookie来验证出这是用户A，因此以后A在这个网站购物时就不必重新在键盘上输入姓名、信用卡号码等信息。这对顾客显然是很方便的。

万维网的文档

超文本标记语言HTML

由于 HTML 部分知识比较庞大，还涉及到 XML(可扩展标记语言) 、XHTML(可扩展超文本标记语言) 、CSS(层叠样式表) 等语言知识，请读者自行查阅相关知识，这里从略。
动态万维网文档

仅由前一小节多种语言组成的页面(Page)有一个特点，在被用户浏览的过程中，内容不会改变。由于这种文档的内容不会改变，因此用户对静态文档的每次读取所得到的返回结果都是相同的。这就是静态文档（比如404 页面）。

静态文档的最大优点是简单。由于HTML是一种排版语言，因此静态文档可以由不横程序设计的人员来创建。但静态文档的缺点是不够灵活。当信息变化时就要由文档的作者手工对文档进行修改。可见，变化频繁的文档不适于做成静态文档。

**动态文档(dynamic document)**是指文档的内容是在浏览器访问万维网服务器时才由应用程序动态创建的。当浏览器请求到达时，万维网服务器要运行另一个应用程序，并把控制转移到此应用程序。接着，该应用程序对浏览器发来的数据进行处理，并输出 HTTP 格式的文档，万维网服务器把应用程序的输出作为对浏览器的响应。由于对浏览器每次请求的响应都是临时生成的，因此用户通过动态文档所看到的内容是不断变化的。

动态文档的主要优点是具有报告当前最新信息的能力。例如，动态文档可用来报告股市行情、天气预报或民航售票情况等内容。但动态文档的创建难度比静态文档的高。因为动态文档的开发不是直接编写文档本身，而是编写用于生成文档的应用程序，这就要求动态文档的开发人员必须会编程，而所编写的程序还要通过大范围的测试，以保证输入的有效性。

从以上所述可以看出，要实现动态文档就必须在以下两个方面对万维网服务器的功能进行扩充：
1. 应增加另一个应用程序，用来处理浏览器发来的数据，并创建动态文档。
2. 应增加一个机制，用来使万维网服务器将浏览器发来的数据传送给这个应用程序，然后万维网服务器能够解释这个应用程序的输出。并向浏览器返回HTML文档。
是扩充了功能的万维网服务器的示意图。这里增加了一个机制，叫做通用网关接口CGI (Common Gateway Interface)。CGI是一种标准，它定义了动态文档应如何创建，输入数据应如何提供给应用程序，以及输出结果应如何使用。

在万维网服务器中新增加的应用程序叫做CGI程序。取这个名字的原因是:万维网服务器与CGI的通信遵循CGI标准。“通用”是因为这个标准所定义的规则对其他任何语言都是通用的。“网关”二字的出现是因为CGI程序还可能访问其他的服务器资源，如数据库或图形软件包，因而CGI程序的作用有点像一个网关。也有人将CGI程序简称为网关程序。“接口”是因为有一些己定义好的变量和调用等可供其他CGI程序使用。请读者注意：在看到CGI这个名词时，应弄清是指CGI标准，还是指CGI程序。

CGI程序的正式名字是CGI脚本(script)。按照计算机科学的一般概念，“脚本”指的是一个程序，它被另一个程序(解释程序)而不是计算机的处理机来解释或执行。有一些语言专门作为脚本语言(script language)，如Perl, REXX(在IBM主机上使用)，JavaScript以及TCIITk等。脚本也可用一些常用的编程语言写出，如C, C++等。使用脚本语言可更容易和更快地进行编码，这对一些有限功能的小程序是很合适的。但一个脚本运行起来比一般的编译程序要慢，因为它的每一条指令先要被另一个程序来处理(这就要一些附加的指令)，而不是直接被指令处理器来处理。脚本不一定是一个独立的程序，它可以是一个动态装入的库，甚至是服务器的一个子程序。
活动万维网文档

但随着HTTP和万维网浏览器的发展，上一节所述的动态文档也己明显地不能满足发展的需要。这是因为，动态文档一旦建立，它所包含的信息内容也就固定下来而无法及时刷新屏幕。另外，像动画之类的显示效果，动态文档也无法提供。

有两种技术可用于浏览器屏幕显示的连续更新：

一种技术称为服务器推送(serverpush)，这种技术是将所有的工作都交给服务器。服务器不断地运行与动态文档相关联的应用程序，定期更新信息，并发送更新过的文档，不过这很明显加重了网络的负担，用户体验也一般。

另一种提供屏幕连续更新的技术是活动文档(active document)。这种技术是把所有的工作都转移给浏览器端。每当浏览器请求一个活动文档时，服务器就返回一段活动文档程序副本，使该程序副本在浏览器端运行。这时，活动文档程序可与用户直接交互，并可连续地改变屏幕的显示。只要用户运行活动文档程序，活动文档的内容就可以连续地改变。由于活动文档技术不需要服务器的连续更新传送，对网络带宽的要求也不会太高。

现在我们所使用的网页基本上都是活动文档。大量的连续更新发生在本地，比如按钮变色，网页排版变化之类的，其实都在本地浏览器上完成。

动态主机配置协议 DHCP

为了把协议软件做成通用的和便于移植的，协议软件的编写者不会把所有的细节都固定在源代码中。相反，他们把协议软件参数化.这就使得在很多台计算机上有可能使用同一个经过编译的二进制代码。一台计算机和另一台计算机的许多区别，都可以通过一些不同的参数来体现。在协议软件运行之前，必须给每一个参数赋值。

在协议软件中给这些参数赋值的动作叫做协议配置。一个协议软件在使用之前必须是已正确配置的。因此，需要连接到互联网的计算机，必须对IP地址等项目进行协议配置。用人工进行协议配置很不方便，而且容易出错。因此，应当采用自动协议配置的方法。

互联网现在广泛使用的是动态主机配置协议DHCP (Dynamic Host ConfigurationProtocol)，它提供了一种机制，称为即插即用连网(plug-and-play networking)。这种机制允许一台计算机加入新的网络和获取IP地址而不用手工参与。DHCP最新的RFC文档是1997年的RFC 2131和RFC 2132，目前还是互联网草案标准。

DHCP很适合于经常移动位置的计算机。当计算机使用Windows操作系统时，点击“控制面板”的“网络”图标就可以找到某个连接中的“网络”下面的菜单，找到TCP/IP协议后点击其“属性”按钮，若选择“自动获得IP地址”和“自动获得DNS服务器地址”，就表示是使用DHCP协议。

简单网络管理协议 SNMP

虽然网络管理还没有精确定义，但它的内容可归纳为：

网络管理包括对硬件、软件和人力的使用、综合与协调，以便对网络资源进行监视、测试、配工、分析、评价和控制，这样就能以合理的价格满足网络的一些需求，如实时运行性能、服务质量等。网络管理常简称为网管。

简单网络管理协议（SNMP），由一组网络管理的标准组成，包含一个应用层协议（application layer protocol）、数据库模型（database schema）和一组资源对象。该协议能够支持网络管理系统，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。

在典型的SNMP用法中，有许多系统被管理，而且是有一或多个系统在管理它们。每一个被管理的系统上又运行一个叫做代理者（agent）的软件，且通过SNMP对管理系统报告资讯。

基本上，SNMP代理者以变量呈现管理资料。管理系统透过GET，GETNEXT和GETBULK协定指令取回资讯，或是代理者在没有被询问的情况下，使用TRAP或INFORM传送资料。管理系统也可以传送配置更新或控制的请求，透过SET协定指令达到主动管理系统的目的。配置和控制指令只有当网络基本结构需要改变的时候使用，而监控指令则通常是常态性的工作。

应用进程跨越网络的通信

在上文我们己经讨论了互联网使用的几种常用的应用层协议，这些应用协议使广大用户可以更加方便地利用互联网的资源。

现在的问题是：如果我们还有一些特定的应用需要互联网的支持，但这些应用又不能直接使用己经标准化的互联网应用协议，那么我们应当做哪些工作?

系统调用和应用编程接口

大多数操作系统使用系统调用(system call)的机制在应用程序和操作系统之间传递控制权。对程序员来说，系统调用和一般程序设计中的函数调用非常相似，只是系统调用是将控制权传递给了操作系统。下图说明了多个应用进程使用系统调用的机制。

本来想简单的介绍一下，发现不可行，这部分的知识涉及到操作系统的相关知识，这些知识实际上需要一门专门的课程来学习，简单的讲一下的话，看了也就过去了，价值太低。不过我之前看过鸟叔写的 [鸟哥的Linux私房菜-基础篇.第四版]，后面，我会把笔记整理成新的一个专栏，有兴趣的话可以来学习操作系统的知识，并且去了解另一个主流的操作系统 Linux。

结尾

哇，写了这么久，终于结束了，这个专栏可以说花费了我大量精力。我也知道自己不过是泛泛而谈，水平一般。但让人庆幸的一件事，那就是，我从写专栏的过程中，受益良多。谢谢你的阅读。