第二章 简单的HTTP协议

第二章 简单的HTTP协议

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

1. 在两台计算机之间使用HTTP协议通信时，在一条通信线路上必定有一端是客户端，另一端则是服务器端。
2. 有时，按实际情况，两台计算机作为客户端和服务器端的角色有可能会互换，但是HTTP协议能够明确区分哪端是客户端，哪端是服务器端。

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

1. HTTP协议规定，请求从客户端发出，最后服务器端响应该请求并返回。

2. 客户端发送给某个HTTP服务器端的请求报文中的内容。

   GET /index.htm HTTP/1.1
   Host: hackr.jp
   

   • GET：表示请求访问服务器的类型，称为方法（method）。
   • /index.htm：指明了请求访问的资源对象，也叫做请求URI（request-URI）。
   • HTTP/1.1：提示客户端使用的HTTP协议版本。

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

   

4. 服务器将请求内容的处理结果以响应的形式返回。

   HTTP/1.1 200 ok
   Date: Tue, 10 Jul 2020 21:55:15 GMT
   Content-Length: 362
   Content-Type: text/html
   

5. 响应报文基本上由协议版本，状态码，用以解释状态码的原因短语，可选的响应首部字段以及实体主体构成。

   

2.3 HTTP是不保存状态的协议

1. HTTP是一种不保存状态，即无状态（stateless）协议。
2. 协议自身不对请求和响应之间的通信状态进行保存。
3. 协议对于发送过的请求或响应都不做持久化处理。
4. 每当有新的请求发送时，就会有对应的新响应产生，协议本身并不保留之前一切的请求或响应报文信息。（确保协议的可伸缩型）
5. 无状态存在的问题
   1. 如：用户登录到一个网站，即使他跳转到该站的其他页面后，也需要能继续保持登录状态。
6. 解决方案
   1. cookie

2.4 请求URI定位资源

1. HTTP协议使用URI定位互联网上的资源。正是因为URI的特定功能，在互联网上任意位置的资源都能访问到。

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

   

3. 此外，如果不是访问特定资源而是对服务器本身发起请求，可以使用一个 * 来代替请求URI。

   1. 如查询HTTP服务器端支持的HTTP方法种类。

      OPTIONS * HTTP/1.1
      

2.5 告知服务器意图的HTTP方法(基于HTTP/1.1)

GET：获取资源

1. GET方法用来请求访问已被URI识别的资源。
2. 如果请求的资源是文本，就保持原样返回。
3. 如果是像CGI（Common Gateway Interface，通用网关接口），则返回经过执行后的输出结果。

使用GET方法的请求，响应示例

请求	响应
GET /index.html HTTP/1.1 Host: www.hackr.jp	返回index.html的页面资源

请求	响应
GET /index.html HTTP/1.1 Host: www.hackr.jp If-Modified-Sine: Tue, 12 Jul 2012 07:30:00 GMT	仅返回2012年7月12日7点30分以后更新过的index.html页面资源。 如果未有内容更新，则以状态码304 Not Modified作为响应结果。

POST：传输实体主体

1. POST方法用来传输实体的主体

使用POST方法的请求，响应示例

请求	响应
POST /submit.cgi HTTP/1.1 Host: www.hackr.jp Content-Length: 1560(1560字节的数据)	返回submit.cgi接收数据的处理结果。

PUT：传输文件

1. PUT方法用来传输文件。要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。
2. 鉴于HTTP/1.1的PUT方法自身不带验证机制，存在安全问题，不推荐。
3. 建议配合Web应用程序的验证机制，或架构设计采用REST（Representational State Transfer，表征状态转移）标准的同类Web网站。

使用PUT方法的请求，响应示例

请求	响应
PUT /example.html HTTP/1.1 Host: www.hackr.jp Content-Type: text/html Content-Length: 1560(1560字节的数据)	响应返回状态码204 No Content （比如：该html已存在于服务器上）

HEAD：获得报文首部

1. 用于确认URI的有效性及资源更新的日期时间等。

使用HEAD方法的请求，响应示例

请求	响应
HEAD /index.html HTTP/1.1 Host: www.hackr.jp	返回index.html有关的响应首部

DELETE：删除文件

1. DELETE方法按请求URI删除指定的资源。
2. HTTP/1.1的DELETE方法本身和PUT方法一样不带验证机制，存在安全问题，不推荐。
3. 建议配合Web应用程序的验证机制，或架构设计采用REST（Representational State Transfer，表征状态转移）标准的同类Web网站。

使用DELETE方法的请求，响应示例

请求	响应
DELETE /example.html HTTP/1.1 Host: www.hackr.jp	响应返回状态码204 Not Content (比如：该html已从该服务器上删除)

OPTIONS：询问支持的方法

1. OPTIONS方法用来查询针对请求URI指定的资源支持的方法。

使用OPTIONS方法的请求，响应示例

请求	响应
OPTIONS * HTTP/1.1 Host: www.hackr.jp	HTTP/1.1 200 OK Allow:GET,POST,HEAD,OPTIONS (返回服务器支持的方法)

TRACE：追踪路径

1. TRACE方法是让Web服务器端将之前的请求通信环回给客户端的方法。
2. 发送请求时，在Max-Forwards首部字段中填入数值，每经过一个服务器端就将该数字减1，当数值刚好减到0时，就停止继续传输，最后接收到请求的服务器端则返回状态码200 OK的响应。
3. TRACE方法容易引发XST（Cross-Site Tracing，跨站追踪）攻击，（实际中几乎不用）

使用TRACE方法的请求，响应示例

请求	响应
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（返回响应包含请求内容）

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

1. CONNECT方法用隧道协议进行TCP通信。
2. 主要使用SSL（Secure Sockets Layer，安全套接层）和TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

CONNECT方法的格式

CONNECT 代理服务器名：端口名 HTTP版本

使用CONNECT方法的请求，响应示例

请求	响应
CONNECT proxy.hackr.jp:8080 HTTP/1.1 Host: proxy.hackr.jp	HTTP/1.1 200 OK（之后进入网络隧道）

2.6 使用方法下达命令

1. 向请求URI指定的资源发送请求报文时，采用称为方法的命令。
2. 方法可以指定请求的资源按期望产生某种行为。

HTTP/1.0和HTTP/1.1支持的方法

方法	说明	支持的HTTP协议版本
GET	获取资源	1.0，1.1
POST	传输实体主体	1.0，1.1
PUT	传输文件	1.0，1.1
HEAD	获得报文首部	1.0，1.1
DELETE	删除文件	1.0，1.1
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINE	断开连接关系	1.0

2.7 持久连接节省通信量

1. HTTP早期协议存在的问题：每进行一次HTTP通信就要断开一次TCP连接。
2. 随着网络的发展，网络数据量的增大：每次的请求都会造成无谓的TCP连接建立和断开增加通信量的开销。

2.7.1 持久连接

1. 持久连接（HTTP Persistent Connections，也称为HTTP keep-alive或HTTP connection reuse）的方法。
2. 特点
   1. 只要任意一端没有明确提出断开连接，则保持TCP连接状态。
3. 优势
   1. 减少了TCP连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。
   2. 减少开销的同时也减少了时间，使得HTTP请求和响应能更早地结束，提高了Web页面的显示速度。

2.7.2 管线化

1. 持久连接使得多数请求以管线化（pipelining）方式发送成为可能。
2. 从前发送请求后需等待并收到响应，才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求。
3. 这样就能够做到同时并行发送多个请求，而不需要一个接一个地等待响应了。

2.8 使用Cookie的状态管理

HTTP无状态协议存在的问题

1. 客户端无法根据之前的状态进行本次的请求处理。（要求登录认证的Web页面无法进行状态的管理）

解决方案

1. Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。
2. Cookie会根据从服务器端发送的响应报文内的一个叫Set-Cookie的首部字段信息，通知客户端保存Cookie。
3. 当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。
4. 服务器端发现客户端发送过来的Cookie后，会去检查究竟是从哪个客户端发送过来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。