HTTP之头部过长和非80端口的报文分析

  本文对抓包过程中遇到的两种情况做了简单的分析：1，HTTP使用非80端口；2，HTTP头部过长导致头部分包传输。

  情况一：


  在wireshark的view->Coloring Rules里面有这个界面。从这幅图可以看出两点：1，不同的颜色表示协议。2，String那一栏表示的是针对该种协议的规则（即wireshark是根据什么条件来判断该报文是什么协议的报文，当然你可以添加新的协议和规则）。有什么用处的，看如下的图：

 


  这是一条使用HTTP协议的流，wirshark将其标记为TCP。经过分析不难发现wireshark中使用TCP的80端口来识别HTTP协议，而图中的流虽然使用的是HTTP协议，但是并没有使用80端口而是使用1028端口，因此wireshark将按照IP层的协议字段将其识别为TCP。但是分析的时候，我们应该尽可能的定位其具体的应用层协议。我们应该知道，这是一条HTTP流，将其改为HTTP的方法是选中无法识别的报文->右键单击->Decode
As->选择相应的应用层协议（当然这也仅仅是为了方便看，这是需要注意的一点），如下图：



  以上的现象是我们联想到了一个问题，即底层的协议是如何承载上层的协议的：在数据链路层，使用两个字节的类型字段表示后续数据类型，比如TYPE:IP(0x0800)；在IP层有专门的8为协议字段表示上层的协议，比如TCP为6；在运输层并没有这样一个协议字段，而是用熟知的端口号来表示协议，SSL为443。这几种方式还是有一定的差异的（我的意思是为什么各层为什么不统一一下，明显端口号增加了应用层协议设计的灵活度）。

  看第二种情况



  提一下前面三个握手包中的长度字段。数据是在以太网上跑的，以太网要求数据范围是46-1500，因此数据部分不足46的要使用padding字段来填充，在第三个握手包中，就出现了6字节填充的情况。因此在使用wireshark抓以太网包的时候最小长度为60=14（以太网头）+6（填充）+20（IP最小）+20（TCP最小），但是你可能会说你的包中存在54个字节的情况，这是什么原因呢？下面的红色解释是转自CSDN，
具有一定的参考价值：

  根据rfc894的说明，以太网封装IP数据包的最大长度是1500字节，也就是说以太网最大帧长应该是以太网首部加上1500，再加上7字节的前导同步码和1字节的帧开始定界符，具体就是：7字节前导同步码
+ 1字节帧开始定界符 + 6字节的目的MAC + 6字节的源MAC + 2字节的帧类型
+1500 + 4字节的FCS。按照上述，最大帧应该是1526字节，但是实际上我们抓包得到的最大帧是1514字节，为什么不是1526字节呢？原因是当数据帧到达网卡时，在物理层上网卡要先去掉前导同步码和帧开始定界符，然后对帧进行CRC检验，如果帧校验和出错，就丢弃此帧。如果校验和正确，就判断帧的目的硬件地址是否符合自己的接收条件（目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等），如果符合，就将帧交给“设备驱动程序”做进一步处理。这时我们抓包的软件才能抓到数据，因此，抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS之外的数据，其最大值是6
+ 6 + 2 + 1500 = 1514。

以太网规定，以太网帧数据域部分最小为46字节，也就是以太网帧最小是 6 + 6 + 2 + 46 + 4 = 64。除去4个字节的FCS，因此，抓包时就是60字节。当数据字段的长度小于46字节时，MAC子层就会在数据字段的后面填充以满足数据帧长不小于64
字节。由于填充数据是由MAC子层负责，也就是设备驱动程序。不同的抓包程序和设备驱动程序所处的优先层次可能不同，抓包程序的优先级可能比设备驱动程序更高，也就是说，我们的抓包程序可能在设备驱动程序还没有填充不到64字节帧的时候，已经捕获了数据。因此不同的抓包工具抓到的数据帧的大小可能不同。（比如，wireshark抓到的可能没有填充数据段，而sniffer抓到的就有填充数据段），（不过根据我的观察wireshark不同的版本抓获的最小数据包的大小好像有60字节也有54字节的情况.....）。

  上述的解释我是部分赞同的，但是对于小于54个字节的包，我的理解和上述还是有点差异的。我在抓包的过程中发现，基本都是下行的包。也就是说上行出去的包，由于优先级关系，填充完毕之后才被捕获；对于下行进来的包，同样的优先级关系，驱动程序会不会去除了填充的部分，然后才被我们抓包软件捕获呢？我觉得我的想法有一定的合理性。（PS：关于winpcap是如何捕获数据的可以参考《原理、实践与WinPcap深入解析》）



  我们姑且认为60-1514是正确的数据范围，因为我们这次讨论的问题与长度关，但是长度只是个引子。首先整个颜色是绿色，还记得我们第一种情况中所提到的情况，wireshark的识别HTTP的原则即端口为80的情况，因此整条流为HTTP流。再看我们包中的数据，第4,5个包，好像与我们通常遇到的情况有所不同。正常情况下，我们所遇到的都是3个握手包之后跟上HTTP的协议请求，为什么这次握手包之后跟上的是分段的包。经过查看包中的数据发现，造成这种情况的原因是GET请求中的URL过长，超过了以太网所能承载的最大数据长度，或者确切的说是超过了TCP所能承载的最大数据长度即1500-20-20=1460，因此需要分段传输。而不巧的是，由于分段将UA的值部分分成了两个部分，那么如果出现这种情况，对于绝大多数的协议识别系统来说，如果该流是简单的基于UA识别，那么将造成识别不了的情况。因为绝大多数的系统并没有类似这种情况的报文重组考虑进去。

  上述的过程中存在着一个问题那就是第4个包为什么被识别成为TCP而第五个包被识别成为HTTP，我是没有想明白（会不会是wireshark解释器的bug），因为并没有研究过wireshark的解释器。以后有机会研究一下，如果哪位大神知道，也请告知一下。还有就是文中有可能会有地方说的不太对，也请指出来。