2、某一种方法的高频出现（比如说post提交数据的方法（例如HTTP-TunnelNG 中，就是完全使用POST 方法打包和传输数据的），还比如说PUT，因为 PUT也可以带消息主体，而且 HTTP 隧道也可以把需要传输的数据放到首部的赋值里，这样一来不但会使非 POST，非 PUT 方法高频出现，也会引起首部赋值异常）
虽然如今 HTTP-TunnelClient.exe 在 HTTP 协议头部的构造方面也更加考究了，但在样本数据看来，POST 的使用还是相当频繁（浏览器 50 天的样本含有 301 个 POST，HTTP-TunnelClient.exe 3 天就 3234 个 POST）
在浏览网页时，我们有时会向服务器提交一些表单，或者在 bbs 论坛上发帖子。 这些时候，浏览器会使用 HTTP 协议的 POST 方法来提交数据；但是，我们提交表单也好，还是发帖子也好，都不会经常连续不断的提交数据；因此在正常情况下，POST 方法不会经常连续出现。但是有些“模仿过分”的 HTTP 隧道，为了假装浏览器在提交数据，也使用 POST 方法（其实他完全可以不使用 POST 也照样传递数据，所以说它“模仿过分”）；但这些 HTTP 隧道经常有连续不断的数据要打包发送出去，这就造成 POST 方法的泛滥。
优缺点：
若是HTTP隧道有意的模仿了浏览器的常见方法-首部，首部-首部匹配，就会降低头部分析的成功率。当然这也是必然的，因为我们检测头部的异常就是要看它距离浏览器的正常标准有多远，如果它也在有意的靠拢这个标准，且做的很考究，那检测成功率降低也是符合规律的。但我们不必担心的是，目前绝大多数 HTTP 隧道的头部做的并没有那样的考究，另一方面要做的那样考究就需要牺牲一部分隧道的效率，增加设计复杂度等等，这并不是 HTTP 隧道开发者所期望的。因此，一般的 HTTP 隧道都不会花力气仔细的模仿浏览器，所以采用这种统一检测匹配异常和高频异常的方法是很有实用价值的
3、首部的赋值异常
对于浏览器的方法-首部等匹配来说存在“对环境不敏感的匹配”，但这里谈 的首部赋值大部分都是对环境敏感的。浏览器的标准样本采自不同用户和不同环 境。不同用户会喜欢上不同的网站，不同的环境中安装了不同版本的操作系统和 其他软件，这些都会使 HTTP 首部的值千变万化，因此我们说首部赋值几乎都是对环境敏感的。但是因为对于一个用户来说，他总是会上一些经常去的网站，他总是不会老是改变操作系统和浏览器，因此一个用户的首部赋值档案就只能适于该用户了。这样，同样基于“正常 HTTP 协议的使用情况”的定义，我们知道，凡是在特定的环境中如果某使用 HTTP 协议的进程的首部赋值里边出现了浏览器中该首部没有的值，那这个进程的首部赋值就属于异常
在 HTTP 隧道中这种异常时有体现。如 Host 首部出现了一个陌生的主机名， Accept 首部出现了未见过的文件类型等等，这些都是极有可能发生的。HTTP 隧道的设计者不可能知道他的软件将会在谁的机上运行，首部到底该取什么值最为隐蔽，他也无法预先知道，因此如果把一个用户的浏览器首部赋值样本与 HTTP 隧道的首部赋值样本作比较，就能看出差异。当然有些首部的值虽然无法预先确定，但是设计者也可以先了解这些首部在实际运用中会较多的取到哪些值，然后
再估计用户可能会与一些用到这些值的 WEB 服务器交互，最后将这些估计值放进 HTTP隧 道 首 部 中 去 。 比 如 Accept 的 值 就 可 以 估 计 是 image/jpeg ，application/x-shockwave-flash 或 image/gif 等等多数时候都会遇到的文件类型，其他有些首部也可以这样估计。当然出现了这种情况是肯定会影响首部赋值的检测，但由于大多数 HTTP 隧道对首部赋值并不很讲究，再加上它们还可能会把某些数据设作首部的值加以传输（比如 GET 方法正常使用频率最高，但基本不带消息体，那么为了隐秘性，就可以把数据设作首部的值加以传输），因此对首部赋值的检测是必不可少的。在首部赋值的异常中，还有一个特殊的首部 Content-Length 需引起关注。之所以关注它，是因为它与数据包尺寸分析有关。单独检测 Content-Length 首部的值，将对头部分析的检测成功率有很大的促进作用。当然没使用到这个首部的 HTTP隧道就不必去谈论，但是使用到这个首部的 HTTP 隧道就大有检测的需要。比如HTTP-TunnelClient.exe 就使用了这个首部，而且它的取值非常怪异，基本上都取的一个较大的定值（在早期版本 HTTP-TunnelNG 中取的定值 40000；在最近的Content-Length 的取值检测中 HTTP-TunnelClient.exe 也获得最高的可疑度，可见开发者一直没注意这个异常）。Content-Length（HTTP 报文消息体的字节数） 首部的取值分布情况会体现 HTTP 隧道的数据包尺寸的表观特征，这个特征是有异于浏览器的。
首部-赋值分析
Content-Length 值分布分析（参差度分布可疑度的算法）
Content-Length 首部的值指明的是 HTTP 报文消息体的字节数。因为浏览器 样本中 Content-Length 首部值的各区间分布情况能够求出，而对象进程的Content-Length 首部值的分布情况也能求出，所以使用参差度分布可疑度的求法，可以计算出 Content-Length 首部值的分布可疑度
算法如下：
把浏览器和某进程的 Content-Length 值的样本分为[0，100]，[101，200]，[201，300]。。。。。。[39801，39900]，[39901，40000]，[40001，+∞]等 401 个区间（当然这些区间是按照实际需要来分的，一般取 0 到 50000 就足够体现出样本差异了）。分析样本，将 Content-Length 值出现在各个区间的次数统计出来，于是得到浏览器 Content-Length 值分布档案1, 2, 3 399, 400, 401c c c ...c c c某进程 Content-Length 值分布档案1, 2, 3 399, 400, 401c ′ c ′ c ′ ...c ′ c ′ c′同时得到浏览器Content-Length首部出现的次数n和某进程Content-Length 首部出现的次数n′然后按下式计算：
算法中区间的划分也可以更细，这随不同的设计需要可以更改。这个算法并 没有在意到底正常情况下 Content-Length 值是一个怎样的分布，而是在肯定 HTTP隧道的 Content-Length 值与正常情况存在差异的前提下进行计算的。这一点可以充分体现出该算法的自适应能力。每个人按自己的喜好都会经常浏览某几
个 WEB服务器上的网页。这些 WEB 服务器发送过来的 HTTP 报文的 Content-Length 值，直观上，体现这几个服务器 WEB 应用程序的打包特征，间接的却体现了用户的行为特点。又因为不同用户有不同的喜好，所以对不同用户采集的 Content-Length值样本只对被采集样本的用户有最大效力。这就是为什么该方法存在自适应性的原因。而且，因为 HTTP 隧道的开发者不可能预测用户的习惯，所以他不能像前边模仿首部匹配和付值那样，去预测和模仿 Content-Length 值的分布。这样，只要HTTP 隧道使用了 Content-Length 首部，那么对 Content-Length 值分布的检测是行之有效的，即具有有效性。
序号 1，2，3 的记录来自于 HTTP-TunnelClient.exe 和其他对象进程同时采 集的样本，序号 4，5，6 的记录是对应于 1，2，3 条记录只改变了HTTP-TunnelClient.exe 的样本得到的结果。可以看出，不同时间采集的HTTP-TunnelClient.exe 样本放到同一个用户环境中去检测，都会体现出很明显的、可疑度差异。这说明，HTTP 隧道的 Content-Length 值分布在任何时候都与正常HTTP 协议使用情况下的分布有着明显的差异。这个差异从表中看，至少波动在 23 到 82 倍于正常情况之间。所以，Content-Length 值分布的检测能比较明显的区别出 HTTP 隧道，为协议头部分析的正确率起到了促进作用。
B：基于签名的检测
基于签名的检测（特征值检测（或者说是基于 HTTP 数据包的外在特性来检 测））
事先定义好一些认为可疑的数据式样（SIGNATURE 或叫PATTERN ）；然后在对 HTTP 数据流的检测中，将数据流中的相关数据与这些式样相匹配，如果匹配上了就认为该数据流是可疑的。例如，我们事先定义好的数据式样有“cat c:” ﹑“cat d:” ﹑“del c:” ﹑“PWD” ﹑“RETR ” ﹑“cmdc:” ﹑“cmd net start”等。在检测时，HTTP 报文主体数据区如果出现了以上的数据样式之一，那么就判定该数据流是存在隧道的。如这个例子，若“cat c:”﹑“cat d:”被匹配上则认为可能该 HTTP 报文的主体数据在请求远程主机显示什么文件，而不是正常的网页请求；若“del c:” ﹑“cmd c:” ﹑“cmd net start”匹配上了则认为该 HTTP 数据包是不安全的，他在操作文件系统或运行某程序，可能有隧道存在；若“PWD” ﹑“RETR ”匹配上了则判定这个 HTTP 数据流可能暗含了 FTP 连接。 （缺点：
a. HTTP 隧道封装的数据可以是任何数据，多样性极强。数据是纷繁复杂的，各种图像，声音，文本等等类型的数据都可以打包到 HTTP 隧道。我们定义的那些式样，无外乎是从内容想去找到一个独特性，然后去判断它是不是 HTTP 隧道。可是 HTTP 隧道本身是一个具有迷惑性的工具，它没有必要告诉你它打包的数据是那种类型的，更何况他还会谎报，比如把文本说成是声音是有可能的。这样，如果我们以这种检测内容的方法去匹配式样，就得对每一个 HTTP 报文进行一次这个处理。这种开销是巨大的。而且面对各种类型的数据，我们在匹配的过程当中会得到大量错误结论。我们可以想象，如果把一个图片的二进制数据当作字符数据来和字符式样比较，就有可能出现“PWD” ﹑“RETR ”等匹配，可它根本就不是文本。再者，即便是文本，哪怕不是有关计算机科学方面的文本，也经常出现这些关键字或缩写，这大大降低了基于签名检测的准确性。b、HTTP 主体数据加密给基于签名检测致命的打击。基于签名的检测事实上就 要对数据的内容进行监测。可是一旦数据被加密，这种方法将完全失效）