HTTP 报文结构

Posted 2021-03-03 niuyourou

　　HTTP位于五层模型中的应用层，是传输层（代表为TCP协议）的上层协议。

       之前我们通过 socket 实现了使用 TCP 协议进行数据收发：手写一个模块化的 TCP 服务端客户端 ，对 TCP 协议的使用有了一个初步的认识。

　　简单的说，IP 协议 帮助我们的数据包在复杂的网络环境下进行寻址，但并不能保证数据包一定可以到达目的地。因为传输环境或网络可能会非常复杂，我们并不能保证路由算法在所有场景下都可以准确的到达目的地，加上为了避免冗余数据包滞留网络对网络造成破坏，IP 协议中还存在最大跃点数等数据销毁机制。因此 IP 协议仅负责寻址，不负责到达。

　　所以仅通过 IP 协议进行通信是不可靠的，TCP 协议位于 IP 协议的上层，通过 ACK 确认机制帮助我们在 IP 协议的基础上建立了可靠的数据通道。

　　但 TCP 协议还是不能满足我们的通信要求，因为它是无界的。这使得我们无法将数据与请求联系起来，如果我们发送多次请求，请求的数据无间隔的到达或被封装在同一个数据包里到达的话，我们无法单纯的靠 TCP 协议确定某段数据属于哪次请求，也就是会出现所谓的粘包和半包问题。

　　HTTP 帮我们解决了这个问题，它从数据层面帮助我们对请求进行了定界，进一步满足了我们的通信需求。

　　整个网络分层模型就是一个责任链模式的典型代表，每层专注解决一类问题后将数据扔给下一层，直到到达我们的应用，使我们可以得到能直接能应用于业务的数据。

　　HTTP 在传输层上层约定了数据的传输格式，搞懂报文格式才能理解其解析机制，当然要看全面的报文格式最好的方式当然是去查阅 RFC 文档，这里我们只介绍其主要部分。

　　HTTP报文分为请求报文和响应报文，二者的基本格式是相同的。

　　请求报文的格式：

　　<method> <request-URL> <version>

　　<headers>

　　<entity-body>

　　响应报文的格式

　　<version><status><reason-phrase>

　　<headers>

　　<entity-body>

　　method： 表示请求方法，如 GET/POST 。
　　request-URL： 为请求的资源路径。

　　version： 表示使用的协议版本号，如1.0/1.1等。
　　status-code： 表示请求的状态码，描述请求过程中发生的情况，比如 200：成功；500：服务器端异常 等。

　　reason-phrase： 表示原因短语，无特殊含义，类似我们平时设计表结构时设计的 remark 备注字段。

　　header：请求首部。每个请求可以有零个或多个首部，每个首部都是一个键值对外加一个可选的空格。所有首部的最后由一个空行 CRLF 标识首部的结束。

　　entity-body：请求的实体部分。包含着我们请求的数据，但并不是我们所有的请求参数都会在请求实体中，请求实体可为空，也是以一个空行 CRLF 标识结束。

　　每个 HTTP 报文都是以一个起始行作为开始的。请求报文的起始行标明我要干什么，响应报文的起始行标明发生了什么。

 

　　响应报文的起始行则没有 url 和请求方法。

　　无论请求报文还是响应报文，其各字段间均是通过空格进行分隔的。

　　响应报文中的状态码可以向请求者说明该次请求发生了什么事情。我们比较熟悉的状态码比如 404/302/500/200 等都属于响应报文的状态码。

　　原因短语是方便我们阅读的状态码的可读版本，比如 200 后面跟的 OK 便是 200 的原因短语。　　

　　HTTP 首部用于向请求和响应的报文中添加一些额外的信息。HTTP规范定义了一些固定的首部字段，当然我们也可以随意添加自己定义的首部字段。

　　首部有以下几种分类：

　　通用首部：即可出现在请求报文中，也可出现在响应报文中
　　请求首部：提供更多有关请求的信息
　　响应首部：提供更多有关响应的信息
　　实体首部：描述主体的长度和内容，或者资源本身
　　扩展首部：规范中没有定义的新首部

　　这样一来，首部可能会有比较多的附加字段，将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符（tab）。

　　以上是对 HTTP 协议组成部分比较粗粒度的介绍，下次我们基于其报文结构，在 TCP 通信框架上层手写一个解析 HTTP 报文的 Handler 。