從輸入URL到頁面展示這中間發(fā)生了什么
Chrome多進程瀏覽器架構
-
瀏覽器進程主要負責用戶交互、子進程管理和文件儲存等功能。 -
網(wǎng)絡進程是面向渲染進程和瀏覽器進程等提供網(wǎng)絡資源加載。 -
渲染進程也稱為瀏覽器內核，JavaScript引擎V8都是運行在該進程中，默認會為每個標簽窗口頁面開辟一個獨立的進程，負責將網(wǎng)絡下載的HTML、JavaScript、CSS、圖片等資源轉化為交互的頁面。 -
GPU進程:用于3D繪制等
僅僅打開了1個頁面，為什么有4個進程？
因為打開1個頁面至少需要1個網(wǎng)絡進程、1個瀏覽器進程、1個GPU進程以及1個渲染進程，共4個
補充1：進程和線程
進程是一個程序運行的實例，操作系統(tǒng)會為進程創(chuàng)建獨立的內存，用來存放運行所需要的代碼和數(shù)據(jù)
線程是進程的組成部分，每個進程可以有多個線程其中至少一個主線程，這些線程由所屬的進程進行啟動和管理。
進程和線程之間關系的特點:
- 只要某個線程執(zhí)行出錯，將會導致整個進程崩潰
- 進程與進程之間相互隔離
- 線程之間可以共享所屬進程的數(shù)據(jù)
- 進程所占用的資源會在其關閉后由操作系統(tǒng)回收
整體的流程
1. 瀏覽器接收到輸入的URL后，先解析URL
判斷用戶輸入的是 URL 還是query？
- 如果是搜索內容，地址欄會使用瀏覽器默認的搜索引擎，來合成新的帶搜索關鍵字的URL。
- 若符合URL規(guī)則，整合
URL + 對應協(xié)議頭(http/https)形成完整的URL
URL結構:Protocol://Host:port/Path?Query#Fragment
瀏覽器接收到輸入的URL后，先對URL解析，把我們請求需要的協(xié)議、域名、端口、路徑這些信息解析提取出來并構造一個HTTP請求。
瀏覽器發(fā)送請求前，嘗試緩存命中
- 根據(jù)請求頭的
expires和cache-control:max-age判斷資源是否命中，如果命中。直接從緩存中獲取資源，返回狀態(tài)碼為200的響應。 - 如果沒有命中，根據(jù)請求頭
If-modified-since: Last-Modified或者If-none-match:ETag發(fā)送一個get請求詢問服務器緩存是否修改，如果沒有修改返回304，從緩存中獲取資源。如果修改了返回狀態(tài)碼為200的請求資源結果。
這里的2已經(jīng)進入網(wǎng)絡請求的流程。協(xié)商緩存時在DNS之后發(fā)生的
2.建立URL請求
網(wǎng)絡進程會查找本地緩存是否緩存了該資源。如果有緩存資源，那么直接返回資源給瀏覽器進程；如果在緩存中沒有查找到資源，那么直接進入網(wǎng)絡請求流程。第一步是要進行DNS解析獲取IP地址。
DNS解析出IP地址
DNS(Domain Name System) 域名系統(tǒng)，DNS解析的目的是將URL中的Host字段轉換成網(wǎng)絡中具體的IP地址。
DNS解析的過程:遞歸查詢+迭代查詢
先在客戶端進行查詢有沒有解析過的記錄(DNS緩存)，在這里任何一步找到就會結束查找流程。如果都沒有找到，開始迭代查詢。
1.先去DNS根域名(.)服務器查詢，屬于哪個頂級域名服務器(.com)，然后返回頂級域名服務器IP
2.再根據(jù)返回的IP去頂級域名服務器查找，屬于哪個權限域名服務器(xxx.com)，返回權限域名服務器IP
3.再根據(jù)返回的IP去權限域名服務器查找
4.找到了就返回目標地址的IP，沒有就報錯
優(yōu)化:DNS預解析
大型網(wǎng)站，有多個不同服務器資源的情況下，都可采取DNS預解析rel="dns-prefetch"，提前解析，減少頁面卡頓。
當網(wǎng)頁打開時，瀏覽器會在加載網(wǎng)頁時對網(wǎng)頁中的域名進行解析緩存，這樣在你單擊當前網(wǎng)頁中的連接時就無需進行DNS的解析，減少用戶等待時間，提高用戶體驗。
使用IP地址建立TCP連接 三次握手
網(wǎng)絡進程拿到IP后，查看URL請求的端口號，如果有根據(jù)IP地址:端口號創(chuàng)建新的套接字發(fā)起TCP連接。
http 默認端口80， https 默認端口443
第一次握手: 客戶端隨機初始化序列號，TCP報文序列號seq=x，SYN同步標志位為1，用來建立連接，然后把該報文發(fā)送給服務端，客戶端進入等待服務端確認的狀態(tài)。
第二次握手:服務器端收到客戶端發(fā)來的SYN同步標志位=1的數(shù)據(jù)包后，知道是在建立連接。服務器自己也生成初始序列號，TCP報文序列號seq=y，SYN同步標志位和ACK確認標志位置1，表示建立連接之后的響應。ack確認號=x+1，期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)序列號位x+1，作為客戶端建立連接請求的應答。
第三次握手:客戶端收到服務端的確認應答后，檢查ack確認號是否x+1，ACK確認標志位是否=1。若正確就返回ack確認號為y+1,序列號為x+1，及ACK=1的數(shù)據(jù)包發(fā)送給服務器，確認服務器的應答。
服務器端收到應答包，檢查ack確認號是否=y+1來確認是否建立連接成功。
為什么要三次握手？
建立TCP連接會先經(jīng)歷三次握手，目的是確保數(shù)據(jù)到達目的–> 客戶端和服務端的接收和發(fā)送能力沒有問題
第二次握手 服務器端同時返回SYN建立連接+ACK確認，說明客戶端發(fā)送的建立連接請求服務器端可以接收到，說明客戶端發(fā)送能力ok。
第三次握手 客戶端向服務器發(fā)送ACK確認標志=1，表示對服務器端的應答，說明服務器發(fā)送能力ok，服務端的接收能力ok。
服務器端收到應答包，檢查成功，說明客戶端的接收能力ok，建立連接。
也可以從為什么不是兩次握手的角度回答
為何不能是兩次握手？
可能連接請求因網(wǎng)絡滯留了一段時間，以至于到達服務端已經(jīng)失效了，但是服務端會誤認為是個新的連接請求，于是向客戶端發(fā)出確認報文，同意建立連接。假設采用兩次握手，那么服務端發(fā)出確認報文，表示連接已建立，但客戶端并沒有發(fā)出確認建立的連接，也不會向服務端發(fā)送任何數(shù)據(jù)，服務端因連接占用導致資源浪費。
三次握手過程中可以攜帶數(shù)據(jù)嗎？ -第三次握手可以
假如第一次握手可以攜帶數(shù)據(jù)的話，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數(shù)據(jù)。因為攻擊者根本就不理服務器的接收、發(fā)送能力是否正常，然后瘋狂著重復發(fā) SYN 報文的話，這會讓服務器花費很多時間、內存空間來接收這些報文。
也就是說，第一次握手不可以放數(shù)據(jù)，其中一個簡單的原因就是會讓服務器更加容易受到攻擊了。而對于第三次的話，此時客戶端已經(jīng)處于 ESTABLISHED 狀態(tài)。對于客戶端來說，他已經(jīng)建立起連接了，并且也已經(jīng)知道服務器的接收、發(fā)送能力是正常的了，所以能攜帶數(shù)據(jù)也沒啥毛病。
syn洪泛攻擊
SYN攻擊就是Client在短時間內偽造大量不存在的IP地址，并向Server不斷地發(fā)送SYN包，Server則回復確認包，并等待Client確認，由于源地址不存在，因此Server需要不斷重發(fā)直至超時，這些偽造的SYN包將長時間占用未連接隊列，導致正常的SYN請求因為隊列滿而被丟棄，從而引起網(wǎng)絡擁塞甚至系統(tǒng)癱瘓。SYN 攻擊是一種典型的 DoS/DDoS 攻擊。
檢測 SYN 攻擊非常的方便，當你在服務器上看到大量的半連接狀態(tài)時，特別是源IP地址是隨機的，基本上可以斷定這是一次SYN攻擊。
解決辦法
1.縮短超時時間
2.過濾網(wǎng)關
HTTP請求
服務器接收到請求信息后，會根據(jù)請求信息生成響應行、響應頭和響應體等信息，并發(fā)給網(wǎng)絡進程。瀏覽器接收到響應數(shù)據(jù)之后，如果是http1.1以下則直接關閉連接，否則雙方都可以根據(jù)情況選擇關閉TCP連接或者保留重用，現(xiàn)在瀏覽器默認都會保持連接(keep-alive)。
關閉TCP連接 四次揮手
TCP連接是全雙工的，因此，每個方向都必須要單獨進行關閉
第一次揮手:客戶端打算關閉連接，發(fā)送FIN標志位置1的報文，表示客戶端沒有發(fā)送給服務端的數(shù)據(jù)了，要關閉連接了。
第二次揮手:服務器收到客戶端的FIN報文后，發(fā)送ACK確認標志位=1，表示你的關閉請求我收到啦，你可以關閉了。
可能服務器端還有未完成的數(shù)據(jù)傳遞，所以請客戶端繼續(xù)等待。
第三次揮手：當服務器確認沒有數(shù)據(jù)發(fā)送之后，發(fā)送FIN為1、ack=u+1、seq=w的FIN報文，準備關閉連接
第四次揮手:客戶端收到FIN報文后，向服務器進行應答。服務器會等待客戶端的應答后才會真正斷開連接，如果服務器沒有收到應答報文則會重傳。客戶端等待2*報文段最大生存時間 后依然沒有收到回復，說明服務器端已正常關閉，客戶端也可以關閉連接了。
為什么要等待2個報文段最大生存時間
1.假設第四次揮手的ACK應答包丟失，服務器沒有收到應答報文則會重傳FIN報文，在2個報文段最大生存時間之內 如果客戶端再次收到FIN報文 重發(fā)ACK應答報文。保證雙方都可以正常進入關閉狀態(tài)
2.確保在創(chuàng)建新連接時，先前網(wǎng)絡中殘余的數(shù)據(jù)都丟失了
為什么連接的時候是三次握手，關閉的時候卻是四次握手？
因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。
但是關閉連接時，當Server端收到FIN報文時，可能服務器還有數(shù)據(jù)需要發(fā)送，所以只能先回復一個ACK報文，告訴Client端，“你發(fā)的FIN報文我收到了”。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。文章來源：http://www.zghlxwxcb.cn/news/detail-482621.html
3.開啟渲染進程
筆記文章來源地址http://www.zghlxwxcb.cn/news/detail-482621.html
到了這里，關于從輸入URL到頁面展示這中間發(fā)生了什么的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
