Http

http和https的區別

• http傳輸協議執行在TCP之上。所有傳輸的內容都是明文，客戶端和伺服器端都無法驗證對方的身份。HTTPS是執行在SSL/TLS之上的HTTP協議，SSL/TLS執行在TCP之上。所有傳輸的內容都經過加密，加密採用對稱加密，但對稱加密的金鑰用伺服器方的證書進行了非對稱加密。

• 對稱加密：通訊雙方都使用用一個金鑰進行加密解密，比如特工接頭的暗號，就屬於對稱加密；這種方式雖然簡單效能好，但是無法解決首次把金鑰發給對方的問題，容易被黑客攔截金鑰
• 非對稱加密：由私鑰＋公鑰組成的金鑰對
  • 即用私鑰加密的資料，只要公鑰才能解密；用公鑰加密的資料，只有私鑰才能解密
  • 通訊雙方都有自己的一套金鑰對，通訊前將自己的公鑰發給對方
  • 然後拿著這個公鑰來加密資料響應給對方，等對方收到之後，再用自己的私鑰進行解密

---

http2相比http1的新特性

• 多路複用。
  • http2子啊一個連線裡面，客戶端可以同時傳送多個請求或回應，較少了tcp連線的數量和tcp連線慢啟動的問題。同時http2可以對請求制定優先順序，優先順序高的響應越快，可以把js和css的優先順序設定高一點，讓他們有限下載並執行。同時，優先順序也能夠動態的修改。

• 壓縮請求頭

• TTP是無狀態的，每次請求都需要附帶一些資訊。但是許多欄位都是重複的，會浪費頻寬影響速度。 HTTP/2對頭部資訊採用HPACK壓縮演算法來減少報文頭的大小。具體做法是把報文頭資訊中常見的名和值對應一個索引，維護了一張靜態字典，index從1到61，比如把：method:GET對映成2，這樣就能達到壓縮頭部的作用。但是對於一些動態的資源，比如，user-agent，需要維護一份可動態新增內容的共同動態字典，這份動態字典在資料傳輸的過程中逐步建立，index從62開始。然後將對映之後的資料用huffman編碼。

• 伺服器推送

• 遊覽器向伺服器請求一個頁面，http1需要等到遊覽器收到並解析html後，如果發現裡面有靜態資源，遊覽器才會再向傳送靜態資源的請求。但是現在http2允許伺服器可以直接將頁面和所需的靜態資源一併返回。

• 新的二進位制格式（Binary Format），

  • HTTP1.x的解析是基於文字。基於文字協議的格式解析存在天然缺陷，文字的表現形式有多樣性，要做到健壯性考慮的場景必然很多，二進位制則不同，只認0和1的組合。基於這種考慮HTTP2.0的協議解析決定採用二進位制格式，實現方便且健壯。

---

解析html頁面的過程

簡單過程：

• HTML解析構建DOM
• CSS解析構建CSSOM樹
• 根據DOM樹和CSSOM樹構建render樹
• 根據render樹進行佈局渲染render layer
• 根據計算的佈局資訊進行繪製詳細過程

詳細過程：

• HTML解析構建DOM樹：其中HTML Parser就起到了將HTML標記解析成DOM Tree的作用，HTML Parser將文字的HTML文件，提煉出關鍵資訊，巢狀層級的樹形結構，便於計算擴充；這其中也有很多的規則和操作，比如容錯機制，識別特殊標籤<br></br>等

• CSS解析構建CSSOM樹：CSS Parser將很多個CSS檔案中的樣式合併解析出具有樹形結構Style Rules，也叫做CSSOM。

※其中還有一個細節是瀏覽器解析文件：當遇到<script>標籤的時候會停止解析文件，立即解析指令碼，將指令碼中改變DOM和CSS的地方分別解析出來，追加到DOM Tree和CSSOM上]

• 根據DOM樹和CSSOM樹構建Render樹：Render Tree的構建其實就是DOM Tree和CSSOM Attach的過程，在webkit中，解析樣式和建立呈現器的過程稱為"附加"，每個DOM節點都有一個"attach"方法，Render Tree其實就相當於一個計算好樣式，與HTML對應的Tree

• 根據Render樹進行佈局渲染render layer：建立渲染樹後，Layout根據根據渲染樹中渲染物件的資訊，計算好每一個渲染物件的位置和尺寸，將其放在瀏覽器視窗的正確位置，某些時候會在文件佈局完成之後進行DOM修改，重新佈局的過程就稱為迴流

※其中計算（樣式計算）一個複雜的過程，因為DOM中的一個元素可以對應樣式表中的多個元素，Firefox採用了規則樹和樣式上下文樹來簡化樣式計算，規則樹包含了所有已知規則的匹配路徑，樣式上下文包含端值，webkit也有樣式物件，但它們不儲存在類似上下文樹這樣的結構中，只是由DOM節點指向此類物件的相關樣式

• 根據計算的佈局資訊進行繪製：繪製階段則會遍歷呈現樹，並呼叫呈現器的paint方法，將呈現器的內容顯示在螢幕上，繪製的順序其實就是元素進入堆疊樣式上下文的順序，例如，塊呈現器的堆疊順序如下：1.背景顏色，2.背景圖片，3.邊框，4.子代，5.輪廓

---

get請求與post請求的區別

• get請求相對post請求更加安全。

  post請求並不是安全的，只是相對安全

• get請求會把資料放在url上，也就是http協議頭。post請求會把資料放在http的包體內。

• get請求會產生一個tcp資料包，瀏覽器會把http header和data一併傳送出去，伺服器響應200(返回資料)。POST產生兩個TCP資料包，瀏覽器先傳送header，伺服器響應100 continue，瀏覽器再傳送data，伺服器響應200 ok(返回資料)。

• get請求長度最多1024kb，post對請求資料沒有限制

  ET方法提交的url引數資料大小沒有限制，在http協議中沒有對url長度進行限制（不僅僅是querystring的長度），這個限制是特定的瀏覽器及伺服器對他的限制

為什麼還要用get請求？ 效率高。對應上面第3點

---

request 的組成

request訊息包括以下格式：請求行（request line）、請求頭部（header）、空行、請求資料

服務端響應response也由四個部分組成，分別是：狀態行、訊息報頭、空行、響應正文

---

TCP和UDP區別有哪些

	TCP	UDP
是否連線	面向連線	面向非連線
傳輸可靠性	可靠	不可靠
應用場景	少量資料	傳輸大量資料
速度	慢	快

• TCP是面向連線的；UDP則是無連線的，即傳送資料之前不需要建立連線
• TCP提供的可靠的服務，即TCP連線傳送的資料，無差錯，不丟失，不重複，且按序到達；而UDP盡最大努力，不保證可靠交付
• TCP面向位元組流，TCP把資料看成一連串無結構的位元組流；UDP是面向報文的
• 每一條TCP連線只能是點到點的；UDP支援一對一，一對多，多對一和多對多的互動通訊
• TCP首部開銷較大，20位元組；UDP只有8位元組
• TCP的邏輯通訊通道是全雙工的可靠通道；而UDP則是不可靠通道

---

前端效能優化的方案有哪些

前端效能優化七大常用的優化手段：減少請求數量，減小資源大小，優化網路連線，優化資源載入，減少迴流重繪，使用更好效能的API和構建優化

• 減少請求數量

  • 檔案合併，並按需分配（公共庫合併，其他頁面元件按需分配）
  • 圖片處理：使用雪碧圖，將圖片轉碼base64內嵌到HTML中，使用字型圖片代替圖片
  • 減少重定向：儘量避免使用重定向，當頁面發生了重定向，就會延遲整個HTML文件的傳輸
  • 使用快取：即利用瀏覽器的強快取和協商快取
  • 不使用CSS @import：CSS的@import會造成額外的請求
  • 避免使用空的src和href：a標籤設定空的href，會重定向到當前的頁面地址，form設定空的method，會提交表單到當前的頁面地址

• 減小資源大小

  • 壓縮：靜態資源刪除無效冗餘程式碼並壓縮
  • webp：更小體積
  • 開啟gzip：HTTP協議上的GZIP編碼是一種用來改進WEB應用程式效能的技術

• 優化網路連線

  • 使用CDN
  • 使用DNS預解析：DNS Prefetch，即DNS預解析就是根據瀏覽器定義的規則，提前解析之後可能會用到的域名，使解析結果快取到系統快取中，縮短DNS解析時間，來提高網站的訪問速度

  // 方法是在 head 標籤裡面寫上幾個 link 標籤
  <link rel="dns-prefecth" href="https://www.google.com">
  <link rel="dns-prefecth" href="https://www.google-analytics.com">
  

  • 並行連線：由於在HTTP1.1協議下，chrome每個域名最大併發數是6個。使用多個域名，可以增加併發數
  • 管道化連線：在HTTP2協議中，可以開啟管道化連線，即單條連線的多路複用

• 優化資源載入

• 減少重繪迴流

• 使用效能更好的API

• 構建優化：如webpack優化