计算机网络＜2＞ 应用层（1）

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

2.1 应用层协议原理

   研发网络应用程序的核心是写出能够运行在不同的端系统和通过网络彼此通信的程序。而网络核心中没有应用层软件，网络核心设备并不在应用层上起作用，而仅在较低层起作用。这种基本设计，即将应用软件限制在端系统的方法，促进了大量的网络应用程序的迅速研发和部署。

2.1.1 网络应用程序体系结构

可能的应用架构： ①客户—服务器模式（C/S:client/server)，②对等模式(P2P:Peer To Peer)，③混合体：客户—服务器和对等体系结构。

（1）客户—服务器（C/S）体系结构

服务器：●一直在运行；●固定的IP地址和周知的端口号(约定)；●拓展性：利用数据中心进行扩展，扩展性差。

客户端：●主动与服务器通信；●与互联网是间歇性的连接；●IP地址可能是动态的；●不能与其它客户端通信。

如Web，FTP，Telent和电子邮件。

 （2）对等体（P2P）体系结构

●（几乎）没有一直运行的服务器；

●任意端系统之间可以进行通信；

●每一个节点既是客户端又是服务器；

●自扩展性—新peer节点带来新的服务能力，当然也带来新的服务请求；

●参与的主机间歇性连接且可以改变IP地址；

●难以管理。

比如： Gnutella，迅雷。

（3）C/S和P2P体系结构的混合体

●文件搜索：集中，①主机在中心服务器上注册其资源；②主机向中心服务器查询资源位置。

●文件传输：P2P，任意Peer节点之间。

●在线检测：集中，①当用户上线时，向中心服务器注册其IP地址；②用户与中心服务器联系，以找到其在线好友的位置。

●两个用户之间：P2P。

2.1.2 进程通信

---

 进程：在主机上运行的应用程序。

 在同一个主机内，可以直接使用操作系统进程间通信机制通信。而不同主机，是通过交换报文来通信。发送进程生成并向网络中发送报文，接收进程接收这些报文并可能通过回送报文进行响应。

 客户进程：发起通信的进程。

 服务器进程：等待连接的进程。

 如在一个Web中，一个浏览器进程向一台Web服务器进程发起联系，因此该浏览器进程是客户，而该Web服务器进程是服务器。

 显然，对于P2P，一个进程能够既是客户又是服务器，但P2P架构的应用也要区分客户端进程和服务器进程。

---

  在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址 为了标识SAP该接收进程，需要定义两种信息：①主机的地址；②在目的主机中指定接收进程的标识符。

 在因特网中，主机由其IP地址(IP address)标识。除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程。目的地端口号(port number)用于这个目的。一个进程由IP+port标识。本质上，一对主机进程之间的通信由2个端节点构成。

 如Web服务器用端口号80来标识。

  从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字(socket)的软件接口向网络发送报文和从网络接收报文。比如房子和门，房子就是一个进程，而门就是一个套接字。

  由于该套接字是建立网络应用程序的可编程接口，因此套接字也 称为应用程序和网络之间的应用程序编程接口 (Application Programming, Interface , API)。

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

---

传输层提供的服务—需要穿过层间的信息：  

（1）层间接口必须要携带的信息：

●要传输的报文（对于本层来说：SDU）；

●谁传的：对方的应用进程的标示：IP+TCP(UDP) 端口；

●传给谁：对方的应用进程的标示：对方的IP+TCP(UDP)端口号。

（2）传输层实体（tcp或者udp实体）根据这些信息进行TCP 报文段（UDP数据报）的封装 ：

● 源端口号，目标端口号，数据等；

● 将IP地址往下交IP实体，用于封装IP数据报（源IP，目标IP）。

但如果如果Socket API每次传输报文，都携带如此多的信息，太繁琐易错，不便于管理。于是我们利用代号标示通信的双方或者单方。

---

 TCP socket：简单，便于管理

 TCP服务：两个进程之间的通信需要之前要建立连接，而两个进程通信会持续一段时间，所以通信关系稳定。

  我们可以用一个整数表示两个应用实体之间的通信关系 ，作为本地标识。使得穿过层间接口的信息量最小。于是对于使用面向连接服务（TCP）的应用而言，套接字是4元组的一个具有本地意义的标示（源IP，源port，目标IP，目标port）。应用使用这个标示，与远程的应用进程通信，不必在每一个报文的发送都要指定这4元组。

  就像使用操作系统打开一个文件，OS返回一个文件句柄一样，以后使用这个文件句柄，而不是使用这个文件 的目录名、文件名。使得通信更加简单方便，便于管理。

---

UDP socket：

 UDP服务：两个进程之间的通信需要之前无需建立连接，对于每个报文都是独立传输的，而前后报文可能给不同的分布式进程。

 因此，只能用一个整数表示本应用实体的标示，因为这个报文可能传给另外一个分布式进程。这样使得穿过层间接口的信息大小最小。

  对于使用无连接服务(UDP)的应用而言，套 接字是2元组的一个具有本地意义的标识（IP，port）。因此在发送数据报时，采用创建好的本地套接字（标示 ID），就不必在发送每个报文中指明自己所采用的 ip和port。但传输报文时：必须要提供对方IP和port；接收报文时： 传输层需要上传对方的IP和port。

---

 TCP：可靠的传输服务，流量控制，拥塞控制，面向连接，但没有时间保证、最小吞吐保证和安全。

 UDP：不可靠数据传输，没有可靠， 没有流量控制、没有拥塞控制、 没有时间、带宽保证、不建立连接。

UDP存在的必要性： 

①能够区分不同的进程，而IP服务不能：在IP提供的主机到主机端到端功能的基础上，区分了主机的 应用进程。

②无需建立连接，省去了建立连接时间，适合事务性的应用。

③不做可靠性的工作，例如检错重发，适合那些对实时性要求比较高而对正确性要求不高的应用：

 因为为了实现可靠性（准确性、保序等），必须付出时间代价（检错重发）。

④没有拥塞控制和流量控制，应用能够按照设定的速度发送数据。而在TCP上面的应用，应用发送数据的速度和主机向网络发送的实际速度是不一致的，因为有流量控制和拥塞控制。

---

 2.1.3 应用层协议

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

  ●交换的报文类型：请求和应答报文。

  ●各种报文类型的语法：报文中的各个字段及其描述。

  ●字段的语义：即字段取值的含义。

  ●进程何时、如何发送报文及对报文进行响应的规则。

  而应用协议仅仅是应用的一个组成部分。

如：Web应用包括：HTTP协议，web客户端，web服务器，HTML等。

---

而对于应用层，传输层需要提供什么样的服务？

我们大体能够从四个方面对应用程序服务要求进行分类：可靠数据传输、吞吐量、定时和安全性。

①可靠的数据传输

  有些应用则要求100%的可靠数据传输（如文件），而有些应用（如音频）能容忍一定比例以下的数据丢失。

②吞吐量

   一些应用（如多媒体）必须需要最小限度的吞吐，从而使得应用能够有效运转。一些应用能充分利用可供使用的吞吐(弹性应用)。

③定时

   一些应用出于有效性考虑，对数据传输有严格的时间限制，比如Internet 电话、交互式游戏等。

④安全性

  运输协议能够为应用程序提供一种或多种安全性服务。机密性，完整性，可认证性。

---

  无论TCP还是 UDP 都没有提供任何加密机制，这就是说发送进程传进其套接字的数据，与经网络传送到目的进程的数据相同。所以因特网界已经研制了TCP的加强版本，称为安全套接字层 (Secure Sockets Layer, SSL)。

  SSL在应用层，在TCP上面实现，提供加密的TCP连接。应用采用SSL库，SSL库使用TCP通信。

  SSL socket API：应用通过API将明文交给socket，SSL将其加密在互联网上传输。加密的数据经因特网传送到接收进程中的TCP套接字，该接收套接字将加密数据传递给SSL ，由其进行解密 后，SSL通过它的SSL 套接字将明文数据传递给接收进程。

2.2 Web和HTTP

Web页：由一些对象组成。对象可以是HTML文件、JPEG图像、Java小程序、声音剪辑文件等。  

Web页含有一个基本的HTML文件，该基本HTML文件又包含若干对象的引用（链接）。通过URL对每个对象进行引用。URL包括访问协议，用户名，口令字，端口等；

 2.2.1 HTTP概括

HTTP：Web 的应用层协议——超文本传输协议，它是Web的核心。

HTTP由两个程序实现：一个客户程序和一个服务器程序，客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。（客户/服务器模式）

●客户：请求、接收和显示Web对象的浏览器。

●服务器：对请求进行响应，发送对象的Web服务器。

HTTP使用TCP作为它的支撑运输协议。

HTTP客户首先发起一个与服务器的TCP连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。

一般服务器向客户发送被请求的文件而不存储任何关于该客户的状态信息，比如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完 全忘记不久之前所做过的事。

正因为HTTP服务器并不保存关于客户的任何信息，所以 我们说HTTP是一个无状态协议。

2.2.2 HTTP非持续连接和持续连接

  生活中，客户和服务器通常在一个个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该成用程序的使用方式，这一系列请求可以以规则的问隔周期性地或者间断性地一个接一个发。

非持续连接：对于即每个请求或响应对是经一个单独的TCP连接发送。

●最多只有一个对象在TCP连接上发送。

●下载多个对象需要多个TCP连接。

●HTTP/1.0使用非持续连接。

响应时间模型：

设往返时间为RTT：一个小的分组从客户端到服务器，在回到客户端的时间（传输时间忽略）。

响应时间：RRT1（用来发起TCP连接）+RRT（用来HTTP请求并等待HTTP响应）+文件传输时间

持续连接：对于即每个请求或响应对是经同一个的TCP连接发送。

●服务器在发送响应后，仍保持TCP连接。在相同客户端和服务器之间的后续请求和响应报文通过相同的连接进行传送。

●多个对象可以在一个（在客户端和服务器之间的）TCP连接上传输。

●HTTP/1.1 默认使用持续连接。

持续连接分为流水方式的HTTP持续连接和非流水方式的HTTP持续连接：

（1）非流水方式的HTTP持续连接：

         ●客户端只能在收到前一个响应后才能发出新的请求；

         ●每个引用对象花费一个RTT。

（2）流水方式的HTTP持续连接：

         ●HTTP/1.1的默认模式

         ●客户端遇到一个引用对象就立即产生一个请求

         ●所有引用（小）对象只花费一个RTT是可能的

2.2.3 HTTP报文格式

两种类型的HTTP报文：请求、响应。

HTTP请求报文：ASCII（人能阅读的）

请求报文的通用格式：

   注意到了在首部行（和附加的回车和换行）后有”实体体“。我们使用GET方法时实体体为空，而使用POST方法时才使用该实体体。即我们提交表单输入时，采用POST方式。此外，我们也可以采用URL方式。

 ●POST方式：网页通常包括表单输入，这包含在实体主体中的输入被提交到服务器。

 ●URL方式：使用GET方法，输入通过请求行的URL字段上载，比如一个表单使用GET方法，它有两个字段，分别填写的是 "monkeys"和"bananas" ，这样，该URL结构为       www.somesite.com/animalsearch? monkeys&bananas。

HTTP响应报文：

  响应报文分为三个部分：一个初始状态行，6个首部行，然后是实体体。实体体是报文的主要部分。

HTTP的响应状态码（位于服务器—>客户端的响应报文中的首行）：

响应报文基本格式：

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

由于HTTP是无状态的，但一个Web站点通常希望能够识别用户，或者因为它希望把内容与用户身份联系起来。为此， HTTP 使用了cookie。

 cookie的4个组成部分：

（1）在HTTP响应报文中有一个cookie的首部行；

（2）在HTTP请求报文含有一个cookie的首部行；

（3）在用户端系统中保留有一个cookie文件，由用户的浏览器管理；

（4）在Web站点有一个后端数据库。

cookies给我们带来了：用户验证，购物车，推荐，用户状态等。但由于cookies允许站点知道许多关于用户的信息，故存在用户隐私的问题。

2.2.5 Web缓存

  Web缓存器也叫代理服务器，它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存既是服务端也是客户端。

Web缓存的作用：①降低客户端的请求响应时间，②可以大大减少一个机构内部网络与Internent接入链路上的流量，③互联网大量采用了缓存，可以使较弱的ICP也能够有效提供内容。

缓存示例：

   我们假如平均对象大小为1Mb，而机构内浏览器对原始服务器的平均请求率为 = 15请求/s，平均到浏览器的速度为15mbps，机构内部路由器到原始服务器再返回到路由器的的延时为2s，接入的链路带宽为1.54mbps。

   我们计算得出局域网上的流量强度为15*100/100=15%，而接人链路上的流量强度为15*1/15=1，当流量强度为1时，时延会无限增大，我们可以用增加接入链路的速率的方式解决，将15mbps改为100mbps，这样时延大约为2s，但代价很高，我们用Web缓存分析：

   假设缓存的命中率为0.4，则40%的请求会被快速响应，时延约在10ms 以内，剩下的60%的请求仍然要由初始服务器解决。对于60%的请求，接人链路上的流量强度从1减小到 0.6，此时时延只会有几十毫秒，远小于2s，考虑这些之后，平均时延为0.4*0.01+0.6*2.01<2s，而Web缓存更加经济。故Web方案更好。

2.2.6 条件GET方法

由于Web缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了，因此HTTP协议有一种机制，允许缓存器证实它的对象是最新的，这种机制就是条件GET方法。

目标：如果缓存器中的对象拷贝是最新的，就不要发送对象。

条件GET请求报文：①请求报文使用GET方法；并且②请求报文中包含一个“If_Modified_Since:”首首部行。而缓存器会在HTTP请求中指定缓存拷贝的日期，对于服务器：如果缓存拷贝陈旧，则响应报文没包含对象。