应用层概述
应用层是计算机网络体系结构的最顶层，其功能是设计和建立计算机网络的最终目的，也是在计算机网络中发展最快的部分。从早期基于文本的应用，例如电子邮件、远程登录，文件传输，新闻组等到20世纪90年代，将因特网带入千家万户的万维网，再到当今流行的即时通信，p2p文件共享， 以及各种音视频应用，网络应用一直层出不穷。此外，计算设备的小型化和无处不在，宽带住宅接入和无线接入的日益普及和迅速发展，为未来更多的新型网络应用提供了广阔的舞台。
例如我们在浏览器的地址栏中输入某个网站的域名号，就可以访问该网站的内容，这就是推动因特网飞速发展的万维网应用。其相关的应用层协议为超文本传送协议HTTP。用户在浏览器地址栏中输入的是域名，而TCP/IP体系的网际层是用IP地址来标识目的主机，从域名到IP地址的转换工作，由属于应用层范畴的域名系统DNS在后台帮用户自动完成，以方便用户的使用。除了万维网应用和域名系统外，常见的应用还有动态主机配置DHCP，电子邮件，文件传送和p2p文件共享，多媒体网络应用等。
客户/服务器方式和对等方式
我们知道网络应用程序运行在处于网络边缘的不同端系统上，通过彼此间的通信来共同完成某项任务。因此开发一种新的网络应用，首先要考虑的问题就是网络应用程序，在各种端系统上的组织方式和他们之间的关系。
目前流行的主要有以下两种：
一种是客户-服务器方式，也称为CS方式
另一种是对等方式，也称为P2P方式
我们首先来看客户/服务器方式：
如图所示：
处于网络边缘的主机a中运行的是客户程序，正在运行的客户程序，称为客户进程，也可简称为客户。需要注意的是运行客户进程的主机应称为客户计算机，但有时也简称为客户。
处于网络边缘的主机b中，运行的是服务器程序，正在运行的服务器程序称为服务器进程，也可简称为服务器。需要注意的是运行服务器进程的主机应称为服务器计算机，但有时也简称为服务器。
在客户服务器方式下，客户向服务器请求服务，服务器收到服务请求后，向客户提供服务也就是说，客户是服务的请求方，服务器是服务的提供方，服务器总是处于运行状态，并等待客户的服务请求。
服务器具有固定的运输层、端口号，例如HTTP服务器的默认端口号为80，而运行服务器的主机也具有固定的IP地址。
我们再来看对等方式，也就是P2P方式：
如图所示，处于网络边缘的主机cdef中运行着同一种P2P程序，例如某种网络下载工具软件，e和f中的P2P进程互为对等方，c和d中的P2P进程互为对等方，而e中的P2P进程还和d中的P2P进程互为对等方。我们可以想象成e的P2P进程正在从f下载文件，与此同时还为d的P2P进程提供下载服务。
P2P方式的最突出特性之一，就是它的可扩展性，因为系统每增加一个对等方，不仅增加的是服务的请求者，同时也增加了服务的提供者。系统性能不会因为规模的增大而降低，P2P方式具有成本上的优势，因为它通常不需要庞大的服务器设施和服务器带宽，为了降低成本，服务提供商对于将P2P方式用于应用的兴趣越来越大。
内容小结如下：
动态主机配置协议DHCP
我们首先来举例说明DHCP的作用。如图所示有这样一个网络拓扑，我们需要给网络中的各主机正确配置IP地址，子网掩码，默认网关，DNS服务器的网络相关配置信息，才能使他们可以正常访问网络中的WEB服务器。
例如这是我们给两台主机手工配置的网络相关配置信息：
试想一下，如果网络中的主机数量比较多，则这种手工配置的工作量就比较大，并且容易出错。
如果我们给网络中添加一台DHCP服务器，在该服务器中设置好，可为网络中其他各主机配置的网络配置信息。网络中各主机开机后自动启动DHCP程序，向DHCP服务器请求自己的网络配置信息，这样网络中的各主机就都可以从DHCP服务器自动获取网络配置信息，而不用手工参与。
接下来我们举例说明DHCP的工作过程
假设网络中有两台DHCP服务器和多台用户主机，为了简单而有效的描述DHCP的工作过程，我们画出网络中的这两台DHCP服务器和一台用户主机，DHCP使用客户/服务器方式，在DHCP服务器上运行DHCP服务器进程，也可简称为DHCP服务器。在用户主机上运行DHCP，客户进程也可简称为DHCP客户。
DHCP是TCP协议体系应用层中的协议，它使用运输层的UDP所提供的服务，也就是说DHCP报文在运输层会被封装成为UDP用户数据报
DHCP服务器使用的UDP端口是67，DHCP客户使用的UDP端口是68，这两个UDP端口都是熟知端口
封装有DHCP报文的UDP用户数据报，在网络层会被封装成IP数据报，然后再根据所使用的网络接口，封装成相应的数据链路层的帧进行发送。例如封装城以太网帧。
为了简单起见，在后续描述过程中，除非有特别需要，否则我们将不再每次描述DHCP报文逐层封装的过程。
下面我们来看看DHCP客户与DHCP服务器的交互过程：
当启用主机的DHCP后，DHCP客户将广播发送DHCP发现报文封装该报文的，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提供报文，封装该报文的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请求报文，封装该报文的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确认报文，封装该报文的IP数据报的源IP地址为DHCP服务器1的IP地址，目的IP地址仍为广播地址，DPHP客户收到该确认报文后，就可以使用租用的IP地址了。
需要注意的是在使用所用到的IP地址之前，主机还会使用ARP检测该IP地址是否已被网络中其他主机占用。
若被占用，DHCP客户会给DHCP服务器发送DACP谢绝报文，来谢绝IP地址租约，并重新发送DHCP发现报文，
若未被占用，则可以使用租约中的IP地址与网络中的其他主机通信了。
当租用期过了一半时，DHCP客户会向DHCP服务器发送DHCP请求报文，来请求更新租用期，封装该报文的IP数据报的源IP地址为 DHCP客户之前租用到的IP地址，目的IP地址为PHP服务器1的地址
DHCP服务器若同意则发回DHCP确认报文，这样DHP客户就要得到了新的租用期。
DHCP服务器若不同意，则发回DHCP否认报文。这时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发现报文，但该广播报文不会被路由器转发，而是丢弃
解决方法是给该路由器配置DHCP服务器的IP地址，并使之成为DHCP中继代理，这样该网络中的各主机就可以通过DHCP来自动获取到网络配置信息了。当该路由器收到广播的DHCP发现报文后，会将其单播转发给DHCP服务器，DHCP客户和DHCP服务器通过该路由器的后续交互过程，我们就要不再赘述了。
使用DHCP中继代理的主要原因是我们并不愿意在每一个网络上都设置一个DHCP服务器，因为这样会使DHCP服务器的数量太多
内容小结如下：
域名系统DNS
当我们在浏览器地址栏中输入某个WEB服务器的域名时，用户主机会首先在自己的DNS高速缓存中查找该域名所对应的IP地址，如果没有找到，则会向网络中的某台DNS服务器查询，DNS服务器中有域名和IP地址映射关系的数据库。当DNS服务器收到DNS查询报文号，在其数据库中进行查询，之后将查询结果发送给用户主机。
现在用户主机中的浏览器可以通过外部服务器的IP地址对其进行访问了。请同学们思考一下，因特网是否可以只使用一台DNS服务器？
接下来我们就来看看因特网域名系统所采用的层次树状结构的域名结构：
接下来我们举例说明因特网的域名空间：
它实际上是一颗倒着生长的树，在最上面的是根，但没有对应的域名，根下面一级的节点就是顶级域名
顶级域名可往下划分出二级域名，例如这是表示公司企业的顶级域名com下面划分有CCTV、IBM、TI等二级域名，分别表示中央电视台、IBM公司、TI公司。还有表示中国的顶级域名CN下面划分的二级域名。图中所示的域名分别表示上海、北京教育机构政府部门的。
二级域名再往下划分就是三级域名。例如这是表示中央电视台的二级域名CCTV下划分的三级域名MAIL表示邮件系统，这是表示我国教育机构的二级域名EDU下划分的三级域名。图中所示的域名分别表示清华大学、湖南科技大学、复旦大学、北京大学
三级域名再往下划分，就是4级域名，例如这是表示湖南科技大学的3级域名，HNUST下划分的一些4级域名，分别表示湖南科技大学的网络信息中心、图书馆、邮件系统、教务处，上述这种按等级管理的命名方法，便于维护域名的唯一性，并且也容易设计出一种高效的域名查询机制。需要注意的是域名只是个逻辑概念，并不代表计算机所在的物理地点
然后我们来看看DNS服务器：
接下来我们介绍域名解析的过程包含以下两种查询方式；
一种是递归查询
另一种是迭代查询
首先来看递归查询。假设图中的主机，想知道域名Y.ABC.COM的IP地址，主机首先向其本地域名服务器进行递归查询，本地域名服务器收到递归查询的委托后，也采用递归查询的方式，向某个根域名服务器查询，根域名服务器收到递归查询的委托后，也采用定规查询的方式，向某个顶级域名服务器查询，顶级域名服务器收到递归查询的委托后，也采用递归查询的方式，向某个权限域名服务器查询，当查询到域名所对应的IP地址后，查询结果会在之前受委托的各域名服务器之间传递，最终传回给用户主机。
再来看迭代查询，主机首先向其本地域名服务器进行递归查询，本地域名服务器采用迭代查询，他先向某个根域名服务器查询，根域名服务器、告诉本地域名服务器，下一次应查询的顶级域名服务器的IP地址，本地域名服务器向顶级域名服务器进行迭代查询，顶级域名服务器告诉本地域名服务器，下一次应查询的权限域名服务器的IP地址，本地域名服务器向权限域名服务器进行迭代查询，权限域名服务器告诉本地域名服务器所查询的域名的IP地址，本地域名服务器，最后把查询结果告诉主机，
由于递归查询，对于被查询的域名服务器负担太大，通常采用这种模式：从请求主机到本地域名服务器的查询采用递归查询方式，而其余的查询是迭代查询方式
为了提高DNS的查询效率，并减轻根域名服务器的负担，和减少因特网上的DNS查询报文数量，在域名服务器中广泛的使用了高速缓存。
高速缓存用来存放最近查询过的域名，以及从何处获得域名映射信息的记录，如图所示，如果不久前已经有用户查询过域名为y.ABC.COM的IP地址，则本地域名服务器的高速缓存中，应该存有该域名对应的IP地址。当主机向本地域名服务器递归查询该域名时，本地域名服务器就没有必要再向某个根域名服务器进行迭代查询了，而是直接把高速缓存中存放的上次查询结果，即该域名的IP地址告诉用户主机。
需要注意的是，由于域名到IP地址的映射关系并不是永久不变，为保持高速缓存中的内容正确，域名服务器因为每项内容设置计时器，并删除超过合理时间的项，例如每个项目只存放两天。
不但在本地域名服务器中需要高速缓存，在用户主机中也很需要。许多用户主机在启动时，从本地域名服务器下载域名和IP地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到域名时才向域名服务器查询。
同理，主机也需要保持高速缓存中内容的正确性。
内容小结如下，需要注意的是DNS报文，是由运输层的UDP协议进行封装，运输层端口号为53，至于DNS报文的格式就不再赘述了。另外 DNS污染等安全问题有需要可自行了解：
文件传送协议FTP
接下来我们举例说明FTP的应用。
如图所示FTP采用客户/服务器方式，因特网上的FTP客户计算机可将各种类型的文件上传到FTP服务器计算机，FTP客户计算机也可以从FTP服务器计算机下载文件，根据应用需求的不同，FTP服务器可能需要一台高性能高可靠性的服务器计算机，也可能只需要一台普通的个人计算机即可。
例如本例也可以采用普通的个人计算机作为FTP服务器计算机，为了简单起见，我们假设FTP客户计算机与FTP服务器计算机处于同一个局域网中，我们在FTP服务器计算机中创建FTP服务器，可以使用第三方的FTP服务器软件，也可以使用操作系统自带的FTP服务器软件，例如我们可以在Windows系统中使用其自带的FTP服务器功能，创建一个FTP服务器站点，具体方法比较简单，请同学们在网上自行查阅。
假设这是我所创建的FTP服务器的IP地址，我们可以在FTP客户计算机中使用浏览器软件，通过该地址来访问FTP服务器，需要注意的是这里使用的是文件传送协议FTP，而不是浏览器最常用的超文本传送协议HTTP
我们也可以在FTP客户计算机中使用Windows系统自带的命令行工具，通过该地址来访问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客户随机选择的另一个端口号，FTP服务器使用自己的熟知端口号20与其建立TCP连接，这条TCP连接用于FTP客户与服务器之间传送文件，也就是说这条TCP连接是FTP客户与服务器之间的数据通道。
由于在建立数据通道时，FTP服务器主动连接FTP客户，因此称为主动模式，需要注意的是控制连接在整个会话期间一直保持打开，用于传送FTP相关的控制命令，而数据连接用于文件传输，在每次文件传输时才建立，传输结束就关闭。
再来看被动模式，对于FTP客户与服务器之间命令通道的建立，它与主动模式并没有什么。不同之处，在于当有数据要传输时，FTP客户通过命令通道通知FTP服务器开启某个协商好的临时端口，被动等待来自FTP客户的TCP连接，以建立数据通道，这是FTP服务器使用的与FTP客户协商好的临时端口号，这是FTP客户随机选择的另一个端口号。FTP客户发起与FTP服务器的TCP连接，以建立数据通道，由于在建立数据通道时，FTP服务器被动等待FTP客户的连接，因此称为被动模式。
内容小结如下：
电子邮件
接下来我们更进一步说明上述的邮件发送和接收过程：
发送方的用户代理，作为SMTP客户与发送方邮件服务器中的SMTP服务器进行TCP连接，然后基于这条连接，是由SMTP协议来发送邮件给发送方邮件服务器，
发送方邮件服务器中的SMTP客户与接收方邮件服务器中的SMTP服务器进行TCP连接，然后基于这条连接，使用SMTP协议来发送已收到的待转发邮件给接收方邮件服务器，
接收方的用户代理，作为POP3客户与接收方邮件服务器中的POP3服务器进行TCP连接。然后基于这条连接，需要POP3协议，从接收方邮件服务器读取邮件，
可以看到左边这是邮件发送协议的使用范围，包含发送方用户代理到发送方邮件服务器，以及发送方邮件服务器到接收方邮件服务器这两部分，右边这是邮件读取协议的使用范围，只有接收方用户代理到接收方邮件服务器这一部分。
接下来我们介绍属于邮件发送协议的简单邮件传送协议SMTP的基本工作原理。
我们以发送方邮件服务器，使用SMTP协议给接收方邮件服务器发送待转发的邮件为例：
发送方邮件服务器周期性的扫描邮件缓存，如果发现有待转发的邮件，则发送方邮件服务器中的SMTP客户会与接收方邮件服务器中的SMTP服务器进行TCP连接，端口号为25（熟知端口号），之后SMTP客户就可以基于这条TCP连接给SMTP服务器，发送SMTP命令，共14条。SMTP服务器也会给SMTP客户发送相应的应答，共21种。
SMTP客户与服务器之间通过命令与应答的交互方式，最终实现SMTP客户发送邮件给SMTP服务器。
接下来我们就要简单介绍一下该过程：
当TCP连接建立成功好后SMTP服务器会主动推送服务就绪应答给SMTP客户。应答代码220后面可能跟有描述信息
SMTP客户收到该应答后，向服务器表明身份，告知自己SMTP服务器的域名，具体命令为HELLO旗号为命令参数
SMTP服务器若认为身份有效，则发回应答代码250，否则发回其他代码。例如421表示服务不可用
SMTP客户收到该应答后，使用命令MAIL FROM来告诉服务器邮件来自何方。
SMTP服务器若认为合理，则发回应答代码250，否则发回其他错误代码
SMTP客户收到该应答后，使用命令RCP TO来告诉服务器邮件去往何方，也就是收件人邮箱
SMTP服务器中，如果有该收件人邮箱，则发回应答代码250，否则发回其他错误代码。
SMTP客户收到该应答后，使用DATA命令来告诉服务器，自己准备发送邮件内容了，
SMTP服务器如果准备好接收发回应答代码354，否则发回其他错误代码。
SMTP客户收到该应答后，就向服务器发送邮件内容，SMTP客户发送完邮件内容后，还要发送结束符 SMTP服务器若收件成功，则发回应答代码250，否则发回其他错误代码。
SMTP客户收到该应答后，使用命令QUIT向服务器请求断开连接，
SMTP服务器发回应答代码221，表示接受请求，并主动断开连接。
需要说明的是为了简单起见，我们省略了可能需要的认证过程，还省略了应答代码后面一般都跟随的简单描述信息，不同的SMTP服务器给出的相同应答代码，其后面跟随的描述信息可能不同。
接下来我们介绍电子邮件的信息格式，电子邮件的信息格式并不是由SMTP协议定义的，而是在RFC 822文档中单独定义。该文档已在2008年更新为RFC 5322，
一个电子邮件有信封和内容两部分，而内容又由首部和主体两部分构成。
首部和主体的信息都需要由用户来填写。首部中包含有一些关键字，后面加上冒号，例如关键字FROM后面填入发件人的电子邮件地址，一般由邮件系统自动填入
关键字TO，后面填入一个或多个收件人的电子邮件
关键字CC后面填入一个或多个收件人以外的抄送人的电子邮件地址，抄送人收到邮件号，可看可不看邮件，可回可不回邮件
关键字SUBJECT，后面填入邮件的主题，它反映了邮件的主要内容，很显然最重要的关键字是To和SUBJECT，他们往往是必填选项
用户写好首部后，邮件系统将自动的将信封所需的信息提取出来，并写在信封上，所以用户不需要填写电子邮件信封上的信息
在填写完首部各关键字的内容号，用户还需要撰写邮件的主体部分，这才是用户想传递给收件人的核心信息。
SMTP协议只能传送ASCII文本数据，不能传送可执行文件或其他的二进制对象。
也就是说SMTP不能传送带，有图片、音频或视频数据的多媒体邮件，并且许多其他非英语国家的文字，例如中文、俄文，甚至带有重音符号的法文或德文，也无法用SMTP传送。
为解决SMTP传送非ASCII文本的问题，提出了多用途因特网邮件扩展MIME。如图所示SMTP协议只能传送ASCII文本数据，假设发送方发送到电子邮件中包含有非ASCII数据，则不能直接使用SMTP进行传送，需要通过MIME进行转换，将非ASCII数据转换为ASCII数据，然后就可以使用SMTP进行传送了。接收方也要使用MIME对接收到的ASCII数据进行逆转换，这样就可以得到包含有非ASCII数据的电子邮件。
为了实现这种转换，MIME增加了5个新的邮件首部字段，这些字段提供了有关邮件主体的信息，定义了许多邮件内容的格式，对多媒体电子邮件的表示方法进行了标准化，定义了传送编码可对任何内容格式进行转换，而不会被邮件系统改变。实际上MIME不仅仅用于SMTP，也用于后来的同样面向ASCII字符的超文本传送协议HTTP。
接下来我们介绍涉及邮件读取的相关内容:
POP3和IAMP4都采用基于TCP连接的客户服务器方式。TOP3是用熟知端口110，IAMP使用熟知端口143
现在越来越多的用户使用基于万维网的电子邮件，通过浏览器登录邮件服务器万维网网站，就可以撰写、收发、阅读和管理电子邮件，这种工作方式与IAMP很类似，不同的是用户计算机无需安装专门的用户代理程序，也就是电子邮件客户端软件，只需要使用通用的万维网浏览器即可。
邮件服务器网站通常都提供非常强大和方便的邮件管理功能，用户可以在邮件服务器网站上管理和处理自己的邮件，而不需要将邮件下载到本地进行管理。
我们来举例说明基于万维网的电子邮件应用，根据上图：
假设用户A和B都使用网易邮件服务器，用户A要给用户B发送邮件，用户A需要浏览器登录邮件服务器网站撰写并发送邮件给用户B。用户B也使用浏览器登录邮件服务器网站读取收到的邮件。用户A和B在发送和接收邮件时，与服务器之间使用的都是HTTP协议，而不需要使用我们之前介绍过的SMTP和POP3协议。HTTP协议是超文本传送协议。
再来看另一种情况，假设用户A使用网易邮件服务器，用户C使用谷歌邮件服务器，用户A要给用户C发送邮件，用户A需要浏览器登录自己的邮件服务器网站，撰写并发送邮件给用户C，使用的是HTTP协议。用户A的邮件服务器，需要SMTP将邮件发送给用户C的邮件服务器。用户C也使用浏览器，登录自己的邮件服务器网站，读取收到的邮件，使用的也是HTTP协议。
内容小结如下：
万维网WWW
万维网并非某种特殊的计算机网络，它是一个大规模的、联机式的信息储藏所，是运行在因特网上的一个分布式应用，他利用网页之间的超链接，将不同网站的网页链接成一张逻辑上的信息网。
万维网是欧洲粒子物理实验室的蒂姆伯纳斯·李Tim Berners-Lee，最初于1989年3月提出的
1993年2月诞生了世界上第一个图形界面的浏览器Mosaic。1995年著名的网景浏览器上市，目前比较流行的浏览器有Chrome浏览器，火狐浏览器，Safari浏览器，欧朋Opear浏览器，IE浏览器
浏览器最重要的部分是渲染引擎，也就是浏览器内核，负责对网页内容进行解析和显示，这是上述各浏览器使用的内核，
不同的浏览器内核对网页内容的解析也有所不同因此。同一网页在不同内核的浏览器里的显示效果可能不同，
网页编写者需要在不同内核的浏览器中测试网页显示效果。
接下来我们举例说明万维网应用，我们在用户主机中使用浏览器来访问湖南科技大学的万维网服务器，也就是访问湖南科技大学的官方网站，我们在浏览器的地址栏中输入湖南科技大学官方网站的域名，并按下回车键后，浏览器将发送请求报文给服务器，服务器收到请求报文后执行相应操作，然后给浏览器发回响应报文，浏览器解析并渲染响应报文中的内容，这样我们就可以看到网站首页了。
为了方便的访问在世界范围的文档，万维网使用统一资源定位符URL，来指明因特网上任何种类资源的位置，统一资源定位符的一般形式，由以下4个部分组成，分别是协议、主机、端口、路径。
我们之前在浏览器地址栏中输入的是湖南科技大学官方网站的域名，目的是获取网站首页的内容，其对应的统一资源定位符如图所示。当我们点击网页中的某个超链接时，将跳转到另一个网页，可以看到这是该网页相应的统一资源定位符，其中协议主机和端口与网站首页相同，不同的是路径和网页文件。
万维网文档一般由HTML、CSS、JAVASCRIPT编写，由浏览器内核负责解释和渲染。
超文本传输协议HTTP
HTTP定义了浏览器即万维网客户进程，怎样向万维网服务器请求万维网文档，以及万维网服务器怎样把万维网文档传送给浏览器。
我们来举例说明，我们使用用户主机来访问湖南科技大学的万维网服务器，可以看成是用户主机中的浏览器进程即客户进程，与服务器中的服务器进程，基于因特网的通信。浏览器进程，首先发起与服务器进程的TCP连接，使用熟知端口号80，基于这条已建立好的TCP连接，浏览器进程向服务器进程发送HTTP请求报文，服务器进程收到后执行相应操作，然后给浏览器进程发回HTTP响应报文
HTTP1.0，采用非持续连接方式，在该方式下，每次浏览器要请求一个文件都要与服务器建立TCP连接，当收到响应后就要立即关闭连接。
我们来举例说明，这是客户与服务器之间通过三报文握手进行TCP连接。在这三个报文中的最后一个报文的数据载荷部分，携带有HTTP请求报文。服务器收到后给客户发回HTTP响应报文，这是一次请求和响应所耗费的时间，即为往返时间RTT，这又是一次请求和响应所耗费的时间，RTT，这是文档的传输时延。可以看到请求一个万维网文档所吸的时间为两倍的RTT加文档的传输RTT，每请求一个文档，就要有两倍RTT的开销。
若一个网页上有很多引用对象，例如图片等，那么请求每一个对象都需要额外花费两倍的RTT的时间。为了减少时延，浏览器通常会建立多个并行的TCP连接，同时请求多个对象，但是这会大量占用万维网服务器的资源，特别是万维网服务器，往往同时服务于大量客户的请求，这会使其负担很重。
HTTP1.1采用持续连接方式，在该方式下，万维网服务器在发送响应后，仍然保持这条连接，使同一个客户和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文，这并不局限于传送同一个页面上引用的对象，而是只要这些文档都在同一个服务器上就行。为了进一步提高效率，HTTP1.1的持续连接，还可以使用流水线方式工作，且浏览器在收到HTTP的响应报文之前，就能够连续发送多个请求报文，这样的接一个的请求报文到达服务器号，服务器就发回一个接一个的响应报文，这样就节省了很多个RTT时间，使TCP连接中的空闲时间减少，提高了下载文档的效率。
接下来我们介绍HTTP的报文格式：
HTTP的请求报文支持以下方法：
再来看HTTP响应报文的格式：
除状态行外，HTTP响应报文的其他部分，与HTTP请求报文格式的对应部分是相似的
我们举例说明，响应报文装常见的状态行：
该状态行表示服务器接受了请求，HTTP1.1表示版本，202是状态吗，ACCEPTED是短语，也就是对状态码的简单描述，该状态行表示请求错误
而该状态行表示找不到所请求的页面。一般来说，浏览器并不会直接显示出服务器发来的这些状态和信息，而是以更友好的形式向用户告知服务器所返回的状态信息。
例如当我们访问某些网站时，浏览器可能会显示类似该图所示的提示信息，其背后的本质是浏览器收到了包含这条状态行的响应报文。
在我们访问网站时，浏览器通常会使用Cookie在服务器上记录用户信息，早期的万维网应用非常简单，仅仅是用户查看存放在不同服务器上的各种静态的文档，因此 HTTP被设计成为一种无状态的协议，这样可以简化服务器的设计。
现在用户可以通过万维网进行各种复杂的应用，如网上购物、电子商务等，这些应用往往需要万维网服务器能够识别用户。例如我们使用浏览器，在某个网站上已经注册了自己的账号，当在该网站上登录自己的账号时，除了输入用户名和密码外，我们还可以选择记住我选项，这样当我们下一次使用该浏览器再次访问该网站时，网站可以自动识别出，我们而不用我们再次输入账号信息，
Cookie提供了一种机制，使得万维网服务器能够记住用户，而无需用户主动提供用户标识信息。也就是说 Cookie是一种对无状态的HTTP进行状态化的技术。
我们来举例说明Cookie的工作原理：
用户主机中的浏览器进程，首先与万维网服务器中的服务器进程建立TCP连接
当用户的浏览器进程初次向服务器进程发送HTTP请求报文时，服务器进程就会为其产生一个唯一的Cookie识别码，并以此为索引，在服务器的后端数据库中创建一个项目，用来记录该用户访问该网站的各种信息
接着就会给浏览器进程发回HTTP响应报文，在响应报文中包含有一个首部字段为 SET Cookie的首部行，该字段的取值就是Cookie识别码
当浏览器进程收到该响应报文之后，就在一个特定的Cookie文件中添加一行，记录该服务器的域名和Cookie的识别码。
当用户再次使用浏览器访问这个网站时，每发送一个HTTP请求报文，浏览器都会从Cookie文件中取出该网站的Cookie识别码，并放到HTTP请求报文的Cookie首部行中，服务器根据Cookie识别码就可以识别出该用户并返回该用户的个性化网页。
接下来我们介绍万维网缓存与代理服务器：
我们来举例说明：当校园网中的某台主机要访问因特网上的原始服务器时，他首先会向校园网中的代理服务器发送请求，若代理服务器中存放有所请求的对象，则代理服务器会向该主机发回包含所请求对象响应。若代理服务器中没有所请求的对象，则代理服务器会向因特网上的原始服务器发送请求，原始服务器将包含有所请求对象的响应，发回给代理服务器，代理服务器将该响应存入WEB缓存，然后给主机发回该响应。
可以想象如果WEB缓存的命中率比较高，则路由器R1和R2之间的链路上的通信量将大大减少，因而可以减少校园网各主机访问因特网的时延。
有的同学可能会有这样的疑问，这是原始服务器中的某个文档，这是该文档在代理服务器中的副本，假设原始服务器中的该文档已被更改之后，校园网中的某台主机要请求该文档，他首先向校园网中的代理服务器发送请求，代理服务器找到该文档后，将其封装在响应报文中发回给主机，这样主机所请求到的文档与原始服务器中的文档就不一致了。
实际上原始服务器通常会为每个响应的对象设定一个修改时间字段和一个有效日期字段：
当校园网中的某台主机要请求原始服务器中的该文档时，他首先向校园网中的代理服务器发送请求
若代理服务器中的该文档未过期，则代理服务器将其封装在响应报文装发回给主机，若代理服务器中的该文档已过期，则代理服务器会向因特网上的原始服务器发送请求。
在请求报文中包含有一个首部字段为if-modified -since的首部行，该字段的取值就是该文档的修改日期，原始服务器根据该文档的修改日期，就可判断出代理服务器中存储的该文档是否与自己存储的该文档一致
如果一致则给代理服务器发送，不包含实体主体的响应，状态码为304，短语为not modified代理服务器重新更新该文档的有效日期，然后将该文档封装在响应报文中发回给主机
如果不一致，则给代理服务器发送封装，有该文档的响应报文，如图所示，这样代理服务器就更新了该文档，然后将更新后的该文档封装在响应报文中发回给主机。
内容小结：
————————————————
版权声明：本文为CSDN博主「十八岁讨厌编程」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/zyb18507175502/article/details/128999819
