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。