http协议 （详细，全面）

看了很多不错的http协议的文章，各自有各自的有点，今天整理了一下，希望能帮到大家。

参考资料：

http://www.cnblogs.com/gaojing/archive/2012/02/04/2413626.html

http://www.runoob.com/http/http-intro.html

http://www.cnblogs.com/li0803/archive/2008/11/03/1324746.html

http://www.cnblogs.com/mengdd/archive/2013/05/25/3099240.html

http://www.cnblogs.com/devinzhang/archive/2012/02/06/2340186.html

什么是http协议

HTTP协议（HyperText Transfer Protocol，超文本传输协议）HTTP是一个属于应用层的面向对象的协议，是因特网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。

HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）。（应用层协议和通信协议后边的扩展里会讲到）。

http协议的特点

1、简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。

由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

2、灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

3.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

4.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。

另一方面，在服务器不需要先前信息时它的应答就较快。

5、支持B/S及C/S模式。

浏览器与服务器通讯的过程

现在http通讯的协议有两个版本，我们分别看一下。

　　HTTP 1.0的协议通信过程：

　　Http是构建在TCP基础之上的，而TCP要求建立连接，所以Http也要求先建立连接。

（这里的TCP建立连接的过程，也就是我们常说的tcp三次握手）

　　Http1.0中，当连接建立后，浏览器发送一个请求，服务器回应一个消息，之后，连接就被关闭。

　　当浏览器下次请求的时候，需要重新建立连接，很显然这种需要不断建立连接的通信方式开销比较大。

持续连接（Persistent Connections）

　　在Http1.1版本中，给出了一个持续连接的机制，并将其作为Http1.1中建立连接的缺省行为。

　　通过这种连接，浏览器可以在建立一个连接之后，发送请求并得到回应，然后继续发送请求并再次得到回应。

　　这样比较节省时间，因为连接的建立是需要时间的。

　　而且，客户端还可以发送流水线请求，也就是说，客户端可以连续发送多个请求，而不用等待每一个相应的到来。

浏览器与服务器通信的过程 HTTP1.1

　　客户端建立连接之后，可以发送多次请求，服务器端依次响应多次请求。

　　因为HTTP是基于TCP的，TCP是带连接的、可靠的，所以可以保证请求的顺序不变。

　　当客户端不会再向服务器端发送新的请求的时候，关闭连接。

url

HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下：

http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

eg:

1、输入：www.guet.edu.cn

浏览器自动转换成：http://www.guet.edu.cn/

2、http:192.168.0.116:8080/index.jsp

(URI,URL,URN之间的关系,后面扩展里也会讲到)

客户端请求消息

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header，）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

1，请求行

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，也可以按一下格式表达：Method Request-URI HTTP-Version CRLF

其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。

,1.1，请求方法

请求方法（所有方法全为大写）有多种，各个方法的解释如下：

GET 请求获取Request-URI所标识的资源

POST 在Request-URI所标识的资源后附加新的数据

HEAD 请求获取由Request-URI所标识的资源的响应消息报头

PUT 请求服务器存储一个资源，并用Request-URI作为其标识

DELETE 请求服务器删除Request-URI所标识的资源

TRACE 请求服务器回送收到的请求信息，主要用于测试或诊断

CONNECT 保留将来使用

OPTIONS 请求查询服务器的性能，或者查询与资源相关的选项和需求

2，实例

使用GET来传递数据的实例：

客户端请求：

GET /hello.txt HTTP/1.1(CRLF)//请求行

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3(CRLF)

Host: www.example.com(CRLF)

Accept-Language: en, mi(CRLF)//该CRLF表示消息报头已经结束，在此之前为消息报头

使用POST来传递数据的实例：

POST /reg.jsp HTTP/1.1 (CRLF)//请求行

Accept:image/gif,image/x-xbit,... (CRLF)

...

HOST:www.guet.edu.cn (CRLF)

Content-Length:22 (CRLF)

Connection:Keep-Alive (CRLF)

Cache-Control:no-cache (CRLF)

(CRLF) //该CRLF表示消息报头已经结束，在此之前为消息报头

user=jeffrey&pwd=1234 //此行以下为提交的数据

（请求报头（请求头部）会在后面讲）

服务器响应消息

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

状态行格式如下：

HTTP-Version Status-Code Reason-Phrase CRLF

其中，HTTP-Version表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。

状态代码有三位数字组成，第一个数字定义了响应的类别，且有五种可能取值：

1xx：指示信息--表示请求已接收，继续处理

2xx：成功--表示请求已被成功接收、理解、接受

3xx：重定向--要完成请求必须进行更进一步的操作

4xx：客户端错误--请求有语法错误或请求无法实现

5xx：服务器端错误--服务器未能实现合法的请求

常见状态代码、状态描述、说明：

200 OK //客户端请求成功

400 Bad Request //客户端请求有语法错误，不能被服务器所理解

401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用

403 Forbidden //服务器收到请求，但是拒绝提供服务

404 Not Found //请求资源不存在，eg：输入了错误的URL

500 Internal Server Error //服务器发生不可预期的错误

503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

eg：HTTP/1.1 200 OK （CRLF）

服务端响应实例

HTTP/1.1 200 OK

Date: Mon, 27 Jul 2009 12:28:53 GMT

Server: Apache

Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT

ETag: "34aa387-d-1568eb00"

Accept-Ranges: bytes

Content-Length: 51

Vary: Accept-Encoding

Content-Type: text/plain

Hello World! My payload includes a trailing CRLF.

（消息报头马上就讲啦）

HTTP协议详解之消息报头

HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行（对于请求消息，开始行就是请求行；对于响应消息，开始行就是状态行），消息报头（可选），空行（只有CRLF的行），消息正文（可选）组成。

HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。每一个报头域都是由名字+“：”+空格+值 组成，消息报头域的名字是大小写无关的。

1、请求报头

请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。

常用的请求报头

Accept请求报头域用于指定客户端接受哪些类型的信息。

Accept-Charset请求报头域用于指定客户端接受的字符集。

Accept-Encoding请求报头域类似于Accept，但是它是用于指定可接受的内容编码。

Accept-Language请求报头域类似于Accept，但是它是用于指定一种自然语言。

Authorization请求报头域主要用于证明客户端有权查看某个资源。

Host请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务器。

2、响应报头

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

常用的响应报头

Location响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。

Server响应报头域包含了服务器用来处理请求的软件信息

3. 实体报头

请求和响应消息都可以传送一个实体。

常用的实体报头

Content-Encoding指示已经被应用到实体正文的附加内容的编码。

Content-Language实体报头域描述了资源所用的自然语言。

Content-Length实体报头域用于指明实体正文的长度，以字节方式存储的十进制数字来表示。

Content-Type实体报头域用语指明发送给接收者的实体正文的媒体类型。

Last-Modified实体报头域用于指示资源的最后修改日期和时间。

Expires实体报头域给出响应过期的日期和时间。

更多报头详情http://www.cnblogs.com/xuemykisskui/p/4259534.html

扩展

一，网络传输层

为什么会有TCP/IP协议

在世界上各地，各种各样的电脑运行着各自不同的操作系统为大家服务，这些电脑在表达同一种信息的时候所使用的方法是千差万别。就好像圣经中上帝打乱了各地人的口音，让他们无法合作一样。计算机使用者意识到，计算机只是单兵作战并不会发挥太大的作用。只有把它们联合起来，电脑才会发挥出它最大的潜力。于是人们就想方设法的用电线把电脑连接到了一起。

但是简单的连到一起是远远不够的，就好像语言不同的两个人互相见了面，完全不能交流信息。因而他们需要定义一些共通的东西来进行交流，TCP/IP就是为此而生。TCP/IP不是一个协议，而是一个协议族的统称。里面包括了IP协议，IMCP协议，TCP协议，以及我们更加熟悉的http、ftp、pop3协议等等。电脑有了这些，就好像学会了外语一样，就可以和其他的计算机终端做自由的交流了。

TCP/IP协议分层

TCP/IP协议族按照层次由上到下，层层包装。

应用层:

向用户提供一组常用的应用程序，比如电子邮件、文件传输访问、远程登录等。远程登录TELNET使用TELNET协议提供在网络其它主机上注册的接口。TELNET会话提供了基于字符的虚拟终端。文件传输访问FTP使用FTP协议来提供网络内机器间的文件拷贝功能。

传输层:

提供应用程序间的通信。其功能包括：一、格式化信息流；二、提供可靠传输。为实现后者，传输层协议规定接收端必须发回确认，并且假如分组丢失，必须重新发送。

网络层 ：

负责相邻计算机之间的通信。其功能包括三方面。

一、处理来自传输层的分组发送请求，收到请求后，将分组装入IP数据报，填充报头，选择去往信宿机的路径，然后将数据报发往适当的网络接口。

二、处理输入数据报：首先检查其合法性，然后进行寻径--假如该数据报已到达信宿机，则去掉报头，将剩下部分交给适当的传输协议；假如该数据报尚未到达信宿，则转发该数据报。

三、处理路径、流控、拥塞等问题。

网络接口层：

这是TCP/IP软件的最低层，负责接收IP数据报并通过网络发送之，或者从网络上接收物理帧，抽出IP数据报，交给IP层。

二，uri url urn之间的关系

首先，URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。而URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。而URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如mailto:[e-mail]。也就是说，URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。

在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的，schema必须被指定。

ok，现在回答文章开头提出的问题，到底是imgUrl好呢，还是imgUri好？显然，如果说imgUri是肯定没问题的，因为即使它实际上是url，那它也是uri的一种。那么用imgUrl有没有问题呢？此时则要看它的可能取值，如果是绝对路径，能够定位的，那么用imgUrl是没问题的，而如果是相对路径，那还是不要用ImgUrl的好。总之，用imgUri是肯定没问题的，而用imgUrl则要视实际情况而定。

第二个，从HttpServletRequest的javadoc中可以看出，getRequestURI返回一个String，“the part of this request’s URL from the protocol name up to the query string in the first line of the HTTP request”，比如“POST /some/path.html?a=b HTTP/1.1”，则返回的值为”/some/path.html”。现在可以明白为什么是getRequestURI而不是getRequestURL了，因为此处返回的是相对的路径。而getRequestURL返回一个StringBuffer，“The returned URL contains a protocol, server name, port number, and server path, but it does not include query string parameters.”，完整的请求资源路径，不包括querystring。

总结一下：URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。URI是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，所以，是绝对的，而通常说的relative URL，则是针对另一个absolute URL，本质上还是绝对的。