基于 HTTP/1.1 版本讲解 HTTP 协议
概念与作用
- HTTP 协议用于客户端与服务端之间的通信。
- HTTP是一种无状态协议(Stateless)。因此引入了Cookie 技术来完成状态管理。
请求报文与响应报文简介
-
由客户端发起请求，服务端针对该请求做出响应，完成一次通信
-
请求报文由 以下内容构成：
- 请求方法
- 请求URI：用于定位资源
- 协议版本
- 可选的请求首部字段与内容实体(Headers and Body
POST /form/entry HTTP/1.1 Host: hackr.jp Connection: keep-alive Content-Type: application/x-www-form-urlencoded Content-Length: 16 name=ueno&age=37
-
响应报文由以下内容构成
- 协议版本
- 状态码（Status code）
- 用以解释状态码的原因短语（reason-phrase）
- 可选的响应首部字段与实体主体（Headers and body）
HTTP/1.1 200 OK Date: Tue, 10 Jul 2012 06:50:15 GMT Content-Length: 362 Content-Type: text/html * 空行分割 <html> ……
URI
主要功能是用于定位客户端需要请求访问的服务端资源。指定 URI的方式有：
- URI为完整的请求URI
GET http://hackr.jp/index.htm HTTP/1.1
- 在Headers 字段Host 中写明网络域名或IP地址
GET /index.htm HTTP/1.1
Host: hackr.jp
- 对服务器本身发起请求，可以用
*代替请求URI
OPTIONS * HTTP/1.1
HTTP Method
HTTP请求方法的介绍（LINK 和 UNLINK 已被 HTTP/1.1 废弃， 不再支持，所以不列出了）：
| 方法 | 作用 | 支持的HTTP协议版本 |
|---|---|---|
| GET | 请求访问已被URI识别的资源，指定的资源经服务端解析后返回响应内容 | 1.0、1.1 |
| POST | 传输实体主体(Body) | 1.0、1.1 |
| PUT | 用于传输文件。要求在 请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。HTTP/1.1 的 PUT 方法不带验证机制，存在安全问题，因此一般的 Web 网站是用该方法。若配合 Web 应用程序的验证机制，或架构设计采用 REST（Representational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使 用 PUT。 | 1.0、1.1 |
| HEAD | HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。 | 1.0、1.1 |
| DELETE | 用于按请求 URI 删除指定的资源。同PUT不安全，配合REST或Web应用程序的验证机制可使用。 | 1.0、1.1 |
| OPTIONS | 查询针对请求 URI 指定的资源支持的方法。响应时对应Allow中的字段 | 1.1 |
| TRACE | 用于追踪代理中转的路径，容易被攻击，通常不用 | 1.1 |
| CONNECT | 要求在与代理服务器通信时建立隧道，实现用隧道 协议进行 TCP 通信。 主要使用 SSL（Secure Sockets Layer， 安全套接 层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。格式CONNECT 代理服务器名:端口号 HTTP版本
|
1.1 |
持久连接
HTTP 协议的初始版本中， 每进行一次 HTTP 通信就要断开一次 TCP 连接。以当年的通信情况来说，因为都是些容量很小的文本传输，所以即使这样也没有多大问题。可随着 HTTP 的普及，文档中包含大量图片的情况多了起来。每次的请求都会造成无谓的 TCP 连接建立和断开， 增加通信量的开销。
由以上历史原因而诞生了 持久连接（HTTP Persistent Connections， 也称为 HTTP keep-alive 或 HTTP connection reuse）, 特点：
- 只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
- 减少了 TCP 连接的重复建立和断开所造成的 额外开销，减轻了服务器端的负载。提升了Web 页面的显示速度
- 在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内 并未标准化。
管线化（Pipelining）：从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术能够做到同时并行发送多个请求，提升了整体的页面显示速度。
Cookie
- 作用：Cookie 技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。
- 过程：Cookie 会根据从服务器端发送的响应报文内的一个叫做
Set-Cookie的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后， 会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。
示例：
- 首次请求：
GET /reader/ HTTP/1.1
Host: hackr.jp
*首部字段内没有Cookie的相关信息
- 首次响应：
HTTP/1.1 200 OK
Date: Thu, 12 Jul 2012 07:12:20 GMT
Server: Apache
＜Set-Cookie: sid=1342077140226724; path=/; expires=Wed,
10-Oct-12 07:12:20 GMT＞
Content-Type: text/plain; charset=UTF-8
- 以后请求：
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
网友评论