瀏覽器
常見的瀏覽器內核有哪些
Trident內核：IE,MaxThon,TT,The World,360,搜狗瀏覽器等
Gecko內核：Netscape6及以上版本，FF,MozillaSuite/SeaMonkey等
Presto內核：Opera7及以上
Webkit內核：Safari,Chrome等
瀏覽器內核
主要分成兩部分：
渲染引擎(layout engineer或Rendering Engine)和JS引擎
渲染引擎：負責取得網頁的內容（HTML、XML、圖像等等）、整理訊息（例如加入CSS等），以及計算網頁的顯示方式，然后會輸出至顯示器或打印機。
瀏覽器的內核的不同對於網頁的語法解釋會有不同，所以渲染的效果也不相同。
所有網頁瀏覽器、電子郵件客戶端以及其它需要編輯、顯示網絡內容的應用程序都需要內核
JS引擎則：解析和執行javascript來實現網頁的動態效果
最開始渲染引擎和JS引擎並沒有區分的很明確，后來JS引擎越來越獨立，內核就傾向於只指渲染引擎
瀏覽器中輸入網址
1.http協議或https協議
2.url的組成：詳解url的組成
http
1. HTTP 請求報文結構
- 首行是Request-Line包括：請求方法，請求URI，協議版本，CRLF
- 首行之后是若干行請求頭，包括general-header，request-header或者entity-header，每個一行以CRLF結束
- 請求頭和消息實體之間有一個CRLF分隔
- 根據實際請求需要可能包含一個消息實體 一個請求報文例子如下：
GET /Protocols/rfc2616/rfc2616-sec5.html HTTP/1.1 Host: www.w3.org Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 Referer: https://www.google.com.hk/ Accept-Encoding: gzip,deflate,sdch Accept-Language: zh-CN,zh;q=0.8,en;q=0.6 Cookie: authorstyle=yes If-None-Match: "2cc8-3e3073913b100" If-Modified-Since: Wed, 01 Sep 2004 13:24:52 GMT name=qiu&age=25
2. HTTP 響應報文結構
- 首行是狀態行包括：HTTP版本，狀態碼，狀態描述，后面跟一個CRLF
- 首行之后是若干行響應頭，包括：通用頭部，響應頭部，實體頭部
- 響應頭部和響應實體之間用一個CRLF空行分隔
- 最后是一個可能的消息實體 響應報文例子如下：
HTTP/1.1 200 OK Date: Tue, 08 Jul 2014 05:28:43 GMT Server: Apache/2 Last-Modified: Wed, 01 Sep 2004 13:24:52 GMT # 最后修改時間，用於協商緩存 ETag: "40d7-3e3073913b100" # 文件hash，用於協商緩存 Accept-Ranges: bytes Content-Length: 16599 Cache-Control: max-age=21600 # 強緩存（瀏覽器端）最大過期時間 Expires: Tue, 08 Jul 2014 11:28:43 GMT # 強緩存（瀏覽器端）過期時間 P3P: policyref="http://www.w3.org/2001/05/P3P/p3p.xml" Content-Type: text/html; charset=iso-8859-1 {"name": "qiu", "age": 25}
3. HTTP常見狀態碼及其含義
- 1XX：信息狀態碼
- 100 Continue 繼續，一般在發送post請求時，已發送了http header之后服務端將返回此信息，表示確認，之后發送具體參數信息
- 2XX：成功狀態碼
- 200 OK 正常返回信息
- 201 Created 請求成功並且服務器創建了新的資源
- 202 Accepted 服務器已接受請求，但尚未處理
- 3XX：重定向
- 301 Moved Permanently 請求的網頁已永久移動到新位置。
- 302 Found 臨時性重定向。
- 303 See Other 臨時性重定向，且總是使用 GET 請求新的 URI。
- 304 Not Modified 自從上次請求后，請求的網頁未修改過。
- 4XX：客戶端錯誤
- 400 Bad Request 服務器無法理解請求的格式，客戶端不應當嘗試再次使用相同的內容發起請求。
- 401 Unauthorized 請求未授權。
- 403 Forbidden 禁止訪問。
- 404 Not Found 找不到如何與 URI 相匹配的資源。
- 5XX: 服務器錯誤
- 500 Internal Server Error 最常見的服務器端錯誤。
- 503 Service Unavailable 服務器端暫時無法處理請求（可能是過載或維護）。
通過網絡去訪問url
1. 網絡七層協議（OSI模型）
OSI是一個定義良好的協議規范集，並有許多可選部分完成類似的任務。它定義了開放系統的層次結構、層次之間的相互關系以及各層所包括的可能的任務，作為一個框架來協調和組織各層所提供的服務。
OSI參考模型並沒有提供一個可以實現的方法，而是描述了一些概念，用來協調進程間通信標准的制定。即OSI參考模型並不是一個標准，而是一個在制定標准時所使用的概念性框架。
- 第7層 應用層
應用層（Application Layer）提供為應用軟件而設計的接口，以設置與另一應用軟件之間的通信。例如：HTTP、HTTPS、FTP、Telnet、SSH、SMTP、POP3等。
- 第6層 表示層
表示層（Presentation Layer）把數據轉換為能與接收者的系統格式兼容並適合傳輸的格式。
- 第5層 會話層
會話層（Session Layer）負責在數據傳輸中設置和維護計算機網絡中兩台計算機之間的通信連接。
- 第4層 傳輸層
傳輸層（Transport Layer）把傳輸表頭（TH）加至數據以形成數據包。傳輸表頭包含了所使用的協議等發送信息。例如:傳輸控制協議（TCP）等。
- 第3層 網絡層
網絡層（Network Layer）決定數據的路徑選擇和轉寄，將網絡表頭（NH）加至數據包，以形成分組。網絡表頭包含了網絡資料。例如:互聯網協議（IP）等。
- 第2層 數據鏈路層
數據鏈路層（Data Link Layer）負責網絡尋址、錯誤偵測和改錯。當表頭和表尾被加至數據包時，會形成信息框（Data Frame）。數據鏈表頭（DLH）是包含了物理地址和錯誤偵測及改錯的方法。數據鏈表尾（DLT）是一串指示數據包末端的字符串。例如以太網、無線局域網（Wi-Fi）和通用分組無線服務（GPRS）等。
分為兩個子層：邏輯鏈路控制（logical link control，LLC）子層和介質訪問控制（Media access control，MAC）子層。
- 第1層 物理層
物理層（Physical Layer）在局部局域網上發送數據幀（Data Frame），它負責管理電腦通信設備和網絡媒體之間的互通。包括了針腳、電壓、線纜規范、集線器、中繼器、網卡、主機接口卡等。
2. TCP 協議三次握手
- 客戶端通過
SYN報文段發送連接請求，確定服務端是否開啟端口准備連接。狀態設置為SYN_SEND; - 服務器如果有開着的端口並且決定接受連接，就會返回一個
SYN+ACK報文段給客戶端，狀態設置為SYN_RECV； - 客戶端收到服務器的
SYN+ACK報文段，向服務器發送ACK報文段表示確認。此時客戶端和服務器都設置為ESTABLISHED狀態。連接建立，可以開始數據傳輸了。
翻譯成大白話就是： 客戶端：你能接收到我的消息嗎？ 服務端：可以的，那你能接收到我的回復嗎？ 客戶端：可以，那我們開始聊正事吧。
為什么是3次？：避免歷史連接，確認客戶端發來的請求是這次通信的人 為什么不是4次？：3次夠了第四次浪費
3. TCP 協議四次揮手
- 為什么不是兩次？
- 兩次情況客戶端說完結束就立馬斷開不再接收，無法確認服務端是否接收到斷開消息，但且服務端可能還有消息未發送完。
- 為什么不是三次？
- 3次情況服務端接收到斷開消息，向客戶端發送確認接受消息，客戶端未給最后確認斷開的回復
通過DNS解析域名的實際IP地址
發送至 DNS 服務器並獲得域名對應的 WEB 服務器的 ip 地址。
DNS 解析首先會從你的瀏覽器的緩存中去尋找是否有這個網址對應的 IP 地址，如果沒有就向OS系統的 DNS 緩存中尋找，如果沒有就是路由器的 DNS 緩存， 如果沒有就是 ISP 的DNS 緩存中尋找。 所以，緩存的尋找過程就是： 瀏覽器 -> 系統 -> 路由器 -> ISP。 如果在某一個緩存中找到的話，就直接跳到下一步。 如果都沒有找到的話，就會向 ISP 或者公共的域名解析服務發起 DNS 查找請求。這個查找的過程還是一個遞歸查詢的過程。
檢查瀏覽器是否有緩存
通過Cache-Control和Expires來檢查是否命中強緩存，命中則直接取本地磁盤的html（狀態碼為200 from disk(or memory) cache，內存or磁盤）
如果沒有命中強緩存，則會向服務器發起請求（先進行下一步的TCP連接），服務器通過Etag和Last-Modify來與服務器確認返回的響應是否被更改（協商緩存），若無更改則返回狀態碼（304 Not Modified）,瀏覽器取本地緩存；
若強緩存和協商緩存都沒有命中則返回請求結果。
與 WEB 服務器建立 TCP 連接
TCP 協議通過三次握手建立連接。
- 客戶端通過
SYN報文段發送連接請求，確定服務端是否開啟端口准備連接。狀態設置為SYN_SEND; - 服務器如果有開着的端口並且決定接受連接，就會返回一個
SYN+ACK報文段給客戶端，狀態設置為SYN_RECV； - 客戶端收到服務器的
SYN+ACK報文段，向服務器發送ACK報文段表示確認。此時客戶端和服務器都設置為ESTABLISHED狀態。連接建立，可以開始數據傳輸了。
翻譯成大白話就是：
- 客戶端：你能接收到我的消息嗎？
- 服務端：可以的，那你能接收到我的回復嗎？
- 客戶端：可以，那我們開始聊正事吧。
為什么是3次？：避免歷史連接，確認客戶端發來的請求是這次通信的人。
為什么不是4次？：3次夠了第四次浪費
若協議是https則會做加密
HTTPS = HTTP + 加密 + 認證 + 完整性保護
- 要先申請CA證書，並安裝在服務器上（一個文件，配置nginx支持監聽443端口開啟ssl並設置證書路徑）
- 瀏覽器發送請求；
- 網站從瀏覽器發過來的加密規則中選一組自身也支持的加密算法和hash算法，並向瀏覽器發送帶有公鑰的證書，當然證書還包含了很多信息，如網站地址、證書的頒發機構、過期時間等。
- 瀏覽器解析證書。
- 驗證證書的合法性。如頒發機構是否合法、證書中的網站地址是否與訪問的地址一致，若不合法，則瀏覽器提示證書不受信任，若合法，瀏覽器會顯示一個小鎖頭。
- 若合法，或用戶接受了不合法的證書，瀏覽器會生成一串隨機數的密碼（即密鑰），並用證書中提供的公鑰加密。
- 使用約定好的hash計算握手消息，並使用生成的隨機數（即密鑰）對消息進行加密，最后將之前生成的所有消息一並發送給網站服務器。
- 網站服務器解析消息。用已有的私鑰將密鑰解密出來，然后用密鑰解密發過來的握手消息，並驗證是否跟瀏覽器傳過來的一致。然后再用密鑰加密一段握手消息，發送給瀏覽器。
- 瀏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之后所有的通信數據將由之前瀏覽器生成的隨機密碼並利用對稱加密算法進行加密。這里瀏覽器與網站互相發送加密的握手消息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密數據，為后續真正數據的傳輸做一次測試。
下圖表示https加密通信的過程：
瀏覽器發送請求獲取頁面html
瀏覽器向 WEB 服務器的 ip 地址發送相應的 http get 請求頁面html。
通常的請求行是: 請求的方式（get或post） + 請求的資源的位置（url） + HTTP/[版本號](HTTP/1.1)
發起http請求的過程主要是組裝http報文並將報文發向指定地址的過程。
http協議的具體信息可以參考：HTTP介紹教程
服務器響應html
這里的服務器可能是server或者是cdn
注：cdn - 內容分發網絡，可用來加快傳輸速度，主要用來存儲靜態文件，例如前端的html、css、js、圖片文件等。具體請參考：CDN概念基本介紹
服務器上可能會通過nginx等設置靜態資源代理，將url對應的html等靜態資源返回。
nginx是常用的反向代理服務器，介紹請見：Nginx 入門指南
如果網站是博客或者其他需要seo友好的頁面，就需要做服務端渲染，這時服務器會根據模版和數據渲染好html文件返回給前端。
常見的服務端渲染方案有：ejs、art-template、等模版語法，也有基於vue、react等框架的服務端渲染框架nuxt.js及next.js等。
瀏覽器解析 HTML
- 瀏覽器下載 HTML 數據，將html文檔解析成為一個個
標簽，這些標簽組成了樹狀結構 - 如果解析到
style標簽則開始解析css，如果解析到link標簽則先異步下載，完成后解析css。 - 如果遇到
script標簽，判斷是行內寫法則直接解析執行，如果是src引入則同步下載腳本文件，下載完成立即執行，注意這里下載過程是阻塞的，其他流程都會等下載完成后執行。
瀏覽器解析HTML文檔過程內容較多，詳情請看:
瀏覽器渲染頁面
瀏覽器渲染頁面的過程主要是解析html文檔組成標簽節點樹，解析css形成樣式規則樹，標簽節點樹和樣式規則樹共同組成渲染樹，瀏覽器最終顯示渲染樹形成頁面。
- 瀏覽器會將HTML解析成一個DOM樹，DOM 樹的構建過程是一個深度遍歷過程：當前節點的所有子節點都構建好后才會去構建當前節點的下一個兄弟節點。（更具體的解析HTML過程看上一篇博客：點擊打開鏈接）
- 將CSS解析成 CSS Rule Tree（css規則樹） 。
- 解析完成后，瀏覽器引擎會根據DOM樹和CSS規則樹來構造 Render Tree。注意：Render Tree 渲染樹並不等同於 DOM 樹，因為一些像Header或display:none的東西就沒必要放在渲染樹中了。
- 有了Render Tree，瀏覽器已經能知道網頁中有哪些節點、各個節點的CSS定義以及他們的從屬關系。下一步進行layout，進入布局處理階段，即計算出每個節點在屏幕中的位置。
- 再下一步就是繪制，即遍歷RenderTree，並使用用戶界面后端層繪制每個節點。根據計算好的信息繪制整個頁面。
瀏覽器解析執行js腳本
這個過程中可能會有dom操作、ajax發起的http網絡請求等。
瀏覽器發起網絡請求
web-socket、ajax等，這個過程通常是為了獲取數據
服務器響應ajax請求
- ajax請求在到達真正的server之前，可能還會經過網關全線校驗、消息隊列或nginx等負載均衡處理
- 到達server后，后端會解析http請求報文，得到url、請求參數、http頭、cookie等等信息
- 登錄校驗、權限校驗（cookie校驗、jwt權限校驗等）
- 可能會查詢數據庫，進行常用的CRUD（增刪改查）等操作
- 返回響應數據
瀏覽器處理事件循環等異步邏輯。
setTimeout、setInterval、Promise等宏任務、微任務隊列