HTTP学习笔记

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。著名的RFC 2616定义了HTTP 1.1。

HTTP是一个客户端和服务器端请求和应答的标准（C/S模式），

HTTP是TCP/IP模型中应用层上的协议，端口号为80（其安全协议HTTPS端口号为443），采用的是TCP传输协议（实际上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。）

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

1、HTTP请求格式

HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。请求报文格式如下：

请求行

若干消息头

空行

实体内容

一个HTTP请求的示例：

GET /mailtest/1.html HTTP/1.1  （请求行）

Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Accept-Language: zh-CN

User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; InfoPath.3)

UA-CPU: AMD64

Accept-Encoding: gzip, deflate

If-Modified-Since: Fri, 15 Jan 2016 10:20:34 GMT

If-None-Match: W/"128-1452853234743"

Host: localhost:8080

Connection: Keep-Alive

（空行）

//实体内容可选。

（1）请求行（Request-Line）是以一个方法标记开始，后面跟随 Request-URI 和协议版本（HTTPVersion），最后以 CRLF 结束。元素是以 SP 字符分隔。除了最后的 CRLF，CR 或 LF 是不被允许的。 

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

请求方法Method有：GET,POST,HEAD,OPINIONS,PUT,DELETE,TRACE,CONNECT等，常用的是GET和POST，其中GET是默认的方法，可以携带少量数据，一般不超过1K，用于打开网页（地址访问和超链接等），POST主要用于上传和下载大量数据，通信的数据量无限制。

（2）消息头

消息头域允许客户端传递请求的附加信息和客户端自己的附加信息给服务器。常用的HTTP请求头如下：

1.Accept：Accept 请求头域被用于指定哪些媒体类型的响应对请求端是可接受的

2.Accept-Charset：Accept-Charset 请求头域可以用来指名哪些字符集的响应对请求端是可接受的。

3.Accept-Encoding：和 Accept 头域相似，但 Accept-Encoding 是限定服务器返回给客户端可以接受的内容编码（content-coding。

4.Accept-Language ：它是限定服务器返回给客户端喜爱的自然语言。

5.Host ：指明了请求资源的网络主机和端口号

6.If-Modified-Since ：用来让方法成为条件方法：如果请求变量（variant）自从此头域里指定的时间之后没有改变，那么服务器不应该返回实体；而是应该以 304（没有改变）状态码进行响应，同时返回的消息不需要消息主体（message-body）。

7.Referer ：允许客户端，为了让服务器受益，指定请求 URI 来源的资源 URI。（资源防盗链，本网站的资源可以通过此头域设置为只能通过本网站的首页访问。）

8.User-Agent ：包含关于发起请求的用户代理的信息。

9.Connection ：允许发送者指定某些专属于某特定连接的选项，并且 Connection 头域不能被代理（proxy）在以后的连接中传送。

10.Date ：表明产生消息的日期和时间

2、HTTP响应

接收和解析一个请求消息后，服务器发出一个 HTTP 响应消息。其组成为：一个状态行、若干消息头、空行以及实体内容。

一个HTTP响应的示例：

HTTP/1.1 304 Not Modified

Server: Apache-Coyote/1.1

ETag: W/"128-1452853234743"

Date: Tue, 19 Jan 2016 03:39:45 GMT

（1）状态行

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

HTTP状态码如下：

总体看：

100-199 这一类型的状态码，代表请求已被接受，需要继续处理。这类响应是临时响应，只包含状态行和某些可选的响应头信息，并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。

200-299 这一类型的状态码，代表请求已成功被服务器接收、理解、并接受

300-399 这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。

400-499 这类的状态码代表了客户端看起来可能发生了错误，妨碍了服务器的处理。除非响应的是一个 HEAD 请求，否则服务器就应该返回一个解释当前错误状况的实体，以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。

500-599 这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求，否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。

"100" ; 10.1.1 节:  继续

|"101" ; 10.1.2 节:  转换协议 

|"200" ; 10.2.1 节: OK 

|"201" ; 10.2.2 节:  已创建 

|"202" ; 10.2.3 节:  接受

|"203" ; 10.2.4 节: 非权威信息 

|"204" ; 10.2.5 节:  无内容

|"205" ; 10.2.6 节:  重置内容

|"206" ; 10.2.7 节:  部分内容

|"300" ; 10.3.1 节:  多个选择

|"301" ; 10.3.2 节:  永久移动

|"302" ; 10.3.3 节:  发现 

|"303" ; 10.3.4 节:  见其它 

|"304" ; 10.3.5 节:  没有被改变

|"305" ; 10.3.6 节:  使用代理 

|"307" ; 10.3.8 节  临时重发 

|"400" ; 10.4.1 节:  坏请求 

|"401" ; 10.4.2 节:  未授权的 

|"402" ; 10.4.3 节:  必要的支付

|"403" ; 10.4.4 节:  禁用 

|"404" ; 10.4.5 节:  没有找到 

|"405" ; 10.4.6 节:  方式不被允许 

|"406" ; 10.4.7 节:  不接受的 

|"407" ; 10.4.8 节:  需要代理验证

|"408" ; 10.4.9 节： 请求超时 

|"409" ; 10.4.10 节； 冲突

|"410" ; 10.4.11 节： 不存在 

|"411" ; 10.4.12 节： 长度必需 

|"412"  ；  10.4.13 节；先决条件失败

|"413" ; 10.4.14 节： 请求实体太大

|"414" ; 10.4.15 节；请求 URI 太大

|"415" ; 10.4.16 节： 不被支持的媒体类型

|"416"  ；  10.4.17 节： 请求的范围不满足

|"417" ; 10.4.18 节： 期望失败

|"500" ; 10.5.1 节:  服务器内部错误 

|"501" ; 10.5.2 节:  不能实现 

|"502" ; 10.5.3 节:  坏网关 

|"503" ; 10.5.4 节:  服务不能获得 

|"504" ; 10.5.5 节:  网关超时 

|"505" ; 10.5.6 节: HTTP 版本不支持 

（2）常用HTTP响应头

1.Location 响应头域被用于为了完成请求或识别一个新资源，使接收者能重定向于 Location 指明的 URI 而不是请求 URI。

2.Server 响应头域包含了源服务器用于处理请求的软件信息。

3.“Content-Encoding”实体头域是对媒体类型的修饰。当此头域出现时，其值表明对实体主体采用了何种内容编码，从而可以知道采用何种解码机制以获取 Content-Type 头域中指出的媒体类型。 Content-Encoding 头域主要目的是可以在不丢失下层媒体类型的标识下对文档进行压缩。

4.Content-Length 实体头域用于指明发送给接收者实体主体（entity-bidy）的大小（以十进制的字节数表示），或是在使用 HEAD 方法时，指明实体主体本应在 GET 方法时发送实体主体的大小。 

5.Content-Type 实体头域指明发给接收者的实体主体的媒体类型，或在 HEAD 方法中指明若请求为 GET 时将发送的媒体类型。 

6.Last-Modified 实体头域（entity-header）指定了变量（variant）被源服务器所确信的最后修改的日期和时间。

7.Refresh，隔多长时间刷新一次

8.Content-Disposition，设置下载

9.传输译码（Transfer-Encoding）常用头域指示了消息主体（message body）的编码转换，这是为了实现在接收端和发送端之间的安全数据传输。它不同于内容编码（content-coding），传输代码是消息的属性，而不是实体（entity）的属性。

10.ETAG 实体标签可用于比较来自同一资源的不同实体。

11.Expires 实体头域（entity-header）给出了在何时之后响应即被视为陈旧的。一个陈旧的缓存项不能被缓存（一个代理缓存或一个用户代理的缓存）返回给客户端，除非此缓存项被源服务器（或者被一个拥有实体的保鲜副本的中间缓存）验证。

12.Cache-Control 常用头域被用于指定必须在请求/响应链上的被所有缓存机制遵守指令。这些指令指定了防止缓存去干涉请求或响应的行为。这些指令经常覆盖缺省的缓存算法。缓存指令是单方向的，因为请求中指令的存在并不意味着同样的指令必须在响应中出现。 

13.Pragma 常用头域被用于包含特定执行指令，这些指令可能被应用于请求/响应链中任何接收者。从协议的观点来看，pragma 指令指定的行为是可选的；然而，一些系统可能要求行为必须满足指令的要求。当 no-cache 指令出现在请求消息中，应用程序应该转发（forward）此请求到源服务器，即使它拥有此请求响应的缓存副本。