WireShark 可以监听本机的网卡，也可以监听手机的收集。应用 WireShark 调试真机时不消连接代劳，只须要经由过程 USB 连接到电脑就行，不然就无法调试 4G 收集了。我们可以用 rvictl -s 设备 UDID 敕令来创建一个虚拟的网卡:
rvictl -s 902a6a449af014086dxxxxxx346490aaa0a8739
当然，看手机 UDID 照样挺麻烦的，作为一个懒人，怎么能不消敕令行来完成呢?
instruments -s | awk '{print $NR}' | sed -n 3p | awk '{print substr($0,2,length($0)-2)}' | xargs rvictl -s
如许只要连上手机，就可以直接获取到 UDID 了。
运行敕令后会看到成功创建 rvi0 虚拟网卡的提示，双击 rvi0 那一行即可。
抓包界面
我们重要存眷两个内容，膳绫擎的大年夜红框琅绫擎是数据流，包含了 TCP、DNS、ICMP、HTTP 等协定，色彩花花绿绿，绚丽多彩。一般来说黑色的内容表示碰到缺点，须要重点存眷，其他内容则帮助懂得。反复调试几回今后也就能根本记住各类色彩对应的含义了。
下面的小红框琅绫擎主如果某一个包的数据详解，会根据不合的协定层来划分，比如我选中的 99 号包时一个 TCP 包，可以很清跋扈的看到它的 IP 头部、TCP 头部和 TCP Payload。这些数据须要时可以做更具体的分析，但一般也不消存眷。
一般来说一次请求的数据包会异常大年夜，可能会有上千个，若何找到本身感兴趣的请求呢，我们可以应用之前提到的过滤功能。WireShark 的过滤应用了一套本身定义的语法，不熟悉的话须要上彀查一查或者借助主动补全功能来“望文生义”。
因为是要查看 HTTP 请求的具体细节，我们先得找到请求的网址，然后应用 ping 敕令获得它对应的 IP 地址。这种做法一般没问题，但也不清除有的域名会做一些优化，比如不合的 IP 请求 DNS 解析时返回不合的 IP 地址来包管最佳速度。也就是说手机上 DNS 解析的结不雅并不老是和电脑上的解析结不雅一致。这种情况下我们可以经由过程查看 DNS 数据包来肯定。
比如大年夜图中可以看到 res.wx.qq.com 这个域名解析出了一大年夜堆 IP 地址，而真正应用的仅有前两个。
解析出地址后，我们就可以做简单的过滤了，输入ip.addr == 220.194.203.68:
如许就只显示和 220.194.203.68 主机之间的通信了。留意红框中的 SourcePort，这是客户端端口。我们知道 HTTP 支撑场发请求，不合的并发请求肯定是占用不合的端口。所以在图中看到的高低两个数据包，并非必定是请求与锾螃的关系，他们可能属于两个不合的端口，彼此之间毫无关系，只是正好在时光上最接近罢了。
如不雅只想显示某个端口的数据，可以应用:ip.addr == 220.194.203.68 and tcp.dstport == 58854。
同时我们也可以肯定，如不雅网页已经加载，但 JS 请求还在持续，这就是告白主的网页质量太差导致的。损掉应当由他们承担，我们力所不及。而长时光的白屏则是我们应当重点推敲的问题。
如不雅只想看 HTTP 协定的 GET 请求与锾螃，可以应用 ip.addr == 220.194.203.68 and (http.request.method == "GET" || http.response.code == 200) 来过滤。
如不雅想看丢包方面的数据，可以用 ip.addr == 220.194.203.68 and (tcp.analysis.fast_retransmission || tcp.analysis.retransmission)
以上是笔者在调试过程顶用到比较多的敕令，仅供参考。有兴趣的读者可以自行抓包实验，就不挨个贴图了。
Case1: DNS解析
经由多次抓包后我开端分析那些长时光白屏的网页对应的数据包，不雅然发明不少问题，比如这里:
可以很明显的看到在一大年夜串黑色缺点信息，但如不雅你去调试这些数据包，那么就掉落进陷阱了。DNS 是基于 UDP 的协定，不会有 TCP 重传，所以这些黑色的数据包必定是之前的丢包重传，不消关怀。如不雅只看蓝色的 DNS 请求，就会发明持续发送了几个请求但都没有响应，直到第 12s 才获得解析后的IP 地址。
大年夜 DNS 请求的接收方的地址以 172.24 开首可以看出，这是内网 DNS 办事器，不知道为什么卡了良久。
Case2: 握手响应延迟
下图是一次典范的 TCP 握手时的场景。同时也可以看到第一张图中的 SYN 握手包发出后，过了一秒钟才接收到 ACK。当然了，原因也不清跋扈，只能解释为收集颤抖。
随后我又在 4G 收集下抓了一次包:
此次工作就更离谱了，第二秒发出的 SYN 握手包反复损掉(也有可能是办事端没有响应、或者是 ACK 损掉)，总之客户端赓续重传 SYN 包。
更有意思的是，不雅察 TSval，它表示包发出时的时光戳。我们不雅察这几个值会发明，前几回的距离时光是 1s，后来变成了 2s，4s 和 8s。这不禁让我想起了 RTO 的概念。
我们知道 RTT 表示的是收集请求大年夜提议到接收响应的时光，它是一个跟着收集情况而动态改变的值。TCP 有窗口的概念，对于窗口的第一个数据包，如不雅它无法发送，窗口就不克不及向后滑动。客户端以接收到 ACK 作为数据包成功发送的标记，那么如不雅 ACK 收不到呢?客户端当然不会一向等下去，它会设置一个超不时光，一旦跨越这个时光就认为数据包损掉，大年夜而重传。
推荐阅读
较长的构建时光将会减缓项目标开辟进度，特别是对于大年夜型的项目，app的构建时光长则十几分钟，短则几分钟，长的构建时光已经成了开辟瓶颈，本篇文┞仿根据Google官方文档，加上本身的一>>>详细阅读
本文标题：利用WireShark深入调试网络请求
地址：http://www.17bianji.com/lsqh/34846.html
1/2 1
网友点评
精彩导读
科技快报
品牌展示