HTTP协议

简介

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。Ted Nelson组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force ）共同合作研究，最终发布了一系列的RFC，其中著名的RFC 2616定义了HTTP 1.1。（百度百科）
HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。

特点

1. 支持客户/服务器模式。
2. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5. 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP URL

• 格式：http://host“:”[port][abs_path]
• http表示要通过HTTP协议来定位网络资源；
• port指定一个端口号，为空则使用缺省端口80；
• abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。
  例如：
  
  1. 输入：www.guet.edu.cn
     浏览器自动转换成：http://www.guet.edu.cn/
  2. http:192.168.0.116:8080/index.jsp

HTTP 请求

http请求由三部分组成，分别是：请求行、消息报头、请求正文

1. 请求行

   • 格式：Method(方法符号) Request-URI(请求的URI) HTTP-Version(协议的版本) CRLF(回车和换行)
     注：除了作为结尾的CRLF外，不允许出现单独的CR或LF字符。

   • 方法符号（大写）：
     GET：请求获取Request-URI所标识的资源
     POST：在Request-URI所标识的资源后附加新的数据
     HEAD：请求获取由Request-URI所标识的资源的响应消息报头
     PUT： 请求服务器存储一个资源，并用Request-URI作为其标识
     DELETE：请求服务器删除Request-URI所标识的资源
     TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断
     CONNECT：保留将来使用
     OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项和需求

2. 消息报头

   • Accept：浏览器可接受的MIME类型。
   • Accept - Charset：浏览器可接受的字符集。
   • Accept - Encoding：浏览器能够进行解码的数据编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。
   • Accept - Language：浏览器所希望的语言种类，当服务器能够提供一种以上的语言版本时要用到。
   • Authorization：授权信息，通常出现在对服务器发送的WWW - Authenticate头的应答中。
   • Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep - Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content - Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
   • Content - Length：表示请求消息正文的长度。
   • Cookie：这是最重要的请求头信息之一。
   • From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
   • Host：初始URL中的主机和端口。
   • If - Modified - Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。
   • Pragma：指定“no - cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
   • Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
   • User - Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
   • UA - Pixels，UA - Color，UA - OS，UA - CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。
3. 请求正文：也就是我们发送的数据

4. 实例

   • POST /reg.jsp HTTP/1.1(CRLF) // 请求行
   • HOST: www.guet.edu.cn(CRLF) // 消息报头
   • Accept:image/gif,image/x-xbit,…(CRLF)
   • Content-Length:22(CRLF)
   • Connection:Keep-Alive(CRLF)
   • Cache-Control:no-cache(CRLF)
   • …
   • (CRLF) // CRLF表示回车和换行
   • user=jeffrey&pwd=1234 // 消息正文
   • …

HTTP 响应

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

1. 状态行

   • 格式：HTTP-Version(协议的版本) Status-Code(响应状态代码) Reason-Phrase(状态代码的文本描述) CRLF(回车和换行)
   • 状态码：三位数字组成，第一个数字定义了响应的类别。
     1xx：指示信息–表示请求已接收，继续处理
     2xx：成功–表示请求已被成功接收、理解、接受
     3xx：重定向–要完成请求必须进行更进一步的操作
     4xx：客户端错误–请求有语法错误或请求无法实现
     5xx：服务器端错误–服务器未能实现合法的请求
     详细请看：（HTTP状态码详解）http://tool.oschina.net/commons?type=5
2. 消息报头：
   
   • Location：重定向接受者到一个新的位置。
   • Server：包含了服务器用来处理请求的软件信息。它和User-Agent请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户 端软件(浏览器)和操作系统的信息。例如：Server: Apache-Coyote/1.1
   • WWW-Authenticate：必须被包含在401(未授权的)响应消息中，这个报头域和前面讲到的Authorization请求报头域是相关的，当客户端收到401响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了 Authorization报头域的请求。例如：WWW-Authenticate: Basic realm=”Basic Auth Test!”。从这个响应报头域，可以知道服务器端对我们所请求的资源采用的是基本验证机制。
   • Content-Encoding：用作媒体类型的修饰符，它的值指示了已经被应用到实体正文的附加内容编码，因而要获得Content- Type报头域中所引用的媒体类型，必须采用相应的解码机制。例如： Content-Encoding: gzip。如果一个实体正文采用了编码方式存储，在使用之前就必须进行解码。
   • Content-Language：描述了资源所用的自然语言。
   • Content-Length：指明正文的长度，以字节方式存储的十进制数字来表示，也就是一个数字字符占一个字节，用其对应的ASCII码存储传输。注：这个长度仅仅是表示实体正文的长度，没有包括实体报头的长度。
   • Content-Type：指明发送给接收者的实体正文的媒体类型。例如：Content-Type: text/html;charset=ISO-8859-1
   • Last-Modified：指示资源最后的修改日期及时间。
   • Expires：给出响应过期的日期和时间。日期和时间必须是RFC 1123中的日期格式，例如：Expires: Thu, 15 Sep 2005 16:00:00 GMT。
     HTTP1.1的客户端和缓存必须将其他非法的日期格式(也包括0)看作已过期。例如，为了让浏览器不要缓存页面，我们也可以利用Expires实体报头 域，设置它的值为0，如下(JSP)：response.setDateHeader(“Expires”,0);
3. 消息正文

4. 例如：

   • HTTP/1.1 200 OK //状态行
   • Server: nginx
   • Date: Tue, 31 May 2016 02:09:24 GMT
   • Content-Type: application/json;charset=UTF-8
   • Connection: keep-alive
   • Vary: Accept-Encoding
   • Access-Control-Allow-Origin: *
   • Access-Control-Allow-Headers: X-Requested-With,access_token,access-token,content-type,multipart/form-data,application/x-www-form-urlencoded

   • Access-Control-Allow-Methods: GET,POST,OPTIONS
     Content-Length: 49

   • {“resultCode”:1,”resultMsg”:”手机号未注册”} //正文

5. 通用头域：通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。

   • 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。各个消息中的指令含义如下：
     1、Public指示响应可被任何缓存区缓存。
     2、Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。
     3、no-cache指示请求或响应消息不能缓存
     4、no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
     5、max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
     6、min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
     7、max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
   • Date头域：表示消息发送的时间，时间的描述格式由rfc822定义。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时，换算成本地时间，需要知道用户所在的时区。
   • Pragma头域：用来包含实现特定的指令，最常用的是Pragma:no-cache。在HTTP/1.1协议中，它的含义和Cache- Control:no-cache相同。

参考：（HTTP协议详解（真的很经典））http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

未完待续。。。。。。