HTTP协议

         HTTP（HyperText Transfer Protocol）协议即超文本传输协议，它是万维网上能够可靠地交换文件（包括文本、声音、图像、等各种多媒体文件）的重要基础。HTTP规定在HTTP客户与HTTP服务器之间的每次交互，都由一个ASCII码串构成的请求和一个规定的通用互联网扩充，即“类MIME（MIME-like）”的响应组成。HTTP报文通常都使用TCP连接传送。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，HTTP协议本身是无连接的。这就是说，虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。

       我们粗略估算一下，从浏览器请求一个万维网文档到收到整个文档所需的时间。用户在点击鼠标链接到某个万维网文档时，HTTP协议首先要和服务器建立TCP连接。这需要使用三报文握手。当建立TCP连接的三报文握手的前两部分完成后（即经过了一个RTT时间后），万维网客户就把HTTP请求报文，作为建立TCP连接的三报文握手中的第三个报文的数据，发送给万维网服务器。服务器收到HTTP请求报文后，就把所请求的文档作为响应报文返回给客户。

这里有图片

       从上图可以看出，请求一个万维网所需的时间是该文档的传输时间（与文档大小成正比）加上两倍往返时间RTT（一个RTT用于连接TCP连接，另一个RTT用于请求和接受万维网文档。TCP建立连接的三报文握手的第三个报文段中的数据，就是客户对万维网文档的请求报文）。

       HTTP/1.0 的主要缺点，就是每请求一个文档就要有两倍RTT的开销。若一个主页上有很多链接的对象（如图片）需要依次进行链接，那么每一次链接下载都导致2 * RTT的开销。另一种开销就是万维网客户和服务器每一次建立新的TCP连接都要分配缓存和变量。万维网服务器往往同时服务于大量客户请求，所以这种非持续连接会使万维网服务器的负担很重。

       HTTP/1.1 协议较好地解决了这个问题，它使用持续连接，就是万维网在发送响应后仍然在一段时间内保持这条连接，使同一个客户（浏览器）和该服务器可以继续在这条连接上传送后续的HTTP请求报文和响应报文。

        HTTP/1.1 协议的持续连接有两种工作方式，即非流水线方式和流水线方式。

非流水线方式特点，是客户在收到前一个响应后才能发出下一个请求。因此，在TCP连接已建立后，客户每访问一次对象都要用去一个RTT。缺点是因为服务器在发送完一个对象后，其TCP连接就处于空闲状态，浪费了服务器资源。

流水线方式的特点，是客户在收到HTTP的响应报文之前就能够接着发送新的请求报文，于是一个接一个的请求报文到达服务器后，服务器就可连续发回响应报文。因此，使用流水线方式时，客户访问所有的对象只需花费一个RTT时间。流水线方式使TCP连接的空闲时间减少，提高了下载文档效率。

HTTP报文结构

HTTP有两类报文：

1. 请求报文—— 从客户向服务器发送请求报文。

2. 响应报文—— 从服务器到客户的回答。

这里有图片

由于HTTP是面向文本的，因此在报文中的每一个字段都是一些ASCII码串，因而各个字段的长度都是不确定的。

HTTP请求报文和响应报文都是由三个部分组成的。他们之间的报文格式区别就是开始行不同。

（1） 开始行     用于区分是请求报文还是响应报文。在请求报文中的开始行叫做请求行，而在响应报文中的开始行叫做状态行。在开始行的三个字段之间都以空格隔开，最后的"CR"和“LF”分别代表“回车”和“换行”。

（2） 首部行     用来说明浏览器、服务器或报文主体的一些信息。

（3） 实体主体    在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。

下面介绍HTTP请求报文的一些主要特点。

请求报文的第一行“请求行”只有三个方法，即方法，请求资源的URL，以及HTTP的版本。

下面为HTTP请求报文的开始行的格式。

 GET  HTTP:// www.baidu.com HTTP/1.1

下面是一个完整的HTTP请求报文的例子：

                                         GET .dir/index.htm HTTP/1.1       {请求行使用了相对的URL}

                                          Host ：www.xyz.edu.cn               {此行是首部行的开始。这里给出了主机的域名}

                                          Connection： close                      {告诉服务器发送完请求的文档后就可以释放连接}

                                          User-Agent：Mozilla/5.0             {表明用户代理是使用火狐浏览器}

                                          Accept-Language：cn                  {表示用户希望优先得到中文版本的文档}

                                                                                                {请求报文的最后一个空行}

       在请求行使用了相对URL（即省略了主机的域名）是因为下面的首部行（第二行）给出了主机的域名。第3行是告诉服务器不使用持续连接，表示浏览器希望服务器在传送完所有请求对象后即关闭TCP连接。这个请求报文没有实体主体。

我们看一下HTTP响应报文的主要特点。

响应报文的第一行就是状态行。

状态行包括三项内容，即HTTP的版本，状态码，以及解释状态码的简单短语。

状态码由三位数字构成。分为5大类：

1XX 表示通知信息，如请求收到了或正在进行处理。

2XX 表示成功，如接受或知道了。

3XX 表示重定向，如要完成请求还必须采取进一步的行动。

4XX 表示客户端的差错，如请求中有错误的语法或不能完成。

5XX 表示服务器的差错，如服务器失效无法完成请求。

下面三种状态行在响应报文中是经常见到的。

HTTP/1.1 202 Accepted           {接受}

HTTP/1.1 400 Bad Request      {错误的请求}

HTTP/1.1 404 Not Found         {找不到}

Cookie的工作方式（存在于客户端）

        因为HTTP是无状态的网络协议，为了记录用户的状态，如购物时的选择等信息，我们引入了Cookie。

       Cookie是这样工作的。当用户A浏览某个使用Cookie的网站时，该网站的服务器就为A生成一个唯一的识别码，并以此作为索引在服务器的后端数据库中产生一个项目。接着在给A的HTTP响应报文中添加一个叫做Set-cookie的首部行。这里的“首部字段名”就是“Set-cookie”，而后面的“值”就是赋予该用户的“识别码”。例如这个首部行是这样的：

                                    Set-cookie：31d4d96e4025981d36

       当A收到这个响应时，其浏览器就在它管理的特定Cookie文件中添加一行，其中包括这个服务器的主机名和Set-cookie后面给出的识别码。当A继续浏览这个网站时，每发送一个HTTP请求报文，其浏览器就会从其Cookie文件中取出这个网站的识别码，并放到HTTP请求报文的Cookie首部行中：

                           Cookie：31d4d96e4025981d36

       于是，这个网站就能够跟踪用户31d4d96e4025981d36（用户A）在该网站的活动。需要注意的是，服务器并不需要知道这个用户的真实姓名和其他信息。但服务器能够知道用户31d4d96e4025981d36在什么时间访问了哪些页面，以及访问的顺序。这样，当A继续在该网站购物时，只要还使用同一个电脑上网，由于浏览器产生的HTTP请求报文中都携带了同样的Cookie首部行，服务器就可利用Cookie来验证出这是用户A。