http协议以及chunked编码分析

最新推荐文章于 2025-04-03 15:14:41 发布

zzhongcy

最新推荐文章于 2025-04-03 15:14:41 发布

阅读量8.8k

点赞数 2

分类专栏： http 文章标签： http协议

http 专栏收录该内容

13 篇文章

订阅专栏

本文深入探讨了HTTP协议的核心组成部分，包括HTTP消息的结构、Header与Body的区分、请求方法、响应状态码、通用头域、请求头域、响应头域、实体头域及其作用，同时解析了Header与Body之间的换行符以及HTTP协议中的状态码分类。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Http协议

Http协议 -- 格式

HTTP消息包括浏览器向服务器的请求消息和服务器向浏览器的响应消息。这两种类型的消息都由一个起始行，一个或者多个头域，一个头域结束的空行和可选的消息体组成。HTTP头域一般包括通用头，请求头，响应头，实体头。每个头域由域名、冒号（:）、域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符。头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。

先来看一个标准的HTTP请求消息和响应消息，使用IE 7.0访问google。

- - - - - - - - 访问google： - - - - - - - -

GET / HTTP/1.1\r\n
Accept: application/x-shockwave-flash, image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-silverlight, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*\r\n
Accept-Language: zh-cn\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0;QQDownload 528; InfoPath.2; .NET CLR 2.0.50727)\r\n
Accept-Encoding: gzip, deflate\r\n
Host: www.google.com\r\n
Connection: Keep-Alive\r\n
Cookie: PREF=ID=bbd19f9992b2c394:TM=1239870831:LM=1239870831:S=yJs2fykR2UkMKub8\r\n

- - - - - - - - - google返回内容 - - - - - - - - -

HTTP/1.1 200 OK\r\n
Cache-Control: private, max-age=0\r\n
Date: Tue, 21 Apr 2009 02:30:02 GMT\r\n
Expires: -1\r\n
Content-Type: text/html; charset=UTF-8\r\n
Server: gws\r\n
Content-Encoding: gzip\r\n
Transfer-Encoding: chunked\r\n

Http协议中的Header与Body

Header的每行最后要加\r\n

Header与Body之间要用\r\n隔开

Body后无需加\r\n

ACSII码中

'\n' 10 换行

'\r' 13 回车

也可以表示为'\x0a'和'\x0d'.(16进制)

示例：HTTP开始部分为header，<html>部分为body。

HTTP/1.1 200 OK\r\n

Content-Encoding: gzip\r\n

Content-Type: text/xml\r\n

Content-Length: 399\r\n

Connection: keep-alive\r\n

X-Varnish-Cache: HIT\r\n

X-Varnish-Cache-Hits: 1241\r\n

\r\n

<html.....</html>

HTTP协议请求方法

http请求由三部分组成，分别是：请求方法、消息报头、请求正文。

请求方法以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。格式如下：

Method Request-URI HTTP-Version CRLF
Method 请求方法

Request-URI 统一资源标识符

HTTP-Version 请求的HTTP协议版本

CRLF 回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

请求方法有多种，各个方法的用处：
GET         请求获取Request-URI所标识的资源
POST       在Request-URI所标识的资源后附加新的数据
HEAD       请求获取由Request-URI所标识的资源的响应消息报头
PUT         请求服务器存储一个资源，并用Request-URI作为其标识
DELETE     请求服务器删除Request-URI所标识的资源
TRACE      请求服务器回送收到的请求信息，主要用于测试或诊断
CONNECT 保留将来使用
OPTIONS   请求查询服务器的性能，或者查询与资源相关的选项和需求

GET方法用来向服务器获取资源，POST方法要求被请求服务器接受附在消息头域后面的数据，常用于提交表单。HEAD方法和GET方法类似，HEAD不用服务器返回实体内容。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。

HTTP协议 -- 响应

在收到浏览器的资源请求后，服务器返回一个HTTP响应消息。HTTP响应也是由三个部分组成：状态行、消息报头、响应正文。
1、状态行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
HTTP-Version    服务器HTTP协议的版本
Status-Code    服务器发回的响应状态代码
Reason-Phrase 状态代码的文本描述
状态代码有三位数字组成，第一个数字定义了响应的类别，并有五种可能取值：
1xx：指示信息--表示请求已接收，继续处理
2xx：成功--表示请求已被成功接收、理解、接受
3xx：重定向--要完成请求必须进行更进一步的操作
4xx：客户端错误--请求有语法错误或请求无法实现
5xx：服务器端错误--服务器未能实现合法的请求
常见状态代码、状态描述、说明：
200 OK               //客户端请求成功
400 Bad Request //客户端请求有语法错误，不能被服务器所理解
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden     //服务器收到请求，但是拒绝提供服务
404 Not Found    //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

2、响应的消息头域下面会细述
3、响应正文就是服务器返回的资源的内容

HTTP协议 -- 消息头域

HTTP的头域的主要功能是完成浏览器和服务器之间的协作。相当于一个协商和控制的作用。比如浏览器高速服务器自己可以接受的文件类型，可以接受何种方式的字符编码，本地的浏览器版本。

通用头域

　　通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。

1. Cache-Control头域
　　Cache-Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下：
　　Public指示响应可被任何缓存区缓存。
　　Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。
　　no-cache指示请求或响应消息不能缓存
　　no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
　　max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
　　min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
　　max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
2. Date头域
　　Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
3. Pragma头域
　　Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache-Control:no-cache相同。

请求头域

1. Host头域
　　Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
2. Referer头域
　　Referer头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。
3. Range头域
　　Range头域可以请求实体的一个或者多个子范围。例如，
　　表示头500个字节：bytes=0-499
　　表示第二个500字节：bytes=500-999
　　表示最后500个字节：bytes=-500
　　表示500字节以后的范围：bytes=500-
　　第一个和最后一个字节：bytes=0-0,-1
　　同时指定几个范围：bytes=500-600,601-999
　　但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200（OK）。在迅雷等HTTP下载软件中就是使用这个头域来完成多线程的下载的。
4. User-Agent头域
　　User-Agent头域的内容包含发出请求的用户信息，比如浏览器的内核版本。

响应头域

响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头域，一般将会作为实体头域处理。

1. Location响应头
　Location响应头用于重定向接收者到一个新URI地址。
2. Server响应头
　Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。

实体头域

请求消息和响应消息都可以包含实体信息，实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息，实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体头，但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流，它的编码方式由Content-Encoding或Content-Type定义，它的长度由Content-Length或Content-Range定义。
1. Content-Type实体头
　　用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型Content-Range实体头
2. Content-Range实体头
　　用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
3. Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
　　例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围，Content-Length表示实际传送的字节数。
4. Last-modified实体头
　　指定服务器上保存内容的最后修订时间。

HTTP协议 -- 状态码

1xx-信息提示
这些状态代码表示临时的响应。客户端在收到常规响应之前，应准备接收一个或多个1xx响应。
100-继续。
101-切换协议。

2xx-成功
这类状态代码表明服务器成功地接受了客户端请求。
200-确定。客户端请求已成功。
201-已创建。
202-已接受。
203-非权威性信息。
204-无内容。
205-重置内容。
206-部分内容。

3xx-重定向
客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求。
301-对象已永久移走，即永久重定向。
302-对象已临时移动。
304-未修改。
307-临时重定向。

4xx-客户端错误
发生错误，客户端似乎有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份验证信息。
400-错误的请求。
401-访问被拒绝。IIS定义了许多不同的401错误，它们指明更为具体的错误原因。这些具体的错误代码在浏览器中显示，但不在IIS日志中显示：
401.1-登录失败。
401.2-服务器配置导致登录失败。
401.3-由于ACL对资源的限制而未获得授权。
401.4-筛选器授权失败。
401.5-ISAPI/CGI应用程序授权失败。
401.7–访问被Web服务器上的URL授权策略拒绝。这个错误代码为IIS6.0所专用。
403-禁止访问：IIS定义了许多不同的403错误，它们指明更为具体的错误原因：
403.1-执行访问被禁止。
403.2-读访问被禁止。
403.3-写访问被禁止。
403.4-要求SSL。
403.5-要求SSL128。
403.6-IP地址被拒绝。
403.7-要求客户端证书。
403.8-站点访问被拒绝。
403.9-用户数过多。
403.10-配置无效。
403.11-密码更改。
403.12-拒绝访问映射表。
403.13-客户端证书被吊销。
403.14-拒绝目录列表。
403.15-超出客户端访问许可。
403.16-客户端证书不受信任或无效。
403.17-客户端证书已过期或尚未生效。
403.18-在当前的应用程序池中不能执行所请求的URL。这个错误代码为IIS6.0所专用。
403.19-不能为这个应用程序池中的客户端执行CGI。这个错误代码为IIS6.0所专用。
403.20-Passport登录失败。这个错误代码为IIS6.0所专用。
404-未找到。
404.0-（无）–没有找到文件或目录。
404.1-无法在所请求的端口上访问Web站点。
404.2-Web服务扩展锁定策略阻止本请求。
404.3-MIME映射策略阻止本请求。
405-用来访问本页面的HTTP谓词不被允许（方法不被允许）
406-客户端浏览器不接受所请求页面的MIME类型。
407-要求进行代理身份验证。
412-前提条件失败。
413–请求实体太大。
414-请求URI太长。
415–不支持的媒体类型。
416–所请求的范围无法满足。
417–执行失败。
423–锁定的错误。

5xx-服务器错误
服务器由于遇到错误而不能完成该请求。
500-内部服务器错误。
500.12-应用程序正忙于在Web服务器上重新启动。
500.13-Web服务器太忙。
500.15-不允许直接请求Global.asa。
500.16–UNC授权凭据不正确。这个错误代码为IIS6.0所专用。
500.18–URL授权存储不能打开。这个错误代码为IIS6.0所专用。
500.100-内部ASP错误。
501-页眉值指定了未实现的配置。
502-Web服务器用作网关或代理服务器时收到了无效响应。 phperz.com
502.1-CGI应用程序超时。
502.2-CGI应用程序出错。application.
503-服务不可用。这个错误代码为IIS6.0所专用。
504-网关超时。
505-HTTP版本不受支持。

content-length 以及chunked编码分析

0.序

在研究百度云盘的响应过程中，发现其响应采用chunked编码形式，并且没有Content-length字段，因为项目需要，就需要研究一下http/1.1协议中的chunked编码。

首先介绍与chunked编码相关的几个概念，从而引出chunked编码

1.http/1.1协议中与chunked编码的相关字段

1）Entity Body： entity-body只有在message-body出现时才会出现。通过对message-body的解码获得entity-body。transfer-encoding用于确保安全和信息的恰当传输。

Entity-length：在应用任何transfer-encoding之前的message-body的长度。即没有编码之前message-body的长度。

2）Content-length ：用于描述HTTP消息实体的传输长度。（the transfer-length of the message-body）

消息实体长度：即Entity-length，压缩之前的message-body的长度

消息实体的传输长度：Content-length，压缩后的message-body的长度。

3）Message Length ：这部分的解释必须得看看大牛的解释 http://blog.xiuwz.com/tag/content-length/

以下内容来自于 http://blog.xiuwz.com/tag/content-length/

在具体的HTTP交互中，客户端是如何获取消息长度的呢，主要基于以下几个规则：

响应为1xx，204，304相应或者head请求，则直接忽视掉消息实体内容。
如果有Transfer-Encoding，则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说Chunked模式。
“如果head中有Content-Length，那么这个Content-Length既表示实体长度，又表示传输长度。如果实体长度和传输长度不相等（比如说设置了Transfer-Encoding），那么则不能设置Content-Length。如果设置了Transfer-Encoding，那么Content-Length将被忽视”。这句话翻译的优点饶，其实关键就一点：有了Transfer-Encoding，则不能有Content-Length。
Range传输。不关注，没详细看了：）
通过服务器关闭连接能确定消息的传输长度。（请求端不能通过关闭连接来指明请求消息体的结束，因为这样可以让服务器没有机会继续给予响应）。这种情况主要对应为短连接，即非keep-alive模式。
HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候，可以通过chunk机制来处理这种情况。
在包含消息内容的header中，如果有content-length字段，那么该字段对应的值必须完全和消息主题里面的长度匹配。
“The entity-length of a message is the length of the message-body before any transfer-codings have been applied”
也就是有chunk就不能有content-length 。
其实后面几条几乎可以忽视，简单总结后如下：
1、Content-Length如果存在并且有效的话，则必须和消息内容的传输长度完全一致。（经过测试，如果过短则会截断，过长则会导致超时。）

2、如果存在Transfer-Encoding（重点是chunked），则在header中不能有Content-Length，有也会被忽视。

3、如果采用短连接，则直接可以通过服务器关闭连接来确定消息的传输长度。（这个很容易懂）

结合HTTP协议其他的特点，比如说Http1.1之前的不支持keep alive。那么可以得出以下结论：

1、在Http 1.0及之前版本中，content-length字段可有可无。

2、在http1.1及之后版本。如果是keep alive，则content-length和chunk必然是二选一。若是非keep alive，则和http1.0一样。content-length可有可无。

其中比较重要的一点如下所述：

如果存在Transfer-encoding存在，则在header中不能由content-length，有也会被忽略。

如果Content-length存在并且有效的话，则必须和消息内容的传输长度完全一致。

4）content-length字段的作用

Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。但是如果消息中没有Conent-Length，那该如何来判断呢？又在什么情况下会没有Conent-Length呢？

没有Content-length时，客户端如何来判断数据是否接收完成呢？

1）静态页面或者图片：当客户端向服务器请求一个静态页面或者一张图片时，服务器可以很清楚的知道内容大小，然后通过Content-length消息首部字段告诉客户端需要接收多少数据。

2）动态页面：如果是动态页面等时，服务器是不可能预先知道内容大小，这时就可以使用Transfer-Encoding：chunk模式来传输数据了。即如果要一边产生数据，一边发给客户端，服务器就需要使用”Transfer-Encoding: chunked”这样的方式来代替Content-Length。

采用Transfer-encoding的目的

一边产生数据，一边发给客户端。

2.chunked编码

1）定义

分块传输编码（Chunked transfer encoding）是超文本传输协议（HTTP）中的一种数据传输机制，允许HTTP由网页服务器发送给客户端应用（通常是网页浏览器）的数据可以分成多个部分。分块传输编码只在HTTP协议1.1版本（HTTP/1.1）中提供。

2）说明：

通常，HTTP应答消息中发送的数据是整个发送的，Content-Length消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。

3）格式：

如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。

每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF （回车及换行），然后是数据本身，最后块CRLF结束。在一些实现中，块大小和CRLF之间填充有白空格（0x20）。

最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。

消息最后以CRLF结尾。

chunk编码将数据分成一块一块的发生。Chunked编码将使用若干个Chunk串连而成，由一个标明长度为0 的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字 ）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF) 隔开。在最后一个长度为0的Chunk中的内容是称为footer的内容，是一些附加的Header信息（通常可以直接忽略）。

Chunk编码的格式如下：

Chunked-Body = *chunk
“0″ CRLF
footer
CRLF
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF

hex-no-zero = <HEX excluding “0″>

chunk-size = hex-no-zero *HEX
chunk-ext = *( “;” chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)

footer = *entity-header

即Chunk编码由四部分组成： 1、0至多个chunk块 ，2、“0″ CRLF ，3、footer ，4、CRLF . 而每个chunk块由：chunk-size、chunk-ext（可选）、CRLF、chunk-data、CRLF组成。