3.
HTTP报文：
用于HTTP协议交互的信息被称为HTTP报文。分为请求报文和响应报文。
报文本身是由多行（用CR+LF作换行符）数据构成的字符串文本。
HTTP报文大致可分为报文首部和报文主体两块。两者由最初出现的空行（CR+LF）来划分。通常，并不一定要有报文主体。
请求行：
包含用于请求的方法，请求URI和HTTP版本。如：GET/HTTP/1.1
状态行：
包含表明响应结果的状态码，原因短语和HTTP版本。如：HTTP/1.1 200 OK
首部字段：
包含表示请求和响应的各种条件和属性的各类首部。
一般有4种首部，分别是：通用首部、请求首部、响应首部和实体首部。
其它：
可能包含HTTP的RFC里定义的首部（Cookie等）。
编码提升传输速率：
HTTP在传输数据时可以按照数据原貌直接传输，但也可以在传输过程中通过编码提升传输速率。在传输时编码，能有效地处理大量的访问请求。但是，编码的操作需要计算机来完成，因此会消耗更多的CPU等资源。
报文：
HTTP通信中的基本单位，由8位字节流组成，通过HTTP通信传输。
实体：
作为请求或响应的有效载荷数据（补充项）被传输，其内容由实体首部和实体主体组成。
HTTP报文的主体用于传输请求或响应的实体主体。
通常报文主体等于实体主体，但当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。
压缩传输的内容编码：
向待发送邮件内增加附件时，为了使邮件容量变小，我们会先用ZIP压缩文件之后再添加附件发送。HTTP协议中有一种被称为内容编码的功能也能进行类似的操作。
内容编码指明应用在实体内容上的编码格式，并保持实体信息原样压缩。内容编码后的实体由客户端接收并负责解码。
常用的内容编码有以下几种：
gzip（GNU zip）、compress（UNIX系统的标准压缩）、deflate（zlib）、identity（不进行编码）
分割发送的分块传输编码：
在HTTP通信过程中，请求的编码实体资源尚未全部传输完成之前，浏览器无法显示请求页面。在传输大容量数据时，通过把数据分割成多块，能够让浏览器逐步显示页面。
这种把实体主体分块的功能称为分块传输编码（Chunked Transfer Coding）。
分块传输将实体主体分成多个部分（块），每一块都会用十六进制来标记块的大小，而实体主体的最后一块会使用“0(CR+LF)”来标记。
使用分块传输编码的实体主体会由接收的客户端负责解码，恢复到编码前的实体主体。
HTTP/1.1中存在一种称为传输编码（Transfer Coding）的机制，它可以在通信时按某种编码方式传输，但只定义作用于分块传输编码中。
发送多种数据的多部分对象集合：
类似于邮件中的MIME协议，它允许邮件处理文本、图片、视频等多个不同类型的数据。是利用MIME来描述标记数据类型。而在MIME扩展中会使用一种称为多部分对象集合的方法，来容纳多份不同类型的数据。
HTTP协议中也采纳了多部分对象集合，发送的一份报文主体内可含有多类型实体。通常是在图片或文本文件等上传时使用。
多部分对象集合包含的对象如下：
multipart/form-data 在Web表单文件上传时使用。
multipart/byteranges 状态码206（Partial Content，部分内容）响应报文包含了多个范围的内容时使用。
在HTTP报文段中使用多部分对象集合时，需要在首部字段里加上Content-type。
使用boundary字符串来划分多部分对象集合指明的各类实体。在boundary字符指定的各个实体的起始行之前插入“--”标记，而在多部分对象集合对应的字符串的最后插入“--”标记作为结束。
多部分对象集合的每个部分类型中，都可以含有首部字段。另外，可以在某个部分中嵌套使用多部分对象集合。
获取部分内容的范围请求：
以前下载一个较大的图片或文件在低带宽下很慢，而且如果下载过程中断。就必须从头开始。为了解决上述问题，需要一种可恢复的机制。可恢复是指能从下载中断处恢复下载。
要实现该功能需要指定下载的实体范围。像这样，指定范围发送的请求叫做范围请求Range Request。
在首部中使用Range字段：
Range:bytes=5001-10000
Range:bytes=5001-
Range:bytes=-3000,5000-7000 //从一开始到3000字节，从5000到7000字节。
内容协商返回最合适的内容：
同一个Web网站有可能存在着多份相同内容的页面。比如英文版和中文版的Web页面，它们内容上虽相同，但使用的语言不同。
当浏览器的默认语言为英语或中文，访问相同URI的Web页面时，则会显示对应的英语版或中文版的Web页面。这样的机制称为内容协商（Content Negotiation）。
内容协商机制是指客户端和服务器端就响应的资源内容进行交涉，然后提供给客户端最为合适的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的基准。
包含在请求报文中的某些首部字段就是判断的基准。
Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language
内容协商技术有以下3种类型。
服务器驱动协商（Server-driven Negotiation）：
由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。但对用户来说，以浏览器发送的信息作为判定的依据，并不一定能筛选出最优内容。
客户端驱动协商（Agent-driven Negotiation）：
由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用JavaScript脚本在Web页面上自动进行上述选择。比如按OS类型或浏览器类型，自行切换成PC版页面或手机版页面。
透明协商（Transparent Negotiation）：
是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。
4.
返回结果的HTTP状态码
HTTP状态码负责表示客户端HTTP请求的返回结果、标记服务器端的处理是否正常、通知出现的错误等工作。
状态码的职责是当客户端向服务器发送请求时，描述返回的请求结果。借助状态码，用户可以知道服务器是正常处理了请求，还是出现了错误。
状态码由3位数字和原因短语组成。如：200 OK
数字中的第一位指定了响应类别，后两位无分类。
响应类别有以下5种：
| 类别 | 原因短语 | |
| 1XX | Informational（信息性状态码） | 接收的请求正在处理 |
| 2XX | Success（成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection（重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error（客户端错误状态码） | 服务器无法处理请求 |
| 5XX | Server Error（服务器错误状态码） | 服务器处理请求出错 |
2XX成功：
2XX的响应结果表明请求被正常处理了。
200 OK：表示从客户端发来的请求在服务端被正常处理了。
204 No Content：该状态码代表服务器接收的请求已成功处理，但在返回的响应报文中不含实体的主体部分。另外，也不允许返回任何实体的主体。没有资源可以返回。
206 Partial Content：该状态码表示客户端进行了范围请求，而服务器成功执行了这部分的GET请求。响应报文中包含由Content-Range指定范围的实体内容。
3XX重定向：
3XX响应结果表明浏览器需要执行某些特殊的处理以正确处理请求。
301 Moved Permanently：永久性重定向。该状态码表示请求的资源已被分配了新的URI，以后应使用资源现在所指的URI。也就是说，如果已经把资源对应的URI保存为书签了，这时应该按Location首部字段提示的URI重新保存。
302 Found：临时性重定向。该状态码表示请求的资源已被分配了新的URI。希望用户（本次）能使用新的URI访问。
此时资源只是临时移动，URI将来或许还会改变。比如，如果用户把URI保存为书签，但不会像301状态码出现时那样去更新书签，而是仍旧保留返回302状态码的页面对应的URI。
303 See Other：该状态码表示由于请求对应的资源存在着另一个URI，应使用GET方法定向获取请求的资源。
304 Not Modified：该状态码表示客户端发送附带条件的请求时。服务器允许请求访问资源，但未满足条件的情况。304状态码返回时，不包含任何响应的主体部分。304虽然被划分在3XX类别中，但和重定向没有关系。
307 Temporary Redirect：临时重定向，该状态码与302 Found有着相同的含义。尽管302标准禁止POST变换成GET，但实际使用时大家并不遵守。307会遵照浏览器标准，不会从POST变成GET。但是，对于处理响应时的行为，每种浏览器有可能出现不同的情况。
4XX客户端错误：
4XX的响应结果表明客户端是发生错误的原因所在。
400 Bad Request：该状态码表示请求报文中存在语法错误。当错误发生时，需修改请求的内容后再次发送请求。另外，浏览器会像200 OK一样对待该状态码。
401 Unauthorized：该状态码表示发送的请求需要通过HTTP认证（BASIC认证、DIGEST认证）的认证信息。另外若之前已进行过一次请求，则表示用户认证失败。
返回含有401的响应必须包含一个适用于被请求资源的WWW-Authenticate首部用以质询用户信息。当浏览器初次接收到401响应，会弹出认证用的对话窗口。
403 Forbidden：该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要给出拒绝的详细理由，但如果想作说明的话，可以在实体的主体部分对原因进行描述，这样就能让用户看到了。
未获得文件系统的访问授权，访问权限出现某些问题（从未授权的发送源IP地址试图访问）等列举的情况都可能是发生403的原因。
404 Not Found：该状态码表明服务器上无法找到请求的资源。除此之外，也可以在服务器端拒绝请求且不想说明理由时使用。
5XX服务器错误：
5XX的响应结果表明服务器本身发生错误。
500 Internal Server Error：该状态码表明服务端在执行请求时发生了错误。也有可能是Web应用存在的bug或某些临时故障。
503 Service Unavaliable：该状态码表明服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。如果事先得知解除以上状况需要的时间，最好写入Retry-After首部字段再返回给客户端。