背景
線上APP有一個下拉刷新的請求，大部分時間下拉刷新很快，偶發性下拉刷新請求接口特別慢，單獨請求接口的時候都很快，懷疑是網絡波動問題或者服務器帶寬問題，因此有了這篇文章
一.復現請求慢的情況
二.charles相關知識
1.顯示模式
（1） Structure形式如下圖 優點：可以很清晰的看到請求的數據結構，而且是以域名划分請求信息的，可以很清晰的去分析和處理數據。
（2）Sequence形式如下圖 優點：可以看到全部請求，這里的結果以數據請求的順序來顯示，最新的請求顯示在最下面
綜上，兩種形式各有千秋，structure 適合對單一系列的訪問請求從宏觀上進行把握，可以快速定位。sequence 適合精確定位內容，因為每條sequence 都有size，status等屬性信息，方便快速定位這條結果的價值.
2.相關名詞解釋
Filter ： 過濾，可以輸入關鍵字來快速篩選出 URL 中帶指定關鍵字的網絡請求
Overview ： 查看這次請求的詳細內容，例如耗時詳細列車了請求開始時間、結束時間，響應開始時間、結束時間，總耗時、DNS耗時、網絡延時等。對於Size也詳細列出了請求頭大小、響應頭大小、壓縮比例等內容。
URL：進行網絡請求的鏈接；
Status：當前狀態，complete表示請求完成；
Responce Code：返回碼。不同的接口，不同的請求結果，返回碼都不同；
Protocol：使用的協議；
Method：請求方式，如GET請求，POST請求等；
Kept Alive：判斷當前是否正在鏈接（活躍）；
Content-Type：響應的content-type頭；
Client Address：客戶端的IP地址；
Remote Address：遠程服務器的IP；
Timing:
Request Start Time：接收到的第一個請求的第一個字節的時間點
Request End Time：發送到客戶端的最后一個響應的最后一個字節的時間
Response Start Time：響應開始時間
Response End Time：響應結束時間
Duration：整個請求響應持續時間。Duration=DNS+Connect+TLS Handshake+Response+Latency（應該是上面的加和）
DNS：所有選中的session解析DNS所花費的時間的總和
Connect：所有選中session建立TCP/IP連接所花費的時間總和
TLS Handshake--TLS協議握手時間
Request：請求耗費時間
Response：響應耗費時間
Latency：網絡延遲時間和服務器處理時間
Charles shows a measure of the latency on each request on the Overview tab. Charles calculates latency by measuring the time taken between finishing sending the request and starting to receive the response. Therefore latency includes network latency and server latency, that is the time spent processing the request. For static requests the server is usually able to respond instantly, unless under load, so the latency figure mostly represents the network latency. For dynamic requests, or any request for which the server has to do some work, you can subtract an approximate network latency to determine how long the server spent processing the request. Charles在“概述”選項卡上顯示了每個請求的延遲度量。Charles通過測量完成發送請求和開始接收響應之間的時間來計算延遲。因此，延遲包括網絡延遲和服務器延遲，即處理請求所花費的時間。 對於靜態請求，服務器通常能夠即時響應（除非處於負載狀態），因此延遲數主要表示網絡延遲。 對於動態請求或服務器必須為之執行的任何請求，您可以減去近似的網絡延遲來確定服務器處理該請求所花費的時間。Size:
Request Header ：請求的頭部大小；
Response Header：返回的頭部大小；
Request : 請求發送的大小；
Response：返回數據的大小；
Total：所有數據大小；
Contents ： 查看請求參數和返回數據
Headers：發送請求的頭部信息或者返回的頭部信息；
Text：請求的參數信息或者返回信息的文本；
Hex：請求的參數或者返回信息的16進制表示；
JavaScript： 以js的形式格式化請求的參數或者返回的參數；
JSON：請求參數或者返回的數據JSON形式展示；
JSONText：請求的信息或者返回的信息格式化成test形式；
Raw：發送的原生數據，包括了Headers和Text；
Summary: 查看發送數據的一些簡要信息（主機，狀態碼，數據的類型，header和body大下，加載時間，總時間）
Chart: Summary中簡要信息以圖表形式展示
Timeline：時間線。請求上傳、處理請求、響應組合的時間線。
Request - the time spent sending (uploading) the request (dark blue) Latency - the time spent waiting for network latency or processing time on the server (mid blue) Response - the time spent receiving (downloading) the response (light blue) 請求-發送（上傳）請求所花費的時間（深藍色）。 延遲-等待網絡延遲或服務器上的處理時間所花費的時間（藍色）。 響應-接收（下載）響應所花費的時間（淺藍色）。Sizes：響應數據的大小
Duration：與Overview中的Duration值是一樣的。不包含請求發送的時間。
Types：返回的格式。application/json
Flow：應該是上傳下載速度與耗時的關系？？？
Notes: 其他信息
三.問題分析
由上面兩張圖可以看出，整個請求過程刨除請求發送，耗時441ms。主要耗時在request上面了，由chart--timeline可以清晰的看出來請求時間組成，request占據了大部分的時間，可以推斷接口的響應速度還是可以的，更大的可能是網絡波動或者服務器帶寬造成的請求時間過長！
在上面的基礎上進行網絡和服務器帶寬的一個檢測，確認問題根源
站在巨人肩膀上摘蘋果
https://www.cnblogs.com/henanleon/p/9902366.html
https://blog.csdn.net/weixin_42139375/article/details/105258019
https://www.jianshu.com/p/2baf3585a4c2
https://www.charlesproxy.com/documentation/using-charles/chart/