HTTP协议分析
摘要
这篇论文分析HTTP的协议工作原理，协议字段的格式及含义，方便更多人了解和学习HTTP协议。这次分析主要使用协议分析工具Wireshark软件和Burpsuit软件，通过过滤得到HTTP协议并进行详细的分析。这篇论文完整的表述出HTTP协议的原理，HTTP工作过程及HTTP协议分析，并且可以使初学协议的人更容易入手，也能为初学者奠定一定的基础。
关键词 HTTP;协议分析;请求;响应
目录
第3章 HTTP协议请求与响应.................................................................................. 5
4.2 HTTP存在的安全问题................................................................................ 12
4.4.2.增加的资源请.................................................................................... 14
4.4.5.缓存（Cache）机制.......................................................................... 15
第1章 绪论
互联网的高速发展使我们的生活变的多姿多彩，用户通过互联网来享受美好时光的同时，帮助我们完成工作的则是服务器，服务器请求和响应方式则是依附于协议之上，所以在这里我引出关键的话题就是HTTP协议。
HTTP协议称为超文本传输协议（hyper text transfer protocol），是互联网中使用最为广泛的传输协议之一。作为超媒体信息系统的网络传输协议 , HTTP工作的层次在 ISO /OSI定义的 7层参考模，是一个在客户端和服务器端请求和应答的标准。由于其简捷、快速的方式，适用于分布式超媒体信息系统。
HTTP协议是从1990年开始使用的,最初的版本是HTTP/0.9,HTTP/1.0是从第一个版本HTTP/0.9发展而来的,对于最初的版本一直没有形成过一个真正的文档,第一个可用的文档出现在1993年(此文档描述了HTTP协议的1.0版本),HTTP协议是由IETF小组于RFC1945中正式提出命名为HTTP/1.0,后来又经过四年的发展,进一步生成的HTTP/1.1。目前正在使用的是HTTP/1.1(其正式文档在1997年的RFC2068中给出)。虽然HTTP协议的推出时间要比FTP和Telnet晚,但HTTP 协议的增长速度是令人吃惊的。据统计通过HTTP协议所产生的数据流量在1995年5月份首次超过了传统的 FTP 协议所产生的数据流量,而且在此后的几年中一直在不断地增长,到1998年HTTP协议所产生的数据占整个互联网数据流量的70%左右，现在其流量已经超过了整个互联网数据流量的80%。
HTTP的性能关系到用户的体验，主要用于从WEB服务器传输超文本到本地浏览器上，让人们一目了然，便于更高效的浏览。人们日常上网均会使用到HTTP协议，但是大多数人对HTTP协议不是很了解，因此对HTTP协议进行详细的介绍和分析，使大家了解其工作的原理。
第2章 HTTP协议原理
2.1 HTTP协议
HTTP协议称超文本传输协议，他是基于TCP连接，是客户端浏览器或其他程序与Web服务器之间的应用层通信协议，也是是用于从WWW服务器传输超文本到本地浏览器的传输协议。WWW服务器使用的主要协议是HTTP协议，由于HTTP协议支持的服务不限于WWW，还可以是其它服务，因而HTTP协议允许用户在统一的界面下，采用不同的协议访问不同的服务，如FTP、Archie、SMTP、NNTP等设计HTTP。
HTTP包含命令和传输信息，由于其简捷、快速的方式不仅可用于Web访问，也可以用于其他因特网/内联网应用系统之间的通信，从而实现各类应用资源超媒体访问的集成。是互联网上应用最广泛的一种协议。
随着互联网的发展HTTP协议也得到了不断的完善与扩展，他的版本由HTTP/0.9第一版本演变到HTTP/1.1版本，由简单的用于网络间原始数据传输进一步改进，允许消息以MIME信息格式存在，也包含了请求与响应范式中的数据传输、修饰等方面的信息。更加严格以确保服务的可靠性。HTTP/1.1版本支持非持续连接和持续连接，可以解决效率低的问题。
2.2 URL的介绍
HTTP使用统一资源标识符（URI）来传输数据和建立连接。URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息。URL（uniform resource locator）统一资源定位符，也称Web地址。
URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL的格式由以下部分组成：协议+“//”+主机域名+：端口号+目录路径+文件名。
协议类型有：HTTP , FTP, NEWS,TELNET。
主机域名：www数据所在的服务器域名
端口：提供端口可以访问服务器上的不同资源，常用的端口号80,8080，Web服务器默认端口号为80。
根据URL可以看出客户端使用的协议是什么，一目了然。
2.3 HTTP的工作过程
图 2-1 HTTP工作工程
（1）地址解析
当客户端通过浏览器访问域名，地址解析将解析域名并且分析协议，端口等信息。
（2）封装数据报
解析完成后，然后结合自己电脑的信息封装成HTTP请求数据报。
（3）建立TCP/IP连接
客户机首先要通过TCP/IP建立连接，即三次握手[见图1-2]。TCP连接的端口号为80。
（4）客户机发送请求命令
建立连接后，客户机发送一个请求给服务器然后等待服务器的响应。
（5）服务器的响应
服务器收到请求后，给予响应信息。
（6）关闭TCP连接
服务器和客户机任何一方发起关闭连接就会关闭连接，完成传输。
图 2-2 TCP三次握手
第一次握手：客户机将标志位SYN置为1，随机产生一个值seq=x，并将该数据包发送给服务器，客户机进入SYN_SENT状态，等待服务器确认。第二次握手：服务器收到数据包后由标志位SYN=1知道客户机请求建立连接，服务器将标志位SYN和ACK都置为1，ack=x+1，随机产生一个值seq=y，并将该数据包发送给客户端以确认连接请求，服务器进入SYN_RCVD状态。第三次握手：客户机收到确认后，检查ack是否为y+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=y+1，并将该数据包发送给服务器，服务器检查ack是否为y+1，ACK是否为1，如果正确则连接建立成功，客户机和服务器进入ESTABLISHED状态，完成三次握手，随后客户机和服务器之间可以开始传输数据了。
第3章 HTTP协议请求与响应
3.1HTTP请求
HTTP请求是客户端向web服务器发送的请求报文。报文的所有字段都是ASCII码。
请求报文的详细格式为：方法[见表3.1]+空格+URL+空格+HTTP版本+信息首部+空行+信息体。
HTTP请求由三部分组成，分别是：请求行、信息首部、请求正文。
请求行包含三个部分：请求方法、URL、HTTP版本。
信息首部格式：首部名+“：”+空格+首部值[见表3.2]。
请求正文：是用来传递请求或响应相关的实体的。
图 3-1 HTTP请求与响应模型
表3.1 HTTP请求方法
方法(操作) | 含义 | 方法(操作) | 含义 |
GET | 取回由URL指定的资源 | HEAD | 查找一个对象的元信息而非本身 |
POST | 附加一个命名资源(如Web页面) | PUT | 请求存储一个Web页面 |
DELETE | 请求HTTP服务器删除在请求消息中表明的资源 | TRACE | 用于测试，要求服务器送回收到的请求 |
CONNECT | 用于代理服务器 |
|
|
表3.2 请求首部
头(header) | 类型 | 说明 |
User-Agent | 请求 | HTTP客户端程序的信息 |
Accept | 请求 | 客户端可以接受的格式，如html |
Accept-Charset | 请求 | 客户可以处理的字符集，如UTF-8 |
Accept-Encoding | 请求 | 客户能处理的页面编码方法，如gzip |
Accept-Language | 请求 | 客户能处理的自然语言，如en(英语)，zh-cn(简体中文） |
Host | 请求 | 客户端主机和端口号。 |
Authorization | 请求 | 客户端权限 |
Cookie | 请求 | 将以前设置的Cookie送回服务器，可用来作为会话信息 |
Date | 请求 | 消息被发送时的日期和时间 |
Range | 请求 | 实体的字节范围请求 |
Referer | 请求 | 请求中URL的原始获取值 |
From | 请求 | 用户电子邮件地址 |
3.2 HTTP响应
接收和解释请求消息后，服务器返回一个HTTP响应消息。
响应报文的详细格式为：HTTP版本+空格+状态码[见表3.3]+空格+状态短语+信息首部+空行+信息体。
HTTP响应也是由三个部分组成，分别是：状态行、响应首部、响应正文。
状态行包含三个部分：协议版本、状态码、状态短语。
响应首部格式：首部名+“：”+空格+首部值[见表3.4]。
表3.3 常见状态码
状态码 | 含义 | 例子 |
1xx | 通知信息 | 100=服务器正在处理客户请求 |
2xx | 成功 | 200=请求成功(OK) |
3xx | 重定向 | 301=页面改变了位置 |
4xx | 客户错误 | 403=禁止的页面； 404=页面未找到 |
5xx | 服务器错误 | 500=服务器内部错误； 503=以后再试 |
表3.4 响应首部
Date | 响应 | 消息被发送时的日期和时间 |
Server | 响应 | 关于服务器的信息 |
Content-Encoding | 响应 | 内容是如何被编码的（如gzip) |
Content-Language | 响应 | 页面所使用的自然语言 |
Content-Length | 响应 | 以字节计算的页面长度 |
Content-Type | 响应 | 页面的MIME类型 |
Last-Modified | 响应 | 页面最后被修改的时间和日期，在页面缓存机制中意义重大 |
Location | 响应 | 指示客户将请求发送给别处，即重定向到另一个URL |
Set-Cookie | 响应 | 服务器希望客户保存一个Cookie |
Accept-range | 响应 | 接受客户请求的范围 |
Age | 响应 | 文档存在寿命 |
Retry-after | 响应 | 服务器可用的日期格式 |
Vary | 响应 | 代理服务器缓存的管理信息 |
3.3 HTTP协议的优缺点
优点：简单灵活：由于HTTP协议的简单，使得HTTP服务器程序规模小而简单，与其他协议相比时间开销较小，HTTP通信速度快，可以有效的处理大量请求。支持客户/服务器模式：HTTP协议是基于TCP连接的应用层协议是以客户/服务器模式工作。支持元信息:HTTP对所有事物处理都加了首部，主数据前面加了一块信息称为元信息，人们可以利用元信息进行有条件的请求。无连接性：每次TCP连接只处理一个请求，客户得到服务器的应答后立即断开。无状态性：HTTP是无状态协议，是指对于事物没有记忆能力，服务器根据请求发送数据，发送完数据后，不记录任何信息。无状态使的客户与服务器连接通信运行速度快，服务器应答也快。
缺点：HTTP原本定位在规模不是太大的分布式超媒体信息系统上的,它的设计目标很大程度上是出于寻找能解决问题的、简单实用的方案,而非建立一个精致、完美的协议。况且设计者当时也并未考虑到日后WWW会发展得如此庞大以至于国际互联网络日益拥挤。 HTTP0.9、HTTP1.0则是在原有基础上进行一些修补,其基本的无连接性、无状态性都未改变。但是,随着网络应用的发展,以及网络带宽的日益拥挤,HTTP1.0的缺陷也随之体现出来。 HTTP的无状态性使得客户与服务器交互的许多历史数据不能保留,缺少历史状态数据意味着如果后续处理需要前面的信息,则它必须重传,这样可能会导致每次连接传送的数据量增大,从而造成浪费。HTTP1.0也没有完善地考虑多级传送代理、缓存机制。这可以概括为两个方面: HTTP协议对事务处理、网络贸易、网络安全的支持不足；HTTP协议的运作机制加剧网络传输带宽的不足。
第4章 HTTP协议分析
4.1详细分析
图 4-1 HTTP请求报文 （POST方法）
下面是请求报文部分字段分析：
（1） TCP头部
源端口为50120随机端口，目的端口为80 是HTTP端口
（2） Request Method请求方法：POST方法4字节
（3） Request URI请求的URL，字节大小不固（POST数据不会显示在url中，而且POST对URL长度无限制）
（4） Accept客户端可以接受的格式：*/* 斜杠前面的是 type（类型），斜杠后面的是 subtype（子类型）
（5）Content-Type媒体类型：二进制文件（post方法无限制，允许二进制数据）
（6） User-Agent 客户端程序的信息
（7）Content-Length 文档长度为151bytes
图 4-2 响应报文分析
下面是响应报文部分字段分析：
（1） Version HTTP 1.1 版本
（2）Status Code 状态码 表示成功
（3） Response Phrase 状态短语 ok
（4）Date 日期
（5）Content-Type 媒体类型 text/plain 将文件设置为纯文本的形式 （POST方法请求头部多了Content-Type和Content-Length两个字段）
（6） Content-Length 文档长度 36
（7） Server 服务器名和版本号 web服务器
图 4- 3 HTTP请求与响应报文 （GET方法）
下面是GET方法的请求报文分析：
（1） Request Method 请求方法 GET
（2） URL （GET对数据长度有限制，可能会产生很长的URL，或许会超过某些浏览器与服务器对URL长度的限制,）
（3）Accept客户端可以接受的格式（GET只允许ASCII字符）
（4） Accept-Language客户端可以接受的语言（zh-CN表示中文，zh-TW表示台湾繁体中文，zh-HK表示香港繁体中文，en-US表示美国英语）
（5） Referer 请求中URI的原始获取处（36.102.84.29 本机的IP地址即WEB服务器的地址，GET方法是请求URL所指定资源的信息）
图 4-4 HTTP响应报文 404
（1） HTTP版本
（2） 状态码 404 资源不存在找不到
（3）状态短语（NOT Found 找不到）
4.2HTTP存在的安全问题
由于HTTP传输数据未加密，数据都是以明文传输，所以在 HTTP 协议下，中间者可以随意嗅探用户搜索内容，窃取隐私甚至篡改网页。因此出现很多安全问题，如CSRF（跨站请求伪造）、Http Heads攻击、（跨站脚本攻击）XSS等等。
CSRF常用特征是欺骗用户浏览器发送HTTP请求到目标站点和涉及到的HTTP请求。不同的HTTP请求方法有不同难易程度的CSRF攻击，浏览器处理不同请求方法的方式不同。
HTTP GET方法进行CSRF攻击，一个简单的包含多个参数的超链接，利用image标签自动加载。
HTTP POST方法对CSRF也有不同难易程度的攻击方法，对于简单的将POST数据编码为查询字符串的方式，使用HTML表单进行CSRF攻击。另一种是利用一个简单的HTML表单发送任意内容，使用ENCTYPE属性可以利用text/plain内容属性区分伪造的请求和合法的请求从而进行攻击。
Http Heads攻击是在HTTP协议的信息首部和信息体中间的空行注入字符完成攻击。这种攻击可以发生在登录时。
XSS攻击是攻击者在网页上发布包含攻击性代码的数据。当浏览者看到此网页时，特定的脚本就会以浏览者用户的身份和权限来执行。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击。
4.3解决问题的方法
防御跨站请求伪造的攻击：验证HTTP Referer字段，在HTTP头中有一个字段叫Referer[见表3.2]，它记录了请求中URL的原始获取值即该HTTP请求的来源地址，验证Referer值可以有效的防止攻击。验证请求中的 token等方式。
HTTP协议首部攻击的预防就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。
另一种最安全的方式就是使用HTTPS协议，在HTTP协议上加了SSL协议依靠证书验证服务器的身份，使访问的信息通过加密而转发。这样大大的增加了安全性，与客户信息的完整性。
4.4 HTTP的新发展
HTTP1.1版本改进了HTTP1.0版本存在的问题，它扩充了以下几个方面：在HTTP1.0、HTTP0.9等版本中,浏览器必须为每一个WWW主页上的文本和该页面上的每一个图片都建立一个单独的连接、请求、接收、断开过程,这种短连接增加了网络传输IP包的数量而拥塞了Internet。与此不同,HTTP1.1提供了持续性连接，允许请求一个web页面的浏览器发起一次连接就可从服务器上下载多个文件。
4.4.1.持续性连接
持续性连接的优越性表现为:
(1)由于减少了打开与关闭 TCP连接的次数,节省了处理机的CPU时间,节省TCP协议控制块占用内存的时间。
(2)一次连接建立后的HTTP请求和应答以流水线(pipeline)方式顺序处理,允许客户陆续发多个请求而无须按次序等待每个请求的应答才能进行下一次请求。这可更有效地使用已建立的TCP连接,节省等待时间,提高一次TCP连接的利用速率。
(3)由TCP连接启动而产生的IP包数目得到减少,并给TCP控制进程以充足的时间制定网络的阻塞状态,从而减少网络阻塞。
(4)持续性连接允许TCP控制进程无需关闭TCP连接就可直接报告差错,避免了重建连接,从而减轻IP报文传输负担。同时,由于将来的HTTP版本可能为了优化性能而引入新特征,当新版本的客户浏览器与旧版本的服务器通信时可能会收到差错报告,由于连接仍然保持,客户浏览就可以使用旧的语法规则重试。这对于HTTP新版本的平稳发展是很有利的。对于持续性连接,当客户请求完成后,即发出关闭连接的消息,二者各自断开连接。同时,客户与服务器通常需要设置超时值,用于撤消那些在限定时间内仍无活动的连接。
4.4.2.增加的资源请求
在原有 GET、HEAD、POST几种方法的基础上新增加有:
(1)OPTIONS
OPTIONS操作用以请求与Request-URI所标识的HTTP请求/应答链接的信息。浏览器使用该操作可在不对资源实体进行操作或传递实体的情况下获得对某一个实体的操作要求、功能选项或服务的能力。
(2)PUTD，ELETE，TRACE[见表3.1]
4.4.3.身份认证
HTTP1.0提出一种简单的“提问-回答”式的基本访问授权方法(BasicAuthenticationScheme)。该方案的过程是: 先由服务器向客户发出身份鉴别请求,再由客户发出确认信息。这种用户口令验证过程最为致命的危险在于,窃听者可以通过物理网络介质或路由设备、中继设备 ,获取用户名及用户口令明文,为此,HTTP1.1提供了一种基于MD5算法的身份鉴别方案DAA( Dig est Access Authenticatio n)[RFC2069],在传输层加密或封装消息包。
4.4.4.内容协商
当服务器能够对客户的请求提供多种表示形式应答时,需要使用内容协商机制,使Web服务器可以从中挑选出能满足用户要求的具有最适合表达形式的资源实体。因为很多时候源服务器或提供缓存的中间服务器并不会有一个统一的最佳资源形式标准,而用户端浏览器也不一定有能力处理所有的实体类型。为此,HTTP1.1规定任何包含信息实体的应答形式都是可协商的,包括出错信息。内容协商机制有三种类型,分别为服务器驱动(server-driven)、用户代理驱动(agent-driven)与透明驱动(transparent driven),这几类协商互不影响,可独立或结合使用。
4.4.5.缓存（Cache）机制
缓存机制提供的功能如下:将先前的客户请求以及请求所对应的Web服务器响应的内容暂时保存在机器的内存或物理存储器中,使得在处理新的客户请求时可以利用。如果新的客户请求与所保存的某个客户请求相同,则缓存机制可提供已保存的该请求所对应的 Web服务器的响应,无需再访问Request-URI所标识的源服务器,这样就可以减轻源服务器的响应负担以及网络拥塞。在HTTP1.1中对缓存机制进行增强,提出复杂的算法与实现机制来完成缓存服务器的运作,主要包括:
(1)过期验证模型(Expiration Model):依据期满时间制定缓存器中的缓存资源是否有相应的有效应答,若有,则可直接返回此应答，不必请求源服务器响应。失效时间的确定方法有二: 一是由源服务器指定,根据源服务器响应信息首部中的Data、Age和Expires信息域计算;二是在源服务器未指定的情况下，由缓存服务器进行启发式猜测。
(2)有效性确认模型(Validaion Model):如果缓存服务器试图使用一个已判别为失效的缓存资源作为应答,则必须向源服务器申请校验,源服务器根据一定的检验信息与校验算法将其与服务器上当前信息比较,如二者相符,则只返回确认报文,否则返回完整的资源报文。并非所有的服务方响应都可被缓存,例如前述的存取验证信息即不被缓存。具有缓存机制的服务器也可以设定只在某一给定时间缓存某一特定响应。
4.4.6.状态控制
目前HTTP协议中是没有状态性的,HTTP服务器仅仅根据当前申请决定响应而不关心以前的查询,服务器也不企图在以后的请求中得到更进一步信息。
参考文献
[1] TCP/IP网络与协议 （第2版）兰少华，杨余旺，吕建勇编著. 清华大学出版社，2017.8重印： 248~256
[2] TCP/IP协议深入分析 许于杰 [M].出版地:清华大学出版社 2012：100~108
[3] Behrouz A.Forouzan . TCP/IP协议族（第4版）[M].译（王海、张娟等）.出版地：清华大学出版社 2011：30~40
[4] 图解TCP/IP （第5版）乌尼日其其格.译 人民邮电出版社 2013 ：216~2328
[5] HTTP权威指南 [美]David Gourley , Brian Totty, Sailu Reddy 赵振平，陈涓.译人民邮电出版社 2012 ：71~120
[6] 姚越，高峰. WindowsServer2008系统管理与服务器配置. 北京：机械工业出版社2011:150~160
[7] 郑娟，余波，杨剑. 网络服务器安装与配置. 北京：电子工业出版社 2015:110~120
1053
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
