瀏覽器輸入url到發起http請求所經歷的過程

用戶輸入url

當用戶輸入url,操做系統會將輸入事件傳遞到瀏覽器中,在這過程當中,瀏覽器可能會作一些預處理,好比 Chrome 會根據歷史統計來預估所輸入字符對應的網站,例如輸入goog,根據以前的歷史發現 90% 的機率會訪問「www.google.com 」,所以就會在輸入回車前就立刻開始創建 TCP 連接甚至渲染了。數據庫

接着是輸入url以後,點擊回車,這時瀏覽器會對 URL 進行檢查,首先判斷協議,若是是 http 就按照 Web 來處理,另外還會對這個 URL 進行安全檢查segmentfault

安全檢查完成以後,在瀏覽器內核中會先查看緩存,而後設置 UA 等 HTTP 信息,接着調用不一樣平臺下網絡請求的方法。瀏覽器

注意:
瀏覽器和瀏覽器內核是不一樣的概念,瀏覽器指的是 Chrome、Firefox,而瀏覽器內核則是 Blink、Gecko,瀏覽器內核只負責渲染,GUI 及網絡鏈接等跨平臺工做則是瀏覽器實現的緩存

http網絡請求

經過 DNS 查詢 IP;
經過 Socket 發送數據安全

dns查詢ip

DNS,英文是Domain Name System,中文叫域名系統,是Internet的一項服務,他將域名和IP地址相互映射的一個分佈式數據庫服務器

假設用戶在瀏覽器中輸入的是www.google.com,大概過程:網絡

若是輸入的是域名,則須要進行dns查詢,將域名解析成ip;app

進行DNS查詢的主機或軟件叫作DNS解析器,用戶使用的工做站或電腦都屬於解析器。域名解析就是利用DNS解析器獲得對應IP過程,解析器會向域名服務器進行查詢處理。tcp

主要過程以下:分佈式

  1. 從瀏覽器緩存中查找域名www.google.com的IP地址
  2. 在瀏覽器緩存中沒找到,就在操做系統緩存中查找,這一步中也會查找本機的hosts看看有沒有對應的域名映射(固然已經緩存在系統DNS緩存中了)
  3. 在系統中也沒有的話,就到你的路由器來查找,由於路由器通常也會有本身的DNS緩存

若是以上都沒有找到,則繼續往下向dns域名服務器查詢

  • 用戶電腦的解析器向LDNS(也就是Local DNS,互聯網服務提供商ISP),發起域名解析請求,查詢www.google.com的IP地址,這是一個遞歸查找過程
  • 在緩存沒有命中的狀況下,LDNS向根域名服務器.查詢www.google.com的IP地址,LDNS的查詢過程是一個迭代查詢的過程
  • 根告訴LDNS,我不知道www.google.com對應的IP,可是我知道你能夠問com域的受權服務器,這個域歸他管
  • LDNS向com的受權服務器問www.google.com對應的IP地址
  • com告訴LDNS,我不知道www.google.com對應的IP,可是我知道你能夠問google.com域的受權服務器,這個域歸他管
  • LDNS向google.com的受權服務器問www.google.com對應的IP地址
  • google.com查詢本身的ZONE文件(也稱區域文件記錄),找到了www.google.com對應的IP地址,返回給LDNS
  • LDNS本地緩存一份記錄,把結果返回給用戶電腦的解析器
  • 在這以後,用戶電腦的解析器拿到結果後,緩存在本身操做系統DNS緩存中,同時返回給瀏覽器,瀏覽器依舊會緩存一段時間。

注意
域名查詢時有多是通過了CDN調度器的(若是有cdn存儲功能的話)

並且,須要知道dns解析是很耗時的,所以若是解析域名過多,會讓首屏加載變得過慢,能夠考慮dns-prefetch優化

tcp/ip請求

有了 IP 地址,就能夠經過 Socket API 來發送數據了,這時能夠選擇 TCP 或 UDP 協議。

http本質是tcp協議。

TCP是一種面向有鏈接的傳輸層協議。他能夠保證兩端(發送端和接收端)通訊主機之間的通訊可達。他可以處理在傳輸過程當中丟包、傳輸順序亂掉等異常狀況;此外他還能有效利用寬帶,緩解網絡擁堵。

創建TCP鏈接一開始都要通過三次握手:

第一次握手,請求創建鏈接,發送端發送鏈接請求報文
第二次握手,接收端收到發送端發過來的報文,可知發送端如今要創建聯機。而後接收端會向發送端發送一個報文

第三次握手,發送端收到了發送過來的報文,須要檢查一下返回的內容是不是正確的;若正確的話,發送端再次發送確認包

在TCP鏈接創建完成以後就能夠發送HTTP請求了。能夠將數據發送給服務器,並收到返回信息。

當請求結束,須要經厲鏈接終止協議(四次揮手)。

因爲TCP鏈接是全雙工的,所以每一個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個 FIN只意味着這一方向上沒有數據流動,一個TCP鏈接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉,而另外一方執行被動關閉。

抽象爲:

客戶端:我已經關閉了向你那邊的主動通道了,只能被動接收了
服務端:收到通道關閉的信息
服務端:那我也告訴你,我這邊向你的主動通道也關閉了
客戶端:最後收到數據,以後雙方沒法通訊

注意
瀏覽器對同一個域名有鏈接數限制,大部分是 6,http1.0中每每一個資源下載就須要對應一個tcp/ip請求,而像 HTTP 2.0 協議儘管只使用一個 TCP 鏈接來傳輸數據,但性能反而更好,並且還能實現請求優先級。

參考文章:
http://fex.baidu.com/blog/201...
https://blog.csdn.net/dojiang...
https://segmentfault.com/a/11...

相關文章
相關標籤/搜索