第二章-应用层

应用层协议原理

网络应用程序体系结构

客户-服务器体系结构

• 如web服务器：web服务器总是打开的用于服务来自浏览器的请求，web服务器接收到来自某客户对某对象的请求时它向该客户发送所请求的对象作为响应。这里注意该体系客户之间不是直接通信的。
• 该体系的另一个特征是该服务器具有固定周知的ip地址。
• 该体系的著名应用程序有web、ftp、telnet和电子邮件。
• 该体系的一大问题是如果流行的社交站点仅有一台服务器来处理所有请求，将很快变得不堪重负。为解决该问题将会配备大量主机的数据中心来创建虚拟服务器，如谷歌亚马逊等。

P2P体系结构

• 应用程序在间断链接的主机对之间会使用直接通信，这些主机对被称为对等方，这些对等方实际就是用户的电脑。因为是对等方直接通信而不通过一个专门的服务器，是对等方到对等方的，所以称为P2(谐音to)P。

进程通信

• 进行通信的实际上是进程而不是程序，两个不同端系统的进程通过跨越计算机网络交换报文来相互通信。
• 客户和服务器：web中客户浏览器进程和web服务器进程交换报文，此时客户浏览器进程是客户，web服务器进程是服务器；p2p中下载文件的是客户，上载文件在是服务器。
• 进程与计算机网络之间的接口：进程通过一个称为套接字的软件接口向网络发送/接受报文。套接字是应用层和传输层之间的接口。程序员可以控制套接字在应用层的一切，但是对套接字在运输层端几乎没有控制权。
  
• 进程寻址：和快递需要指名目的地一样，发送报文也要指名目标主机的地址，即我们熟知的ip地址。除此以外因为有很多应用程序运行在应用层上，需要决定我们的报文发送给哪个程序，所以还要指定接收进程的标识符，即端口号。

运输层提供的服务

• 运输层协议能够为调用它的应用程序提供大致四个服务：

1. 可靠数据传输
   可以避免之前讲过的分组丢失情况。如果运输层协议不提供可靠数据传输时，发送进程发送的某些数据可能不能够到达接收进程，这可以用于一些可以容忍丢失的应用；
2. 吞吐量
   运输层协议能够以某种特定的速率提供确保的可用吞吐量。比如如果使用这种服务，应用程序请求了Rbits/s的吞吐量，这个协议可以确保可用吞吐量总是至少为Rbits/s；
3. 定时
   比如确保发送方注入进套接字中的每个比特到达接收方的套接字不迟于100ms；
4. 安全性
   比如加密由发送进程传输的所有数据。

因特网提供的运输服务

• TCP提供面向连接的服务，即在应用层数据报文开始流动之前TCP让客户和服务器交换运输层控制信息，这个行为是为了提示客户和服务器马上开始大量分组了，作好准备。
• TCP还提供了可靠数据传送服务，通信进程能够依靠TCP进行无差错按适当顺序交付所有发送的数据，不会有字节的丢失和冗余。
• TCP还有拥塞控制机制，这种服务不一定为通信带来直接好处，但能为因特网带来整体好处。当发送接收方之间出现拥塞时，TCP的拥塞控制可以抑制发送进程。
• UDP仅提供最小服务，在两个进程通信前没有握手过程，提供不可靠数据传送服务，没有拥塞控制机制，到达接收进程的报文可能是乱序的
• TCP和UDP都缺少了对吞吐量和定时的保证，原因是为了保证速度。

应用层协议

• 应用层协议定义了1. 交换报文的类型（请求报文or响应报文） 2. 报文类型的语法（报文中的各个字段） 3. 字段的语义（字段中包含的信息的含义） 4. 一个进程何时以及如何发送报文。
• 应用程序和应用层协议是不一样的，比如Web是应用层的程序，而Web的协议是HTTP。所以协议实际是应用的一部分。

Web和HTTP

• Web页面是由对象组成的，一个对象是一个文件，比如一个HTML文件、一个JEPG图片，这些对象可以通过一个URL地址寻址。
• Web浏览器实现了HTTP客户端，Web服务器实现了HTTP的服务器端。
• HTTP使用TCP作为支撑它的运输协议。HTTP客户首先发起一个和服务器端的TCP连接。连接建立好后双方就可以通过套接字接口访问TCP。
• 注意：服务器给客户发送被请求的文件，并不会存储任何关于客户的状态信息，所以HTTP是一个无状态的协议。

持续和非持续连接

• 在很多应用程序里客户和服务器会在很长一段时间范围里通信，服务器会响应客户发送的每个请求。请求可以有规律的间隔发也可以一个接一个发出，但要是交互是经过TCP的，就分情况了：如果每次请求/响应都经过一个单独的TCP连接，这称为非持续连接；每次请求/相应都经过同一条TCP连接，称为持续连接。HTTP默认使用持续连接，但也可以使用非持续连接。
• 采用非持续连接的HTTP每次请求一个报文都要经历：发起TCP连接->发送请求报文->服务器响应报文->双方断开连接这些步骤。
  
• 如图所示，如果采用非持续连接，每次请求都要耗费响应时间2*RTT（往返时间）+接收时间。而持续连接在服务器发送响应后会保持该TCP连接打开，客户可以在单个TCP连接上一个接一个的发出对对象的请求。

HTTP报文格式

• 请求报文格式：第一行是请求行，后继的都叫首部行。请求行三个字段分别是：方法字段 URL HTTP版本。如果图的请求行意思就是浏览器使用HTTP/1.1版本请求一个对象/somedir/page.html。首部行第一行Host指明对象所在主机，Connection表示是否使用上面讲的持续连接，这里使用非持续连接。User-agent指明用户代理，即向服务器发送请求的浏览器类型。最后一行表示用户想得到的该对象的语言版本。
  
• 实际首部行的后面还会有一个实体，使用POST方法时会使用到该实体，此时向服务器请求的内容会依赖于实体。举例就是百度翻译，想翻译的内容会放到表单中。
• 用表单生成请求报文不是必须使用POST方法，HTML也经常使用GET方法并在表单字段中所请求的URL中
• HTTP响应报文由三个部分组成：一个初始状态行，6个首部行及实体体。状态行由协议版本字段、状态码和状态信息组成，首部行指示服务器产生并发送该响应报文的日期和时间。Server指示该报文是由一台Apache Web服务器长生，类似于HTTP请求报文中的User-agent。Last…指示了对象创建或最后修改的日期和时间。Content Length指示了被发送对象的字节数，Content Type指示出实体体中的对象是HTML文本。
  
  

cookie

• 前面说过HTTP服务器是无状态的，但是web站点又通常希望能识别用户（可能是为了限制用户的访问，也可能希望能把内容和用户身份联系起来）。所以HTTP使用了cookie，cookie允许站点对用户进行跟踪。
• cookie技术依赖四个组件：1. 在HTTP响应报文中的一个cookie首部行；2. 在HTTP请求报文中的一个cookie首部行；3. 在用户端系统中保留一个cookie文件，并由用户的浏览器管理；4. 位于web站点的一个后端数据库。
  

web缓存

• web缓存器扮演着计算机中cache的角色。浏览器请求一个服务器对象，会首先建立一个到Web缓存器的TCP连接然后发送请求，Web缓存器会查看是否有这个对象副本，如果有就直接返回该对象。如果没有就会打开与这个对象所在服务器的TCP连接，缓存器在这条连接上发送对该对象的HTTP请求。缓存器收到对象后会在本地存储一份副本，然后再发给用户。
• 注意web缓存器既是服务器又是客户

条件GET方法

• web缓存有个问题就是存放在缓存其中的对象副本可能是陈旧的
• HTTP协议有一个机制允许缓存器证实它的对象是新的，即条件GET方法。如果请求报文使用GET方法，并且请求报文中包含If Modified Since首部行，那就是条件GET方法。
  
• If Modified Since后面带的时间就是上次的修改时间，该GET报文告诉服务器仅当指定日期之后该对象被修改过才发送该对象。

FTP协议

• HTTP和FTP都是文件传输协议，但是FTP使用两个并行的TCP连接来传输文件，一个控制连接一个数据连接。控制连接用于在两个主机之间传输控制信息，如用户标识、口令等。数据连接用来发送真正的数据。
• FTP客户端首先在21号端口与服务器端发起一个用于控制的TCP连接，FTP客户端也通过该控制连接发送用户的标识和口令。FTP服务端从该连接上接到文件传输命令后发起一个到客户端的TCP数据连接，FTP再数据连接上传送文件，然后关闭连接。同一个会话期间如果客户需要另一个文件，FTP会打开另一个数据连接。也就是说控制连接是贯穿会话始终的。

电子邮件

• 从发送方的用户代理开始传送到发送方的邮件服务器，在传送到接收方的邮件服务器，然后再分发到接收方的邮箱中。当接收方要在邮箱中读取报文时包含他邮箱的邮件服务器会使用用户名和口令来鉴别他。
• 如果发送方的服务器不能将邮件交付给接收方的服务器，发送方的邮件会在邮件服务器中的一个报文队列中保持该报文并国会再尝试发送。
• SMTP是电子邮件的主要应用层协议，它使用TCP可靠数据传输服务。SMTP也有两个部分：运行在发送方服务器的客户端和运行在接收方服务器的服务器端。每台邮件服务器既运行SMTP的客户端也运行STMP的服务器端。
• 流程：发送端使用邮件待理并提供接收端的地址-用户代理发送报文到邮件服务器，报文被放在报文队列-邮件服务器中的SMTP发现了队列中的报文，开始创建运行到接收端服务器上SMTP的TCP连接-SMTP通过TCP连接发送报文-接收端服务器接收报文，然后把报文放到接收端的邮箱中-接收端使用代理阅读报文。

对比HTTP

• HTTP从Web服务器向Web客户传送文件；SMTP从一个邮件服务器向另一个邮件服务器传送文件。
• 传送文件时HTTP和SMTP都是用持续连接
• HTTP主要使用拉协议，即在方便的时候某些人在Web服务器上装载信息，用户使用HTTP从该服务器拉去这些信息，并且TCP连接是由想接收文件的机器发起的。SMTP是推协议，即发送邮件服务器把文件推向接收邮件服务器。
• SMTP要求每个报文使用7比特ASC码格式，HTTP没有这种限制。
• HTTP把每个对象封装到自己的HTTP响应报文里；SMTP把所有报文对象放在一个报文中。

邮件访问协议

• 用户代理不能使用SMTP取回报文，因为取报文是一个拉操作，而SMTP上面说过是一个推协议。通过引入特殊的邮件访问协议来解决这个问题：POP3、IMAP以及HTTP。

POP3

• 当用户代理（客户端）打开一个到邮件服务器（服务器端）端口110上的TCP连接后POP3就开始工作了。先是特许阶段，以用户名密码鉴别用户；再是事务处理阶段，用户代理取回报文，同时会作一些统计处理；最后更新阶段，出现在客户端发出quit命令后，结束POP3。
• POP3事务处理中用户代理发出一些命令，服务器对每个命令做出回答，回答有两种：+OK表示前面的命令正常；-ERR表示前面的命令出了差错。
• 使用POP3的用户代理通常被用户配置为下载并删除或下载并保留。使用下载并删除，用户代理会发出list、retr和dele命令。
  
• list让邮件服务器列出所有存储的报文的长度，然后retr取出邮件，dele删除邮件，最后quit退出。但是下载并删除方式的问题是如果删了一次以后就收不到该邮件了。使用下载并保留方式，用户代理下载邮件后，该邮件仍保留在邮件服务器上。

IMAP

• 使用POP3接收端可以将邮件下载在本地之后随意处理，但是移动用户更喜欢使用一个远程服务器上的层次文件夹，这样可以从任何一台机器上对所有报文进行访问。POP3做不到，POP3没有给用户提供任何创建远程文件夹并为报文指派文件夹的方法，IMAP应运而生。
• 当保温第一次到达服务器时，它与收件人的INBOX文件夹相关联，收件人能把邮件移到一个新创建的文件夹中进行操作。IMAP就为用户提供了创建文件夹以及将邮件从一个文件夹移到另一个文件夹的命令和在远程文件夹中按指定条件查询匹配邮件。。
• IMAP另一个特性是具有允许用户代理后取报文组件的命令，比如用户代理可以只读取一个报文的报文首部。

基于Web的电子邮件

• 比如谷歌、雅虎、hotmail等，这种服务用户代理就是浏览器，用户和它远程邮箱之间的通信都通过HTTP进行，哪怕从邮件服务器推到用户代理也是用HTTP。

DNS

• 识别主机有两个种方式，主机名（如www.yahoo.com）和IP地址，人类喜欢方便记忆的主机名，而路由器喜欢定长、有层次结构的IP地址。用一种能进行主机名到IP地址转换的目录服务折中一下，DNS应运而生。
• DNS一般是由其他应用层协议使用的，比如浏览器（HTTP客户）请求www.baidu.com，为了将请求报文准确发送，用户主机就必须获得www.baidu.com的IP地址。浏览器会从URL中提取出主机名发送个DNS客户端，DNS客户端向DNS服务器发送一个包含主机名的请求，收到回答报文中包含主机名的IP地址。
• 除了主机名到IP地址的转换外，DNS还提供其他服务：1. 复杂主机名的主机会有一或多个别名，DNS可以获得主机别名对应的规范主机名（即真正的主机名）和IP地址；2. 电子邮件服务器可以调用DNS对提供的邮件服务器别名进行解析，以获得该主机的规范主机名和IP地址；3. 负载分配。

DNS工作机理

• 如web浏览器需要将主机名转换为IP地址，浏览器将会调用DNS客户端，指明需要被转换的主机名。用户主机上的DNS接收到后向网络发送一个DNS查询报文（所有DNS请求和回答报文用UDP数据报经53端口发送）。用户主机上的DNS接收到一个提供所希望映射的DNS回答报文。这个映射结果被传递到调用DNS的浏览器上。
• DNS的一种简单设计是在因特网上只用一个DNS服务器，该服务器包含所有映射。但这种服务器有问题：1. 单点故障，DNS服务器崩溃，整个因特网都瘫痪；2. 通信容量，单个服务i去不得不处理所有DNS查询；3. 远距离的集中式数据库，单台DNS服务器放在纽约，拿澳大利亚的所有查询都要跨越地球；4. 维护，单个DNS服务器不得不为所有因特网主机保留记录。
• 综上，单个DNS服务器弊端非常多，由此诞生了精彩的分布式数据库案例：
  
• DNS使用了大量DNS服务器以层次方式组织分布在全世界，没有一台DNS服务器拥有因特网上所有主机的映射，相反，该映射分布在所有DNS服务器上。
• 假设一个DNS客户要主机名www.amazon.com的IP地址，客户首先与跟服务器之一联系，它会返回顶级域名com的TLD服务器的IP地址。然后客户与TLD服务器联系，它会返回amazon.com的IP地址，最后客户再和amazon.com权威服务器之一联系，返回www.amazon.com的IP地址。
• 根服务器：视为单个服务器，单每台服务器实际上是冗余服务器的网络以提供安全性和可靠性
• 顶级域服务器：com、org、net等等以及国家顶级域名uk、cn、fr。不同公司维护不同顶级域TLD服务器
• 权威DNS服务器：因特网上具有公共可访问主机的每个组织机构必须提供公共可访问的DNS记录。一个组织机构能够选择实现它自己的DNS服务器来保存这些记录；另一个方法是组织付钱让记录存在某个服务提供上的一个权威DNS服务器中。一般大学和公司实现并维护自己基本的权威DNS服务器。
• 本地DNS服务器：不属于DNS服务器的层次结构中，但同样重要。每个ISP都有一台本地DNS服务器。
  
• 如图，假设主机B想知道F的IP地址，B首先向它的本地DNS服务器A发送DNS查询报文，A将报文发到根服务器C，C注意到报文的edu前缀会向A返回负责edu的TLD的IP地址列表。A收到后向表里其一D发送查询报文，D注意到umass.edu前缀后用负责该大学的权威服务器E的IP地址进行响应，最后A向E发送查询报文，E返回F的IP地址进行响应。
• 这里的例子假设了询问的TLD服务器D知道E的IP地址，一般来说TLD服务器只知道中间的某个DNS服务器，依次询问这中间的几个才能得知E的IP地址。比如E如果是大学的DNS中间服务器，同时大学每个系都有自己的DNS权威服务器，当E收到计科系，即cs.umass.edu结尾的请求时会返回所有以cs.umass.edu结尾的权威服务器，然后A再向收到的权威服务器发送查询…

DNS记录和报文

• 共同实现DNS分布式数据库的所有DNS服务器存储了资源记录RR，RR提供了主机名到IP地址的映射。
• RR由Name, Value, Type, TTL四元组组成，TTL是记录生存时间，决定了RR从缓存中删除的时间。

Type	Name	Value	解释
A	主机名	IP地址	提供了主机名到IP地址的映射
NS	域	知道如何获得该域中IP地址的权威DNS服务器的主机名	用于沿着查询链来路由DNS查询
CNAME	别名	别名为Name的主机对应的规范主机名	该记录能够向查询的主机提供一个主机名对应的规范主机名
MX	别名	别名为Name的邮件服务器的规范主机名	用于获得邮件服务器的规范主机名

• 如果一台DNS服务器用于某特定主机名的权威DNS服务器，那么该服务器会有一条包含该主机名的A记录；如果服务器不用于某主机名的权威服务器，那么该服务器将包含一条NS记录，即对应于包含主机名的域，同时还会包含A记录，用于提供在NS记录的Value字段中的DNS服务器的IP地址。
• 举例：假设eduTLD不是主机gaia.cs.umass.edu的权威DNS服务器，则该服务器将包含一条包括主机cs.umass.edu的域记录(umass.edu, dns.umass.edu, NS)，该TLD还会包含一条A记录(dns.umass.edu, 128.119.40.111, A)，该记录将dns.umass.edu映射为一个IP地址。

P2P应用

介绍两种特别适合P2P设计的应用。第一种是文件分发：从单个源向大量的对等方分发文件。第二种是分布在大型对等方社区的数据库。

P2P文件分发

• BitToorent原理：参与一个特定文件分发的对等方的集合称为一个洪流，在一个洪流中的对等方彼此下载等长度的文件块（一般256K）。当一个对等方首次加入洪流时没有块，随着时间推移累计越来越多的块，当下载块时也给其他对等方上传块。一旦某对等方获得了整个文件，它可能会离开洪流，也可能继续为其他对等方上传块。
• 当一个新的对等方Alice加入洪流，追踪器会随机的从其余对等方集合中选一个子集（假设子集包含50个对等方）并将自己内所有IP地址发给Alice，Alice会与子集内所有对等方建立并行的TCP连接，成功连接的称为邻近对等方。随着时间推移对等方可能会离开，别的对等方可能会加入。（图中有三个对等方与Alice连接）
  
• Alice会周期性地询问每个邻近对等方它们所具有的块列表，如果Alice有L个不同邻居，她会获得L个块列表，然后对自己还没有的块发出请求。
• 假设有个新文件，在任何给定时间中，每个对等方都将会具有来自该文件的块子集，并且不同对等方有不同的子集。
• 任意时刻Alice都具有块的子集并知道邻居有哪些块，利用这点Alice会作两个决定：1. 她应从邻近处请求哪些块 2. 她应向哪些向她请求块的邻居发送。Alice采用稀有优先的策略：针对她没有的块在邻居手中选择最稀有的（在邻居手上副本数量最少的），这样可以保证均衡每个块在洪流中的副本数量。
• 而对向谁发送，Alice会对能以最高速率向她提供数据的邻居给出优先权，她会每10秒计算速率并修改4个对等方的集合，每过30秒她还要随机地选择另一个邻居并发送块。如果这位新邻居速度够快就有潜力成为Alice的前四位上载者之一，如果Alice也够快那可能双方都被放入各自的前四位中，直到其中一个找到更好的。除了这五个（四个邻居+一个试探新邻居）对等方其他邻居对等方都被阻塞，即他们不会从Alice这里接到块。

分布式散列表

• 先构建一个集中式简单数据库，该数据库只包含键值对，我们用键来查询数据库。这样的数据库实际采用了CS架构，一个中心服务器存储了所有键值对。我们重新建一个P2P版本，在数以百万计的对等方上存储键值对。每个对等方维持的键值对仅占总体的一个小子集，对等方会用一个特别的键来查询数据，分布式数据库会定位到有该数据的对等方，然后返回查找的键值对。这就是分布式散列表DHT。
• 举例：假设Bob和Charlie都有最新的Linux分发副本，则DHT会有两个键值对(Linux, IP_bob)和(Linux, IP_Charlie)。因为DHT是分布在对等方上的，所有会存在对等方对某些键值对负责，假设Dave对Linux负责（会具有相应的键值对记录），如果Alice要获得Linux的一个副本，然后使用键来查询DHT，DHT会联系对Linux负责的Dave，从Dave处获得当前的两个键值对（bob和Charlie）并传给Alice。
• 如果通过随机的散布键值对来构建DHT会很幼稚，这样的方法要求每个对等方需要知道其他所有参与对等方，而且要向所有对等方发送查询！正确的方法是先为每个对等方分配标识符（范围[0, 2ⁿ-1]），键也是同一范围的整数（键非整数，使用散列函数对应，这也是分布式“散列”表的由来），然后会为标识符最邻近该键的对等方分配一个键值对。举例：n=4，标识符和键都位于[0, 15]之内，假设八个对等方标识符分别为1、3、4、5、8、10、12和15，现在上传(11, xxx)，采用最邻近规则，11最邻近后继是12，所以把(11, xxx)存储在对等方12上。
• 最邻近规则：如果键恰好等于某个对等方标识符，则直接存储在该对等方上；如果键大于所有对等方标识符，则使用模2ⁿ规则，在具有最小标识符的对等方中存储键值对。
• 但是又有个问题，如果我要插入一条键值对，我得联系所有对等方，然后确定所有对等方标识符再按照邻近原则找，这又要联系每个对等方了，所以有下面的方法解决问题。

1. 环形DHT
   将对等方组织为一个环，每个对等方仅与它直接后继和直接前任联系。如图n取4，对等方5只知道8和4的IP地址。现在假设对等方3要确定DHT中的哪个对等方负责键11，并顺时针发送报文，如果收到报文的对等方不负责该键，会继续顺时针传递给自己的后继，直到传到12，然后12给3回送一个报文。
   
   可以发现一个规律，如果一个对等方能关联所有其他对等方，则报文只要发一次；环形就是对等方只关联两个对等方，所以报文平均要发N/2次。所以我们可以使用捷径，让对等方多关联几个对等方以减少报文发送次数，现在让3查询11，向4发送报文后4发送给10，10再发送给12，总共发送3次。
2. 对等方干扰问题
   在P2P系统中，对等方（用户）是想来就来想走就走，所以设计DHT时必须关注这种对等方扰动。用环形DHT举例，假设对等方4联系5和8，因此要求每个对等方周期性的验证其两个后继的存在（发送ping报文并寻求回复），当5突然离开，4和3就要更新它们后继的状态信息，方法为4使用它的第二个后继8来代替5，然后4向8询问它的后继（10）的标识符和地址，4再将10确认为第二个后继。
   除了离开还有到来，假设13要加入该DHT，加入时它只知道DHT里有对等方1的存在，对等方会先向1发送报文询问13的前任和后继，1顺时针查询到12，12认识到自己会是13的前任，而自己的后继15会是13的后继，所以12向13发送它的前任后继信息，对等方13因此加入DHT，标记后继为15，通知12将后继改为13.