《图解HTTP协议》第二章个人学习

简单的HTTP协议
2.1 HTTP协议用于客户端和服务器之间的通信
2.2 通过请求和响应的交换达成通信
2.3 HTTP是不保存状态的协议
2.4 请求URI定位资源
2.5 告知服务器意图的HTTP方法
2.6 使用方法下达命令
2.7 持久连接节省通信量
2.8 使用Cookie进行状态管理

---

心得：
HTTP协议是TCP/IP协议簇里的一个协议，是应用层的协议，用户客服端和服务器端的通信。那如何进行通信???
如果是人和人通信，线下就见个面打个招呼唠两句，线上那就发消息呗。
客户端和服务器就是在线上交流，用的”消息“叫做报文。说需求的一方的报文叫做请求报文，请求报文是由请求方法、请求 URI、协议版本、可选的请求首部字段和内容实体构成的。回应需求的一方的报文是响应报文，响应报文由版本协议、状态码（标识成功或失败的数字代段）、用以解释状态码的原因语句，可选的响应首部字段以及实体主体构成。


提需求，五花八门需求对应的不同在请求报文里的方法，get获取资源、post传输实体主体、 put传输文件、head获得报文首部、 delete删除文件、 options询问支持的方法等传达信息从而更好地得到有针对性地响应。


事务总会不断发展，遇到问题，然后解决问题。本章就讲了HTTP发展过程里地两个问题并简单概要讲述如何解决这两个问题地方法。
问题一：HTTP协议的初始版本里，每进行一次HTTP通信就要断开一次TCP连接。同一个网站了访问好多好多次资源，那就给连接好多好多次，每一次请求都重新建立连还给得到响应，资源极大浪费怎么解决？ 持久连接和管道化。
问题二：HTTP 协议自身不对请求和响应之间的通信状态进行保存。因此会使得在需要进行和用户判断身份等操作时候遇到困难，为解决这个问题就有Cookie出现。本章就对Cookie在客户端和服务器端的过程进行概述。

在学习java SE程序的时候，有Java Servlet，然后老看到Servlet Cookie 处理，有这么一句话，java servlet支持http cookie。但是看了也不知是啥，也没去查查。《图解HTTP》算是给我解惑.。HTTP是一个不保存状态的协议，

2.1 HTTP协议用于客户端和服务器之间的通信

HTTP 协议和 TCP/IP 协议族内的其他众多的协议相同，用于客户端和服务器之间的通信。请求访问文本或图像等资源的一端称为客户端，而提供资源响应的一端称为服务器端。

2.2 通过请求和响应的交换达成通信

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

例子1请求报文：
GET /index.htm HTTP/1.1
Host: hackr.jp
Get表示请求访问服务器的类型，称为方法。
index.htm指明访问的资源对象，也称为请求URI(request-URI)
HTTP/1.1表示HTTP的版本号

响应报文由版本协议、状态码（标识成功或失败的数字代段）、用以解释状态码的原因语句，可选的响应首部字段以及实体主体构成。

例子2
请求报文

响应报文

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

2.3 HTTP是不具有保存状态的协议

HTTP 是一种不保存状态，即无状态（stateless）协议。HTTP 协议自身不对请求和响应之间的通信状态进行保存。在HTTP协议里，每当有新的请求发送时，就会有对应的新响应产生。也就是说在 HTTP 协议对于发送过的请求或响应都不做持久化处理。为了实现更快处理大量事务，确保协议的可伸缩性。

在面向用户的网站里用户切换一个子页面难道要重新登入一次信息

用户登录到一家购物网站，即使他跳转到该站的其他页面后，也需要能继续保持登录状态。针对这个实例，网站为了能够掌握是谁送出的请求，需要保存用户的状态。HTTP/1.1 虽然是无状态协议，但为了实现期望的保持状态功能，于是引入了 Cookie 技术。

2.4 请求URI定位资源

HTTP协议使用URI定位网上资源，实现资源对用户的可访问。

当客户端请求访问资源而发送请求时，URI 需要将作为请求报文中的 请求 URI 包含在内。指定请求 URI 的方式有很多。

2.5 告知服务器意图的HTTP方法

get获取资源
post传输实体主体
put传输文件
head获得报文首部
delete删除文件
options询问支持的方法
trace方法追踪路径
connect方法要求隧道协议链接代理

1. GET 获取资源
   get方法用来请求访问已被URI识别的资源。指定的资源经服务器端解析后返回响应内容。
   

2. POST ** 传输实体主体 **
   POST方法用来传输实体的主体（GET方法也可传输实体的主体，但是一般用POST方法）POST 的主要目的并不是获取响应的主体内容，而是传输实体的主体。
   

3. PUT 传输文件
   PUT方法要求在请求的报文主体里包含文件的内容，然后保存到请求URI指定的位置。**但是，鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以上传文件 , 存在安全性问题，**因此一般的 Web 网站不使用该方法。若配合 Web 应用程序的验证机制，或架构设计采用REST（REpresentational State Transfer，表征状态转移）标准的同类Web 网站，就可能会开放使用 PUT 方法
   

4. HEAD 获得报文首部
   HEAD 方法和 GET 方法一样是一种获得资源的方法，只是不返回报文主体部分。用于获取报文首部里如URI 的有效性及资源更新的日期时间等信息以便于后续确认等操作。
   

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

6. OPYIONS询问支持的方法
   OPTIONS 方法用来查询针对请求 URI 指定的资源支持的方法，比如GET, POST, HEAD, OPTIONS。
   

7. TRACE追踪路径
   TRACE 方法是让 Web 服务器端将之前的请求通信环回给客户端的方法。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器端就将该数字减 1，当数值刚好减到 0 时，就停止继续传输，最后接收到请求的服务器端返回状态码 200 OK 的响应。客户端通过 TRACE 方法可以查询发送出去的请求是怎样被加工修改/ 篡改的。这是因为，请求想要连接到源目标服务器可能会通过代理中转，TRACE 方法就是用来确认连接过程中发生的一系列操作。 但是，TRACE 方法本来就不怎么常用，再加上它容易引发XST（Cross-Site Tracing，跨站追踪）攻击，通常就更不会用到了。
   

请求
TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2
响应
HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 1024

TRACE / HTTP/1.1
Host: hackr.jp
Max-Forwards: 2（返回响应包含请求内容）

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

2.6 使用方法下达命令

向请求URI指定的资源发送请求报文时，采用称为方法的命令。
方法的作用在于，可以指定请求的资源按期望产生某种行为。方法中有 GET、POST 和 HEAD 等。

2.7 持久连接节省通信量

HTTP协议的初始版本里，每进行一次HTTP通信就要断开一次TCP连接。（因为当时传输的是容量很小的文本）

问题：用浏览器浏览一个包含多张图片的HTML页面，请求访问页面里某资源，也会请求该资源包含的的其他资源。每一次请求都重新建立连接造成资源浪费。

2.7.1 持久连接——实现持久化的方法1
HTTP/1.1 和一部分的 HTTP/1.0 想出了持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或HTTP connection reuse）的方法。持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
在 HTTP/1.1 中，所有的连接默认都是持久连接，但在 HTTP/1.0 内并未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接，但服务器端不一定能够支持持久连接。毫无疑问，除了服务器端，客户端也需要支持持久连接。

持久连接优点：
减少TCP连接重复建立和断开所造成的额外开销，减轻服务器端的负载。
减少服务器端的运行时间使得HTTP请求和响应更快，web页面显示速度提高。

2.7.2 管线化——实现持久化的方法2
持久连接使得多数请求以管线化（piplining）的方式发送称为可能。

从前端发送请求到后端需要等待并收到响应，进而才可以发送下一个请求。管线化i技术使得不用收到等待响应也可以直接发送下一个请求，即管线技术使得可以并行发送多个请求。

管线化技术则比持久连接还要快。请求数越多，时间差就越明显。

2.8 Cookie的状态管理

HTTP 是无状态协议，它不对之前发生过的请求和响应的状态进行管理。
假设要求登录认证的 Web 页面本身无法进行状态的管理（不记录已登录的状态），那么每次跳转新页面不是要再次登录，就是要在每次请求报文中附加参数来管理登录状态。

如何管理客户端的状态？？？
Cookie在请求报文和响应报文里写入Cookie信息来控制客户端的状态。

1. 服务器端发送响应报文内包含一个Set-Coolie首部字段信息，通知客户端保存Cookie
2. 客户端再次往服务器发送请求时，客户端会自动在请求报文里加入Cookie值后再发送
3. 客户端向服务器端发送请求
4. 服务器端发现客户端发送的请求里的Cookie后，检查是哪一个客户端发送的连接请求，对比服务器上记录，最后得到状态信息。