大腦中一直存在誤區:一個Web前端工做者只要完美實現產品所提需求,至於瀏覽器到底是怎麼工做或者其中間都經歷了些什麼事情,就不用刨根問底了。直到最近看見前端大神winter老師關於瀏覽器部分的系列文章後,方纔意識到瀏覽器的這些知識,還得好好研究一番。html
對於瀏覽器實現者來講,他們所作的事情就是把一個URL連接變成用戶眼睛所能看見的網頁。前端
主要過程描述:
1.瀏覽器首先使用HTTP或者HTTPS協議,向服務器端請求頁面;
2.把請求回來的HTML解析,構建爲DOM樹;
3.計算DOM樹上的CSS屬性,對元素逐個進行渲染,獲得內存中的位圖;
4.合成位圖,繪製到頁面上。瀏覽器
請求報文的格式: 起始行: <method> <request-URL> <version> 頭部: <headers> 主體: <entity-body>
響應報文的格式: 起始行: <version> <status> <reason-phrase> 頭部: <headers> 主體: <entity-body>
主要的http報文頭部字段以及其含義:
服務器
1XX:Informational(信息性狀態碼) 接收的信息正在處理 2XX:Success(成功狀態碼) 請求正常處理完畢 3XX:Redirection(重定向狀態碼) 須要進行附加操做已完成請求 4XX:Client Error(客戶端錯誤狀態碼) 服務器沒法處理請求 5XX:Server Error(服務器錯誤狀態碼) 服務器處理請求出錯
①TCP:Transmission Control Protocol.傳輸控制協議網絡
TCP共有6個標誌位,分別是:SYN(synchronous),創建聯機;ACK(acknowledgement),確認;PSH(push),傳輸;FIN(finish),結束;RST(reset),重置;URG(urgent),緊急。tcp
Client端發送鏈接請求報文,Server段接受鏈接後回覆ACK報文,併爲此次鏈接分配資源。Client端接收到ACK報文後也向Server段發生ACK報文,並分配資源,這樣TCP鏈接就創建了。
②TCP在傳輸以前會進行三次溝通,通常稱爲「三次握手」;傳輸數據斷開的時候須要進行四次溝通,通常稱爲「四次揮手」。函數
斷開鏈接端能夠是Client端,也能夠是Server端post
假設Client端發起中斷鏈接請求,就先發送FIN報文。Server端接到FIN報文後,可是若是還有數據沒有發送完成,則沒必要急着關閉Socket,能夠繼續發送數據。因此服務器端先發送ACK,告訴Client端:請求已經收到了,可是我還沒準備好,請繼續等待中止的消息。這個時候Client端就進入FIN_WAIT狀態,繼續等待Server端的FIN報文。當Server端肯定數據已發送完成,則向Client端發送FIN報文,告訴Client端:服務器這邊數據發完了,準備好關閉鏈接了。Client端收到FIN報文後,就知道能夠關閉鏈接了,可是他仍是不相信網絡,因此發送ACK後進入TIME_WAIT狀態, Server端收到ACK後,就知道能夠斷開鏈接了。Client端等待了2MSL後依然沒有收到回覆,則證實Server端已正常關閉,最後,Client端也能夠關閉鏈接了至此,TCP鏈接就已經徹底關閉了!.net
參考文章:這裏代理
HTTP協議中的兩種發送請求的方法;這裏更詳細
瀏覽器事件通常經歷的過程:事件捕獲、處於目標階段、事件冒泡階段。
考慮瀏覽器的兼容性
addEventListener可接受3個參數:要處理的事件名、做爲事件處理程序的函數和一個布爾值。布爾值若爲true,表示在捕獲階段調用事件處理程序;若爲false,表示在冒泡階段調用事件處理程序。
……(再補)
乾癟的海綿葉葉,迅速膨大吧!