Networks

tcpdump-zine.pdf

准备条件 有gcc编译器 安装libpcap包 1.c 试运行 #include <stdio.h> #include <pcap.h> int main(int argc, char *argv[]) { char *dev = argv[1]; printf("Device: %s\n", dev); return(0); } gcc ./1.c -o 1.exe -lpcap demo-libpcap git:(master) ✗ ./1.exe eth0 Device: eth0 第一个栗子非常简单，仅仅是测试相关的库是否加载正确 2.c 获取默认网卡名称 参考 http://www.tcpdump.org/pcap.html

使用tcpdump在服务端抓包，将抓包后的文件在wireshark中打开。 然后选择：Telephony - VoIP Calls，wireshark可以从抓包文件中提取出SIP呼叫列表。 呼叫列表页面 在呼叫列表页面，选择一条呼叫记录，点击Flow Sequence， 可以查看该呼叫的SIP时序图。点击Play Stream， 可以播放该条呼叫的声音。 RTPplay页面有播放按钮，点击播放可以听到通话声音。

tcpdump可以在抓包时，按照指定时间间隔或者按照指定的包大小，产生新的pcap文件。用wireshark分析这些包时，往往需要将这些包做合并或者分离操作。 mergecap 如果安装了Wireshark那么mergecap就会自动安装，可以使用它来合并多个pcap文件。 // 按照数据包中的时间顺序合并文件 mergecap -w output.pcap input1.pcap input2.pcap input3.pcap // 按照命令行中的输入数据包文件顺序合并文件 // 不加-a, 可能会导致SIP时序图重复的问题 mergecap -a -w output.pcap input1.pcap input2.pcap input3.pcap editcap 对于一个很大的pcap文件，按照时间范围分割出新的pcap包 editcap -A '2014-12-10 10:11:01' -B '2014-12-10 10:21:01' input.pcap output.pcap 参考 https://blog.csdn.net/qq_19004627/article/details/82287172

介绍 之所以要写这篇文章，是因为我要从pcap格式的抓包文件中抽取出语音文件。之间虽然对tcp协议有不错的理解，但并没有写代码去真正的解包分析。 最近用Node.js尝试去pacp文件中成功提取出了语音文件。再次做个总结。 预备知识 字节序： 关于字节序，可以参考 https://www.ruanyifeng.com/blog/2016/11/byte-order.html。读取的时候，如果字节序设置错了，就会读出来一堆无法解析的内容 PCAP格式 下面是paap文件的格式。 开局是一个全局的头文件。后续跟着一系列的包头和包体。 Global Header格式 全局头由六个字段组成，加起来一共24个字节。 typedef struct pcap_hdr_s { guint32 magic_number; /* magic number */ guint16 version_major; /* major version number */ guint16 version_minor; /* minor version number */ gint32 thiszone; /* GMT to local correction */ guint32 sigfigs; /* accuracy of timestamps */ guint32 snaplen; /* max length of captured packets, in octets */ guint32 network; /* data link type */ } pcap_hdr_t; magic_number 魔术字符，32位无符号整型，一般是0xa1b2c3d4或者0xd4c3b2a1，前者表示字段要按照大端字节序来读取，后者表示字段要按照小段字节序来读取。 version_major 大版本号，16位无符号整形。一般是2 version_minor 小版本号，16位无符号整形。一般是4 thiszone 时区 sigfigs 实际时间戳 snaplen 捕获的最大的长度 network 数据链路层的类型。参考http://www....

图解包在TCP/IP各个协议栈的流动情况 点击查看【undefined】

IP协议格式 字段说明 Protocol 表示上层协议，也就是传输层是什么协议。 只需要看Decimal这列，常用的有6表示TCP, 17表示UDP, 50表示ESP。 用wireshark抓包的时候，也可以看到Protocol: UDP(17) 参考 https://tools.ietf.org/html/rfc791 https://tools.ietf.org/html/rfc790 https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers

在事务结束之后，仍然保持在打开状态的链接称为持久连接。非持久的链接会在每个事务结束之后就会关闭。 持久连接的好处 避免缓慢的链接建立阶段 避免慢启动的拥塞适应阶段 Keep-Alive 客户端发起请求，带有Connection: Keep-Alive头。客户端在响应头中回应Connection: Keep-Alive。则说明客户端同意持久连接。 如果客户端不同意持久连接，就会在响应头中返回Connection: Close 注意事项 即使服务端同意了持久连接，服务端也可以随时关闭连接 HTTP 1.0 协议，必须显式传递Connection: Keep-Alive，服务端才会激活持久连接 HTTP 1.1 协议，默认就是持久连接 在通信双方中，主动关闭连接的一方会进入TIME_WIAT状态，而被动关闭的一方则不会进入该状态。 TIME_WAIT连接太多 服务端太多的TIME_WAIT连接，则说明连接是服务端主动去关闭的。查看了响应头，内容也是Connection: Close。 我们知道，一般情况下TIME_WAIT状态的链接至少会持续60秒。也就是说该连接占用的内存至少在60秒内不会释放。 当连接太多时，就有可能产生out of memory的问题，而操作系统就会很有可能把这个进程给kill掉，进而导致服务不可用。

在《tcp/ip详解卷一》中，有幅图介绍了TCP的状态迁移，TCP的状态转移并不简单，我们本次重点关注TIME_WAIT状态。 TIME-WAIT 主机1发起FIN关闭连接请求，主机2发送ACK确认，然后也发送FIN。主机1在收到FIN之后，想主机2发送了ACK。 在主机1发送ACK时，主机1就进入了TIME-WAIT状态。 主动发起关闭连接的一方会有TIME-WAIT状态 如果两方同时发起关闭连接请求，那么两方都会进入TIME-WAIT状态 TIME-WAIT的时长在 /proc/sys/net/ipv4/tcp_fin_timeout 中配置，一般是60s 为什么要有TIME-WAIT状态？ 太多TIME-WAIT链接是否意味有故障？