HTTP 在网络协议中的位置
通常HTTP是在TCP层协议之上，默认的 HTTP 端口是80。可当它在TLS或者SSL协议层之上的时候，就是我们常说的 HTTPS了，默认的端口为443. 注意这里说的是“通常”，如同能在TLS或者SSL之上一样，HTTP并没有规定必须使用TCP协议。其实是可以使用其他协议的，比如 UDP (User Datagram Protocol) . Ok ，那么为什么不使用 UDP 呢？
HTTP 如何工作
总的来说，HTTP协议永远都是客户端发起请求，服务器回送响应。无法实现在客户端没有发起请求的时候，服务器将消息推送给客户端. 它是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。一次HTTP操作称为一个事务，其工作过程可分为四步：
1）首先客户机与服务器需要建立连接
比如打开一个网络地址， 比如www.163.com，HTTP开始工作。
这里不能不提到的一个概念是 TCP Three-way Handshake ：
TCP 三次握手, 也不是一两句能说清除的。可以参考这里。
2）建立连接后，客户机发送一个请求给服务器
请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
以下时使用 Firefox 插件 Live HTTP Headers 查看的内容。
1
2
3
4
5
6
7
8
9
10
11
| GET / HTTP/1.1Host: www.163.comUser-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110615 Ubuntu/10.10 (maverick) Firefox/3.6.18Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 115Cookie: wp-settings-1=m7%3Dc%26m5%3Do%26m6%3Dc%26m0%3Dc%26m8%3Dc%26m9%3Do%26hidetb%3D1%26editor%3Dtinymce%26m3%3Dc%26m2%3Do%26m1%3Do%26m4%3Do; wp-settings-time-1=1312254428DNT: 1Connection: keep-alive |
其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
1
2
3
4
5
6
7
8
9
10
| HTTP/1.1 200 OKDate: Fri, 19 Aug 2011 01:17:59 GMTServer: Apache/2.2.19 (Unix) mod_ssl/2.2.19 OpenSSL/0.9.8e-fips-rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_perl/2.0.5 Perl/v5.8.8X-Pingback: www.urdomain.com/xmlrpc.phpX-Powered-By: W3 Total Cache/0.9.2.3Vary: Accept-EncodingKeep-Alive: timeout=5, max=100Connection: Keep-AliveTransfer-Encoding: chunkedContent-Type: text/html; charset=UTF-8 |
如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。
- 1xx消息——请求已被服务器接收，继续处理
- 2xx成功——请求已成功被服务器接收、理解、并接受
- 3xx重定向——需要后续操作才能完成这一请求
- 4xx请求错误——请求含有词法错误或者无法被执行
- 5xx服务器错误——服务器在处理某个正确请求时发生错误
HTTP 请求方法
HTTP/1.1协议中共定义了八种方法（有时也叫“动作”）来表明Request-URI指定的资源的不同操作方式：OPTIONS
返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送’*'的请求来测试服务器的功能性。
HEAD
向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头中的元信息。
GET
向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中。其中一个原因是GET可能会被网络蜘蛛等随意访问。参见安全方法
POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT
向指定资源位置上传其最新内容。
DELETE
请求服务器删除Request-URI所标识的资源。
TRACE
回显服务器收到的请求，主要用于测试或诊断。
CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。
HTTP服务器至少应该实现GET和HEAD方法，其他方法都是可选的。当然，所有的方法支持的实现都应当符合下述的方法各自的语义定义。此外，除了上述方法，特定的HTTP服务器还能够扩展自定义的方法。
持久链接
在 HTTP 0.9和1.0里，TCP链接在每一对 request和response之后就会关闭。 毫无疑问会有延迟的影响。而且对于每个这样的连接，TCP得在客户端和服务器端分配TCP缓冲区，并维持TCP变量。对于有可能同时为来自数百个不同客户 的请求提供服务的web服务器来说，这会严重增加其负担。所以在 HTTP 1.1中增加了 keep-alive-mechanism, 可以让connection再多次request中被重复使用。
Cookie 和 Session
因为HTTP是无状态的，这给我们大量需要保持状态的WEB应用程序带来了麻烦，比如购物车。 Cookie 和 Session 就是这个目的，用来保存客户端状态的机制。 Session可以用Cookie来实现，也可以用URL回写的机制来实现。Cookie 和 Session 有以下明显的不同点：
- Cookie 将状态保存在客户端，Session将状态保存在服务器端
- Cookies 是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器
Session 是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回 给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器。 就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些，因为它不会任意读取客户存储的信息。
HTTPS 图解
从上面的图，已经可以看到，HTTPS就是加上了信息加密的处理。下面这个图已经能很明白的展示了。
关于 数字签名 的概念，请参考 http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html
--------------------------------------------------
HTTP（HyperTextTransferProtocol） 是超文本传输协议的缩写，它用于传送WWW方式的数据，关于HTTP 协议的详细内容请参 考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户 信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以 及可能的实体内容。
通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行， 一个或者多个头域，一个只是头域结束的空行和可 选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域 值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。
通用头域
通用头 域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩 展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。
phperz~com
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消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
php程序员之家
Date头域 Date头域表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
Pragma头域
Pragma头域用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。
请求消息
请求消息的第一行为下面的格式：
Method SP Request-URI SP HTTP-Version CRLF
Method 表 示对于Request-URI完成的方法，这个字段是大小写敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、 TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持，其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。 HEAD方法也是取回由Request-URI标识的信息，只是可以在响应时，不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息，可 以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。
www.phperz.com
SP表示空格。Request-URI遵循URI格式，在此字段为星 号（*）时，说明请求并不用于某个特定的资源地址，而是用于服务器本身。
HTTP- Version表示支持的HTTP版本，例如为HTTP/1.1。
CRLF表 示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加 信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请 求头域，一般将会作为实体头域处理。
典型的请求消息：
GET http://www.phperz.com:80/somedata.exe
Host: download.microtool.de
Accept:*/*
Pragma: no-cache
Cache-Control: no-cache
www.phperz.com
Referer: http://www.phperz.com/ User-Agent:Mozilla/4.04[en](Win95;I;Nav)
Range:bytes=554554-
上例第一行表示HTTP客户端（可能是浏览器、下载程序）通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息，绿色的部分表示通用头部分。
Host头域
Host头域指定请求资源的Intenet主机和端口号，必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
Referer头域
Referer 头域允许客户端指定请求uri的源资源地址，这可以允许服务器生成回退链表，可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被 追踪。如果请求的uri没有自己的uri地址，Referer不能被发送。如果指定的是部分uri地址，则此地址应该是一个相对地址。
Range头域
Range头域可以请求实体的一个或者多个子范围。例如，
表示头500个字节：bytes=0-499
表示第二个500字节：bytes=500-999
表示最后500个字节：bytes=-500 phperz~com
表示500字节以后的范围：bytes=500-
第一个和最后一个字节：bytes=0-0,-1
同时指定几个范围：bytes=500-600,601-999
但是服务器可以忽略此请求头，如果无条件GET包含Range请求头，响应会以状态码206（PartialContent）返回而不是以200 （OK）。
User-Agent头域
User-Agent头域的内容包含发出请求的用户信息。
响应消息
响应消息的第一行为下面的格式：
HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP -Version表示支持的HTTP版本，例如为HTTP/1.1。
Status- Code是一个三个数字的结果代码。
Reason-Phrase给Status-Code提供一个简单的文本描述。
Status-Code主要用于机器自 动识别，Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别，后两个数字没有分类的作用。第一个数字可 能取5个不同的值：
1xx:信息响应类，表示接收到请求并且继续处理
2xx:处理成功响应类，表示动作被成功接收、理解和接受
php程序员站
3xx:重定向响应类，为了完成指定的动作，必须接受进一步处理
4xx:客户端错误，客户请求包含语法错误或者是不能正确执行
5xx:服务端错误，服务器不能正确执行一个正确的请求
响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器的信息和 Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持，如果存在不支持的响应头 域，一般将会作为实体头域处理。
典型的响应消息：
HTTP/1.0200OK
Date:Mon,31Dec200104:25:57GMT
Server:Apache/1.3.14(Unix)
Content-type:text/html
Last-modified:Tue,17Apr200106:46:28GMT
Etag:”a030f020ac7c01:1e9f”
Content-length:39725426
Content-range:bytes554554-40279979/40279980
上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息，绿色的部分表示通用头部分，红色的部分表示实体头域的信息。
php程序员站
Location响应头 Location响应头用于重定向接收者到一个新URI地址。
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定义。
Content-Type实体头
Content-Type实体头用于向接收方指示实体的介质类型，指定HEAD方法送到接收方的实体介质类型，或GET方法发送的请求介质类型 Content-Range实体头 php程序员之家
Content-Range实体头用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：
Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth
例如，传送头500个字节次字段的形式：Content-Range:bytes0- 499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围， Content-Length表示实际传送的字节数。
Last-modified实体头
| 应答头 | 说明 |
| Allow | 服务器支持哪些请求方法（如GET、POST等）。 |
| Content-Encoding | 文 档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的 下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader(“Accept- Encoding”)）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。 |
| Content-Length | 表 示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStram，完成后查看其大小，然后把该值放入Content-Length头，最后通过 byteArrayStream.writeTo(response.getOutputStream()发送内容。 |
| Content-Type | 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentTyep。 www.phperz.com |
| Date | 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。 |
| Expires | 应该在什么时候认为文档已经过期，从而不再缓存它？ |
| Last-Modified | 文 档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档 才会返回，否则返回一个304（Not Modified）状态。Last-Modified也可用setDateHeader方法来设置。 |
| Location | 表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。 |
| Refresh | 表示浏览器应该在多少时间之后刷新文档，以秒计。除了刷新当前文档之外，你还可以通过setHeader(“Refresh”, “5; URL=http://host/path”)让浏览器读取指定的页面。 phperz.com 注 意这种功能通常是通过设置HTML页面HEAD区的＜META HTTP-EQUIV=”Refresh” CONTENT=”5;URL=http://host/path”＞实现，这是因为，自动刷新或重定向对于那些不能使用CGI或Servlet的 HTML编写者十分重要。但是，对于Servlet来说，直接设置Refresh头更加方便。 注意Refresh的意义是“N秒之后 刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面”。因此，连续刷新要求每次都发送一个Refresh头，而发送204状态代码则 可以阻止浏览器继续刷新，不管是使用Refresh头还是＜META HTTP-EQUIV=”Refresh” …＞。 注意Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。 |
| Server | 服务器名字。Servlet一般不设置这个值，而是由Web服务器自己设置。 |
| Set-Cookie | 设置和页面关联的Cookie。Servlet不应使用response.setHeader(“Set-Cookie”, …)，而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。 |
| WWW-Authenticate | 客 户应该在Authorization头中提供什么类型的授权信息？在包含401（Unauthorized）状态行的应答中这个头是必需的。例如， response.setHeader(“WWW-Authenticate”, “BASIC realm=＼”executives＼”")。 www~phperz~com 注意Servlet一般不进行这方面的处理，而是让Web服务器的专门机制来控制受密码保护页面的访问（例如.htaccess）。 |
标准状态代码
Number
|
Description
|
100
|
Continue
|
101
|
Switching protocols
|
200
|
OK
|
201
|
Created
|
202
|
Accepted
|
203
|
Non-Authoritative Information
|
204
|
No Content
|
205
|
Reset Content
|
206
|
Partial Content
|
300
|
Multiple Choices
|
301
|
Moved Permanently
|
302
|
Found
|
303
|
See Other
|
304
|
Not Modified
|
305
|
Use Proxy
|
307
|
Temporary Redirect
|
400
|
Bad Request
|
401
|
Unauthorized
|
402
|
Payment Required
|
403
|
Forbidden
|
404
|
Not Found
|
405
|
Method Not Allowed
|
406
|
Not Acceptable
|
407
|
Proxy Authentication Required
|
408
|
Request Timeout
|
409
|
Conflict
|
410
|
Gone
|
411
|
Length Required
|
412
|
Precondition Failed
|
413
|
Request Entity Too Large
|
414
|
Request-URI Too Long
|
415
|
Unsupported Media Type
|
416
|
Requested Range Not Suitable
|
417
|
Expectation Failed
|
500
|
Internal Server Error
|
501
|
Not Implemented
|
502
|
Bad Gateway
|
503
|
Service Unavailable
|
504
|
Gateway Timeout
|
505
|
HTTP Version Not Supported
|
1.1 消息1xx（Informational 1xx）
该类状态代码用于表示临时回应。临时回应由状态行（Status-Line）及可选标题组成，由空行终止。HTTP/1.0中没有定义任何1xx的状态代码，所以它们不是对HTTP/1.0请求的合法回应。实际上，它们主要用于实验用途，这已经超出本文档的范围。
1.2 成功2xx（Successful 2xx）
表示客户端请求被成功接收、理解、接受。
200 OK
请求成功。回应的信息依赖于请求所使用的方法，如下：
GET 要请求的资源已经放在回应的实体中了。
HEAD 没有实体主体，回应中只包括标题信息。
POST 实体（描述或包含操作的结果）。
201 Created
请求完成，结果是创建了新资源。新创建资源的URI可在回应的实体中得到。原始服务器应在发出该状态代码前创建该资源。如果该操作不能立即完成，服务器必须在该资源可用时在回应主体中给出提示，否则，服务器端应回应202（可被接受）。
在本文定义的方法，只有POST可以创建资源。
202 Accepted
请求被接受，但处理尚未完成。请求可能不一定会最终完成，有可能被处理过程随时中断，在这种情况下，没有办法在异步操作中重新发送状态代码。
202回应是没有义务的，这样做的目的是允许服务器不必等到用户代理和服务器间的连接结束，就可以响应其它过程的请求（象每天运行一次的，基于批处理的过程）。
在某些回应中返回的实体中包括当前请求的状态指示、状态监视器指针或用户对请求能否实现的评估信息。
204 No Content
服务器端已经实现了请求，但是没有返回新的信息。如果客户是用户代理，则勿需为此更新自身的文档视图。该回应主要是为了在不影响用户代理激活文档视图的前 提下，进行script语句的输入及其它操作。该回应还可能包括新的、以实体标题形式表示的元信息，它可被当前用户代理激活视图中的文档所使用。
1.3 重定向（Redirection 3xx）
该类状态码表示用户代理要想完成请求，还需要发出进一步的操作。这些操作只有当后跟的请求是GET或HEAD时，才可由用户代理来实现，而不用与用户进行交互。用户代理永远也不要对请求进行5次以上的重定向操作，这样可能导致无限循环。
300 Multiple Choices
该状态码不被HTTP/1.0的应用程序直接使用，只是做为3xx类型回应的缺省解释。存在多个可用的被请求资源。
除非是HEAD请求，否则回应的实体中必须包括这些资源的字符列表及位置信息，由用户或用户代理来决定哪个是最适合的。
如果服务器有首选，它应将对应的URL信息存放在位置域（Location field）处，用户代理会根据此域的值来实现自动的重定向。
301 Moved Permanently
请求到的资源都会分配一个永久的URL，这样就可以在将来通过该URL来访问此资源。有编辑链接功能的客户端会尽可能地根据服务器端传回的新链接而自动更 新请求URI。新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体（Entity-Body）必须包括对新URL超链接的简要 描述。
如果用POST方法发出请求，而接收到301回应状态码。在这种情况下，除非用户确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。
注意：当在接收到301状态码后而自动重定向POST请求时，一些现存的用户代理会错误地将其改为GET请求。
302 Moved Temporarily
请求到的资源在一个不同的URL处临时保存。因为重定向有时会被更改，客户端应继续用请求URI来发出以后的请求。新的URL必须由回应中的位置域指定。除非是HEAD请求，否则回应的实体主体（Entity-Body）必须包括对新URL超链接的简要描述。
如果用POST方法发出请求，而接收到302回应状态码。在这种情况下，除非用户确认，否则用户代理不必自动重定向请求，因为这将导致改变已发出请求的环境。
注意：当在接收到302状态码后而自动重定向POST请求时，一些现存的用户代理会错误地将其改为GET请求。
304 Not Modified
如果客户端成功执行了条件GET请求，而对应文件自If-Modified-Since域所指定的日期以来就没有更新过，服务器应当回应此状态码，而不是 将实体主体发送给客户端。回应标题域中只应包括一些相关信息，比如缓存管理器、与实体最近更新（entity’s Last-Modified）日期无关的修改。相关标题域的例子有：日期、服务器、过期时间。每当304回应中给出的域值发生变化，缓存都应当对缓存的实 体进行更新。
1.4 客户端错误（Client Error）4xx
4xx类的状态码表示客户端发生错误。如果客户端在收到4xx代码时请求还没有完成，它应当立即终止向服务器发送数据。除了回应HEAD请求外，不论错误是临时的还是永久的，服务器端都必须在回应的实体中包含错误状态的解释。这些状态码适用于任何请求方法。
注意：如果客户端正在发送数据，服务器端的TCP实现应当小心，以确保客户端在关闭输入连接之前收到回应包。如果客户端在关闭后仍旧向服务器发送数据，服务器会给客户 端发送一个复位包，清空客户端尚未处理的输入缓冲区，以终止HTTP应用程序的读取、解释活动。
400 非法请求（Bad Request）
如果请求的语法不对，服务器将无法理解。客户端在对该请求做出更改之前，不应再次向服务器重复发送该请求。
401 未授权（Unauthorized）
请求需要用户授权。回应中的WWW-Authenticate标题域（10.16节）应提示用户以授权方式请求资源。客户端应使用合适的授权标题域 （10.2节）来重复该请求。如果请求中已经包括了授权信任信息，那回应的401表示此授权被拒绝。如果用户代理在多次尝试之后，回应一样还是返回401 状态代码，用户应当察看一下回应的实体，因为在实体中会包括一些相关的动态信息。HTTP访问授权会在11节中解释。
403 禁止（Forbidden）
服务器理解请求，但是拒绝实现该请求。授权对此没有帮助，客户端应当停止重复发送此请求。如果不是用HEAD请求方法，而且服务器端愿意公布请求未被实现 原因的前提下，服务器会将拒绝原因写在回应实体中。该状态码一般用于服务器端不想公布请求被拒绝的细节或没有其它的回应可用。
404 没有找到（Not Found）
服务器没有找到与请求URI相符的资源。404状态码并不指明状况是临时性的还是永久性的。如果服务器不希望为客户端提供这方面的信息，还回应403（禁止）状态码。
1.5 服务器错误（Server Error ）5xx
回应代码以‘5’开头的状态码表示服务器端发现自己出现错误，不能继续执行请求。如果客户端在收到5xx状态码时，请求尚未完成，它应当立即停止向服务器发送数据。除了回应HEAD请求外，服务器应当在其回应实体中包括对错误情况的解释、并指明是临时性的还永久性的。
这类回应代码没有标题域，可适用于任何请求方法。
500 服务器内部错误（Internal Server Error）
服务器碰到了意外情况，使其无法继续回应请求。
501 未实现（Not Implemented）
服务器无法提供对请求中所要求功能的支持。如果服务器无法识别请求方法就会回应此状态代码，这意味着不能回应请求所要求的任何资源。
502 非法网关（Bad Gateway）
充当网关或代理的服务器从要发送请求的上游（upstream）服务器收到非法的回应。
503 服务不可用（Service Unavailable）
服务器当前无法处理请求。这一般是由于服务器临时性超载或维护引起的。该状态码暗示情况是暂时性的，要产生一些延迟。
注意：503状态码并没有暗示服务器在超载时一定要返回此状态码。一些服务器可能希望在超载时采用简单处理，即断掉连接。
IIS 错误代码大汇总
400 无法解析此请求。
401.1 未经授权：访问由于凭据无效被拒绝。
401.2 未经授权: 访问由于服务器配置倾向使用替代身份验证方法而被拒绝。
401.3 未经授权：访问由于 ACL 对所请求资源的设置被拒绝。
401.4 未经授权：Web 服务器上安装的筛选器授权失败。
401.5 未经授权：ISAPI/CGI 应用程序授权失败。
401.7 未经授权：由于 Web 服务器上的 URL 授权策略而拒绝访问。
403 禁止访问：访问被拒绝。
403.1 禁止访问：执行访问被拒绝。
403.2 禁止访问：读取访问被拒绝。
403.3 禁止访问：写入访问被拒绝。
403.4 禁止访问：需要使用 SSL 查看该资源。
403.5 禁止访问：需要使用 SSL 128 查看该资源。
403.6 禁止访问：客户端的 IP 地址被拒绝。
403.7 禁止访问：需要 SSL 客户端证书。
403.8 禁止访问：客户端的 DNS 名称被拒绝。
403.9 禁止访问：太多客户端试图连接到 Web 服务器。
403.10 禁止访问：Web 服务器配置为拒绝执行访问。
403.11 禁止访问：密码已更改。
403.12 禁止访问：服务器证书映射器拒绝了客户端证书访问。
403.13 禁止访问：客户端证书已在 Web 服务器上吊销。
403.14 禁止访问：在 Web 服务器上已拒绝目录列表。
403.15 禁止访问：Web 服务器已超过客户端访问许可证限制。
403.16 禁止访问：客户端证书格式错误或未被 Web 服务器信任。
403.17 禁止访问：客户端证书已经到期或者尚未生效。
403.18 禁止访问：无法在当前应用程序池中执行请求的 URL。
403.19 禁止访问：无法在该应用程序池中为客户端执行 CGI。
403.20 禁止访问：Passport 登录失败。
404 找不到文件或目录。
404.1 文件或目录未找到：网站无法在所请求的端口访问。
注意 404.1 错误只会出现在具有多个 IP 地址的计算机上。如果在特定 IP 地址/端口组合上收到客户端请求，而且没有将 IP 地址配置为在该特定的端口上侦听，则 IIS 返回 404.1 HTTP 错误。例如，如果一台计算机有两个 IP 地址，而只将其中一个 IP 地址配置为在端口 80 上侦听，则另一个 IP 地址从端口 80 收到的任何请求都将导致 IIS 返回 404.1 错误。只应在此服务级别设置该错误，因为只有当服务器上使用多个 IP 地址时才会将它返回给客户端。
404.2 文件或目录无法找到：锁定策略禁止该请求。
404.3 文件或目录无法找到：MIME 映射策略禁止该请求。
405 用于访问该页的 HTTP 动作未被许可。
406 客户端浏览器不接受所请求页面的 MIME 类型。
407 Web 服务器需要初始的代理验证。
410 文件已删除。
412 客户端设置的前提条件在 Web 服务器上评估时失败。
414 请求 URL 太大，因此在 Web 服务器上不接受该 URL。
500 服务器内部错误。
500.11 服务器错误：Web 服务器上的应用程序正在关闭。
500.12 服务器错误：Web 服务器上的应用程序正在重新启动。
500.13 服务器错误：Web 服务器太忙。
500.14 服务器错误：服务器上的无效应用程序配置。
500.15 服务器错误：不允许直接请求 GLOBAL.ASA。
500.16 服务器错误：UNC 授权凭据不正确。
500.17 服务器错误：URL 授权存储无法找到。
500.18 服务器错误：URL 授权存储无法打开。
500.19 服务器错误：该文件的数据在配置数据库中配置不正确。
500.20 服务器错误：URL 授权域无法找到。
500.100 内部服务器错误：ASP 错误。
501 标题值指定的配置没有执行。
502 Web 服务器作为网关或代理服务器时收到无效的响应。
-------------
HTTP协议入门之HTTP协议的历史演变和设计思路
HTTP 协议是互联网的基础协议，也是网页开发的必备知识，最新版本 HTTP/2 更是让它成为技术热点。
本文介绍 HTTP协议的历史演变和设计思路。
一、HTTP/0.9
HTTP 是基于 TCP/IP 协议的应用层协议。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。
最早版本是1991年发布的0.9版。该版本极其简单，只有一个命令GET。
|
|
上面命令表示，TCP 连接（connection）建立后，客户端向服务器请求（request）网页index.html。
协议规定，服务器只能回应HTML格式的字符串，不能回应别的格式。
|
|
服务器发送完毕，就关闭TCP连接。
二、HTTP/1.0
2.1 简介
1996年5月，HTTP/1.0 版本发布，内容大大增加。
首先，任何格式的内容都可以发送。这使得互联网不仅可以传输文字，还能传输图像、视频、二进制文件。这为互联网的大发展奠定了基础。
其次，除了
再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。
GET命令，还引入了POST命令和HEAD命令，丰富了浏览器与服务器的互动手段。再次，HTTP请求和回应的格式也变了。除了数据部分，每次通信都必须包括头信息（HTTP header），用来描述一些元数据。
其他的新增功能还包括状态码（status code）、多字符集支持、多部分发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等。
2.2 请求格式
下面是一个1.0版的HTTP请求的例子。
|
|
可以看到，这个格式与0.9版有很大变化。
第一行是请求命令，必须在尾部添加协议版本（
第一行是请求命令，必须在尾部添加协议版本（
HTTP/1.0）。后面就是多行头信息，描述客户端的情况。2.3 回应格式
服务器的回应如下。
|
|
回应的格式是”头信息 + 一个空行（
\r\n） + 数据”。其中，第一行是”协议版本 + 状态码（status code） + 状态描述”。2.4 Content-Type 字段
关于字符的编码，1.0版规定，头信息必须是 ASCII 码，后面的数据可以是任何格式。因此，服务器回应的时候，必须告诉客户端，数据是什么格式，这就是
下面是一些常见的
Content-Type字段的作用。下面是一些常见的
Content-Type字段的值。
|
|
这些数据类型总称为MIME type，每个值包括一级类型和二级类型，之间用斜杠分隔。
除了预定义的类型，厂商也可以自定义类型。
除了预定义的类型，厂商也可以自定义类型。
|
|
上面的类型表明，发送的是Debian系统的二进制数据包。
MIME type还可以在尾部使用分号，添加参数。
MIME type还可以在尾部使用分号，添加参数。
|
|
上面的类型表明，发送的是网页，而且编码是UTF-8。
客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。
客户端请求的时候，可以使用Accept字段声明自己可以接受哪些数据格式。
|
|
上面代码中，客户端声明自己可以接受任何格式的数据。
MIME type不仅用在HTTP协议，还可以用在其他地方，比如HTML网页。
MIME type不仅用在HTTP协议，还可以用在其他地方，比如HTML网页。
|
|
2.5 Content-Encoding 字段
由于发送的数据可以是任何格式，因此可以把数据压缩后再发送。Content-Encoding字段说明数据的压缩方法。
|
|
客户端在请求时，用Accept-Encoding字段说明自己可以接受哪些压缩方法。
|
|
2.6 缺点
HTTP/1.0 版的主要缺点是，每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。
TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。
为了解决这个问题，有些浏览器在请求时，用了一个非标准的
TCP连接的新建成本很高，因为需要客户端和服务器三次握手，并且开始时发送速率较慢（slow start）。所以，HTTP 1.0版本的性能比较差。随着网页加载的外部资源越来越多，这个问题就愈发突出了。
为了解决这个问题，有些浏览器在请求时，用了一个非标准的
Connection字段。
|
|
这个字段要求服务器不要关闭TCP连接，以便其他请求复用。服务器同样回应这个字段。
|
|
一个可以复用的TCP连接就建立了，直到客户端或服务器主动关闭连接。但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。
三、HTTP/1.1
1997年1月，HTTP/1.1 版本发布，只比 1.0 版本晚了半年。它进一步完善了 HTTP 协议，一直用到了20年后的今天，直到现在还是最流行的版本。
3.1 持久连接
1.1 版的最大变化，就是引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。
客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。
客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。不过，规范的做法是，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接。
|
|
目前，对于同一个域名，大多数浏览器允许同时建立6个持久连接。
3.2 管道机制
1.1 版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。
举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送A请求，然后等待服务器做出回应，收到后再发出B请求。管道机制则是允许浏览器同时发出A请求和B请求，但是服务器还是按照顺序，先回应A请求，完成后再回应B请求。
3.3 Content-Length 字段
一个TCP连接现在可以传送多个回应，势必就要有一种机制，区分数据包是属于哪一个回应的。这就是
Content-length字段的作用，声明本次回应的数据长度。
|
|
上面代码告诉浏览器，本次回应的长度是3495个字节，后面的字节就属于下一个回应了。
在1.0版中，
在1.0版中，
Content-Length字段不是必需的，因为浏览器发现服务器关闭了TCP连接，就表明收到的数据包已经全了。3.4 分块传输编码
使用
Content-Length字段的前提条件是，服务器发送回应之前，必须知道回应的数据长度。
对于一些很耗时的动态操作来说，这意味着，服务器要等到所有操作完成，才能发送数据，显然这样的效率不高。更好的处理方法是，产生一块数据，就发送一块，采用”流模式”（stream）取代”缓存模式”（buffer）。
因此，1.1版规定可以不使用
Content-Length字段，而使用”分块传输编码”（chunked transfer encoding）。只要请求或回应的头信息有Transfer-Encoding字段，就表明回应将由数量未定的数据块组成。
|
|
每个非空的数据块之前，会有一个16进制的数值，表示这个块的长度。最后是一个大小为0的块，就表示本次回应的数据发送完了。下面是一个例子。
|
|
3.5 其他功能
1.1版还新增了许多动词方法：
PUT、PATCH、HEAD、 OPTIONS、DELETE。
另外，客户端请求的头信息新增了
Host字段，用来指定服务器的域名。
|
|
有了
Host字段，就可以将请求发往同一台服务器上的不同网站，为虚拟主机的兴起打下了基础。3.6 缺点
虽然1.1版允许复用TCP连接，但是同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只有处理完一个回应，才会进行下一个回应。要是前面的回应特别慢，后面就会有许多请求排队等着。这称为”队头堵塞“（Head-of-line blocking）。
为了避免这个问题，只有两种方法：一是减少请求数，二是同时多开持久连接。这导致了很多的网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等等。如果HTTP协议设计得更好一些，这些额外的工作是可以避免的。
四、SPDY 协议
2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。
这个协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。
这个协议在Chrome浏览器上证明可行以后，就被当作 HTTP/2 的基础，主要特性都在 HTTP/2 之中得到继承。
五、HTTP/2
2015年，HTTP/2 发布。它不叫 HTTP/2.0，是因为标准委员会不打算再发布子版本了，下一个新版本将是 HTTP/3。
5.1 二进制协议
HTTP/1.1 版的头信息肯定是文本（ASCII编码），数据体可以是文本，也可以是二进制。HTTP/2 则是一个彻底的二进制协议，头信息和数据体都是二进制，并且统称为”帧”（frame）：头信息帧和数据帧。
二进制协议的一个好处是，可以定义额外的帧。HTTP/2 定义了近十种帧，为将来的高级应用打好了基础。如果使用文本实现这种功能，解析数据将会变得非常麻烦，二进制解析则方便得多。
5.2 多工
HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”。
举例来说，在一个TCP连接里面，服务器同时收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。
这样双向的、实时的通信，就叫做多工（Multiplexing）。
5.3 数据流
因为 HTTP/2 的数据包是不按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。因此，必须要对数据包做标记，指出它属于哪个回应。
HTTP/2 将每个请求或回应的所有数据包，称为一个数据流（stream）。每个数据流都有一个独一无二的编号。数据包发送的时候，都必须标记数据流ID，用来区分它属于哪个数据流。另外还规定，客户端发出的数据流，ID一律为奇数，服务器发出的，ID为偶数。
数据流发送到一半的时候，客户端和服务器都可以发送信号（
RST_STREAM帧），取消这个数据流。1.1版取消数据流的唯一方法，就是关闭TCP连接。这就是说，HTTP/2 可以取消某一次请求，同时保证TCP连接还打开着，可以被其他请求使用。
客户端还可以指定数据流的优先级。优先级越高，服务器就会越早回应。
5.4 头信息压缩
HTTP 协议不带有状态，每次请求都必须附上所有信息。所以，请求的很多字段都是重复的，比如
Cookie和User Agent，一模一样的内容，每次请求都必须附带，这会浪费很多带宽，也影响速度。
HTTP/2 对这一点做了优化，引入了头信息压缩机制（header compression）。一方面，头信息使用
gzip或compress压缩后再发送；另一方面，客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。5.5 服务器推送
HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送（server push）。
常见场景是客户端请求一个网页，这个网页里面包含很多静态资源。正常情况下，客户端必须收到网页后，解析HTML源码，发现有静态资源，再发出静态资源请求。其实，服务器可以预期到客户端请求网页后，很可能会再请求静态资源，所以就主动把这些静态资源随着网页一起发给客户端了。
参考
----------------------相关帖子；https://briteming.blogspot.com/2013/03/http.html
No comments:
Post a Comment