整理之前的筆記時，發現之前的掌握的東西尚差的太遠，就仔細查詢了這個問題。
總體來說，可以分為一下幾個部分：
1. dns解析
2. tcp連線
3. 傳送http請求
4. 伺服器處理請求並返回http報文
5. 瀏覽器解析渲染頁面
6. 連線結束
dns解析是將網域名稱轉換成ip的過程,從使用者在瀏覽器位址列輸入url開始
chrome檢視瀏覽器dns快取:chrome://net-internals/#dns4、5步借用網上的來說明：
關於dns的相關知識有:
1. 減少dns查詢,各級快取的使用，使用keep-alive特性來減少查詢。
2. dns預解析:
http協議是使用tcp作為其傳輸層協議的，當tcp出現瓶頸時，http也會受到影響。
tcp3次握手
tcp4次揮手
tcp協議：tcp是主機對主機層的傳輸控制協議，提供可靠的連線服務。
簡單的說一下5層網路協議：
關於tcp/udp協議的區別，這應該屬於網路的知識。
先簡單說明一下tcp的標誌位（位碼），有6種表示：
syn(synchronous建立聯機)常用的有：syn，ack，fin。ack(acknowledgement 確認)
psh(push傳送)
fin(finish結束)
rst(reset重置)
urg(urgent緊急)
sequence number(順序號碼)
acknowledge number(確認號碼)
各個狀態的意義：
listen - 偵聽來自遠方tcp埠的連線請求；在我們分析3次握手和4次揮手的過程中，我們困惑的地方可能是因為我們不清楚傳送的位碼的意義和對應狀。syn-sent -在傳送連線請求後等待匹配的連線請求；
syn-received -在收到和傳送乙個連線請求後等待對連線請求的確認；
established- 代表乙個開啟的連線，資料可以傳送給使用者；
fin-wait-1 - 等待遠端tcp的連線中斷請求，或先前的連線中斷請求的確認；
fin-wait-2 - 從遠端tcp等待連線中斷請求；
close-wait - 等待從本地使用者發來的連線中斷請求；
closing -等待遠端tcp對連線中斷的確認；
last-ack - 等待原來發向遠端tcp的連線中斷請求的確認；
time-wait -等待足夠的時間以確保遠端tcp接收到連線中斷請求的確認；
closed - 沒有任何連線狀態；
第1次握手：建立連線時，客戶端a傳送syn包到伺服器b，並進入syn_send狀態，等待伺服器b確認。
第2次握手：伺服器b收到syn包，必須確認客戶a的syn，同時自己也傳送乙個syn包，即syn+ack包，此時伺服器b進入syn_recv狀態。
第3次握手：客戶端a收到伺服器b的syn＋ack包，向伺服器b傳送確認包ack，此包傳送完畢，客戶端a和伺服器b進入established狀態，完成三次握手。
由於tcp連線是全雙工的，因此每個方向都必須單獨進行關閉。這個原則是當一方完成它的資料傳送任務後就能傳送乙個fin來終止這個方向的連線。收到乙個 fin只意味著這一方向上沒有資料流動，乙個tcp連線在收到乙個fin後仍能傳送資料。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。第1次揮手：客戶端a傳送乙個fin，用來關閉客戶a到伺服器b的資料傳送。客戶端和伺服器都可以發起揮手
第2次揮手：伺服器b收到這個fin，它發回乙個ack。
第3次揮手：伺服器b關閉與客戶端a的連線，傳送乙個fin給客戶端a。
第4次揮手：客戶端a發回ack報文確認。
簡單分析：
1. tcp協議的連線是全雙工連線，乙個tcp連線存在雙向的讀寫通道。
2. 每個方向都必須單獨進行關閉。
3. 先關讀，後關寫。
4. 以伺服器發起的關閉為例：
可以對應4次揮手分析，每次揮手關閉了哪個通道，就會清晰。這樣我們可以對tcp協議在前端的應用有了清晰的理解。
主要發生在客戶端，是構造http請求報文並通過tcp傳送到伺服器指定的埠。
http請求報文是由三部分組成: 請求行, 請求報頭和請求正文。
關於http請求頭和響應頭我會單獨在寫一篇博文的。
伺服器從接收到tcp報文開始，對http協議進行解析，並按照報文的格式進一步封裝成http request物件供上層使用。
http響應報文是由3部分組成的：狀態碼，響應報頭，請求報頭。
狀態碼取值說明：
1. 1xx：指示資訊–表示請求已接收，繼續處理。
2. 2xx：成功–表示請求已被成功接收、理解、接受。
3. 3xx：重定向–要完成請求必須進行更進一步的操作。
4. 4xx：客戶端錯誤–請求有語法錯誤或請求無法實現。
5. 5xx：伺服器端錯誤–伺服器未能實現合法的請求。
要理解常見的狀態碼的含義，http快取。
瀏覽器在收到html,css,js檔案後，它是如何把頁面呈現到螢幕上的？下圖對應的就是webkit渲染的過程。
這是乙個邊解析邊渲染的過程。首先瀏覽器解析html檔案構建dom樹，然後解析css檔案構建渲染樹，等到渲染樹構建完成後，瀏覽器開始布局渲染樹並將其繪製到螢幕上。這個過程比較複雜，涉及到兩個概念: reflow(回流)和repain(重繪)。dom節點中的各個元素都是以盒模型的形式存在，這些都需要瀏覽器去計算其位置和大小等，這個過程稱為relow;當盒模型的位置,大小以及其他屬性，如顏色,字型,等確定下來之後，瀏覽器便開始繪製內容，這個過程稱為repain。頁面在首次載入時必然會經歷reflow和repain。reflow和repain過程是非常消耗效能的，尤其是在移動裝置上，它會破壞使用者體驗，有時會造成頁面卡頓。所以我們應該盡可能少的減少reflow和repain。
js的解析是由瀏覽器中的js解析引擎完成的。參見我的另一篇文章js執行緒
連線是否關閉，還要看connection欄位是否設定為長連線。
關於http報文，可以說的地方很多，要搞懂http快取必須先懂這些，對報文的字段都要清晰的理解。請求是https時，有何差異，這些我會陸續更新https，http協議報文等博文意義說明，這是我前端知識體系化必走之路，我會對遇見的知識點，逐一寫部落格，demo，來理清他們。
從輸入URL到頁面載入發生了什麼
最近在進行前端面試方面的一些準備，看了網上許多相關的文章，發現有乙個問題始終繞不開 在瀏覽器中輸入url到整個頁面顯示在使用者面前時這個過程中到底發生了什麼。仔細思考這個問題，發現確實很深，這個過程涉及到的東西很多。這個問題的回答真的能夠很好的考驗乙個web工程師的水平，於是我自問自答一番。總體來說...
從輸入URL到頁面載入發生了什麼
tcp連線 傳送http請求 伺服器處理請求並返回http報文 瀏覽器解析渲染頁面 連線結束 系統快取主要存在 etc hosts linux系統 中 http請求 2xx 成功 表示請求已被成功接收 理解 接受。3xx 重定向 要完成請求必須進行更進一步的操作。4xx 客戶端錯誤 請求有語法錯誤或...
從輸入URL到頁面載入發生了什麼
tcp連線 傳送http請求 伺服器處理請求並返回http報文 瀏覽器解析渲染頁面 連線結束 系統快取主要存在 etc hosts linux系統 中 2xx 成功 表示請求已被成功接收 理解 接受。3xx 重定向 要完成請求必須進行更進一步的操作。4xx 客戶端錯誤 請求有語法錯誤或請求無法實現。...