如果和我一样，对网络毫无概念，并且想去了解HTTP，建议看下HTTP图解这一本书，很不错，包含大量的图画帮助我们理解HTTP，不会那么枯燥，讲的很清晰。非常棒的一本书
本篇笔记大部分使用此书原文和原图，提取了个人觉得比较重要的知识点，供后期自己回顾学习使用
请求报文构成
请求报文是由请求方法、请求 URI、协议版本、可选的请求首部字
段和内容实体构成的。
请求响应,响应报文
HTTP/1.1 200 OK
Date: Tue, 10 Jul 2012 06:50:15 GMT
Content-Length: 362
Content-Type: text/html
<html>
......
在起始行开头的 HTTP/1.1 表示服务器对应的 HTTP 版本。
紧挨着的 200 OK 表示请求的处理结果的状态码(status code)和原 因短语(reason-phrase)。下一行显示了创建响应的日期时间，是首部字 段(header field)内的一个属性。
接着以一空行分隔，之后的内容称为资源实体的主体(entity body)。
响应报文基本上由协议版本、状态码(表示请求成功或失败的数字 代码)、用以解释状态码的原因短语、可选的响应首部字段以及实体主体构成。
HTTP 是不保存状态的协议
HTTP 是一种不保存状态，即无状态(stateless)协议。HTTP 协议 自身不对请求和响应之间的通信状态进行保存。也就是说在 HTTP 这个 级别，协议对于发送过的请求或响应都不做持久化处理。
使用 HTTP 协议，每当有新的请求发送时，就会有对应的新响应产 生。协议本身并不保留之前一切的请求或响应报文的信息。这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成 如此简单的。
随着 Web 的不断发展，因无状态而导致业务处理变得棘手 的情况增多了。比如，用户登录到一家购物网站，即使他跳转到该站的 其他页面后，也需要能继续保持登录状态。针对这个实例，网站为了能 够掌握是谁送出的请求，需要保存用户的状态。
HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能， 于是引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通信，就可以管 理状态了。
告知服务器意图的 HTTP 方法
- GET :获取资源
GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务 器端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保 持原样返回;如果是像 CGI(Common Gateway Interface，通用网关接 口)那样的程序，则返回经过执行后的输出结果。
- POST:传输实体主体
POST 方法用来传输实体的主体。
虽然用 GET 方法也可以传输实体的主体，但一般不用 GET 方法进 行传输，而是用 POST 方法。虽说 POST 的功能与 GET 很相似，但 POST 的主要目的并不是获取响应的主体内容。
- PUT :传输文件
PUT 方法用来传输文件。就像 FTP 协议的文件上传一样，要求在 请求报文的主体中包含文件内容，然后保存到请求 URI 指定的位置。
但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可 以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST(REpresentational State Transfer，表征状态转移)标准的同类 Web 网站，就可能会开放使 用 PUT 方法。
- HEAD:获得报文首部
HEAD 方法和 GET 方法一样，只是不返回报文主体部分。用于确认 URI 的有效性及资源更新的日期时间等。
- DELETE:删除文件
DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方 法按请求 URI 删除指定的资源。
但是，HTTP/1.1 的 DELETE 方法本身和 PUT 方法一样不带验证机 制，所以一般的 Web 网站也不使用 DELETE 方法。当配合 Web 应用程 序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。
- OPTIONS:询问支持的方法
OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法。
- TRACE:追踪路径，TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的 方法，基本不用，容易引发 XST (Cross-Site Tracing，跨站追踪)攻击
- CONNECT:要求用隧道协议连接代理
CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道 协议进行 TCP 通信。主要使用 SSL(Secure Sockets Layer，安全套接 层)和 TLS(Transport Layer Security，传输层安全)协议把通信内容加 密后经网络隧道传输。
CONNECT 方法的格式如下所示。
CONNECT 代理服务器名:端口号 HTTP版本
HTTP/1.0 和 HTTP/1.1 支持的方法
持久连接节省通信量
HTTP 协议的初始版本中，每进行一次 HTTP 通信就要断开一次 TCP 连接。
以早起的通信情况来说，因为都是些容量很小的文本传输，所以即 使这样也没有多大问题。可随着 HTTP 的普及，文档中包含大量图片的 情况多了起来。
比如，使用浏览器浏览一个包含多张图片的 HTML 页面时，在发 送请求访问 HTML 页面资源的同时，也会请求该 HTML 页面里包含的 其他资源。因此，每次的请求都会造成无谓的 TCP 连接建立和断开， 增加通信量的开销。
持久连接
为解决上述 TCP 连接的问题，HTTP/1.1 和一部分的 HTTP/1.0 想出 了持久连接(HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse)的方法。持久连接的特点是，只要任意一端没 有明确提出断开连接，则保持 TCP 连接状态。
持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的 额外开销，减轻了服务器端的负载。另外，减少开销的那部分时间，使 HTTP 请求和响应能够更早地结束，这样 Web 页面的显示速度也就相应 提高了。
在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内 并未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户 端也需要支持持久连接。
管线化
持久连接使得多数请求以管线化(pipelining)方式发送成为可能。 从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术 出现后，不用等待响应亦可直接发送下一个请求。
这样就能够做到同时并行发送多个请求，而不需要一个接一个地等 待响应了。
比如，当请求一个包含 10 张图片的 HTML Web 页面，与挨个连接 相比，用持久连接可以让请求更快结束。而管线化技术则比持久连接还 要快。请求数越多，时间差就越明显。
使用 Cookie 的状态管理
如果让服务器管理全部客户端状态则会成为负担，于是引 入了 Cookie 技术。Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。
Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。
服务器端发现客户端发送过来的 Cookie 后，会去检查究竟是从哪 一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前 的状态信息。
请求报文(没有 Cookie 信息的状态)
GET /reader/ HTTP/1.1
Host: hackr.jp
* 首部字段内没有 Cookie 的相关信息
响应报文(服务器端生成 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
二次请求报文(自动发送保存着的 Cookie 信息)
GET /image/ HTTP/1.1
Host: hackr.jp
Cookie: sid=1342077140226724
