应用层（一）

目录

2.1 应用层协议原理

• 网络应程序体系结构
• 进程通信
• 应用层协议

2.2 Web和HTTP

• HTTP概况
• 非持续性连接和持续性连接
• HTTP报文格式
• 用户与服务器的交互：cookie
• Web缓存
• 条件GET方法

---

应用层协议原理

2.1.1 网络应用程序体系结构

应用程序的体系结构明显不同于网络的体系结构，从应用程序开发者的角度看，网络体系结构是固定的，并为应用程序提供了特定的服务集合。在另一方面，应用程序体系结构是由应用程序研发者设计，规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序所使用的两种主流体系结构之一：

• 客户-服务器体系结构
• 对等（P2P）体系结构

在C/S中，有一个总是打开的主机叫服务器，它服务于来自许多其他称为客户的主机的请求。它有两个特点：

• C/S中，客户之间互相不通信，例如，在Web应用中两个浏览器并不直接通信。
• 该服务器具有固定的，周知的地址，该地址称为IP地址。

在C/S应用中，常常会出现一台单独的服务器主机跟不上它所有的客户请求的情况。为此，配备大量主机的数据中心常被用于创建强大的虚拟服务器。

在P2P体系结构中，对位于数据中心的专用服务器有最小的（或者没有）依赖。相反，应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方。其最引人入胜的特性之一是它们的自扩展性。

2.1.2 进程通信

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

• 客户和服务器进程

  无论如何，在任何给定的一对进程之间的通信会话场景中，发起通信的进程被标识为客户，在会话开始时等待联系的进程是服务器。

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

  多数应用进程是由通信进程对组成，每对中的两个进程互相发送报文。进程通过一个称为“套接字”的软件接口向网络发送报文和从网络接收报文。套接字是同一台主机内应用层与传输层之间的接口。

• 进程寻址

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

在因特网中，主机由其IP地址标识（一个32比特的量且它能够唯一地标识该主机）。标识符则是目的地址端口号，比如，Web服务器用端口号80来表示。

2.1.4 应用层协议

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

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

---

Web和HTTP

2.1.1 HTTP概况
Web的应用层协议是超文本传输协议（HyperText Transfer Protocal），它是Web的核心。HTTP由两个程序实现：

• 一个客户程序
• 一个服务器程序

客户程序和服务器程序运行在不同的端系统中，通过交换HTTP报文进行会话。HTTP定义了这些报文的结构以及客户和服务器进行报文交换的方式。

HTTP使用TCP作为它的支撑运输协议。HTTP客户首先发起一个与服务器的TCP连接，一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问TCP。即：

• 客户端的套接字接口是客户进程与TCP连接之间的门
• 服务器端的套接字接口是服务器进程与TCP连接之间的门

客户向它的套接字接口发送HTTP请求报文，并从它的套接字接口接受HTTP响应报文。类似服务器。一旦客户从它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP连接。

注意：

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

2.2.2 非持续连接和持续连接

• 非持续连接
  每个请求/响应对是经过一个单独的TCP连接发送
• 持续连接
  每个请求/响应对是经相同的TCP连接发送

1. 采用非持续连接的HTTP

看从服务器向客户端传送一个web页面：

假设某页面有一个HTML基本文件和10个JPEG文件，并且这11个对象位于同一台服务器上。该HTML文件的URL为：
http://www.someSchool.edu/someDepartment/home.index
我们看看发生了什么情况：

• HTTP客户进程在端口号80发起一个到服务器www.someSchool.edu的TCP连接，该端口号是HTTP的默认端口号。在客户和服务器上分别有一个套接字与该连接相连。
• HTTP客户经它的套接字向该服务器发送一个HTTP请求报文，请求报文中包含了路径名/someDepartment/home.index
• HTTP服务器进程经过它的套接字接收该请求报文，从其存储器（RAM或磁盘）中检索出对象www.someSchool.edu/someDepartment/home.index，在一个HTTP响应报文中封装对象，并通过其套接字向客户发送响应报文。
• HTTP服务器进程通知TCP断开该TCP连接。（但是直到TCP确认客户已经完整地收到响应报文为止，它才会实际中断连接）
• HTTP客户接收响应报文，TCP连接关闭。该报文指出封装对象是一个HTML文件，客户从响应报文中提取出该文件，检查该HTML文件，得到对10个JPEG图形的引用
• 对每个JPEG图形对象重复前4个步骤

其中每个TCP连接在服务器发送一个对象后关闭，即该连接不为其他对象而持续下来。值得注意的是每个TCP连接只传输一个请求报文和一个响应报文。因此在本例中，当用户请求该Web页面时，要产生11个TCP连接。

image.png

2. 采用持续连接的HTTP

非持续连接有一些缺点：

• 首先，必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配TCP缓冲区和保持TCP变量，这给Web服务器带来了严重的负担，因为一台Web服务器可能同时服务于数以百计不同的客户的请求。
• 每一个对象经过两倍RTT的交付时延，即一个RTT用于创建TCP，另一个用于请求和接受一个对象。

在采用持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间的后续请求和响应报文能够通过相同的连接进行传送。可以一个接一个地发出对对象的这些请求而不必等待对未决请求的回答。一般来说，如果一条连接经过一定时间间隔（一个可配置的超时间隔）仍未被使用，HTTP服务器就关闭该连接。HTTP默认模式是使用带流水线的持续连接。

2.2.3 HTTP报文格式

HTTP报文有两种：

• 请求报文

  
  请求报文的通用格式

使用GET方法时实体体为空，使用POST报文时才使用该实体体。

• 响应报文

  
  响应报文的通用格式

2.2.4 用户与服务器之间的交互：cookie
我们前面提到了HTTP服务是无状态的，这简化了服务器的设计，并且允许工程师去开发可以同时处理数以千计的TCP连接的高性能Web服务器。然而一个Web站点通常希望可以识别用户,可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用cookie（允许站点对用户进行跟踪）。

cookie技术有四个组件：

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

一个例子：
Susan总是从家中PC使用IE上网，她首次上亚马逊。假设她已经去过eBay站点。当请求报文到达Amazon Web服务器时，该Web站点将产生一个唯一的标识码，并以此作为索引在它后端数据库中产生一个表项。接下来Amazon Web服务器用一个包含Set-cookie:首部的HTTP响应报文对Susan的浏览器进行响应，其中Set-Cookie:首部有该识别码，例如，该首部行可能是：

Set-cookie:1678

用cookie跟踪用户状态

从上述讨论中我们可以看到：cookie可以用于标识一个用户。用户首次访问一个站点时，可能需要提供一个用户标识（可能是名字）。在后继回话中，浏览器向服务器传递一个cookie首部，从而向该服务器标识了用户。因此cookie可以在无状态的HTTP之上建立一个用户会话层。例如，当用户向一个基于Web的电子邮件系统注册时，浏览器向服务器发送cookie信息，允许该服务器在用户与应用程序会话的过程中标识该用户。

2.2.5 Web缓存

Web缓存器也叫代理服务器（proxy server），它是能够代表初始Web服务器来满足HTTP请求的网络实体。Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。如图所示，可以配置用户的浏览器，使得用户的所有HTTP请求首先指向Web缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该Web缓存器。举例来说，假设浏览器正在请求对象：http://www.someschool.edu/campus.gif,将会发生如下情况

• 浏览器建立一个到Web缓存器的TCP连接，并向Web缓存器中的对象发送一个HTTP请求
• Web缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web缓存器就向客户浏览器用HTTP响应报文返回该对象
• 如果Web缓存器中没有该对象，它就打开一个与该对象的初始服务器（如www.someschool.edu）的TCP连接。Web缓存器则在这个缓存器到服务器的TCP连接上发送一个对该对象的HTTP请求。在收到该请求后，初始服务器向该Web缓存器发送具有该对象的HTTP响应。
• 当Web缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用HTTP响应报文发送该副本（通过现有的客户浏览器和Web缓存器之间的TCP连接）

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

image.png

2.2.6 条件GET方法

尽管高速缓存能减少用户感受到的响应时间，但也引入了一个新的问题：存放在缓存器中的对象副本可能是陈旧的。换句话说，保存在服务器中的对象自该副本缓存在客户上以后可能已经被修改了。幸运的是，HTTP协议有一种机制，允许缓存器证实它的对象是最新的。这种机制就是条件GET方法。