应用层协议原理

网络应用程序的体系结构

由应用程序研发者设计, 规定了如何在各种端系统上组织该应用程序。
两种主流体系结构：客户-服务器体系结构，对等（P2P）体系结构。

客户-服务器体系结构

客户(client)和服务器(server)都是指通信中所涉及的两个应用进程。客户是服务请求方，服务器是服务提供方。
一个典型的例子是Web应用程序，其中总是打开的Web服务器服务于来自浏览器（运行在客户主机上）的请求。当Web服务器接收到来自某客户对某对象的请求时，它向该客户发送所请求的对象作为响应。

特征：

• 客户相互之间不直接通信。
• 该服务器具有固定的、周知的地址(IP地址)，因为该服务器总是打开的，客户总是能够通过向该服务器的IP地 址发送分组来与其联系。

该体系结构著名的应用程序包括WEB、FTP、Telnet和电子邮件。

在一个客户-服务器应用中，常常会出现一台单独的服务器主机跟不上它所有客户请 求的情况。例如，一个流行的社交网络站点如果仅有一台服务器来处理所有请求，将很快变得不堪重负。为此，配备大量主机的数据中心（data center）常被用于创建强大的虚拟 服务器。最为流行的因特网服务一一如搜索引擎（如谷歌、Bing和百度）、因特网商务（如亚马逊、e-Bay和阿里巴巴）、基于Web的电子邮件（如Gmail和雅虎邮件）、社交网 络（如脸书、Instagram推特和微信），就应用了一个或多个数据中心。一个数据中心能够有数十万台服务器。

P2P体系结构

应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。因为这种对等方通信不必通过专门的服务器，该体系结构被称为对等方到对等方的。

许多目前流行的、流量密集型应用都是P2P体系结构的。这些应用包括文件共享（例如BitTorrent） x对等方协助下载加速器（例如迅雷）、因特网电话和视频会议（例如Skype）。

P2P体系结构的最引人入胜的特性之一是它们的自扩展性 self-scalability o例如, 在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等 方通过向其他对等方分发文件也为系统增加服务能力。然而，未来P2P应用由于高度非集中式结构，面临安全性、性 能和可靠性等挑战。

进程通信

用操作系统的术语来说，进行通信的实际上是进程（process）而不是程序。一个进程可以被认为是运行在端系统中的一个程序。当多个进程运行在相同的端系统上时，它们使用进程间通信机制相互通信。进程间通信的规则由端系统上的操作系统确定。

在两个不同端系统上的进程，通过跨越计算机网络交换报文（message）而相互通信。对每对通信进程, 我们通常将这两个进程之一标识为客户（client）,而另一个进程标识为服务器（serve"。 对于Web而言，浏览器是一个客户进程，Web服务器是一台服务器进程。对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方标识为服务器。

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

两个进程互相发送报文时，进程通过一个称为套接字（socket）的软件接口向网络发送报文和从网络接收报文。
下图显示了两个经过因特网通信的进程之间的套接字通信(假设运输层协议是因特网的TCP协议)：

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

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

进程寻址

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

• 1.主机的地址；
• 2.在目的主机中指定接收进程的标识符。

主机由IP地址标识，IP地址是一个32比特的量且它能够唯一地标识该主机。
除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程(更具体地说，接收套接字)。因为一般而言一台主机能够运行许多网络应用, 这些信息是需要的。

目的地端口号(port number)用于这个目的。已经给流行的应用分配 了特定的端口号。例如，Web服务器用端口号80来标识。邮件服务器进程(使用SMTP协议)用端口号25来标识。

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

前面讲过套接字是应用程序进程和运输层协议之间的接口。在发送端的应用程序将报文推进该套接字。在该套接字的另一侧，运输层协议负责从接收进程的套接字得到该报文。 包括因特网在内的很多网络提供了不止一种运输层协议。
当开发一个应用时，必须选择一种可用的运输层协议。如何做出这种选择呢？最可能的方式是，通过研究这些可用的运输层协议所提供的服务，选择一个最能为你的应用需求提供恰当服务的协议。这种情况类似于在两个城市间旅行时选择飞机还是火车作为交通工具。每种运输模式为你提供不同的服务，你必须选择一种或另一种(例如，火车可以直到市区上客和下客，而飞机提供了更短的旅行时间)。
一个运输层协议能够为调用它的应用程序提供什么样的服务呢？我们大体能够从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。

可靠数据传输

分组在计算机网络中可能丢失。像电子邮件、文件传输、远程主机访问、Web文档传输以及金融应用等这样的应用，数据丢失可能会造成灾难性的后果。因此，为了支持这些应用，必须做一些工作以确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输。
运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数 据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。
当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用(loss-tolerant application)所接受，最值得注意的是多媒体应用，如交谈式音频/视频，它们能够承受一定量的数据丢失。在这些多媒体应 用中，丢失的数据引起播放的音频/视频出现小干扰，而不是致命的损伤。

吞吐量

运输层协议能够以某种特定的速率提供确保的可用吞吐量。使用这种服务，该应用程序能够请求 r 比特/秒的确保吞吐量，并且该运输协议能够确保可用吞吐量总是为至少 r 比特/秒。
例如，如果因特网电话应用程序对语音以32kbps的速率进行编码， 那么它需要以这个速率向网络发送数据，并以该速率向接收应用程序交付数据。如果运输协议不能提供这种吞吐量，该应用程序或以较低速率进行编码（并且接收足够的吞吐量以 维持这种较低的编码速率），或它可能必须放弃发送.这是因为对于这种因特网电话应用而言，接收所需吞吐量的一半是几乎没有或根本没有用处的。
具有吞吐量要求的应用程序被称为带宽敏感的应用。

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

定时

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

安全性

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

因特网提供的运输服务

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

TCP服务

TCP协议包括面向连接服务和可靠数据传输服务。还具有拥塞控制机制。

面向连接的服务

在应用层数据报文开始流动之前，TCP让客户和服务器互相交 换运输层控制信息。这个所谓的握手过程提醒客户和服务器，让它们为大量分组 的到来做好准备。在握手阶段后，一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。当应用程序结束报文发送时，必须拆除该连接。

可靠的数据传送服务

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

拥塞控制

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

TCP安全

无论TCP还是UDP都没有提供任何加密机制，这就是说发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同。因此，举例来说如果某发送进程以明文方式（即没有加密）发送了一个口令进入它的套接字，该明文口令将经过发送方与接收方之间的所有链路传送，这就可能在任何中间链路被嗅探和发现。因为隐私和其他安全问 题对许多应用而言已经成为至关重要的问题，所以因特网界已经研制了 TCP的加强版 本，称为安全套接字层（Secure Sockets Layer, SSL）。用SSL加强后的TCP不仅能够做 传统的TCP所能做的一切，而且提供了关键的进程到进程的安全性服务，包括加密、数据完整性和端点鉴别。我们强调SSL不是与TCP和UDP在相同层次上的第三种因特网运输协议，而是一种对TCP的加强，这种强化是在应用层上实现的。

UDP服务

UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
UDP是无连接的，因此在两个进程通信前没有握手过程。
UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。
UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层 （网络层）注入数据。

应用层协议

应用层协议定义了运行在不同端系统上的应用程序进程如何相互传递报文。

特别是定义了：

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

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

网络应用和应用层协议区别

应用层协议只是网络应用的一部分。
比如，Web是一种客户----服务器应用，它允许客户按照需求从Web服务器获得文档。
该Web应用有很多组成部分,包括文档格式的标准（即HTML）、Web浏览器（如Firefox和Microsoft Internet Explorer）、Web服务器（如Apache、Microsoft服务器程序），以及一个应用层协议。
Web的应用层协议是HTTP,它定义了在浏览器和Web服务器之间传输的报文格式和序列。因此，HTTP只是Web应用的一个部分。