前端的最重要的基礎知識點是什麼？

• 原生javaScript，HTML,CSS.
• Dom操作
• EventLoop和渲染機制
• 各類工程化的工具原理以及使用，根據需求定製編寫外掛和包。（webpack的plugin和babel的預設包）
• 資料結構和演算法（特別是IM以及超大型高併發網站應用等，例如B站）
• 最後便是通訊協議

在使用某個技術的時候，一定要去追尋原理和底層的實現，長此以往堅持，只要自身底層的基礎紮實，無論技術怎麼變化，學習起來都不會太累，總的來說就是拒絕5分鐘技術

從輸入一個url地址，到顯示頁面發生了什麼出發：

• 1.瀏覽器向 DNS 伺服器請求解析該 URL 中的域名所對應的 IP 地址;
• 2.建立TCP連線（三次握手）;
• 3.瀏覽器發出讀取檔案(URL 中域名後面部分對應的檔案)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的資料傳送給伺服器;
• 4.伺服器對瀏覽器請求作出響應，並把對應的 html 文字傳送給瀏覽器;
• 5.瀏覽器將該 html 文字並顯示內容;
• 6.釋放 TCP連線（四次揮手）;

目前常見的通訊協議都是建立在TCP連結之上

那麼什麼是TCP呢

TCP是因特網中的傳輸層協議，使用三次握手協議建立連線。當主動方發出SYN連線請求後，等待對方回答

TCP三次握手的過程如下：

• 客戶端傳送SYN報文給伺服器端，進入SYN_SEND狀態。
• 伺服器端收到SYN報文，迴應一個SYN（SEQ=y）ACK（ACK=x+1）報文，進入SYN_RECV狀態。
• 客戶端收到伺服器端的SYN報文，迴應一個ACK（ACK=y+1）報文，進入Established狀態。
• 三次握手完成，TCP客戶端和伺服器端成功地建立連線，可以開始傳輸資料了。

如圖所示：

TCP的四次揮手：

• 建立一個連線需要三次握手，而終止一個連線要經過四次握手，這是由TCP的半關閉（half-close）造成的。具體過程如下圖所示。
• 某個應用程式首先呼叫close，稱該端執行“主動關閉”（active close）。該端的TCP於是傳送一個FIN分節，表示資料傳送完畢。
• 接收到這個FIN的對端執行 “被動關閉”（passive close），這個FIN由TCP確認。

注意：FIN的接收也作為一個檔案結束符（end-of-file）傳遞給接收端應用程式，放在已排隊等候該應用程式接收的任何其他資料之後，因為，FIN的接收意味著接收端應用程式在相應連線上再無額外資料可接收。

• 一段時間後，接收到這個檔案結束符的應用程式將呼叫close關閉它的套接字。這導致它的TCP也傳送一個FIN。
• 接收這個最終FIN的原傳送端TCP（即執行主動關閉的那一端）確認這個FIN。 [3]

既然每個方向都需要一個FIN和一個ACK，因此通常需要4個分節。

特別提示： SYN報文用來通知，FIN報文是用來同步的

以上就是面試官常問的三次握手，四次揮手，但是這不僅僅面試題，上面僅僅答到了一點皮毛，學習這些是為了讓我們後續方便了解他的優缺點。

在TCP連線建立後，我們可以有多種協議的方式通訊交換資料：

最古老的方式一：http 1.0

• 早先1.0的HTTP版本，是一種無狀態、無連線的應用層協議。
• HTTP1.0規定瀏覽器和伺服器保持短暫的連線，瀏覽器的每次請求都需要與伺服器建立一個TCP連線，伺服器處理完成後立即斷開TCP連線（無連線），伺服器不跟蹤每個客戶端也不記錄過去的請求（無狀態）。
• 這種無狀態性可以藉助cookie/session機制來做身份認證和狀態記錄。而下面兩個問題就比較麻煩了。
• 首先，無連線的特性導致最大的效能缺陷就是無法複用連線。每次傳送請求的時候，都需要進行一次TCP的連線，而TCP的連線釋放過程又是比較費事的。這種無連線的特性會使得網路的利用率非常低。
• 其次就是隊頭阻塞（headoflineblocking）。由於HTTP1.0規定下一個請求必須在前一個請求響應到達之前才能傳送。假設前一個請求響應一直不到達，那麼下一個請求就不傳送，同樣的後面的請求也給阻塞了。

Http 1.0的致命缺點,就是無法複用TCP連線和並行傳送請求，這樣每次一個請求都需要三次握手，而且其實建立連線和釋放連線的這個過程是最耗時的，傳輸資料相反卻不那麼耗時。還有本地時間被修改導致響應頭expires的快取機制失效的問題～（後面會詳細講）

• 常見的請求報文～

於是出現了Http 1.1，這也是技術的發展必然結果～

• Http 1.1出現，繼承了Http1.0的優點，也克服了它的缺點，出現了keep-alive這個頭部欄位，它表示會在建立TCP連線後，完成首次的請求，並不會立刻斷開TCP連線，而是保持這個連線狀態～進而可以複用這個通道
• Http 1.1並且支援請求管道化，“並行”傳送請求，但是這個並行，也不是真正意義上的並行，而是可以讓我們把先進先出佇列從客戶端（請求佇列）遷移到服務端（響應佇列）

例如：客戶端同時發了兩個請求分別來獲取html和css，假如說伺服器的css資源先準備就緒，伺服器也會先傳送html再傳送css。

• B站首頁，就有keep-alive，因為他們也有IM的成分在裡面。需要大量複用TCP連線～

• HTTP1.1好像還是無法解決隊頭阻塞的問題

實際上，現階段的瀏覽器廠商採取了另外一種做法，它允許我們開啟多個TCP的會話。也就是說，上圖我們看到的並行，其實是不同的TCP連線上的HTTP請求和響應。這也就是我們所熟悉的瀏覽器對同域下並行載入6~8個資源的限制。而這，才是真正的並行！

Http 1.1的致命缺點：

• 1.明文傳輸
• 2.其實還是沒有解決無狀態連線的
• 3.當有多個請求同時被掛起的時候 就會擁塞請求通道，導致後面請求無法傳送
• 4.臃腫的訊息首部:HTTP/1.1能壓縮請求內容,但是訊息首部不能壓縮;在現今請求中,訊息首部佔請求絕大部分(甚至是全部)也較為常見.

我們也可以用dns-prefetch和 preconnect tcp來優化～

<link rel="preconnect" href="//example.com" crossorigin>
<link rel="dns=prefetch" href="//example.com">

• Tip: webpack可以做任何事情，這些都可以用外掛實現

基於這些缺點，出現了Http 2.0

相較於HTTP1.1，HTTP2.0的主要優點有采用二進位制幀封裝，傳輸變成多路複用，流量控制演算法優化，伺服器端推送，首部壓縮，優先順序等特點。

HTTP1.x的解析是基於文字的，基於文字協議的格式解析存在天然缺陷，文字的表現形式有多樣性，要做到健壯性考慮的場景必然很多。而HTTP/2會將所有傳輸的資訊分割為更小的訊息和幀，然後採用二進位制的格式進行編碼，HTTP1.x的頭部資訊會被封裝到HEADER frame，而相應的RequestBody則封裝到DATAframe裡面。不改動HTTP的語義，使用二進位制編碼，實現方便且健壯。

多路複用

• 所有的請求都是通過一個 TCP 連線併發完成。HTTP/1.x 雖然通過 pipeline 也能併發請求，但是多個請求之間的響應會被阻塞的，所以 pipeline 至今也沒有被普及應用，而 HTTP/2 做到了真正的併發請求。同時，流還支援優先順序和流量控制。當流併發時，就會涉及到流的優先順序和依賴。即：HTTP2.0對於同一域名下所有請求都是基於流的，不管對於同一域名訪問多少檔案，也只建立一路連線。優先順序高的流會被優先傳送。圖片請求的優先順序要低於 CSS 和 SCRIPT，這個設計可以確保重要的東西可以被優先載入完

流量控制

• TCP協議通過sliding window的演算法來做流量控制。傳送方有個sending window，接收方有receive window。http2.0的flow control是類似receive window的做法，資料的接收方通過告知對方自己的flow window大小表明自己還能接收多少資料。只有Data型別的frame才有flow control的功能。對於flow control，如果接收方在flow window為零的情況下依然更多的frame，則會返回block型別的frame，這張場景一般表明http2.0的部署出了問題。

伺服器端推送

• 伺服器端的推送，就是伺服器可以對一個客戶端請求傳送多個響應。除了對最初請求的響應外，伺服器還可以額外向客戶端推送資源，而無需客戶端明確地請求。當瀏覽器請求一個html，伺服器其實大概知道你是接下來要請求資源了，而不需要等待瀏覽器得到html後解析頁面再傳送資源請求。

首部壓縮

• HTTP 2.0 在客戶端和伺服器端使用“首部表”來跟蹤和儲存之前傳送的鍵-值對，對於相同的資料，不再通過每次請求和響應傳送;通訊期間幾乎不會改變的通用鍵-值對(使用者代理、可接受的媒體型別,等等)只 需傳送一次。事實上,如果請求中不包含首部(例如對同一資源的輪詢請求),那麼 首部開銷就是零位元組。此時所有首部都自動使用之前請求傳送的首部。
• 如果首部發生變化了，那麼只需要傳送變化了資料在Headers幀裡面，新增或修改的首部幀會被追加到“首部表”。首部表在 HTTP 2.0 的連線存續期內始終存在,由客戶端和伺服器共同漸進地更新 。
• 本質上，當然是為了減少請求啦，通過多個js或css合併成一個檔案，多張小圖片拼合成Sprite圖，可以讓多個HTTP請求減少為一個，減少額外的協議開銷，而提升效能。當然，一個HTTP的請求的body太大也是不合理的，有個度。檔案的合併也會犧牲模組化和快取粒度，可以把“穩定”的程式碼or 小圖 合併為一個檔案or一張Sprite，讓其充分地快取起來，從而區分開迭代快的檔案。

Demo的效能對比：

Http的那些致命缺陷，並沒有完全解決，於是有了https，也是目前應用最廣的協議之一

HTTP+ 加密 + 認證 + 完整性保護 =HTTPS ?

可以這樣認為～HTTP 加上加密處理和認證以及完整性保護後即是 HTTPS

• 如果在 HTTP 協議通訊過程中使用未經加密的明文，比如在 Web 頁面中輸入信用卡號，如果這條通訊線路遭到竊聽，那麼信用卡號就暴露了。
• 另外，對於 HTTP 來說，伺服器也好，客戶端也好，都是沒有辦法確認通訊方的。

因為很有可能並不是和原本預想的通訊方在實際通訊。並且還需要考慮到接收到的報文在通訊途中已經遭到篡改這一可能性。

• 為了統一解決上述這些問題，需要在 HTTP 上再加入加密處理和認證等機制。我們把新增了加密及認證機制的 HTTP 稱為 HTTPS

不加密的重要內容被wireshark這類工具抓到包，後果很嚴重～

HTTPS 是身披 SSL 外殼的 HTTP

• HTTPS 並非是應用層的一種新協議。只是 HTTP 通訊介面部分用 SSL（SecureSocket Layer）和 TLS（Transport Layer Security）協議代替而已。

通常，HTTP 直接和 TCP 通訊。

• 當使用 SSL 時，則演變成先和 SSL 通訊，再由 SSL和 TCP 通訊了。簡言之，所謂 HTTPS，其實就是身披 SSL 協議這層外殼的HTTP。
• 在採用 SSL 後，HTTP 就擁有了 HTTPS 的加密、證照和完整性保護這些功能。SSL 是獨立於 HTTP 的協議，所以不光是 HTTP 協議，其他執行在應用層的 SMTP和 Telnet 等協議均可配合 SSL 協議使用。可以說 SSL 是當今世界上應用最為廣泛的網路安全術。

相互交換金鑰的公開金鑰加密技術 -----對稱加密

• 在對 SSL 進行講解之前，我們先來了解一下加密方法。SSL 採用一種叫做公開金鑰加密（Public-key cryptography）的加密處理方式。
• 近代的加密方法中加密演算法是公開的，而金鑰卻是保密的。通過這種方式得以保持加密方法的安全性。

加密和解密都會用到金鑰。沒有金鑰就無法對密碼解密，反過來說，任何人只要持有金鑰就能解密了。如果金鑰被攻擊者獲得，那加密也就失去了意義。

• https://blog.csdn.net/ituling...， Https加密篇幅太長，這篇文章寫得很好，大家可以去看看。

HTTPS 採用混合加密機制

• HTTPS 採用共享金鑰加密和公開金鑰加密兩者並用的混合加密機制。
• 但是公開金鑰加密與共享金鑰加密相比，其處理速度要慢。所以應充分利用兩者各自的優勢，將多種方法組合起來用於通訊。在交換金鑰環節使用公開金鑰加密方式，之後的建立通訊交換報文階段則使用共享金鑰加密方式。

HTTPS雖好，非對稱加密雖好，但是不要濫用

HTTPS 也存在一些問題，那就是當使用 SSL 時，它的處理速度會變慢。

SSL 的慢分兩種。一種是指通訊慢。另一種是指由於大量消耗 CPU 及記憶體等資源，導致處理速度變慢。

• 和使用 HTTP 相比，網路負載可能會變慢 2 到 100 倍。除去和 TCP 連線、傳送 HTTP 請求 ? 響應以外，還必須進行 SSL 通訊，因此整體上處理通訊量不可避免會增加。
• 另一點是 SSL 必須進行加密處理。在伺服器和客戶端都需要進行加密和解密的運算處理。因此從結果上講，比起 HTTP 會更多地消耗伺服器和客戶端的硬體資源，導致負載增強。

針對速度變慢這一問題，並沒有根本性的解決方案，我們會使用 SSL 加速器這種（專用伺服器）硬體來改善該問題。該硬體為 SSL 通訊專用硬體，相對軟體來講，能夠提高數倍 SSL 的計算速度。僅在 SSL 處理時發揮 SSL加速器的功效，以分擔負載。

為什麼不一直使用 HTTPS

• 既然 HTTPS 那麼安全可靠，那為何所有的 Web 網站不一直使用 HTTPS？

其中一個原因是，因為與純文字通訊相比，加密通訊會消耗更多的 CPU 及記憶體資源。如果每次通訊都加密，會消耗相當多的資源，平攤到一臺計算機上時，能夠處理的請求數量必定也會隨之減少。

• 因此，如果是非敏感資訊則使用 HTTP 通訊，只有在包含個人資訊等敏感資料時，才利用 HTTPS 加密通訊。

特別是每當那些訪問量較多的 Web 網站在進行加密處理時，它們所承擔著的負載不容小覷。在進行加密處理時，並非對所有內容都進行加密處理，而是僅在那些需要資訊隱藏時才會加密，以節約資源。

• 除此之外，想要節約購買證照的開銷也是原因之一。

要進行 HTTPS 通訊，證照是必不可少的。而使用的證照必須向認證機構（CA）購買。證照價格可能會根據不同的認證機構略有不同。通常，一年的授權需要數萬日元（現在一萬日元大約摺合 600 人民幣）。那些購買證照並不合算的服務以及一些個人網站，可能只會選擇採用HTTP 的通訊方式。

複習完了基本的協議，介紹下報文格式：

• 請求報文格式

• 響應報文格式

所謂響應頭，請求頭，其實都可以自己新增欄位，只要前後端給對應的處理機制即可

Node.js程式碼實現響應頭的設定

  if (config.cache.expires) {
                        res.setHeader("expries", new Date(Date.now() + (config.cache.maxAge * 1000)))
                    }
                    if (config.cache.lastModified) {
                        res.setHeader("last-modified", stat.mtime.toUTCString())
                    }
                    if (config.cache.etag) {
                        res.setHeader('Etag', etagFn(stat))
                    }
}

響應頭的詳解：

本人的開源專案，手寫的Node.js靜態資源伺服器，https://github.com/JinJieTan/...，歡迎 star~

瀏覽器的快取策略：

• 首次請求：

• 非首次請求：

• 使用者行為與快取：

不能快取的請求：

無法被瀏覽器快取的請求如下：

• HTTP資訊頭中包含Cache-Control:no-cache，pragma:no-cache（HTTP1.0），或Cache-Control:max-age=0等告訴瀏覽器不用快取的請求
• 需要根據Cookie，認證資訊等決定輸入內容的動態請求是不能被快取的
• 經過HTTPS安全加密的請求（有人也經過測試發現，ie其實在頭部加入Cache-Control：max-age資訊，firefox在頭部加入Cache-Control:Public之後，能夠對HTTPS的資源進行緩寸）
• 經過HTTPS安全加密的請求（有人也經過測試發現，ie其實在頭部加入Cache-Control：max-age資訊，firefox在頭部加入Cache-Control:Public之後，能夠對HTTPS的資源進行快取，參考《HTTPS的七個誤解》）
• POST請求無法被快取
• HTTP響應頭中不包含Last-Modified/Etag，也不包含Cache-Control/Expires的請求無法被快取

即時通訊協議

從最初的沒有websocket協議開始：

傳統的協議無法服務端主動push資料，於是有了這些騷操作：

• 輪詢，在一個定時器中不停向服務端傳送請求。
• 長輪詢，傳送請求給服務端，直到服務端覺得可以返回資料了再返回響應，否則這個請求一直掛起～
• 以上兩種都有瑕疵，而且比較明顯，這裡不再描述。

為了解決實時通訊，資料同步的問題，出現了webSocket.

• webSockets的目標是在一個單獨的持久連線上提供全雙工、雙向通訊。在Javascript建立了Web Socket之後，會有一個HTTP請求傳送到瀏覽器以發起連線。在取得伺服器響應後，建立的連線會將HTTP升級從HTTP協議交換為WebSocket協議。
• webSocket原理： 在TCP連線第一次握手的時候，升級為ws協議。後面的資料互動都複用這個TCP通道。
• 客戶端程式碼實現：

  const ws = new WebSocket('ws://localhost:8080');
        ws.onopen = function () {
            ws.send('123')
            console.log('open')
        }
        ws.onmessage = function () {
            console.log('onmessage')
        }
        ws.onerror = function () {
            console.log('onerror')
        }
        ws.onclose = function () {
            console.log('onclose')
        }

• 服務端使用 Node.js語言實現

const express = require('express')
const { Server } = require("ws");
const app = express()
const wsServer = new Server({ port: 8080 })
wsServer.on('connection', (ws) => {
    ws.onopen = function () {
        console.log('open')
    }
    ws.onmessage = function (data) {
        console.log(data)
        ws.send('234')
        console.log('onmessage' + data)
    }
    ws.onerror = function () {
        console.log('onerror')
    }
    ws.onclose = function () {
        console.log('onclose')
    }
});

app.listen(8000, (err) => {
    if (!err) { console.log('監聽OK') } else {
        console.log('監聽失敗')
    }
})

webSocket的報文格式有一些不一樣：

![圖片上傳中...]

• 客戶端和服務端進行Websocket訊息傳遞是這樣的:

  • 客戶端：將訊息切割成多個幀，併傳送給服務端。
  • 服務端：接收訊息幀，並將關聯的幀重新組裝成完整的訊息。

即時通訊的心跳檢測：

pingandpong

• 服務端Go實現：

package main

import (
    "net/http"
    "time"

    "github.com/gorilla/websocket"
)

var (
    //完成握手操作
    upgrade = websocket.Upgrader{
       //允許跨域(一般來講,websocket都是獨立部署的)
       CheckOrigin:func(r *http.Request) bool {
            return true
       },
    }
)

func wsHandler(w http.ResponseWriter, r *http.Request) {
   var (
         conn *websocket.Conn
         err error
         data []byte
   )
   //服務端對客戶端的http請求(升級為websocket協議)進行應答，應答之後，協議升級為websocket，http建立連線時的tcp三次握手將保持。
   if conn, err = upgrade.Upgrade(w, r, nil); err != nil {
        return
   }

    //啟動一個協程，每隔5s向客戶端傳送一次心跳訊息
    go func() {
        var (
            err error
        )
        for {
            if err = conn.WriteMessage(websocket.TextMessage, []byte("heartbeat")); err != nil {
                return
            }
            time.Sleep(5 * time.Second)
        }
    }()

   //得到websocket的長連結之後,就可以對客戶端傳遞的資料進行操作了
   for {
         //通過websocket長連結讀到的資料可以是text文字資料，也可以是二進位制Binary
        if _, data, err = conn.ReadMessage(); err != nil {
            goto ERR
     }
     if err = conn.WriteMessage(websocket.TextMessage, data); err != nil {
         goto ERR
     }
   }
ERR:
    //出錯之後，關閉socket連線
    conn.Close()
}

func main() {
    http.HandleFunc("/ws", wsHandler)
    http.ListenAndServe("0.0.0.0:7777", nil)
}

客戶端的心跳檢測(Node.js實現)：

this.heartTimer = setInterval(() => {
      if (this.heartbeatLoss < MAXLOSSTIMES) {
        events.emit('network', 'sendHeart');
        this.heartbeatLoss += 1;
        this.phoneLoss += 1;
      } else {
        events.emit('network', 'offline');
        this.stop();
      }
      if (this.phoneLoss > MAXLOSSTIMES) {
        this.PhoneLive = false;
        events.emit('network', 'phoneDisconnect');
      }
    }, 5000);

自定義即時通訊協議：

從new Socket開始：

• 目前即時通訊大都使用現有大公司成熟的SDK接入，但是逼格高些還是自己重寫比較好。
• 打個小廣告，我們公司就是自己定義的即時通訊協議～招聘一位高階前端，地點深圳-深南大道，做跨平臺IM桌面應用開發的～
• 客戶端程式碼實現（Node.js）:

const {Socket} = require('net') 
const tcp = new Socket()
tcp.setKeepAlive(true);
tcp.setNoDelay(true);
//保持底層tcp連結不斷，長連線
指定對應域名埠號連結
tcp.connect(80,166.166.0.0)
建立連線後
根據後端傳送的資料型別 使用對應不同的解析
readUInt8 readUInt16LE readUInt32LE readIntLE等處理後得到myBuf 
const myBuf = buffer.slice(start);//從對應的指標開始的位置擷取buffer
const header = myBuf.slice(headstart,headend)//擷取對應的頭部buffer
const body = JSON.parse(myBuf.slice(headend-headstart,bodylength).tostring())
//精確擷取資料體的buffer,並且轉化成js物件

即時通訊強烈推薦使用Golang,GRPC,Prob傳輸資料。

上面的一些程式碼，都在我的開源專案中：

• 手寫的靜態資源伺服器,https://github.com/JinJieTan/...
• webpack-electron-react-websocket的Demo, https://github.com/JinJieTan/...

覺得寫得不錯，可以點個贊支援下，文章也借鑑了一下其他大佬的文章，但是地址都貼上來了～ 歡迎gitHub點個star哦～