|
今天，我们为大家带来《HTTP协议流量分析》短篇系列文章，和大家一起从流量分析角度来学习一下HTTP协议。本篇文章先从总体上给大家讲解HTTP的概念、HTTP数据包解码及简单的分析方法，希望能够对大家在web业务保障及web安全流量分析上有所帮助。
HTTP的全称Hyper Text Transfer Protocol，中文叫超文本传输协议。字面意思理解，就是传输“超文本”的协议。我们搞清其中的2个关键概念：（1）什么叫协议？通信双方都要同时遵守的规则就是协议；（2）什么是超文本Hypertext？超文本简单来说就是内容中有超链接（Hyperlink）的文本，点击超链接就可以跳转到其它内容。超文本的格式有很多，目前最常用的就是超文本标记语言。有点耳熟？对，就是超文本标记语言HTML（Hyper TextMarkup Language）。所以，用一句话来解释HTTP就是：用来在通信双方之间传输HTML的一种协议。磨刀不费砍柴工，我们先来了解一下HTTP的发展历史进程：设计蓝本：HTTP协议使用C/S模型（客户端/服务器），客户端从服务器请求资源，如下图：（1） HTTP协议版本0.9 和HTTP协议版本1.0（前世）1991年http正式诞生！因为不够成熟，甚至没有RFC文档（后来作为MEMO写进RFC），我们把它称作HTTP 0.9版本。最初的HTTP设计十分简陋，采用纯文本的格式，并且客户端只有GET方法从服务器获取HTML文档，并且在响应请求后立即关闭连接。此时HTTP的特征如下： 随着互联网的蓬勃发展，0.9版本的ASCII编码也不能满足各种场景的数据编码，于是HTTP1.0引入了请求头部和响应头部，让客户端和服务器可以进行协商，请求的文件类型、文件的编码方式、文件的压缩方式等等。进一步，如果服务器不能满足客户端的请求，就会告知客户端具体的原因，因此引进了状态码。为了优化客户感受，引进了缓存机制等等。（关于HTTP0.9和HTTP1.0的详细信息，可查阅RFC1945） 1997年，HTTP发布RFC2616，也是直到现在还在广泛使用的HTTP协议版本1.1正式发布！（时至今日，90%以上的网站仍然运行HTTP版本1.1），以下是它在HTTP1.0版本基础上的功能进阶：注：本文后面的介绍，全部基于HTTP协议版本1.1。（3） HTTP协议版本2和HTTP协议版本3（未来）在HTTP1.1多年的使用中，发现很多性能可作优化的地方，HTTP协议版本2就引入了多路复用等功能。还可以设置请求的优先级、压缩头字段、服务器推送等，目标就是把协议性能做到极致。但由于HTTP协议是建立在TCP基础上的，所以HTTP2在性能上始终会受到TCP传输性能的限制。为了摆脱TCP传输性能的限制，HTTP3构建在UDP协议之上，但UDP协议是不可靠传输，因此在UDP和HTTP3之间引入了QUIC协议，努力抛弃TCP的缺点，保留TCP的优点。但HTTP3还不成熟，暂时只算一种尝试和构想。上文中有提到，HTTP采用了C/S模型，即请求/响应模型，简单来说就2步：1、客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。2、服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。但因为HTTP是基于TCP的应用层协议，因此在一次完整的交互中，数据包交互如下：在流量分析工具中看到的一次实际HTTP交互流量如下：注意：从上面的流量，我们可以看到HTTP回话交互流量是由“HTTP”和“TCP”共同组成，因此在使用过滤器进行数据包过滤时，不要用“protocol=HTTP”来进行过滤，推荐使用“port=80”（如果使用了非标准HTTP端口，端口按需求进行改变）来进行HTTP数据包的过滤。这样我们才能更好地结合实际业务进行流量分析。要深入了解HTTP客户端和服务器端是如何协商工作的，就必须去解码HTTP请求和HTTP响应，下面我们就来深入探索一下它们的解码：第一部分：请求行。用来说明请求类型，要访问的资源，以及当前所使用的HTTP版本。上图中：请求类型为“POST”，“/user/login”为要访问的资源路径，最后的“HTTP/1.1”说明使用的是HTTP1.1版本。注：HTTP协议的请求类型，我们将在本系列第二篇文章中详细讲解。第二部分：请求头部。紧接着请求行（即第一行）之后的部分，用来说明客户端发给服务器的附加信息（包括各种首部字段，如资源描述、服务器名称、浏览器类型等）。该信息由你的浏览器来定义，并且在每个请求中自动发送。注：请求头部字段，我们将在本系列第三篇文章中详细讲解。第三部分：空行。没有实际意义，用于把“请求头部”和“请求主体”隔离开。但请求头部后面的空行是必须的，即使第四部分的请求数据为空，也必须有空行。第四部分：请求主体也叫请求数据，可以添加任意的其他数据。如上图中，客户端向服务器提交用户名和密码，用于登陆。通过HTTP请求包的解码，我们可以看到，实际HTTP的请求就是和服务器进行协商，告知服务器：要访问的服务器名字；浏览器类型；请求资源的位置、类型、长度、更新时间；支持的编解码方式；支持的语言等等。服务器接收到请求后，将“阅读理解”所有的请求信息，然后按信息查找资源、对资源编码加压、发送资源等。第一部分：状态行。由HTTP协议版本号、状态码、状态消息
三部分组成。上图中状态码为200，状态消息为OK。状态码代表服务器是否正常接收请求，并响应数据。状态消息是解释当前状态码的含义。注：我们将在本系列第二篇文章中详细讲解HTTP状态码。第二部分：消息报头，用来说明客户端要使用的一些附加信息（包括各种响应字段，如资源描述、服务器类型等）。如上图中：Date：生成响应的日期和时间；Content-Type：指定了MIME类型的HTML（text/html），编码类型是UTF-8等等。注：各种消息报头字段，我们将在本系列第三篇文章中详细讲解。第四部分：响应正文。服务器返回给客户端的超文本信息。空行后面的部分为响应正文。（上图数据包中的内容我们看不懂，是由于编码的原因，并非是加密数据，浏览器会帮我们翻译）通过对HTTP响应包的解码，我们可以看到服务器是如何答复相应的HTTP请求，也就知道了客户端和服务器是如何遵守“协议”，利用同一种规则进行通信的。在实际工作中，其实我们很少单独对HTTP请求包或HTTP请求包进行分析，更多的，我们回去查看HTTP会话数据流。什么是会话数据流呢？通过一次HTTP通信的五元组（客户端IP地址、服务器IP地址、客户端端口号、服务器端端口号和双方通信的协议，这5个基本信息称为五元组），把所有相同五元组的数据包信合并成数据流消息，就叫会话数据流。在CSNAS中，可以从“数据包视图”选中一个HTTP数据包，右键菜单选择“定位到会话视图”，双击该会话查看数据流。如下图：在会话视图中，双击会话，即可进入“数据流”视图（或选中会话，直接查看下方解码区域）：在“数据流”视图中，我们能清楚的看到HTTP请求的解码和HTTP响应的解码，更便于我们对实际业务性能或安全方面的分析。在流视图中，CSNAS专门设计了一个单独的工具栏，更方便我们操作分析，下面简单对流视图的工具栏说明如下：双击选中的会话后，除“数据流”视图，还可以点击该会话的“数据包”选项卡，可以直接显示该会话的所有数据包，还可以在本会话数据包中再进行二次过滤，如下图：如果是对web应用进行性能分析，可以选“TCP交易列表”选项看，会看到本次HTTP会话的所有数据包交互的详细情况，如下图：
在了解了HTTP协议以后，我们可以通过对HTTP的流量进行分析，解决HTTP相关业务的性能问题、安全问题（攻击研判与定性）、从HTTP流量中还原文件（HTTP是明文的流量）等等。下面举个简单的例子，来加强我们对HTTP协议的认识：举例：在一次巡检中，发现在某一时间点有流量突发的情况，请分析造成流量突发的原因。分析：首先获取到流量突发时间点的流量（由科来回溯分析服务器定位时间并从服务器上下载到相关流量）。查看相关流量的成分（流量协议构成、端点情况、会话情况等），找出造成流量突发的原因。（1）查看流量组成，发现突发流量基本全是HTTP流量：
可以看到产生流量最高的端点为内网主机192.168.10.103及外网主机123.125.9.19。（3）在TCP会话视图中进行排序（因为HTTP流量最大，HTTP是基于TCP）：可以看到，字节数最高的HTTP会话，就是端点视图中我们分析出的两台流量最高主机的会话。从HTTP请求行中，可以看到，是访问了： 123.125.9.19/dl.softmgr.qq.com/original/Audio/QQMusic_Setup_1733.4793_QMgr.exe从URL（下篇文章中详细介绍）中了解到是QQMusic，在数据流中看到确实是以“MZ”开头的PE文件（Windows的可执行文件）。因此我们大概可以确定是内网主机192.168.10.103下载QQMusic造成的流量突发对服务器IP作调研，发现外网IP：123.125.9.19为联通IDC机房IP，并非QQ服务器本身。还原HTTP会话中的exe文件，在虚拟机或沙箱中进行验证（本篇文章不再叙述详细讲解文件还原的过程）。通过本篇文章的讲解，相信大家从流量角度认识了HTTP的概念、HTTP数据包解码及简单的分析方法，后面将再展开给大家说说HTTP请求方法和响应码，以及HTTP头部字段解码这两部分内容。
| 
发表于 2025-2-20 17:05:05