请问那个大神可以告诉小弟，看连接跟踪的代码，从哪里入手。

nswcfd

从最基本的conntrack逻辑入手，暂时先不用关心exepct/helper/NAT等扩展功能。

基本逻辑很简单，来了报文查表，查到就结束，查不到就新建。（稍微特殊的地方在于有个confirm过程）

额外的复杂度可能来自于生命周期的管理（引用计数、超时、并发考虑等）

nswcfd

不好意思，才看到消息。平时不怎么上qq的。

感觉楼主领导的意思是要在用户态模拟conntrack的逻辑？
那就不需要关心内核的skb到底是怎么回事，又是怎么被驱动+协议栈送给conntrack hook的，只需要知道skb是对数据包的一个抽象就行了。

conntrack的核心就是一个hash表，对五元组做hash求一个key，hash算法可以照抄内核的jhash，也可以自己选择其他的。
用户态做hash表的方法有很多，stl的map+vector应该就够用了。不行的话，照抄内核的hlist也行。

PS，简单模拟的话甚至都不需要hash表，并发数不高的话，简单的线性表（数组或链表）就可以了。

为什么需要conntrack？因为pcap文件中可能有多个会话，需要把属于不同连接的报文区分开来。

什么样的报文属于一个会话？五元组相同的，注意A->B和B->A两个方向的五元组命中同一个会话。
楼主可以选择向conntrack一样，把A->B和B->都插入到hash表（或者线性表）中，这样无论查找A->B还是B->A只需要查询一次。
也可以只插入A->B，查找的时候，先后按照A->B和B->A查询两次，只要有一个命中就算查到。

报文又是什么？pcap库提供了报文的一种表示，就是一定长度的buffer。

所以基本流程就是，在pcap的回调函数里，分析报文，提取ip/tcp头部，拼出五元组，去查找会话表，查不到新建一个，于是报文就跟会话关联了。

那么对于分析html这个任务来说，会话究竟有什么用？说到底就是一句话，存放会话的状态机。
比如tcp的前三个包是个状态机，http header和http body又是状态机，html的标签还是状态机。
这样，根据状态机记录的状态，就知道之前的报文分析到哪一步了。

nswcfd

基于会话分析内容有两大流派：
A。 把连接的报文全部拼接/缓存起来，作为一个整体去分析。
B。 逐包分析，不断更新状态，所谓的流式引擎。
有点像当年的DOM和SAX

nswcfd

对于保存html/jpg这个任务来说，需要在http header包里分析出content-type/content-length，记录文件名，类型，长度（这都是保存在session上的状态，不仅是五元组）。
然后对于后续报文（假设没有tcp乱序\丢包发生），不断追加文件，直到剩余长度（也是状态）小于等于0为止。