应用层
应用程序的体系结构
目前主要的网络应用程序体系结构有以下两种：客户-服务器体系结构和P2P体系结构。
- 客户-服务器体系结构：有一个总是打开的主机称为服务器，服务于来自其他称为客户的的主机的请求；一个典型例子就是Web应用程序。Web服务器响应来自与客户端程序的请求，提供请求的对象，客户与客户之间并不会相互通信。
- P2P体系结构：应用程序在间断连接的主机之间直接通信，这些主机被称为对等方。目前流量密集型应用都是用P2P体系结构，包括文件共享（比如BitTorrent）、对等放协助下载器（迅雷）、某些因特网电话和视频应用（Skype）。
应用层的主要协议
应用层主要有以下协议：超文本传输协议（HyperText Transfer protocol,HTTP）,简单邮件传输协议（Simple Mail Transfer Protocol,SMTP）和域名系统（Domain Name System,DNS）。
1.超文本传输协议（HTTP）
HTTP概述
- HTTP定义了客户程序和服务器程序进行报文交换的方式，包括Web客户向Web服务器请求Web页面的方式，以及服务器向客户传送Web页面的方式。
- Web页面由对象组成，一个对象只是一个文件，例如是一个HTML文件、一个JPEG的图片或者一段视频；它们可以通过URL进行地址寻址。
- HTTP使用TCP作为它的支撑运输协议。HTTP客户首先发起一个与服务器的TCP连接，连接建立之后就可以通过套接字接口访问TCP。客户和服务器可以通过他们的套接字发送HTTP请求报文和接收HTTP响应报文。
- HTTP服务器不保存关于客户的任何信息，是一个无状态协议。
非持续连接和持续链接
客户对服务器的请求可能是间断或者周期性的。若每个请求/响应是通过一个单独的TCP进行的，则被称为非持续连接(non-persistent connection)；若是所有请求/响应都是通过同一个TCP发送，则被称为连续连接(persistent connection)。一般情况下HTTP默认采用持续连接，到那时HTTP客户和服务器也可配置成非持续连接。下面给出在使用非持续连接情况下，服务器向客户传送一个Web页面的步骤：
- HTTP客户在端口80（HTTP协议默认端口号）发起一个到服务器的TCP连接。在客户和服务器上分别有一个套接字与该连接相关联。
- HTTP客户经套接字向该服务器发送一个HTTP请求报文。
- HTTP服务器进程通过它的套接字接收到请求报文，从数据库中检索出对象，在HTTP响应报文中封装对象，然后通过套接字发送响应报文。
- HTTP服务器进程通知TCP断开该TCP连接（但是要直到客户已经完整的接收到响应报文为止，TCP才会实际断开）。
- HTTP客户接受响应报文，TCP连接关闭。客户端程序从响应报文中提取出所需对象，交由浏览器渲染并展示（HTTP与客户如何解释一个Web页面没有关系，它只定义了HTTP客户和HTTP服务器之间的通信协议）。
非持续连接有些缺点。1.必须为每一个请求的对象建立和维护一个全新的连接。对于每一个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量，这样会给Web服务器带来严重的负担。2.每个对象都需要经受两倍往返时间（Round-Trip Time，RTT）的交付时延（一个用于创建TCP，一个用于请求和接受一个对象）。
若是采用HTTP1.1持续链接的情况下，在请求/响应报文交换之后保持TCP连接打开，则后续的请求/响应报文则可以通过相同的TCP连接进行传送。甚至于，位于同一台服务器的多个Web页面在从该服务器发送给同一个客户时，可以在单个持续的TCP上进行。若一个连接经过一定时间间隔（可配置）未被使用，则HTTP服务器关闭此连接。
HTTP请求报文格式
下面是一个典型的HTTP请求报文：
GET /somedir/page.html HTTP/1.1
Host: www.adomainname.com
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr
每个请求报文至少有一行。第一行较做请求行（request line），后继的行较做首部行（header line）。每行都由回车和换行符结束。在首部行之后还有可选的实体体（entity body）。
- 请求行：包括3个字段:方法字段，URL字段和HTTP版本字段。方法字段可以取不同的值，包括GET、POST、HEAD、PUT和DELETE。绝大部分请求报文使用GET方法。POST用于上传用户表单；HEAD方法类似GET方法，但是收到使用HEAD方法的请求时，会使用HTTP报文进行响应，但是不返回请求的对象，一般用于调试；PUT方法用于向Web服务器上传对象；DELETE方法用于删除Web服务器上的对象。URL字段带有请求对象的标识。在此例中，请求的对象是/somedir/page.html。版本字段指示使用的HTTP版本。
- 首部行：Host: www.adomainname.com字段指示服务器主机名（虽说建立连接时候已经知道主机名了，但是这里是Web代理高速缓存所要求的）。Connection: close字段指示服务器发送完请求对象后就关闭连接； User-agent: Mozilla/5.0字段指明用户代理，即向服务器发送请求的浏览器类型；Accept-language: fr字段表示希望得到该对象的法语版本，否则返回默认语言版本。
- 实体体：使用GET方法时为空，使用POST方法时才使用。例如用户提交数据时，则使用POST方法，此时请求的内容依赖于用户提交的数据。若使用POST方法，则实体体中包含的就是用户输入的数据值。但是在实际中，一般不用POST方法，而是使用GET方法，并在所请求的URL中包含用户输入的数据，从而来定位请求的对象。
HTTP响应报文格式
下面是一条典型的响应报文：
HTTP/1.1 200 OK
Connectrion: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
(data data data data data …)
每个响应报文有三个部分。一个初始状态行（status line），6个首部行（header line），然后是实体体（entity body）。
- 状态行有3个字段：协议版本字段，状态码和相应状态信息。
常见的状态码和状态消息：
200 OK：请求成功，信息返回在响应报文中。
301 Moved Permanently：请求的对象已经被永久转移了，新的URL定义在响应 报文的Location首部行中。客户软件将自动获取新的URL。
400 Bad Request：一个通用差错代码，指示该请求不能被服务器理解。
404 Not Found：被请求的不在服务器上。
505 HTTP Version Not Supported：服务器不支持请求报文使用的HTTP协议版本。
- 首部行中，Server: Apache/2.2.3 (CentOS)字段指示该报文是由一台Apache Web服务器产生，类似于请求报文中的User-agent；Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT字段指示对象创建或者最后修改的日期和时间；Content-Type: text/html字段指示实体体中对象是HTML文本。
cookie
HTTP服务器是无状态的。但是一个Web网站有时候需要识别用户，进行个性化推送等。cookie主要用以下方式实现：
- 在HTTP请求/响应报文中的一个cookie首部行
- 在用户端系统中保留有一个cookie文件，借由用户浏览器进行管理
- Web服务器有一个后端服务器
当用户首次访问一个站点时，Web服务器会产生一个唯一的识别码，并用一个包含Set-cookie首部的响应报文对浏览器进行响应；浏览器接收到这个报文后会将它自己管理的cookie文件中添加一行，该行包含服务器的主机名和在Set-cookie中的识别码。当用户下次对同一个网站发起请求时候，浏览器就会查询cookie文件并抽取在此网站的识别码，并放到HTTP请求报文中cookie首部行中，这样Web服务器就可以追踪用户的数据。
Web缓存
Web缓存器（Web cache）也叫代理服务器（proxy server），它能够代表初始Web服务器来满足HTTP请求的网络实体。它有自己的ROM，并在ROM中保存最近请求过的对象的副本。可以配置用户浏览器以有限指向代理服务器，这样可以分散来自于客户的请求，使得服务器有更好的响应能力；同时还可以大大减少网络上的流量。用户向代理服务器请求对象过程如下：
- 浏览器创建一个到代理服务器的连接，并发送HTTP请求报文请求一个对象。
- 代理服务器进行检查，若在本地存储了对象副本则直接发送响应报文返回该对象。
- 若在代理服务器中没有缓存该对象，它就向该对象初始服务器请求该对象。
- 在原服务器中获取到对象后，代理服务器会在本地存储一个副本，然后向客户发酸该副本。
一般来说实践中的命中率（即由一个代理服务器所满足请求的比率）通常在0.2~0.7之间。
但是引入代理也有一个问题，就是代理服务器中对象副本可能是陈旧的，在原服务器中对象可能被更改过。为了解决这个问题，HTTP中有一种机制：条件GET（conditional GET）方法。如何实现的呢？即在GET方法报文中包含一个If-Modified-Since首部行。即当用户向代理服务器请求的对象不知道是不是最新的时候，代理服务器发送一个条件GET执行检查，条件GET报文中If-Modified-Since首部行的值正好等于之前该对象的报文中Last-Modified首部行的值。该GET报文告诉服务器，仅当自指定日期之后该对象被修改过，才发送该对象。
2.简单邮件传输协议（SMTP)
因特网电子邮件系统
主要由三部分组成：用户代理（user agent）、邮件服务器（mail server）和简单邮件传输协议（Simple Mail Transfer Protocol，SMTP）。用户代理允许用户阅读、回复、转发、保存和撰写邮件。用户代理将用户写完的邮件发送给其他邮件服务器，邮件服务器之间相互转发，然后接收邮件的用户可以在他的用户代理中取得邮件。
SMTP概述
SMTP是一个老旧的协议，它只支持使用7位的ASCII码编码，若需要传输多媒体数据，也需要将二进制多媒体数据编码成ASCII码，传输完成之后再解码还原成多媒体数据。使用SMTP发送邮件过程如下：
- 客户端SMTP再25号端口建立一个到服务器SMTP的TCP连接，若服务器没开机，客户端则会稍后尝试。
- 连接建立后，会进行某些应用层的握手。握手时，SMTP客户端指示发送方的邮件地址和接受方的邮件地址。
- 发送报文。SMTP依赖TCP，能够以无差错的方式传送邮件数据。发送完毕后关闭TCP连接。
对比HTTP
- HTTP是一个拉协议，用户从服务器上拉取信息，即TCP连接是由想接收文件的客户端发起的。而SMTP是一个推协议，发送邮件服务器把文件推向接受邮件的服务器，即TCP协议是由要发送文件的机器发起的。
- SMTP要求报文必须为ASCII码格式，若含有非7比特ASCII字符或二进制数据，则必须按照7比特ASCII码进行编码；HTTP则不受这种限制。
- 在处理包含多个对象的报文方面，HTTP封装到多个它自己的响应报文中；而SMTP则把所有报文对象封装在一个报文中。
邮件访问协议
由于取报文是一个拉操作，而SMTP是一个推协议。所以一般使用SMTP来将邮件从用户代理发送至邮件服务器和使用SMTP将邮件从发送邮件服务器发送至接收邮件服务器；而读取报文则采用邮件访问协议，包括第三版的邮局协议（Post Office Protocol-Version 3，POP3）、因特网邮件访问协议（Internet Mail Access Protocol，IMAP）以及HTTP。
3.域名服务（Domain Name System，DNS）
DNS概述
简单的说，DNS就是用于IP地址和域名之间相互映射的一个分布式数据库。运行TCP/IP互联网协议使用IP地址标识主机，但是IP地址不便于记忆，主机名方便记忆，于是使用DNS来进行IP地址与主机名（域名）之间的映射。
- 一个分层的DNS服务器实现的分布式数据库。
- 一个使得主机能够查询分布式数据库的应用层协议。
- DNS运行在UDP之上，使用53号端口。
DNS工作原理
考虑一个Web应用的例子。若一个HTTP客户希望向某个HTTP服务器发起一个请求，那么客户需要：
- 客户运行着DNS客户端。
- 浏览器从URL中 取出主机名，并将其传给DNS应用的客户端。
- DNS客户向DNS服务器发送一个包含主机名的请求。
- DNS客户最终收到一份回答报文，包含该主机名对应的IP地址。
- 浏览器收到来自DNS的IP地址，向该IP地址的HTTP服务器的80端口发起一个TCP连接。
如上所述，DNS服务会带来额外的时延。但是我们在实际中可以通过部署**本地域名服务器（local DNS server）**来减少时延。
除了IP地址和域名之间的相互映射之外，DNS还提供一些重要的服务：
- 主机别名（host aliasing）：有些复杂的主机能拥有一个或者多个别名，某些时候主机别名比对应的规范主机名更加容易记忆。应用程序可以调用DNS服务来获取主机别名对应的规范主机名以及主机的IP地址。
- 邮件服务器别名（mail server aliasing）：用处同上，但是用于邮件服务器别名到规范主机名和IP地址的映射。并且在DNS报文的资源记录（Resource record，RR）中，MX记录允许一个公司的邮件服务器和Web服务器使用相同的（别名化的）主机名。
- 负载分配（load distribution）：用于在冗余的服务器之间进行负载分配。某些并发量较大的站点，会有多台服务器和多个IP地址，而DNS允许一个IP地址集合同一个规范主机名相互映射。
DNS结构
若将所有的DNS请求置于一个服务器中，当产生单点故障时候，整个网络将会瘫痪；同时这一个服务器必然承受极大负载；而且距离该DNS服务器比较远的用户将有可能因为低速链路而承受较大的时延。于是为了处理这个问题，DNS采用分布式、分层次的数据库来解决这个问题。
大致上来说由3种类型的DNS服务器：根服务器、顶级域（Top-Level Domain，TLD）DNS服务器和权威DNS服务器。假定一个DNS客户需要主机名www.amazon.com的IP地址，它首先会与根服务器之一联系，它将返回顶级域名com的TLD服务器的IP地址；然后该客户与TLD服务器之一联系，它将返回amazon.com权威服务器的IP地址；最后该客户与amazon.com权威服务器之一联系，返回www.amazon.com的IP地址。
- 根DNS服务器：提供TLD服务器的IP地址。
- 顶级域（DNS）服务器：对于每个顶级域（如com、org、net、edu和gov）和所有国家顶级域（如uk、fr、jp和cn），都有TLD服务器（群）。TLD服务器提供了权威DNS服务器的IP地址。
- 权威DNS服务器：互联网上可被公共访问的主机或站点（比如一个公司），需要提供一个站点的DNS记录。这些DNS记录将站点名映射为IP地址。一个组织机构（如一个公司）可以自己实现自己的权威DNS服务器，或者使用某个服务器提供商提供的权威DNS服务器。
除此之外，还有一种不属于该层次结构，却十分重要的DNS服务器，称之为本地DNS服务器（local DNS server）。一般来说，一个居民区或者一个机构的ISP都有一台或多台本地DNS（也叫LDNS），这些DNS服务器的IP地址通过动态主机配置协议（Dynamic Host Configuration Protocol，DHCP）确定。为了改善时延并且减少在网络上传输的DNS报文数量，DNS会使用缓存技术。DNS缓存（DNS caching）即当DNS服务器接受到某个DNS回答（包含主机名与IP地址之间的映射），则将此映射缓存到本地存储器中。这个映射并不是永久的，DNS服务器在一段时间（通常为2天）后将丢弃缓存的信息。下面是一个使用LDNS的例子：假设一个HTTP客户端想要请求一个Web网页，则应经过以下过程：
- 客户端首先会向本地DNS服务器发送一个DNS查询报文，该报文含有需要被转换的主机名。
- 本地DNS服务器接收到报文，在本地缓存中索引该主机名，若查找到则直接返回主机名对应IP地址；
- 若在本地缓存中未查询到该主机名，本地DNS服务器则将DNS查询报文转发给根域名服务器；
- 根域名服务器根据顶级域名返回对应顶级域名的TLD的IP地址；
- 本地DNS服务器则向TLD发送查询报文；
- TLD根据其权威域名返回权威域名服务器的IP地址；
- 本地DNS向权威域名服务器发送查询报文；权威域名服务器返回主机名对应的IP地址
- 本地DNS将返回的报文转发给客户端，客户端建立与主机的TCP连接。
以上方式每一次查询都是由本地DNS以自己的名义查询，该种查询方式称为迭代查询（iterative query）；另一种方式是通过本地向根服务器发送DNS查询报文，根服务器向TLD发送查询报文，TLD向权威服务器发送查询报文，最后逐级返回，最后由根域名服务器返回给本地DNS，本地DNS再返回给客户端。这种方式称为递归查询（recursive query）。一般来说，从请求的主机到本地DNS服务器的查询是递归的，其余的查询时迭代的。
DNS记录和报文
共同实现DNS分布式数据库的所有DNS服务器存储了资源记录（Resource record，RR），RR提供了主机名到IP地址的映射。每个DNS回答报文包含了一条或者多条RR。资源记录时包含里下列字段的4元组：
（Name、Valu、Type、TTL）
TTL是该记录的生存时间，它决定了RR应当从缓存中删除的时间。
- 如果Type=A，则Name是主机名，Value是该主机名对应的IP地址；
- 如果Type=NS，则Name是个域名（如baidu.com），而Value是个知道如何获得该域名对应主机IP地址的权威DNS服务器的主机名。
- 如果Type=CNAME，则Value是别名为Name的主机对应的规范主机名。
- 如果Type=MX，则Value是个别名为Name的邮件服务器的规范主机名。
DNS报文只有查询和回答这2种报文。
P2P文件分发
前面讨论的Web、电子邮件和DNS都采用了客户-服务器体系结构，极大地依赖于总是打开的基础设施服务器。而使用P2P体系结构，对总是打开的基础设施服务器由最小的（甚至没有）依赖。与之相反，成对间接连接的主机（称为对等方）彼此直接通信。这些对等方不是服务提供商所有，而是一般的PC机或笔记本。到2016年为止，最流行的P2P文件分发协议是BitTorrent。
P2P体系结构和客户-服务器体系结构对比
若有大量客户端主机向一个服务器请求同一个文件，则该服务器必须向每个客户发送一个该文件的副本。这消耗了大量的服务器带宽。而在P2P文件分发中，每个对等方能够向任何其他对等方重新分发它已经收到文件的任何部分，从而再分发过程中协助服务器。P2P应用程序具有自扩展性，因为对等方出了事比特的消费者之外它们还是重新分发者。
基于P2P协议的BitTorrent协议基本原理
参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）。在一个洪流中对等方彼此下载等长度的文件块（chunk），典型的块长度为256KB。当一个对等方首次加入一个洪流时，它没有块。随时间流逝，它累积了越来越多的块。在它下载块的同时，它也为其他对等方上载了多个块。
一个对等方可以随时离开或者加入一个洪流。每一个洪流有一个基础设施节点，称为追踪器（tracker）。当一个对等方加入某一个洪流时，它向追踪器注册自己，并周期地通知追踪器它仍在洪流中。之后追踪器随机从参与对等方集合中选择对等方的一个子集，并将这些子集里对等方的IP地址发送给加入的对等方，让其建立TCP连接。创建了TCP连接的对等方称为“邻近对等方”。随时间流逝，邻近对等方可能离开，其他对等方可能加入并变成临近对等方。
在任何时间，每个对等方将具有该特定文件的子集，不用对等方具有不同的子集。计入的对等方周期性地（经TCP连接）询问每个邻近对等方它们所具有的块列表，然后对其还未拥有的块发出请求（仍通过TCP连接）。
现在又有2个问题。1.该加入对等方应从其邻居请求哪些块？2.应当向哪些向它请求块的邻居发送块?为了解决这个问题，引入了一种**最稀缺优先（rarest first）**的技术。这种技术的思路是，在其未拥有的块中选择最稀缺的块（稀缺即邻居拥有最少）优先分发，其目的是（大致地）均衡每个块在洪流中的副本数量。这种关于交换的激励机制常被称为“一报还一报”。
2615
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
