網絡通訊的響應時長優化

原文地址

網絡是用物理鏈路將各個孤立的工做站或主機相連在一塊兒，組成數據鏈路，從而達到資源共享和通訊的目的。

通訊是人與人之間經過某種媒體進行的信息交流與傳遞。

網絡通訊是經過網絡將各個孤立的設備進行鏈接，經過信息交換實現人與人，人與計算機，計算機與計算機之間的通訊。

客戶端在應用打開以後都會與服務端進行網絡通訊，以獲取最新的數據，並把數據展現在界面上供用戶操做。

今天咱們來聊聊客戶端與服務端之間通訊的優化，主要是如何縮短響應延時爲目標。

通訊過程介紹

下面簡單介紹一下客戶端與服務端的通訊過程。 若是忽略其中硬件部分和部分細節，手機APP網絡通訊的大致過程以下圖所示：

• 客戶端拼接好網絡請求以後，經過DNS解析服務找到對應的IP
• 客戶端發出網絡請求，請求經過一些列的交換機、路由等硬件設備以後到達服務端
• 服務端會有一個請求分發的服務，會把請求發送給對應的業務方，業務方會對此次請求作獨特的數據- 封裝，而數據來源於數據機房
• 封裝好業務數據以後把數據返回給客戶端，
• 客戶端接收到響應數據以後，對CDN上的資源進行請求

咱們要想提高網絡訪問成功率，本質上是減小每一步出錯的機率 咱們要想縮短一次網絡訪問的響應時間，本質上是提升數據的返回速度，說的直白一點就是要把請求數據過程當中的各個步驟提升速度，這樣總體下來響應時間就會縮短。

DNS預解析

全部網絡請求的第一步都要找到域名對應的IP地址，DNS解析的效率直接決定了請求的延遲多少。而Cache的存在使得解析過程減小了不少延遲。可是緩存策略在不一樣系統上不同，在iOS系統上，緩存策略通常是，24小時以後會過時、飛行模式的開啓關閉、開關機、重置網絡等，都會致使cache的清除，因此新的DNS請求又會致使請求耗時。 在這裏簡單介紹一下手機中DNS的查詢過程：

• 優先本地Cache查詢
• 查詢本地DNS服務器
• 查詢根域名服務器
• 查詢頂級域名服務器
• 查詢域名服務器

在整個查詢過程當中大概要持續20ms到120ms左右的時間，而這段時間是能夠優化的。

方案很簡單：咱們能夠在客戶端上存儲本身的DNS映射表。在程序冷啓時拉取」api.xxxxxx.com」對應的全部的IP列表；對全部IP進行跑馬測試，找到速度最快的IP。後續全部的請求都將域名更換爲跑馬最快的IP便可。

那如何設計一份DNS映射表？幾點要求以下：

• APP打包時就加入一個默認映射文件，避免首次去服務器獲取數據的延遲
• 開啓一個定時器，每隔一段時間就從服務器獲取最新的映射表
• 若是映射文件中沒有相應信息，就須要回滾使用默認的DNS解析服務
• 若是一個映射後的IP持續致使請求失敗，須要一個淘汰機制將無效域名刪除，並及時上報服務器，及時發現問題更新文件

網絡間傳輸信息

中國的基礎網絡是世界上最複雜的基礎網絡，國內的網絡運營商衆多且各自爲政，互聯互通成本很高。信息在基礎網絡上的流通是不可靠的。

整個通訊過程的響應時間取決於不少因素：HTTP請求是基於Socket設計的，請求發起以前會經歷三次握手，在請求時會有一個慢啓動，路由器的路由策略是否最優，整個過程經過的網關數據量，須要跨網絡運營商，物理路徑較長，服務器帶寬是否足夠，有時候甚至還會遇到GFW的攔截等等。這些由於都會直接致使通訊時間的增加，甚至致使通訊的失敗。

那麼改如何改善這種狀況呢？把數據放在離用戶越近的地方響應時間越快。舉兩個栗子：1）異地多活 2）長連模式 3）

異地多活架構的關鍵點就是異地、多活，其中異地就是指地理位置上不一樣的地方，相似於「不要把雞蛋都放在同一籃子裏」；多活就是指不一樣地理位置上的系統都可以提供業務服務，這裏的「活」是活動、活躍的意思。 這裏要注意一點：要把數據機房和業務機房作到地域對齊，不然跨地域跨機房調用的話延時是比較高的。如：北京到北京的網絡延時是1ms，而北京到上海的網絡延時大概在30ms左右。

長連模式是指在客戶端與業務服務器之間架設代理長連服務器，而代理服務器負責與業務服務器進行HTTP請求，請求的結果經過長連通道送回客戶端。代理服務器與業務服務器之間的網絡通道也能夠進行優化，經過租用騰訊雲乃至架設專線等方式能夠大大提高通道服務質量。與部署業務服務器相比，部署代理長連服務器的代價就小了不少，能夠在全國甚至全世界多地部署代理長連服務器 再好比說壓縮數據、數據分級等等都可以保證數據傳輸的性能。

服務端性能優化

對於服務端服務，通常用QPS（Query Per Second：每秒請求數）CT（Response Time：響應時間）、併發數、服務可用性四個指標做爲性能優化的業務指標。

正常狀況下響應時間（RT）越短，一秒鐘處理的請求數（QPS）天然也就會越多，這在單線程處理的狀況下看起來是線性的關係，即只要把每一個請求的RT降到最低，那麼性能就會最高。

可是，響應時間（RT）總會有一個極限，不可能無限降低，因此又出現了另一個維度，即經過多線程，來處理請求。 理論上就變成了「總 QPS =（1000ms / 響應時間（RT））× 線程數量」，這樣性能就和兩個因素相關了，一個是一次響應的服務端耗時，一個是處理請求的線程數。

可是在某些狀況下，下降響應時間（RT）、提升QPS和提升服務可用性三者相互矛盾，不可兼得。例如：增長緩存能夠下降平均響應時間，可是處理線程數量會由於緩存過大而有所限制，從而下降QPS；爲了提升服務可用性，對異常請求重複調用是一個經常使用的作法，可是這會提升響應時間並下降QPS。 那麼常規的優化手段都有哪些呢？

代碼優化

之因此把代碼放到第一位，是由於這一點最容易引發技術人員的忽視。

• 架構不合理。業務發展超越架構支撐能力而致使系統負荷過載，進而致使出現系統奔潰、響應超時等現象。另外不合理的架構如：單點、無cache、應用混部署、沒有考慮分佈式、集羣化等也都會影響性能
• 研發功底和經驗不足。開發的server效率和性能較低、不穩定也是常見的事情
• 沒有性能意識，只實現了業務功能不注意代碼性能，新功能上線後總體性能降低，或當業務上量後系統出現連鎖反應，致使性能問題疊加，直接影響用戶體驗

緩存優化

緩存能夠稱的上是性能優化的利器，使用緩存時須要考慮緩存命中率、緩存丟失、緩存更新、數據一致性、緩存穿透及雪崩、Value過大等問題，能夠經過mutiGet將屢次請求合併一次、異步訪問等方式來提高緩存讀取的性能。

產品邏輯優化

業務邏輯優化常常會容易被忽略，但效果卻每每比數據庫調優、JVM調優之類的來的更明顯。

舉一個例子，12306春運搶火車票的場景，因爲訪問的人多，用戶點擊「查票」以後系統會很是卡，進度條很是慢，做爲用戶，會習慣性的再去點「查票」，可能會連續點個好幾回。假設平均一個用戶點5次，則後端系統負載就增長了5倍！而其中80%的請求是重複請求。這個時候咱們能夠經過產品邏輯的方式來優化，好比，在用戶點擊查詢以後將「按鈕置灰」，或者經過JS控制xx秒只能只能提交一次請求等，有效的攔截了80%的無效流量。

硬件優化

硬件問題對性能的影響不容忽視。 舉一個例子：一個DB集羣常常有慢SQL報警，業務排查下來發現SQL都很簡單，該作的索引優化也都作了。後來DBA同窗幫忙定位到問題是硬件過舊致使，將機械硬盤升級成固態硬盤以後報警立馬消失了，效果立竿見影！

數據庫優化

• SQL調優

這是最經常使用、每個技術人員都應該掌握基本的SQL調優手段（包括方法、工具、輔助系統等）。

• 架構層面的調優

這一類調優包括讀寫分離、多重庫負載均衡、水平和垂直分庫分表等方面，通常須要的改動較大，可是頻率沒有SQL調優高，並且通常須要DBA來配合參與。

• 鏈接池調優

這一類調優是爲了實現數據庫鏈接的高效獲取、對數據庫鏈接的限流等目的，一般會採用鏈接池類的方案，即每個應用節點都管理了一個到各個數據庫的鏈接池。 可是複雜查詢以及一些聚合計算不適合在數據庫中作，能夠利用搜索引擎來實現，另外搜索引擎還能夠幫咱們很好的解決跨庫、跨數據源檢索的場景。

併發優化

併發能夠利用線程池、消息隊列等方式實現。 使用線程池的時候必定要注意核心參數的設置，能夠經過監控工具去觀測實際建立、活躍、空閒的線程數，結合CPU、內存的使用率狀況來作線程池調優。

CDN加速優化

CDN 的全稱是 Content Delivery Network，即內容分發網絡。CDN 是構建在網絡之上的內容分發網絡，依靠部署在各地的邊緣服務器，經過中心平臺的負載均衡、內容分發、調度等功能模塊，使終端用戶就近獲取所需內容，下降網絡擁塞，提升用戶訪問響應速度和命中率。CDN 的關鍵技術主要有內容存儲和分發技術。

給你們放一張直觀圖，給你們對比下 CDN 服務部署先後的區別：

CDN 系統設計的最大目標是儘可能減小用戶的訪問響應時間。 爲達到這一目標，CDN 系統應該儘可能將用戶所須要的內容存放在距離用戶最近的位置。也就是說，負責爲用戶提供內容服務的 Cache 設備應部署在物理上的網絡邊緣位置，咱們稱這一層爲CDN邊緣層。CDN 系統中負責全局性管理和控制的設備組成 中心層，中心層同時保存着最多的內容副本，當邊緣層設備未命中時，會向中心層請求，若是在中心層仍未命中，則須要中心層向源站回源。 使用CDN後的http請求處理流程以下圖，其中左邊爲DNS解析過程，右邊爲內容訪問過程：

CDN基於這樣的原理：

• 挑選最優設備爲用戶提供服務；
• 若是某個內容被不少用戶所須要，它就被緩存到距離用戶最近的節點中。

CDN 公司在整個互聯網上部署數以百計的CDN服務器（Cache），這些服務器一般在運營商的 IDC (互聯網數據中心Internet Data Center）中，儘可能靠近接入網絡和用戶。CDN在Cache中複製內容，當內容的提供者更新內容時，CDN 向Cache從新分發這些被刷新的內容。CDN提供一種機制，當用戶請求內容時，該內容可以由以最快速度交付的Cache 來向用戶提供，這個挑選"最優"的過程就叫作負載均衡。被選中的最優 Cache 可能最靠近用戶，或者有一條與用戶之間條件最好的路徑。

總結

性能優化的過程首先要從監控開始。客戶端的網絡通訊監控和服務端的網絡通訊監控是不一樣的。

客戶端的網絡訪問是從請求發出開始，通過基礎網絡到達服務端，服務端處理好數據以後回吐給客戶端，客戶端接收到響應數據以後結束網絡通訊。服務端監控的是從接收到請求，到回吐數據的過程也就是說服務端的網絡監控是客戶端網絡監控的一個子集。

今天簡單梳理了一下客戶端的網絡通訊，介紹的一些優化措施。除此以外，還能夠在減小數據、數據分級（動靜分離），以及減小中間環節、增長預處理等這些環節上作優化。

首先是減小數據，事實上，有兩個地方特別影響性能，一是服務端在處理數據時不可避免地存在字符到字節的相互轉化，二是 HTTP 請求時要作 Gzip 壓縮，還有網絡傳輸的耗時，這些都和數據大小密切相關。

再次，就是數據分級，也就是要保證首屏爲先、重要信息爲先，次要信息則異步加載，以這種方式提高用戶獲取數據的體驗。

最後就是要減小中間環節，減小字符到字節的轉換，增長預處理（提早作字符到字節的轉換）去掉不須要的操做。