应用层协议原理

网络应用程序体系结构

在客户-服务体系结构（client-server architecture）中，有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。一个经典的例子就是Web应用程序。

在一个P2P体系结构中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。例如，对于许多即时通讯应用而言，服务器被用于跟踪用户的IP地址，但用户到用户的报文在用户之间（无需通过中间服务器）直接发送。

进程通信

进行通信的实际上是进程（process）而不是程序。一个进程可以被认为是运行在端系统中的一个程序。

在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）而相互通信。发送进程生成并向网络中发送报文；接收进程接收这些报文并可能通过将报文发送回去进行响应。

客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。

在给定的一对进程之间的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被表示为客户，在会话开始时等待联系的进程是服务器。

进程与计算机网络之间的接口

进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。

套接字是同一台主机内应用层与运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（Application Programming Interface，API）。

应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字在运输层端几乎没有控制权。应用程序开发者对于运输层的控制权仅限于：
- 选择运输层协议；
- 设定运输层参数，如最大缓存和最大报文段长度等。

进程寻址

在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，需要有一个接收进程的地址。为了标识该接收进程，需要定义：
- 主机的地址；IP地址（IP address）
- 在目的主机中的接收进程的标识符。端口号（port number）

可供应用程序使用的运输服务

可靠数据传输
吞吐量
定时
安全性

因特网提供的运输服务

TCP服务
- 面向连接的服务：在应用层数据报文开始流动之前的握手阶段，TCP让客户和服务器相互交换运输层控制信息。握手阶段之后，就在两个进程的套接字之间建立了一个TCP连接。连接双方的进程都可以在此连接上同时进行报文收发，当应用程序结束报文发送时，必须拆除该连接。
- 可靠的数据传输服务：通信进程能够依靠TCP，无差错、按适当顺序交付所有发送的数据。

TCP协议还具有拥塞控制机制，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。当发送方和接收方之间的网络出现阻塞时，TCP的拥塞控制机制会抑制发送进程（客户或服务器）。TCP拥塞控制也试图限制每个TCP连接，使它们达到公平共享网络带宽的目的。

UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将达到接受进程，而且到达接受进程的报文也可能是乱序到达的。

UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。

应用层协议

应用层协议（application-layer protocol）定义了运行在不同端系统上的应用程序进程如何相互传递报文。特别是应用层协议定义了：

交换的报文类型，例如请求报文和响应报文。
各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
字段的语义，即这些字段中包含的信息的含义。
一个进程何时以及如何发送报文，对报文进行响应的规则。

有些应用层协议是由RFC文档定义的，因此它们位于公共域中。例如，Web的应用层协议HTTP（超文本传输协议[RFC 2616]）就作为

RFC：Request For Comments（RFC），是一系列以编号排定的文件。文件收集了有关互联网相关信息，以及UNIX和互联网社区的软件文件。目前RFC文件是由Internet Society（ISOC）赞助发行。基本的互联网通信协议都有在RFC文件内详细说明。RFC文件还额外加入许多的论题在标准内，例如对于互联网新开发的协议及发展中所有的记录。因此几乎所有的互联网标准都有收录在RFC文件之中。

Web和HTTP

HTTP概况

Web的应用层协议是超文本传输协议（HyperText Transfer Protocol，HTTP），它是Web的核心。HTTP由两个程序实现：一个客户程序和一个服务器程序。客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。

Web页面（Web page）（也加文档）是由对象组成的。一个对象（object）只是一个文件，例如，HTML文件、JPEG图形、Java小程序或视频片段，且它们都可以通过一个URL地址寻址。
多数Web页面含有一个HTML基本文件（base HTML file）以及几个引用对象。HTML基本文件通过对象的URL地址引用页面中的其他对象。每个URL地址由两部分组成：存放对象的服务器主机名和对象的路径名。
Web浏览器（Web browser）实现了HTTP的客户端；Web服务器（Web server）实现了HTTP的服务器端，它用于存储Web对象，每个对象由URL寻址。流行的Web服务器有Apache和Microsoft Internet Information Server（微软互联网信息服务器）。

服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。所以说HTTP是一个无状态协议（stateless protocol）。同时Web服务器总是打开的，具有一个固定的IP地址，且它服务于可能来自数以百万计的不同浏览器的请求。

非持续连接和持续连接

当客户-服务器的交互是经过TCP进行的，应用程序的研制者就需要决定每个请求/响应对是经过一个单独的TCP连接发送，还是所有的请求及其响应经相同的TCP连接发送。如果采用前一种方法，该应用程序被称为使用非持续连接（non-persistent connection）；采用后一种方法，该应用程序被称为使用持续连接（persistent connection）。

HTTP既能够使用非持续连接，也能够使用持续连接。尽管HTTP在默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接。一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。

HTTP报文格式

HTTP请求报文

GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n
实体主体

第一行为请求行（request line），包括：方法字段、URL字段和HTTP版本字段，方法字段包括GET、POST、HEAD、PUT和DELETE；其后继的行叫做首部行（header line）。

HTTP响应报文

HTTP/1.1 200 OK\r\n
Date: Sun, 26 Sep 2010 20:09:20 GMT\r\n
Server: Apache/2.0.52 (CentOS)\r\n
Last-Modified: Tue, 30 Oct 2007 17:00:02 GMT\r\n
ETag: "17dc6-a5c-bf716880"\r\n
Accept-Ranges: bytes\r\n
Content-Length: 2652\r\n
Keep-Alive: timeout=10, max=100\r\n
Connection: Keep-Alive\r\n
Content-Type: text/html; charset=ISO-8859-1\r\n
\r\n
data data data data data ...

有三个部分：初始状态行（status line），首部行（header line）和实体主体（entity body）。实体主体部分是报文的主要部分，它包含了所请求的对象本身。状态行包含：协议版本字段、状态码和相应状态信息。

用户器与服务器的交互：cookie

cookie技术有4个组件：

在HTTP响应报文中的一个cookie首部行；
在HTTP请求报文中的一个cookie首部行；
在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理；
位于Web站点的一个后端数据库。

响应报文：

Set-cookie: 1678\r\n

请求报文：

Cookie： 1678\r\n

cookie可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识。在后继会话中，浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。

Web缓存

Web缓存器（Web cache）也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。

Web缓存器是服务器同时又是客户。当它接收浏览器的请求并发回响应时，它是一个服务器。当它向初始服务器发出请求并接收响应时，它是一个客户。

Web缓存器通常由ISP购买并安装。

大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时更是如此。
大大减少一个机构的接入链路到因特网的通信量。
从整体上大大减低因特网上的Web流量，从而改善所有应用的性能。

条件GET方法

尽管高速缓存能减少用户感受到的响应时间，但也引人了一个新的问题，即存放在缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。

HTTP 协议有一种机制，允许缓存器证实它的对象是最新的这种机制就是条件GET (conditional GET）方法：

请求报文使用 GET 方法；
并且②请求报文中包含一个“ If- Modified-Since ：”首部行。

因特网中的电子邮件

用户代理（user agent）
邮件服务器（mail server）
简单邮件传输协议（Simple Mail Transfer Protocol, SMTP）

邮件服务器形成了电子邮件体系结构的核心。每个接收方在其中的某个邮件服务器上有一个邮箱（ mailbox ）。邮箱管理和维护着发送给他的报文。

一个典型的邮件发送过程是：从发送方的用户代理开始，传输到发送方的邮件服务器，再传输到接收方的邮件服务器，然后在这里被分发到接收方的邮箱中。

如果Mail From的服务器不能将邮件交付给Mail To的服务器，Mail From的邮件服务器在一个报文队列（ message queue ）中保持该报文并在以后尝试再次发送。通常每 30 分钟左右进行一次尝试；如果几天后仍不能成功，服务器就删除该报文并以电子邮件的形式通知发送方。

SMTP

SMTP 是因特网电子邮件应用的核心，用于从发送方的邮件服务器发送报文到接收方的邮件服务器。

SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样。

使用Telnet连接SMTP服务器的命令：

telnet serverName 25

之后可以通过命令发送报文，例如：HELO、MAIL FROM、RCPT TO、DATA以及QUIT。

与HTTP相比：
1. HTTP主要是一个拉协议（pull protocol），SMTP基本上是一个推协议（push protocol）。
2. SMTP 要求每个报文使用 7 比特 ASCII 码格式。
3. HTTP 把每个对象封装到它自己的 HTTP 响应报文中，而 SMTP 则把所有报文对象放在一个报文之中。

邮件报文格式

一个典型的报文首部看起来如下：

From: [email protected]
To: [email protected]
Subject: Searching for the meaning of life.

在报文首部之后，紧接着一个空白行，然后是以 ACSII 格式表示的报文体。

邮件访问协议

POP3：第三版的邮局协议（ Post Office Protocol-Version 3, POP3 ）
IMAP：因特网邮件访问协议（ Internet Mail Access Protocol, IMAP)
HTTP：基于 Web 的电子邮件，用户代理就是普通的浏览器，用户和他远程邮箱之间的通信则通过 HTTP 进行，而邮件服务器之间发送和接收邮件时，仍然使用的是 SMTP。

DNS：因特网的目录服务

域名系统（Domain Name System, DNS ）的主要任务是进行主机名到地址转换的目录服务。

DNS 是：
1.一个由分层的 DNS 服务器（ DNS server ）实现的分布式数据库；
2. 一个使得主机能够查询分布式数据库的应用层协议。

DNS 服务器通常是运行 BIND ( Berkeley Internet Name Domain ）软件 [ BIND 2012 ] 的UNIX 机器。 DNS 协议运行在 UDP 之上，使用 53 号端口。

DNS 提供的重要服务：
- 主机别名（ host aliasing ）
- 邮件服务器别名（ mail server aliasing ）
- 负载分配（ load distribution ）
DNS采用集中式设计的问题：
- 单点故障（ a single poinl of failure ）
- 通信容量（ traffic volume）
- 远距离的集中式数据库（ distant centralized database ）
- 维护（ maintenance）
DNS 服务器的层次结构：
- 根 DNS 服务器
- 顶级域（ DNS ）服务器
- 权威 DNS 服务器
- 本地 DNS 服务器

从理论上讲，任何 DNS 查询既可以是迭代的也可以是递归的。

在一个请求链中，当某 DNS 服务器接收一个 DNS 回答（例如，包含主机名到IP地址的映射）时，它能将该回答中的信息缓存在本地存储器中。** DNS 缓存**（ DNS caching ）可以改善时延性能并减少在因特网上到处传输的 DNS 报文数量。

DNS 服务器存储的资源记录是一个包含了下列字段的4元组：

(Name, Value, Type, TTL)

TTL 是该记录的生存时间，它决定了资源记录应当从缓存中删除的时间。
如果 Type= A，则 Name 是主机名， Value 是该主机名对应的 IP 地址。
如果 Type ＝ NS，则 Name 是个域（如 foo.com ），而 Value 是个知道如何获得该域中主机IP地址的权威 DNS 服务器的主机名。
如果 Type= CNAME ，则 Value 是别名为 Name 的主机对应的规范主机名。
如果 Type= MX ，则 Value 是别名为 Name 的邮件服务器的规范主机名。

使用 nslookup 程序（ nslookup program ）可以向DNS服务器发送 DNS 查询报文。

P2P应用

P2P文件分发

P2P体系结构的扩展性

分发时间(distribution time)是所有 N 个对等方得到该文件的副本所需要的时间。

客户-服务器体系结构
- $D_{c-s}>=max（\frac{NF}{u_s},\frac{F}{d_min}）$
- N：对等方数目
- F：被分发文件大小
- u_s：服务器接入链路的上载速率
- d_min：具有最小下载速率的对等方的下载速率，即 $d_{min}=min(d_1,d_2,……,d_N)$
P2P 体系结构
- $D_{p-p}>=max（\frac{F}{u_s},\frac{F}{d_min},\frac{NF}{u_s+\sum_{i=1}^N{u_i}}）$

BitTorrent

BitTorrent是一种用于文件分发的流行 P2P 协议。

洪流(torrent)：参与一个特定文件分发的所有对等方的集合。在一个洪流中的对等方彼此下载等长度的文件块(chunk)，典型的块长度为256KB。

当一个对等方首次加入一个洪流时，它没有块。随着时间的流逝，它累积了越来越多的块。当它下载块，也为其他对等方上载了多个块。一且某对等方获得了整个文件，它也许(自私地)离开洪流，或(大公无私地)留在该洪流中井继续向其他对等方上载块。同时，任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中。

每个洪流具有一个基础设施结点，称为追踪器(tracker)。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟踪正参与在洪流中的对等方。

当一个新的对等方 A 加入该洪流时，追踪器随机地从参与对等方的集合中选择对等方的一个子集，并将这些对等方的IP地址发送给 A ，A 持有对等方的这张列表，试图与该列表上的所有对等方创建并行的 TCP 连接。我们称所有这样与 A 成功地创建一个 TCP 连接的对等方为“邻近对等方”。一个对等方的邻近对等方将随时间而波动（有些离开，有些加入）。

A 应当从它的邻居请求哪些块

最稀缺优先(rarest first)的技术：针对它没有的块在它的邻居中决定最稀缺的块，并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是均衡每个块在洪流中的副本数量。

A 应当向哪些向它请求块的邻居发送

对换算法：根据当前能够以最高速率向它提供数据的邻居，给出其优先权。被选中的对等方被称为疏通(unchoked)。同时，每过 30 秒，它也要随机地选择另外一个邻居并向其发送块，如果速率更快则进行替换。这种效果是对等方能够以趋向于找到彼此的协调的速率上载。

分布式散列表

在 P2P 网络中实现一个简单的键-值数据库。考虑构建这种数据库的一个分布式、 P2P 的版本，在数以百万计的对等方上存储(键，值)对。在该 P2P 系统中，每个对等方将保持 (键，值)对仅占总体的一个小子集。我们将允许任何对等方用一个特别的键来查询该分布式数据库。分布式数据库则将定位拥有该相应(键，值)对的对等方，然后向查询的对等方返回该(键，值)对。任何对等方也将允许在数据库中插入新键-值对。这样一种分布式数据库被称为分布式散列表( Distributed Hash Table, DHT)。

为每个对等方分配一个标识符，其中每个标识符是一个[ O, 2^N -1 ] 范围内的整数，N 取某些固定的值。并设计一个散列函数，将每一个键的值映射到这个范围内。

环形DHT

将对等方组织为一个环。在这种环形设置中，每个对等方仅与它的直接后继和直接前驱联系。使用该环形覆盖网络，初始对等方生成一个查询报文，并绕环顺时针发送该报文。无论何时某对等方接收到该报文，因为它知道其后继和前驱的标识符，它能够确定是否是由它负责(即最邻近)查询的键。如果某对等方不负责该键，它只需将该报文发送给它的后继。：O（N/2）

具有捷径的环形DHT

细化的方案之一是以该环形覆盖网络为基础，但增加“捷径”，使每个对等方不仅联系它的直接后继和直接前驱，而且联系分布在环上的数量相对少的捷径对等方。使用捷径来加速查询报文的路由选择。研究表明 DHT 能被设计成每个对等方的邻近数量以及每个请求的报文数量均为O(log N)。

对等方扰动

在P2P系统中，对等方能够不加警示地到来和离去。因此，当设计一个 DHT 时，我们也必须关注存在这种对等方扰动时维护 DHT 的情况。为处理对等方扰动，我们要求每个对等方知道其第一个和第二个后继的IP地址。

视频流和内容分发网络

DASH

经HTTP的动态适应性流（Dynamic Adaptive Streaming over HTTP，DASH）。

在DASH中，视频编码为几个不同的版本，其中每个版本具有不同的比特率，对应不同的质量水平。每个版本具有一个不同的URL，HTTP服务器也有一个告示文件（manifest file），为每个版本提供一个URL及其比特率，客户用HTTP GET请求报文一次选择一个不同的块，在下载块的同时，用户也测量带宽并运行一个速率决定算法来选择下次请求的块。

CDN：内容分发网络

CDN的全称是Content Delivery Network，即内容分发网络。CDN是构建在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。

CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器直接响应用户请求。

内容分发网络(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理4个要件.

大多数CDN利用DNS来截获和重定向请求。
CDN的部署核心是集群选择策略（cluster selection strategy）：
- 地理上最为临近（geographically closest）的集群。
- 对集群和客户之间的时延和丢包性能执行周期性的实时测量（real-time measurement）。

TCP和UDP套接字编程

UDP套接字编程

UDPClient.py

from socket import *
serverName = ’ hostname ’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_DGRAM)
message = raw_input (’ Input lowercase sentence z’)
clientSocket.sendto(message,(serverName, serverPort))
modified.Message, serverAddress = clientSocket.recvfrom(2048)
print modified.Message
clientSocket. close ( )

UDPServer.py

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET, SOCK_DGRAM) serverSocket.bind{ ("" , serverPort))
print "The server is ready to receive"
while true:
    message, clientAddress = serverSocket.recvfrom(2048)
    modifiedMessage = message.upper()
    serverSocket.sendto(modifiedMessage, clientAddress)

TCP套接字编程

TCPClient.py

from socket import *
serverName = ’ servername ’
serverPort = 12000
clientSocket = socket(AF_INET, SOCK_STREAM)
clientSocket.connect((serverName, serverPort))
sentence = raw_input(’ Input lowercase sentence:’)
clientSocket.send(sentence)
modifiedSentence = clientSocket.recv(1024)
print ’From Server:’, modifiedSentence
clientSocket.close()

TCPServer.py

from socket import *
serverPort = 12000
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((’’, serverPort))
serverSocket.listen(1)//最大并发连接数
print ’The server is ready to receive’
while true:
    connectionSocket, addr = serverSocket.accept()
    sentence = connectionSocket.recv(1024)
    capitalizedSentence = sentence.upper()
    connectionSocket.send(capitalizedSentence)
    connectionSocket.close()

想了解更多关于计算机网络架构与网络安全：计算机网络架构与网络安全专栏

计算机网络：应用层