利用WireShark深入调试网络请求

背景

比来发明我们产品在打开告白链接(Webview)时有必定概率会异常慢，白屏时光跨越 10s，追查告白的过程中碰到不少有意思的工作，感到颇有收成。在这里分享一下，重要想聊一聊追查 bug 时的那些办法论，当然也不克不及太虚，照样要带一点干货，比如 WireShark 的应用。

Bug 复现

碰到 bug 后的第一件事当然是复现。经由一番测试我发明 bug 几乎只会重要涌如今 iPhone6 这种老旧机型上，而笔者的 7Plus 则根本没有问题。4G 和 Wifi 下都有必定概率出现，Wifi 似乎加倍频繁。

所以说收集加载还可以细分为两部分，一个是纯白屏时光，另一部分则是出现了网页但还在迁移转变菊花的时光。这是因为一个 Frame(可所以 HTML 也可所以 iFrame) 全部加载完成(包含 CSS/JS 等)后才会调用 webViewDidFinishLoad 办法，所以存在网页已经衬着但还在履行 JS 请求的情况，反竽暌钩在用户端，就是能看到网页但菊花还在迁移转变。这种情况如不雅持续时光过久会导致用户不耐烦，但比拟于纯粹的白屏时光来说更能被接收一些。

其实有点经验的开辟者看到这里心里应当有点谱了，这应当不是客户端的 bug，更可能是因为告白主网页质量太低或者收集情况不稳定导致。但作为一个靠谱的法度榜样员，怎么能把这种毫无根据的猜测向上级报告请示呢?

存眷点分别

我们知道加载网页可以由两部分时光构成，一个是本地的处理时光，另一个是收集加载的时光。两者的分水岭应当在 UIWebview 的 shouldStartLoadWithRequest 办法上。这个办法调用之前是本地处理耗时，调用之后是收集加载的请求。所以我们可以把工作分成两部分来看:

大年夜 cell 接收点击事宜的 didSelectedRowAtIndexPath 起到 UIWebview 的 shouldStartLoadWithRequest 为止。

须要留意的是，RTO 跟着 RTT 动态变更，但如不雅达到了 RTO 导致了超时重传，今后的 RTO 就不再跟着 RTT 变更了(此时的 RTT 难以估计)，会指数增长。也就是膳绫擎截图中的距离时光大年夜 2s 变成 4s 再变成 8s 的原因。

大年夜 shouldStartLoadWithRequest 起到 UIWebview 的 webViewDidFinishLoad 为止。

因为 Bug 是偶现，所以弗成能长时光用 Xcode 调试，所以还要留意写一个简单的对象，将每次的 Log 日记持久化存下来，保存每一步的函数调用、耗时、具体参数等。如许一旦复现出来，可以连上电脑攫取手机中的日记。

本地处理

本地处理低砟瓯相对较短，但逻辑一点都不简单。在我小我看来，大年夜展示 UITableview 到处理点击事宜的流程，足以反竽暌钩出一个团队的技巧实力。毫不夸大的说，能把这个小营业做到完美的团队寥寥无几，个中必定涉及到 MVC/MVVM 等架构的选型设计与具体实现、收集层与持久化层的封装、项目模块化的拆分等核心常识点。我会尽快抽空专门一些篇文┞仿来聊聊┞封些，这里就不再赘述。

花了一番工夫整顿好营业流程、做好统计今后还真有一些收成。客户端的逻辑是 pushViewController 动画履行完后才发送请求，白白浪费了大年夜约 0.5s 的动画时光，这些时光本来可以用来加载网页。

借助日记我还发明，本地处理固然浪费了时光，但这个时光相对稳定，大年夜约在 1s 阁下。更大年夜低砟瓯来自于收集请求部分。一般情况下，打开辟页会有短暂的白屏时光，这段时光内体系会加载 HTML 等资本并进行衬着，同时界面上有菊花在迁移转变。

白屏什么时刻消掉取决于体系什么时刻加载完网页，我们无法控制。但菊花消掉的时光是已知的，我们的逻辑是写在 webViewDidFinishLoad 中。这么做不必定精确，因为网页重定向时也会调用 webViewDidFinishLoad 办法导致客户端误认为已经加载完成。加倍精确的做法可以参考: 若何精确断定 WebView 加载完成，当然这也也仅仅是更精确一些，就 UIWebview 而言，想精确的断定收集是否加载完成就乎是弗成能的(感激 @JackAlan 的实践)。

小结

【编辑推荐】

iOS：若何捕获异常？
iOS单位测试和UI测试周全解析
基于iOS 10.3，开辟者若何与用户更好地“沟通”
iOS主动化测试的那些干货
iOS编译过程的道理和应用

【义务编辑：枯木 TEL：（010）68476606】

其实分析到这里已经可以向引导报告请示了。收集加载低砟瓯一共是三段，第一段是本地处理时光，存在机能浪费但时光比较稳定，第二段是网页白屏时光，这段时光内体系的 UIWebView 在请求资本并衬着，第三段是加载网页后的菊花迁移转变时光，一般耗时较少，我们也无法控制。

我们还知道 UIWebView 供给的 API 很少，大年夜开端请求到网页加载停止美满是黑盒模式，几乎无大年夜下手。但作为一名有寻求，有幻想，有幻想，有技巧的四有法度榜样员，怎么能轻言放弃呢?

WireShark

客户端在调试收集时最常用的对象要数 Charles，但它只能调试 HTTP/HTTPS 请求，对 TCP 层就力所不及了。要想懂得 HTTP 请求过程中的细节，我们必须要应用威力更大年夜(肯定也更复杂)的兵器，也就是本文的主角 WireShark。

一般来说袈浣牛X 的对象长得就越丑，WireShark 也毫不例外的有着一副让人懵逼的外表。

不过不消太急，我们要用到的器械不多，顶部红框里的蓝色鲨鱼标记表示开端监听收集数据，红色按钮一看也能猜出来是停止录制。与 Charles 只监听 HTTP 请求不合的是，WireShark 可声调试到 IP 层甚至更细节，所以它的数据包也更多，几秒钟的时光就会被上千个请求吞没，所以我建议用户略微控制一下监听的时长，或者我们可以在第二个红框中输入过滤前提来削减干扰，这个下文会具体介绍。

1/3 1 2 3 下一页尾页

　　推荐阅读

　　Android优化APP构建速度的17条建议

较长的构建时光将会减缓项目标开辟进度，特别是对于大年夜型的项目，app的构建时光长则十几分钟，短则几分钟，长的构建时光已经成了开辟瓶颈，本篇文┞仿根据Google官方文档，加上本身的一>>>详细阅读

本文标题：利用WireShark深入调试网络请求

地址：http://www.17bianji.com/lsqh/34846.html

1/2 1