应用层

网络应用是计算机网络存在的理由，如果我们不能构想出任何有用的应用，也就没有任何必要去设计支持它们的网络协议了。

因特网应用包括 20 世纪 70年代 和 80年代开始流行的，经典的基于文本的应用，如文本电子邮件、远程访问计算机、文件传输和新闻组，还包括 20 世纪 90 年代中期的万维网，

2.1 应用层协议原理

研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通信的程序。

例如，在 Web 应用程序中，有两个互相通信的不同程序，一个是运行在用户主机（桌面机、平板电脑、智能电话等）上的浏览器程序，另一个是运行在 Web 服务器主机上的 Web 服务器程序。

另一个例子是 P2P 文件共享系统， 在参与文件共享的设区中的每台主机中都有一个程序。 在这种情况下，在各台主机中的这些程序可能都是类似得或相同的。

因此，当研发新应用程序时，你需要编写将在多台端系统上运行的软件。例如，该软件能够用 C、Java等来编写。重要的是，你不需要写在网络核心设备如路由器或链路层交换机上运行的软件。

即使你要为网络核心设备写应用程序软件，你也不能做到这一点。

如我们之前所说， 网络核心设备并不在应用层上起作用，而仅在较低层起作用，特别是位于网络层及下面层。这种基本设计，也即将应用软件限制在端系统的方法，促进了大量的网络应用程序的迅速研发和部署。

2.1.1 网络应用程序体系结构

当进行软件编码之前，应对程序有一个宽泛的体系结构计划。 记住应用功能程序的体系结构明显不同于网络的体系结构。

从应用程序研发者的角度来看，网络体系结构是固定的，并为应用程序提供了特定的服务集合。

在另一方面，应用程序体系结构由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。

在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序中所使用的两种主流体系结构之一：客户服务器体系结构或对等（P2P） 体系结构。

C/S 结构:

在客户-服务器体系结构中， 有一个总是打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。

一个经典的例子是 Web 应用程序， 其中总是打开的 Web 服务器服务于来自浏览器（运行在客户主机上）的请求。

当 Web 服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为相应。

值得注意的是利用客户-服务器体系结构， 客户相互之间不直接通信；例如， 在 Web 应用程序中两个浏览器不直接通信。 客户-服务器体系结构的另一个特征是该服务器具有固定的、周知的地址，该地址称为 IP 地址， 因为该服务器具有固定的、周知的地址，并且因为该服务器总是打开的，客户总是能够通过向该服务器的 IP 地址发送分组来与其联系。

具有客户-服务器体系结构的非常著名的应用功能程序包括 Web、FTP、Telnet 和电子邮件。

在一个 C/S 应用中，常常会出现一台单独的服务器主机跟不上它所有客户请求的情况。

比如，一个流行的社交网络站点如果仅有一台服务器来处理所有请求，将很快变得不堪重负。

为此，配备大量主机的数据中心常被用于创建强大的虚拟服务器。

最为流行的的因特网服务——如搜索引擎、因特网商务、社交网络，就应用了一个或多个数据中心。

如之前讨论的，谷歌有分布于全世界的 30 ~ 50个数据中心，这些数据中心共同处理搜索、YouTube、Gmail 和其他服务。

一个数据中心能够有数十万台服务器，它们必须要供电和维护。此外，服务器提供商必须支付不断出现的互联和带宽费用，以发送和接收到达/ 来自数据中心的数据。

P2P 结构：

在一个 P2P体系结构（P2P architecture）中，对位于数据中心的专用服务器有最小的（或没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。

这些对等方并不为服务提供上所有，相反却为用户控制的桌面机和膝上机所有，大多数对等方驻留在家庭、大学和办公室。

因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。

许多目前流行的、流量密集性应用都是 P2P 体系结构，这些应用功能包括文件共享、对等方协助下载加速器（迅雷）、因特网电话（Skype） 和 IPTV ，需要提到的是：

某些应用具有混合的体系结构，它结合了客户-服务器和 P2P 的元素。

例如，对于许多即时讯息应用而言，服务器被用于跟踪用户的 IP 地址， 但用户到用户的报文在用户之间（无需通过中间服务器）直接发送。

P2P 的特性

1. 自扩展性，例如，在一个 P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作量， 但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

P2P 体系结构也是成本有效的，因为它们通常不需要庞大的服务器基础设施和服务器带宽 。

未来 P2P 应用面临三个主要挑战：

• ISP 友好。 大多数住宅ISP（包括 DSL 和 电缆 ISP）已经受制于“ 非对称的” 带宽应用，也就是说，下载比上载要多得多， 但是 P2P 视频流和文件分发应用功能改变了从服务器到 住宅 ISP的 上载流量， 因而给 ISP 带来了巨大压力，未来 P2P 应用需要设计对 ISP 友好的模式。
• 安全性，因为它们的高度分布和开放特性， P2P应用给安全带来挑战。
• 激励。 未来P2P应用成功也取决于说服用户自愿向用户提供贷款、存储和计算资源，这对激励化设计带来挑战。

2.1.2 进程通信

在构建网络应用程序之前，还需要对运行在多个端系统上的程序是如何互相通信的情况有个基本了解。

在操作系统的术语中，进行通信的实际上是进程而不是程序。 一个进程可以被认为是运行在端系统中的一个程序。

当进程运行在相同的端系统上时，它们使用进程间通信机制相互通信。 进程间通信的规则由端系统上的操作系统确定。

我们关注运行在不同端系统（可能具有不同操作系统）上的进程间的通信。

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

1. 客户和服务器进程

网络应用程序由成对的进程组成，这些进程通过网络相互发送报文。 例如，在 Web 应用程序中，一个客户浏览器进程与一台 Web 服务器进程交换报文， 在一个 P2P 文件共享系统中， 文件从一个对等方中的进程传输到另一个对等方中的进程。

对每对通信进程， 我们通常将这两个进程之一标识为客户，而另一个进程标识为服务器， 对于 Web 而言，浏览器是一个客户进程， Web 服务器是一台服务器进程。

对于 P2P 文件，下载文件的对等方标识为客户，上载文件的对等方表示为服务器。

你或许已经观察到， 如在 P2P 文件共享的某些应用中，一个进程能够既是客户又是服务器， 无论如何，在任何给定的一堆进程之间的通信会话场景中，我们仍能将一个进程标识为客户，另一个进程标识为服务器。

我们定义客户和服务器进程如下:

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

如上所述， 多数应用程序是由通信进程对组成， 每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。

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

我们考虑一个类比来帮助我们来理解进程和套接字：

进程可类比于一座房子，而它的套接字可以类比于它的门，当一个进程想向位于另外一台主机上的另一个进程发送报文时，它把报文推出该门（套接字）。

该发送进程假定该门道另外一侧之间有运输的基础设施，该设施将把报文传送到目的进程的门口。一旦该报文抵达目的主机，它通过接收进程的门（套接字）传递，然后接收进程对该报文进程处理。

如图所示， 套接字是同一台主机内应用层与运输层之间的接口，由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口（API），应用程序开发者可以控制套接字在应用层端的一切，但是对该套接字的运输层端几乎没有控制权。

应用程序开发者对于运输层的控制仅限于：

①选择运输层协议；
②也许能设定几个运输层参数， 如最大缓存和最大报文段长度。

一旦应用程序开发者选择了一个运输层协议，则应用程序就建立在该协议提供的运输层服务之上。

3. 进程选址

为了向特定目的地发送邮政邮件，目的地需要有一个地址。 类似地， 在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。

为了标识该接收进程， 需要定义两种信息： ①主机的地址； ②定义在目的主机中的接收进程的标识符。

在因特网中，主机由其 IP地址标识， 此时，我们只要知道 IP地址是一个 32 比特的量且它能够唯一地表示该主机就够了。

除了知道报文送往目的地的主机地址外， 发送进程还必须指定运行在接收主机上的接收进程（更具体地说，接收套接字）。

因为一般而言，一台主机能够运行许多网络应用，这些信息是需要的， 目的地端口号用于这个目的， 已经给流行的应用分配了特定的端口号。 例如， Web 服务器用端口号 80 来标识， 邮件服务器进程（使用 SMTP 协议）用端口号 25 来标识，

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

前面讲过套接字是应用程序进程和运输层协议之间的接口， 在发送端的应用程序将报文推进该套接字， 在该套接字的另一侧， 运输层协议负责使该报文进入接收进程的套接字。

包括因特网在内的很多网络提供了不止一种运输层协议。当开发一个应用时， 必须选择一种可用的运输层协议。 如何做出这种选择呢？

最可能的方式是， 通过研究这些可用的运输层协议所提供的服务， 选择一个最能为你的应用需求提供恰当服务的协议。

一个运输层协议能够为调用它的应用程序提供什么样的服务呢？ 我们大体从四个方面对应用程序服务要求进行分类： 可靠数据传输、吞吐量、定时和安全性。

1. 可靠数据传输

如之前所述， 分组在计算机网络中可能丢失。 例如， 分组能够使路由器中的缓存溢出，或者当分组中的某些比特损坏后可能被丢弃。

像电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等这样的应用。 数据丢失可能会造成灾难性的后果， 因此，为了支持这些应用， 必须做一些以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。

如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输， 运输层协议能够潜在地向应用程序提供的一个重要服务是：

进程到进程的可靠数据传输。

当一个运输协议提供这种服务时， 发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错到达接收进程。

当一个运输层协议不提供可靠数据传输时， 由发送进程发送的某些数据可能不能够到达接收进城。 这可能能被容忍丢失的应用所接受。

最值得注意的是多媒体应用。 如交谈式音频 / 视频， 它们能够承受一定量的数据丢失， 在这些多媒体应用中，丢失的数据引起播放的音频 / 视频出现小干扰，而不是致命的损伤。

2. 吞吐量

之前讲过吞吐量的概念， 在沿着一条网络路径上的两个进程之间的通信会话场景中， 可用吞吐量就是发送进程能够向接收进程交付比特的速率。

因为其他会话将共享沿着该网络路径的带宽， 并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动。

这些观察导致另一种自然的服务，即运输层协议能够以某种特定的速率提供确保的可用吞吐量。

使用这种服务， 该应用程序能够请求 r 比特 / 秒的确保吞吐量， 并且该运输协议能够确保可用吞吐量总是为 至少 r 比特/ 秒。

这样的确保吞吐量的服务将对许多应用程序有吸引力。 例如， 如果因特网电话应用程序对语音以 32kbps 的速率进行编码， 那么它也必须以这个速率向网络发送数据， 并向接收应用程序交付数据。

如果运输协议不能提供这种吞吐量， 该应用程序或以较低速率进行编码（并且接收足够的吞吐量以维持这种较低的编码速率），或它可能必须放弃发送，这是因为对于这种因特网电话应用而言， 接收所需吞吐量的一半是几乎没有或根本没有用处的。

具有吞吐量要求的应用程序被称为带宽敏感的应用， 许多当前的多媒体应用是带宽敏感的， 尽管某些多媒体应用程序可能采用自适应编码技术对数字语音或视频以与当前可用带宽相匹配的速率进行编码、

带宽敏感的应用具有特定的吞吐量要求，而弹性应用能够根据情况或多或少地利用可供使用的吞吐量。电子邮件、文件传输以及 Web 传送都属于弹性应用。

3. 定时

运输层协议也能提供定时保证，如同具有吞吐量保证那样，定时保证能够以多种形式实现， 一个保证的例子如：发送方注入进套接字中的每个比特到达接收方的套接字不迟于 100ms， 这种服务将对交互式实时应用程序有吸引力， 如因特网电话、虚拟环境、电话会议和多方游戏，所有这些服务为了有效性而要求数据交付有严格的时间限制。

例如、在因特网电话中，较长的时延会导致会话中出现不自然的停顿，在多方游戏和虚拟互动环境中，在做出动作并看到来自环境（如来自位于端到端连接中另一端点的玩家）的响应之间，较长的时延使得它失去真实感。对于非实时的应用，较低的时延总比较高的时延好，但对端到端的时延没有严格的约束。

4. 安全性

最后，运输协议能够为应用程序提供一种或多种安全性服务。例如，在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据。

这种服务将在发送和接收之间提供机密性，以防止该数据以某种方式在这两个进程之间被观察到。运输协议除了机密性以外的其他安全性服务，包括数据完整性和端点鉴别，

因特网提供的运输服务

至此，我们已经考虑了计算机网络能够一般性地提供的运输服务，现在我们要更为具体地考察由因特网提供的运输服务类型。

因特网（更一般的是 TCP/IP 网络）为应用程序提供两个运输层协议，即 UDP 和 TCP。

当你（作为一个软件开发者）为因特网创建一个新的应用时，首先要做出的决定是， 选择 UDP 还是 选择 TCP。 每个协议为调用它们的应用程序提供了不同的服务集合。

1. TCP服务

TCP服务模型包括面向连接服务和可靠数据传输服务。 当某个应用程序调用 TCP 作为其运输协议时， 该应用程序就能获得来自 TCP的这两种服务。

• 面向连接的服务： 在应用层数据报文开始流动之前， TCP 让客户和服务器互相交换运输层控制信息。 这个所谓的握手过程提示客户和服务器，使它们为大量分组的到来做好准备。

在握手阶段后，一个 TCP 连接（TCP connection） 就在两个进程的套接字之间建立了。 这条连接时全双工的， 即连接双方的进程可以在此连接上同时进行报文收发，当应用程序结束报文发送时，必须拆除该连接。

• 可靠的数据传送服务：通信进程能够依靠 TCP， 无差错、按适当顺序交付所有发送的数据。 当应用程序的一端将字节流传进套接字时， 它能够依靠 TCP 将相同的字节流交付给接收方的套接字， 而没有字节的丢失和冗余。

TCP 还拥有拥塞控制进程，这种服务不一定能为通信进程带来直接好处，但能为因特网带来整体好处。 当发送方和接收方之间的网络出现阻塞时， TCP的拥塞控制机制会抑制发送进程（客户或服务器）。

TCP 进程也可以试图限制每个 TCP连接，使它们达到公平共享网络带宽的目的。

2. UDP服务

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

UDP 没有包括拥塞控制机制，所有 UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。（然而，值得注意的是实际端到端吞吐量可能小于这种速率，这可能是因为中间链路的带宽受限或因为拥塞而造成的）。

3. 因特网运输协议所不提供的服务

我们已经从 4 个方面组织了运输协议服务：可靠数据传输、吞吐量、定时和安全性。

我们已经注意到 TCP 提供了可靠的端到端数据传送，并且我们也知道 TCP 在应用层可以很容易地用 SSL 来加强以提供安全服务。但在我们对 TCP 和 UDP 的简要描述中，明显地缺少了对吞吐量或定时保证的讨论，即这些服务目前的因特网运输协议并没有提供。

这是否意味着诸如因特网电话这样的时间敏感应用不能运行在今天的因特网上呢 ? 答案显然是否定的， 因为在因特网运行时间敏感应用已经有多年了，这些应用经常工作的非常好，因为它们已经被设计成尽最大可能对付这种保证的缺乏。（可见这种保证也不是必须要有的）。

无论如何，在时延过大或端到端吞吐量受限时，好的设计也是有限制的，总之，今天的因特网能够为时间敏感应用提供满意的服务，但它不能提供任何定时或带宽保证。

上图指出了一些流行的因特网应用所使用的运输协议。

可以看到，电子邮件、远程终端访问、Web、文件传输都使用了 TCP。 这些应用选择 TCP的最主要原因是 TCP 提供了可靠数据传输服务， 确保所有数据最终到达目的地。

因特因特网电话应用通常能够容忍某些丢失但要求达到一定的最小速率才能有效工作，所以因特网电话应用的开发者通常愿意将该应用运行在 UDP 上，从而设法避开 TCP 的拥塞控制机制和分组开销，但因为许多防火墙被配置成 阻挡（大多数类型的）UDP 流量，所以因特网电话应用通常设计出如果 UDP 通信失败就使用 TCP 作为备份。

2.1.5 应用层协议

我们刚刚学习了通过把报文发送进套接字使网络进程间实现相互通信。但是构造报文？报文各个字段的含义，进程何时发送这些报文？

让我们展开了解应用层协议的具体细节：

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

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

有些应用层协议是由 RFC 文档定义的， 因此它们处于公共域中。例如， Web 的应用层协议 HTTP（超文本传输协议）就作为一个 RFC 可供使用。如果浏览器开发者遵从 HTTP RFC 规则， 所开发出的浏览器就能访问任何遵从该文档标准的 Web 服务器并获取相应 Web 页面。还有很多别的应用层协议是专用的，有意不为公共域使用。例如， Skype 使用了专用的应用层协议。

应用可以自己定义协议？

区分网络应用和应用层协议是很重要的，应用层协议只是网络应用的一部分，例如：

Web是一种客户-服务器应用功能，它运行客户按照需求从 Web 服务器获得文档，该 Web 应用有很多组成部分， 包括文档格式的标准（即HTML）、Web 浏览器（如Firefox）、Web服务器（如Microsoft服务器程序），以及一个应用层协议。

Web 的应用层协议是 HTTP， 它定义了在浏览器和 Web 服务器之间传输的报文格式和序列，因此， HTTP只是 Web 应用的一个部分。