HTTP协议分析

此段摘自：http://hi.baidu.com/%C0%E4%D4%C2%B6%C9%D4%C6/blog/item/e2c15c8445b7743267096edc.html

 

一、HTTP协议简述

     HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其它的工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。（我们称这个客户端）叫用户代理（user agent）。应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和（基于）它支持的层。 事实上，HTTP可以在任何其他互联网协议上，或者在其他网络上实现。HTTP只假定（其下层协议提供）可靠的传输，任何能够提供这种保证的协议都可以被其使用。


二、HTTP协议通信过程

当我们在浏览器的地址栏输入“www.baidu.com”然后按回车，这之后发生了什么事，我们直接看到的是打开了对应的网页，那么内部客户端和服务端是如何通信的呢？

1、URL自动解析

HTTP URL包含了用于查找某个资源的足够信息，基本格式如下：HTTP://host[“:”port][abs_path]，其中HTTP表示桶盖HTTP协议来定位网络资源；host表示合法的主机域名或IP地址，port指定一个端口号，缺省80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。

例如：输入www.163.com;浏览器会自动转换成：HTTP://www.163.com/

2、获取IP，建立TCP连接

浏览器地址栏中输入"HTTP://www.xxx.com/"并提交之后，首先它会在DNS本地缓存表中查找，如果有则直接告诉IP地址。如果没有则要求网关DNS进行查找，如此下去，找到对应的IP后，则返回会给浏览器。

当获取IP之后，就开始与所请求的Tcp建立三次握手连接，连接建立后，就向服务器发出HTTP请求。

3、客户端浏览器向服务器发出HTTP请求

一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令，接着以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。

4、Web服务器应答，并向浏览器发送数据

客户机向服务器发出请求后，服务器会客户机回送应答，

HTTP/1.1 200 OK

应答的第一部分是协议的版本号和应答状态码，正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。

Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据

5、Web服务器关闭TCP连接

一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接，然后如果浏览器或者服务器在其头信息加入了这行代码

Connection:keep-alive

TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽。


三、实例分析HTTP通信

     先介绍一个工具，HTTP Analyzer ，为一款实时分析 HTTP/HTTPS 数据流的工具。它可以实时捕捉HTTP/HTTPS 协议数据，可以显示许多信息（包括：文件头、内容、Cookie、查询字符窜、提交的数据、重定向的URL地址），可以提供缓冲区信息、清理对话内容、HTTP状态信息和其他过滤选项。同时还是一个非常有用的分析、调试和诊断的开发工具。

     下面我们访问http://www.google.cn/ ，HTTP analyzer将抓包来分析访问浏览器和服务器通信的过程。


1、   运行HTTP Analyzer，选择菜单Action—start开始抓包；

2、   浏览器中输入 http://www.google.cn/，网页打开后，在HTTP Analyzer中选择Action—stop停止抓包；工具已经详细列出了访问的数据包信息。通过截图见到了解下抓包信息

l           抓包结果和文件头信息（下图）


    



l           一次请求的html正文内容（下图）

    





l           本次请求是否存在cookies信息（下图）







l           一次请求的整个数据包信息，包括头信息和正文(下图)。





    

     你会发现浏览器中只点击了一个超级链接，却发送了多个数据包。那是因为,我们请求的网页文件中有很多图片、音乐、电影等信息时，服务器返回的信息中并不直接包含图片数据，而只是保存该图片的链接，当浏览器进行解释的时候，遇到图片的url时,才向服务器发出对图片的请求信息。

       下面我们来详细分析HTTP的请求和响应信息：

1）HTTP请求消息，当客户端和服务端建立TCP连接后，客户端就会向服务器发送一个请求信息， 如：

       [1] GET / HTTP/1.1

       [2] Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/x-silverlight, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */* 客户端可识别的内容类型列表。

       [3] Accept-Language: zh-cn 客户端所能解释的语言：简体中文

       [4] UA-CPU: x86

       [5] Accept-Encoding: gzip, deflate 客户端可以解释的类型

       [6] User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Maxthon; EmbeddedWB 14.52 from:http://www.bsalsa.com/ EmbeddedWB 14.52; .NET CLR 2.0.50727; InfoPath.1; CIBA) 客户端浏览器型号

       [7] Host: http://www.google.cn/ 提交请求页面

       [8] Connection: Keep-Alive TCP连接保持打开

       [9]

       该请求信息主要由4部分组成：

l           请求方法URI协议/版本：以上代码第[1]行“GET”表示请求方法，，“HTTP/1.1代表协议和协议的版本，HTTP请求可以使用多种请求方法，最常用的为GET和POST方法

l           请求头：[2]-[8]行，包含许多有关客户端环境和请求正文的有用信息。

l           空行 ：[9] 请求头和请求正文之间是一个空行，这个行非常重要，表示请求头已经结束，接下来是正文，这个行非常重要，它表示请求头已经结束，接下来是请求正文。

l           请求正文。请求正文中可以包含客户提交的查询字符串信息，如用户名和密码等。这里没有。

这里有一点值得说明的是:请求方法中的GET和POST方法；

               GET方法是默认的HTTP请求方法，我们日常用GET方法来提交表单数据，然而用GET方法提交的表单数据只经过了简单的编码，同时它将作为URL的一部分向Web服务器发送，因此，如果使用GET方法来提交表单数据就存在着安全隐患上，同时这个URL长度还有限制，不允许超过1k。

               POST方法是GET方法的一个替代方法，它主要是向Web服务器提交表单数据，尤其是大批量的数据。POST方法克服了GET方法的一些缺点。通过POST方法提交表单数据时，数据不是作为URL请求的一部分而是作为标准数据传送给Web服务器，这就克服了GET方法中的信息无法保密和数据量太小的缺点。因此，出于安全的考虑以及对用户隐私的尊重，通常表单提交时采用POST方法。

2）HTTP响应消息，响应跟请求类似，如：

[1]HTTP/1.1 200 OK

[2]Cache-Control: private, max-age=0

[3]Date: Fri, 27 Feb 2009 07:53:36 GMT

[4]Expires: -1

[5]Content-Type: text/html; charset=UTF-8

[6]Set-Cookie: PREF=ID=cc4a31ab6792ef2c:NW=1:TM=1235721216:LM=1235721216:S=q1hQBu-1KdamAWK-; expires=Sun, 27-Feb-2011 07:53:36 GMT; path=/; domain=.google.cn

[7]Content-Encoding: gzip

[8]Server: gws

[9]Transfer-Encoding: chunked

[10]

[11]ddc

该响应信息也以对应的4部分组成：

l           协议状态描述，HTTP/1.1表示协议版本，200 OK表示服务器已经成功处理了客户端发出的请求。200表示HTTP的应答码成功。HTTP应答码由3位数字构成，其中首位数字定义了应答码的类型：

               1XX－信息类(Information),表示收到Web浏览器请求，正在进一步的处理中

               2XX－成功类（Successful）,表示用户请求被正确接收，理解和处理例如：200 OK

               3XX-重定向类(Redirection),表示请求没有成功，客户必须采取进一步的动作。

               4XX-客户端错误(Client Error)，表示客户端提交的请求有错误 例如：404 NOT Found，意味着请求中所引用的文档不存在。

               5XX-服务器错误(Server Error)表示服务器不能完成对请求的处理：如 500

l           响应头：跟请求头一样，它指出服务器的功能，标识出响应数据的细节。

l           空行：也是属于响应头和响应正文之间必须存在的一个空行，表示响应头结束，接下来是响应正文

l           响应正文：也就是服务器返回的网页内容。

根据上文的描述，再结合工具实际验证一回，相信应该能对HTTP协议和其通信流程有个大致的了解。

此段摘自：http://www.cnblogs.com/diyunpeng/archive/2009/12/02/1615065.html

例子：163.com的头部
请求头信息
User-Agent:Mozilla/5.0 (Windows; U; Windows NT 5.2; zh-CN; rv:1.9.1) Gecko/20090624 Firefox/3.5 GTB5
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language:zh-cn,zh;q=0.5
Accept-Encoding:gzip,deflate
Accept-Charset:gb2312,utf-8;q=0.7,*;q=0.7
Keep-Alive:300
Connection:keep-alive
----------------------------------------------------
响应头信息
HTTP/1.0 200 OK
Server: nginx/0.6.36
Date: Wed, 01 Jul 2009 09:56:15 GMT
Content-Type: text/html; charset=GBK
Vary: Accept-Encoding
Expires: Wed, 01 Jul 2009 09:57:35 GMT
Cache-Control: max-age=80
Age: 58
X-Cache: HIT from cache.163.com
Via: 192.168.51.74.nginx, 1.0 cache.163.com (squid/3.0.STABLE13)
Connection: close

----------------------------------------
其中X-Cache反向代理抛出的头，其他的看下面的收藏资料即可。

HTTP 头部解释
============================================================================================================================
1. Accept：告诉WEB服务器自己接受什么介质类型，*/* 表示任何类型，type/* 表示该
类型下的所有子类型，type/sub-type。

2. Accept-Charset： 浏览器申明自己接收的字符集
Accept-Encoding： 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压
缩，支持什么压缩方法（gzip，deflate）
Accept-Language：：浏览器申明自己接收的语言
语言跟字符集的区别：中文是语言，中文有多种字符集，
比如big5，gb2312，gbk等等。

3. Accept-Ranges：WEB服务器表明自己是否接受获取其某个实体的一部分（比如文件
的一部分）的请求。
bytes：表示接受，none：表示不接受。

4. Age：当代理服务器用自己缓存的实体去响应请求时，用该头部表明该实体从产生
到现在经过多长时间了。

5. Authorization：当客户端接收到来自WEB服务器的 WWW-Authenticate 响应时，
用该头部来回应自己的身份验证信息给WEB服务器。

6. Cache-Control：请求：no-cache（不要缓存的实体，要求现在从WEB服务器去取）
max-age：（只接受 Age 值小于 max-age 值，并且没有过期的对象）
max-stale：（可以接受过去的对象，但是过期时间必须小于
max-stale 值）
min-fresh：（接受其新鲜生命期大于其当前 Age 跟 min-fresh 值之和的
缓存对象）
响应：public(可以用 Cached 内容回应任何用户)
private（只能用缓存内容回应先前请求该内容的那个用户）
no-cache（可以缓存，但是只有在跟WEB服务器验证了其有效后，
才能返回给客户端）
max-age：（本响应包含的对象的过期时间）
ALL: no-store（不允许缓存）

7. Connection：请求：close（告诉WEB服务器或者代理服务器，在完成本次请求的响应
后，断开连接，不要等待本次连接的后续请求了）。
keepalive（告诉WEB服务器或者代理服务器，在完成本次请求的
响应后，保持连接，等待本次连接的后续请求）。
响应：close（连接已经关闭）。
keepalive（连接保持着，在等待本次连接的后续请求）。
Keep-Alive：如果浏览器请求保持连接，则该头部表明希望 WEB 服务器保持
连接多长时间（秒）。
例如：Keep-Alive：300

8. Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩
响应中的对象。
例如：Content-Encoding：gzip
Content-Language：WEB 服务器告诉浏览器自己响应的对象的语言。
Content-Length： WEB 服务器告诉浏览器自己响应的对象的长度。
例如：Content-Length: 26012
Content-Range： WEB 服务器表明该响应包含的部分对象为整个对象的哪个部分。
例如：Content-Range: bytes 21010-47021/47022
Content-Type： WEB 服务器告诉浏览器自己响应的对象的类型。
例如：Content-Type：application/xml

9. ETag：就是一个对象（比如URL）的标志值，就一个对象而言，比如一个 html 文件，
如果被修改了，其 Etag 也会别修改， 所以，ETag 的作用跟 Last-Modified 的
作用差不多，主要供 WEB 服务器 判断一个对象是否改变了。
比如前一次请求某个 html 文件时，获得了其 ETag，当这次又请求这个文件时，
浏览器就会把先前获得的 ETag 值发送给 WEB 服务器，然后 WEB 服务器
会把这个 ETag 跟该文件的当前 ETag 进行对比，然后就知道这个文件
有没有改变了。

10. Expired：WEB服务器表明该实体将在什么时候过期，对于过期了的对象，只有在
跟WEB服务器验证了其有效性后，才能用来响应客户请求。
是 HTTP/1.0 的头部。
例如：Expires：Sat, 23 May 2009 10:02:12 GMT

11. Host：客户端指定自己想访问的WEB服务器的域名/IP 地址和端口号。
例如：Host：rss.sina.com.cn

12. If-Match：如果对象的 ETag 没有改变，其实也就意味著对象没有改变，
才执行请求的动作。
If-None-Match：如果对象的 ETag 改变了，其实也就意味著对象也改变了，
才执行请求的动作。

13. If-Modified-Since：如果请求的对象在该头部指定的时间之后修改了，才执行请求
的动作（比如返回对象），否则返回代码304，告诉浏览器该对象
没有修改。
例如：If-Modified-Since：Thu, 10 Apr 2008 09:14:42 GMT
If-Unmodified-Since：如果请求的对象在该头部指定的时间之后没修改过，才执行
请求的动作（比如返回对象）。

14. If-Range：浏览器告诉 WEB 服务器，如果我请求的对象没有改变，就把我缺少的部分
给我，如果对象改变了，就把整个对象给我。 浏览器通过发送请求对象的
ETag 或者 自己所知道的最后修改时间给 WEB 服务器，让其判断对象是否
改变了。
总是跟 Range 头部一起使用。

15. Last-Modified：WEB 服务器认为对象的最后修改时间，比如文件的最后修改时间，
动态页面的最后产生时间等等。
例如：Last-Modified：Tue, 06 May 2008 02:42:43 GMT

16. Location：WEB 服务器告诉浏览器，试图访问的对象已经被移到别的位置了，
到该头部指定的位置去取。
例如：Location：
http://i0.sinaimg.cn/dy/de...

17. Pramga：主要使用 Pramga: no-cache，相当于 Cache-Control： no-cache。
例如：Pragma：no-cache

18. Proxy-Authenticate： 代理服务器响应浏览器，要求其提供代理身份验证信息。
Proxy-Authorization：浏览器响应代理服务器的身份验证请求，提供自己的身份信息。

19. Range：浏览器（比如 Flashget 多线程下载时）告诉 WEB 服务器自己想取对象的
哪部分。
例如：Range: bytes=1173546-

20. Referer：浏览器向 WEB 服务器表明自己是从哪个 网页/URL 获得/点击 当前请求中
的网址/URL。
例如：Referer：http://www.sina.com/

21. Server: WEB 服务器表明自己是什么软件及版本等信息。
例如：Server：Apache/2.0.61 (Unix)

22. User-Agent: 浏览器表明自己的身份（是哪种浏览器）。
例如：User-Agent：Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN;
rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

23. Transfer-Encoding: WEB 服务器表明自己对本响应消息体（不是消息体里面的对象）
作了怎样的编码，比如是否分块（chunked）。
例如：Transfer-Encoding: chunked

24. Vary: WEB服务器用该头部的内容告诉 Cache 服务器，在什么条件下才能用本响应
所返回的对象响应后续的请求。
假如源WEB服务器在接到第一个请求消息时，其响应消息的头部为：
Content-Encoding: gzip; Vary: Content-Encoding 那么 Cache 服务器会分析后续
请求消息的头部，检查其 Accept-Encoding，是否跟先前响应的 Vary 头部值
一致，即是否使用相同的内容编码方法，这样就可以防止 Cache 服务器用自己
Cache 里面压缩后的实体响应给不具备解压能力的浏览器。
例如：Vary：Accept-Encoding

25. Via： 列出从客户端到 OCS 或者相反方向的响应经过了哪些代理服务器，他们用
什么协议（和版本）发送的请求。
当客户端请求到达第一个代理服务器时，该服务器会在自己发出的请求里面
添加 Via 头部，并填上自己的相关信息，当下一个代理服务器 收到第一个代理
服务器的请求时，会在自己发出的请求里面复制前一个代理服务器的请求的Via
头部，并把自己的相关信息加到后面， 以此类推，当 OCS 收到最后一个代理服
务器的请求时，检查 Via 头部，就知道该请求所经过的路由。
例如：Via：1.0 236-81.D07071953.sina.com.cn:80 (squid/2.6.STABLE13)