【计算机网络】二应用层
1、应用层协议原理
1.1网络应用程序体系结构
网络体系结构是固定的，但是应用程序体系结构是由应用程序研发者设计的。
目前两种主流体系结构：客户-服务器体系结构（C/S）和对等（P2P）体系结构。
1.1.1C/S体系结构
其中客户是请求方，服务器是服务方
特点：
（1）服务器是一直运行着的。
（2）客户之间是不直接通信的
（3）服务器具有固定的、周知的地址（IP地址）
其非常著名的应用包括Web、FTP、Telnet和电子邮件。
但是在很多大型客户请求下，一台服务器是不够的，所以配备大量主机的数据中心常被用于创建强大的虚拟服务器。
1.1.2P2P体系结构
特点：
（1）在该体系结构之下，对位于数据中心的专用服务器有最小的依赖。
（2）应用程序在间断的主机对之间使用直接通信，这些主机对被称为对等方。
（3）这些对等方不为服务提供商所拥有。却为用户控制的桌面所有。
（4）自扩展性。每个对等方节点都能够帮助服务器来分发文件。也就是说，当一 个节点接收到文件数据时，它可以利用自己的上载能力重新将数据分发给其他节点。
（5）成本有效：不需要庞大的服务器基础设施和服务器带宽。
1.2进程通信
进行通信的实际上是进行，而不是程序。进程被认为是运行在端系统中的一个程序。
在同一台端系统中，进程使用进程间通信机制相互通信，通信规则由操作系统觉得。
当在不同端系统上进心通信的时候，就需要跨越计算机网络交换报文。发送进程生成并发送报文，接收进程接收报文并可能会做出响应。
1.2.1客户和服务器进程
网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。在每一对进程中，一个标识为客户，一个表示为服务器。通常情况下，发起通信的进程被标识为客户，等待联系的进程是服务器。
1.2.2进程与计算机网络之间的接口
进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。
套接字是同一台主机内应用层与运输层之间的接口（可编程接口），也称为应用程序和网络之间的应用程序编程接口。
应用开发者可以控制在应用层中的一切，但是对于运输层，只能确定使用的协议，有时可以设定几个运输层参数。
1.2.3进程寻址
要想实现分组的发送，接收进程需要进行唯一标记：主机的地址和定义在目的主机中接收进程的标识符。
主机由其IP地址标识。此外，发送进程还必须指定运行在接收主机上的接收进程，这就需要端口号。如WEB服务器用端口号80；邮件服务器进程用端口号25来标识。
1.3可供应用程序使用的运输服务
网络提供的运输服务分类：可靠数据传输、吞吐量、定时和安全性
1.3.1可靠数据传输
例如在金融、电子邮件、web文档传输等应用中，数据丢失造成的后果是严重的。所以必须确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端，如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。
但是还有一些应用，比如多媒体应用，是可以允许一小部分的数据丢失，这就是容忍丢失的应用。
1.3.2吞吐量
带宽敏感的应用就是对具有吞吐量要求的应用。概述中讲到的吞吐量其实是随着时间波动的，但是运输层协议能够以某种特定的速率提供确保的吞吐量。
带宽敏感的应用具有特定的吞吐量要求，而弹性应用就可以根据情况或多或少地利用可供使用的吞吐量。
1.3.3定时
这种服务对交互式实时应用具有吸引力。
1.3.4安全性
运输协议能够为应用程序提供一种或多种安全性服务。比如数据的加解密。
1.4因特网提供的运输服务
因特网（更一般的是TCP/IP网络）为应用程序提供了两个运输层协议TCP和UDP。
1.4.1TCP服务
TCP服务模型包括面向连接服务和可靠数据传输服务。
（1）面向连接服务
在报文进行传输之前需进行握手阶段，让客户和服务器交换运输层控制信息，让他们为大量分组的到来做好准备。握手之后，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的（可以同时收发），在结束报文发送的时候，必须拆除连接。
（2）可靠的数据传输服务
通信进程可以依靠TCP，无差错、按适当顺序交付所有发送的数据。
此外，TCP协议还具有拥塞控制机制，能够为因特网整体带来好处。当发送方和接收方之间网络出现拥塞的时候，TCP的拥塞控制机制就会抑制发送进程。
1.4.2UDP服务
UDP是一种不提供不必要服务的轻量级运输协议。与TCP提供服务恰好相反，UDP无连接、不可靠也没有拥塞控制机制。
1.4.3因特网运输协议所不提供的服务
目前的因特网运输层协议并没有提供吞吐量和定时保证服务。
1.5应用层协议
应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文：
交换的报文类型（请求报文和响应报文）、各种报文类型的语法（如字段描述）、字段的语义（字段中信息的含义）、一个进程和是以及如何发送报文（响应的规则）
应用层协议也有公用和专用之分。
应用层协议只是网络应用中的一部分。
2、Web和HTTP
web最具有吸引力的就是它的按需操作。当用户需要时，就可以获得他们所需要的内容。
2.1HTTP概况
web的应用层协议是超文本传输协议，也就是HTTP协议，这是web的核心。
HTTP分为客户程序和服务器程序两部分实现。客户程序和服务器程序运行在不同的端系统上，通过交换报文进行会话。
URL由两部分组成：存放对象的服务器主机名和路径名。
HTTP定义了WEB客户向web服务器请求web页面的方式以及传送页面的方式。
HTTP使用TCP作为他的运输协议。所以需要事先建立连接。
HTTP服务器不保存关于客户的任何信息，所以是一个无状态协议。也就是服务器不会因为一个客户在短时间内请求了相同的第二次就不去做出响应。跟概述中说的一样，web服务器是一只打开的，具有一个固定的ip地址。
2.2非持续连接和持续连接
在长时间范围内通信的情况下，在C/S交互过程中，如果每个请求是经一个单独的tcp连接发送，那么就是非持续连接；如果所有的请求是通过一个相同的TCP连接发送，那就是持续连接。
HTTP既可以使用非持续连接，也可以使用持续连接。默认情况下是持续连接。
2.2.1采用非持续连接的HTTP
每个TCP连接在服务器发送一个对象后关闭。每个TCP连接只传输一个请求报文和一个响应报文。
比如请求一个有10个JPG文件的WEB页面，就有11个对象，这样的话就需要产生11个TCP连接。
RTT往返时间：一个短分组从客户到服务器然后再返回客户的时间。RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。
三次握手的前两部分时间是一个RTT，第三部分结合请求文件一起将请求发送出去，再由服务器确认接收并且返回文件。所以总时间是2RTT+传输时间。
对于每一个连接，客户和服务器都要分配TCP的缓冲区和保持TCP变量，这就带来了很大的负担。
2.2.2采用持续连接的HTTP
服务器在发送响应后保持该TCP连接打开。如上页面的请求就可以使用单个连续TCP连接进行。
如果一条连接经过一定时间间隔仍未被使用，HTTP服务器就关闭该连接。
2.3HTTP报文格式
2.3.1HTTP请求报文
第一行叫做请求行，后继的部分叫做首部行。
请求行有3段：方法字段、URL字段和HTTP版本字段。方法字段有：GET、HOST、HEAD、PUT、DELETE。当浏览器请求一个对象的时候，采用GET方法。URL字段包括请求对象的标识，如图正在请求/somedir/page.html对象。版本字段就是HTTP/1.1版本
首部行Host指明了对象所在的主机。
Connection首部行表明是持续连接还是非持续连接。如图close则是非持续连接。
User-agent首部行用来指明用户代理，也即是向服务器发送请求的浏览器的类型。（服务器可以向不同的用户代理浏览器发送相同对象的不同版本）
Accept-language首部行表示用户想得到的语言版本，如图是法语版本。
如图是HTTP请求报文的通用格式。最下面的实体主体是跟方法字段相关联的，如果是GET方法，就为空；如果是HOST方法，这里面就是要传过去的参数。但是表单生成的请求报文也不是必须要POST方法，也可以在URL中携带参数。HEAD方法常用于调试跟踪。
2.3.2HTTP响应报文
三部分组成：一个初始状态行、首部行和实体主体。
实体主体是报文的主要部分，包含了所请求的对象本身。
状态行：协议版本字段、状态码、相应状态信息。
首部行Connection:close表示发送完报文之后就关闭tcp连接。Date是服务器产生并发送该响应报文的日期和时间。
Server：产生该报文的服务器
Last-Modified指明了最后修改的日期和时间
Content-Length指示了被发送对象中的字节数
Content-Type表示了传送对象的类型，如图是HTML文本
2.4用户与服务器的交互：cookie
允许把内容与用户身份联系起来。运行站点对用户进行跟踪。
cookie技术的组件：
（1）在HTTP响应报文中的一个cookie首部行
（2）在HTTP请求报文中的一个cookie首部行
（3）在用户端系统保留有一个cookie文件，并由用户的浏览器进行管理
（4）位于web站点的一个后端数据库
用户在首次访问服务器的时候需要提供一个标识符，然后服务器给的响应报文中会带有set-cookie，这样的话，之后一段时间，用户再访问这个服务器的时候就会将set-cookie这一行加进去，那么就可以在无状态HTTP中实现“记录”。
2.5web缓存
Web缓存器也叫代理服务器。既充当客户端又充当服务器。
浏览器先与缓存器建立连接，如果缓存器有请求的对象，则由缓存器直接发送给浏览器；如果缓存器中没有该对象，那么此时缓存器用作客户端向浏览器的初始请求服务器发送请求，得到对象之后，自己备份一份，然后发送给浏览器。
web缓存器的使用，可以从整体上减少因特网上的web流量，也可以减少对客户端请求的响应时间。
2.5条件GET方法
考虑到在缓存中的对象可以已经被修改过了，那么GET方法就是来解决这个问题的。
（1）请求报文使用GET方法（2）请求报文中包含一个If-Modified-Since首部行，那么这个HTTP请求就是一个条件GET请求报文。
在第一次请求过后，缓存器中有一个备份。一段时间之后再次请求相同对象的时候，缓存器会先发送一个条件GET执行最新检查，主要是If-Modified-Since首部行的检查，其中该首部行的值是首次服务器发送给缓存器的响应报文中的Last-Modified首部行内容，如果条件GET告诉缓存器没有改变，那么缓存器才会去发送对象。但是这时的响应报文中不会再将对象显示出来，那样太浪费带宽了，会将状态码改成304Not Modified表示没有被修改，也就是告诉缓存器可以把自己缓存的备份发送出去。
3、因特网中的电子邮件
电子邮件是一个异步通信媒介。
主要组成部分：用户代理、邮件服务器、简单邮件传输协议。
邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮箱。当用户需要从其中读取自己邮件的时候，就要提供一些口令来鉴别。
SMTP是因特网电子邮件中主要的应用层协议，它使用TCP可靠数据传输服务。
SMTP既有客户端又有服务器端，用户从发送方的邮件服务器发送报文到接收方的邮件服务器。
3.1SMTP
发送方用户代理将邮件发给发送方邮件服务器（客户端），存放在发送方邮件服务器的队列中。如果接收方邮件服务器（服务器端）在线，那么客户端发送TCP连接，握手之后进行发送，过服务器端没有在线，那么客户端需要等待，超过一定时间之后，会放弃发送并告知发送方用户。如果还需要继续发送邮件，那么就在同一条TCP连接中发送。
3.2与HTTP的对比
相同点：都是从一台主机向另一台主机传送文件；持续的HTTP和SMTP都是持续连接
不同点：HTTP是一个拉协议（常用于从web服务器上装载信息），而SMTP是一个推协议（发送邮件服务器将文件推向接收邮件服务器）；SMTP对内容限制较多；HTTP把每个对象封装到它自己的HTTP响应报文中，而SMTP则是把所有报文对象放在一个报文中。
3.3邮件报文格式
必须包含一个From：首部行和一个To：首部行。首部行和报文体中用空行隔开。
3.4邮件访问协议
将邮件服务器上的报文传送给本地PC。
目前流行的邮件访问协议：第三版的邮局协议（POP3）、因特网邮件访问协议（IMAP）以及HTTP。
SMTP用来将邮件从发送方的邮件服务器传输到接收方的邮件服务器；也可以将邮件从发送方的用户代理传输到接收方的邮件服务器。
POP3用来将邮件从接收方的邮件服务器传送到接收方的用户代理。
3.4.1POP3
当客户打开一个到邮件服务器的TCP连接之后，POP3就会开始工作：特许、事务处理和更新。
特许阶段类似身份识别阶段：用户代理发送用户名和口令进行鉴别；
事务处理阶段：用户代理取回报文，并且可以进行一些额外操作（做删除标记或者取消删除标记）；
更新阶段：在要结束POP3会话的时候，邮件服务器会根据那些标记进行更新。
事务处理过程中有两种方式：下载并删除和下载并保留。
下载并删除方式是指当用户在一台机器上接收访问之后，该邮件报文就会从邮件服务器中删除，那么就不能从其他机器中进行访问了。比如如果在电脑上访问邮件之后，在手机上就会发现这个报文已经被删除了。
下载并保留方式是说访问完之后，仍会保留在邮件服务器中。
3.4.2IMAP
POP3访问时，用户将邮件下载到本地主机之后，就能建立邮件文件夹，将下载的邮件放到该文件夹中。但是这种文件夹和报文存放到本地主机上的话，对于远程访问是不友好的，所以IMAP就是解决这个问题的。
特点：
（1）IMAP服务器能把每个报文与一个文件夹联系起来
（2）为用户提供了在远程文件夹中查询邮件的命令
（3）具有允许用户代理获取报文组件的命令（比如用户不太想接收下载所有邮件）
3.4.3基于Web的电子邮件
这种情况下，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信都用HTTP进行。
4、DNS：因特网的目录服务
主机的一种标识方法是用主机名（不定长，难处理），所以也可以用IP地址（4字节）。
4.1DNS提供的服务
DNS域名系统的主要任务：能进行主机名到IP地址转换的目录服务。
定义：（1）DNS是一个由分层DNS服务器实现的分布式数据库；（2）DNS是一个使得主机能够查询分布式数据库的应用层协议。
DNS通常是被其他应用层协议所使用的，将用户提供的主机名解析为IP地址。
DNS提供的服务：
（1）主机名到IP地址的解析；（2）主机别名；（3）邮件服务器别名；（4）负载分配（一个IP地址集合与一个规范主机名相联系）
4.2DNS工作机理概述
应用程序需要进行解析的时候，调用DNS客户端，指明需要解析的主机名；
用户主机上的DNS接收到之后向网络中发送一个DNS查询报文（UDP)；
用户主机接收到DNS回答报文，并传递给应用程序。
但是目前因特网中，不能只有一个DNS服务器：
（1）单点故障：如果这一个服务器崩溃，那么整个因特网将瘫痪；
（2）通信容量：要处理的太多了
（3）远距离的集中式数据库：位置不能偏心
（4）维护：主机很多，那么需要的记录也就很多
所以，应该采用分布式的设计方案。DNS是一个在因特网上是吸纳分布式数据库的精彩范例。
4.2.1分布式、层次数据库
为了处理扩展性问题，DNS使用了大量DNS服务器，以层次方式分布在世界各地。
主要有：**根DNS服务器、顶级域DNS服务器（TLD）、权威DNS服务器。
还有一个对其很重要的本地DNS服务器。每个ISP都有一台本地DNS服务器。本地DNS服务器通常邻近本主机。
请求流程：
在本例子中，一共发送了4份查询报文和4份回答报文。利用DNS缓存就可以减少这样的查询流量。其中cis.poly.edu到dns.poly.edu发出的查询是递归查询，其他的是迭代查询。
如图则是DNS递归查询，在这种情况下，根DNS的任务比较大。
4.2.2DNS缓存
在一个请求链中，当某DNS服务器接收一个DNS回答时，能将该回答中的信息缓存在本地存储器中。这样的话，当请求同相同主机名的时候，即使不是权威服务器，也可以很快的回答。但是由于主机和主机名与IP间的映射不是永久的，所以DNS服务器在一段时间之后就会丢弃缓存的信息。
4.3DNS记录和报文
共同实现DNS分布式数据库的所有DNS服务器存储了资源记录(RR)。RR记录格式（NAME,TYPE,VALUE,TTL）
其中TTL是该记录的生存时间，决定了资源记录应当从缓存中删除的时间。
NAME和VALUE的值取决于TYPE。
（1）如果TYPE=A，那么NAME是主机名，VALUE就是对于的IP地址。
（2）如果TYPE=NS，那么NAME是个域，VALUE是个知道如何获得该域中主机IP地址的权威DNS服务器的主机名。这个记录用于沿着查询链来路由DNS查询。
（3）如果TYPE=CNAME，那么VALUE是别名为NAME的主机对应的规范主机名。
（4）如果TYPE=MX，那么VALUE是个别名为NAME的邮件服务器的规范主机名。
4.3.1DNS报文
DNS报文只有DNS查询报文和DNS回答报文，并且有着相同的格式。
（1）首部区域：12字节。
标识符：16bit，用于表示该查询。会复制到对于的回答报文中。其中有1bit用来区别查询还是回答报文。
（2）问题区域：包含正在进行的查询信息：名字字段（正在被查询的主机名子）、类型字段（正在被询问的问题类型）
（3）回答区域：包含了对最初请求的名字的资源记录。
（4）权威区域：包含了其他权威服务器的记录
（5）附加区域：包含了其他有帮助的记录
5、P2P应用
常用两种应用：文件分发（自扩展性）、分布在大型对等方社区中的数据库（分布式散列表DHT）
5.1P2P文件分发
从单一服务器向大量主机分发一个大文件，这种情况下，主机承受了极大的负担并且消耗了大量的服务器带宽。
5.1.1P2P体系结构的扩展性
将C/S与P2P进行对比。
在C/S模式下：文件大小为F比特，对等方有N个，那么一个需要分发NF比特。服务器上载速率为us，所以分发这个文件的时间至少是NF/us；dmin为最小下载速率的对等方的下载速率，那么最小分发时间是F/dmin。所以该体系的分发时间Dcs=max{NF/us,F/dmin}
在P2P模式下：
每个对等方都可以帮助服务器分发该文件。当一个对等方接收到某些文件数据，它能够使用自己的上载能力重新将数据分发给其他对等方。
首先服务器需要将该文件至少发送一次：F/us；同样的，具有最低下载速率的对等方不能少于F/dmin分发时间，所以最小分发时间至少为F/dmin；系统总上载能力是us+u1+u2+…+un，系统一共为这些对等方分发FN比特，所以分发时间是FN/(us+u1+u2+…+un)。所以P2P的分发时间为：Dp2p=max{F/us,F/dmin,NF/(US+U1+U2+…+UN)。
随着对等方数量的增加，CS模式下的分发时间是线性增长的。
具有P2P体系结构的应用程序是能够自扩展的，是因为对等方除了是比特的消费者之外还是它们的重新分发者。
5.1.2BitTorrent
是一种用于文件分发的流行P2P协议。将参与一个特定文件分发的所有对等方的集合称为一个洪流。洪流中的对等方彼此下载等长度的文件块。
每个洪流都有一个基础设施结点——追踪器。追踪器跟踪正在参与洪流中的对等方。
与一个对等方成功创建一个TCP连接的对等方为“邻近对等方”，这是不断更新的。
如图，不同的对等方获得的块子集可能不一样。ALICE获得他的邻近对等方的块子集列表之后，就可以查看自己所没有的块子集，然后发出请求。
alice需要做出一些决定：从邻居请求哪些块呢？（最稀缺优先）向哪些向他请求块的邻居发送？（能够以最高速率向他提供数据的邻居，会不断更新）
6、视频流和内容分发网
6.1因特网视频
预先录制好的视频放置在服务器上，用户按需向服务器发送请求来进行观看。
可以用比特率来衡量视频质量。比特率越高，图像质量越好。
6.2HTTP和DASH
流式视频周期性地从客户应用程序缓存中抓取帧，所以流式视频应用接收到视频就进行播放，同时缓存该视频后面的部分。
在HTTP流中，视频指示存储在HTTP服务器中作为一个普通的文件。
对不同的用户提供不同的视频编码版本，这就是经HTTP的动态适应性流DASH。
使用DASH之后，每个视频版本存储字啊HTTP服务器中，都有一个不同的URL。
6.3内容分发网
单一的大规模数据中心存在的问题：客户原理数据中心的话，速率会小；会要向一些ISP支付费用；单点故障问题。
所以几乎所有主要的视频流公司都利用内容分发网CDN。在它的服务器中存储副本。
CDN分为专用CDN和第三方CDN。
CDN采用的服务器安置原则：
深入、邀请做客
深入：在接入ISP中部署服务器集群来深入到ISP的接入网中，这样可以靠近用户，减少端用户和CDN集群之间的链路和路由器的数量，改善用户感受的时延和吞吐量。但是，维护和管理集群成为挑战。
邀请做客：通常将集群设置在IXP（因特网交换点）。可以产生较低的维护和管理开销，但是用户感受的时延和吞吐量就没有深入原则那么好了
CDN使用一种简单的拉策略，如果客户向一个未存储该视频的集群请求某视频，那么集群会进行检索，同时会进行缓存。缓存满的时候，会删除不常使用的视频。