HTTP 概况
Web 的应用层协议是超文本传输协议 （HyperText Transfer Protocol, HTTP) , 它是 Web的核心，在RFC 1945 和RFC 2616 中进行了定义 HTTP 由两个程序实现： 一个客户程序和一个服务器程序客户程序和服务器程序运行在不同的端系统中，通过交换HTTP 报文进行会话 HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方方式在详细解释HTTP 之前，应当回顾某些 eb 术语。
Web页面
Web 页面 (Web page) (也叫文档）是由对象组成的 一个对象 (object) 只是一个文件，诸如一个 HTML 文件 、一个 JPEG 图形 一个 Java 小程序或一个视频片段这样的文件，且它们可通过一个 RL 地址寻址 多数 Web 页面含有一个 HTML 基本文件 (base HTML file) 以及几个引用对象 例如，如果一个 Web 页面包含 HTML 文本和 JPEG 图形，那么这个 Web 页面有 个对象： 一个 HTML 基本文件加 个图形 HTML 基本文件通过对象URL 地址引用页面中的其他对象 每个 RL 地址由两部分组成：存放对象的服务楛主机名和对象的路径名例如， URL 地址 http: /www. someSchoo1. edu/ s01neDepartment/ pielure. gif, 其中的 www.someSchoo1.edu 就是主机名，/someDep ment/ picture. 创就是路径名。因为 Web 浏览器 (Web browser) (例如 Intemel Explorer Firefox) 实现了 HTTP 的客户端，所以在 Web环境中我们经常交替使用“浏览器”和“客户”这两个术语 Web务器 (Weh server) 实现了 HTTP的服务器端，它用千存储 Web 对象，每个对象由 URL寻址。流行的 Web 服务器有 Apache和 Microsofl Internet Information Server (微软互联网信息服务器）。
请求方式
HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送的Web 页面的方式 我们稍后详细讨论客户和服务器的交互过程，而其基本思想在当用户请求 Web 页面（如点击 个超链接）时，浏览器向服务器发出对该 页面中所包含对象的HTTP 求报文 服务器接收到请求并用包含这些对象的 HTTP 响应报文进行响应。
运输协议
HTTP 使用 TCP 作为它的支撑运输协议（而不是在 UDP 上运行） HTTP 客户首先发起个与服务器的 TCP 连接。一旦连接建立，该浏览器和服务器进程就可以通过套接字接口访问 TCP 。客户端的套接字接口是客户进程与 TCP 连接之间的门，在服务器端的套接字接口则是服务器进程 TCP 连接之间的客户向它的套接接口发送。HTTP 请求报文并从它的套接字接口接收 HTTP 响应报文 类似地 ，服 务器从它 套接字接口接收 HTTP 请求报文和向它的套接字接口发送 HTTP响应报文一旦客户向它的套接。接口发送了 个请求报文，该报文就脱离了客户控制并进入 TCP 的控制，TCP HTTP 提供可靠数据传输服务 这意味着， 个客户进程发出的每个 HTTP 请求报文最终 完整地到达服务器；类似地 ，服务器进程发出的每个 HTTP 报文最终能完整地到达客 这里我们看到了分层体系结构最大的优点，即 HTTP 协议不用担心数据丢失， 也不关 TCP 从网络的数据丢失和乱序故障中恢复的 细节 那是 TCP 以及协议栈较低层协议的工作。
非持续连接和持续连接
在许多因特网应用程序中，客户和服务器在一个相当长的时间范围内通信，其中客户发出一系列请求并且服务器对每个请求进行响应。依据应用程序以及该应用程序的使用方式，这一系列请求可以以规则的间隔周期性地或者间断性地一个接一个发出。当这种客户-服务器的交互是经TCP 进行的，应用程序的研制者就需要做一个重要决定，即每个请求/响应对是经一个单独的 TCP 连接发送，还是所有的请求及其响应经相同的 TCP 连接发送呢?采用前一种方法，该应用程序被称为使用非持续连接(non-persistent connection);采用后一种方法，该应用程序被称为使用持续连接(persistent connection)。为了深人地理解该设计问题，我们研究在特定的应用程序即 HTTP 的情况下持续连接的优点和缺点HTTP既能够使用非持续连接，也能够使用持续连接。尽管 HTTP在其默认方式下使用持续连接，HTTP客户和服务器也能配置成使用非持续连接
1、采用非持续连接的HTTP
我们看看在非持续连接情况下，从服务器向客户传送一个 Web 页面的步骤。假设该页面含有一个HTML基本文件和10个JPEG图形，并且这11个对象位于同一台服务器上。进步假设该HTML文件的URL为: http://www. someSchool.edu/someDepartment/home.index。我们看看发生了什么情况:
1、HTTP客户进程在端口号80发起一个到服务器www.someSchooledu的TCP连接该端口号是 HTTP的默认端口。在客户和服务器上分别有一个套接字与该连接相关联。
2、HTTP客户经它的套接字向该服务器发送一个HTTP 请求报文。请求报文中包含了路径名/someDepartment/homeindex(后面我们会详细讨论HTTP报文)。
3、HTTP服务器进程经它的套接字接收该请求报文，从其存储器 (RAM 或磁盘)中检索出对象www.someSchooledu/someDepartment/home.index，在一个HTTP响应报文中封装对象，并通过其套接字向客户发送响应报文。
4、HTTP服务器进程通知TCP 断开该TCP连接。(但是直到 TCP确认客户已经完整地收到响应报文为止，它才会实际中断连接。)
5、HTTP客户接收响应报文，TCP 连接关闭。该报文指出封装的对象是一个HTML文件，客户从响应报文中提取出该文件，检查该HTML文件，得到对10个JPEG图形的引用。
6、对每个引用的JPEG图形对象重复前4个步骤。当浏览器收到 Web 页面后，向用户显示该页面。两个不同的浏览器也许会以不同的方式解释(即向用户显示) 该页面。HTTP 与客户如何解释一个 Web 页面毫无关系HTTP规范([RFC1945]和[RFC2616])仅定义了在HTTP客户程序与HTTP服务器程序之间的通信协议。
TCP连接
上面的步骤举例说明了非持续连接的使用，其中每个TCP 连接在服务器发送一个对象后关闭，即该连接并不为其他的对象而持续下来。值得注意的是每个TCP 连接只传输一个请求报文和一个响应报文。因此在本例中，当用户请求该 Web 页面时，要产生11个TCP 连接。
在上面描述的步骤中，我们有意没有明确客户获得这10个JPEC图形对象是使用10个串行的TCP 连接，还是某些JPEG 对象使用了一些并行的TCP 连接。事实上，用户能够配置现代浏览器来控制连接的并行度。在默认方式下，大部分浏览器打开5~10个并行的TCP连接，而每条连接处理一个请求响应事务。如果用户愿意，最大并行连接数可以设置为1，这样10 条连接就会串行建立。
请求时间
先简单估算一下从客户请求HTML基本文件起到该客户收到整个文件止所花费的时间。为此，我们给出往返时间(Round-TripTime，RTT)的定义该时间是指一个短分组从客户到服务器然后再返回客户所花费的时间。RTT包括分组传播时延、分组在中间路由器和交换机上的排队时延以及分组处理时延。请求并接收一个 HTML 文件所需的时间估算这引起浏览器在它和 Web 服务器之间发起一个TCP 连接;这涉及一次“三次握手”过程即客户向服务器发送一个小TCP 报文段，服务器用一个小TCP 报文段做出确认和响应最后，客户向服务器返回确认。三次握手中前两个部分所耗费的时间占用了一个 RTT。完成了三次握手的前两个部分后，客户结合三次握手的第三部分(确认) 向该TCP 连接发送一个HTTP 请求报文。一旦该请求报文到达服务器，服务器就在该TCP 连接上发送HTML文件。该HTTP 请求/响应用去了另一个RTT。因此，粗略地讲，总的响应时间就是两个RTT加上服务器传输 HTML文件的时间。
2、采用持续连接的HTTP
非持续连接有一些缺点。第一，必须为每一个请求的对象建立和维护一个全新的连接。对于每个这样的连接，在客户和服务器中都要分配 TCP 的缓冲区和保持TCP 变量这给 Web 服务器带来了严重的负担，因为一台 Web 服务器可能同时服务于数以百计不同的客户的请求。第二，就像我们刚描述的那样，每一个对象经受两倍 RTT的交付时延即一个RTT用于创建TCP，另一个RTT用于请求和接收一个对象。
在采用HTTP1.1持续连接的情况下，服务器在发送响应后保持该TCP 连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。特别是，一个完整的 Web页面(上例中的 HTML基本文件加上10个图形)可以用单个持续TCP 连接进行传送。更有甚者，位于同一台服务器的多个 Web 页面在从该服务器发送给同一个客户时，可以在单个持续 TCP 连接上进行。对对象的这些请求可以一个接一个地发出，而不必等待对未决请求(流水线) 的回答。一般来说，如果一条连接经过一定时间间隔(一个可配置的超时间隔)仍未被使用，HTTP 服务器就关闭该连接。HTTP的默认模式是使用带流水线的持续连接。最近，HTTP/2[RFC7540] 是在HTTP11基础上构建的，它允许在相同连接中多个请求和回答交错，并增加了在该连接中优化 HTTP 报文请求和回答的机制。