瀏覽器上面輸入URL敲擊回車后都發生了什么
這哥問題是一個常被用作面試題的問題下面我們來細說一下這個流程和相關概念
URL 解析
URL，統一資源定位符，是用來表示從互聯網上得到的資源位置和訪問這些資源的方法，俗稱網址！互聯網上的所有資源，都有一個唯一確定的URL。URL的一般形式由一下四個部分組成：
<協議>://<主機>:<端口>/<路徑>URL的第一部分是最左邊的<協議>。這里的<協議>就是指出使用什么協議來獲取萬維網文檔。現在最常用的協議就是http（超文本傳輸協議HTTP），其次就是ftp（文件傳輸協議FTP）。在協議后面的:// 是規定的格式。它的右邊是第二部分<主機>，它指出這個萬維網文檔是在哪一臺主機上。這里的<主機>就是指該主機在互聯網上的域名 。在后面是第三部分和第四部分<端口>和<路徑>,有時可以省略。如果是采用http協議訪問萬維網文檔，如果省略端口，走會訪問默認端口80，如果省略路徑，則URL就指到互聯網上的某個主頁（home page）。而URL解析，就是當用戶輸入URL并回車后，瀏覽器對拿到的URL進行識別，抽取出域名字段，比如https://www.baidu.com,它的域名就是www.baidu.com,拿到域名后，就會順利進行第二步了，就是DNS域名解析!
圖片
DNS 域名解析
域名系統DNS（Domain Name System）是互聯網使用的命名系統，用來把便于人們使用的機器名轉換為IP地址。用戶與互聯網上的某臺主機通信時，必須要知道對方的IP地址。然而用戶很難記住長達32位的二進制主機地址。及時是點分十進制IP地址也并不容易記憶。但是在應用層為了方便用戶記憶各種網絡應用，連接在互聯網上的主機不僅有IP地址，而且還有便于用戶記憶的主機名字（域名）。域名系統DNS能夠把互聯網上的主機名字轉換為IP地址。既然互聯網上的每一臺主機都有主機名字，那么為什么機器在處理IP數據報的時候要使用IP地址而不是用域名呢？簡單來說，這是因為IP地址的長度是固定的32位（如果是IPv6地址，那就是固定的128位，也是定長的），而域名的長度并不是固定的，機器處理起來比較困難。注意，可以在瀏覽器中輸入域名得出網頁內容，也可以輸入對應的IP地址得到網頁內容。雖然得出的內容是一樣的，但調用的過程不一樣，輸入IP地址是直接從主機上調用內容，輸入域名是通過對應的域名解析服務器指向對應的主機IP地址，在從主機中調用網址的內容。
圖片
建立 TCP 連接
第一次握手：客戶端向服務器端發送請求（SYN=1） 等待服務器響應；第二次握手：服務器收到請求并確認，回復一個指令（SYN=1，ACK=1）；第三次握手：客戶端收到服務器的回復指令并返回確認（ACK=1）。
圖片
這里我又有一個問題來了，為什么A最后還要發送一次確認呢？請讀者稍加思考一下！
這主要是為了防止已失效的連接請求報文段突然又傳送到了B，因而產生錯誤！所謂的已失效的請求報文段是這樣產生的。考慮一種正常情況，A發出連接請求，但因連接請求報文丟失而未收到確認。于是A在重傳一次連接請求。后來收到了來自服務器的連接請求確認，建立了連接。數據傳輸完畢后，就通過四次揮手釋放了連接。在該過程中，A共發出了兩個連接請求報文段，其中第一個丟失，第二個達到了B，沒有已失效的連接請求報文段。
現假定出現一種異常情況，即A發出的第一個連接請求報文段并沒有丟失，而是在某些網絡結點長時間滯留了，以致延誤到連接釋放以后的某個時間才達到B。本來這是一個早已失效的報文段，但B收到此失效的連接請求報文段后，就誤認為是A又發出了一次新的連接請求。于是就想A發出確認連接報文段，同意建立連接。假定不采用三次握手，那么只要B發出確認，新的連接就建立了。由于現在A并沒有發出建立連接的請求，因此不會理睬B的確認，也不會向B發送數據。但B卻認為新的運輸連接已經建立了，并一直等待A發送數據。于是B的資源就這樣白白浪費了。
發送 HTTP 請求
HTTP協議定義了瀏覽器怎樣向萬維網服務器請求萬維網文檔，以及服務器怎樣把文檔傳送給瀏覽器。從層次的角度看，HTTP是面向事務的應用層協議。HTTP有兩類報文：
（1）請求報文——從客戶端向服務器發送請求報文。如下圖所示。
（2）響應報文——從服務器到客戶端的回答。
圖片
HTTP請求報文有三部分組成，即請求行，首部行和實體主體三部分組成。請求報文的第一行，請求行只有三個內容，即方法，請求資源的URL以及HTTP的版本。這里的方法就是對所請求的對象進行操作這些方法實際上也就是一些命令。
常見請求報文的方法
方法（操作） | 意義 |
OPTION | 請求一些選項的信息 |
GET | 請求讀取由URL所標志的信息 |
HEAD | 請求讀取由URL所標志的信息的首部 |
CONNECT | 用于代理服務器 |
POST | 給服務器添加信息 |
PUT | 在指明的URL下存儲一個文檔 |
DELETE | 刪除指明的URL所標志的資源 |
TRACE | 用來進行環回測試的請求報文 |
例如下面是一個HTTP的請求報文的開始行的格式,由方法，域名以及HTTP的版本構成。注意（方法與域名之間含空格，域名與HTTP版本之間也含空格）。
GET http://www.lovsh.com/dir/index.html HTTP/1.1服務器處理相關的請求
接受HTTP報文后，會對連接進行處理，對HTTP協議進行解析（請求方法、域名、路徑等），并且進行一些驗證：
驗證是否配置虛擬主機驗證虛擬主機是否接受此方法驗證該用戶可以使用該方法（根據 IP 地址、身份信息等）重定向假如服務器配置了 HTTP 重定向，就會返回一個 301永久重定向響應，瀏覽器就會根據響應，重新發送 HTTP 請求（重新執行上面的過程）。URL 重寫然后會查看 URL 重寫規則，如果請求的文件是真實存在的，比如圖片、html、css、js文件等，則會直接把這個文件返回。否則服務器會按照規則把請求重寫到 一個 REST 風格的 URL 上。然后根據動態語言的腳本，來決定調用什么類型的動態文件解釋器來處理這個請求。
圖片
返回響應的結果
服務器每收到一個請求報文后，對應的都會回復一個響應報文。HTTP的響應報文由狀態行，首部行以及實體主體組成，一般用開始行是請求行還是狀態行來區分是請求報文還是響應報文！
響應報文的第一行就是狀態行，狀態行包括版本，狀態碼以及短語組成。狀態碼都是三位數字構成的，分為5大類，原先有33種，后來又增加了幾種。這5大類的狀態碼都是以不同的數字開頭的。
狀態碼 | 意義 |
1xx | 表示通知信息，如請求收到了或正在進行處理 |
2xx | 表示成功，如接受或知道了 |
3xx | 表示重定向，如要完成請求還必須采取進一步的行動 |
4xx | 表示客戶的差錯，如請求中有錯誤的語法或不能完成 |
5xx | 表示服務器的錯誤，如服務器失效無法完成請求 |
斷開 TCP 連接
第一次揮手：客戶端向服務器發送連接釋放報文段（FIN=1），等待服務器響應；
第二次揮手：服務器收到連接釋放報文段并發出確認（ACK=1），客戶端到服務器的連接關閉，此時TCP處理半關閉狀態，需要等到服務器向客戶端發送數據結束；
第三次揮手：服務器向客戶端發送連接釋放報文段（FIN=1，ACK=1），并等待客戶端的確認；
第四次揮手：客戶端收到服務器的連接釋放報文段并給出確認（ACK=1），連接釋放。
圖片
瀏覽器解析渲染頁面
HTMl解析與頁面渲染的過程如下所示：
- 瀏覽器獲取到 html 資源后開始解析 html (dom tree)
- 解析到 css 后根據 css 生成 css 規則樹 (style rules).
- 在 dom 樹和 css 規則樹都生成完后，通過 dom 樹和 css 規則樹生成渲染樹( render tree )
- 渲染樹構建完成后，瀏覽器開始計算元素的大小和位置( layout )
- 根據計算好的節點信息將內容繪制到屏幕上( painting )
圖片
注意：
瀏覽器為了提升性能，在 URL 解析之后，實際會先查詢是否有緩存，如果緩存命中，則直接返回緩存資源。
如果是 HTTPS 協議，在建立 TCP 連接之后，還需要進行 SSL/TLS 握手過程，以協商出一個會話密鑰，用于消息加密，提升安全性。
