前言

今天和大家分享WWDC2021的HTTP流量分析的技術(shù)界逛，通常我們會在一些抓包工具里處理自己的應(yīng)用網(wǎng)絡(luò)數(shù)據(jù)分析
那么。但是，這些工具如何和我們的代碼結(jié)合在一起呢咏窿，WWDC2021引入了新的HTTP traffic in Instruments，如圖

HTTP Traffic Instrument

我們可以看到素征，還是很像之前的Network工具的集嵌。
實際上萝挤，今天介紹的13版本工具集中的HTTP 流量工具它包含在之前的Network模版中，可以幫助我們理解API和請求生命周期的關(guān)系

1. 它適用于所有蘋果設(shè)備
2. 整個穿過URL 加載系統(tǒng)的流量都會曝光纸淮、甚至是HTTP/3或者是VPN
3. 以framework級別集成在系統(tǒng)中
   ○ 過程以屬性方式表達(dá)
   ○ 磁盤緩存請求
   ○ 揭示網(wǎng)絡(luò)錯誤
   ○ 熟悉的高層API

篇章結(jié)構(gòu)

介紹的內(nèi)容分兩部分：
第一部分：主要解釋工具的UI如何反映你正在使用的API內(nèi)容
第二部分：通過4個例子來解決性能和正確性問題

第一部分: 工具UI概覽

HTTP Traffic Instrument

首先介紹導(dǎo)航平斩，導(dǎo)航是圍繞軌跡堆棧構(gòu)建的
HTTP流量工具在最頂層（紅色區(qū)域），展示任意時間APP中有多少任務(wù)咽块，非常適合在應(yīng)用程序生命周期中檢測HTTP流量活動增加的點绘面。
下一層次結(jié)構(gòu)（綠色區(qū)域）顯示了按進程劃分的活動。 不僅有所有可調(diào)試的過程產(chǎn)生的流量侈沪，還有由它們初始化的后臺流量
每個進程下面都包含它使用的所有URLSession揭璃。這些對應(yīng)于在代碼中創(chuàng)建的URLSession對象。
橙色的這一部分是每個session和它們的獨立任務(wù)亭罪，為了更好的將代碼和可視化結(jié)合起來瘦馍，允許我們查看每個獨立的任務(wù)間隔，可以在代碼中將session實例命名应役，可以通過如下的代碼來實現(xiàn)
let session = URLSession(configuration: .default)
session.sessionDescription = "Main session”
最后一個是按照域名分類的任務(wù)信息情组，這里會展示任務(wù)的狀態(tài)
例如，上圖的藍(lán)色部分就是一些task 從選中的域名在加載數(shù)據(jù)

單個Task分析

我們來分析一個task

單個task的信息

這個任務(wù)間隔有很多的信息
我們可以以一個更抽象的方式來重新表示這張圖箩祥，來理解工具的可視化如何映射到使用的API
我們把它簡化成第二張圖

task信息抽象表示

任務(wù)API與UI對應(yīng)

API與UI的映射

Task 是代表了你的代碼如何與URL加載系統(tǒng)API進行交互 當(dāng)我們創(chuàng)建一個task 并調(diào)用它的resume方法院崇，這個task 間隔就開始了而當(dāng)你的completion Block被調(diào)用的時候這個間隔就結(jié)束了
每個task都可以給一個semantic語義名稱，通過使用taskDescription屬性袍祖，這個屬性會在工具中來標(biāo)記任務(wù)間隔

任務(wù)描述

任務(wù)label的描述

每個task都可以給一個semantic語義名稱通過使用taskDescription屬性 這個屬性會在工具中來標(biāo)記任務(wù)間隔

任務(wù)標(biāo)識

任務(wù)label的標(biāo)識

同時我們也會在task label 上顯示task的identifier 這允許我們將任務(wù)與其他數(shù)據(jù)交叉引用

任務(wù)發(fā)生錯誤

任務(wù)label描述錯誤

當(dāng)任務(wù)失敗的時候底瓣，錯誤的提示會打印在間隔的label上 這使得我們更容易調(diào)試 下面我們來看 一個任務(wù)包含多個事務(wù)的情況

Task 有多個事務(wù)

包含多個事務(wù)的task

任務(wù)Label內(nèi)容的結(jié)構(gòu)

任務(wù)Label內(nèi)容

如前所述：任務(wù)Label表示了URL加載系統(tǒng)處理的請求 + 響應(yīng)對
其中包含了所有的HTTP層的信息：
URL, HTTP版本,連接,緩存信息
請求 + 響應(yīng)頭
請求 + 響應(yīng)體

Transaction 信息概要

Transaction信息概要

就像任務(wù)一樣蕉陋，事務(wù)的label也是展示一個概要捐凭，基本上，我們可以找到請求和響應(yīng)兩部分凳鬓，導(dǎo)航結(jié)構(gòu)會顯示域名茁肠，可以在請求部分找到路徑、請求參數(shù)缩举， 例子中的信息依次是HTTP的version垦梆、method、請求里是否攜帶了認(rèn)證頭部和cookie 頭部蚁孔。對于響應(yīng)奶赔，我們會看到 status code 例如上面的200 ，還有響應(yīng)里是否攜帶了set-cookie 頭部杠氢，最后是content-type的內(nèi)容站刑。 請求和響應(yīng)花費了多長時間。以及關(guān)于事務(wù)其他部分的詳細(xì)時間信息都會在存儲在事務(wù)的狀態(tài)里鼻百。接下里我們分析一下這個內(nèi)容

不同階段的時間

事務(wù)不同階段的時間

Transaction 的起始是transaction被創(chuàng)建的時候绞旅。 它首先會檢查我們是否已經(jīng)有了一個合法的緩存如果沒有摆尝，它就會在一個connection上開始一個新的請求，接下來 transaction 可能會等待一段時間來等一個可用的連接因悲， 當(dāng)請求被連接處理之后堕汞，發(fā)送請求的階段就開始了，這一階段持續(xù)到我們把請求的最后一個比特發(fā)送出去 然后transaction 進入一個空閑的狀態(tài)晃琳，等待響應(yīng)然后接收響應(yīng)讯检，該響應(yīng)將跟蹤從服務(wù)器收到的第一個字節(jié)到最后一個字節(jié)的跨度，整個事務(wù)將在收到最后一個字節(jié)后的很短時間內(nèi)結(jié)束
事實上卫旱， 緩存查找和發(fā)送一個GET請求要比圖中短很多 所以實際上的時間段看起來就像這樣

實際的事務(wù)不同階段時間

接下來我們進入第二部分：實例

第二部分：實例

用HTTP Traffic工具驗證APP

讓我們來用HTTP Traffic工具驗證下APP來幫助我們改善這種狀況 在Product菜單中我選擇Profile來在工具中分析APP 這會使用release 配置人灼，開啟了全部的優(yōu)化來構(gòu)建我的APP，以確保我的應(yīng)用程序能夠像我用戶運行的那樣進行評測顾翼。 構(gòu)建完成后投放，工具會自動啟動，啟動后就會看到標(biāo)準(zhǔn)的工具選擇界面适贸，我們選擇Network模版

使用Profile驗證APP

Network 面板

Network面板

下邊的是已有的流量分析工具灸芳，上邊是新的HTTP Traffic工具。我們主要集中在上邊這個工具 只要我們點擊record 工具就會啟動APP并開始記錄拜姿，當(dāng)然 開始使用這個工具之前需要確認(rèn)你理解捕獲網(wǎng)絡(luò)流量的含義 工具會抓獲很多數(shù)據(jù)尤其是你決定捕獲所有進程 即使是用戶憑據(jù)烙样，所以你應(yīng)該對結(jié)果追蹤文件非常小心

顯示所有的事務(wù)間隔

接著讓我們使用option click 和拖動放大數(shù)據(jù)確保包含我們HTTP traffic的區(qū)域

展開追蹤區(qū)域

我們也可以像圖片一樣在左側(cè)點擊向下展開，增加追蹤區(qū)域的高度砾隅，來顯示所有的事務(wù)間隔

實例1

想象我們有一個專門展示圖片的類似社交媒體的APP误阻，用戶可以上傳圖片债蜜，并且獲得一連串最近的上傳圖片 當(dāng)加載一系列圖片的時候晴埂，我們會注意到等全部加載完會花費一些時間，為了分析這個問題我們打開HTTP Traffic面板

列表加載過程.png

查看整個過程的耗時

事務(wù)的完成時間

選擇 HTTP Transactions by Connection項

HTTP Transactions by Connection視圖

事務(wù)的階梯完成狀態(tài)

線路阻塞

使用http1的事務(wù)完成圖

使用HTTP/2解決阻塞問題

使用HTTP/2的事務(wù)完成狀態(tài)

這是我們改為使用http/2之后的效果富岳，可以看到這里沒有明顯的阻塞狀態(tài)了
我們再次回顧一下 HTTP Transaction by connection 面板，我們可以注意到這里只有一個連接拯腮， 這是因為我們不再需要多個連接來發(fā)送并發(fā)的請求了窖式。這也意味著我們只有一次連接建立的損耗 我們也能注意到可以在事務(wù)等待同一個連接的上一個事務(wù)的請求響應(yīng)的時候發(fā)送新的請求 我們可以看到請求都在很短時間內(nèi)發(fā)送出去，只剩下等待服務(wù)器響應(yīng)了 我們往下滾動也可以看到动壤，所有的等待都是同時開始的

實例2

假如我們APP有一個需要登錄的功能萝喘，登錄之后用戶就可以不用登錄了

登錄請求過程

這是之前記錄的一個追蹤文件 我們可以用工具打開它并分析 左側(cè)是我點擊某個按鈕時候的任務(wù) 第一個任務(wù)間隔包含兩個事務(wù) 最后一個是對應(yīng)我的第二次put請求

第一個登錄請求

第二個登錄請求

當(dāng)我們進行操作來登錄的時候 我們會重試事務(wù) 201響應(yīng)碼表示請求已經(jīng)被成功處理,并且創(chuàng)建了新的資源 這次成功了 身份驗證質(zhì)詢的這種交互 輸入密碼 然后重試事務(wù) 是URL加載系統(tǒng)為我們處理的另外一種case

兩個事務(wù)的關(guān)系

第三個登錄請求

失敗事務(wù)的前置事務(wù)

transaction列表

detail面板

可以看到我們期望的Set-Cookie Header 第一眼看上去這個cookie很正常但是 細(xì)看會發(fā)現(xiàn) 它的過期時間是 2020年饶米，在過去 ，所以這會導(dǎo)致URLSession 不發(fā)送cookie

實例3

有時车胡， 我們的網(wǎng)絡(luò)資源列表里會一些元素沒有正確顯示出來

列表加載的過程

比如看上面這張圖檬输，我們期望找到一個列表加載的過程，所以先選中域名匈棘，這里有很多的請求丧慈，注意到左下角的detail filter了嗎 我們可以在這里過濾

列表過濾的結(jié)果

第一個請求

可以看到一切正常
但是當(dāng)我們向后滑動的時候，可以看到一個很短的請求羹饰。

持續(xù)時間較短的請求

時間線放大后的請求

HTTP Transaction by connection 面板

實例4

如果我們集成了一些SDK筒主，使用時候會發(fā)現(xiàn)关噪，集成的SDK在不期望網(wǎng)絡(luò)操作的時候就發(fā)出了網(wǎng)絡(luò)請求，

SDK在不期望的時候發(fā)出請求

我們同樣可以在detail面板來觀察代碼哪一部分做了網(wǎng)絡(luò)請求

網(wǎng)絡(luò)請求的詳細(xì)信息

SDK的請求的位置信息

看起來像是 Core Location被激活了 這是非澄诿睿可疑的使兔，尤其是我并沒有用任何操作來觸發(fā)它。我們可能會想藤韵，我的位置是否上傳到了服務(wù)器虐沥，因為CoreLocation和CFNetwork同時存在， 我們可以通過HTTP事務(wù)來驗證

detail面板

生成debug報告

XCtrace命令行

結(jié)語

分享到這里就結(jié)束了，希望大家通過簡介和實例掌握HTTP Traffic的使用雳攘，能夠解決遇到的問題带兜，幫助大家的APP越來越好。