打開瀏覽器從輸入網址到網頁呈如今你們面前,背後到底發生了什麼?經歷怎麼樣的一個過程?先給你們來張整體流程圖,具體步驟請看下文分解!本文首發地址爲GitHub博客,寫文章不易,請多多支持與關注! html
整體來講分爲如下幾個過程:前端
URL(Uniform Resource Locator),統一資源定位符,用於定位互聯網上資源,俗稱網址。 好比 http://www.w3school.com.cn/html/index.asp
,遵照如下的語法規則:nginx
scheme://host.domain:port/path/filename 各部分解釋以下:git
scheme - 定義因特網服務的類型。常見的協議有 http、https、ftp、file,其中最多見的類型是 http,而 https 則是進行加密的網絡傳輸。github
host - 定義域主機(http 的默認主機是 www)web
domain - 定義因特網域名,好比 w3school.com.cn
面試
port - 定義主機上的端口號(http 的默認端口號是 80)redis
path - 定義服務器上的路徑(若是省略,則文檔必須位於網站的根目錄中)。apache
filename - 定義文檔/資源的名稱segmentfault
在瀏覽器輸入網址後,首先要通過域名解析,由於瀏覽器並不能直接經過域名找到對應的服務器,而是要經過 IP 地址。你們這裏或許會有個疑問----計算機既能夠被賦予 IP 地址,也能夠被賦予主機名和域名。好比 www.hackr.jp
。那怎麼不一開始就賦予個 IP 地址?這樣就能夠省去解析麻煩。咱們先來了解下什麼是 IP 地址
IP 地址是指互聯網協議地址,是 IP Address 的縮寫。IP 地址是 IP 協議提供的一種統一的地址格式,它爲互聯網上的每個網絡和每一臺主機分配一個邏輯地址,以此來屏蔽物理地址的差別。IP 地址是一個 32 位的二進制數,好比 127.0.0.1 爲本機 IP。 域名就至關於 IP 地址喬裝打扮的假裝者,帶着一副面具。它的做用就是便於記憶和溝通的一組服務器的地址。用戶一般使用主機名或域名來訪問對方的計算機,而不是直接經過 IP 地址訪問。由於與 IP 地址的一組純數字相比,用字母配合數字的表示形式來指定計算機名更符合人類的記憶習慣。但要讓計算機去理解名稱,相對而言就變得困難了。由於計算機更擅長處理一長串數字。爲了解決上述的問題,DNS 服務應運而生。
DNS 協議提供經過域名查找 IP 地址,或逆向從 IP 地址反查域名的服務。DNS 是一個網絡服務器,咱們的域名解析簡單來講就是在 DNS 上記錄一條信息記錄。
例如 baidu.com 220.114.23.56(服務器外網IP地址)80(服務器端口號)
複製代碼
瀏覽器經過向 DNS 服務器發送域名,DNS 服務器查詢到與域名相對應的 IP 地址,而後返回給瀏覽器,瀏覽器再將 IP 地址打在協議上,同時請求參數也會在協議搭載,而後一併發送給對應的服務器。接下來介紹向服務器發送 HTTP 請求階段,HTTP 請求分爲三個部分:TCP 三次握手、http 請求響應信息、關閉 TCP 鏈接。
在客戶端發送數據以前會發起 TCP 三次握手用以同步客戶端和服務端的序列號和確認號,並交換 TCP 窗口大小信息。
客戶端發送一個帶 SYN=1,Seq=X 的數據包到服務器端口(第一次握手,由瀏覽器發起,告訴服務器我要發送請求了)
服務器發回一個帶 SYN=1, ACK=X+1, Seq=Y 的響應包以示傳達確認信息(第二次握手,由服務器發起,告訴瀏覽器我準備接受了,你趕忙發送吧)
客戶端再回傳一個帶 ACK=Y+1, Seq=Z 的數據包,表明「握手結束」(第三次握手,由瀏覽器發送,告訴服務器,我立刻就發了,準備接受吧)
謝希仁著《計算機網絡》中講「三次握手」的目的是「爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端,於是產生錯誤」。
TCP 三次握手結束後,開始發送 HTTP 請求報文。 請求報文由請求行(request line)、請求頭(header)、請求體四個部分組成,以下圖所示:
POST /chapter17/user.html HTTP/1.1
複製代碼
以上代碼中「POST」表明請求方法,「/chapter17/user.html」表示 URL,「HTTP/1.1」表明協議和協議的版本。如今比較流行的是 Http1.1 版本
請求頭部通知服務器有關於客戶端請求的信息。它包含許多有關的客戶端環境和請求正文的有用信息。其中好比:Host,表示主機名,虛擬主機;Connection,HTTP/1.1 增長的,使用 keepalive,即持久鏈接,一個鏈接能夠發多個請求;User-Agent,請求發出者,兼容性以及定製化需求。
name=tom&password=1234&realName=tomson
複製代碼
上面代碼,承載着 name、password、realName 三個請求參數。
服務器是網絡環境中的高性能計算機,它偵聽網絡上的其餘計算機(客戶機)提交的服務請求,並提供相應的服務,好比網頁服務、文件下載服務、郵件服務、視頻服務。而客戶端主要的功能是瀏覽網頁、看視頻、聽音樂等等,二者大相徑庭。 每臺服務器上都會安裝處理請求的應用——web server。常見的 web server 產品有 apache、nginx、IIS 或 Lighttpd 等。 web server 擔任管控的角色,對於不一樣用戶發送的請求,會結合配置文件,把不一樣請求委託給服務器上處理相應請求的程序進行處理(例如 CGI 腳本,JSP 腳本,servlets,ASP 腳本,服務器端 JavaScript,或者一些其它的服務器端技術等),而後返回後臺程序處理產生的結果做爲響應。
後臺開發如今有不少框架,但大部分都仍是按照 MVC 設計模式進行搭建的。 MVC 是一個設計模式,將應用程序分紅三個核心部件:模型(model)-- 視圖(view)--控制器(controller),它們各自處理本身的任務,實現輸入、處理和輸出的分離。
一、視圖(view)
它是提供給用戶的操做界面,是程序的外殼。
二、模型(model)
**模型主要負責數據交互。**在 MVC 的三個部件中,模型擁有最多的處理任務。一個模型能爲多個視圖提供數據。
三、控制器(controller)
**它負責根據用戶從"視圖層"輸入的指令,選取"模型層"中的數據,而後對其進行相應的操做,產生最終結果。**控制器屬於管理者角色,從視圖接收請求並決定調用哪一個模型構件去處理請求,而後再肯定用哪一個視圖來顯示模型處理返回的數據。 這三層是緊密聯繫在一塊兒的,但又是互相獨立的,每一層內部的變化不影響其餘層。每一層都對外提供接口(Interface),供上面一層調用。 至於這一階段發生什麼?簡而言之,首先瀏覽器發送過來的請求先通過控制器,控制器進行邏輯處理和請求分發,接着會調用模型,這一階段模型會獲取 redis db 以及 MySQL 的數據,獲取數據後將渲染好的頁面,響應信息會以響應報文的形式返回給客戶端,最後瀏覽器經過渲染引擎將網頁呈如今用戶面前。
響應報文由響應行(request line)、響應頭部(header)、響應主體三個部分組成。以下圖所示:
(1) 響應行包含:協議版本,狀態碼,狀態碼描述
狀態碼規則以下: 1xx:指示信息--表示請求已接收,繼續處理。 2xx:成功--表示請求已被成功接收、理解、接受。 3xx:重定向--要完成請求必須進行更進一步的操做。 4xx:客戶端錯誤--請求有語法錯誤或請求沒法實現。 5xx:服務器端錯誤--服務器未能實現合法的請求。
(2) 響應頭部包含響應報文的附加信息,由 名/值 對組成
(3) 響應主體包含回車符、換行符和響應返回數據,並非全部響應報文都有響應數據
瀏覽器拿到響應文本 HTML 後,接下來介紹下瀏覽器渲染機制
瀏覽器解析渲染頁面分爲一下五個步驟:
當數據傳送完畢,須要斷開 tcp 鏈接,此時發起 tcp 四次揮手。
給你們推薦一個好用的BUG監控工具Fundebug,歡迎免費試用!