2019独角兽企业重金招聘Python工程师标准>>> 
前面几篇文章铺垫了一大批的协议讲解，主要是为了提取pcap文件中http协议附加的资源。
1、解析pcap文件，分为文件格式头，后面就是数据包头和包数据了
2、分析每个包数据，数据中第一部分是以太网帧，ip协议头，tcp协议头，tcp携带的实际数据（当然这里只是分析的是以太网帧下的tcp协议，蓝牙也有专门的帧格式，以太网帧中也还有其他协议，比如arp，这里只是专门介绍这些）
这几步就是协议的分析，都很简单，最难的就是tcp数据的整合，因为一大段数据tcp会分成好几段去发送，这就需要了解tcp连接传输断开过程中seq的变化了，前文已经提到了。简单思路如下：
1、搜索tcp协议，然后判断flag是不是SYN建立连接，此时记下seq
2、然后seq+1，搜索seq+1的tcp数据包，记做seq1也就是携带数据的TCP包了
3、搜索到携带数据的包，然后seq1+TCP携带数据字节数，记做seq2，提取数据，然后搜索计算后的seq2，依次类推，直接到搜索到flag为FIN（该flag可能还有ACK标记，需要判断有没有数据提取，尤其是服务器返回时），结束搜索，整合数据。
至此一个tcp连接的数据搜索整合完毕了。下面就是分析http协议了，分析出http的头部，这里只分析post提交的，然后http参数，最后就是http附加的资源了。
以上思路看着可行，只是在实际分析中问题很多
1、首先数据分析效率很慢，需要搜索整个抓包文件，由于服务器的请求太多，大多都是向外发送图片和附件，十几秒的实际抓了八十多兆数据，搜索文件，然后提取数据加入到ArrayList中效率很慢，而且占用大量内存。
2、数据慢还不是致命的缺点。通过分析tcp协议，然后对携带数据的TCP包提取前四个字节，判断是不是POST，然后提取出请求的URL。这种方法得到的URL数量明显大于上面得到的，而且上面得到的附件许多损坏的。通过对损坏的附件16进制数据分析，发现附件中包含很多POST请求，也就是一个TCP连接中进行了多次的POST提交，这种靠上面的方法是分析不出来的。
根据上面的缺点，编程思路如下
1、通过 FileChannel 读取数据，支持大文件，再就是通过红色标记的方法提取URL，这样不会漏掉。
2、提取的URL关联上该TCP包在文件的position，同时关联上TCP包的seq，然后一次只提取十个，可以更多，只是价格限制，避免一次扫描整个文件。
3、以前是以TCP包flag为SYN开始搜索的，限制根据URL所在的包进行搜索，搜索到什么位置呢，搜索到下一个URL的seq或者FIN标记，这样就同时支持一个TCP连接里包含单个或者多个HTTP请求的情况了。
通过position去访问数据，每次打开就超快了，知道TCP包的位置就可以直接访问TCP包的数据了，比扫描整个文件，全部提取出来是快多了。然后通过position和TCP携带的数据字节数，就可以推断出下一个数据包的位置，向后推测数据很方便，向前就需要提前记录position了。
只提取POST附加文件写入硬盘，80.8M的抓包文件，提取出38.1M的数据，总工耗时4942毫秒。
最后将信息自动插入到Excel表格中，附件资源写入到文件，然后将文件链接写入Excel表格。其他字符串搜索交给Excel表格去做吧。
wireshark是支持导出http提交的附件了，不过只能是单个提取，上面是给批量导出一个思路.
事后注：最后通过另一种方法获取的附加数据的边界，抛弃了通过下一个数据包seq的方法，那就是根据http的参数Content-Length，如果组合的信息完整了，就是一个post请求的结束。
