HTTP的结构是什么?试用示例阐述

HTTP基本架构

下面我们用一张简单的流程图来展示HTTP协议基本架构，以便大家先有个基本的了解。

9.png

Web Client可以是浏览器、搜索引擎、机器人等等一切基于HTTP协议发起http请求的工具。Web Server可以是任何的能解析HTTP请求，并返回给Web Client可识别的响应的服务，常见的有apache、nginx、IIS等等web服务器。

浓缩就是精华，看下最简洁的HTTP交互图：

10.png

HTTP报文结构

请求报文

HTTP请求报文由请求行、请求头、空行和请求内容4个部分构成。

如下图所示：

11.png

下面对上图进行简单的分析：

请求行

由请求方法字段、URL字段、协议版本字段三部分构成，它们之间由空格隔开。常用的请求方法有：GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。

请求头

请求头由key/value对组成，每行为一对，key和value之间通过冒号(:)分割。请求头的作用主要用于通知服务端有关于客户端的请求信息。

典型的请求头有：

User-Agent：生成请求的浏览器类型

Accept：客户端可识别的响应内容类型列表；星号* 用于按范围将类型分组。*/*表示可接受全部类型，type/*表示可接受type类型的所有子类型。

Accept-Language: 客户端可接受的自然语言

Accept-Encoding: 客户端可接受的编码压缩格式

Accept-Charset： 可接受的字符集

Host: 请求的主机名，允许多个域名绑定同一IP地址

connection：连接方式（close或keeplive）

Cookie: 存储在客户端的扩展字段

空行

最后一个请求头之后就是空行，用于告诉服务端以下内容不再是请求头的内容了。

请求内容

请求内容主要用于POST请求，与POST请求方法配套的请求头一般有Content-Type（标识请求内容的类型）和Content-Length（标识请求内容的长度）

响应报文

HTTP响应报文由状态行、响应头、空行和响应内容4个部分构成。

如下图所示：

12.png

下面对响应报文格式进行简要的分析说明：

状态行

由HTTP协议版本、状态码、状态码描述三部分构成，它们之间由空格隔开。

状态码由3位数字组成，第一位标识响应的类型，常用的5大类状态码如下：

1xx：表示服务器已接收了客户端的请求，客户端可以继续发送请求

2xx：表示服务器已成功接收到请求并进行处理

3xx：表示服务器要求客户端重定向

4xx：表示客户端的请求有==非法内容==

5xx：标识服务器未能正常处理客户端的请求而出现意外错误

常见状态码说明：

200 OK： 表示客户端请求成功

400 Bad Request： 表示客户端请求有语法错误，不能被服务器端解析

401 Unauthonzed： 表示请求未经授权，该状态码必须与WWW-Authenticate报文头一起使用

404 Not Found：请求的资源不存在，例如输入了错误的url

500 Internal Server Error： 表示服务器发生了不可预期的错误，导致无法完成客户端的请求

503 Service Unavailable：表示服务器当前不能处理客户端的请求，在一段时间后服务器可能恢复正常

响应头

一般情况下，响应头会包含以下，甚至更多的信息。

Location：服务器返回给客户端，用于重定向到新的位置

Server： 包含服务器用来处理请求的软件信息及版本信息

Vary：标识不可缓存的请求头列表

Connection: 连接方式。

对于==请求端==来讲：close是告诉服务端，断开连接，不用等待后续的求请了。keeplive则是告诉服务端，在完成本次请求的响应后，保持连接，等待本次连接后的后续请求。

对于==响应端==来讲：close表示连接已经关闭。keeplive则表示连接保持中，可以继续处理后续请求。Keep-Alive表示如果请求端保持连接，则该请求头部信息表明期望服务端保持连接多长时间（秒），例如300秒，应该这样写Keep-Alive:300

空行

最后一个响应头之后就是空行，用于告诉请求端以下内容不再是响应头的内容了。

响应内容

服务端返回给请求端的文本信息。

在两台计算机之间使用 HTTP 协议通信时，在一条通信线路上必定有 一端是客户端，另一端则是服务器端。

仅从一条通信路线来说，服务器端和客户端的角色是 确定的，而用 HTTP 协议能够明确区分哪端是客户端，哪端是服务器 端。

报文的传送方式由首部字段来决定，不同的首部字段代表不同的含义与功能。

对于前端开发者来说，掌握一些常用的首部字段的含义是很有必要的。

具体headers含义可参考 https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers

http协议无状态的原因： 这是为了 更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设 计成如此简单的。如果让服务器管理全部客户端状态， 服务器则会负担很大压力

但是有时候我们又需要记录用户的状态，这时候就引入了Cookie的技术。

Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。

Cookie 会根据从 服务器 端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出 去。

服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪一 个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前 的状态信息。

HTTP 协议使用 URI 定位互联网上的资源。

HTTP 协议使用 URI 让客户端定位到资源

GET 方法用来请求 访问已被 URI 识别的资源 。

指定的资源经服务器 端解析后返回响应内容。

POST 方法用来传输实体的主体

虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进行 传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。

获得报文首部，用于确认 URI 的有效性及资源更新的日期时间等。

用来查询针对请求 URI 指定的资源支持的方法

PUT 方法用来传输文件。

要求在请 求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置

但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以 上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。

用来删除文件。

但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用 程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。

通过请求头中的Max-Forwards填入数值，每经过一个服务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最后接收到请求的服务器端则返回状态码 200 OK 的响应。

客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改 / 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理 中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。

TRACE方法容易引发 XST（Cross-Site Tracing，跨站追踪）攻击，通常不会用到。

CONNECT 方法的格式

CONNECT 代理服务器名:端口号 HTTP版本

以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使 这样也没有多大问题。可随着 HTTP 的普及，文档中包含大量图片的 情况多了起来。 比如，使用浏览器浏览一个包含多张图片的 HTML页面时，在发送 请求访问 HTML页面资源的同时，也会请求该 HTML页面里包含的 其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断 开，增加通信量的开销。

（ 网络的发展， 从容量小的文本传输->包含大量图片的HTML页面，图片的请求、资源的请求都会导致TCP的连接建立和断开，增加通信的开销 ）

注意，Connection: Keep-Alive首部只是请求将连接保持在活跃状态。即使服务器和客户端都同意建立持久连接了，它们仍可以在任意时刻关闭空闲的keep-alive连接，且可随意限制keep-alive连接所处理事务的数量。我们可以通过Keep-Alive选项调节它们的行为:

用法 ：Keep-Alive: name[=value][, name=[value]]...

完全可选，但 只有在包含了Connection: Keep-Alive首部的情况下才可使用它 。

参数timeout ：在Keep-Alive响应首部中发送，告诉客户端服务器估计会在打开状态保持到连接空闲多长时间后关闭连接。

参数max ：在Keep-Alive响应首部中发送，告诉客户端服务器还会为另外几个http事务将连接保持在打开状态。

注意，这两个参数值仅仅是估计，并非承诺。

说明服务器最多还会为另外5个事务保持连接在打开状态，或者将打开状态保持到连接空闲了2两分钟后关闭。

HTTP/1.1逐渐停止了对keep-alive连接的支持，用persistent连接替代了它。

一个web页面中内嵌的图片通常都来自同一个Web站点，而且相当一部分的超链接都指向同一个站点。如果初始化了一个持久连接，我们就可以通过此连接发起更多目标服务器相同的请求。

HTTP/1.1的新特性，允许在持久连接上可选地使用请求管道。在响应到达之前，可以将多条请求放入队列。当第一条请求通过网络流向服务器时，第二条和第三条请求也可以开始发送了。在髙时延网络条件下，这样做可以降低网络的环回时间，提高性能。

管道化连接有如下几条限制：

参考资料：

HTTP协议一般指超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force ）共同合作研究，最终发布了一系列的RFC，其中著名的RFC 2616定义了HTTP 1.1。HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）叫用户代理（user agent）。应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在http和多个中间层，比如代理，网关，或者隧道（tunnels）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。 事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器（向客户端）发回一个状态行，比如"HTTP/1.1 200 OK"，和（响应的）消息，消息的消息体可能是请求的文件、错误消息、或者其它一些信息。HTTP使用TCP而不是UDP的原因在于（打开）一个网页必须传送很多数据，而TCP协议提供传输控制，按顺序组织数据，和错误纠正。通过HTTP或者HTTPS协议请求的资源由统一资源标示符（Uniform Resource Identifiers）（或者，更准确一些，URLs）来标识。HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。HTTP是客户端浏览器或其他程序与Web服务器之间的应用层通信协议。在Internet上的Web服务器上存放的都是超文本信息，客户机需要通过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。我们在浏览器的地址栏里输入的网站地址叫做URL (Uniform Resource Locator，统一资源定位符)。就像每家每户都有一个门牌地址一样，每个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级链接时，URL就确定了要浏览的地址。浏览器通过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。

---