http详解（1.X）

我不是女神ヾ 2023-07-13 15:19 14阅读 0赞

## 前言 ##

**HTTP/0.9**  
HTTP 于 1990 年问世。那时的 HTTP 并没有作为正式的标准被建立。 现在的 HTTP 其实含有 HTTP1.0 之前版本的意思，因此被称为 HTTP/0.9。  
**HTTP/1.0**  
HTTP 正式作为标准被公布是在 1996 年的 5 月，版本被命名为 HTTP/1.0，并记载于 RFC1945。虽说是初期标准，但该协议标准至今 仍被广泛使用在服务器端。

*  RFC1945 - Hypertext Transfer Protocol – HTTP/1.0

[http://www.ietf.org/rfc/rfc1945.txt HTTP/1.1][http_www.ietf.org_rfc_rfc1945.txt HTTP_1.1]  
**HTTP/1.1**  
1997 年 1 月公布的 HTTP/1.1 是目前主流的 HTTP 协议版本。当初的 标准是 RFC2068，之后发布的修订版 RFC2616 就是当前的最新版 本。  
RFC2616 - Hypertext Transfer Protocol – HTTP/1.1 http://www.ietf.org/rfc/rfc2616.txt 可见，作为 Web 文档传输协议的 HTTP，它的版本几乎没有更新。新 一代 HTTP/2.0 也已经定制完毕，但要达到较高的使用覆盖率，仍需假以 时日。  
当年 HTTP 协议的出现主要是为了解决文本传输的难题。由于协议本 身非常简单，于是在此基础上设想了很多应用方法并投入了实际使 用。现在 HTTP 协议已经超出了 Web 这个框架的局限，被运用到了 各种场景里。

## 1. 网络基础 TCP/IP ##

通常使用的网络（包括互联网）是在 TCP/IP 协议族的基础上运作 的。而 HTTP 属于它内部的一个子集  
**注：不同的硬件、操作系统之 间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为 协议（protocol）。**  
常见协议如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70]  
**TCP/ IP 是在 IP 协议的通信过程中，使用到的协议族的统称。**

### 1.1 TCP/IP 的分层管理 ###

TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分别分 为以下 4 层：**应用层、传输层、网络层和数据链路层**

**- 应用层**  
TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP（File Transfer Protocol，文件传输协议）和 DNS（Domain Name System，域 名系统）服务就是其中两类。HTTP 协议也处于该层  
**- 传输层**  
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据 传输。在传输层有两个性质不同的协议：TCP（Transmission Control Protocol，传输控制协议）和 UDP（User Data Protocol，用户数据报 协议）。  
**- 网络层（又名网络互连层）**  
网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数 据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计 算机，并把数据包传送给对方。  
与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所 起的作用就是在众多的选项内选择一条传输路线

**- 链路层（又名数据链路层，网络接口层）**  
用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱 动、NIC（Network Interface Card，网络适配器，即网卡），及光纤等 物理可见部分（还包括连接器等一切传输媒介）。硬件上的范畴均在 链路层的作用范围之内

### 1.2 TCP/IP 通信传输流![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 1] ###

利用 TCP/IP 协议族进行网络通信时，会通过分层顺序与对方进行通 信。发送端从应用层往下走，接收端则往应用层往上走。  
我们用 HTTP 举例来说明，首先作为发送端的客户端在应用层 （HTTP 协议）发出一个想看某个 Web 页面的 HTTP 请求。 接着，为了传输方便，在传输层（TCP 协议）把从应用层处收到的数 据（HTTP 请求报文）进行分割，并在各个报文上打上标记序号及端 口号后转发给网络层。  
在网络层（IP 协议），增加作为通信目的地的 MAC 地址后转发给链 路层。这样一来，发往网络的通信请求就准备齐全了。  
接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用 层。当传输到应用层，才能算真正接收到由客户端发送过来的 HTTP 请求  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 2]  
发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该 层所属的首部信息。反之，接收端在层与层传输数据时，每经过一层 时会把对应的首部消去。  
这种把数据信息包装起来的做法称为封装（encapsulate）  
**报文结构如下：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 3]

## 2.0 http ##

粗略画了张导图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 4]

### 2.1 http请求报文 ###

一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成。  
大致如下：

＜request-line＞ //请求行
    
    ＜headers＞ //首部行
    
    ＜blank line＞ //空行
    
    ＜request-body＞ //请求体

请求实例对照：

POST /user HTTP/1.1     //请求行
    Host: www.jsasj.com     //请求头start，此处是域名（主机地址）
    Content-Type: application/x-www-form-urlencoded //数据类型
    Connection: Keep-Alive         //持久化连接
    User-agent: Mozilla/5.0.      //请求头end，此处是浏览器类型
    空行                    //空行分割header和请求内容 
    name=world   请求体

### 2.2 请求方法 ###

**1） GET**  
GET 方法用来请求访问已被 URI 识别的资源。指定的资源经服务器 端解析后返回响应内容。也就是说，如果请求的资源是文本，那就保 持原样返回，如果是像 CGI（CommonGateway Interface，通用网关接 口）那样的程序，则返回经过执行后的输出结果。  
传递参数长度受限制，因为传递的参数是直接表示在地址栏中，而特定浏览器和服务器对url的长度是有限制的。

因此，GET不适合用来传递私密数据，也不适合拿来传递大量数据。

一般的HTTP请求大多都是GET。  
例如这个get请求：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 5]  
**2）POST**

POST把传递的数据封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据，对数据量没有限制，也不会显示在URL中。

表单的提交用的是POST。  
post请求如下：  
![在这里插入图片描述][20200313121530908.png]  
**3）HEAD**

HEAD跟GET相似，不过服务端接收到HEAD请求时只返回响应头，不发送响应内容。所以，用于确认 URI 的有效性及资源更新的日期时间等。如果只需要查看某个页面的状态时，用HEAD更高效，因为省去了传输页面内容的时间。  
head请求如下：  
![在这里插入图片描述][20200313121858201.png]  
**4）DELETE**

DELETE 方法用来删除文件，是与 PUT 相反的方法。DELETE 方法按 请求 URI 删除指定的资源。  
delete请求如下：  
![在这里插入图片描述][20200313121952571.png]  
**5）OPTIONS**

用于获取当前URL所支持的方法。若请求成功，会在HTTP头中包含一个名为“Allow”的头，值是所支持的方法，如“GET, POST”。  
options请求如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 6]  
**6）PUT**

把一个资源存放在指定的位置上。

本质上来讲， PUT和POST极为相似，都是向服务器发送数据，但它们之间有一个重要区别，PUT通常指定了资源的存放位置，而POST则没有，POST的数据存放位置由服务器自己决定。  
鉴于 HTTP/1.1 的 PUT 方法自身不带验证机制，任何人都可以 上传文件 , 存在安全性问题，因此一般的 Web 网站不使用该方法。若 配合 Web 应用程序的验证机制，或架构设计采用 REST（REpresentational State Transfer，表征状态转移）标准的同类 Web 网站，就可能会开放使用 PUT 方法。  
put请求如下：![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 7]  
**7）TRACE**

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

**8）CONNECT**

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

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 9]  
connect请求如下：  
![在这里插入图片描述][20200313122545263.png]

### 2.3 请求头部 ###

请求头部由关键字/值对组成，每行一对

*  User-Agent : 产生请求的浏览器类型
 *  Accept : 客户端希望接受的数据类型，比如  
    Accept：text/xml（application/json）表示希望接受到的是xml（json）类型
 *  Content-Type：发送端发送的实体数据的数据类型。  
    比如，Content-Type：text/html（application/json）表示发送的是html类型。
 *  Host : 请求的主机名，允许多个域名同处一个IP地址，即虚拟主机

#### 2.3.1 Content-Type ####

常见的Content-Type：

<table> 
 <thead> 
  <tr> 
   <th>Content-Type</th> 
   <th>解释</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>text/html</td> 
   <td>html格式</td> 
  </tr> 
  <tr> 
   <td>text/plain</td> 
   <td>纯文本格式</td> 
  </tr> 
  <tr> 
   <td>text/css</td> 
   <td>CSS格式</td> 
  </tr> 
  <tr> 
   <td>text/javascript</td> 
   <td>js格式</td> 
  </tr> 
  <tr> 
   <td>image/gif</td> 
   <td>gif图片格式</td> 
  </tr> 
  <tr> 
   <td>image/jpeg</td> 
   <td>jpg图片格式</td> 
  </tr> 
  <tr> 
   <td>image/png</td> 
   <td>png图片格式</td> 
  </tr> 
  <tr> 
   <td>application/x-www-form-urlencoded</td> 
   <td>POST专用：普通的表单提交默认是通过这种方式。form表单数据被编码为key/value格式发送到服务器。</td> 
  </tr> 
  <tr> 
   <td>application/json</td> 
   <td>POST专用：用来告诉服务端消息主体是序列化后的</td> 
  </tr> 
  <tr> 
   <td>text/xml</td> 
   <td>POST专用：发送xml数据</td> 
  </tr> 
  <tr> 
   <td>multipart/form-data</td> 
   <td>POST专用</td> 
  </tr> 
 </tbody> 
</table>

这了讲解一下multipart/form-data：  
用以支持向服务器发送二进制数据，以便可以在 POST 请求中实现文件上传等功能

现在用Postman向百度发送一个请求方式为multipart/form-data的POST包，请求报文是这样的：

POST / HTTP/1.1
    Host: www.baidu.com
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
    Cache-Control: no-cache
    Postman-Token: 033120fe-2185-15d4-e486-75e86e2baddd
    
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="url"
    
    https://www.baidu.com/
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="name"
    
    waffle
    ------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="desk"; filename="桌子.jpg"
    Content-Type: image/jpeg
    
    ...contents of 桌子.jpg...
    ------WebKitFormBoundary7MA4YWxkTrZu0gW--

其中， boundary这个参数是分界线的意思，这个分界线参数具体是什么你可以随意自定义 ，建议定义复杂一点，因为这样子才不会跟请求体中其它字段重复。

上面的例子看出分界线=“–”+boundary

每个参数都由分界线分隔开，参数名（二进制数据还需要指明文件类型）和参数值之间有一行空行，这个空行不能省略:

------WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name="url"
    
    https://www.baidu.com/

#### 2.3.2 空行 ####

请求头之后是一个空行，通知服务器以下不再有请求头

#### 2.3.3 请求体 ####

GET没有请求数据，POST有。

与请求数据相关的最常使用的请求头是 Content-Type 和 Content-Length 。

### 2.4 响应报文 ###

＜status-line＞   //状态行
    
    ＜headers＞   //消息报头
    
    ＜blank line＞   //空行
    
    ＜response-body＞    //响应体

#### 2.4.1 状态行 ####

状态行也由三部分组成：服务器HTTP协议版本，响应状态码，状态码的文本描述

格式：HTTP-Version Status-Code Reason-Phrase CRLF

比如：HTTP/1.1 200 OK  
状态码：由3位数字组成，第一个数字定义了响应的类别

*  1xx：指示信息，表示请求已接收，继续处理
 *  2xx：成功，表示请求已被成功接受，处理。
 *  200 OK：客户端请求成功

204 No Content：无内容。服务器成功处理，但未返回内容。一般用在只是客户端向服务器发送信息，而服务器不用向客户端返回什么信息的情况。不会刷新页面。  
206 Partial Content：服务器已经完成了部分GET请求（客户端进行了范围请求）。响应报文中包含Content-Range指定范围的实体内容

*  3xx：重定向

301 Moved Permanently：永久重定向，表示请求的资源已经永久的搬到了其他位置。

302 Found：临时重定向，表示请求的资源临时搬到了其他位置

303 See Other：临时重定向，应使用GET定向获取请求资源。303功能与302一样，区别只是303明确客户端应该使用GET访问

307 Temporary Redirect：临时重定向，和302有着相同含义。POST不会变成GET

304 Not Modified：表示客户端发送附带条件的请求（GET方法请求报文中的IF…）时，条件不满足。返回304时，不包含任何响应主体。虽然304被划分在3XX，但和重定向一毛钱关系都没有  
一个304的使用场景：  
缓存服务器向服务器请求某一个资源的时候，服务器返回的响应报文具有这样的字段：Last-Modified:Wed,7 Sep 2011 09:23:24，缓存器会保存这个资源的同时，保存它的最后修改时间。下次用户向缓存器请求这个资源的时候，缓存器需要确定这个资源是新的，那么它会向原始服务器发送一个HTTP请求（GET方法），并在请求头部中包含了一个字段：If-Modified-Since:Wed,7 Sep 2011 09:23:24，这个值就是上次服务器发送的响应报文中的最后修改时间。

假设这个资源没有被修改，那么服务器返回一个响应报文：

HTTP/1.1 304 Not Modified
        Date：Sat, 15 Oct 2011 15:39:29
        (空行)                                      
        (空响应体)

用304告诉缓存器资源没有被修改，并且响应体是空的，不会浪费带宽

*  4xx：客户端错误

400 Bad Request：客户端请求有语法错误，服务器无法理解。  
401 Unauthorized：请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用。  
403 Forbidden：服务器收到请求，但是拒绝提供服务  
404 Not Found：请求资源不存在。比如，输入了错误的url  
415 Unsupported media type：不支持的媒体类型

*  5xx：服务器端错误，服务器未能实现合法的请求。

500 Internal Server Error：服务器发生不可预期的错误。  
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常，

[http_www.ietf.org_rfc_rfc1945.txt HTTP_1.1]: http://www.ietf.org/rfc/rfc1945.txt%20HTTP/1.1
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70]: /images/20230529/673aa7f41d164746aee30f7fad58a166.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 1]: /images/20230529/ef50475afd3b4135b12ca9fafaa72ec9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 2]: /images/20230529/988c915343304baf9f1f330af59250ad.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 3]: /images/20230529/1f1ff27e772e46f2b640b730ea7483a5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 4]: /images/20230529/df4d2aa0760243099db786fb0f1a9e90.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 5]: /images/20230529/c63225652f694e6b85f39c3915d59b8e.png
[20200313121530908.png]: /images/20230529/4381639989b64e40af88166f3e4e6c4e.png
[20200313121858201.png]: /images/20230529/318c3276e2564970825e3759e4927f45.png
[20200313121952571.png]: /images/20230529/0ef399b59b9d4928a2bc22dcbd78123a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 6]: /images/20230529/ac265ef98fae47bbac4ef442fab25aa7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 7]: /images/20230529/015213abc99e4a12978febc37e260ec4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 8]: /images/20230529/cc4222083c644abfb073e8a4ce4d47ed.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTIxNzU0MQ_size_16_color_FFFFFF_t_70 9]: /images/20230529/4ebf06a072584a1cb542a270e2b0602e.png
[20200313122545263.png]: /images/20230529/7881ae8fe3e34a20a28e7c0a8f479e3c.png