简单的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 值后发送出去。