应用层概述
应用层是计算机网络的最顶层,是设计和建立计算机网络的最终目的,也是计算机网络中发展最快的部分
应用层的主要任务是解决通过应用进程的交互来实现特定网络应用的问题
经典的网络应用:
- 万维网WWW
- 域名系统DNS
- 动态主机配置协议DHCP
- 电子邮件
- 文件传送协议FTP
- P2P文件共享
- 多媒体网络应用
客户/服务器方式(C/S方式)和对等方式(P2P方式)
网络应用程序运行在处于网络边缘的不同的端系统上,通过彼此间的通信来共同完成某项任务
开发一种新的网络应用首先要考虑的问题就是网络应用程序在各种端系统上的组织方式和它们之间的关系,目前流行的主要有以下两种:
- 客户/服务器(Client/Server,C/S)方式
- 对等(Peer-to-Peer,P2P)方式
客户-服务器(Client/Server,C/S)方式
客户和服务器是指通信中所涉及的两个应用进程
客户/服务器方式所描述的是进程之间服务和被服务的关系
处于网络边缘的主机A中运行的是客户程序,正在运行的客户程序称为客户进程,也可简称为客户,运行客户进程的主机应该称为客户计算机,但为了方便有时也简称为客户
处于网络边缘的主机B中运行的是服务器程序,正在运行的服务器程序称为服务器进程,也可简称为服务器,运行服务器进程的主机应该称为服务器计算机,但为了方便有时也简称为服务器
在客户/服务器方式下,客户向服务器请求服务,服务器收到服务请求后向客户提供服务
客户是服务的请求方,服务器是服务的提供方
服务器总是处于运行状态,并等待客户的服务请求
服务器具有固定端口号(例如HTTP服务器的默认端口号为80),而运行服务器的主机也具有固定的IP地址
C/S方式是因特网上传统的、同时也是最成熟的方式,很多我们熟悉的网络应用采用的都是C/S方式,包括万维网WWW、电子邮件、文件传输FTP等
基于C/S方式的应用服务通常是服务集中型的,即应用服务集中在网络中比客户计算机少得多的服务器计算机上
由于一台服务器计算机要为多个客户机提供服务,因此在C/S应用中,常会出现服务器计算机跟不上众多客户机请求的情况
为此,在C/S应用中,常用计算机群集(或服务器场)构建一个强大的虚拟服务器
对等(Peer-to-Peer,P2P)方式
在P2P方式中,没有固定的服务请求者和服务提供者
分布在网络边缘各端系统中的应用进程是对等的,被称为对等方
对等方相互之间直接通信,每个对等方既是服务的请求者,又是服务的提供者
处于网络边缘的主机C、D、E、F中运行着同一种P2P程序,例如某种网络下载工具软件
E和F中的P2P进程互为对等方,C和D中的P2P进程互为对等方
而E中的P2P进程还和D中的P2P进程互为对等方,
可以想象为E的P2P进程正在从F处下载文件,与此同时还为D的P2P进程提供下载服务
目前,在因特网上流行的P2P应用主要包括:P2P文件共享、即时通信、P2P流媒体、分布式存储等
基于P2P的应用是服务分散型的,因为服务不是集中在少数几个服务计算机中,而是分散在大量对等计算机中,这些计算机并不为服务提供商所有,而是为个人控制的桌面计算机和笔记本电脑,它们通常位于住宅、校园和办公室中
P2P方式的最突出特性之一就是它的可扩展性,因为系统每增加一个对等方,不仅增加的是服务的请求者,同时也增加了服务的提供者,系统性能不会因规模的增大而降低
P2P方式具有成本上的优势,因为它通常不需要庞大的服务器设施和服务器带宽
为了降低成本,服务提供商对于将P2P方式用于应用的兴趣越来越大
动态主机配置协议DHCP
假设有如下网络拓扑,要使该网络中的主机能够访问Web服务器,就需要给每一台主机都配置一些相应的信息,包括:IP地址、子网掩码、默认网关、DNS服务器等网络相关配置信息
当网络中的主机数量较少时,手工配置也是可行的,假设给该网络的各主机手工配置了如下的网络相关配置信息
如果网络中的主机数量较多,则手工配置的方式显然就不可取
可以给网络中添加一台DHCP服务器,在该服务器中设置好可为网路中其他各主机配置的网络配置信息
当网络中的各主机开机后,让其自动启动DHCP程序,向DHCP服务器请求自己的网络配置信息
这样,网络中的各主机就都可以从DHCP服务器中自动获取网络配置信息,而不需要手工参与
动态主机配置协议DHCP(Dynamic Host Configuration Protocol)提供了一种机制,称为即插即用连网。这种机制允许一台计算机加入新网络时可自动获取IP地址等网络配置信息而不用手工参与
DHCP的作用是为局域网中各主机配置IP地址、子网掩码、默认网关和DHS服务器地址等网络配置信息
DHCP的工作过程
假设网络中有两台DHCP服务器和一台用户主机
DHCP使用客户/服务器方式
在DHCP服务器上运行DHCP服务器进程,也可简称为DHCP服务器
在用户主机上运行DHCP客户进程,也可简称为DHCP客户
DHCP是TCP/IP体系结构中应用层中的协议,它使用运输层的UDP所提供的服务,也就是说,DHCP报文在运输层会被封装成UDP数据报
DHCP服务器进程使用的UDP端口是67,DHCP客户进程使用的UDP端口是68,两者都是熟知端口号
封装有DHCP报文的UDP用户数据报,在网络层会被封装成IP数据报,然后再根据所使用的网络接口,封装成相应的数据链路层的帧进行发送,例如封装成以太网帧
当启用主机的DHCP后,DHCP客户将广播发送DHCP发现报文(DHCP DISCOVER),封装该报文的IP数据报的源IP地址为0.0.0.0,这是因为主机目前还未分配到IP地址,因此使用该地址来代替
目的IP地址为广播地址255.255.255.255,之所以广播发送,是因为主机现在并不知道网络中有哪几个DHCP服务器,它们的IP地址是什么
由于是广播的IP数据报,因此网络中的所有设备都会收到该IP数据报,并对其层层解封,解封出封装有DHCP发现报文的UDP用户数据报
对于DHCP客户,其应用层没有监听该UDP用户数据报的目的端口67的进程,也就是DHCP服务器进程,因此无法交付DHCP发现报文,只能丢弃
对于DHCP服务器,其应用层始终运行着DHCP服务器进程,因此会接受该DHCP发现报文并作出响应
DHCP报文的格式比较复杂,对于DHCP发现报文,我们只需要知道其内部封装有事务ID和DHCP客户端的MAC地址即可
DHCP服务器收到DHCP发现报文后,根据其中封装的DHCP客户端的MAC地址来查找自己的数据库,看是否有针对该MAC地址的配置信息
如果有,则使用这些配置信息来构建并发送DHCP提供报文(DHCP OFFER)
如果没有,则采用默认配置信息来构建并发送DHCP提供报文
封装该提供报文的IP数据报的源IP地址为DHCP服务器的IP地址,目的IP地址仍为广播地址,仍然使用广播地址的原因是主机目前还没有配置IP地址,为了使主机可以收到,只能发送广播
这样一来,网络中的所有设备都会收到该IP数据报,并对其层层解封,解封出封装有DHCP提供报文的UDP用户数据报
对于DHCP服务器,其应用层没有监听该UDP用户数据报目的端口68的进程,也就是DHCP客户进程,因此无法交付DHCP提供报文,将其丢弃
对于DHCP客户,其应用层运行着DHCP客户进程,因此会接受该DHCP提供报文并作出相应处理
DHCP客户会根据DHCP提供报文中的事务ID,来判断该报文是否是自己所请求的报文,如果该事务ID与自己之前发送的DHCP发现报文中封装的事务ID相等,就表明这是自己所请求的报文,就可以接受该报文,否则就丢弃该报文
DHCP提供报文中还封装有配置信息,例如IP地址、子网掩码、地址租期、默认网关、DNS服务器等
DHCP服务器从自己的IP地址池中挑选待租用给主机的IP地址时,会先使用ARP来确保所选IP地址未被网络中其他主机占用
在本例中,DHCP客户会收到两个DHCP服务器发来的DHCP提供报文,DHCP客户从中选择一个,一般来说,选择先到的那个,并向所选择DHCP服务器发送DHCP请求报文(DHCP REQUEST)
封装该报文的IP数据报的源IP地址仍为0.0.0.0,因为此时DHCP客户才从多个DHCP服务器中,挑选一个作为自己的DHCP服务器,它首先需要得到该服务器的同意,之后才能正式使用向该DHCP服务器租用的IP地址
目的IP地址仍为广播地址,这样做的目的是可以不用向网络中的每一个DHCP服务器单播发送DHCP请求报文来告知它们是否请求它们作为自己的DHCP服务器
DHCP请求报文中封装有事务ID,DHCP客户端的MAC地址,接受的租约中的IP地址、提供此租约的DHCP服务器端的IP地址等信息
在本例中,假设DHCP客户选择DHCP服务器1作为自己的DHCP服务器,并且DHCP服务器1接受该请求,于是DHCP服务器1给DHCP客户发送DHCP确认报文(DHCP ACK)
封装该报文的IP数据报的源IP地址为DHCP服务器1的IP地址;目的IP地址仍为广播地址
DHCP客户收到该确认报文后,就可以使用所租用到的IP地址了
在使用租用到的IP地址之前,主机还会使用ARP检测所分配到的IP地址是否已被网络中其他主机占用:
若被占用,DHCP客户会给DHCP服务器发送“DHCP DECLINE”(DHCP谢绝)报文撤销IP地址租约,并重新发送“DHCP DISCOVER”报文
若未被占用,可以使用租约中的IP地址与网络中其他主机通信了
当租用期过了一半时,DHCP客户会向DHCP服务器发送DHCP请求报文(DHCP REQUEST),来请求更新租用期
封装该报文的IP数据报的源IP地址为DHCP客户之前租用到的IP地址,目的地址为DHCP服务器1的地址
DHCP服务器若同意,则发送DHCP确认报文(DHCP ACK),这样DHCP客户就得到了新的租用期
DHCP服务器若不同意,则发送DHCP否认报文(DHCP NACK),这时,DHCP客户必须立即停止使用之前租用的IP地址,并重新发送DHCP发现报文来重新申请IP地址
DHCP服务器若未做出响应,则在租用期过了87.5%时,DHCP客户必须重新发送DHCP请求报文来请求更新租用期,然后继续等待DHCP服务器可能做出的反应
若DHCP服务器仍未做出响应,则当租用期到期后,DHCP客户必须立即停止使用之前租用的IP地址,并重新发送DHCP发现报文来重新申请IP地址
DHCP客户可以随时提前终止DHCP服务器所提供的租用期,这时只需要向DHCP服务器发送DHCP释放报文段即可
注意:
- DHCP服务器在给DHCP客户挑选IP地址时,使用ARP来确保所挑选的IP地址未被网络中其他主机占用
- DHCP客户在使用所租用的IP地址之前,也会使用ARP来检测该IP地址是否已被网络中其他主机占用
DHCP中继代理
由于DHCP客户在使用DHCP服务器提供的IP地址之前是没有IP地址的,需要先使用广播报文(目的IP地址为255.255.255.255)寻找DHCP服务器,若DHCP服务器与DHCP客户不在同一网络内,则DHCP客户发送的广播报文在传送到路由器时会被其丢弃
解决方法是给该路由器配置DHCP服务器的IP地址并使之成为DHCP中继代理,这样,该网络的各主机就可以通过DHCP协议来获取网络配置信息了
当该路由器收到广播的DHCP发现报文后,会将其单播转发(点对点转发)给DHCP服务器
使用DHCP中继代理的理由是我们并不愿意在每个网络中都设置一个DHCP服务器
域名系统DNS
域名系统DNS(Domain Name System)的作用
以因特网中的某台主机访问某台Web服务器为例
当我们在浏览器的地址栏中输入某个Web服务器的域名时,用户主机会首先在自己的DNS高速缓存表中查找该域名所对应的IP地址
如果没有找到,则会向网络中的某台DNS服务器查询,DNS服务器中有域名和IP地址的映射关系的数据库,当DNS服务器收到DNS查询报文后,就会在其数据库中进行查询,之后将查询结果发送给用户主机,随后用户主机的浏览器就可以通过Web服务器的IP地址对其进行访问了
因特网不能只使用一台DNS服务器,因为因特网的规模很大,这样的域名服务器肯定会因为超负荷而无法正常工作,而且一旦域名服务器出现故障,整个因特网就会瘫痪
因特网采用层次结构的命名树作为主机的名字(即域名),并使用分布式的域名系统DNS
DNS使大多数域名都在本地解析,仅少量解析需要在因特网上通信,因此系统效率很高
由于DNS是分布式系统,即使单个计算机出现了故障,也不会妨碍整个系统的正常运行
DNS报文使用运输层的UDP协议进行封装,运输层端口号为53
域名结构
因特网采用层次树状结构的域名结构,域名的结构由若干个分量组成,各分量之间用“点”隔开,分别代表不同级别的域名
xxx.三级域名.二级域名.顶级域名
- 每一级的域名都由英文字母和数字组成,不超过63个字符,不区分大小写字母
- 级别最低的域名写在最左边,级别最高的顶级域名写在最右边
- 完整的域名不超过255个字符
域名系统既不规定一个域名需要包含多少个下级域名,也不规定每一级的域名代表什么意思
各级域名由其上一级的域名管理机构管理,而最高的顶级域名则由因特网名称与数字地址分配机构ICANN进行管理
以域名
nic.hnust.edu.cn为例cn为顶级域名,表示中国
edu是在顶级域名cn之下注册的二级域名,表示教育机构
hnust是在二级域名edu之下注册的三级域名,表示湖南科技大学
nic是在三级域名hnust之下注册的四级域名,表示网络信息中心
顶级域名TLD(Top Level Domain)分为以下三类:
-
国家顶级域名nTLD 采用ISO 3166的规定
如:cn表示中国,us表示美国,uk表示英国等
-
通用顶级域名gTLD 最常见的通用顶级域名有七个
即:com(公司企业)、net(网络服务机构)、org(非营利性组织)、int(国际组织)、edu(美国教育机构)、gov(美国政府部门)、mil(美国军事部门)
-
反向域arpa 用于反向域名解析,即IP地址反向解析为域名
在国家顶级域名下注册的二级域名均由该国家自行确定
例如:顶级域名为jp的日本,将其教育和企业机构的二级域名定为ac和co,而不用edu和com
我国则将二级域名划分为以下两类:
-
类别域名
共七个:ac(科研机构)、com(工、商、金融等企业)、edu(教育机构)、gov(政府部门)、net(提供网络服务的机构)、mil(军事机构)和org(非营利性组织)
-
行政区域名
共34个,适用于我国的各省、自治区、直辖市
例如:bj为北京市、sh为上海市、js为江苏省等
名称相同的域名其等级未必相同
例如:com(公司企业)是通用顶级域名,但我国顶级域名cn下也有一个名称为com(工、商、金融等企业)的二级域名
因特网的域名空间
它实际上是一棵倒着生长的树,在最上面是根,但没有对应的域名,根下面一级的节点就是顶级域名,顶级域名可往下划分出二级域名,二级域名再往下划分就是三级域名,三级域名再往下划分就是四级域名
这种按等级管理的命名方法便于维护域名的唯一性,并且也容易设计出一种高效的域名查询机制
需要注意的是,域名只是一个逻辑概念,并不代表计算机所在的物理地点
域名和IP地址的映射关系必须保存在域名服务器中,供所有其他应用查询
显然不能将所有信息都储存在一台域名服务器中
DNS使用分布在各地的域名服务器来实现域名到IP地址的转换
域名服务器可以划分为以下四种不同的类型:
-
根域名服务器
根域名服务器是最高层次的域名服务器
每个根域名服务器都知道所有的顶级域名服务器的域名及其IP地址
因特网上共有13个不同IP地址的根域名服务器
尽管我们将这13个根域名服务器中的每一个都视为单个的服务器,但“每台服务器”实际上是由许多分布在世界各地的计算机构成的服务器群集
当本地域名服务器向根域名服务器发出查询请求时,路由器就把查询请求报文转发到离这个DNS客户最近的一个根域名服务器,这就加快了DNS的查询过程,同时也更合理地利用了因特网的资源
根域名服务器通常并不直接对域名进行解析,而是返回该域名所属顶级域名的顶级域名服务器的IP地址
-
顶级域名服务器
这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名
当收到DNS查询请求时就给出相应的回答,回答可能是最后的结果,也可能是下一级权限域名服务器的IP地址
-
权限域名服务器
这些域名服务器负责管理某个区的域名
每一个主机的域名都必须在某个权限域名服务器处注册登记
因此权限域名服务器知道其管辖的域名与IP地址的映射关系
另外,权限域名服务器还知道其下级权限域名服务器的地址
-
本地域名服务器
本地域名服务器有时也称为默认域名服务器
本地域名服务器不属于上述的域名服务器的等级结构
当一个主机发出DNS请求报文时,这个报文首先会被送往该主机的本地域名服务器
本地域名服务器起着代理的作用,会将该报文转发到上述的域名服务器的等级结构中
每一个因特网服务提供者ISP,一个大学,甚至是一个大学里的学院,都可以拥有一个本地域名服务器
本地域名服务器离用户较近,一般不超过几个路由器的距离,也有可能就在同一个局域网中
本地域名服务器的IP地址需要直接配置在需要域名解析的主机中
域名解析的过程
域名解析包含两种查询方式:
- 递归查询
- 迭代查询
假设主机想知道y.abc.com的IP地址
图中的dns.xxx.com是该域名服务器的域名
递归查询
主机首先向其本地域名服务器进行递归查询
本地域名服务器收到递归查询的委托后,也采用递归查询的方式向某个根域名服务器查询
根域名服务器收到递归查询的委托后,也采用递归查询的方式向某个顶级域名服务器查询
顶级域名服务器收到递归查询的委托后,也采用递归查询的方式向某个权限域名服务器查询
当查询到某个域名对应的IP地址后,查询结果会在之前受委托的各域名服务器之间传递,最终传回给用户主机
递归查询是一种深度优先的查询方式
迭代查询
主机首先向其本地域名服务器进行递归查询
本地域名服务器采用迭代查询,它先向某个根域名服务器查询
根域名服务器告诉本地域名服务器下一次应查询的顶级域名服务器的IP地址
本地域名服务器(根据得到的顶级域名服务器的IP地址)向顶级域名服务器进行迭代查询
顶级域名服务器告诉本地域名服务器下一次查询的权限域名服务器的IP地址
本地域名服务器(根据得到的权限域名服务器的IP地址)向权限域名服务器进行迭代查询
权限域名服务器告诉本地域名服务器所查询的域名的IP地址
本地域名服务器最后把查询结果告诉主机
迭代查询是一种广度优先的查询方式
由于递归查询对于被查询的域名服务器负担太大,因此通常采用迭代查询模式:从请求主机到本地域名服务器的查询是递归查询,而其余的查询是迭代查询
为了提高DNS的查询效率,并减轻根域名服务器的负荷和减少因特网上DNS查询报文的数量,在域名服务器中广泛地使用了高速缓存
高速缓存用来存放最近查询过的域名以及从何处获得域名映射信息的记录
如果不久前已经有用户查询过域名为y.abc.com的IP地址,则本地域名服务器的高速缓存中应该存有该域名对应的IP地址
当主机向本地域名服务器递归查询该域名时,本地域名服务器就没有必要再向某个根域名服务器进行查询了,而是直接把高速缓存中存放的上次的查询结果(即y.abc.com的IP地址)告诉用户主机
由于域名到IP地址的映射关系并不是永久不变,为保持高速缓存中的内容正确,域名服务器应为每项内容设置计时器并删除超过合理时间的项(例如,每个项目只存放两天)
不但在本地域名服务器中需要高速缓存,在用户主机中也很需要
许多用户主机在启动时会从本地域名服务器下载域名和IP地址的全部数据库,维护存放自己最近使用的域名的高速缓存,并且只在从缓存中找不到域名时才向域名服务器查询
同理,主机也需要保持自己的高速缓存中内容的正确性
练习:
文件传送协议FTP
将某台计算机中的文件通过网络传送到可能相距很远的另一台计算机中,是一项基本的网络应用,即文件传送
文件传送协议(File Transfer Protocol)是因特网上使用最广泛的文件传送协议
FTP提供交互式的访问,允许客户指明文件的类型与格式(如指明是否使用ASCII码),并允许文件具有存取权限(如访问文件的用户必须经过授权,并输入有效的口令)
FTP屏蔽了各计算机系统的细节,因而适用于在异构网络中任意计算机之间传送文件
FTP的应用
FTP采用客户/服务器方式
因特网上的FTP客户计算机可将各种类型的文件上传到FTP服务器计算机,FTP客户计算机也可以从FTP服务器计算机上下载文件
根据应用需求的不同,FTP服务器可能需要一台高性能和高可靠性的服务器计算机,也可能只需要一台普通的个人计算机即可
FTP的最常见用途是在计算机之间传输文件,尤其是用于批量传输文件
FTP的另一个常见用途是让网站设计者将构成网站内容的大量文件批量上传到他们的Web服务器
FTP的基本工作原理
主动模式
FTP服务器监听熟知端口号21,FTP客户随机选择一个临时端口号与其建立一个TCP连接(图中橙色部分),这条TCP连接用于FTP客户与服务器之间传送FTP的相关控制命令,也就是说,这条TCP连接是FTP客户与服务器之间的命令通道
当有数据要传输时,FTP客户通过命令通道告知FTP服务器来与自己的另一个临时端口号建立TCP连接,即建立数据通道
FTP服务器使用自己的熟知端口号20与其建立TCP连接(图中蓝色部分),这条TCP连接用于FTP客户与服务器之间传送文件,也就是说,这条TCP连接是FTP客户与服务器之间的数据通道
由于在建立数据通道时,FTP服务器主动连接FTP客户,因此称为主动模式
用于传送FTP相关控制命令的连接(控制连接)在整个会话期间一直保持打开,用于传送FTP相关控制命令
用于传送数据的连接(数据连接)用于文件传输,在每次文件传输时才建立,传输结束后就关闭
被动模式
对于被动模式,FTP客户与服务器之间命令通道的建立,它与主动模式并没有区别
不同之处在于,当有数据要传输时,FTP客户通过命令通道告知FTP服务器开启某个临时端口被动等待来自FTP客户的TCP连接,以建立数据通道
FTP客户发起与FTP服务器的TCP连接以建立数据通道,由于在建立数据通道时,FTP服务器被动等待FTP客户的连接,因此称为被动模式
电子邮件
传统的电话通信属于实时通信,存在以下两个缺点:
- 电话通信的主叫和被叫必须同时在场
- 一些不是十分紧迫的电话也常常不必要地打断人们的工作或休息
电子邮件与邮政系统的寄信相似:
- 发件人将邮件发送到自己使用的邮件服务器
- 发件人的邮件服务器将收到的邮件按其目的地址转发到收件人邮件服务器中的收件人邮箱
- 收件人在方便的时候访问收件人邮件服务器中自己的邮箱,获取收到的电子邮件
电子邮件系统采用客户/服务器方式
电子邮件系统的三个主要组成构件:用户代理、邮件服务器以及电子邮件所需要的协议
-
用户代理是用户与电子邮件系统的接口,又称为电子邮件客户端软件
-
邮件服务器是电子邮件系统的基础设施
因特网上所有的ISP都有邮件服务器,其功能是发送和接收邮件,同时还要负责维护用户的邮箱
-
协议包括邮件发送协议(例如SMTP)和邮件读取协议(例如POP3,IMAP)
在发送方计算机中需要使用用户代理来发送邮件
在接收方计算机中需要使用用户代理来接收邮件
可以简单地认为邮件服务器中有很多邮箱,还有用来缓存待转发邮件的缓存
发送方使用用户代理,并通过邮件发送协议(例如SMTP)将邮件发送给发送方邮件服务器
发送方邮件服务器同样通过邮件发送协议将该邮件发送给接收方邮件服务器,接收方在方便的时候使用用户代理通过邮件读取协议(例如POP3)从接收方邮件服务器读取邮件
邮件发送和接收的详细过程
发送方的用户代理作为SMTP客户,与发送方邮件服务器中的SMTP服务器进行TCP连接,然后基于这条连接,使用SMTP协议来发送邮件给发送方邮件服务器
发送方邮件服务器中的SMTP客户与接收方邮件服务器中的SMTP服务器进行TCP连接,然后基于这条连接,使用SMTP协议来发送已收到的待转发邮件给接收方邮件服务器
接收方的用户代理作为POP3客户,与接收方邮件服务器中的POP3服务器进行TCP连接,然后基于这条连接,使用POP3协议从接收方邮件服务器读取邮件
邮件发送协议的使用范围包含发送方用户代理到发送方邮件服务器,以及发送方邮件服务器到接收方邮件服务器这两部分
邮件读取协议的使用范围只有接收方用户代理到接收方邮件服务器这一部分
简单邮件传送协议SMTP(Simple Mail Transfer Protocol)的基本工作原理
以发送方邮件服务器使用SMTP协议给接收方邮件服务器发送待转发邮件为例
发送方邮件服务器周期性地扫描邮件缓存,如果发现有待转发的邮件,则发送方邮件服务器中的SMTP客户会与接收方邮件服务器中的SMTP服务器进行TCP连接,端口号为25
之后,SMTP客户就可以基于这条TCP连接给SMTP服务器发送SMTP命令(共14条)
SMTP服务器也会给SMTP客户发送相应的应答(共21种)
SMTP客户与服务器之间通过命令与应答的交互方式,最终实现SMTP客户发送邮件给SMTP服务器
下面简单介绍一下该过程:
当TCP连接建立成功后,SMTP服务器会主动推送服务就绪应答给SMTP客户,应答代码220后面可能跟有描述信息
SMTP客户收到该应答后,向服务器表明身份,告知自己SMTP服务器的域名,具体命令为HELO,其后为命令参数
SMTP服务器若认为身份有效,则发回应答代码250;否则发回其他错误代码(例如421表示服务不可用)
SMTP客户收到该应答后,使用MAIL FROM来告诉服务器邮件来自何方
SMTP服务器若认为合理,则发回应答代码250;否则发回其他错误代码
SMTP客户收到该应答后,使用命令RCPT TO来告诉服务器邮件去往何地,也就是收件人邮箱
SMTP服务器中如果有该收件人邮箱,则发回应答代码250;否则发回其他错误代码
SMTP客户收到该应答后,使用DATA命令来告诉服务器自己准备发送邮件内容了
SMTP服务器如果准备好接收,就发回应答代码354;否则发回其他错误代码
SMTP客户收到该应答后,就向服务器发送邮件内容
SMTP客户发送完邮件内容后,还要发送结束符
SMTP服务器若收件成功,则发回应答代码250;否则发回其他错误代码
SMTP客户收到该应答后,使用命令QUIT向服务器请求断开连接
SMTP服务器发回应答代码221表示接受请求并主动断开连接
注意:
- 为了简单起见,省略了认证过程
- 应答代码后面一般都跟有简单的描述信息
- 不同的SMTP服务器给出的相同应答代码的描述信息可能不同
电子邮件的信息格式
电子邮件的信息格式并不是由SMTP定义的,而是在RFC 822中单独定义的
这个RFC文档已在2008年更新为RFC 5322
一个电子邮件有信封和内容两部分,而内容又由首部和主体两部分构成
首部和主体的信息都需要由用户来填写
首部中包含一些关键字,后面加上冒号,例如:
- From:后面填入发件人的电子邮件地址,一般由邮件系统自动填入
- To:后面填入一个或多个收件人的电子邮件地址
- Cc:后面填入一个或多个收件人以外的抄送人的电子邮件地址,抄送人收到邮件后,可看可不看邮件,可回可不回邮件
- Subject:后面填入邮件的主题,它反映了邮件的主要内容
用户写好首部后,邮件系统会自动将信封所需的信息提取出来并写在信封上,所以用户不需要填写电子邮件信封上的信息
在填写完首部各关键字的内容后,用户还需要撰写邮件的主体部分,这是用户想传递给收件人的核心信息
SMTP协议只能传送ASCII码文本数据,不能传送可执行文件或其他的二进制对象
因此,SMTP不能满足传送多媒体邮件(例如带有图片、音频或视频数据)的需要,并且许多其他非英语国家的文字(例如中文,俄文,甚至带有重音符号的法文或德文)也无法用SMTP传送
为解决SMTP传送非ASCII码文本的问题,提出了多用途因特网邮件扩展MIME(Multipurpose Internet Mail Extensions)
SMTP协议只能传送ASCII码文本数据
假设,发送方发送的电子邮件中包含有非ASCII码数据,则不能直接使用SMTP进行传送,需要通过MIME进行转换,将非ASCII码数据转换为ASCII码数据,然后就可以使用SMTP进行传送了
接收方也要使用MIME对接收到的ASCII码数据进行逆转换,这样就可以得到包含有非ASCII码数据的电子邮件
为了实现这种转换,MIME
- 增加了5个新的邮件首部字段,这些字段提供了有关邮件主体的信息
- 定义了许多邮件内容的格式,对多媒体电子邮件的表示方法进行了标准化
- 定义了传送编码,可对任何内容格式进行转换,而不会被邮件系统改变
MIME不仅仅用于SMTP,也用于后来的同样面向ASCII字符的HTTP
常用的邮件读取协议
常用的邮件读取协议有以下两个:
-
邮局协议POP(Post Office Protocol)
POP3是其第三个版本,是因特网正式标准
POP3是非常简单、功能有限的邮件读取协议
用户只能以下载并删除方式或下载并保留方式从邮件服务器下载邮件到用户方计算机
不允许用户在邮件服务器上管理自己的邮件(如创建文件夹,对邮件进行分类管理等)
-
因特网邮件访问协议IMAP(Internet Message Access Protocol)
IMAP4是其第四个版本,目前还是因特网建议标准
IMAP功能比POP3强大的邮件读取协议
用户在自己的计算机上就可以操控邮件服务器中的邮箱,就像在本地操控一样,因此IMAP是一个联机协议
POP3和IMAP4都采用基于TCP连接的客户/服务器方式
POP3使用熟知端口110,IMAP4使用熟知端口143
基于万维网的电子邮件
通过浏览器登录(提供用户名和口令)邮件服务器万维网网站就可以撰写、收发、阅读和管理电子邮件
这种工作模式与IMAP很类似,不同的是用户计算机无需安装专门的用户代理程序,只需要使用通用的万维网浏览器
邮件服务器网站通常都提供非常强大和方便的邮件管理功能,用户可以在邮件服务器网站上管理和处理自己的邮件,而不需要将邮件下载到本地进行管理
假设用户A和用户B都使用网易邮件服务器
用户A的电子邮件地址为aaa@163.com,用户B的电子邮件地址为bbb@163.com
用户A要给用户B发送邮件
用户A使用浏览器登录邮件服务器网站,撰写并发送邮件给用户B,用户B也使用浏览器登录邮件服务器网站读取收到的邮件
用户A和B在发送和接收邮件时,与服务器之间使用的是HTTP协议,而不需要使用SMTP和POP3协议
假设用户A使用网易邮件服务器,用户C使用谷歌邮件服务器,用户C的电子邮件地址为ccc@163.com
用户A要给用户C发送邮件
用户A使用浏览器登录自己的邮件服务器网站撰写并发送邮件给用户C,使用的是HTTP协议
用户A的邮件服务器使用SMTP将邮件发送给用户C的邮件服务器
用户C也使用浏览器登录自己的邮件服务器网站,读取收到的邮件,使用的也是HTTP协议
万维网WWW
万维网WWW(World Wide Web)并非某种特殊的计算机网络
它是一个大规模的、联机式的信息储藏所,是运行在因特网上的一个分布式应用
万维网利用网页之间的超链接将不同网站的网页链接成一张逻辑上的信息网
目前比较流行的浏览器有:
- Chrome(内核为Blink)
- Firefox(内核为Cecko)
- Safari(内核为Webkit)
- Opera(内核为Blink)
- Internet Explorer(内核为Trident)
浏览器最重要的部分是渲染引擎,也就是浏览器内核,其负责对网页内容进行解析和显示
- 不同的浏览器内核对网页内容的解析也有不同,因此同一网页在不同内核的浏览器里的显示效果可能不同
- 网页编写者需要在不同内核的浏览器中测试网页显示效果
为了方便地访问在世界范围的文档,万维网使用统一资源定位符URL来指明因特网上任何种类“资源”的位置
URL的一般形式由以下四个部分组成:
<协议>://<主机域名或IP地址>:<端口>/<路径>
万维网的文档
超文本标记语言HTML(HyperText Markup Language)使用多种“标签”来描述网页的结构和内容
层叠样式表CSS(Cascading Style Sheets)用来描述网页的样式
JavaScript是一种脚本语言,用于控制网页的行为
由HTML、CSS、JavaScript编写的万维网文档,由浏览器内核负责解析和渲染
超文本传输协议HTTP(HyperText Transfer Protocol)
HTTP定义了浏览器(即万维网客户进程)怎样向万维网服务器请求万维网文档,以及万维网服务器怎样把万维网完档传送给浏览器
以用户主机来访问某个万维网服务器为例,可以看成是用户主机中的浏览器进程,即客户进程与服务器中的服务器进程基于因特网的通信
浏览器进程首先发起与服务器进程的TCP连接,使用熟知端口号80,基于这条已建立好的TCP连接,浏览器进程向服务器进程发送HTTP请求报文
服务器进程收到HTTP请求报文后,执行相应操作,然后给浏览器进程发回HTTP响应报文
HTTP/1.0采用非持续连接方式,在该方式下,每次浏览器要请求一个文件都要与服务器建立TCP连接,当收到响应后就立即关闭连接
客户与服务器之间通过三报文握手进行TCP连接
在这三个报文中的最后一个报文的数据载荷部分携带有HTTP请求报文
服务器收到后给客户发回HTTP响应报文
所以请求一个万维网文档所需的时间为2RTT + 文档的发送时延
- 建立TCP连接的前两次“握手”花费1个RTT;最后一个“握手”时报文的数据载荷部分携带有HTTP请求报文,服务器收到该报文后给客户发回HTTP响应报文,这一共需要花费1个RTT;发送时延为HTTP响应报文的发送时延
每请求一个文档就要有两倍的RTT的开销
若一个网页上有很多引用对象(例如图片等),那么请求每一个对象都需要花费2RTT的时间
为了减小时延,浏览器通常会建立多个并行的TCP连接同时请求多个对象
但是,这会大量占用万维网服务器的资源,而万维网服务器往往需要同时服务于大量客户的请求,这会使其负担很重
HTTP/1.1采用持续连接方式,在该方式下,万维网服务器在发送响应后仍然保持这条连接,使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文,这并不局限于传送同一个页面上引用的对象,而是只要这些文档都在同一个服务器上就行
为了进一步提供效率,HTTP/1.1的持续连接还可以使用流水线方式工作,即浏览器在收到HTTP的响应报文之前就能够连续发送多个请求报文
这样的一个接一个的请求报文到达服务器后,服务器就发回一个接一个的响应报文,这样就节省了很多个RTT时间,使TCP连接中的空闲时间减少,提高了下载文档的效率
持续连接方式:服务器在发送响应后仍然保持这条连接,使同一个客户(浏览器)和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文
非流水线方式:只有收到上一个请求的响应后,才能发送下一个请求
HTTP的报文格式
HTTP是面向文本的,其请求和响应报文中的每一个字段都是一些ASCII码串,并且每个字段的长度都是不确定的
HTTP请求报文格式
HTTP请求报文的第一行是请求行,由方法字段开始,其后跟一个空格,后跟统一资源定位符字段,其后跟一个空格,后跟版本字段,最后是回车换行
从第二行开始,就是首部行。每一个首部行由一个首部字段名开始时,其后跟一个冒号,再跟一个空格,然后是该字段的取值,最后是回车换行,可以有多个首部行
在最后的首部行下面是一个空行
在空行下面是实体主体,通常不使用(可以没有)
这是浏览器发送的HTTP请求报文的具体内容:
GET /index.htm HTTP/1.1
Host: www.hnust.cn
Connection: close
User-Agent: Mozilla/5.0
Accept-Language: cn
第一行为请求行,指明了方法GET,统一资源定位符(URL)以及HTTP的版本
第二行为第一个首部行,首部字段为Host,指明服务器的域名,其值为湖南科技大学广方网站的域名
第三行为第二个首部行,首部字段名为Connection,其值为close,这是告诉服务器发送完请求的文档后就可释放连接;其值若为keep-alive,则表示持续连接方式(持续与非持续不应该根据HTTP的版本判断,因为HTTP/1.1也可以使用非持续连接)
第四行为第三个首部行,首部字段名为User-Agent,其值是浏览器的类型及版本
第五行为第四个首部行,首部字段名为Accept-Language,其值为cn,这是告诉服务器用户希望优先得到中文版本的文档
在最后一个首部行下面是一个空行
该HTTP请求没有实体主体
HTTP请求报文支持以下方法:
| 方法 | 描述 |
|---|---|
| GET | 请求URL标志的文档 |
| HEAD | 请求URL标志的文档的首部 |
| POST | 向服务器发送数据 |
| PUT | 在指明的URL下存储一个文档 |
| DELETE | 删除URL标志的文档 |
| CONNECT | 用于代理服务器 |
| OPTIONS | 请求一些选项信息 |
| TRACE | 用来进行环回测试 |
| PATCH | 对PUT方法的补充,用来对已知资源进行局部更新 |
HTTP响应报文格式
HTTP响应报文的第一行是状态行,由版本字段开始,其后跟一个空格,后跟状态码字段,其后跟一个空格,后跟短语字段,最后是回车换行
除状态行外,HTTP响应报文的其他部分与HTTP请求报文格式的对应部分是相似的
状态行中的状态码共分为五大类,共33种
| 状态码(五大类共33种) | 描述 |
|---|---|
| 1XX | 表示通知信息,如请求收到了或正在进行处理 |
| 2XX | 表示成功,如接受或知道了 |
| 3XX | 表示重定向,即要完成请求还必须采取进一步的行动 |
| 4XX | 表示客户的差错,如请求中有错误的语法或不能完成 |
| 5XX | 表示服务器的差错,如服务器失效无法完成请求 |
响应报文中常见的状态行:
-
HTTP/1.1 202 Accepted该状态行表示服务器接受了请求,HTTP/1.1表示版本,202是状态码,Accepted是短语,也就是对状态码的简单描述
-
HTTP/1.1 400 Bad Request该状态行表示请求错误
-
HTTP/1.1 404 Not Found该状态行表示找不到所请求的页面
在访问网站时,浏览器通常会使用Cookie在服务器上记录用户信息
早期的万维网应用非常简单,仅仅是用户查看存放在不同服务器上的各种静态的文档,因此HTTP被设计为一种无状态的协议,这样可以简化服务器的设计
现在,用户可以通过万维网实现各种复杂的应用,如网上购物、电子商务等,这些应用往往需要万维网服务器能识别用户
Cookie提供了一种机制使得万维网服务器能够“记住”用户,而无需用户主动提供用户标识信息
也就是说,Cookie是一种对无状态的HTTP进行状态化的技术
Cookie的工作原理
用户主机中的浏览器进程首先与万维网服务器中的服务器进程建立TCP连接,端口号为80
当用户的浏览器进程初次向服务器进程发送HTTP请求报文时,服务器进程就会为其产生一个唯一的Cookie识别码,并以此为索引在服务器的后端数据库中创建一个项目,用来记录该用户访问该网站的各种信息,接着就会给浏览器进程发回HTTP响应报文
在响应报文中,包含有一个首部字段为Set-Cookie的首部行,该字段的取值就是Cookie识别码
当浏览器进程收到该响应报文后,就在一个特定的Cookie文件中添加一行记录该服务器的域名和Cookie识别码
当用户再次使用该浏览器访问这个网站时,每发送一个HTTP请求报文,浏览器都会从Cookie文件中取出该网站的Cookie识别码,并放到HTTP请求报文的Cookie首部行中,服务器根据Cookie识别码就可以识别出该用户,并返回该用户的个性化网页
万维网缓存与代理服务器
在万维网中还可以使用缓存机制以提高万维网的效率
万维网缓存又称为Web缓存(Web Cache),可位于客户机,也可位于中间系统上,位于中间系统上的Web缓存又称为代理服务器(Proxy Server)
Web缓存把最近一些请求和响应暂存在本地磁盘中
当新请求到达时,若发现这个请求与暂时存放的请求相同,就返回暂存的响应,而不需要按URL的地址再次去因特网访问资源
假设校园网中的某台主机要访问因特网上的某台万维网服务器,它首先会向校园网中的某台代理服务器发送请求,若代理服务器中存放有所请求的对象,则代理服务器会向该主机发回包含所请求对象的响应
若代理服务器中没有所请求的对象,则代理服务器会向因特网上的原始服务器发送请求,原始服务器将包含有所请求对象的响应发回给代理服务器,代理服务器将该响应存入Web缓存,然后给主机发回该响应
如果Web缓存的命中率较高,则路由器R1和R2之间链路上的通信量将大大减少,因而可以减少校园网各主机访问因特网的时延
使用代理服务器中缓存的响应有时也会带来一些问题,例如,当原始服务器对所请求对象的响应进行了修改,则代理服务器保存的缓存就不再是最新的,因此主机所请求的文档就与原始服务器不一致了
为尽可能保持代理服务器中缓存的响应与原始服务器中的实际响应一致,原始服务器通常会为每个响应的对象设置一个修改时间Last-Modified字段和一个有效日期Expires字段
当校园网中的某台主机要请求原始服务器中的该文档时,它首先向校园中的代理服务器发送请求,若代理服务器中的该文档未过期,则代理服务器将其封装在响应报文中发回给主机
若代理服务器中的该文档已过期,则代理服务器会向因特网上的原始服务器发送请求
在请求报文中包含有一个首部字段为If-modified-since的首部行,该字段的取值就是该文档的修改日期Last-Modified
原始服务器根据该文档的修改日期,就可以判断出代理服务器中存储的该文档是否与自己存储的该文档一致。如果一致,则给代理服务器发送不包含实体主体的响应,状态码为304,短语为Not modified
之后代理服务器重新更新该文档的有效日期,然后将该文档封装在响应报文中发回给主机
如果不一致,则给代理服务器发送封装有该文档的响应报文,这样代理服务器就更新了该文档,然后代理服务器再将更新后的该文档封装在响应报文中发回给主机