初衷：
大腦中一直存在誤區：一個Web前端工作者只要完美實現產品所提需求，至於瀏覽器究竟是怎麼工作或者其中間都經歷了些什麼事情，就不用刨根問底了。直到最近看見前端大神winter老師關於瀏覽器部分的系列文章後，方才意識到瀏覽器的這些知識，還得好好研究一番。
刨根問底：
1.瀏覽器如何工作的？
對於瀏覽器實現者來說，他們所做的事情就是把一個URL連結變成使用者眼睛所能看見的網頁。
主要過程描述： 1.瀏覽器首先使用HTTP或者HTTPS協議，向伺服器端請求頁面； 2.把請求回來的HTML解析，構建為DOM樹； 3.計算DOM樹上的CSS屬性，對元素逐個進行渲染，得到記憶體中的點陣圖； 4.合成點陣圖，繪製到頁面上。
2.http報文頭部有哪些欄位? 有什麼意義 ?
2.1 HTTP報文：它是HTTP應用程式之間傳送的資料塊。這些資料塊以一些文字形式的元資訊開頭，這些資訊描述了報文的內容及含義，後面跟著可選的資料部分。這些報文都是在客戶端、伺服器和代理之間流動。
2.2 所有的HTTP報文都可以分為兩類，請求報文和響應報文。它倆結構大致相同，只是起始行的語法不同。
請求報文的格式：
起始行： <method> <request-URL> <version>
頭部： <headers>
主體： <entity-body>
複製程式碼響應報文的格式：
起始行： <version> <status> <reason-phrase>
頭部： <headers>
主體： <entity-body>
複製程式碼主要的http報文頭部欄位以及其含義：
3.HTTP狀態碼
3.1詳細的HTTP狀態碼解釋請看這裡：
3.2最早之前看過有位大神寫過的文章中，描述的簡單易記憶版的：
1XX:Informational(資訊性狀態碼) 接收的資訊正在處理
2XX：Success(成功狀態碼) 請求正常處理完畢
3XX：Redirection(重定向狀態碼) 需要進行附加操作已完成請求
4XX:Client Error(客戶端錯誤狀態碼) 伺服器無法處理請求
5XX:Server Error(伺服器錯誤狀態碼) 伺服器處理請求出錯
複製程式碼4.TCP三次握手、四次的過程
4.1：
①TCP:Transmission Control Protocol.傳輸控制協議
TCP共有6個標誌位，分別是：SYN(synchronous),建立聯機；ACK(acknowledgement),確認；PSH(push),傳輸；FIN(finish),結束；RST(reset),重置；URG(urgent),緊急。
Client端傳送連線請求報文，Server段接受連線後回覆ACK報文，併為這次連線分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP連線就建立了。 ②TCP在傳輸之前會進行三次溝通，一般稱為“三次握手”；傳輸資料斷開的時候需要進行四次溝通，一般稱為“四次揮手”。
斷開連線端可以是Client端，也可以是Server端
假設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連線就已經完全關閉了！
參考文章：這裡
5. get post請求的區別：
HTTP協議中的兩種傳送請求的方法;這裡更詳細
6.瀏覽器事件有哪些過程? 為什麼一般在冒泡階段, 而不是在捕獲階段註冊監聽? addEventListener 引數分別是什麼 ?
瀏覽器事件一般經歷的過程：事件捕獲、處於目標階段、事件冒泡階段。
考慮瀏覽器的相容性
addEventListener可接受3個引數：要處理的事件名、作為事件處理程式的函式和一個布林值。布林值若為true，表示在捕獲階段呼叫事件處理程式；若為false，表示在冒泡階段呼叫事件處理程式。
6.TCP與UDP的區別：
TCP:（Transmission Control Protocol 傳輸控制協議）面向連線的通訊協議（如打電話要先撥號建立連線），通過三次握手建立連線、通訊完成時四次揮手。
優點：TCP在資料傳遞時，有確認、視窗、重傳、擁塞等控制機制，能保證資料正確性，較為可靠。
缺點：相對於UDP，速度慢一點，效率低、要求系統資源較多、易被攻擊。
UDP:（User Datagram Protocal 使用者資料包協議）面向無連線的通訊協議，UDP資料包括目的埠號和源埠號資訊。
優點：速度快、操作簡單、要求的系統資源較少，由於通訊不需要連線，可以實現廣播傳送。
缺點：UDP傳送資料前不與對方建立連線，對接收到的資料也不傳送確認訊號，傳送端不知道資料是否正確接收，也不重複傳送，不可靠。
適用場景： TCP:當對網路通訊質量有要求，比如HTTP、HTTPS、FTP等傳輸檔案的協議，POP、SMTP等郵件傳輸的協議； UDP：對網路通訊質量要求不高時，要求網路通訊速度要快的場景。
……（再補）
結語：
乾癟的海綿葉葉，迅速膨大吧！