深刻理解Http請求、DNS劫持與解析。

背景

前段時間在處理iOS端的HTTPDNS相關SDK，在接入和測試環節發現你們對HTTP的總體請求流程包括HTTP劫持原理以及HTTPDNS的工做原理並非太清楚，因此寫下這邊文章幫助你們深刻web請求過程：如何發起請求，HTTP協議解析，DNS域名解析。

HTTP發起一個請求過程

當咱們在手機端請求一個@"www.baidu.com"的域名的時候

• 1.請求到達運營商的DNS服務器並由其把這個域名解析成對應的IP地址。

• 2.根據IP地址在互聯網上找到對應的服務器，向這個服務器發起一個get\post請求。

• 3.由這個服務器找到對應的資源原路返回給訪問的用戶。

這裏只是一個大概的流程實際每一步都有複雜的結構和邏輯例如：服務器可能有不少臺，到底指定哪臺服務器來處理請求，須要一個負載均衡設備來平均分配全部用戶的請求。請求的數據是存儲在分佈式緩存中仍是一個靜態文件中，或是在數據庫裏。當數據返回瀏覽器時，瀏覽器解析數據發現還有一些靜態資源（如CSS、JS或者圖片）時又會發起另外的HTTP請求，而這些請求極可能會在CDN上，那麼CDN服務器上又會處理這個用戶的請求。

HTTP劫持

咱們使用HTTPDNS的主要目的就是解決HTTP劫持問題。HTTP的劫持分兩種第一種是DNS劫持，第二種是內容劫持，後者是基於前者的基礎上發展出來，是比較高級的劫持手段，目前無解，下面來分開講解：

1：DNS劫持

• 劫持流程
  DNS劫持又稱域名劫持，是指在劫持的網絡範圍內攔截域名解析的請求，分析請求的域名，把審查範圍之外的請求放行，不然返回假的IP地址或者什麼都不作使請求失去響應，其效果就是對特定的網絡不能訪問或訪問的是假網址。其實本質就是對DNS解析服務器作手腳，或者是使用僞造的DNS解析服務器能夠經過下圖來展現
  

  DNS劫持原理

  
  從圖中能夠看出紅色的是劫持的流程，劫持後將你的請求轉發到一個虛假的服務器。
• 解決辦法
  DNS的劫持過程是經過攻擊運營商的解析服務器來達到目的。咱們能夠不用運營商的DNS解析而使用本身的解析服務器或者是提早在本身的App中將解析好的域名以IP的形式發出去就能夠繞過運營商DNS解析，這樣一來也避免了DNS劫持的問題。

2：內容劫持

• 劫持流程
  內容劫持網上不多有提到，這也是在作httpDNS SDK所遇到的一個問題，其實內容劫持一開始的出發點是好的，是運營商爲了加快用戶的訪問速度同時減小本身的流量損耗而作的一個緩存機制，用戶在像服務器請求數據的時候運營商會把用戶的請求轉移到這個緩存池中，若是緩存中有就直接返回，沒有的話再去像服務器請求而後攔截並緩存服務端給用戶的回調數據，這樣一來能夠極大的下降運營商像服務器請求的次數，也能加快用戶的訪問，因此出發點是好，可是一些非法的商家對緩存池內部作一次些處理就是直接對返回的內容進行修改，這樣一來咱們就會接受到錯誤的數據
  

  內容劫持

  黃色線條就是比價危險的了，由於回調的數據極可能已經被篡改過。
• 解決辦法：
  如今暫時沒有發現辦法，不過這樣的劫持不是不少。

  DNS解析過程

  若是是iOS設備請直接跳到第三步驟

• 1.系統會檢查瀏覽器緩存中有沒有這個域名對應的解析過的IP地址，若是緩存中有，這個解析過程就將結束。瀏覽器緩存是受這個域名的失效時間和緩存的空間大小控制的。

• 2.若是用戶的瀏覽器緩存中沒有，瀏覽器會查找操做系統緩存中即爲本地的Host文件。

• 3.若是本地Host文件中沒有那麼操做系統會把這個域名發送給這裏設置的LocalDNS，也就是本地區的域名服務器。這個DNS一般都提供給你本地互聯網接入的一個DNS解析服務。這個專門的域名解析服務器性能都會很好，它們通常都會緩存域名解析結果，固然緩存時間是受域名的失效時間控制的，通常緩存空間不是影響域名失效的主要因素。大約90%的域名解析都到這裏就已經完成了，因此LDNS主要承擔了域名的解析工做。

• 4.若是LDNS仍然沒有命中，就直接到Root Server域名服務器請求解析

• 5.根域名服務器返回給本地域名服務器一個所查詢的域的主域名服務器（gTLD Server）地址。gTLD是國際頂級域名服務器，如.com，.cn、.org等。全球只有13臺左右。

• 6.本地域名服務器（Local DNS Server）再向上一步返回的gTLD服務器發送請求。

• 7.接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server一般就是你註冊的域名服務器，例如你在某個域名服務提供商申請的域名，那麼這個域名解析任務就由這個域名提供商的服務器來完成

• 8.Name Server域名服務器會查詢存儲的域名和IP的映射關係表，正常狀況下都根據域名獲得目標IP記錄，連同一個TTL值返回給DNS Server域名服務器。

• 9.返回該域名對應的IP和TTL值，Local DNS Server會緩存這個域名和IP的對應關係，緩存的時間由TTL值控制。

• 10.把解析的結果返回給用戶，用戶根據TTL值緩存在本地系統緩存中，域名解析過程結束。
  以上的流程能夠簡化爲下圖
  

  DNS解析

  
  綠色的爲非iOS設備的操做流程

  CDN工做機制

  CDN簡介

  CDN，全稱Content Delivery Network，根本的做用是將網站的內容發佈到最接近用戶的網絡「邊緣」，使用戶能夠就近取得所需的內容，提升用戶訪問網站的響應速度。他-有別於鏡像，它比鏡像更智能，能夠這樣作一個比喻：CDN=鏡像（Mirror） + 緩存（cache） + 總體負載均衡（GSLB），於是，CDN能夠明顯提升Internet中信息流動的效率。目前CDN都以緩存網站中的靜態數據爲主，如CSS、JS、圖片和靜態網頁等數據。用戶在從主站服務器請求到動態內容後再從CDN上下載這些靜態數據，從而加速網頁數據內容的下載速度，如淘寶有90%以上的數據都是由CDN來提供的。這裏引用一個網上比較形象的例子：A家的網速 100M的，但他只用了10M的速度，B家的網速是10M的，可是他須要15M的速度才行。怎麼辦呢。 C是一家CDN服務商，在A家有個節點（就像A是一個贊助商同樣）B在C家買了CDN加速服務。當B的速度不夠的時候，CDN加速就會選擇有節餘的節點來幫B，提升B的速度。這樣B的速度就能達到或超過15M ，皆大歡喜。A沒浪費，B速度有了，C賺了錢。 當C的節點在全國都有，很是多的時候。那麼你用C家的CDN加速服務，你就會大步流星了。

  CDN工做流程

  一個用戶訪問某個靜態文件（如CSS），這個靜態文件的域名假如是www.baidu.com，而這個域名最終會被指向CDN全局中CDN負載均衡服務器，再由這個負載均衡服務器來最終分配是哪一個地方的訪問用戶，返回給離這個訪問用戶最近的CDN節點。以後用戶就直接去這個CDN節點訪問這個靜態文件了，若是這個節點中請求的文件不存在，就會再回到源站去獲取這個文件，而後再返回給用戶。

  負載均衡

  負載均衡就是對工做任務進行平衡、分攤到多個操做單元上執行，如圖片服務器、應用服務器等，共同完成工做任務。它能夠提升服務器響應速度及利用效率，避免軟件或者硬件模塊出現單點失效，解決網絡擁塞問題，實現地理位置無關性，爲用戶提供較一致的訪問質量。
  CDN總體的工做流程能夠大概歸爲下圖：
  

  image.png

  總結

  以上就是Http請求的一些理解，若是有不對的地方及時與我來溝通。