文章目录
应用层
域名系统DNS
域名系统概述
互联网的域名系统DNS被设计成为一个联机分布式数据库系统,并采用客户-服务器方式。DNS使大多数名字都在本地进行解析(resolve),仅少量解析需要在互联网上通信,因此DNS系统的效率很高。由于DNS是分布式系统,即使单个计算机出了故障,也不会妨碍整个DNS系统的正常运行。
域名到IP地址的解析是由分布在互联网上的许多域名服务器程序(可简称为域名服务器)共同完成的。域名服务器程序在专设的结点上运行,而人们也常把运行域名服务器程序的机器称为域名服务器。
域名到IP地址的解析过程的要点如下:当某一个应用进程需要把主机名解析为IP地址时,该应用进程就调用解析程序( resolver),并成为DNS的一个客户,把待解析的域名放在DNS请求报文中,以UDP用户数据报方式发给本地域名服务器(使用UDP是为了减少开销)。本地域名服务器在查找域名后,把对应的IP地址放在回答报文中返回。应用进程获得目的主机的IP地址后即可进行通信。
若本地域名服务器不能回答该请求,则此域名服务器就暂时成为DNS中的另一个客户,并向其他域名服务器发出査询请求。这种过程直至找到能够回答该请求的域名服务器为止。
互联网的域名结构
任何一个连接在互联网上的主机或路由器,都有一个唯一的层次结构的名字,即域名(domain name)。这里,“域(domain)”是名字空间中一个可被管理的划分。域还可以划分为子域,而子域还可以划分为子域的子域,这样就形成了顶级域,二级域,三级域等。
从语法上来讲,每一个域名都由标号(label)组成,各标号之间用点隔开:
DNS规定,域名中的标号都由英文字母和数字组成,每一个标号不超过63个字符(但为了记忆方便,最好不要超过12个字符),也不区分大小写字母(例如CCTV或cctv在域名中是等效的)。标号中除连字符(-)外不能使用其他的标点符号。级别最低的域名写在最左边,而级别最高的顶级域名则写在最右边。由多个标号组成的完整域名总共不超过255个字符。DNS既不规定一个域名需要包含多少个下级域名,也不规定每一级的域名代表什么意思。各级域名由其上一级的域名管理机构管理,而最高的顶级域名则由 ICANN进行管理。用这种方法可使每一个域名在整个互联网范围内是唯一的,并且也容易设计出一种查找域名的机制。
据2012年5月的统计[W-IANA-root],现在顶级域名TLD(Top Level Domain)已有326个。原先的顶级域名共分为三大类:
(1) 国家顶级域名nTLD:采用ISO 3166的规定。如:cn表示中国,us表示美国,uk表示英国,等等°。国家顶级域名又常记为cTLD(cc表示国家代码 country-code)。到2012年5月为止,国家顶级域名总数已达296个。
(2) 通用顶级域名gTLD:到2006年12月为止,通用顶级域名的总数已经达到20个。
最先确定的通用顶级域名有7个,即:com(公司企业),net(网络服务机构),org(非营利性组织),int(国际组织),edu(美国专用的教育机构),gov(美国的政府部门),ml表示(美国的军事部门)。
以后又陆续增加了13个通用顶级域名:aero(航空运输企业),asia(亚太地区),biz(公司和企业),cat(使用加泰隆人的语言和文化团体),coop(合作团体),info(各种情况),jobs(人力资源管理者),mobi(移动产品与服务的用户和提供者), museum(博物馆),name(个人),pro(有证书的专业人员),tel( Telnic股份有限公司), travel(旅游业)。
(3) 基础结构域名(infrastructure domain):这种顶级域名只有一个,即arpa,用于反向域名解析,因此又称为反向域名。
值得注意的是, ICANN于2011年6月20日在新加坡会议上正式批准新顶级域名(New gTLD),因此任何公司、机构都有权向 ICANN申请新的顶级域。新顶级域名的后缀特点,使企业域名具有了显著的、强烈的标志特征。因此,新顶级域名被认为是真正的企业网络商标。例如,商城、公司、新闻等。到2016年,在 ICANN注册的中文顶级域名已有60个[ W-IANA-ro0在国家顶级域名下注册的二级域名均由该国家自行确定。例如,顶级域名为jp的日本,将其教育和企业机构的二级域名定为ac和co,而不用edu和com。
我国把二级域名划分为“类别域名”和“行政区域名”两大类:
“类别域名” 共7个,分别为:ac(科研机构),com(工、商、金融等企业),edu(中国的教育机构),gov(中国的政府机构),mil(中国的国防机构),net(提供互联网络服务的机构),org(非营利性的组织)。
“行政区域名” 共34个,适用于我国的各省、自治区、直辖市。例如:bj(北京市),js(江苏省),等等。
域名服务器
上面讲述的域名体系是抽象的。但具体实现域名系统则是使用分布在各地的域名服务器。从理论上讲,可以让每一级的域名都有一个相对应的域名服务器,使所有的域名服务器构成和上图相对应的“域名服务器树”的结构。但这样做会使域名服务器的数量太多,从而使域名系统的运行效率降低。因此DNS就采用划分区的办法来解决这个问题。
一个服务器所负责管辖的(或有权限的)范围叫做区(zone)。各单位根据具体情况来划分自己管辖范围的区。但在一个区中的所有节点必须是能够连通的。每一个区设置相应的权限域名服务器(authoritative name server),用来保存该区中的所有主机的域名到IP地址的映射。总之,DNS服务器的管辖范围不是以“域”为单位,而是以“区”为单位。区是DNS服务器实际管辖的范围。区可能等于或小于域,但一定不能大于域。
下图是区的不同划分方法的举例。假定abc公司有下属部门x和y,部门x下面又分三个分部门u,v和w,而y下面还有其下属部门t。图(a)表示abc公司只设一个区abc.com。这时,区 abc.com和域 abc.com指的是同一件事。但图(b)表示abc公司划分了两个区(大的公司可能要划分多个区):abc.com和y.abc.com。这两个区都隶属于域abc. com,都各设置了相应的权限域名服务器。不难看出,区是“域”的子集。
下图以上图(b)中公司abc划分的两个区为例,给出了DNS域名服务器树状结构图。
这种DNS域名服务器树状结构图可以更准确地反映出DNS的分布式结构。在下图中的每个域名服务器都能够进行部分域名到IP地址的解析。当某个DNS服务器不能进行域名到IP地址的转换时,它就设法找互联网上别的域名服务器进行解析。
从上图可看出,互联网上的DNS域名服务器也是按照层次安排的。每一个域名服务器都只对域名体系中的一部分进行管辖。根据域名服务器所起的作用,可以把域名服务器划分为以下四种不同的类型:
(1) 根域名服务器(root name server)**:**根域名服务器是最高层次的域名服务器,也是最重要的域名服务器。所有的根域名服务器都知道所有的顶级域名服务器的域名和IP地址。根域名服务器是最重要的域名服务器,因为不管是哪一个本地域名服务器,若要对互联网上仼何一个域名进行解析(即转换为IP地址),只要自己无法解析,就首先要求助于根域名服务器。假定所有的根域名服务器都瘫痪了,那么整个互联网中的DNS系统就无法工作。
(2) 顶级域名服务器(即TLD服务器)**:**这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。当收到DNS查询请求时,就给出相应的回答(可能是最后的结果,也可能是下一步应当找的域名服务器的IP地址)。
(3) **权限域名服务器:**负责一个区的域名服务器,当一个权限域名服务器还不能给出最后的查询回答时,就会告诉查询请求的DNS客户,下一步应当找一个权限域名服务器。
(4) 本地域名服务器(local name server):本地域名服务器并不属于上图所展示的域名服务器层次结构,但它对域名系统非常重要。当一台主机发出DNS查询请求时,这个查询请求报文就首先发送给本地域名服务器。每一个互联网服务提供者ISP,或一个大学,甚至一个大学里的系,都拥有一个本地域名服务器,这种域名服务器有时也称为默认域名服务器。
为了提高域名服务器的可靠性,DNS域名服务器都把数据复制到几个域名服务器来保存,其中的一个是主域名服务器(master name server),其他的是辅助域名服务器(secondary name server)。当主域名服务器出故障时,辅助域名服务器可以保证DNS的査询工作不会中断。主域名服务器定期把数据复制到辅助域名服务器中,而更改数据只能在主域名服务器中进行。这样就保证了数据的一致性。
下面简单讨论一下域名的解析过程,这里要注意两点:
第一、主机向本地域名服务器的查询一般都是采用递归查询(recursive query)。所谓递归查询就是:如果主机所询问的本地域名服务器不知道被查询域名的IP地址,那么本地域名服务器就以DNS客户的身份,向其他根域名服务器继续发出査询请求报文(即替该主机继续查询),而不是让该主机自己进行下一步的查询。因此,递归查询返回的查询结果或者是所要查询的IP地址,或者是报错,表示无法查询到所需的IP地址。
第二、本地域名服务器向根域名服务器的查询通常是采用迭代查询(iterative query)。迭代查询的特点是这样的:当根域名服务器收到本地域名服务器发出的迭代查询请求报文时要么给出所要查询的IP地址,要么告诉本地域名服务器:“你下一步应当向哪一个域名服务器进行查询”。然后让本地域名服务器进行后续的查询(而不是替本地域名服务器进行后续的查询)。根域名服务器通常是把自己知道的顶级域名服务器的IP地址告诉本地域名服务器,让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后,要么给出所要查询的IP地址,要么告诉本地域名服务器下一步应当向哪一个权限域名服务器进行查询,本地域名服务器就这样进行迭代查询。最后,知道了所要解析的域名的IP地址,然后把这个结果返回给发起查询的主机。当然,本地域名服务器也可以采用递归查询,这取决于最初的查询请求报文的设置是要求使用哪一种查询方式。
下面通过一个例子说明这两种查询的区别:
假定域名为m.xyz.com的主机想知道另一台主机(域名为y.abc.com)的IP地址。例如,主机m.xyz.com打算发送邮件给主机y.abc:com。这时就必须知道主机y.abc.com的IP地址。下面是下图(a)的几个查询步骤:
❶ 主机mxyZ.com先向其本地域名服务器dns.xyz.com进行递归查询
❷ 本地域名服务器采用迭代查询。它先向一个根域名服务器查询。
❸ 根域名服务器告诉本地域名服务器,下一次应查询的顶级域名服务器 dns.com的IP地址
❹ 本地域名服务器向顶级域名服务器 dns.com进行查询。
❺ 顶级域名服务器 dns.com告诉本地域名服务器,下一次应查询的权限域名服务器dns.abc.com的IP地址。
❻ 本地域名服务器向权限域名服务器 dns. abc. com进行查询。
❼ 权限域名服务器 dns.abc.com告诉本地域名服务器,所查询的主机的IP地址。
❽ 本地域名服务器最后把查询结果告诉主机m.xyz.com。
我们注意到,这8个步骤总共要使用8个UDP用户数据报的报文。本地域名服务器经过三次迭代查询后,从权限域名服务器dnsabc.com得到了主机y.abc.com的IP地址,最后把结果返回给发起查询的主机 m.xyz.com上图(b)是本地域名服务器采用递归查询的情况。在这种情况下,本地域名服务器只需向根域名服务器查询一次,后面的几次查询都是在其他几个域名服务器之间进行的(步骤❸至❻)。只是在步骤❼,本地域名服务器从根域名服务器得到了所需的IP地址。最后在步骤❽,本地域名服务器把查询结果告诉主机m.xyz.com。整个的查询也是使用8个UDP报文。
为了提高DNS查询效率,并减轻根域名服务器的负荷和减少互联网上的DNS查询报文数量,在域名服务器中广泛地使用了高速缓存(有时也称为高速缓存域名服务器)。高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录。
例如,在上图(a)的查询过程中,如果在不久前己经有用户查询过域名为y.abc.com的IP地址,那么本地域名服务器就不必向根域名服务器重新查询y.abc.com的IP地址,而是直接把高速缓存中存放的上次查询结果(即y.abc.com的IP地址)告诉用户。
文件传送协议
FTP概述
文件传送协议FTP(File Transfer Protocol)[RFC 959]是互联网上使用得最广泛的文件传送协议。FTP提供交互式的访问,允许客户指明文件的类型与格式(如指明是否使用 ASCII码),并允许文件具有存取权限(如访问文件的用户必须经过授权,并输入有效的口令)。FTP屏蔽了各计算机系统的细节,因而适合于在异构网络中任意计算机之间传送文件。RFC 959很早就成为了互联网的正式标准。
在互联网发展的早期阶段,用FTP传送文件约占整个互联网的通信量的三分之一,而由电子邮件和域名系统所产生的通信量还小于FTP所产生的通信量。只是到了1995年,www的通信量才首次超过了FTP。
下面分别介绍基于TCP的FTP和基于UDP的简单文件传送协议TFTP,它们都是文件共享协议中的一大类,即复制整个文件,其特点是:若要存取一个文件,就必须先获得一个本地的文件副本。如果要修改文件,只能对文件的副本进行修改,然后再将修改后的文件副本传回到原节点。
文件共享协议中的另一大类是联机访问(on- line access),联机访问意味着允许多个程序同时对一个文件进行存取。和数据库系统的不同之处是用户不需要调用一个特殊的客户进程,而是由操作系统提供对远地共享文件进行访问的服务,就如同对本地文件的访问一样。这就使用户可以用远地文件作为输入和输出来运行任何应用程序,而操作系统中的文件系统则提供对共享文件的透明存取。透明存取的优点是:将原来用于处理本地文件的应用程序用来处理远地文件时,不需要对该应用程序作明显的改动。属于文件共享协议的有网络文件系统NFS(Network File System)[COME06]。
FTP的基本工作原理
网络环境中的一项基本应用就是将文件从一台计算机中复制到另一台可能相距很远的计算机中。初看起来,在两台主机之间传送文件是很简单的事情。其实这往往非常困难。原因是众多的计算机厂商研制出的文件系统多达数百种,且差别很大。经常遇到的问题是:
(1) 计算机存储数据的格式不同。
(2) 文件的目录结构和文件命名的规定不同。
(3) 对于相同的文件存取功能,操作系统使用的命令不同。
(4) 访问控制方法不同。
文件传送协议FTP只提供文件传送的一些基本的服务,它使用TCP可靠的运输服务。FTP的主要功能是减少或消除在不同操作系统下处理文件的不兼容性。
FTP使用客户服务器方式。一个FTP服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成:一个主进程,负责接受新的请求;另外有若干个从属进程,负责处理单个请求。
主进程的工作步骤如下:
(1) 打开熟知端口(端口号为21),使客户进程能够连接上。
(2) 等待客户进程发出连接请求。
(3) 启动从属进程处理客户进程发来的请求。从属进程对客户进程的请求处理完毕后即终止,但从属进程在运行期间根据需要还可能创建其他一些子进程。
(4) 回到等待状态,继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发进行的。
FTP的工作情况如下图所示。图中的椭圆圈表示在系统中运行的进程。图中的服务器端有两个从属进程:控制进程和数据传送进程。为简单起见,服务器端的主进程没有画上。
客户端除了控制进程和数据传送进程外,还有一个用户界面进程用来和用户接口在进行文件传输时,FTP的客户和服务器之间要建立两个并行的TCP连接:“控制连接”和“数据连接”。控制连接在整个会话期间一直保持打开,FTP客户所发出的传送请求,通过控制连接发送给服务器端的控制进程,但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”,用于连接客户端和服务器端的数据传送进程。数据传送进程实际完成文件的传送,在传送完毕后关闭“数据传送连接”并结束运行。由于FTP使用了一个分离的控制连接,因此FTP的控制信息是带外(out of band)传送的。
FTP并非对所有的数据传输都是最佳的。例如,计算机A上运行的应用程序要在远地计算机B的一个很大的文件末尾添加一行信息。若使用FTP,则应先将此文件从计算机B传送到计算机A,添加上这一行信息后,再用FTP将此文件传送到计算机B,来回传送这样大的文件很花时间。实际上这种传送是不必要的,因为计算机A并没有使用该文件的内容。
然而,网络文件系统NFS则采用另一种思路。NFS允许应用进程打开一个远地文件,并能在该文件的某一个特定的位置上开始读写数据。这样,NFS可使用户只复制一个大文件中的一个很小的片段,而不需要复制整个大文件。对于上述例子,计算机A中的NFS客户软件,把要添加的数据和在文件后面写数据的请求一起发送到远地的计算机B中的NFS服务器,NFS服务器更新文件后返回应答信息。在网络上传送的只是少量的修改数据。
简单文件传送协议TFTP
远程终端协议TELNET
TELNET是一个简单的远程终端协议[RFC 854],它也是互联网的正式标准。用户用TELNET就可在其所在地通过TCP连接注册(即登录)到远地的另一台主机上(使用主机名或IP地址)。 TELNET能将用户的击键传到远地主机,同时也能将远地主机的输出通过TCP连接返回到用户屏幕。这种服务是透明的,因为用户感觉到好像键盘和显示器是直接连在远地主机上。因此, TELNET又称为终端仿真协议。
TELNET并不复杂,以前应用得很多。现在由于计算机的功能越来越强,用户已较少使用TELNET了。
TELNET也使用客户服务器方式。在本地系统运行 TELNET客户进程,而在远地主机则运行 TELNET服务器进程。和FTP的情况相似,服务器中的主进程等待新的请求,并产生从属进程来处理每一个连接。
TELNET能够适应许多计算机和操作系统的差异。例如,对于文本中一行的结束,有的系统使用ASCII码的回车(CR),有的系统使用换LF),还有的系统使用两个字符,回车-换行(CRLF)。又如,在中断一个程序时,许多系统使用 Control-C(^C),但也有系统使用ESC按键。为了适应这种差异, TELNET定义了数据和命令应怎样通过互联网。这些定义就是所谓的网络虚拟终端NVT(Network Virtual Terminal)。
下图说明了NVT的意义:
客户软件把用户的击键和命令转换成NVT格式,并送交服务器。服务器软件把收到的数据和命令从NVT格式转换成远地系统所需的格式。向用户返回数据时,服务器把远地系统的格式转换为NVT格式,本地客户再从NVT格式转换到本地系统所需的格式。
NVT的格式定义很简单。所有的通信都使用8位一个字节。在运转时,NVT使用7位,ASCII码传送数据,而当高位置1时用作控制命令。ASCII码共有95个可打印字符(如字母、数字、标点符号)和33个控制字符。所有可打印字符在NVT中的意义和在ASCI码中一样。但NVT只使用了ASCI码的控制字符中的几个。此外,NvT还定义了两字符的CRLF为标准的行结束控制符。当用户键入回车按键时, TELNET的客户就把它转换为CRLF再进行传输,而 TELNET服务器要把CRLF转换为远地机器的行结束字符。
TELNET的选项协商(Option Negotiation)使 TELNET客户和 TELNET服务器可商定使用更多的终端功能,协商的双方是平等的。
超文本传送协议HTTP
HTTP的操作过程
HTTP协议定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档,以及服务器怎样把文档传送给浏览器。从层次的角度看,HTTP是面向事务的(transaction-oriented)应用层协议,它是万维网上能够可靠地交换文件(包括文本、声音、图像等各种媒体文件)的重要基础。请注意,HTTP不仅传送完成超文本跳转所必需的信息,而且也传送任何可从互联网上得到 的信息,如文本,超文本,声音和图像等。
万维网的大致工作过程如下图所示:
每个万维网网点都有一个服务器进程,它不断地监听TCP的端口80,以便发现是否有浏览器向它发出连接建立请求。(HTTP是应用层协议,底层的运输层采用TCP协议)。
一旦监听到连接建立请求并建立了TCP连接之后,浏览器就向万维网服务器发出浏览某个页面的请求,服务器接着就返回所请求的页面作为响应。最后,TCP连接就被释放了。在浏览器和服务器之间的请求和响应的交互,必须按照规定的格式和遵循一定的规则。这些格式和规则就是超文本传送协HTTP。
HTTP规定在HTTP客户与HTTP服务器之间的每次交互,都由一个ASCII码串构成的请求和一个类似的通用互联网扩充,即“类MME(MIME-like)”的响应组成。HTTP报文通常都使用TCP连接传送。
HTTP使用了面向连接的TCP作为运输层协议,保证了数据的可靠传输。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是,HTTP协议本身是无连接的。这就是说,虽然HTTP使用了TCP连接,但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。在1997年以前使用的是RFC1945定义的HTTP/1.0协议。现在普遍使用的升级版本HTTP/1.1已是互联网建议标准[RFC7231]。
HTTP协议是无状态的(stateless)。也就是说,同一个客户第二次访问同一个服务器上的页面时,服务器的响应与第一次被访问时的相同(假定现在服务器还没有把该页面更新),因为服务器并不记得曾经访问过的这个客户,也不记得为该客户曾经服务过多少次。HTTP的无状态特性简化了服务器的设计,使服务器更容易支持大量并发的HTTP请求。
下面我们粗略估算一下,从游览器请求一个万维网文档到收到整个文档所需的时间。HTTP协议首先要和服务器建立TCP连接。这需要使用三次握手。当建立TCP连接的三报文握手的前两部分完成后(即经过了一个RTT时间后),万维网就把HTTP请求报文,作为建立TCP连接的三报文握手中的第三个报文的数据,发送给万维网服务器。服务器受到HTTP请求报文后,就把所请求的文档作为响应报文返回给客户。
从上图可看出,请求一个万维网文档所需的时间是该文档的传输时间(与文档大小成正比)加上两倍往返时间RTT(一个RTT用于连接TCP连接,另一个RTT用于请求和接收万维网文档。TCP建立连接的三报文握手的第三个报文段中的数据,,就是客户对万维网文档的请求报文)。
HTTP/1.0的主要缺点,就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象(如图片等)需要依次进行链接,那么每一次链接下载都导致2 × RTT的开销。另一种开销就是万维网客户和服务器每一次建立新的TCP连接都要分配缓存和变量。
特别是万维网服务器往往要同时服务于大量客户的请求,所以这种非持续连接会使万维网服务器的负担很重。好在浏览器都能够打开5~10个并行的TCP连接,而每一个TCP连接处理客户的一个请求。因此,使用并行TCP连接可以缩短响应时间。
HTTP/ 1.1协议较好地解决了这个问题,它使用了持续连接(persistent connection)。所谓持续连接就是万维网服务器在发送响应后仍然在一段时间内保持这条连接,使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。这并不局限于传送同一个页面上链接的文档,而是只要这些文档都在同一个服务器上就行。目前些流行的浏览器(如I11.0)的默认设置就使用了HTTP/1.1。
HTTP/1.1协议的持续连接有两种工作方式,即非流水线方式(without pipelining)和流水线方式(with pipelining)。
非流水线方式的特点,是客户在收到前一个响应后才能发出下一个请求。因此,在TCP连接已建立后,客户每访问一次对象都要用去一个往返时间RTT。这比非持续连接要用去两倍RTT的开销,节省了建立TCP连接所需的一个RTT时间。但非流水线方式还是有缺点的,因为服务器在发送完一个对象后,其TCP连接就处于空闲状态,浪费了服务器资源。
流水线方式的特点,是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文。于是一个接一个的请求报文到达服务器后,服务器就可连续发回响应报文。因此,使用流水方式时,客户访问所有的对象只需一个RTT时间。流水线工作方式使TCP连接中的空闲时间减少,提高了下载文档效率。
代理服务器
代理服务器(proxy server)是一种网络实体,它又称为万维网高速缓存(Web cache)。代理服务器把最近的一些请求和响应暂存在本地磁盘中。当新请求到达时,若代理服务器发现这个请求与暂时存放的请求相同,就返回暂存的响应,而不需要按URL的地址再次去互联网访问该资源。代理服务器可在客户端或服务器端工作,也可在中间系统上工作。
下面我们通过一个例子说明它的作用:
设下图(a)是校园网不使用代理服务器的情况。这时,校园网中所有的计算机都通过2Mbit/s专线链路(R1-R2)与互联网上的源点服务器建立TCP连接。因而校园网各计算机访问互联网的通信量往往会使这条2 Mbit/s的链路过载,使得时延大大增加。
下图(b)是校园网使用代理服务器的情况。这时,访问互联网的过程是这样的:
(1) 校园网的计算机中的浏览器向互联网的服务器请求服务时,就先和校园网的代理服务器建立TCP连接,并向代理服务器发出HTTP请求报文(见下图(b)中的❶)。
(2) 若代理服务器已经存放了所请求的对象,代理服务器就把这个对象放入HTTP响应报文中返回给计算机的浏览器。
(3) 否则,代理服务器就代表发出请求的用户浏览器,与互联网上的源点服务器(origin sever)建立TCP连接(如下图(b)中的❷所示),并发送HTTP请求报文。
(4) 源点服务器把所请求的对象放在HTP响应报文中返回给校园网的代理服务器。
(5) 代理服务器收到这个对象后,先复制在自己的本地存储器中(留待以后用),然后再把这个对象放在HTTP响应报文中,通过已建立的TCP连接(见上图(b)中的❶),返回给请求该对象的游览器。
我们注意到,代理服务器有时是作为服务器(当接受浏览器的HTTP请求时),但有时却作为客户(当向互联网上的源点服务器发送HTTP请求时)。
HTTP的报文结构
HTTP有两类报文:
- 请求报文——从客户向服务器发送请求报文,见下图(a)。
- 响应报文——从服务器到客户的回答,见下图(b)。
由于HTTP是面向文本的(text-oriented),因此在报文中的每一个字段都是一些ASCI码串,因而各个字段的长度都是不确定的。
HTTP请求报文和响应报文都是由三个部分组成的。可以看出,这两种报文格式的区别就是开始行不同:
(1) 开始行,用于区分是请求报文还是响应报文。在请求报文中的开始行叫做请求(Request-Line),而在响应报文中的开始行叫做状态行(Status-Line)。在开始行的三个字段之间都以空格分隔开,最后的“CR”和“LF”分别代表“回车”和“换行”。
(2) 首部行,用来说明浏览器、服务器或报文主体的一些信息。首部可以有好几行,但也可以不使用。在每一个首部行中都有首部字段名和它的值,每一行在结束的地方都要有“回车”和“换行”。整个首部行结束时,还有一空行将首部行和后面的实体主体分开。
(3) 实体主体(entity body),在请求报文中一般都不用这个字段,而在响应报文中也可能没有这个字段。
下图给出了HTTP请求报文中常用的几种方法:
HTTP状态码都是有三位数字的。分为5大类,原来有33种[RFC 2616],后来又增加到了几种[RFC 6585]。这5大类的状态码是以不同的数字开头的。
在服务器上存放用户的信息
Cookie是这样工作的:当用户A浏览某个使用 Cookie的网站时,该网站的服务器就为A产生一个唯一的识别码,并以此作为索引在服务器的后端数据库中产生一个项目。接着在给A的HTP响应报文中添加一个叫做 Set-cookie的首部行。这里的“首部字段名”就是Set-cookie”,而后面的“值”就是赋予该用户的“识别码”。例如这个首部行是这样的:
Set-cookie: 31d4d96e407aad42
当A收到这个响应时,其浏览器就在它管理的特定 Cookie文件中添加一行,其中包括这个服务器的主机名和 Set-cookie后面给出的识别码。当A继续浏览这个网站时,每发送一个HTTP请求报文,其浏览器就会从其Cookie文件中取出这个网站的识别码,并放到HTTP请求报文的Cookie首部行中:
Cookie: 31d4d96e407aad42
于是,这个网站就能够跟踪用户31d4d96e407aad42(用户A)在该网站的活动。需要注意的是,服务器并不需要知道这个用户的真实姓名以及其他的信息。但服务器能够知道用户31d4d96e407aa42在什么时间访问了哪些页面,以及访问这些页面的顺序。如果A是在网上购物,那么这个服务器可以为A维护一个所购物品的列表,使A在结束这次购物时可以一起付费。
如果A在几天后再次访问这个网站,那么他的浏览器会在其HTTP请求报文中继续使用首部行Cookie:31d4a96e407aad42,而这个网站服务器根据A过去的访问记录可以向他推荐商品(根据cookie中携带的sessionid就可以在服务器中查找到相应的对话Session)。如果A已经在该网站登记过和使用过信用卡付费,那么这个网站就已经保存了A的姓名、电子邮件地址、信用卡号码等信息(Session数据保存在服务器上)。这样,当A继续在该网站购物时,只要还使用同一个电脑上网,由于浏览器产生的HTTP请求报文中都携带了同样的Cookie首部行,服务器就可利用Cookie来验证出这是用户A,因此以后A在这个网站购物时就不必重新在键盘上输入姓名、信用卡号码等信息。这对顾客来说显然是很方便的。
电子邮件
简单邮件传输协议SMTP
SMTP规定了在两个相互通信的SMTP进程之间应如何交换信息。由于SMTP使用客户服务器方式,因此负责发送邮件的SMTP进程就是SMTP客户,而负责接收邮件的SMTP进程就是SMTP服务器。至于邮件内部的格式,邮件如何存储,以及邮件系统应以多快的速度来发送邮件,SMTP也都未做出规定。
SMTP规定了14条命令和21种应答信息。每条命令用几个字母组成,而每一种应答信息一般只有一行信息,由一个3位数字的代码开始,后面附上(也可不附上)很简单的文字说明。下面通过发送方和接收方的邮件服务器之间的SMTP通信的三个阶段介绍几个最主要的命令和响应信息。
连接建立
发件人的邮件送到发送方邮件服务器的邮件缓存后,SMTP客户就每隔一定时间(例如30分钟)对邮件缓存扫描一次。如发现有邮件,就使用SMTP的熟知端口号码25与接收方邮件服务器的SMTP服务器建立TCP连接。在连接建立后,接收方SMTP服务器要发出220 Service ready”(服务就绪)。然后SMTP客户向SMTP服务器发送HELO命令,附上发送方的主机名。SMIP服务器若有能力接收邮件,则回答:“250OK”,表示已准备好接收。若SMTP服务器不可用,则回答“421 Service not available”(服务不可用)。
如在一定时间内(例如三天)发送不了邮件,邮件服务器会把这个情况通知发件人。
SMTP不使用中间的邮件服务器。不管发送方和接收方的邮件服务器相隔有多远,不管在邮件传送过程中要经过多少个路由器,TCP连接总是在发送方和接收方这两个邮件服务器之间直接建立。当接收方邮件服务器出故障而不能工作时,发送方邮件服务器只能等待一段时间后再尝试和该邮件服务器建立TCP连接,而不能先找一个中间的邮件服务器建立TCP连接。
- 邮件传送
- 连接释放
SMTP传送的协议是明文,不利于保密。
邮件读取协议POP3和IMAP
现在常用的邮件读取协议有两个,即邮局协议第3个版本POP3和网际报文存取协议IMAP(Internet Message Access Protocol)。现分别讨论如下:
邮局协议POP是一个非常简单、但功能有限的邮件读取协议。经过几次更新,现在使用的是1996年的版本POP3[RFC 1939],它已成为互联网的正式标准,大多数的ISP都支持POP3协议。
POP3也使用客户服务器的工作方式。在接收邮件的用户计算机中的用户代理必须运行POP3客户程序,而在收件人所连接的ISP的邮件服务器中则运行POP3服务器程序。当然,这个ISP的邮件服务器还必须运行SMTP服务器程序,以便接收发送方邮件服务器的SMTP客户程序发来的邮件。POP3服务器只有在用户输入鉴别信息(用户名和口令)后,才允许对邮箱进行读取。
POP3协议的一个特点就是只要用户从POP3服务器读取了邮件,POP3服务器就把该邮件删除。这在某些情况下就不够方便。例如,某用户在办公室的台式计算机上接收了一个邮件,还来不及写回信,就马上携带笔记本电脑出差。当他打开笔记本电脑写回信时,POP3服务器上却已经删除了原来已经看过的邮件(除非他事先将这些邮件复制到笔记本电脑中)。为了解决这一问题,POP3进行了一些功能扩充,其中包括让用户能够事先设置邮件读取后仍然在POP3服务器中存放的时间[RFC2449]。目前RFC2449是互联网建议标准。
另一个读取邮件的协议是网际报文存取协议IMAP,它比POP3复杂得多。IMAP和POP都按客户服务器方式工作,但它们有很大的差别。现在较新的版本是2003年3月修订的版本4,即MAP4[RFC3501],它目前也是互联网的建议标准。不过在习惯上,对这个协议大家很少加上版本号“4”,而经常简单地用IMAP表示IMAP4。但是对POP3却不会忘记写上版本号“3”。
在使用IMAP时,在用户的计算机上运行IMAP客户程序,然后与接收方的邮件服务器上的IMAP服务器程序建立TCP连接。用户在自己的计算机上就可以操纵邮件服务器的邮箱,就像在本地操纵一样,因此IMAP是一个联机协议。当用户计算机上的IMAP客户程序打开IMAP服务器的邮箱时,用户就可看到邮件的首部。若用户需要打开某个邮件,则该邮件才传到用户的计算机上。用户可以根据需要为自己的邮箱创建便于分类管理的层次式的邮箱文件夹,并且能够将存放的邮件从某一个文件夹中移动到另一个文件夹中。用户也可按某种条件对邮件进行查找。在用户未发出删除邮件的命令之前,IMAP服务器邮箱中的邮件直保存着。
IMAP最大的好处就是用户可以在不同的地方使用不同的计算机(例如,使用办公室的计算机、或家中的计算机,或在外地使用笔记本电脑)随时上网阅读和处理自己在邮件服务器中的邮件。IMAP还允许收件人只读取邮件中的某一个部分。例如,收到了一个带有视像附件(此文件可能很大)的邮件,而用户使用的是无线上网,信道的传输速率很低。为了节省时间,可以先下载邮件的正文部分,待以后有时间再读取或下载这个很大的附件。
IMAP的缺点是如果用户没有将邮件复制到自己的计算机上,则邮件一直存放在IMAP服务器上。要想查阅自己的邮件,必须先上网。
下表给出了IMAP和POP3的主要功能的比较:
最后再强调一下,不要把邮件读取协议POP3或IMAP与邮件传送协议SMTP弄混。发件人的用户代理向发送方邮件服务器发送邮件,以及发送方邮件服务器向接收方邮件服务器发送邮件,都是使用SMTP协议。而POP3或MAP则是用户代理从接收方邮件服务器上读取邮件所使用的协议。
通用互联网邮件扩充MIME
MIME概述
前面所述的电子邮件协议SMTP有以下缺点:
(1) SMTP不能传送可执行文件或其他的二进制对象。人们曾试图将二进制文件转换为
SMTP使用的ASCI文本,例如流行的 UNIX UUencode/ UUdecode方案,但这些均未形成正式标准或事实上的标准。
(2) SMTP限于传送7位的ASCⅡ码。许多其他非英语国家的文字(如中文、俄文,甚至带重音符号的法文或德文)就无法传送。即使在SMTP网关将 EBCDIC码(即扩充的十进制交换码)转换为ASCI码,也会遇到一些麻烦。
(3) SMTP服务器会拒绝超过一定长度的邮件。
(4) 某些SMTP的实现并没有完全按照SMTP的互联网标准。常见的问题如下:
- 车、换行的删除和增加;
- 超过76个字符时的处理:截断或自动换行;
- 后面多余空格的删除;
- 将制表符tab转换为若干个空格。
于是在这种情况下就提出了通用互联网邮件扩充MIME[RFC2045~2049]。MIME并没有改动或取代SMTP。MIME的意图是继续使用原来的邮件格式,但增加了邮件主体的结构,并定义了传送非ASCII码的编码规则。也就是说,MME邮件可在现有的电子邮件程序和协议下传送。
下图表示了MIME和SMTP的关系:
MIME主要包括以下三部分内容:
(1) 5个新的邮件首部字段,它们可包含在原来的邮件首部中。这些字段提供了有关邮件主体的信息。
(2) 定义了许多邮件内容的格式,对多媒体电子邮件的表示方法进行了标准化。
(3) 定义了传送编码,可对任何内容格式进行转换,而不会被邮件系统改变。
为适应于任意数据类型和表示,每个MME报文包含告知收件人数据类型和使用编码的信息。MME把增加的信息加入到原来的邮件首部中。
下面是MIME增加的5个新的邮件首部的名称及其意义(有的可以是选项)。
(1) MIME- Version:标志MME的版本。现在的版本号是1.0。若无此行,则为英文文本
(2) Content-Description:这是可读字符串,说明此邮件主体是否是图像、音频或视频。
(3) Content-Id:邮件的唯一标识符。
(4) Content- Transfer- Encoding:在传送时邮件的主体是如何编码的
(5) Content—Type:说明邮件主体的数据类型和子类型。
上述的前三项的意思很清楚,因此下面只对后两项进行介绍。
内容传送编码
下面介绍三种常用的内容传送编码(Content-Transfer-Encoding)
最简单的编码就是7位ASCII码,而每行不能超过100个字符。MIME对这种由ASCII码构成的邮件主体不进行任何转换。
另一种编码称为quoted-printable,这种编码方法适用于所传送的数据中只有少量的非ASCII码,例如汉字。这种编码方法的要点就是对于所有可打印的ASCII码,除特殊字符等号“=”外,都不改变。等号“=”和不可打印的ASCII码以及非ASCII码的数据的编码方法是:先将每个字节的二进制代码用两个十六进制数字表示,然后在前面再加上一个等号“=”。例如,汉字的“系统”的二进制编码是:110011101101011100110110110011(共有32位,但这四个字节都不是ASCII码),其十六进制表示为: CFBSCDB3。用quoted-printable编码则表示为:=CF=B5=CD=B3,这12个字符都是可打印的ASCII字符,它们的二进制编码需要96位,和原来的32位相比,开销达200%!而等号“=”的二进制代码为001111,即十六进制的3D,因此等号“=”的 quoted-printable编码为“=3D”。
对于任意的二进制文件,可用base64编码。这种编码方法是先把二进制代码划分为一个个24位长的单元,然后把每一个24位单元划分为4个6位组。每一个6位组按以下方法转换成ASCⅡ码。6位的二进制代码共有64种不同的值,从0到63。用A表示0,用B表示1,等等。26个大写字母排列完毕后,接下去再排26个小写字母,再后面是10个数字,最后用“+”表示62,而用“/”表示63。再用两个连在一起的等号“=”和一个等号“=”分别表示最后一组的代码只有8位或16位。回车和换行都忽略,它们可在任何地方。
内容类型
MIME标准规定 Content-Type说明必须含有两个标识符,即内容类型(type)和子类型(subtype),中间用“/”分开。
MIME标准原先定义了7个基本内容类型和15种子类型(见RFC1521,但这个文档已被列入“陈旧的”)。除了内容类型和子类型,MIME允许发件人和收件人自己定义专用的内容类型。但为避免可能出现名字冲突,标准要求为专用的内容类型选择的名字要以字符串X-开始。但是,后来陆续出现了几百个子类型,而且子类型的数目还在不断地增加。现在可以在网站上查出现有的MIME类型和子类型的名称,以及申请新的子类型的具体步骤[WMEDIA-TYPE]。
下表列出了MME的内容类型、子类型举例及其说明:
MIME的内容类型中的 multipart是很有用的,因为它使邮件增加了相当大的灵活性MIME标准为 multipart定义了四种可能的子类型,每个子类型都提供重要功能。
(1) mixed子类型允许单个报文含有多个相互独立的子报文,每个子报文可有自己的类型和编码。mied子类型报文使用户能够在单个报文中附上文本、图形和声音,或者用额外数据段发送一个备忘录,类似商业信笺含有的附件。在 mixed后面还要用到一个关键字,即Boundary=,此关键字定义了分隔报文各部分所用的字符串(由邮件系统定义),只要在邮件的内容中不会出现这样的字符串即可。当某一行以两个连字符“-”开始,后面紧跟上述的字符串,就表示下面开始了另一个子报文。
(2) alternative子类型允许单个报文含有同一数据的多种表示。当给多个使用不同硬件和软件系统的收件人发送备忘录时,这种类型的 multipart报文很有用。例如,用户可同时用普通的ASCII文本和格式化的形式发送文本,从而允许拥有图形功能的计算机用户在查看图形时选择格式化的形式。
(3) parallel子类型允许单个报文含有可同时显示的各个子部分(例如,图像和声音子部分必须一起播放)。
(4) digest子类型允许单个报文含有一组其他报文(如从讨论中收集电子邮件报文)。
动态主机配置协议DHCP
为了把协议软件做成通用的和便于移植的,协议软件的编写者不会把所有的细节都固定在源代码中。相反,他们把协议软件参数化。这就使得在很多台计算机上有可能使用同个经过编译的二进制代码。一台计算机和另一台计算机的许多区别,都可以通过一些不同的参数来体现。在协议软件运行之前,必须给每一个参数赋值在协议软件中给这些参数赋值的动作叫做协议配置。一个协议软件在使用之前必须是已正确配置的。具体的配置信息有哪些则取决于协议栈。例如,连接到互联网的计算机的协议软件需要配置的项目包括:
(1) IP地址;
(2) 子网掩码
(3) 默认路由器的IP地址
(4) 域名服务器的IP地址
为了省去给计算机配置IP地址的麻烦,我们能否在计算机的生产过程中,事先给每台计算机配置好一个唯一的IP地址呢(如同每一个以太网适配器拥有一个唯一的硬件地址)?
这显然是不行的。这是因为IP地址不仅包括了主机号,而且还包括了网络号。一个IP地址指出了一台计算机连接在哪一个网络上。当计算机还在生产时,无法知道它在出厂后将被连接到哪一个网络上。因此,需要连接到互联网的计算机,必须对IP地址等项目进行协议配置。
用人工进行协议配置很不方便,而且容易出错。因此,应当采用自动协议配置的方法。
互联网现在广泛使用的是动态主机配置协议DHCP(Dynamic Host Configuration Protocol),它提供了一种机制,称为即插即用连网( plug-and- play networking)。这种机制允许一台计算机加入新的网络和获取IP地址而不用手工参与。DHCP最新的RFC文档是1997年的RFC2131和RFC2132,目前还是互联网草案标准。
DHCP对运行客户软件和服务器软件的计算机都适用。当运行客户软件的计算机移至一个新的网络时,就可使用DHCP获取其配置信息而不需要手工干预。DHCP给运行服务器软件而位置固定的计算机指派一个永久地址,而当这计算机重新启动时其地址不改变。
DHCP使用客户服务器方式。需要IP地址的主机在启动时就向DHCP服务器广播发送发现报文(DHCPDISCOVER)(将目的IP地址置为全1,即255.255.255.255),这时该主机就成为DHCP客户。发送广播报文是因为现在还不知道DHCP服务器在什么地方,因此要发现(DISCOVER)DHCP服务器的IP地址。这台主机目前还没有自己的IP地址,因此它将IP数据报的源IP地址设为全0。这样,在本地网络上的所有主机都能够收到这个广播报文,但只有DHCP服务器才对此广播报文进行回答。DHCP服务器先在其数据库中查找该计算机的配置信息。若找到,则返回找到的信息。若找不到,则从服务器的IP地址池(address pool)中取一个地址分配给该计算机。DHCP服务器的回答报文叫做提供报(DHCPOFFER),表示“提供”了IP地址等配置信息。
但是我们并不愿意在每一个网络上都设置一个DHCP服务器,因为这样会使DHCP服务器的数量太多。因此现在是使每一个网络至少有一个DHCP中继代理(relay agent)(通常是一台路由器,见下图),它配置了DHCP服务器的IP地址信息。
当DHCP中继代理收机A以广播形式发送的发现报文后,就以单播方式向DHCP服务器转发此报文,并等待其回答。收到DHCP服务器回答的提供报文后,DHCP中继代理再把此提供报文发回给主机A。需要注意的是,下图只是个示意图。实际上,DHCP报文只是UDP用户数据报的数据,它还要加上UDP首部、IP数据报首部,以及以太网的MAC帧的首部和尾部后,才能在链路上传送。
DHCP服务器分配给DHCP客户的IP地址是临时的,因此DHCP客户只能在一段有限的时间内使用这个分配到的IP地址。DHCP协议称这段时间为租用期(lease period),但并没有具体规定租用期应取为多长或至少为多长,这个数值应由DHCP服务器自己决定。例如,一个校园网的DHCP服务器可将租用期设定为1小时。DHCP服务器在给DHCP发送的提供报文的选项中给出租用期的数值。按照RFC2132的规定,租用期用4字节的二进制数字表示,单位是秒。因此可供选择的租用期范围从1秒到136年。DHCP客户也可在自己发送的报文中(例如,发现报文)提出对租用期的要求。
DHCP的详细工作过程如下图所示。DHCP客户使用的UDP端口是68,而DHCP服务器使用的UDP端口是67。这两个UDP端口都是熟知端口。
下面按照上图中的注释编号(❶至❾)进行简单的解释:
❶ DHCP服务器被动打开UDP端口67,等待客户端发来的报文。
❷ DHCP客户从UDP端口68发送DHCP发现报文。
❸ 凡收到DHCP发现报文的DHCP服务器都发出DHCP提供报文,因此DHCP客户可能收到多个DHCP提供报文。
❹ DHCP客户从几个DHCP服务器中选择其中的一个,并向所选择的DHCP服务器发送DHCP请求报文。
❺ 被选择的DHCP服务器发送确认报文 DHCPACK。从这时起,DHCP客户就可以使用这个IP地址了。这种状态叫做已绑定状态,因为在DHCP客户端的IP地址和硬件地址已经完成绑定,并且可以开始使用得到的临时IP地址了。
DHCP客户现在要根据服务器提供的租用期T设置两个计时器T1和T2,它们的超时时间分别是0.5T和0.875T。当超时时间到了就要请求更新租用期。
❻ 租用期过了一半(T1时间到),DHCP发送请求报文 DHCPREQUEST要求更新租用期。
❼ DHCP服务器若同意,则发回确认报文 DHCPACK。DHCP客户得到了新的租用期,重新设置计时器。
❽ DHCP服务器若不同意,则发回否认报文 DHCPNACK。这时DHCP客户必须立即停止使用原来的IP地址,而必须重新申请IP地址(回到步骤❷)。
若DHCP服务器不响应步骤❻的请求报文 DHCPREQUEST,则在租用期过了87.5%时(T2时间到),DHCP客户必须重新发送请求报文 DHCPREQUEST(重复步骤❻),然后又继续后面的步骤。
❾ DHCP客户可以随时提前终止服务器所提供的租用期,这时只需向DHCP服务器发送释放报文 DHCPRELEASE即可DHCP很适合于经常移动位置的计算机。当计算机使用 Windows操作系统时,点击“控制面板”的“网络”图标就可以找到某个连接中的“网络”下面的菜单,找到TCP/IP协议后点击其“属性”按钮,若选择“自动获得IP地址”和“自动获得DNS服务器地址”,就表示是使用DHCP协议。
今天的文章计算机网络应用层协议_局域网结构的三个层次分享到此就结束了,感谢您的阅读。
版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
如需转载请保留出处:https://bianchenghao.cn/84746.html