简单的http 协议

• 简单实例：

• 客户端发送给服务器端的报文内容
• 起始行开头的GET表示请求访问服务器的类型，称为方法（method）。
• 随后的字符串 /index.htm 指明了请求访问的资源对象，也叫做请求 URI（request-URI）。
• 最后的 HTTP/1.1，即 HTTP 的版本号，用来提示客户端使用的 HTTP 协议功能。

请求报文是由请求方法、请求 URI、协议版本、可选的请求首部字段和内容实体构成的。

• 响应
• 在起始行开头的 HTTP/1.1 表示服务器对应的 HTTP 版本。
• 紧挨着的 200 OK 表示请求的处理结果的状态码（status code）和原因短语（reason-phrase）。
• 下一行显示了创建响应的日期时间，是首部字段（header field）内的一个属性。
• 接着以一空行分隔，之后的内容称为资源实体的主体（entity body）。

响应报文基本上由协议版本、状态码（表示请求成功或失败的数字代码）、用以解释状态码的原因短语、可选的响应首部字段以及实体主
体构成。

HTTP 是一种不保存状态，即无状态（stateless）协议。

• HTTP 协议自身不对请求和响应之间的通信状态进行保存。
• 也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不做持久化处理。
• 这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把 HTTP 协议设计成如此简单的。

HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了 Cookie 技术。

• 有了 Cookie 再用 HTTP 协议通信，就可以管理状态了。

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

• 正是因为 URI 的特定功能，在互联网上任意位置的资源都能访问到。

• 如果不是访问特定资源而是对服务器本身发起请求，可以用一个 * 来代替请求 URI。
• 下面这个例子是查询 HTTP 服务器端支持的 HTTP 方法种类。

告知服务器意图的 HTTP 方法

• GET ：获取资源
  • 指定的资源经服务器端解析后返回响应内容。
  • 如果请求的资源是文本，那就保持原样返回；
  • 如果是像 CGI（Common Gateway Interface，通用网关接口）那样的程序，则返回经过执行后的输出结果。

POST：传输实体主体

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

PUT：传输文件

• 鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。
• 当配合 Web 应用程序的验证机制，或遵守 REST 标准时还是有可能会开放使用的。

HEAD：获得报文首部

• HEAD 方法和 GET 方法一样，只是不返回报文主体部分。
• 用于确认URI 的有效性及资源更新的日期时间等。

DELETE：删除文件

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

OPTIONS：询问支持的方法

TRACE：追踪路径

• TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。
• 客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改/ 篡改的。
  • 这是因为，请求想要连接到源目标服务器可能会通过代理中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。
• TRACE 方法本来就不怎么常用，再加上它容易引发XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。

CONNECT：要求用隧道协议连接代理

• CONNECT 方法要求在与代理服务器通信时建立隧道，实现用隧道协议进行 TCP 通信。
• 主要使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加 密后经网络隧道传输。

• 向请求 URI 指定的资源发送请求报文时，采用称为方法的命令。

持久连接节省通信量

• 三次握手建立连接，四次握手断开

为解决上述 TCP 连接的问题，

• HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或HTTP connection reuse）的方法。
• 持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
• 持久连接旨在建立 1 次 TCP 连接后进行多次请求和响应的交互

• 在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并未标准化。
• 除了服务器端，客户端也需要支持持久连接。

持久连接使得多数请求以管线化（pipelining）方式发送成为可能。

• 从前发送请求后需等待并收到响应，才能发送下一个请求。
• 管线化技术出现后，不用等待响应亦可直接发送下一个请求。

• 与挨个连接相比，用持久连接可以让请求更快结束。
• 而管线化技术则比持久连接还要快。请求数越多，时间差就越明显。

使用 Cookie 的状态管理

• 保留无状态协议这个特征的同时又要解决类似的矛盾问题，于是引入了 Cookie 技术。
• Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的首部字段信息，通知客户端保存 Cookie。
• 当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。