报文解析源码
❶ Android socket源码解析(三)socket的connect源码解析
上一篇文章着重的聊了socket服务端的bind，listen，accpet的逻辑。本文来着重聊聊connect都做了什么？
如果遇到什么问题，可以来本文 https://www.jianshu.com/p/da6089fdcfe1 下讨论
当服务端一切都准备好了。客户端就会尝试的通过 connect 系统调用，尝试的和服务端建立远程连接。
首先校验当前socket中是否有正确的目标地址。然后获取IP地址和端口调用 connectToAddress 。
在这个方法中，能看到有一个 NetHooks 跟踪socket的调用，也能看到 BlockGuard 跟踪了socket的connect调用。因此可以hook这两个地方跟踪socket，不过很少用就是了。
核心方法是 socketConnect 方法，这个方法就是调用 IoBridge.connect 方法。同理也会调用到jni中。
能看到也是调用了 connect 系统调用。
文件：/ net / ipv4 / af_inet.c
在这个方法中做的事情如下：
注意 sk_prot 所指向的方法是， tcp_prot 中 connect 所指向的方法，也就是指 tcp_v4_connect .
文件：/ net / ipv4 / tcp_ipv4.c
本质上核心任务有三件:
想要能够理解下文内容，先要明白什么是路由表。
路由表分为两大类：
每个路由器都有一个路由表(RIB)和转发表 (fib表)，路由表用于决策路由，转发表决策转发分组。下文会接触到这两种表。
这两个表有什么区别呢？
网上虽然给了如下的定义：
但实际上在Linux 3.8.1中并没有明确的区分。整个路由相关的逻辑都是使用了fib转发表承担的。
先来看看几个和FIB转发表相关的核心结构体：
熟悉Linux命令朋友一定就能认出这里面大部分的字段都可以通过route命令查找到。
命令执行结果如下：
在这route命令结果的字段实际上都对应上了结构体中的字段含义：
知道路由表的的内容后。再来FIB转发表的内容。实际上从下面的源码其实可以得知，路由表的获取，实际上是先从fib转发表的路由字典树获取到后在同感加工获得路由表对象。
转发表的内容就更加简单
还记得在之前总结的ip地址的结构吗？
需要进行一次tcp的通信，意味着需要把ip报文准备好。因此需要决定源ip地址和目标IP地址。目标ip地址在之前通过netd查询到了，此时需要得到本地发送的源ip地址。
然而在实际情况下，往往是面对如下这么情况：公网一个对外的ip地址，而内网会被映射成多个不同内网的ip地址。而这个过程就是通过DDNS动态的在内存中进行更新。
因此 ip_route_connect 实际上就是选择一个缓存好的，通过DDNS设置好的内网ip地址并找到作为结果返回，将会在之后发送包的时候填入这些存在结果信息。而查询内网ip地址的过程，可以成为RTNetLink。
在Linux中有一个常用的命令 ifconfig 也可以实现类似增加一个内网ip地址的功能：
比如说为网卡eth0增加一个IPV6的地址。而这个过程实际上就是调用了devinet内核模块设定好的添加新ip地址方式，并在回调中把该ip地址刷新到内存中。
注意 devinet 和 RTNetLink 严格来说不是一个存在同一个模块。虽然都是使用 rtnl_register 注册方法到rtnl模块中：
文件：/ net / ipv4 / devinet.c
文件：/ net / ipv4 / route.c
实际上整个route模块，是跟着ipv4 内核模块一起初始化好的。能看到其中就根据不同的rtnl操作符号注册了对应不同的方法。
整个DDNS的工作流程大体如下：
当然，在tcp三次握手执行之前，需要得到当前的源地址，那么就需要通过rtnl进行查询内存中分配的ip。
文件：/ include / net / route.h
这个方法核心就是 __ip_route_output_key .当目的地址或者源地址有其一为空，则会调用 __ip_route_output_key 填充ip地址。目的地址为空说明可能是在回环链路中通信，如果源地址为空，那个说明可能往目的地址通信需要填充本地被DDNS分配好的内网地址。
在这个方法中核心还是调用了 flowi4_init_output 进行flowi4结构体的初始化。
文件：/ include / net / flow.h
能看到这个过程把数据中的源地址，目的地址，源地址端口和目的地址端口，协议类型等数据给记录下来，之后内网ip地址的查询与更新就会频繁的和这个结构体进行交互。
能看到实际上 flowi4 是一个用于承载数据的临时结构体，包含了本次路由操作需要的数据。
执行的事务如下：
想要弄清楚ip路由表的核心逻辑，必须明白路由表的几个核心的数据结构。当然网上搜索到的和本文很可能大为不同。本文是基于LInux 内核3.1.8.之后的设计几乎都沿用这一套。
而内核将路由表进行大规模的重新设计，很大一部分的原因是网络环境日益庞大且复杂。需要全新的方式进行优化管理系统中的路由表。
下面是fib_table 路由表所涉及的数据结构：
依次从最外层的结构体介绍：
能看到路由表的存储实际上通过字典树的数据结构压缩实现的。但是和常见的字典树有点区别，这种特殊的字典树称为LC-trie 快速路由查找算法。
这一篇文章对于快速路由查找算法的理解写的很不错: https://blog.csdn.net/dog250/article/details/6596046
首先理解字典树：字典树简单的来说，就是把一串数据化为二进制格式，根据左0，右1的方式构成的。
如图下所示：
这个过程用图来展示，就是沿着字典树路径不断向下读，比如依次读取abd节点就能得到00这个数字。依次读取abeh就能得到010这个数字。
说到底这种方式只是存储数据的一种方式。而使用数的好处就能很轻易的找到公共前缀，在字典树中找到公共最大子树，也就找到了公共前缀。
而LC-trie 则是在这之上做了压缩优化处理，想要理解这个算法，必须要明白在 tnode 中存在两个十分核心的数据：
这负责什么事情呢？下面就简单说说整个lc-trie的算法就能明白了。
当然先来看看方法 __ip_dev_find 是如何查找
文件：/ net / ipv4 / fib_trie.c
整个方法就是通过 tkey_extract_bits 生成tnode中对应的叶子节点所在index，从而通过 tnode_get_child_rcu 拿到tnode节点中index所对应的数组中获取叶下一级别的tnode或者叶子结点。
其中查找index最为核心方法如上，这个过程，先通过key左移动pos个位，再向右边移动（32 - bits）算法找到对应index。
在这里能对路由压缩算法有一定的理解即可，本文重点不在这里。当从路由树中找到了结果就返回 fib_result 结构体。
查询的结果最为核心的就是 fib_table 路由表，存储了真正的路由转发信息
文件：/ net / ipv4 / route.c
这个方法做的事情很简单，本质上就是想要找到这个路由的下一跳是哪里？
在这里面有一个核心的结构体名为 fib_nh_exception 。这个是指fib表中去往目的地址情况下最理想的下一跳的地址。
而这个结构体在上一个方法通过 find_exception 获得.遍历从 fib_result 获取到 fib_nh 结构体中的 nh_exceptions 链表。从这链表中找到一模一样的目的地址并返回得到的。
文件：/ net / ipv4 / tcp_output.c
❷ OkHttp源码分析：五大拦截器详解
主要完成两件事： 重试与重定向
重试与重定向拦截器主要处理Response，可以看到RouteException和IOException都是调用了recover，返回true表示允许重试。允许重试—>continue—> while (true)—>realChain.proceed，这就完成了重试的过程。
接着看重定向
重定向总结
另附HTTP响应状态码分类：
小结： RetryAndFollowUpInterceptor是整个责任链中的第一个，首次接触到Request和最后接收Response的角色，它的主要功能是判断是否需要重试与重定向。
重试的前提是出现了RouteException或IOException，会通过recover方法进行判断是否进行重试。
重定向是发生在重试判定后，不满足重试的条件，会进一步调用followUpRequest根据Response的响应码进行重定向操作。
补全请求头：
小结： BridgeInterceptor是连接应用程序和服务器的桥梁，它为我们补全请求头，将请求转化为符合网络规范的Request。得到响应后：1.保存Cookie，在下次请求会读取对应的cookie数据设置进请求头，默认cookieJar不提供的实现 2.如果使用gzip返回的数据，则使用 GzipSource 包装便于解析。
缓存拦截器顾名思义处理缓存的，但是要建立在get请求的基础上，我们可以去通过okHttpClient.cache(cache)去设置。缓存拦截器的处理流程：
1.从缓存中取出对应请求的响应缓存
2.通过CacheStrategy判断使用缓存或发起网络请求，此对象中的networkRequest代表需要发起网络请求，cacheResponse表示直接使用缓存。
即： networkRequest存在则优先发起网络请求，否则使用cacheResponse缓存，若都不存在则请求失败。
如果最终判定不能使用缓存，需要发起网络请求，则来到下一个拦截器ConnectInterceptor
StreamAllocation对象是在第一个拦截器RetryAndFollowUpInterceptor中初始化完成的（设置了连接池、url路径等），当一个请求发出，需要建立连接，建立连接之后需要使用流来读取数据，这个StreamAllocation就是协调请求、连接与数据流三者之前的关系，它负责为一次请求寻找连接，然后获得流来实现网络通信。
StreamAllocation对象有两个关键角色：
真正的连接是在RealConnection中实现的，连接由ConnectionPool管理。
接着我们看下RealConnection的创建和连接的建立：
streamAllocation.newStream—>findHealthyConnection—>findConnection
findConnection：
①StreamAllocation的connection如果可以复用则复用
②如果connection不能复用，则从连接池中获取RealConnection对象，获取成功则返回
③如果连接池里没有，则new一个RealConnection对象
④调用RealConnection的connect()方法发起请求
⑤将RealConnection对象存进连接池中，以便下次复用
⑥返回RealConnection对象
小结：
ConnectInterceptor拦截器从拦截器链中获取StreamAllocation对象，这个对象在第一个拦截器中创建，在ConnectInterceptor中才用到。
执行StreamAllocation对象的newStream方法创建HttpCodec对象，用来编码HTTP request和解码HTTP response。
newStream方法里面通过findConnection方法返回了一个RealConnection对象。
StreamAllocation对象的connect方法拿到上面返回的RealConnection对象，这个RealConnection对象是用来进行实际的网络IO传输的。
writeRequestHeaders和readResponseHeaders（以Http2Codec为例）
小结： CallServerInterceptor完成HTTP协议报文的封装和解析。
①获取拦截器链中的HttpCodec、StreamAllocation、RealConnection对象
②调用httpCodec.writeRequestHeaders(request)将请求头写入缓存
③判断是否有请求体，如果有，请求头通过携带特殊字段 Expect:100-continue来询问服务器是否愿意接受请求体。（一般用于上传大容量请求体或者需要验证）
④通过httpCodec.finishRequest()结束请求
⑤通过responseBuilder构建Response
⑥返回Response
❸ heapbuffer报文java怎么解析
heap buffer 和 direct buffer区别
在Java的NIO中，我们一般采用ByteBuffer缓冲区来传输数据，一般情况下我们创建Buffer对象是通过ByteBuffer的两个静态方法：
ByteBuffer.allocate(int capacity);
ByteBuffer.wrap(byte[] array);
查看JDK的NIO的源代码关于这两个部分：
/**allocate()函数的源码**/
public static ByteBuffer allocate(int capacity) {
if (capacity < 0)
throw new IllegalArgumentException();
return new HeapByteBuffer(capacity, capacity);
}
/**wrap()函数的源码**/
public static ByteBuffer wrap(byte[] array) {
return wrap(array, 0, array.length);
}
//
public static ByteBuffer wrap(byte[] array,
int offset, int length)
{
try {
return new HeapByteBuffer(array, offset, length);
} catch (IllegalArgumentException x) {
throw new IndexOutOfBoundsException();
}
}
我们可以很清楚的发现，这两个方法都是实例化HeapByteBuffer来创建的ByteBuffer对象，也就是heap buffer. 其实除了heap buffer以外还有一种buffer，叫做direct buffer。我们也可以创建这一种buffer，通过ByteBuffer.allocateDirect(int capacity)方法，查看JDK源码如下：
public static ByteBuffer allocateDirect(int capacity) {
return new DirectByteBuffer(capacity);
}
我们发现该函数调用的是DirectByteBuffer(capacity)这个类，这个类就是创建了direct buffer。
❹ OkHttp源码解析 （三）——代理和路由
初看OkHttp源码，由于对Address、Route、Proxy、ProxySelector、RouteSelector等理解不够，读源码非常吃力，看了几遍依然对于寻找复用连接、创建连接、连接服务器、连接代理服务器、创建隧道连接等逻辑似懂非懂，本篇决定梳理一遍相关的概念及基本原理。
● HTTP/1.1(HTTPS)
● HTTP/2
● SPDY
一个http请求的流程（直连）：
1、输入url及参数；
2、如果是url是域名则解析ip地址，可能对应多个ip，如果没有指定端口，则用默认端口，http请求用80；
3、创建socket，根据ip和端口连接服务器（socket内部会完成3次TCP握手）；
4、socket成功连接后，发送http报文数据。
一个https请求的流程（直连）：
1、输入url及参数；
2、如果是url是域名则解析ip地址，可能对应多个ip，如果没有指定端口，则用默认端口，https请求用443；
3、创建socket，根据ip和端口连接服务器（socket内部会完成3次TCP握手）；
4、socket成功连接后进行TLS握手，可通过java标准款提供的SSLSocket完成；
5、握手成功后，发送https报文数据。
1、分类
● HTTP代理：普通代理、隧道代理
● SOCKS代理：SOCKS4、SOCKS5
2、HTTP代理分类及说明
普通代理
HTTP/1.1 协议的第一部分。其代理过程为：
● client 请求 proxy
● proxy 解析请求获取 origin server 地址
● proxy 向 origin server 转发请求
● proxy 接收 origin server 的响应
● proxy 向 client 转发响应
其中proxy获取目的服务器地址的标准方法是解析 request line 里的 request-URL。因为proxy需要解析报文，因此普通代理无法适用于https，因为报文都是加密的。
隧道代理
通过 Web 代理服务器用隧道方式传输基于 TCP 的协议。
请求包括两个阶段，一是连接（隧道）建立阶段，二是数据通信（请求响应）阶段，数据通信是基于 TCP packet ，代理服务器不会对请求及响应的报文作任何的处理，都是原封不动的转发，因此可以代理 HTTPS请求和响应。
代理过程为：
● client 向 proxy 发送 CONNET 请求（包含了 origin server 的地址）
● proxy 与 origin server 建立 TCP 连接
● proxy 向 client 发送响应
● client 向 proxy 发送请求，proxy 原封不动向 origin server 转发请求，请求数据不做任何封装，为原生 TCP packet.
3、SOCKS代理分类及说明
● SOCKS4：只支持TCP协议（即传输控制协议）
● SOCKS5: 既支持TCP协议又支持UDP协议（即用户数据包协议），还支持各种身份验证机制、服务器端域名解析等。
SOCK4能做到的SOCKS5都可得到，但反过来却不行，比如我们常用的聊天工具QQ在使用代理时就要求用SOCKS5代理，因为它需要使用UDP协议来传输数据。
有了上面的基础知识，下面分析结合源码分析OkHttp路由相关的逻辑。OkHttp用Address来描述与目标服务器建立连接的配置信息，但请求输入的可能是域名，一个域名可能对于多个ip，真正建立连接是其中一个ip，另外，如果设置了代理，客户端是与代理服务器建立直接连接，而不是目标服务器，代理又可能是域名，可能对应多个ip。因此，这里用Route来描述最终选择的路由，即客户端与哪个ip建立连接，是代理还是直连。下面对比下Address及Route的属性，及路由选择器RouteSelector。
描述与目标服务器建立连接所需要的配置信息，包括目标主机名、端口、dns，SocketFactory，如果是https请求，包括TLS相关的SSLSocketFactory 、HostnameVerifier 、CertificatePinner，代理服务器信息Proxy 、ProxySelector 。
Route提供了真正连接服务器所需要的动态信息，明确需要连接的服务器IP地址及代理服务器，一个Address可能会有很多个路由Route供选择（一个DNS对应对个IP）。
Address和Route都是数据对象，没有提供操作方法，OkHttp另外定义了RouteSelector来完成选择的路由的操作。
1、读取代理配置信息：resetNextProxy()
读取代理配置：
● 如果有指定代理（不读取系统配置，在OkHttpClient实例中指定），则只用1个该指定代理；
● 如果没有指定，则读取系统配置的，可能有多个。
2、获取需要尝试的socket地址（目标服务器或者代理服务器）：resetNextInetSocketAddress()
结合Address的host和代理，解析要尝试的套接字地址（ip+端口）列表：
● 直连或者SOCK代理， 则用目标服务器的主机名和端口，如果是HTTP代理，则用代理服务器的主机名和端口；
● 如果是SOCK代理，根据目标服务器主机名和端口号创建未解析的套接字地址，列表只有1个地址；
● 如果是直连或HTTP代理，先DNS解析，得到InetAddress列表（没有端口），再创建InetSocketAddress列表（带上端口），InetSocketAddress与InetAddress的区别是前者带端口信息。
3、获取路由列表：next()
选择路由的流程解析：
● 遍历每个代理对象，可能多个，直连的代理对象为Proxy.DIRECT（实际是没有中间代理的）；
● 对每个代理获取套接字地址列表；
● 遍历地址列表，创建Route，判断Route如果在路由黑名单中，则添加到失败路由列表，不在黑名单中则添加到待返回的Route列表；
● 如果最后待返回的Route列表为空，即可能所有路由都在黑名单中，实在没有新路由了，则将失败的路由集合返回；
● 传入Route列表创建Selection对象，对象比较简单，就是一个目标路由集合，及读取方法。
为了避免不必要的尝试，OkHttp会把连接失败的路由加入到黑名单中，由RouteDatabase管理，该类比较简单，就是一个失败路由集合。
1、创建Address
Address的创建在RetryAndFollowUpInteceptor里，每次请求会声明一个新的Address及StreamAllocation对象，而StreamAllocation使用Address创建RouteSelector对象，在连接时RouteSelector确定请求的路由。
每个Requst都会构造一个Address对象，构造好了Address对象只是有了与服务器连接的配置信息，但没有确定最终服务器的ip，也没有确定连接的路由。
2、创建RouteSelector
在StreamAllocation声明的同时会声明路由选择器RouteSelector，为一次请求寻找路由。
3、选择可用的路由Route
下面在测试过程跟踪实例对象来理解，分别测试直连和HTTP代理HTTP2请求路由的选择过程：
● 直连请求流程
● HTTP代理HTTPS流程
请求url： https://www.jianshu.com/p/63ba15d8877a
1、构造address对象
2、读取代理配置：resetNextProxy
3、解析目标服务器套接字地址：resetNextInetSocketAddress
4、选择Route创建RealConnection
5、确定协议
测试方法：
● 在PC端打开Charles，设置端口，如何设置代理，网上有教程，比较简单；
● 手机打开WIFI，选择连接的WIFI修改网络，在高级选项中设置中指定了代理服务器，ip为PC的ip，端口是Charles刚设置的端口；
● OkHttpClient不指定代理，发起请求。
1、构造address对象
2、读取代理配置：resetNextProxy
3、解析目标服务器套接字地址：resetNextInetSocketAddress
4、选择Route创建RealConnection
5、创建隧道
由于是代理https请求，需要用到隧道代理。
从图可以看出，建立隧道其实是发送CONNECT请求，header包括字段Proxy-Connection，目标主机名，请求内容类似：
6、确定协议，SSL握手
1、代理可分为HTTP代理和SOCK代理；
2、HTTP代理又分为普通代理和隧道代理；普通代理适合明文传输，即http请求；隧道代理仅转发TCP包，适合加密传输，即https/http2;
3、SOCK代理又分为SOCK4和SOCK5，区别是后者支持UDP传输，适合代理聊天工具如QQ；
4、没有设置代理（OkHttpClient没有指定同时系统也没有设置），客户端直接与目标服务器建立TCP连接；
5、设置了代理，代理http请求时，客户端与代理服务器建立TCP连接，如果代理服务器是域名，则解释代理服务器域名，而目标服务器的域名由代理服务器解析；
6、设置了代理，代理https/http2请求时，客户端与代理服务器建立TCP连接，发送CONNECT请求与代理服务器建立隧道，并进行SSL握手，代理服务器不解析数据，仅转发TCP数据包。
如何正确使用 HTTP proxy
OkHttp3中的代理与路由
HTTP 代理原理及实现（一）
❺ 求C# socket 封包拆包源码
看这个题目就知道你对“协议”的概念还不了解。
所谓的封包和拆包，值得是在指定协议下，将若干个不同数据类型的值整合到一个报文帧里面。
拆包是封包的反向过程，将报文帧还原为原始数据。
不论是封包也好拆包也好，都必然是在指定协议下进行的。
脱离协议约定，这两个动作是没有意义的，无法独立存在。
❻ http协议解析 请求行的信息怎么提取 c语言源码
实现步骤：
1）用Wireshark软件抓包得到test.pcap文件
2）程序：分析pcap文件头 -> 分析pcap_pkt头 -> 分析帧头 -> 分析ip头 -> 分析tcp头 -> 分析http信息
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
#include<netinet/in.h>
#include<time.h>
#define BUFSIZE 10240
#define STRSIZE 1024
typedef long bpf_int32;
typedef unsigned long bpf_u_int32;
typedef unsigned short u_short;
typedef unsigned long u_int32;
typedef unsigned short u_int16;
typedef unsigned char u_int8;
//pacp文件头结构体
struct pcap_file_header
{
bpf_u_int32 magic; /* 0xa1b2c3d4 */
u_short version_major; /* magjor Version 2 */
u_short version_minor; /* magjor Version 4 */
bpf_int32 thiszone; /* gmt to local correction */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
bpf_u_int32 snaplen; /* max length saved portion of each pkt */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
};
//时间戳
struct time_val
{
long tv_sec; /* seconds 含义同 time_t 对象的值 */
long tv_usec; /* and microseconds */
};
//pcap数据包头结构体
struct pcap_pkthdr
{
struct time_val ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};
//数据帧头
typedef struct FramHeader_t
{ //Pcap捕获的数据帧头
u_int8 DstMAC[6]; //目的MAC地址
u_int8 SrcMAC[6]; //源MAC地址
u_short FrameType; //帧类型
} FramHeader_t;
//IP数据报头
typedef struct IPHeader_t
{ //IP数据报头
u_int8 Ver_HLen; //版本+报头长度
u_int8 TOS; //服务类型
u_int16 TotalLen; //总长度
u_int16 ID; //标识
u_int16 Flag_Segment; //标志+片偏移
u_int8 TTL; //生存周期
u_int8 Protocol; //协议类型
u_int16 Checksum; //头部校验和
u_int32 SrcIP; //源IP地址
u_int32 DstIP; //目的IP地址
} IPHeader_t;
//TCP数据报头
typedef struct TCPHeader_t
{ //TCP数据报头
u_int16 SrcPort; //源端口
u_int16 DstPort; //目的端口
u_int32 SeqNO; //序号
u_int32 AckNO; //确认号
u_int8 HeaderLen; //数据报头的长度(4 bit) + 保留(4 bit)
u_int8 Flags; //标识TCP不同的控制消息
u_int16 Window; //窗口大小
u_int16 Checksum; //校验和
u_int16 UrgentPointer; //紧急指针
}TCPHeader_t;
//
void match_http(FILE *fp, char *head_str, char *tail_str, char *buf, int total_len); //查找 http 信息函数
//
int main()
{
struct pcap_file_header *file_header;
struct pcap_pkthdr *ptk_header;
IPHeader_t *ip_header;
TCPHeader_t *tcp_header;
FILE *fp, *output;
int pkt_offset, i=0;
int ip_len, http_len, ip_proto;
int src_port, dst_port, tcp_flags;
char buf[BUFSIZE], my_time[STRSIZE];
char src_ip[STRSIZE], dst_ip[STRSIZE];
char host[STRSIZE], uri[BUFSIZE];
//初始化
file_header = (struct pcap_file_header *)malloc(sizeof(struct pcap_file_header));
ptk_header = (struct pcap_pkthdr *)malloc(sizeof(struct pcap_pkthdr));
ip_header = (IPHeader_t *)malloc(sizeof(IPHeader_t));
tcp_header = (TCPHeader_t *)malloc(sizeof(TCPHeader_t));
memset(buf, 0, sizeof(buf));
//
if((fp = fopen(“test.pcap”,”r”)) == NULL)
{
printf(“error: can not open pcap file\n”);
exit(0);
}
if((output = fopen(“output.txt”,”w+”)) == NULL)
{
printf(“error: can not open output file\n”);
exit(0);
}
//开始读数据包
pkt_offset = 24; //pcap文件头结构 24个字节
while(fseek(fp, pkt_offset, SEEK_SET) == 0) //遍历数据包
{
i++;
//pcap_pkt_header 16 byte
if(fread(ptk_header, 16, 1, fp) != 1) //读pcap数据包头结构
{
printf(“\nread end of pcap file\n”);
break;
}
pkt_offset += 16 + ptk_header->caplen; //下一个数据包的偏移值
strftime(my_time, sizeof(my_time), “%Y-%m-%d %T”, localtime(&(ptk_header->ts.tv_sec))); //获取时间
// printf(“%d: %s\n”, i, my_time);
//数据帧头 14字节
fseek(fp, 14, SEEK_CUR); //忽略数据帧头
//IP数据报头 20字节
if(fread(ip_header, sizeof(IPHeader_t), 1, fp) != 1)
{
printf(“%d: can not read ip_header\n”, i);
break;
}
inet_ntop(AF_INET, (void *)&(ip_header->SrcIP), src_ip, 16);
inet_ntop(AF_INET, (void *)&(ip_header->DstIP), dst_ip, 16);
ip_proto = ip_header->Protocol;
ip_len = ip_header->TotalLen; //IP数据报总长度
// printf(“%d: src=%s\n”, i, src_ip);
if(ip_proto != 0×06) //判断是否是 TCP 协议
{
continue;
}
//TCP头 20字节
if(fread(tcp_header, sizeof(TCPHeader_t), 1, fp) != 1)
{
printf(“%d: can not read ip_header\n”, i);
break;
}
src_port = ntohs(tcp_header->SrcPort);
dst_port = ntohs(tcp_header->DstPort);
tcp_flags = tcp_header->Flags;
// printf(“%d: src=%x\n”, i, tcp_flags);
if(tcp_flags == 0×18) // (PSH, ACK) 3路握手成功后
{
if(dst_port == 80) // HTTP GET请求
{
http_len = ip_len – 40; //http 报文长度
match_http(fp, “Host: “, “\r\n”, host, http_len); //查找 host 值
match_http(fp, “GET “, “HTTP”, uri, http_len); //查找 uri 值
sprintf(buf, “%d: %s src=%s:%d dst=%s:%d %s%s\r\n”, i, my_time, src_ip, src_port, dst_ip, dst_port, host, uri);
//printf(“%s”, buf);
if(fwrite(buf, strlen(buf), 1, output) != 1)
{
printf(“output file can not write”);
break;
}
}
}
} // end while
fclose(fp);
fclose(output);
return 0;
}
//查找 HTTP 信息
void match_http(FILE *fp, char *head_str, char *tail_str, char *buf, int total_len)
{
int i;
int http_offset;
int head_len, tail_len, val_len;
char head_tmp[STRSIZE], tail_tmp[STRSIZE];
//初始化
memset(head_tmp, 0, sizeof(head_tmp));
memset(tail_tmp, 0, sizeof(tail_tmp));
head_len = strlen(head_str);
tail_len = strlen(tail_str);
//查找 head_str
http_offset = ftell(fp); //记录下HTTP报文初始文件偏移
while((head_tmp[0] = fgetc(fp)) != EOF) //逐个字节遍历
{
if((ftell(fp) – http_offset) > total_len) //遍历完成
{
sprintf(buf, “can not find %s \r\n”, head_str);
exit(0);
}
if(head_tmp[0] == *head_str) //匹配到第一个字符
{
for(i=1; i<head_len; i++) //匹配 head_str 的其他字符
{
head_tmp[i]=fgetc(fp);
if(head_tmp[i] != *(head_str+i))
break;
}
if(i == head_len) //匹配 head_str 成功，停止遍历
break;
}
}
// printf(“head_tmp=%s \n”, head_tmp);
//查找 tail_str
val_len = 0;
while((tail_tmp[0] = fgetc(fp)) != EOF) //遍历
{
if((ftell(fp) – http_offset) > total_len) //遍历完成
{
sprintf(buf, “can not find %s \r\n”, tail_str);
exit(0);
}
buf[val_len++] = tail_tmp[0]; //用buf 存储 value 直到查找到 tail_str
if(tail_tmp[0] == *tail_str) //匹配到第一个字符
{
for(i=1; i<tail_len; i++) //匹配 head_str 的其他字符
{
tail_tmp[i]=fgetc(fp);
if(tail_tmp[i] != *(tail_str+i))
break;
}
if(i == tail_len) //匹配 head_str 成功，停止遍历
{
buf[val_len-1] = 0; //清除多余的一个字符
break;
}
}
}
// printf(“val=%s\n”, buf);
fseek(fp, http_offset, SEEK_SET); //将文件指针 回到初始偏移
}