Http 构成详解

梦里梦外; 2022-03-16 17:36 237阅读 0赞

HTTP全称为HyperText Transfer Protocol，从名字不难看出这是一种基于文本的网络协议，对于初学者来说比较友好，容易上手。各平台上的一些第三方库都对HTTP做了进一步的封装，让HTTP变得更加亲民，但往往拿来就用的技术，很容易忽视其背后隐藏的细节。今天一起来扒一扒HTTP到底是如何构成的。

### 初窥全貌 ###

HTTP第一眼看上去非常简单，先来看看Request部分：

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLWRjZjBlMDM1NThlYmYyYzcucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81OTIvZm9ybWF0L3dlYnA][]

上图主要分为三部分：request line，header和body，中间的CRLF为换行符。如果能将我们平常发送的http请求对应到上述三个部分，就能形成初步的印象了。

我们以一个实际的http request例子，抓包来看一看详细的内部构造。假设我们的请求URL为：

> [http://www.baidu.com/res/static/thirdparty/connect.jpg?t=1480992153433][http_www.baidu.com_res_static_thirdparty_connect.jpg_t_1480992153433]

后续的分析都是以此请求为基础。

### Request Line ###

Request Line的结构为：

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

**Method**也就是我们平常谈论最多的POST和GET所处的部分(除了POST和GET，还有其他类型的Method)。

**SP**是个分隔符，我用Wireshark抓包看了下，就一个字节大小，值为0x20，对应ASCII码中的空格。

**Request-URI**我们就更熟悉了，上述请求对应为：/res/static/thirdparty/connect.jpg?t=1480992153.564331。这里值得注意的一点是：实际传输的时候Request-URI有两种可能的形式，一种是完整的absoluteURI，包含Schema和Host，另一种是abs\_path，并没有包含Schema（http）和Host（mrpeak.cn）部分，Host部分被移交到了Header当中。所以平时我们抓包，有时看到的是完整的URI，有时则只有路径信息。

**HTTP-Version**也很直观，文本展示形式为：HTTP/1.1，代表我们当前使用的版本。

**CRLF**由两个字节组成。CR值为16进制的0x0D，对应ASCII中的回车键，LF值为0x0A，对应ASCII中的换行键，CRLF合起来就是我们平常所说的**\\r\\n**。

所以上述请求的Request-Line的文本展示：

> **GET** 空格 **/res/static/thirdparty/connect.jpg?t=1480992153.564331** 空格 **HTTP/1.1** CRLF

### Header ###

header其本质上是一些文本键值对，一个典型的例子如下图所示：

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLWVlYTM0OTNkODE4MWI1MjMucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy8xMDAwL2Zvcm1hdC93ZWJw][]

每个键值对的形式为：**Key：空格 Value CRLF**。

上面讲述Request-URI的时候，缺失的Host就以键值对的形式存在于header中，比如，Host： pan.baidu.com。

将若干个上述格式的键值对组合起来，就成了我们HTTP请求的完整header。最后一个键值对之后再跟一个CRLF，就表示我们的header结束了。

HTTP本身定义了一些header key，另外也允许开发者添加自己的key，自定义的key一般以X开头，比如可以定义X-APP-VERSION来记录客户端的版本号。

### Body ###

body里面包含请求的实际数据。

对于Method=GET的请求来说，body体是为空的，或者说不存在body体，Header最后的两个CRLF就标识着请求的结尾。我们一般调用请求的业务参数是通过Request Line当中的Request-URI来传递的，比如上述请求中的?t=1480992153.564331，也就是URI的query string部分。这部分同样是以键值对的形式存在，不过是位于Request Line当中。

对于Method=POST的请求来说，body体一般不为空，我们实际的业务数据都存放于body当中，数据在body体中是以何种形式存在，其实大有门道，后面再细说。至于Request-URI当中的query string部分，我们依然可以选择放置一部分数据在其中，但更普遍的做法是使用body体。

### HTTP Response ###

response的结构和request结构大致相同，可以用下图表示：

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLTk2YTVhMTQxNmUxOGMyNTYucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81OTQvZm9ybWF0L3dlYnA][]

不过是将Request Line换成了Status Line。

Status Line的结构如下：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

这里关键在于Status-Code的记忆，记住常见的Status-Code值，对于我们平时分析网络错误十分有帮助，不需要记住每个值的含义，只需理解每个类别的含义即可：

> 1xx: Informational - Request received, continuing process。  
> 2xx: Success - The action was successfully received, understood, and accepted。  
> 3xx: Redirection - Further action must be taken in order to complete the request。  
> 4xx: Client Error - The request contains bad syntax or cannot be fulfilled。  
> 5xx: Server Error - The server failed to fulfill an apparently valid request。

### 可以用来携带数据的部分 ###

分析至此，我们可以总结一个http请求，哪些地方是可以用来携带业务数据的。

Request Line当中的Request-URI是一个选择，也是标准的GET请求用来传递数据的位置，一般以query string的格式存在于URI当中。一些浏览器或者Framework对于query string的长度会有一定的限制，所以此处不适宜于传递较大的数据。

Header也是一个选择，我们可以选择协议中的一些标准header key，比如Host，User-Agent等，将我们的业务数据存放其Value中。或者我们通过自定义key，比如上面提到的X-APP-VERSION，使用X-开头是业界默认的习惯，虽然[RFC 6648][]当中建议大家不要再使用X-作为Prefix，但这一习惯今天依旧还在持续。

Body体是我们的第三个选择，POST请求可以根据Header中的Content-Type值，以不同的形式将数据保存在body体中。

### 一些隐藏的细节 ###

可以看出http是一种基于文本解析的协议，上面提到的空格（0x20），换行（0x0D0A）都是HTTP用来做文本解析的辅助符号。

解析HTTP的text流程，其实也比较好理解。一个简化的流程大致是这样：当我们从TCP层拿到应用层的buffer之后，以CLRF(\\r\\n)为分割符，将整个buffer分成若干行，第一行自然是我们的Request Line，之后每一行代表一个Header，如果连续读到两个CLRF，则表示header结束，如果是Method=POST，读取Header中的Content-Length值，最后根据这个值读取固定长度的body体。这样就完成了我们上述三个主要部分的读取。当然，上述是个简化的流程，实际解析场景会更多一些。

**我们再深入看下Request Line的解析**

我们从TCP层拿到的实际上是一个字节流，要将字节流解析成我们能够阅读交流的形式，我们需要将字节码进行编码和解码。Request Line使用的编解码格式是US-ASCII，也就是我们平时接触的ASCII码中的一种。

Request Line通过ASCII码做还原之后，我们得到的是类似这样的结果：

> **GET** **/res/static/thirdparty/connect.jpg?a=1&b=2** **HTTP/1.1**

URI的解析也自有一套规范，我们需要特别注意的是query string部分。我们平时编写业务代码的时候，可能会在query string当中塞入自己的数据，这些数据可能是任意形式的字节流，而Request Line和URI的解析都依赖于一些特殊字符来做分割，比如空格，/，？等等，所以为了能正确，安全的解析整个Request Line和URI，我们需要对query string中的字节流做进一步的编码约束，只允许其中出现安全的ASCII码，这也是我们为什么需要UrlEncode的原因。

UrlEncode的过程也比较简单，它将字节流中的所有字节，对照ASCII码表分为，安全的ASCII码和不安全的ASCII码。安全的ASCII码不用做任何处理，不安全的ASCII码（比如空格0x20）则做进一步的编码处理，编码的思路也简单：用安全的ASCII码来代替不安全的ASCII码。比如空格（0x20）被编码成%20，由一个ASCII码(空格)变成了三个ASCII码(%，2，0)。对于原本就不是ASCII码的内容来说，比如中文，则先以UTF-8编码成字节流，再对照ASCII码做编码。比如中文字「高」，其UTF-8的表现形式为：\\xE9\\xAB\\x98，再进一步做ASCII编码，最后UrlEncode的结果就为：%E9%AB%98。

由此可见，UrlEncode是出于URL安全解析的需要，Encode的结果是由%和一部分安全的ASCII码所组成。UrlEncode的缺点也比较明显，Encode非ASCII码的时候（比如中文），一个字节会被encode成3个字节，长度整整是原先的3倍，造成流量的浪费。

我见过有人使用base64来对query string做encode，这是把概念搞混淆了，至少base64 encode之后的=就不是一个URL安全的字符，=在UrlEncode之后对应%3d。

**Header的解析**

对于Header的解析可以先按CRLF分割成一个个的键值对，键值对里面的值，也就是我们所说的field content其实也有编码要求。[RFC 7230][]中有阐述：

> Historically, HTTP has allowed field content with text in the  
> ISO-8859-1 charset \[ISO-8859-1\], supporting other charsets only  
> through use of \[RFC2047\] encoding. In practice, most HTTP header  
> field values use only a subset of the US-ASCII charset \[USASCII\].  
> Newly defined header fields SHOULD limit their field values to  
> US-ASCII octets. A recipient SHOULD treat other octets in field  
> content (obs-text) as opaque data.

简单来说，我们在实际使用当中使用ASCII码来限制field content。我们常用几个Field，诸如Host，User-Agent等，使用ASCII码字符也已绰绰有余，一般不会对值做进一步的encode处理。

**Body的解析**

body的解析是我们平时打交道最多的部分，不是说我们需要知道如何去解析body，而是要了解body体里的数据格式。

body的解析本身比较简单，从header中知道Content-Length之后，读取固定长度的字节流即完成了body的获取，关键的环节是获取之后，如何读取其中的数据并递交给应用层，所以HTTP协议本身并没有对Body中的内容编码做约束，而是把它交给协议的使用者去决定，我们甚至可以在body体里存放二进制流，对应的Content-Type为application/octet-stream。

我们来看看平时发送HTTP请求时，以AFNetworking为例，使用最频繁的几种Content-Type：

*  multipart/form-data
 *  application/x-www-form-urlencoded
 *  application/json

当我们向Server发送数据的时候，需要和Server约定好所使用的Content-Type，客户端在发送Request的时候也要注意API的差别，以AFNetworking为例，发送json则使用：

AFJSONRequestSerializer* jsonSerializer = [AFJSONRequestSerializer serializer];
    request = [jsonSerializer requestWithMethod:@"POST" URLString:requestUrl parameters:requestParams error:nil];

发送multipart/form-data：

request = [self.requestSerializer multipartFormRequestWithMethod:@"POST" URLString:requestUrl parameters:requestParams constructingBodyWithBlock:nil error:nil];

发送x-www-form-urlencoded：

request = [self.requestSerializer requestWithMethod:@"POST" URLString:requestUrl parameters:requestParams error:nil];

json不用多说，大家都非常熟悉的数据交换格式。multipart/form-data和x-www-form-urlencoded比较容易引起混淆。

在AFNetworking中有这样一段代码：

//AFURLRequestSerialization
    if (![mutableRequest valueForHTTPHeaderField:@"Content-Type"]) {
        [mutableRequest setValue:@"application/x-www-form-urlencoded" forHTTPHeaderField:@"Content-Type"];
    }

可见当我们的Request没有设置Content-Type的时候，默认使用的就是application/x-www-form-urlencoded。这里的urlencoded和前面Request-URI中的urlencode是一回事，只不过encode的是body体当中的内容。

那我们什么时候用application/x-www-form-urlencoded，什么时候用multipart/form-data呢？

先来看下使用Content-Type为multipart/form-data时，我们的Request有什么变化，下图是使用mitmproxy抓包一个文件上传Request的headers示意图：

![aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLWEzODVmMWMwOWVmZWJkZGEucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy8xMDAwL2Zvcm1hdC93ZWJw][]

Content-Type的完整值为：multipart/form-data; boundary=Boundary+2BBBEA582E48968C。

multipart把body体分成多个块，多个块之间依赖于boundary值去做分割，所以生成的boundary要足够长，长到在字节流当中出现重复的概率几乎为0，否则就会导致错误的传输，AFNetworking中生成Boundary的方法如下：

static NSString * AFCreateMultipartFormBoundary() {
        return [NSString stringWithFormat:@"Boundary+%08X%08X", arc4random(), arc4random()];
    }

我们可以看下一个例子，如果使用multipart/form-data，body中具体的数据格式：

Boundary+2BBBEA582E48968C
    Content-Disposition: form-data; name="text1"
    text
    Boundary+2BBBEA582E48968C
    Content-Disposition: form-data; name="text2"
    another text

可以看到在body中多出了Boundary+2BBBEA582E48968C和Content-Disposition，这些会增加body的传输大小。

假设我们有一个大文件需要上传，如果使用application/x-www-form-urlencoded作为Content-Type，由于字节流当中存在非常多的非ASCII码，文件的长度会变至原本的2-3倍，所以此时multipart/form-data更合适。

假设我们只有少量的键值对需要上传，如果使用multipart/form-data作为Content-Type，由于boundary和Content-Disposition带来的额外流量，又显得得不偿失，所以此时使用application/x-www-form-urlencoded更为合适。

这也是为什么我们使用multipart/form-data作为文件类Request的Content-Type，而对于普通业务数据，则使用application/x-www-form-urlencoded或者application/json。

### 总结 ###

上述的分析，更多的是站在客户端的角度去看的，实际HTTP协议的构成细节非常之多，需要旷日持久的深入学习和积累。功夫越深，坑越少 ;)

原文链接：[扒一扒HTTP的构成][HTTP]

[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLWRjZjBlMDM1NThlYmYyYzcucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81OTIvZm9ybWF0L3dlYnA]: /images/20220310/9d6f042a035f4e528ebc8922e8c1bfe2.png
[http_www.baidu.com_res_static_thirdparty_connect.jpg_t_1480992153433]: https://link.jianshu.com?t=http://www.baidu.com/res/static/thirdparty/connect.jpg?t=1480992153433
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLWVlYTM0OTNkODE4MWI1MjMucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy8xMDAwL2Zvcm1hdC93ZWJw]: /images/20220310/ff709e39b54847c78b19acb3bc85d44d.png
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLTk2YTVhMTQxNmUxOGMyNTYucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy81OTQvZm9ybWF0L3dlYnA]: /images/20220310/ba2f70a082df4597928cfad58a9baeea.png
[RFC 6648]: https://link.jianshu.com?t=http://tools.ietf.org/html/rfc6648
[RFC 7230]: https://link.jianshu.com?t=https://tools.ietf.org/html/rfc7230#section-3.2.4
[aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy8xNTM0MTYxLWEzODVmMWMwOWVmZWJkZGEucG5nP2ltYWdlTW9ncjIvYXV0by1vcmllbnQvc3RyaXAlN0NpbWFnZVZpZXcyLzIvdy8xMDAwL2Zvcm1hdC93ZWJw]: /images/20220310/13e996ce0e7f4862a1730949555a3c41.png
[HTTP]: https://www.jianshu.com/p/b97ce60c631e