网络编程懒人入门(六)：深刻浅出，全面理解HTTP协议

本文引用了自简书做者“涤生_Woo”的文章，内容有删减，感谢原做者的分享。

一、前言

HTTP（全称超文本传输协议，英文全称HyperText Transfer Protocol）是互联网上应用最为普遍的一种网络协议。全部的WWW文件都必须遵照这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

对于移动端即时通信（尤为IM应用）来讲，现今主流的数据通讯总结下来无外乎就是长链接+短链接的方式，而短链接在应用上讲就是本文将要介绍的HTTP协议的应用，而而正确地理解HTTP协议对于写好IM来讲，是至关有益的（关于移动端的HTTP具体应用状况，能够阅读《现代移动端网络短链接的优化手段总结：请求速度、弱网适应、安全保障》）。

本篇文章篇幅比较长，先来个思惟导图预览一下：

 

学习交流：

- 即时通信开发交流3群：185926912[推荐]

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

（本文同步发布于：http://www.52im.net/thread-1677-1-1.html）

二、“HTTP之父”其人

 

▲ “HTTP之父”——Ted Nelson

 

▲ HTTP协议logo

1960年Ted Nelson构思了一种经过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。

Ted Nelson组织协调万维网协会（World Wide Web Consortium）和Internet工做小组（Internet Engineering Task Force）共同合做研究，最终发布了一系列的RFC，其中最著名的就是RFC 2616。RFC 2616定义了HTTP协议的咱们今天广泛使用的一个版本——HTTP 1.1。

因为Ted Nelson对HTTP技术的发展作出的突破性历史贡献，他被称为“HTTP之父”。

三、系列文章

本文是系列文章中的第6篇，本系列文章的大纲以下：

《网络编程懒人入门(一)：快速理解网络通讯协议（上篇）》

《网络编程懒人入门(二)：快速理解网络通讯协议（下篇）》

《网络编程懒人入门(三)：快速理解TCP协议一篇就够》

《网络编程懒人入门(四)：快速理解TCP和UDP的差别》

《网络编程懒人入门(五)：快速理解为何说UDP有时比TCP更有优点》

《网络编程懒人入门(六)：深刻浅出，全面理解HTTP协议》（本文）

若是您以为本系列文章过于基础，您可直接阅读《鲜为人知的网络编程》系列文章，该系列目录以下：

《鲜为人知的网络编程(一)：浅析TCP协议中的疑难杂症(上篇)》

《鲜为人知的网络编程(二)：浅析TCP协议中的疑难杂症(下篇)》

《鲜为人知的网络编程(三)：关闭TCP链接时为何会TIME_WAIT、CLOSE_WAIT》

《鲜为人知的网络编程(四)：深刻研究分析TCP的异常关闭》

《鲜为人知的网络编程(五)：UDP的链接性和负载均衡》

《鲜为人知的网络编程(六)：深刻地理解UDP协议并用好它》

关于移动端网络特性及优化手段的总结性文章请见：

《现代移动端网络短链接的优化手段总结：请求速度、弱网适应、安全保障》

《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》

《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》

四、参考资料

《TCP/IP详解 - 第11章·UDP：用户数据报协议》

《TCP/IP详解 - 第17章·TCP：传输控制协议》

《TCP/IP详解 - 第18章·TCP链接的创建与终止》

《TCP/IP详解 - 第21章·TCP的超时与重传》

《通俗易懂-深刻理解TCP协议（上）：理论基础》

《通俗易懂-深刻理解TCP协议（下）：RTT、滑动窗口、拥塞处理》

《理论经典：TCP协议的3次握手与4次挥手过程详解》

《理论联系实际：Wireshark抓包分析TCP 3次握手、4次挥手过程》

《计算机网络通信协议关系图（中文珍藏版）》

《高性能网络编程(一)：单台服务器并发TCP链接数到底能够有多少》

《高性能网络编程(二)：上一个10年，著名的C10K并发链接问题》

《高性能网络编程(三)：下一个10年，是时候考虑C10M并发问题了》

《高性能网络编程(四)：从C10K到C10M高性能网络应用的理论探索》

《简述传输层协议TCP和UDP的区别》

《为何QQ用的是UDP协议而不是TCP协议？》

《移动端即时通信协议选择：UDP仍是TCP？》

五、HTTP概述

5.1 计算机网络体系结构分层

 

5.2 TCP/IP 通讯传输流

利用 TCP/IP 协议族进行网络通讯时，会经过分层顺序与对方进行通讯。发送端从应用层往下走，接收端则从链路层往上走。

TCP/IP 通讯传输流以下：

 

首先做为发送端的客户端在应用层（HTTP 协议）发出一个想看某个 Web 页面的 HTTP 请求；

接着，为了传输方便，在传输层（TCP 协议）把从应用层处收到的数据（HTTP 请求报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层；

在网络层（IP 协议），增长做为通讯目的地的 MAC 地址后转发给链路层。这样一来，发往网络的通讯请求就准备齐全了；

接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到由客户端发送过来的 HTTP请求。

HTTP 请求以下图所示：

 

在网络体系结构中，包含了众多的网络协议，这篇文章主要围绕 HTTP 协议（HTTP/1.1版本）展开。

HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传输协议。它可使浏览器更加高效，使网络传输减小。它不只保证计算机正确快速地传输超文本文档，还肯定传输文档中的哪一部分，以及哪部份内容首先显示(如文本先于图形)等。

HTTP是客户端浏览器或其余程序与Web服务器之间的应用层通讯协议。在Internet上的Web服务器上存放的都是超文本信息，客户机须要经过HTTP协议传输所要访问的超文本信息。HTTP包含命令和传输信息，不只可用于Web访问，也能够用于其余因特网/内联网应用系统之间的通讯，从而实现各种应用资源超媒体访问的集成。

咱们在浏览器的地址栏里输入的网站地址叫作URL (Uniform Resource Locator，统一资源定位符)。就像每家每户都有一个门牌地址同样，每一个网页也都有一个Internet地址。当你在浏览器的地址框中输入一个URL或是单击一个超级连接时，URL就肯定了要浏览的地址。浏览器经过超文本传输协议(HTTP)，将Web服务器上站点的网页代码提取出来，并翻译成漂亮的网页。

六、HTTP 工做过程

HTTP请求响应模型：

 

HTTP通讯机制是在一次完整的 HTTP 通讯过程当中，客户端与服务器之间将完成下列7个步骤：

1）创建 TCP 链接：在HTTP工做开始以前，客户端首先要经过网络与服务器创建链接，该链接是经过 TCP 来完成的，该协议与 IP 协议共同构建 Internet，即著名的 TCP/IP 协议族，所以 Internet 又被称做是 TCP/IP 网络。HTTP 是比 TCP 更高层次的应用层协议，根据规则，只有低层协议创建以后，才能进行高层协议的链接，所以，首先要创建 TCP 链接，通常 TCP 链接的端口号是80；

2）客户端向服务器发送请求命令：一旦创建了TCP链接，客户端就会向服务器发送请求命令；

例如：GET/sample/hello.jsp HTTP/1.1；

3）客户端发送请求头信息：客户端发送其请求命令以后，还要以头信息的形式向服务器发送一些别的信息，以后客户端发送了一空白行来通知服务器，它已经结束了该头信息的发送；

4）服务器应答：客户端向服务器发出请求后，服务器会客户端返回响应；

例如： HTTP/1.1 200 OK

响应的第一部分是协议的版本号和响应状态码；

5）服务器返回响应头信息：正如客户端会随同请求发送关于自身的信息同样，服务器也会随同响应向用户发送关于它本身的数据及被请求的文档；

6）服务器向客户端发送数据：服务器向客户端发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以 Content-Type 响应头信息所描述的格式发送用户所请求的实际数据；

7）服务器关闭 TCP 链接：通常状况下，一旦服务器向客户端返回了请求数据，它就要关闭 TCP 链接，而后若是客户端或者服务器在其头信息加入了这行代码 Connection:keep-alive ，TCP 链接在发送后将仍然保持打开状态，因而，客户端能够继续经过相同的链接发送请求。保持链接节省了为每一个请求创建新链接所需的时间，还节约了网络带宽。

七、HTTP 协议基础

7.1 经过请求和响应的交换达成通讯

应用 HTTP 协议时，一定是一端担任客户端角色，另外一端担任服务器端角色。仅从一条通讯线路来讲，服务器端和客服端的角色是肯定的。HTTP 协议规定，请求从客户端发出，最后服务器端响应该请求并返回。换句话说，确定是先从客户端开始创建通讯的，服务器端在没有接收到请求以前不会发送响应。

7.2 HTTP 是不保存状态的协议

HTTP 是一种无状态协议。协议自身不对请求和响应之间的通讯状态进行保存。也就是说在 HTTP 这个级别，协议对于发送过的请求或响应都不作持久化处理。这是为了更快地处理大量事务，确保协议的可伸缩性，而特地把 HTTP 协议设计成如此简单的。

但是随着 Web 的不断发展，咱们的不少业务都须要对通讯状态进行保存。因而咱们引入了 Cookie 技术。有了 Cookie 再用 HTTP 协议通讯，就能够管理状态了。

7.3 使用 Cookie 的状态管理

Cookie 技术经过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。Cookie 会根据从服务器端发送的响应报文内的一个叫作 Set-Cookie 的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie 后，会去检查到底是从哪个客户端发来的链接请求，而后对比服务器上的记录，最后获得以前的状态信息。

Cookie 的流程：

 

7.4 请求 URI 定位资源

HTTP 协议使用 URI 定位互联网上的资源。正是由于 URI 的特定功能，在互联网上任意位置的资源都能访问到。

7.5 告知服务器意图的 HTTP 方法（HTTP/1.1）

 

7.6 持久链接

HTTP 协议的初始版本中，每进行一个 HTTP 通讯都要断开一次 TCP 链接。好比使用浏览器浏览一个包含多张图片的 HTML 页面时，在发送请求访问 HTML 页面资源的同时，也会请求该 HTML 页面里包含的其余资源。所以，每次的请求都会形成无畏的 TCP 链接创建和断开，增长通讯量的开销。

为了解决上述 TCP 链接的问题，HTTP/1.1 和部分 HTTP/1.0 想出了持久链接的方法。其特色是，只要任意一端没有明确提出断开链接，则保持 TCP 链接状态。旨在创建一次 TCP 链接后进行屡次请求和响应的交互。在 HTTP/1.1 中，全部的链接默认都是持久链接。

7.7 管线化

持久链接使得多数请求以管线化方式发送成为可能。之前发送请求后需等待并接收到响应，才能发送下一个请求。管线化技术出现后，不用等待亦可发送下一个请求。这样就能作到同时并行发送多个请求，而不须要一个接一个地等待响应了。

好比，当请求一个包含多张图片的 HTML 页面时，与挨个链接相比，用持久链接可让请求更快结束。而管线化技术要比持久链接速度更快。请求数越多，时间差就越明显。

八、HTTP 协议报文结构

8.1 HTTP 报文

用于 HTTP 协议交互的信息被称为 HTTP 报文。请求端（客户端）的 HTTP 报文叫作请求报文；响应端（服务器端）的叫作响应报文。HTTP 报文自己是由多行（用 CR+LF 做换行符）数据构成的字符串文本。

8.2 HTTP 报文结构

HTTP 报文大体可分为报文首部和报文主体两部分。二者由最初出现的空行（CR+LF）来划分。一般，并不必定有报文主体。

HTTP 报文结构以下：

 

 

8.3 请求报文结构

 

请求报文的首部内容由如下数据组成：

请求行 —— 包含用于请求的方法、请求 URI 和 HTTP 版本；

首部字段 —— 包含表示请求的各类条件和属性的各种首部。（通用首部、请求首部、实体首部以及RFC里未定义的首部如 Cookie 等）。

请求报文的示例，以下：

 

8.4 响应报文结构

 

响应报文的首部内容由如下数据组成：

状态行 —— 包含代表响应结果的状态码、缘由短语和 HTTP 版本；

首部字段 —— 包含表示请求的各类条件和属性的各种首部。（通用首部、响应首部、实体首部以及RFC里未定义的首部如 Cookie 等）。

响应报文的示例，以下：

 

九、HTTP 报文首部之首部字段（重点分析）

9.1 首部字段概述

先来回顾一下首部字段在报文的位置，HTTP 报文包含报文首部和报文主体，报文首部包含请求行（或状态行）和首部字段。

在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖 HTTP 报文相关的内容信息。使用首部字段是为了给客服端和服务器端提供报文主体大小、所使用的语言、认证信息等内容。

9.2 首部字段结构

HTTP 首部字段是由首部字段名和字段值构成的，中间用冒号“：”分隔。

另外，字段值对应单个 HTTP 首部字段能够有多个值。

当 HTTP 报文首部中出现了两个或以上具备相同首部字段名的首部字段时，这种状况在规范内还没有明确，根据浏览器内部处理逻辑的不一样，优先处理的顺序可能不一样，结果可能并不一致。

 

9.3首部字段类型

首部字段根据实际用途被分为如下4种类型：

 

9.4通用首部字段（HTTP/1.1）

 

9.5请求首部字段（HTTP/1.1）

 

9.6响应首部字段（HTTP/1.1）

 

9.7实体首部字段（HTTP/1.1）

 

9.8为 Cookie 服务的首部字段

 

十、其余首部字段

HTTP 首部字段是能够自行扩展的。因此在 Web 服务器和浏览器的应用上，会出现各类非标准的首部字段。如下是最为经常使用的首部字段。

X-Frame-Options：

X-Frame-Options: DENY 首部字段 X-Frame-Options 属于 HTTP 响应首部，用于控制网站内容在其余 Web 网站的 Frame 标签内的显示问题。其主要目的是为了防止点击劫持（clickjacking）攻击。首部字段 X-Frame-Options 有如下两个可指定的字段值：

DENY：拒绝；

SAMEORIGIN：仅同源域名下的页面（Top-level-browsing-context）匹配时许可。（好比，当指定 http://sample.com/sample.html 页面为 SAMEORIGIN 时，那么 sample.com 上全部页面的 frame 都被容许可加载该页面，而 example.com 等其余域名的页面就不行了）。

X-XSS-Protection：

X-XSS-Protection: 1 首部字段 X-XSS-Protection 属于 HTTP 响应首部，它是针对跨站脚本攻击（XSS）的一种对策，用于控制浏览器 XSS 防御机制的开关。首部字段 X-XSS-Protection 可指定的字段值以下:

0 ：将 XSS 过滤设置成无效状态

1 ：将 XSS 过滤设置成有效状态

DNT：

DNT: 1 首部字段 DNT 属于 HTTP 请求首部，其中 DNT 是 Do Not Track 的简称，意为拒绝我的信息被收集，是表示拒绝被精准广告追踪的一种方法。首部字段 DNT 可指定的字段值以下：

0 ：赞成被追踪

1 ：拒绝被追踪

因为首部字段 DNT 的功能具有有效性，因此 Web 服务器须要对 DNT作对应的支持。

P3P：

P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND 首部字段 P3P 属于 HTTP 响应首部，经过利用 P3P（The Platform for Privacy Preferences，在线隐私偏好平台）技术，可让 Web 网站上的我的隐私变成一种仅供程序可理解的形式，以达到保护用户隐私的目的。

要进行 P3P 的设定，需按如下操做步骤进行：

步骤 1：建立 P3P 隐私

步骤 2：建立 P3P 隐私对照文件后，保存命名在 /w3c/p3p.xml

步骤 3：从 P3P 隐私中新建 Compact policies 后，输出到 HTTP 响应中

十一、HTTP 响应状态码

消息

描述

100 Continue

服务器仅接收到部分请求，可是一旦服务器并无拒绝该请求，客户端应该继续发送其他的请求。

101 Switching Protocols

服务器转换协议：服务器将听从客户的请求转换到另一种协议。

消息

描述

200 OK

请求成功（其后是对GET和POST请求的应答文档。）

201 Created

请求被建立完成，同时新的资源被建立。

202 Accepted

供处理的请求已被接受，可是处理未完成。

203 Non-authoritative Information

文档已经正常地返回，但一些应答头可能不正确，由于使用的是文档的拷贝。

204 No Content

没有新文档。浏览器应该继续显示原来的文档。若是用户按期地刷新页面，而Servlet能够肯定用户文档足够新，这个状态代码是颇有用的。

205 Reset Content

没有新文档。但浏览器应该重置它所显示的内容。用来强制浏览器清除表单输入内容。

206 Partial Content

客户发送了一个带有Range头的GET请求，服务器完成了它。

消息

描述

300 Multiple Choices

多重选择。连接列表。用户能够选择某连接到达目的地。最多容许五个地址。

301 Moved Permanently

所请求的页面已经转移至新的url。

302 Found

所请求的页面已经临时转移至新的url。

303 See Other

所请求的页面可在别的url下被找到。

304 Not Modified

未按预期修改文档。客户端有缓冲的文档并发出了一个条件性的请求（通常是提供If-Modified-Since头表示客户只想比指定日期更新的文档）。服务器告诉客户，原来缓冲的文档还能够继续使用。

305 Use Proxy

客户请求的文档应该经过Location头所指明的代理服务器提取。

306 Unused

此代码被用于前一版本。目前已再也不使用，可是代码依然被保留。

307 Temporary Redirect

被请求的页面已经临时移至新的url。

消息

描述

400 Bad Request

服务器未能理解请求。

401 Unauthorized

被请求的页面须要用户名和密码。

401.1

登陆失败。

401.2

服务器配置致使登陆失败。

401.3

因为 ACL 对资源的限制而未得到受权。

401.4

筛选器受权失败。

401.5

ISAPI/CGI 应用程序受权失败。

401.7

访问被 Web 服务器上的 URL 受权策略拒绝。这个错误代码为 IIS 6.0 所专用。

402 Payment Required

此代码尚没法使用。

403 Forbidden

对被请求页面的访问被禁止。

403.1

执行访问被禁止。

403.2

读访问被禁止。

403.3

写访问被禁止。

403.4

要求 SSL。

403.5

要求 SSL 128。

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。这个错误代码为 IIS 6.0 所专用。

403.19

不能为这个应用程序池中的客户端执行 CGI。这个错误代码为 IIS 6.0 所专用。

403.20

Passport 登陆失败。这个错误代码为 IIS 6.0 所专用。

404 Not Found

服务器没法找到被请求的页面。

404.0

（无）–没有找到文件或目录。

404.1

没法在所请求的端口上访问 Web 站点。

404.2

Web 服务扩展锁定策略阻止本请求。

404.3

MIME 映射策略阻止本请求。

405 Method Not Allowed

请求中指定的方法不被容许。

406 Not Acceptable

服务器生成的响应没法被客户端所接受。

407 Proxy Authentication Required

用户必须首先使用代理服务器进行验证，这样请求才会被处理。

408 Request Timeout

请求超出了服务器的等待时间。

409 Conflict

因为冲突，请求没法被完成。

410 Gone

被请求的页面不可用。

411 Length Required

"Content-Length" 未被定义。若是无此内容，服务器不会接受请求。

412 Precondition Failed

请求中的前提条件被服务器评估为失败。

413 Request Entity Too Large

因为所请求的实体的太大，服务器不会接受请求。

414 Request-url Too Long

因为url太长，服务器不会接受请求。当post请求被转换为带有很长的查询信息的get请求时，就会发生这种状况。

415 Unsupported Media Type

因为媒介类型不被支持，服务器不会接受请求。

416 Requested Range Not Satisfiable

服务器不能知足客户在请求中指定的Range头。

417 Expectation Failed

执行失败。

423

锁定的错误。

消息

描述

500 Internal Server Error

请求未完成。服务器遇到不可预知的状况。

500.12

应用程序正忙于在 Web 服务器上从新启动。

500.13

Web 服务器太忙。

500.15

不容许直接请求 Global.asa。

500.16

UNC 受权凭据不正确。这个错误代码为 IIS 6.0 所专用。

500.18

URL 受权存储不能打开。这个错误代码为 IIS 6.0 所专用。

500.100

内部 ASP 错误。

501 Not Implemented

请求未完成。服务器不支持所请求的功能。

502 Bad Gateway

请求未完成。服务器从上游服务器收到一个无效的响应。

502.1

CGI 应用程序超时。　·

502.2

CGI 应用程序出错。

503 Service Unavailable

请求未完成。服务器临时过载或当机。

504 Gateway Timeout

网关超时。

505 HTTP Version Not Supported

服务器不支持请求中指明的HTTP协议版本。

十二、HTTP 报文实体

12.1HTTP 报文实体概述

 

 

你们请仔细看看上面示例中，各个组成部分对应的内容。

接着，咱们来看看报文和实体的概念。若是把 HTTP 报文想象成因特网货运系统中的箱子，那么 HTTP 实体就是报文中实际的货物。

报文：是网络中交换和传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，其长短很不一致，长度不限且可变；

实体：做为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。（实体首部相关内容在上面第六点中已有阐述。）

咱们能够看到，上面示例右图中深红色框的内容就是报文的实体部分，而蓝色框的两部份内容分别就是实体首部和实体主体。而左图中粉红框内容就是报文主体。

一般，报文主体等于实体主体。只有当传输中进行编码操做时，实体主体的内容发生变化，才致使它和报文主体产生差别。

12.2内容编码

HTTP 应用程序有时在发送以前须要对内容进行编码。例如，在把很大的 HTML 文档发送给经过慢速链接上来的客户端以前，服务器可能会对其进行压缩，这样有助于减小传输实体的时间。服务器还能够把内容搅乱或加密，以此来防止未受权的第三方看到文档的内容。

这种类型的编码是在发送方应用到内容之上的。当内容通过内容编码后，编好码的数据就放在实体主体中，像往常同样发送给接收方。

内容编码类型：

 

 

12.3传输编码

内容编码是对报文的主体进行的可逆变换，是和内容的具体格式细节紧密相关的。

传输编码也是做用在实体主体上的可逆变换，但使用它们是因为架构方面的缘由，同内容的格式无关。使用传输编码是为了改变报文中的数据在网络上传输的方式。

 

 

12.4分块编码

分块编码把报文分割成若干已知大小的块。块之间是紧挨着发送的，这样就不须要在发送以前知道整个报文的大小了。分块编码是一种传输编码，是报文的属性。

若客户端与服务器端之间不是持久链接，客户端就不须要知道它在读取的主体的长度，而只须要读取到服务器关闭主体链接为止。

当使用持久链接时，在服务器写主体以前，必须知道它的大小并在 Content-Length 首部中发送。若是服务器动态建立内容，就可能在发送以前没法知道主体的长度。

分块编码为这种困难提供了解决方案，只要容许服务器把主体分块发送，说明每块的大小就能够了。由于主体是动态建立的，服务器能够缓冲它的一部分，发送其大小和相应的块，而后在主体发送完以前重复这个过程。服务器能够用大小为 0 的块做为主体结束的信号，这样就能够继续保持链接，为下一个响应作准备。

来看看一个分块编码的报文示例：

 

 

12.5多部分媒体类型

MIME 中的 multipart（多部分）电子邮件报文中包含多个报文，它们合在一块儿做为单一的复杂报文发送。每一部分都是独立的，有各自的描述其内容的集，不一样部分之间用分界字符串链接在一块儿。

相应得，HTTP 协议中也采纳了多部分对象集合，发送的一份报文主体内可包含多种类型实体。

多部分对象集合包含的对象以下：

multipart/form-data：在 Web 表单文件上传时使用；

multipart/byteranges：状态码 206 Partial Content 响应报文包含了多个范围的内容时使用。

12.6范围请求

假设你正在下载一个很大的文件，已经下了四分之三，突然网络中断了，那下载就必须重头再来一遍。为了解决这个问题，须要一种可恢复的机制，即能从以前下载中断处恢复下载。要实现该功能，这就要用到范围请求。

有了范围请求， HTTP 客户端能够经过请求曾获取失败的实体的一个范围（或者说一部分），来恢复下载该实体。固然这有一个前提，那就是从客户端上一次请求该实体到这一次发出范围请求的时间段内，该对象没有改变过。例如：

GET  /bigfile.html  HTTP/1.1

Host: [url=http://www.sample.com]www.sample.com[/url]

Range: bytes=20224-

···

 

 

上面示例中，客户端请求的是文档开头20224字节以后的部分。

1三、与 HTTP 协做的 Web 服务器

HTTP 通讯时，除客户端和服务器外，还有一些用于协助通讯的应用程序。以下列出比较重要的几个：代理、缓存、网关、隧道、Agent 代理。

13.1代理

 

 

HTTP 代理服务器是 Web 安全、应用集成以及性能优化的重要组成模块。代理位于客户端和服务器端之间，接收客户端全部的 HTTP 请求，并将这些请求转发给服务器（可能会对请求进行修改以后再进行转发）。对用户来讲，这些应用程序就是一个代理，表明用户访问服务器。

出于安全考虑，一般会将代理做为转发全部 Web 流量的可信任中间节点使用。代理还能够对请求和响应进行过滤，安全上网或绿色上网。

13.2缓存

浏览器第一次请求：

 

 

浏览器再次请求：

 

 

Web 缓存或代理缓存是一种特殊的 HTTP 代理服务器，能够将通过代理传输的经常使用文档复制保存起来。下一个请求同一文档的客户端就能够享受缓存的私有副本所提供的服务了。客户端从附近的缓存下载文档会比从远程 Web 服务器下载快得多。

13.3网关

 

 

网关是一种特殊的服务器，做为其余服务器的中间实体使用。一般用于将 HTTP 流量转换成其余的协议。网关接收请求时就好像本身是资源的源服务器同样。客户端可能并不知道本身正在跟一个网关进行通讯。

13.4隧道

 

 

隧道是会在创建起来以后，就会在两条链接之间对原始数据进行盲转发的 HTTP 应用程序。HTTP 隧道一般用来在一条或多条 HTTP 链接上转发非 HTTP 数据，转发时不会窥探数据。

HTTP 隧道的一种常见用途就是经过 HTTP 链接承载加密的安全套接字层（SSL）流量，这样 SSL 流量就能够穿过只容许 Web 流量经过的防火墙了。

13.5Agent 代理

 

 

Agent 代理是表明用户发起 HTTP 请求的客户端应用程序。全部发布 Web 请求的应用程序都是 HTTP Agent 代理。

（原文连接：https://www.jianshu.com/p/6e9e4156ece3）

附录：更多网络编程资料

《技术往事：改变世界的TCP/IP协议（珍贵多图、手机慎点）》

《UDP中一个包的大小最大能多大？》

《Java新一代网络编程模型AIO原理及Linux系统AIO介绍》

《NIO框架入门(一)：服务端基于Netty4的UDP双向通讯Demo演示》

《NIO框架入门(二)：服务端基于MINA2的UDP双向通讯Demo演示》

《NIO框架入门(三)：iOS与MINA二、Netty4的跨平台UDP双向通讯实战》

《NIO框架入门(四)：Android与MINA二、Netty4的跨平台UDP双向通讯实战》

《P2P技术详解(一)：NAT详解——详细原理、P2P简介》

《P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解》

《P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解》

《通俗易懂：快速理解P2P技术中的NAT穿透原理》

>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-1677-1-1.html）