HTTP：HTTP报文是什么样子的

骑猪看日落 2022-08-28 02:53 144阅读 0赞

# 引言 #

*  在[这里][Link 1]，我们在本机的最小化环境里做了两个HTTP协议的实验，使用wireshark抓包，弄清楚了HTTP协议的工作流程，也就是“请求-应答”模式
 *  可以看到，HTTP是由底层的TCP/IP协议负责底层的具体传输工作，单从这一点来看，所谓的“超文本传输协议”其实并不怎么管“传输”的事情，优点名不副实
 *  那么HTTP协议的核心部分是什么呢？
    
     *  HTTP协议在规范文档中详细定义了报文的格式，规定了组成部分、解析规则，还有处理策略
     *  所以可以在TCP/IP层之上实现更灵活丰富的功能，比如连接管理、缓存管理、数据编码、内容协商等等

# 报文结果 #

HTTP协议和TCP/UDP类似，同样也需要在实际传输的数据前加一些头数据，不过跟TCP/UDP不同的是，它是一个“纯文本”的协议，所以头数据都是ASCII码的文本，阅读很方便，不用接祖程序解析也能过看懂

HTTP 协议的请求报文和响应报文的结构基本相同，由三大部分组成：

*  起始行（start line）：描述请求或响应的基本信息；
 *  头部字段集合（header）：使用 key-value 形式更详细地说明报文；
 *  .消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

这其中前两部分起始行和头部字段经常又合称为“请求头”或“响应头” （“header”），消息正文又称为“实体”（“body”）

HTTP 协议规定报文必须有 header，但可以没有 body，而且在 header 之后必须要有一个“空行”，也就是“CRLF”，十六进制的“0D0A”。

所以，一个完整的 HTTP 报文就像是下图的这个样子，注意在 header 和 body 之间有一个“空行”。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16]  
报文里的 header 就是“大头儿子”的“大头”，空行就是他的“脖子”，而后面的 body 部分就是他的身体了。

看一下我们之前用 Wireshark 抓的包吧。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]  
在这个浏览器发出的请求报文里，第一行“GET /HTTP/1.1”就是请求行，而后面的“Host”“Connection”等等都属于 header，报文的最后是一个空白行结束，没有 body。

在很多时候，特别是浏览器发送 GET 请求的时候都是这样，HTTP 报文经常是只有 header 而没 body，相当于只发了一个超级“大头”过来，你可以想象的出来：每时每刻网络上都会有数不清的“大头儿子”在跑来跑去。

不过这个“大头”也不能太大，虽然HTTP协议对header的大小没有做限制，但各个web服务器都不允许过大的请求头，因为头部太大可能会占用大量的服务器资源，影响运行效率。

## 请求行 ##

了解了HTTP报文的基本结构后，我们来看看请求报文里的起始行也就是**请求行(request line)**，它简要的描述了**客户端想要如何操作服务器的资源**

请求行有三部分组成：

*  请求方法：是一个动词，如 GET/POST，表示对资源的操作；
 *  请求目标：通常是一个 URI，标记了请求方法要操作的资源；
 *  版本号：表示报文使用的 HTTP 协议版本。

这三个部分通常使用空格（space）来分隔，最后要用CRLF 换行表示结束。  
![在这里插入图片描述][04b07b95b2fc40f7a2a62e228e713c9d.png]  
还是用 Wireshark 抓包的数据来举例：

GET / HTTP/1.1

在这个请求行里，“GET”是请求方法，“/”是请求目标，“HTTP/1.1”是版本号，把这三部分连起来，意思就是“服务器你好，我想获取网站根目录下的默认文件，我用的协议版本号是 1.1，请不要用 1.0 或者 2.0 回复我。”

## 状态行 ##

看完了请求行，我们再看响应报文里的起始行，在这里它不叫“响应行”，而是叫做“状态行（status line）”，意思是**服务器响应的状态**

比起请求行来说，状态行要简单一些，同样也是由三部分构成：

*  版本号：表示报文使用的 HTTP 协议版本；
 *  状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
 *  原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。  
    ![在这里插入图片描述][cd457c20b6e0428cbe46a6ea4ae32117.png]  
    Wireshark 抓包里的响应报文，状态行是：

HTTP/1.1 200 OK

意思就是：“浏览器你好，我已经处理完了你的请求，这个报文使用的协议版本号是 1.1，状态码是 200，一切OK。”

而另一个“GET /favicon.ico HTTP/1.1”的响应报文状态行是：

HTTP/1.1 404 Not Found

意思就是：“抱歉啊浏览器，刚才你的请求收到了，但我没找到你要的资源，错误代码是 404，接下来的事情你就看着办吧。”

## 头部字段 ##

请求行或状态行 + 头部字段 --> HTTP报文里的完整请求头或者响应头：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16 1]  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16 1]

请求头和响应头的结构是基本一样的，唯一的区别是起始行。 其头部字段是一样的。

*  头部字段是 key-value 的形式，key 和 value 之间用“:”分隔，最后用 CRLF 换行表示字段结束
 *  比如在“Host: 127.0.0.1”这一行里 key 就是“Host”，value就是“127.0.0.1”。

HTTP 头字段非常灵活，不仅可以使用标准里的 Host、Connection 等已有头，也可以任意添加自定义头，这就给HTTP 协议带来了无限的扩展可能。

### 注意 ###

使用头字段需要注意下面几点：

*  字段名不区分大小写，例如“Host”也可以写成“host”，但首字母大写的可读性更好；
 *  字段名里不允许出现空格，可以使用连字符“-”，但不能使用下划线“\_”。例如，“test-name”是合法的字段名，而“test name”“test\_name”是不正确的字段名；
 *  字段名后面必须紧接着“:”，不能有空格，而“:”后的字段值前可以有多个空格；
 *  字段的顺序是没有意义的，可以任意排列不影响语义；
 *  字段原则上不能重复，除非这个字段本身的语义允许，例如 Set-Cookie。

### 分类 ###

HTTP 协议规定了非常多的头部字段，实现各种各样的功能，但基本上可以分为四大类：

*  通用字段：在请求头和响应头里都可以出现；
 *  请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；
 *  响应字段：仅能出现在响应头里，补充说明响应报文的信息；
 *  实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。

对 HTTP 报文的解析和处理实际上主要就是对头字段的处理，理解了头字段也就理解了 HTTP 报文。

### 常用报文 ###

> **host字段**

*  它属于请求字段，只能出现在请求头里，它同时**也是唯一一个 HTTP/1.1 规范里要求必须出现的字段**，也就是说，如果请求头里没有 Host，那这就是一个错误的报文。
 *  Host字段告诉服务器这个请求应该由哪个主机来处理，当一条计算机上托管了多个虚拟主机的时候，服务端就需要用host字段来选择

例如我们的试验环境，在 127.0.0.1 上有三个虚拟主机：“www.chrono.com”“www.metroid.net”和“origin.io”。那么当使用域名的方式访问时，就必须要用 Host字段来区分这三个 IP 相同但域名不同的网站，否则服务器就会找不到合适的虚拟主机，无法处理。

> User-Agent

*  请求字段，只出现在请求头里
 *  它使用一个字符串来描述发起HTTP请求的客户端，服务器可以依据它来返回最合适此浏览器显式的页面

但由于历史的原因，User-Agent 非常混乱，每个浏览器都自称是“Mozilla”“Chrome”“Safari”，企图使用这个字段来互相“伪装”，导致 User-Agent 变得越来越长，最终变得毫无意义。

> Date字段

*  Date字段是一个通用字段，但通常出现在响应头里，表示HTTP 报文创建的时间
 *  客户端可以使用这个时间再搭配其他字段决定缓存策略。

> Server字段

*  Server字段是响应字段，只能出现在响应头里。
 *  它告诉客户端当前正在提供 Web 服务的软件名称和版本号
 *  例如在我们的实验环境里它就是“Server: openresty/1.15.8.1”，即使用的是 OpenResty 1.15.8.1。
 *  Server 字段也不是必须要出现的，因为这会把服务器的一部分信息暴露给外界，如果这个版本恰好存在 bug，那么黑客就有可能利用 bug 攻陷服务器。所以，有的网站响应头里要么没有这个字段，要么就给出一个完全无关的描述信息。
 *  比如 GitHub，它的 Server 字段里就看不出是使用了Apache 还是 Nginx，只是显示为“GitHub.com”。  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_11_color_FFFFFF_t_70_g_se_x_16]

> Content-Length

*  这是一个实体字段，表示报文里body的长度，也就是请求头或者响应头空行后面数据的长度。
 *  服务器看到这个字段，就知道了后续有多少数据，可以直接接收
 *  如果没有这个字段，那么body就是不定长的，需要使用chunked方式分段传输。

# 实践 #

## 操作 ##

*  先启动OpenResty服务器，然后用组合键“Win+R”运行telnet，输入命令`open www.chrono.com 80`，连上web服务器  
    ![在这里插入图片描述][7a065584154e480a8569c0d171eb36fd.png]  
    ![在这里插入图片描述][30fe4663dc9d4daf8eff6d10fa5de5ba.png]
 *  连接上之后按组合键`CTRL+]`，然后按回车键，就进入了编辑模式。在这里，你可以直接用鼠标右键黏贴文本，敲两下回车后就会发送数据，也就是模拟了一次HTTP请求  
    ![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]

下面是两个最简单的 HTTP 请求，第一个在“:”后有多个空格，第二个在“:”前有空格。

GET /09-1 HTTP/1.1
    Host: www.chrono.com
    GET /09-1 HTTP/1.1
    Host : www.chrono.com

第一个可以正确获取服务器的响应报文，而第二个得到的会是一个“400 Bad Request”，表示请求报文格式有误，服务器无法正确处理：

2
    3
    HTTP/1.1 400 Bad Request
    Server: openresty/1.15.8.1
    Connection: close

# 总结 #

*  HTTP 报文结构就像是“大头儿子”，由“起始行 + 头部 + 空行 + 实体”组成，简单地说就是“header+body”；
 *  HTTP 报文可以没有 body，但必须要有 header，而且header 后也必须要有空行，形象地说就是“大头”必须要带着“脖子”；
 *  请求头由“请求行 + 头部字段”构成，响应头由“状态行 + 头部字段”构成；
    
     *  请求行有三部分：请求方法，请求目标和版本号；
     *  状态行也有三部分：版本号，状态码和原因字符串；
 *  头部字段是 key-value 的形式，用“:”分隔，不区分大小写，顺序任意，除了规定的标准头，也可以任意添加自定义字段，实现功能扩展；
 *  HTTP/1.1 里唯一要求必须提供的头字段是 Host，它必须出现在请求头里，标记虚拟主机名。

# 问题 #

> 如果拼 HTTP 报文的时候，在头字段后多加了一个CRLF，导致出现了一个空行，会发生什么？

头字段后多了一个CRLF，会被当做body处理

> 讲头字段时说“:”后的空格可以有多个，那为什么绝大多数情况下都只使用一个空格呢？

节省资源

[Link 1]: https://blog.csdn.net/zhizhengguan/article/details/121021565
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/dc6599ab1f19465cbec83d5bbcba19a7.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/cc270dc8a1c34e368529550a9b658a19.png
[04b07b95b2fc40f7a2a62e228e713c9d.png]: /images/20220828/56fdbbe274a940dfac5b3fcdc2974c0e.png
[cd457c20b6e0428cbe46a6ea4ae32117.png]: /images/20220828/22820a1fed3c4202928d810231eabec9.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/f58a678aa36640a0b6716ba2c9973c91.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/0eb51d96843149bea60200fba2fef38c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_11_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/f4e30f1561354349ad47bfb8ab1bcef6.png
[7a065584154e480a8569c0d171eb36fd.png]: /images/20220828/8f33fa42654a4e5fb2ea913de071fd14.png
[30fe4663dc9d4daf8eff6d10fa5de5ba.png]: /images/20220828/8536562cd61a474bbbf7cc107d172a28.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/2c42ad5977ed4fdc92e3401e8f8a70ba.png