下面给出几种涉及到http的协议头部异常的情况（区别上面所提到的直接看协议异常）：HTTP-TunnelClient.exe(特别关注) 1、请求方法和首部，首部和首部的搭配异常
这种只需要的是匹配，比如说一个if（A && B）即可
多数 HTTP 隧道在设计时只考虑使用 HTTP 协议封装数据，忽略了方法和首 部，首部和首部的搭配。于是就会出现诸如 HEAD 方法的响应会带消息主 体,If-Modified-Since 与 If-Not-Modified-Since 首部同时出现在一个报文头部等等非常荒谬的情况。当然这已经是比较极端的例子了。大多数情况下，这些在设计上没有考虑方法-首部，首部-首部搭配规范的 HTTP 隧道，会不知不觉的用一些很少出现的方法-首部或首部-首部的搭配。这里说很少出现，是相对于“正常 HTTP 协议的使用情况”而言的，即某用户在使用浏览器的过程中，浏览器接收到的 HTTP报文中很少出现的方法-首部，或首部-首部搭配。那么哪些属于为数较多的搭配，哪些又是为数较少的搭配呢？下表是关于浏览器的 HTTP 协议首部-首部搭配的部分样本数据。如下所示统计信息：
从表中我们可以看到，为数较多的匹配是首部 1 和同一行的首部 2 的出现次数相当的匹配。如 Server 和 Date，Accept 和 Connection，User-Agent 和 Accept 等匹配都属于为数较多的。从这些为数较多的匹配的出现次数上看，首部 1 和首部 2 几乎都是成对出现的。也就是说如果首部 1 出现了，那么首部 2 就几乎没有不出现的可能性。反过来对于较少出现的匹配，如 Server 和 Vary 等，首部 1 的出现几乎不伴有首部 2 的出现。匹配出现的较多或较少是受到多方面因素制约（如大多数WEB 服务器遵守的 HTTP 协议规范，WEB 服务器自身的个性特点，用户喜好上的那些网站等等都会影响匹配的出现频度），因此在另一个环境中采集到的浏览器首部-首部匹配样本可能不会体现出表 5-1 的情况，而体现出样本所在的环境的情况。
下图给出了报文中的首部的各个字段在请求，应答，与主体中出现与否
对于设计上未考虑这些正常匹配的 HTTP 隧道来说，它们在封装数据时可 能是随机的挑选某个方法和某些首部，也可能是固定的就用某个方法和某些首部，还可能是在自己已选中的方法和首部中随便的挑选。这样，这些“胡乱”搭配的组合就不可能出现类似表 5-1 列出的那些匹配情况。这里关键在于“胡乱”搭配的组合体现 HTTP 隧道自身的特点，它完全不顾，也不可能顾及到实际环境中用户的行为特点。因此由用户实际行为产生的浏览器标准样本中的匹配情况就一定会和这些“胡乱”搭配的组合情况有很大的差距。根据“正常 HTTP 协议的使用情况”的定义，这个差距越大，就越是异常
方法-首部，首部-首部匹配异常是针对大多数非专业的 HTTP 隧道而言的
方法-首部匹配，首部-首部匹配可疑度计算的具体分析：（需要用到下图）