HTTP 协议

1.1 HTTP协议

---

HTTP协议

Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web）服务器传输文本到本地浏览器的传送协议。

 

HTTP的特性

1.HTTP构建于TCP/IP协议之上，默认端口号是80

2.HTTP是无连接无状态的

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

无状态：HTTP协议是无状态协议。无状态是指协议对于事物处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

 

HTTP请求与响应

客户端Request：

请求行，请求头，空行，请求数据四部分。

服务端 Response：

响应行，响应头，空行，响应体。

 

HTTP状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别：

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

2xx：成功--表示请求已被成功接收，接受

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

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

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

 

200 OK                              //客户端请求成功

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

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

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

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

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

 

HTTP请求方法

根据HTTP标准，HTTP请求可以使用多种请求方法。HTTP1.0定义了三种请求方法：GET，POST和HEAD方法。HTTP1.1新增了五种请求方法：OPTIONS,PUT,DELETE,TRACE和CONNECT方法。

 

GET   请求指定的页面信息，并返回实体主体。

HEAD   类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头。

PST      向指定资源提交数据进行处理请求（例如提交表单或者上传文件）.POST请求可能会导致新的资源的建立和/或已有资源的修改。

PUT      从客户端向服务器传送的数据取代指定的文档的内容。

DELETE   请求服务器删除指定的页面。

OPTIONS  允许客户端查看服务器的性能。

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

 

HTTP工作原理

HTTP协议定义Web客户端如何从Web服务器请求Web页面,以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。                                     以下是HTTP请求/响应的步骤：

1、客户端连接到Web服务器  一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认是80）建立一个TCP套接字连接。例如，http：//www.oakcms.cn。

2、发送HTTP请求 通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

3、服务器接收请求并返回HTTP响应Web服务器解析请求，定位请求资源。服务器将资源本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成，

4、释放连接TCP连接  若connnection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接；若connection模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接受请求；

5、客户端浏览器解析HTML内容客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。例如：在浏览器地址栏键入URL，按下回车之后会经历以下流程：

1）浏览器向DNS服务器请求解析该URL中的域名所对应的IP地址；

2）解析出IP地址后，根据该IP地址和默认端口80，和服务器建立TCP连接；

3）浏览器发出读取文件（URL中域名后面部分对应的文件）的HTTP请求，该请求报文作为TCP三次握手的第三个报文的数据发送给服务器；

4）服务器对浏览器请求作出响应，并把对应的html文本发送给浏览器；

5）释放TCP连接；

6）浏览器将该html文件并显示内容；

get和post的区别

从原理性看：

根据HTTP规范，GET用于信息获取，而且应该是安全和幂等的

根据HTTP规范，POST请求表示可能修改服务器上资源的请求

从表面上看：

GET请求的数据会附在URL后面，POST的数据放在HTTP包体

POST安全性比GET安全性高

 

持久连接

我们知道 HTTP协议采用“请求-应答”模式。当使用普通模式，即非Keep-Alive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

在HTTP版本中，并没有官方的标准来规定Keep-Alive如何工作，因此实际上它是被附加到HTTP1.0协议上。如果客户端浏览器支持Keep-Alive，那么就在HTTP请求头中添加一个字段 Connection：Keep-Alive，当服务器收到附带有Connection：Keep-Alive的请求时，它也会在响应头中添加一个同样的字段来使用Keep-Alive。这样一来，客户端和服务器之间的HTTP连接就会被保持，不会断开（超过Keep-Alive规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

在HTTP1.1版本中，默认情况下所有连接都被保持，如果加入“Connection：close”才关闭。目前大部分浏览器都是用HTTP1.1协议，也就是说默认都会发起Keep-Alive的连接请求了，所以是否能完成一个完整的Keep-Alive连接就看服务器设置情况。

由于HTTP1.0没有官方的Keep-Alive规范，并且也已经基本被淘汰，以下讨论均是针对HTTP1.1标准中的Keep-Alive展开的。

注意：

1）HTTP Keep-Alive 简单说就是保持当前的TCP连接，避免了重新建立连接。

2）HTTP长连接不可能一直保持，例如Keep-Alive：timeout=5，max=100，表示这个TCP通道可以保持5秒，max=100，表示这个长连接最多接收100次请求就断开。

3）HTTP是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive没能改变这个结果。另外，Keep-Alive也不能保证客户端和服务器之间的连接一定是活跃的，在HTTP1.1版本中也是如此。唯一能证明的就是当连接被关闭时你能得到一个通知，所以不应该让程序依赖于Keep-Alive的保持连接特性，否则会有意想不到的后果。

4）使用长连接之后，客户端、服务端怎么知道本次传输结果呢？俩部分：

1.判断传输数据是否达到了Content-Length指示的大小；

2.动态生成的文件没有Content-Length，它是分块传输（chunked），这时候就要根据chunked编码来判断，chunked编码的数据在最后一个空chunked块，表明本次传输数据结束。

 

Transfer-Encoding

Transfer-Encoding是一个用来标识HTTP报文传输格式的头部值。尽管这个取值理论上可以有很多，但是当前的HTTP规范里实际上定义了一种传输取值-----chunked。

如果一个HTTP消息（请求消息或应答消息）的Transfer-Encoding消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0的块为结束。

每一个非空的块都以该快包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF（回车及换行），然后是数据本身，最后块CRLF结束。在一些现实中，块大小和CRLF之间填充有白空格（0x20）。

最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。消息最后以CRLF结尾。

注意：chunked和multipart 俩个名词在意义上游类似的地方，不过在HTTP协议当中这俩个概念则不是一个类别的。multipart是一种Content-Type，标识HTTP报文内容的类型，而chunked是一种传输格式，标示报文将以何种方式进行传输。

 

HTTP  Pipelining（HTTP管线化）

 

默认情况下HTTP协议中每个传输层连接只能承载一个HTTP请求和响应，浏览器会在收到上一个请求的响应之后，再发送下一个请求。在使用持久连接的情况下，某个连接上消息的传递类似于 请求1——响应1——请求2——响应2——请求3——响应3.HTTP Pipelining（管线化）是将多个HTTP请求整批提交的技术，在传送过程中不需等待服务端的回应。使用HTTP Pipelining技术之后，某个连接上的消息变成了类似这样请求1——请求2——请求3——响应1——响应2——响应3。

注意下面几点:

1)管线化机制通过持久连接（persistent connection）完成，仅HTTP/1.1 支持此技术（HTTP/1.0不支持）

2）只有GET和HEAD请求可以进行管线化，而POST则有所限制

3）初次创建连接时不应启动管线机制，因为对方（服务器）不一定支持HTTP/1.1版本的协议

4）管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序并未改变

5）HTTP/1.1要求服务器端支持管线化，但并不要求服务器端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可

6）由于上面提到的服务器端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务器端和代理程序对管线化的支持并不好，因此现代浏览器如Chrome和Firefox默认并未开启管线化支持