Http简介
HTTP（Hypertext Transfer Protocol）超文本传输协议，从1990年开始在WWW上广泛应用，目前版本1.1。
HTTP是应用层的协议，当你上网浏览网页的时候，浏览器和Web服务器之间就会通过HTTP在Internet上进行数据的发送和接收。
HTTP是一个基于 请求/响应 模式的、无状态的协议。
Http URL
格式：http://host[“:”port][abs_path]
注释：
http:通过HTTP协议定位网络资源
host:合法的Internet主机域名或IP地址（以点分十进制的格式表示）
port:指定端口号，拥有被请求资源的服务器主机监听该端口的TCP连接，若为空，或者没有给出，则使用缺省的端口80
abs_path：指定请求资源的URI(Uniform Resource Identifier,统一资源标志符)，如果URL中没有给出abs_path,那么当它作为请求URI时，必须以“/”的形式
给出。通常这个工作浏览器帮助我们完成
（URI:指定构成Web资源的字符串的各个不同部分的符号结构。URL是一种特殊类型的URI,包含查找某个资源的足够信息。）
Http请求
包括：
请求行：Method Request_URI HTTP-Version (CRLF)
如：GET /ajax.html HTTP/1.1 (CRLF)
消息报头
请求正文
详细解释：
Method:请求方法
具体请参看下表：
（1） Get
（2） Post
POST方法向母的服务器发出请求，要求服务器接受附加在请求后面的数据。POST方法在表单提交的时候用得比较多
例:
(3) Head
Head方法只请求消息报头，而不是完整的内容。对于Head请求的回应部分来说，它的http头部中包含的信息与通过GET请求得到的信息是相同的
注意：在html文档中，书写get和post，大小写都可以，但http协议中的GET和POST只能是大写。
Request_URI：统一资源标志符，标志了要请求的资源
HTTP-Version：请求的http协议版本
CRTF:回车换行
消息报头；
请求正文。
Http响应
组成部分：
状态行:HTTP-Version Status-Code Reason-Phrase CRLF
消息报头；
响应正文。
详细解释：
HTTP-Version:服务器http协议版本
Status-Code:服务器发回的响应代码
状态代码由3位数字组成，表示请求是否被理解或满足
状态代码的第一个数字定义响应的类别，后两位数字没有具体分类。第一个数字的5种分类：
- 1xx : 指示信息—表示请求已接收
- 2xx ：成功—请求已经被成功接收、理解、接受
- 3xx ：重定向—要完成请求必须进行更进一步的操作
- 4xx : 客户端错误—请求有语法错误或请求无法实现
- 5xx : 服务器错误—服务器未能实现合法的请求
详细说明如下：
Reason-Phrase：状态代码的文本描述
状态描述给出了关于状态代码的简短的文本描述
CRLF:回车换行
如：HTTP/1.1 200 OK (CRLF)
消息报头；
响应正文。
HTTP消息
HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由 开始行，消息报头（可选的），空行（只用CRLF的行），消息正文（可选的）组成。
对于请求消息，开始行就是请求行，对于响应消息，开始行就是状态行。
请求消息的例子
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,image/pjpeg,application/x-shockjwave-flash,application/vnd.ms-excel.application/vnd.ms-powerpoint,application/msword,*/* (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2005 11:21:52 GMT (CRLF)
If-None-Match:W/’’80b1a4c018f3c41:8317” (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE 6.0;Windows NT 5.0) (CRLF)
Host:www.winsunlight.com (CRLF)
Connection:Keep-Alive (CRLF)
CRLF
响应消息例子：
HTTP/1.1 200 OK (CRLF)
Connection-Length:2218 (CRLF)
Content-Type:text/html (CRLF)
Last-Modified:wed,05 Jan 2005 11:21:52 GMT (CRLF)
Accept-Ranges:bytes (CRLF)
ETag:W/’’ 80b1a4c018f3c41:831d’’ (CRLF)
Server:Microsoft-IIS/6.0 (CRLF)
Date:Wed,05 Jan 2006 05:48:54 GMT (CRLF)
CRLF
<html>
<head>
<title>
This is the form page.
</title>
</head>
<body>
…（省略）
</body>
<html>
HTTP消息报头
包括:
普通报头
请求报头
响应报头
实体报头
每一个报头域都是由名字+“:”+空格+值组成，消息报头域的名字是大小写无关的。
详细解释：
常用普通报头：
在普通报头中，有少数报头域应用于所有的请求和响应信息，但并不用于被传输的实体，这些报头域只用于传输的消息
Cache-Control
Cache-Control普通报头域用于指定缓存指令，该指令将被 请求/响应 链中所有的缓存机制所遵循。这些指令将覆盖缺省的缓存规则。缓存指令是单向的，在请求中出现的缓存指令，并不意味着在响应中也会出现。此外，在一个消息（请求或响应消息）中指定的缓存指令，并不会影响另一个消息处理的缓冲机制。
注意：Cache-Control普通报头域是在HTTP1.1中新加的，HTTP1.0使用的类似报头域为Pragma。
缓存指令分为请求时的缓存指令和响应时的缓存指令。请求时的缓存指令包括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、s-maxage。其中最常用的是no-cache,用于指示请求或响应消息不能缓存。
例如：为了指示IE浏览器（客户端）不要缓存页面，服务器端的JSP程序可以编写下面的代码：
Response.setHeader(“Cache-Control”,“no-cache”);
这句代码将在发送的响应消息中设置普通报头域：Cache-Control:no-cache。
Date
Date普通报头域表示消息产生的日期和时间，可以用于HTTP响应中，也可以用于HTPP请求中。作为服务器端，应该总是在所有的响应中包含Date报头域。作为客户端只有在发送的消息中包含了消息正文的时候，才应该发送Date报头域，例如，在POST请求的时候。
Connection
Connection普通报头域允许发送者制定连接的选项。例如制定连接是持续的，或者指定“close”选项，通知服务器，在响应完成后，关闭连接。
Pragma
Pragma普通报头域被用于包含特定实现的指令，这些指令可能会应用到 请求/响应链中的任何一个接受者。最常用的是Pragma:no-cache。在HTTP1.1中，它的含义和Cache-Control:no-cache相同。有时候，我们不知道客户端浏览器是否支持HTTP1.1,可以同时使用Pragma和Cache-Contrl报头域，来指示客户端不要缓存响应消息，如下：
Response.setHeader(“Pragma”,“no-cache”);
Response.setHeader(“Cache-Control”,“no-cache”);
常用请求报头
请求报头允许客户端向服务器端传递该请求的附加信息以及客户端自身的信息。
Accept
Accept请求报头域用于指定客户端接受哪些类型的信息。例如：Accept
:image/gif,表明客户端希望接受GIF图像格式的资源；Accept：text/html,表明客户端希望接受html文本。
Accept-Charset
Accept-Charset请求报头域用于指定客户端接受的字符集。例如：Accept-Charset
:iso-8859-1,gb2312。
如果在请求消息中没有设置这和域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding请求报头域类似于Accept,但是它是用于指定可接受的内容编码。例如：Accept-Encoding：gzip,deflate。如果请求消息中没有设置这个域，服务器假定客户端对各种内容编码都可以接受。
Accept-Language
Accept-Language请求报头域类似于Accept,但是它是用于指定一种自然语言。例如：Accept-Language： zh-cn。如果请求消息中没有设置这个域，服务器假定客户端对各种语言都可接受。
Authorization
Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization
请求报头域的请求，要求服务器对其进行验证。
Host
Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常是从HTTP URL中提取出来的。
例如：我们在浏览器的地址栏输入：
http://www.sunxin.org/index.html
浏览器发送的请求消息中，就会包含Host请求报头域，如下：
Host:www.sunxin.org
后面没有跟端口号，表明使用的是缺省端口号80
要注意的是，在发送HTTP请求的时候，这个报头域是必须的。
User-Agent
我们上网登录论坛的时候，往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本，你所用的浏览器的名称和版本。服务器应用程序就是从User-Agent这个请求报头域中获取到的这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。不过，这个报头域不是必须的，如果我们自己编写一个浏览器，不使用User-Agent请求报头域，那么服务器端就无法得知我们的信息了。
常用响应报头
响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
Location
Location响应报头域用于重定向接受者到一个新的位置。例如：客户端所请求的页面已不在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头域。这种情况还经常发生在更换域名的时候，在旧的域名所对应的服务器上保留一个文件，然后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源。当我们在JSP中使用重定向语句的时候，服务器端向客户端发回的响应报头中，就会有Location响应报头域。下面是Location响应报头域的一个例子：
Location:http://www.sunxin.org
Server
Server响应报头域包含了服务器用来处理请求的软件信息。它和User-Agent请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件（浏览器）和操作系统的信息。
下面是Server响应报头域的一个例子：
Server:Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate响应报头域必须被包含在401（未授权的）响应消息中，这个报头域和前面讲到的Authorization请求报头域是相关的，当客户端收到401响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了Authorization报头域的请求。下面是WWW-Authenticate响应报头域的一个例子：
WWW-Authenticate:Basic realm=“Basic Auth Test!”
从这个响应报头域，可以知道服务器端对我们所请求的资源采用的是基本验证机制。
实体报头
请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，在大多数情况下，实体正文就是请求消息中的请求正文或者响应消息中的响应正文。但是在发送时，并不是说实体报头域和实体正文要在一起发送，例如：有些响应可以只包含实体报头域。实体就好像我们写的书信，在信中，我们可以写上标题，加上页号等，这部分就相当于是实体报头域，而我们所写的书信的内容，就相当于是实体正文。前面所讲的普通报头、请求报头，响应报头我们可以看成是写在信封上的邮编、接收者、发送者等内容。
实体报头定义了关于实体正文（例如：有实体无正文）和请求所标识的资源的元信息。
常用的实体报头
Content-Encoding
Content-Encoding实体报头域被用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容编码，因而要获得Content-Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding主要用于记录文档的压缩方法，下面是它的一个例子：
Content-Encoding：gzip
如果一个实体正文采用了编码方式存储，在使用之前就必须进行解码。
Content-Language
Content-Language实体报头域描述了资源所用的自然语言。Content-Language允许用户遵照自身的首选语言来识别和区分实体。如果这和实体内容仅仅打算提供给丹麦的阅读者，那么可以按照如下的方式设置这个实体报头域：
Content-Language：da
如果没有指定Content-Language报头域，那么实体内容将提供给所欲语言的阅读者。
Content-Length
Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示，也就是一个数字字符占一个字节，用其对应的ASCII码存储传输。
要注意的是，这个长度仅仅是表示实体正文的长度，没有包括实体报头的长度。
Content-Type
Content-Type实体报头域用于指明发送给接收者的实体正文的媒体类型。例如：
Content-Type：text/html;charset=ISO-8859-1
Content-Type:text/html;charset=GB2312
Last-Modified
Last-Modified实体报头域用于指示资源最后的修改日期及时间。
Expires
Expires实体报头域给出响应过期的日期和时间。通常，代理服务器或浏览器会缓存一些页面，当用户再次访问这些页面时，直接从缓存中加载并显示给用户，这样缩短了响应的时间，减少了服务器的负载。为了让代理服务器或浏览器在一段时间后更新页面，我们可以使用Expires实体报头域指定页面过期的时间。当用户又一次访问页面时，如果Expires
报头域给出的日期和时间比Date普通报头域给出的日期和时间要早（或相同），那么代理服务器或浏览器就不会再使用缓存页面，而是从服务器请求更新的页面。不过要注意，即使页面过期了，也并不意味着服务器上的原始资源在此时间之前或之后发生了改变。
Expires实体报头域使用的日期和时间必须是RFC 1123中的日期和格式，例如：
Expires：Thu,15 Sep 2005 16:00:00 GMT
HTTP1.1的客户端和缓存必须将其它非法的日期格式（也包括0）看作已经过期。例如，为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置它的值为0，如下：
Response.setDateHeader(“Expires”,0);
总结
这里介绍了HTTP协议实现的一些细节，包括HTTP请求与HTTP响应的组成，重点介绍了HTTP消息报头，其中请求报头只能用于HTTP请求中，响应报头只能用于HTTp响应中，普通报头中有些报头域既可以用于HTTP请求中，也可以用于HTTP响应中，实体报头定义了关于实体正文和请求所标识的资源的元信息。
如果想要更深入地学习HTTP协议，可以参看RFC2616。RFC(Request For Comments,请求注释)，即Internet标准草案。Internet上有各种各样的技术，需要遵循一定的标准，这些标准以RFC文件的形式在Internet上发布。每个RFC文件都有一个序列号，讨论一个有关Internet技术的主题。大家可以在http://www.ietf.org/rfc 上找到RFC2616文件，或者在 搜索引擎上搜索“RFC2616”关键字，查找此文件。建议大家，如果不是要从事HTTP协议的相关开发，没有必要去看RFC文档。
此文章只是作为资料查看，Word文档大家可以到http://download.csdn.net/source/2451850下载，如有问题请留言。谢谢！
声明：文字内容来源于孙鑫老师《HTTP协议详解》视频资料
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
