http輸入地址到頁面加載完

一.從瀏覽器接受url開始,開啓網絡請求線程。參考https://www.cnblogs.com/chengxs/p/11039155.html在他的基礎上補充了些
1.瀏覽器是多進程的
(1)瀏覽器是多進程的
(2)不一樣類型的標籤頁會開啓一個新的進程
(3)相同類型的標籤頁會合併到一個進程中
2.瀏覽器中各個進程及做用
(1)瀏覽器進程:只有一個進程,負責各個標籤的建立和銷燬;負責瀏覽器頁面顯示,負責資源的下載和管理。
(2)第三方插件進程:每一個第三方插件使用都會建立一個對應的進程
(3)GPU進程:最多一個進程,負責3D繪製和硬件加速
(4)瀏覽器渲染進程:每一個tab頁對應一個進程,主要負責html,css,js的解析,執行和渲染,以及事件處理等
3.瀏覽器渲染進程
  每一個tab頁是一個瀏覽器內核進程,該進程是多線程的:GUI線程,JS引擎線程,事件觸發線程,定時器線程,異步的http網絡請求線程。JS引擎線程是內核線程中的一個線程,因此常說JS引擎是單線程的。
4.解析url
  url:統一資源定位符。包括:protocol,host,port,path,query,fragment
二.開啓網絡請求線程到發出一個完整的http請求。
1.每一次網絡請求須要開闢單獨的線程進行,好比URL解析到http協議,就會新建一個網絡線程去處理資源下載。
   URL會根據解析得協議,開闢網絡線程,前往請求資源。
2.開啓網絡線程到發出一個完整的http請求
(1)DNS解析:根據輸入的域名,須要對其進行解析成對應的ip,解析過程爲:先去瀏覽器緩存中查找該域名,若是未命中就去本機的緩存中查找,若是尚未命中,就去查找本機的host文件,若是尚未命中就去請求本地域名服務器(,這個DNS服務器不是權威服務器,而是至關於一個代理的dns解析服務器,他會幫你迭代權威服務器返回的應答,而後把最終查到IP返回給你,可在本機進行配置,若是沒有配置回去請求公共域名解析地址114.114.114.114和8.8.8.8),若是尚未命中,本地域名服務器就會從配置文件中讀取配置13個根域名服務器的地址,向其中一臺發出查詢請求,若是該域名不屬於該服務器,該服務器也會知道它是屬於哪臺根服務器的域名並將這臺根服務器的ip返回,而後本地域名服務器再向這臺服務器發起請求,這臺服務器會將ip返回,本地域名服務器再給用戶返回,並保存在緩存中。
         DNS解析是很耗時的,所以若是解析域名過多,首屏加載會變慢。
(2)tcp/ip請求構建:http請求就是tcp/ip請求構建,須要經過3次握手創建鏈接,斷開鏈接時會經歷四次揮手。
    三次握手:
客戶端:hello,你是server麼?(發送標有SYN的數據包) 
    服務端:hello,我是server,你是client麼(發送標爲SYN/ACK的數據包) 
    客戶端:yes,我是client(發送ACK的數據包)
    四次揮手:
    主動方:我已經關閉了向你那邊的主動通道了,只能被動接收了(客戶端發送FIN=1表明主動關閉鏈接,不能發送,可是能夠接受) 
    被動方:收到通道關閉的信息(服務端收到FIN,並向客戶端發送一個確認報文ACK=U+1,客戶端收到這個狀態後會進入等待狀態,等待服務端請求釋放鏈接) 
    被動方:那我也告訴你,我這邊向你的主動通道也關閉了(服務端發送完數據後,就發送FIN報文,請求釋放連接) 
    主動方:最後收到數據,以後雙方沒法通訊(客戶端收到後回覆一個確認信息,ACK=1,並關閉鏈接)    
(3)tcp/ip的併發限制
    瀏覽器對同一域名下併發的tcp鏈接是有限制的(2-10個不等)
(4)get和post的區別
    get請求時,瀏覽器會把header和data一塊兒發送出去,服務器響應200並返回數據
    post請求時,瀏覽器首先發送headers,服務器響應100continue,瀏覽器在發送data,服務器響應200並返回數據
(5)五層網絡協議棧
    五層網絡協議:應用層(DNS,FTP,HTTP):DNS解析成IP併發出http請求;傳輸層(TCP,UDP):創建tcp鏈接;網絡層(IP):IP尋址;數據鏈路層:封裝成幀;物理層(利用物理介質傳輸比特流):物理傳輸,
    總體流程爲:應用層通過dns解析成IP後發送http請求,傳輸層經過tcp/ip鏈接,再通過網絡層的IP尋址(尋找mac地址)再到數據鏈路層封裝成幀,再到物理層經過物理介質傳遞
三.服務器接收到請求到對應後臺接收請求。
     服務端收到請求時會經歷一系列處理:請求到達調度服務器(反向代理服務器,如nginx的均衡負載)調度服務器根據實際的調度算法,分配不一樣的請求到集羣中的服務器執行,調度服務器等待實際服務器的http響應,而且反饋給用戶
    (1)請求到達實際服務器時,會先到達後臺所在的容器(如tomcat)
    (2)而後到達對應的程序,程序會先進行統一的驗證,如安全攔截等,若是不符合就會返回相應的http報文
    (3)若是驗證經過了,會進行計算,數據庫操做等
    (4)程序執行完成以後會返回一個http響應(繼續通過五層網絡協議,不過是方向),而後返回前端,完成交互。
四.後臺和前端的http交互。
    後臺和前端經過http報文進行交互
    1. http報文結構包括:通用頭部,請求/響應頭部,請求/響應體
    (1)通用頭部(General)
             Request  URL:請求的web服務器地址
             Request Method:請求方法
             Status Code:請求狀態(1xx:表示請求以接受,繼續處理;2xx:表示請求成功;3xx:重定向或請求以發出可是內容未修改;4xx:客戶端錯誤,語法錯誤或者請求沒法實現;5xx:服務端錯誤)
             Remote Address:服務器的IP地址
    (2)請求頭(Request Headers)
             Accept:瀏覽器接受的MIME類型,同瀏覽器返回的content-type(通知服務器可以處理的媒體類型及媒體類型的相對優先級,相對優先級經過q=?表示,範圍爲0-1,當服務器提供多種內容時,將會首先返回權重值高的媒體類型,使用type/subtype形式,一次指定多種媒體類型)
             Accept-Charset首部字段用於通知服務器客戶端支持的字符集及字符集的相對優先順序,能夠一次指定多種字符集,一樣用權重q值來表示相對優先級
 
             Accept-Encoding:瀏覽器支持的壓縮類型,如gzip(用於告知服務器客戶端支持的內容編碼及內容編碼的優先級順序,如:gzip,compress,deflate,identity)
             Accept-Language:接受的語言類型(告知服務器客戶端可以處理的天然語言集如:zh-ch,zh;en-us,en)
             Connection:瀏覽器與服務器通訊時對長鏈接的處理,如keep-live
             Content-type:客戶端發送的實體內容類型(  MediaType,便是Internet Media Type,互聯網媒體類型;也叫作MIME類型,在Http協議消息頭中,使用Content-Type來表示具體請求中的媒體類型信息。)
             Content-length:發送給服務端實體正文的長度(以字節爲單位)
             Cookie:有cookie且同域名訪問時會靜止
             Host:請求的服務器URL
             Origin:請求的域名(只會精確到端口 )
             Refer:該頁面的來源(精確到詳細地址)
             User-agent:用戶客戶端的相關信息
    (3)響應頭( Response Headers)
             Content-type:服務端返回的的實體內容類型
             Date:數據從服務端發送的時間
             Cache-Control:告訴瀏覽器什麼狀況能夠緩存 
             Set-Cookie:設置該域名的cookie,服務端經過這個頭部把cookie傳給客戶端
             Keep-Live:若是客戶端有keep-live,服務端也會有迴應(如time-out=38)
             Server:服務器的一些相關信息
    (3)請求/響應體 (Form Data)
             請求實體會將須要的參數放入
             響應實體就是服務端須要傳給客戶端的內容(json或者html)
五.緩存問題:http緩衝(待補充)
             強緩衝
             協商緩衝
六.瀏覽器收到http數據包後的解析流程(詞法 分析生成dom樹,同時css生成規則樹,兩者合併生成render樹,layout佈局肯定dom位置,painting渲染,複合圖層的合成,GPU繪製)
1. 使用GUI渲染線程:GUI渲染線程與JS引擎線程是互斥的,當JS引擎線程執行時,GUI線程會被掛起,GUI線程會被保存在一個隊列裏等到JS引擎空閒時執行
(1)解析html,構建DOM樹;同時解析CSS,生成CSS規則樹。
(2)合併DOM樹和CSS規則樹,生成Render樹。
(3)佈局Render樹(layout/reflow迴流,通常意味着元素的內容、結構、位置或尺寸發生了變化,須要從新計算樣式和渲染樹),負責各元素的尺寸,位置計算。
(4)繪製render樹(paint重繪。意味着元素髮生的改變只是影響了元素的一些外觀之類的時候(例如,背景色,邊框顏色,文字顏色等),此時只須要應用新樣式繪製這個元素就能夠了),繪製頁面像素信息。
(5)瀏覽器會將各層的信息發給GPU。GPU會將各層合成(composite),顯示在屏幕上。
迴流必定伴隨着重繪,重繪卻能夠單獨出現。
2.優化方案:
(1)減小逐項更改樣式,作好一次性更改樣式。或者將樣式定義爲class,並一次性更新。
(2)避免循環操做dom,建立一個documentFragment或div,在他上面進行全部的dom操做,最後添加到window.document中。
(3)避免屢次讀取offset等屬性,沒法避免就將他們緩存到變量中。
(4)將複雜的元素絕對定位或者固定定位,使他們脫離文檔流,不然迴流代價很高。
3.複合圖層的概念(如下幾點轉載:http://web.jobbole.com/83575/)
將該元素變成一個複合圖層,就是傳說中的硬件加速技術
  • 最經常使用的方式:translate3d、translateZ
  • opacity屬性/過渡動畫(須要動畫執行的過程當中纔會建立合成層,動畫沒有開始或結束後元素還會回到以前的狀態)
  • will-chang屬性(這個比較偏僻),通常配合opacity與translate使用(並且經測試,除了上述能夠引起硬件加速的屬性外,其它屬性並不會變成複合層),
做用是提早告訴瀏覽器要變化,這樣瀏覽器會開始作一些優化工做(這個最好用完後就釋放)
  • <video><iframe><canvas><webgl>等元素
  • 其它,譬如之前的flash插件
4. absolute和硬件加速的區別
能夠看到,absolute雖然能夠脫離普通文檔流,可是沒法脫離默認複合層。因此,就算absolute中信息改變時不會改變普通文檔流中render樹,可是,瀏覽器最終繪製時,是整個複合層繪製的,因此absolute中信息的改變,仍然會影響整個複合層的繪製。(瀏覽器會重繪它,若是複合層中內容多,absolute帶來的繪製信息變化過大,資源消耗是很是嚴重的)而硬件加速直接就是在另外一個複合層了(另起爐竈),因此它的信息改變不會影響默認複合層(固然了,內部確定會影響屬於本身的複合層),僅僅是引起最後的合成(輸出視圖)

5. 複合圖層的做用?css

通常一個元素開啓硬件加速後會變成複合圖層,能夠獨立於普通文檔流中,改動後能夠避免整個頁面重繪,提高性能
可是儘可能不要大量使用複合圖層,不然因爲資源消耗過分,頁面反而會變的更卡
硬件加速時請使用index
使用硬件加速時,儘量的使用index,防止瀏覽器默認給後續的元素建立複合層渲染
具體的原理時這樣的:
**webkit CSS3中,若是這個元素添加了硬件加速,而且index層級比較低,
 
那麼在這個元素的後面其它元素(層級比這個元素高的,或者相同的,而且releative或absolute屬性相同的),
會默認變爲複合層渲染,若是處理不當會極大的影響性能**
簡單點理解,其實能夠認爲是一個隱式合成的概念:若是a是一個複合圖層,並且b在a上面,那麼b也會被隱式轉爲一個複合圖層,這點須要特別注意
另外,這個問題能夠在這個地址看到重現(原做者分析的挺到位的,直接上連接):
 七:Js引擎執行過程 另開一篇,傳送門:https://www.cnblogs.com/pianruijie/p/11454598.html
相關文章
相關標籤/搜索