一、什么是HTTP？
超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是互联网上应用最为广泛的一种网络协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。
HTTP的发展是万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，其中最著名的RFC 2616，定义了HTTP协议中现今广泛使用的一个版本—HTTP 1.1。
二、协议概述
HTTP协议（HyperText Transfer Protocol，超文本转移协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等
HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。
通常，一次Web请求的基本过程：
建立连接→接收请求→处理请求→访问资源→构建响应→发送响应→记录日志
由HTTP客户端发起一个请求，创建一个到服务器指定端口（默认是80端口）的TCP连接。HTTP服务器则在那个端口监听客户端的请求。一旦收到请 求，服务器会向客户端返回一个状态，比如"HTTP/1.1 200 OK"，以及返回的内容，如请求的文件、错误消息、或者其它信息。
HTTP协议的主要特点可概括如下：
1)支持客户/服务器模式。支持基本认证和安全认证。
2)简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3)无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
三、HTTP协议版本
超文本传输协议已经演化出了很多版本，它们中的大部分都是向下兼容的。在RFC 2145中描述了HTTP版本号的用法。客户端在请求的开始告诉服务器它采用的协议版本号，而后者则在响应中采用相同或者更早的协议版本。
HTTP/0.9
诞生于1991，仅用于传输html文档，已过时。只接受GET一种请求方法，没有在通讯中指定版本号，且不支持请求头。由于该版本不支持POST方法，因此客户端无法向服务器传递太多信息
HTTP/1.0
这是第一个在通讯中指定版本号的HTTP协议版本，至今仍被广泛采用，特别是在代理服务器中。支持多媒体数据的处理，keep-alive(保持连接)，有缓存功能
HTTP/1.1
当前版本。持久连接被默认采用，并能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。更多的请求方法，更精细的缓存控制，持久连接
HTTP/1.1相较于HTTP/1.0协议的区别主要体现在：
·缓存处理
·带宽优化及网络连接的使用
·错误通知的管理
·消息在网络中的发送
·互联网地址的维护
·安全性及完整性
MIME: Multipurpose Internet Mail Extension
base64: 将二进制数据编码成文本发送，并能够让接收方还原回原来的格式；
四、HTTP报文：
HTTP事务：一次请求以及与其对应的响应的过程
HTTP请求：request
HTTP请求报文
报文格式：
<method> <request-URL> <version>
<headers>
<entity-body>
HTTP响应：response
HTTP响应报文
报文格式：
<version> <status> <reason-phrase>
<headers>
<entity-body>
其中：
<method>: 请求方法，希望服务器端执行的动作，如GET、HEAD、POST等
<request-url>: 请求的资源，可以是相对路径，也是完整的URL
<version>：协议版本，格式HTTP/<major>.<minor>，如http/1.0
<headers>：HTTP首部
<status>: 状态码
<reason-phrase>：原因短语，数字状态码易读信息
<entity-body>: 主体部分
请求方法<method>
HTTP/1.1协议*定义了八种方法（也叫“动作”）来以不同方式操作指定的资源：
GET：向指定的资源发出“显示”请求；需要服务器发送；
HEAD：跟GET相似，但其不需要服务发送资源而仅传回响应首部
POST：向指定资源提交数据，支持HTML表单提交，表单中有用户填入的数据，这些数据会发送到服务器端，由服务器存储至某位置（例如发送处理程序）。
PUT：与GET相反，向服务写入文档；例如发布系统
DELETE：请求服务器删除Request-URI所标识的资源。
OPTIONS：探测服务器端对某资源所支持的请求方法
TRACE：回显服务器收到的请求，主要用于测试或诊断。
CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。
方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed），当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。
HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。例如：
PATCH（由RFC5789指定的方法）:用于将局部修改应用到资源。
除了以上八种方法外还有其他扩展方法：LOCK、MKCOL、COPY、MOVE
HTTP状态码<status>:
|
状态码 |
状态码英文名称 |
中文描述 |
|---|---|---|
| 1XX：信息性状态码 | ||
|
100 |
Continue |
继续。客户端应继续其请求 |
|
101 |
Switching Protocols |
切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 2xx：成功状态码 | ||
|
200 |
OK |
请求成功。一般用于GET与POST请求 |
|
201 |
Created |
已创建。成功请求并创建了新的资源 |
|
202 |
Accepted |
已接受。已经接受请求，但未处理完成 |
|
203 |
Non-Authoritative Information |
非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
|
204 |
No Content |
无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
|
205 |
Reset Content |
重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
|
206 |
Partial Content |
部分内容。服务器成功处理了部分GET请求 |
| 3XX：重定向状态码 | ||
|
300 |
Multiple Choices |
多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
|
301 |
Moved Permanently |
永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
|
302 |
Found |
临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
|
303 |
See Other |
查看其它地址。与301类似。使用GET和POST请求查看 |
|
304 |
Not Modified |
未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
|
305 |
Use Proxy |
使用代理。所请求的资源必须通过代理访问 |
|
306 |
Unused |
已经被废弃的HTTP状态码 |
|
307 |
Temporary Redirect |
临时重定向。与302类似。使用GET请求重定向 |
| 4XX：客户端类的错误 | ||
|
400 |
Bad Request |
客户端请求的语法错误，服务器无法理解 |
|
401 |
Unauthorized |
请求要求用户的身份认证 |
|
402 |
Payment Required |
保留，将来使用 |
|
403 |
Forbidden |
服务器理解请求客户端的请求，但是拒绝执行此请求 |
|
404 |
Not Found |
服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
|
405 |
Method Not Allowed |
客户端请求中的方法被禁止 |
|
406 |
Not Acceptable |
服务器无法根据客户端请求的内容特性完成请求 |
|
407 |
Proxy Authentication Required |
请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
|
408 |
Request Time-out |
服务器等待客户端发送的请求时间过长，超时 |
|
409 |
Conflict |
服务器完成客户端的PUT请求时可能返回此代码，服务器处理请求时发生了冲突 |
|
410 |
Gone |
客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
|
411 |
Length Required |
服务器无法处理客户端发送的不带Content-Length的请求信息 |
|
412 |
Precondition Failed |
客户端请求信息的先决条件错误 |
|
413 |
Request Entity Too Large |
由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
|
414 |
Request-URI Too Large |
请求的URI过长（URI通常为网址），服务器无法处理 |
|
415 |
Unsupported Media Type |
服务器无法处理请求附带的媒体格式 |
|
416 |
Requested range not satisfiable |
客户端请求的范围无效 |
|
417 |
Expectation Failed |
服务器无法满足Expect的请求头信息 |
| 5XX：服务器类的错误 | ||
|
500 |
Internal Server Error |
服务器内部错误，无法完成请求 |
|
501 |
Not Implemented |
服务器不支持请求的功能，无法完成请求 |
|
502 |
Bad Gateway |
充当网关或代理的服务器，从远端服务器接收到了一个无效的请求 |
|
503 |
Service Unavailable |
由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
|
504 |
Gateway Time-out |
充当网关或代理的服务器，未及时从远端服务器获取请求 |
|
505 |
HTTP Version not supported |
服务器不支持请求的HTTP协议的版本，无法完成处理 |
HTTP首部：<headers>：
Name: Value
如：Content-type: images/gif
分为以下几类：
通用首部：请求和响应都可以使用的；
请求首部：
响应首部：
实体首部：用于指定实体属性
扩展首部：非标准首部，可能是由程序开发者创建的，例如X-Forward-For
通用首部：
Connection：定义C/S之间关于请求/响应的有关选项
对于http/1.0, Connection: keep-alive
Via: 显示了报文经过的中间节点
Cache-Control: 缓存指示
Pragma
请求首部：
Client-IP:
Host: 请求的主机名和端口号，虚拟主机环境下用于不同的虚拟主机
Referer：指明了请求当前资源的原始资源的URL
User-Agent: 用户代理，使用什么工具发出的请求
Accept首部：用户标明客户自己更倾向于支持的能力
Accept: 指明服务器能发送的媒体类型
Accept-Charset: 支持使用的字符集
Accept-Encoding: 支持使用的编码方式
Accept-Language: 支持使用语言
条件请求首部：
Expect:
If-Modified-Since: 是否在指定时间以来修改过此资源
If-None-Match
跟安全相关的请求首部：
Authorization: 客户端提交给服务端的认证数据，如帐号和密码
Cookie: 客户端发送给服务器端身份标识
Cookie2
响应首部：
Age:
Server: 向客户端标明服务器程序名称和版本
协商首部：
Accept-Ranges: 对当前资源来讲，服务器所能够接受的范围类型
Vary: 首部列表，服务器会根据列表中的内容挑选出最适合的版本发送给客户端
跟安全相关的响应首部：
Set-Cookie: 服务器端在某客户端第一次请求时发给令牌
Set-Cookie2:
WWW-Authentication: 质询，即要求客户提供帐号和密码
实体首部：
Location: 资源的新位置
Allow: 允许对此资源使用的请求方法
内容首部：
Content-Encoding
Content-Language
Content-Length
Content-Location
Content-Range
Content-Type
缓存首部：
ETag: 实体标签
Expires: 过期期限
Last-Modified: 上一次的修改时间
五、HTTPS
目前有两种方法来创建安全超文本协议连接：HTTPS URI方案和HTTP 1.1请求头（由RFC2817引入）。由于浏览器对后者的几乎没有任何支持，因此HTTPS URI方案仍是创建安全超文本协议连接的主要手段。安全超文本连接协议使用https://代替http://
安全方法
对于GET和HEAD方法而言，除了进行获取资源信息外，这些请求不应当再有其他意义。也就是说，这些方法应当被认为是“安全的”。客户端可能会使用其他“非安全”方法，例如POST，PUT及DELETE，应该以特殊的方式（通常是按钮而不是超链接）告知客户可能的后果（例如一个按钮控制的资金交易），或请求的操作可能是不安全的（例如某个文件将被上传或删除）。
但是，不能想当然地认为服务器在处理某个GET请求时不会产生任何副作用。事实上，很多动态资源会把这作为其特性。这里重要的区别在于用户并没有请求这一副作用，因此不应由用户为这些副作用承担责任。
副作用
假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视作“幂等”的。 GET，HEAD，PUT和DELETE方法都有这样的幂等属性，同样由于根据协议，OPTIONS，TRACE都不应有副作用，因此也理所当然也是幂等 的。
假 如某个由若干个请求做成的请求串行产生的结果在重复执行这个请求串行或者其中任何一个或多个请求后仍没有发生变化，则这个请求串行便是“幂等”的。但是，可能出现若干个请求做成的请求串行是“非幂等”的，即使这个请求串行中所有执行的请求方法都是幂等的。例如，这个请求串行的结果依赖于某个会在下次执行这 个串行的过程中被修改的变量。
六、持续连接
在 HTTP 0.9和1.0使用非持续连接，在非持续连接下，每个tcp只连接一个web对象，连接在每个请求-回应对后都会关闭，一个连接可被多个请求重 复利用的保持连接机制被引入。这种连接持续化显著地减少了请求延迟，因为客户不用在首次请求后再次进行TCP交互确认创建连接。现在在HTTP 1.1使用持续连接，不必为每个web对象创建一个新的连接，一个连接可以传送多个对象。 HTTP1.1还进行了带宽优化，例如1.1引入了分块传输编码来允许流化传输持续连接上发送的内容，取代原先的buffer式传输。HTTP管道允许客户在上一个回应被收到前发送多重请求从而进一步减少了延迟时间。
另一项协议的改进是byte serving（字节服务），允许服务器根据客户的请求仅仅传输资源的一部分。
七、HTTP协议例子：
下面是一个我通过浏览器自带的开发工具HTTP客户端与服务器之间会话的例子，运行于www.google.com，端口80
客户端请求报文：
|
1
2
3
4
5
6
7
8
|
GET / HTTP/1.1
Host: www.google.com.hkUser-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3Accept-Encoding: gzip, deflate
Cookie: PREF=ID=1737e66a16d71100:U=18298c26ad246c7f:FF=1:LD=zh-CN:NW=1:TM=1392034889:LM=1395146306:GM=1:S=oDsIzDBU1QId5BJy; NID=67=q2AFerfuDoSCSUYh8cLAHL3bJTcwBl0TF9COVot2bYGOUdauofGqlCr9eVtH68IOhIsggtl9bYk2k4O94fqhAW3pCSKTqA5aGqowV0u9ymWksMy8Fjd0KIsvEgXaroa7; OGPC=270001-1:Connection: keep-alive |
服务器应答报文：
|
1
2
3
4
5
6
7
8
9
10
11
|
HTTP/1.1 200 OK
Alternate-Protocol: 443:quicCache-Control: private, max-age=0Content-Encoding: gzip
Content-Type: text/html; charset=UTF-8
Date: Wed, 19 Mar 2014 05:35:06 GMTExpires: -1Server: gwsX-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockX-Firefox-Spdy: 3.1 |
在HTTP1.0，单一TCP连接内仅执行一个“客户端发送请求—服务器发送应答”周期，之后释放TCP连接。在HTTP1.1优化支持持续活跃连接：客户端连续多次发送请求、接收应答；批量多请求时，同一TCP连接在活跃（Keep-Live）间期内复用，避免重复TCP初始握手活动，减少网络负荷和响应周期。此外支持应答到达前继续发送请求（通常是两个），称为“流线化”（stream）。