使用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.tcpdump.org/linktypes.html， 常见的1就是表示IEEE 802.3 Packet Header 当读取了pcap文件的前24个字节之后，紧接着需要读取16个字节。这16个字节中，incl_len表示packet数据部分的长度。当拿到了Packet Data部分数据的长度。我们同时也就知道了下一个packet header要从哪个位置开始读取。 ...

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链接是否意味有故障？

1. HTTPS域向HTTP域发送请求会被浏览器直接拒绝，HTTP向HTTPS则不会 例如在github pages页面，这是一个https页面，如果在这个页面向http发送请求，那么会直接被浏览器拒绝，并在控制台输出下面的报错信息。 jquery-1.11.3.min.js:5 Mixed Content: The page at 'https://wangduanduan.github.io/ddddddd/' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://cccccc/'. This request has been blocked; the content must be served over HTTPS. 如果你在做第三方集成的系统，如果他们是在浏览器中直接调用你提供的接口，那么最好你使用https协议，这样无论对方是https还是http都可以访问。（相信我，这个很重要，我曾经经历过上线后遇到这个问题，然后连夜申请证书，把http升级到https的痛苦经历） 2. HTTPS的默认端口是443，而不是443 如果443端口已经被其他服务占用了，那么使用其他任何没有被占用的端口都可以用作HTTPS服务，只不过在请求的时候需要加上端口号罢了。

一般使用tcpdump抓包，然后将包文件下载到本机，用wireshark去解析过滤。 但是这样会显得比较麻烦。 ngrep可以直接在linux转包，明文查看http的请求和响应信息。 安装 apt install ngrep # debian yum install ngrep # centos7 # 如果centos报错没有ngrep, 那么执行下面的命令, 然后再安装 rpm -ivh http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm HTTP抓包 -W byline 头信息会自动换行 host 192.168.60.200 是过滤规则 源ip或者目的ip是192.168.60.200 ngrep -W byline host 192.168.60.200 interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( host 192.168.60.200 ) #### T 192.168.1.102:39510 -> 192.168.60.200:7775 [AP] GET / HTTP/1.1. Host: 192.168.60.200:7775. User-Agent: curl/7.52.1. Accept: */*. . # T 192.168.60.200:7775 -> 192.168.1.102:39510 [AP] HTTP/1.1 302 Moved Temporarily. Server: Apache-Coyote/1.1. Set-Cookie: JSESSIONID=211CA612EC681B9FDCE7726B03F42088; Path=/; HttpOnly. Location: http://192.168.60.200:7775/homepage.action. Content-Type: text/html. Content-Length: 0. Date: Fri, 16 Aug 2019 02:16:51 GMT. 过滤规则 按IP地址过滤 ngrep -W byline host 192.168.60.200 # 源地址或者目的地址是 192.168.60.200 按端口过滤 ngrep -W byline port 80 # 源端口或者目的端口是 80 按照正则匹配 ngrep -W byline -q HTTP # 匹配所有包中含有HTTP的 指定网卡 默认情况下，ngrep使用网卡列表中的一个网卡，当然你也可以使用-d选项来指定抓包某个网卡。 ...

图片来自 https://microchipdeveloper.com/ 只不过这个网站访问速度很慢，但是里面的图片非常有意思，能够简洁明了的说明一个概念。 上学的时候，数学老师喜欢在讲课前先讲一些概念，然后再做题。但是我觉得概念并没有那么重要，我更喜欢做题。 但是，当你理解了概念后，再去实战，就有事半功倍的效果。 1. 路由器 路由器（英语：Router，又称路径器）是一种电讯网络设备，提供路由与转送两种重要机制，可以决定数据包从来源端到目的端所经过的路由路径（host到host之间的传输路径），这个过程称为路由；将路由器输入端的数据包移送至适当的路由器输出端（在路由器内部进行），这称为转送。路由工作在OSI模型的第三层——即网络层，例如网际协议（IP）。 路由器用来做网络之间的链接，所以路由器一般至少会链接到两个网络上。常见的就是一边连接外网，一边连接内网。 2. IP地址 3. 交换机 4. 五层网络模型 5. TCP vs UDP 6. TCP 和 UDP 头 7. 常见的端口号 8. 客户端和服务端 9. Socket 10. Socket建立 11. 一个Web服务器的工作过程s step1: 服务器在80端口监听消息 step2: 客户端随机选择一个端口，向服务端发起连接请求 step3: 传输层将消息传输给服务器 服务端建立一个Socket用来和客户端建立通道 step4: 服务器通过socket将html发给客户端 step5: 消息接受完毕，Socket关闭 12 NAT 参考 https://zh.wikipedia.org/wiki/%E8%B7%AF%E7%94%B1%E5%99%A8