前言

掌握網路協議可以讓我們在日常專案開發程序中，定位那些在發起網路請求遇到的奇怪問題，

而且在一些比較成熟的團隊面試程序中也經常會問到網路協議這方面的知識，

因此作為一名前端，我們需要掌握網路協議這方面的相關知識，

一、HTTP協議?

1. HTTP 的特點和缺點

特點：無連接、無狀態、靈活、簡單快速

• 無連接：每一次請求都要連接一次，請求結束就會斷掉，不會保持連接
• 無狀態：每一次請求都是獨立的，請求結束不會記錄連接的任何資訊(提起褲子就不認人的意思)，減少了網路開銷，這是優點也是缺點
• 靈活：通過http協議中頭部的Content-Type標記，可以傳輸任意資料型別的資料物件(文本、圖片、視頻等等)，非常靈活
• 簡單快速：發送請求訪問某個資源時，只需傳送請求方法和URL就可以了，使用簡單，正由于http協議簡單，使得http服務器的程式規模小，因而通信速度很快

缺點：無狀態、不安全、明文傳輸、隊頭阻塞

• 無狀態：請求不會記錄任何連接資訊，沒有記憶，就無法區分多個請求發起者身份是不是同一個客戶端的，意味著如果后續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連接傳送的資料量增大
• 不安全：明文傳輸可能被竊聽不安全，缺少身份認證也可能遭遇偽裝，還有缺少報文完整性驗證可能遭到篡改
• 明文傳輸：報文(header部分)使用的是明文，直接將資訊暴露給了外界，WIFI陷阱就是復用明文傳輸的特點，誘導你連上熱點，然后瘋狂抓取你的流量，從而拿到你的敏感資訊
• 隊頭阻塞：開啟長連接(下面有講)時，只建立一個TCP連接，同一時刻只能處理一個請求，那么當請求耗時過長時，其他請求就只能阻塞狀態(如何解決下面有講)

2. HTTP 報文結構是怎樣的

http報文：由請求報文和回應報文組成

請求報文：由請求行、請求頭、空行、請求體四部分組成

回應報文：由狀態行、回應頭、空行、回應體四部分組成

• 請求行：包含http方法，請求地址，http協議以及版本
• 請求頭/回應頭：就是一些key:value來告訴服務端我要哪些內容，要注意什么型別等
• 空行：用來區分首部與物體，因為請求頭都是key:value的格式，當決議遇到空行時，服務端就知道下一個不再是請求頭部分，就該當作請求體來決議了
• 請求體：請求的引數
• 狀態行：包含http協議及版本、數字狀態碼、狀態碼英文名稱
• 回應體：服務端回傳的資料

請求行：

狀態行：

3. 常見的HTTP請求頭和回應頭

HTTP Request Header 常見的請求頭

• Accept: 瀏覽器能夠處理的內容型別
• Accept-Charset:瀏覽器能夠顯示的字符集
• Accept-Encoding：瀏覽器能夠處理的壓縮編碼
• Accept-Language：瀏覽器當前設定的語言
• Connection：瀏覽器與服務器之間連接的型別
• Cookie：當前頁面設定的任何Cookie
• Host：發出請求的頁面所在的域
• Referer：發出請求的頁面的URL
• User-Agent：瀏覽器的用戶代理字串

HTTP Responses Header 常見的回應頭

• Date：表示訊息發送的時間，時間的描述格式由rfc822定義
• server: 服務器名稱
• Connection：瀏覽器與服務器之間連接的型別
• Cache-Control：控制HTTP快取
• content-type: 表示后面的檔案屬于什么MIME型別
• Pragma：只有一個屬性值，就是 no-cache ，效果和 Cache-Control 中的 no-cache 一致，不使用強快取

4. HTTP 有哪些請求方法

http/1.1規定了以下請求方法(注意，都是大寫):

• GET: 通常用來獲取資源
• HEAD: 獲取資源的元資訊
• POST: 提交資料，即上傳資料
• PUT: 修改資料
• DELETE: 洗掉資源(幾乎用不到)
• CONNECT: 建立連接隧道，用于代理服務器
• OPTIONS: 列出可對資源實行的請求方法，用來跨域請求
• TRACE: 追蹤請求-回應的傳輸路徑

5. GET和POST請求的區別

• 從快取的角度，GET 請求會被瀏覽器主動快取下來，留下歷史記錄，而 POST 默認不會，
• 從編碼的角度，GET 只能進行 URL 編碼，只能接收 ASCII 字符，而 POST 沒有限制，
• 從引數的角度，GET 一般放在 URL 中，因此不安全，POST 放在Request body請求體中，更適合傳輸敏感資訊，
• 從冪等性的角度，GET是冪等的，而POST不是，(在編程中一個冪等操作的特點是其任意多次執行一個方法所產生的影響均與一次執行的影響相同)
• 從TCP的角度，GET 請求會產生一個TCP資料包，把請求報文一次性發出去，而 POST 會分為兩個 TCP 資料包，GET瀏覽器把http header和data一起發出去，回應成功200，POST先發送header，回應100 continue，再發送data，回應成功200，(并不是所有的瀏覽器都會發送兩次資料包，Firefox就發送一次，它的 POST 請求只發一個 TCP 包)

6. PUT和POST請求的區別

PUT 和 POST 都有更改指定URI的語意，但PUT被定義為冪等的方法，而POST則不是，多次呼叫會產生不同的結果，也就是說：

PUT請求：如果兩個請求相同，后一個請求會把第一個請求覆寫掉，（所以PUT用來改資源）

POST請求：后一個請求不會把第一個請求覆寫掉，（所以Post用來增資源）

7. OPTIONS請求方法的使用場景

OPTIONS請求方法的主要用途有兩個：

• 獲取服務器支持的所有HTTP請求方法；
• 用來檢查訪問權限，例如：在進行 CORS 跨域資源共享時，對于復雜請求，就是使用 OPTIONS 方法發送嗅探請求，以判斷是否有對指定資源的訪問權限，

8. 常見 HTTP 狀態碼

1xx: 指示資訊——表示請求已接收，繼續處理

2xx: 成功——表示請求成功處理完畢

3xx: 重定向——表示要完成請求必須進行進一步操作

4xx: 客戶端錯誤——表示請求有語法錯誤或請求無法實作

5xx: 服務端錯誤——表示服務器未能實作合法的請求

常見狀態碼：

9. 詳細描述一下 301 和 302 狀態碼

301 Moved Permanently 永久重定向：

301重定向是網頁更改地址后對搜索引擎友好的最好方法，只要不是暫時搬移的情況,都建議使用301來做轉址，

302 Found 臨時重定向：

302狀態碼應用的典型場景是服務器頁面路徑的重新規劃，

常見場景有百度，知乎、簡書等等，比如說我們要在百度進入菜鳥教程，搜索出來后有一系列的串列，我們可以選擇一個去進行一個點擊，點擊的那個不會直接進入菜鳥教程，而是先跳轉到百度設定的一個臨時地址，之后再跳轉到菜鳥教程真實的地址，

10. 304 狀態碼是什么意思？詳細描述一下 HTTP 強快取和協商快取

該知識點重要且篇幅較長，已開新的文章：304 狀態碼是什么意思？圖解 HTTP 強快取和協商快取

11. 從URL輸入到頁面展現到底發生什么

該知識點重要且篇幅較長，已開新的文章：從URL輸入到頁面展現到底發生什么？爆肝研讀數十篇文章詳解 TCP 三次握手 和 四次揮手！！！

12. 為什么需要 持久連接

**HTTP協議的初始版本中，每進行一次HTTP通信就要斷開一次TCP連接，**以當年的通信情況來說，因為都是些容量很小的文本傳輸，所以即使這樣也沒有多大問題，可隨著 HTTP 的 普及，檔案中包含大量圖片的情況多了起來，比如，使用瀏覽器瀏覽一個包含多張圖片的 HTML 頁面時，在發送請求訪問 HTML 頁面資源的同時，也會請 求該 HTML 頁面里包含的其他資源，因此，每次的請求都會造成無謂的 TCP 連接建立和斷開，增加通信量的 開銷，

13. 持久連接 的特點

為解決上述 TCP 連接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久連接（HTTP Persistent Connections，也稱為 HTTP keep-alive 或 HTTP connection reuse）的方法，持久連接的特點是，只要任意一端沒有明確提出斷開連接，則保持TCP連接狀態，

持久連接的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載，另外， 減少開銷的那部分時間，使 HTTP 請求和回應能夠更早地結束，這樣 Web 頁面的顯示速度也就相應提高了， 在 HTTP/1.1 中，所有的連接默認都是持久連接，但在 HTTP/1.0 內并未標準化，雖然有一部分服務器通過非 標準的手段實作了持久連接，但服務器端不一定能夠支持持久連接，毫無疑問，除了服務器端，客戶端也需 要支持持久連接，

14. HTTP管線化

持久連接使得多數請求以管線化（pipelining）方式發送成為可能，

HTTP管線化是將多個HTTP要求（request）整批提交的技術，而在傳送程序中不需先等待服務端的回應，管線化機制須通過永久連接（persistent connection）完成，僅HTTP/1.1支持此技術（HTTP/1.0不支持），并且只有GET和HEAD要求可以進行管線化，而POST則有所限制，此外，初次創建連接時也不應啟動管線機制，因為對方（服務器）不一定支持HTTP/1.1版本的協議，

15. 對keep-alive的理解

HTTP1.0 中默認是在每次請求/應答，客戶端和服務器都要新建一個連接，完成之后立即斷開連接，這就是短連接，當使用Keep-Alive模式時，Keep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的后繼請求時，Keep-Alive功能避免了建立或者重新建立連接，這就是長連接，其使用方法如下：

• HTTP1.0版本是默認沒有Keep-alive的（也就是默認會發送keep-alive），所以要想連接得到保持，必須手動配置發送Connection: keep-alive欄位，若想斷開keep-alive連接，需發送Connection:close欄位；
• HTTP1.1規定了默認保持長連接，資料傳輸完成了保持TCP連接不斷開，等待在同域名下繼續用這個通道傳輸資料，如果需要關閉，需要客戶端發送Connection：close首部欄位，

開啟Keep-Alive的優點：

• 較少的CPU和記憶體的使?（由于同時打開的連接的減少了）；
• 允許請求和應答的HTTP管線化；
• 降低擁塞控制 （TCP連接減少了）；
• 減少了后續請求的延遲（?需再進?握?）；
• 報告錯誤?需關閉TCP連；

開啟Keep-Alive的缺點：

• 長時間的Tcp連接容易導致系統資源無效占用，浪費系統資源，

16. HTTP版本

HTTP/1.0

最早的http只是使用在一些較為簡單的網頁上和網路請求上，所以比較簡單，每次請求都打開一個新的TCP鏈接，收到回應之后立即斷開連接，

HTTP/1.1

• HTTP/1.1 引入了更多的快取控制策略，如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等
• HTTP/1.1 允許范圍請求，即在請求頭中加入Range頭部
• HTTP/1.1 的請求訊息和回應訊息都必須包含Host頭部，以區分同一個物理主機中的不同虛擬主機的域名
• HTTP/1.1 默認開啟持久連接，在一個TCP連接上可以傳送多個HTTP請求和回應，減少了建立和關閉連接的消耗和延遲，

HTTP/2.0

在 HTTP/2 中，有兩個非常重要的概念，分別是幀（frame）和流（stream），理解這兩個概念是理解下面多路復用的前提，幀代表資料傳輸的最小的單位，每個幀都有序列標識表明該幀屬于哪個流，流也就是多個幀組成的資料流，每個流表示一個請求，這里有個chrome擴展程式，可以方便的查看當前網站的HTTP請求版本（安裝后在chrome開發工具-Network-在Name/Size/Time表格頭右鍵選擇Procotol，即可查看協議版本），

• 新的二進制格式： HTTP/1.x的決議是基于文本的，基于文本協議的決議存在天然缺陷，文本的表現形式有多樣性，要做到全面性考慮的場景必然很多，二進制則不同，只識別0和1的組合，基于這種考慮HTTP/2.0的協議決議采用二進制格式，方便且強大，
• 多路復用： HTTP/2.0支持多路復用，這是HTTP/1.1持久連接的升級版，多路復用，就是在一個 TCP 連接中可以存在多條流，也就是可以發送多個請求，服務端則可以通過幀中的標識知道該幀屬于哪個流（即請求），通過重新排序還原請求，多路復用允許并發的發起多個請求，每個請求及該請求的回應不需要等待其他的請求或回應，避免了線頭阻塞問題，這樣某個請求任務耗時嚴重，不會影響到其它連接的正常執行,極大的提高傳輸性能，
• 頭部壓縮： HTTP/1.x的請求和回應頭部帶有大量資訊，而且每次請求都要重復發送，HTTP/2.0使用encoder來減少需要傳輸的頭部大小，通訊雙方各自cache一份頭部 fields表，既避免了重復頭部的傳輸，又減小了需要傳輸的大小，
• 服務端推送： 這里的服務端推送指把客戶端所需要的css/js/img資源伴隨著index.html一起發送到客戶端，省去了客戶端重復請求的步驟（從快取中取），

HTTP/3.0

HTTP/2.0 使用了多路復用，一般來說同一域名下只需要使用一個 TCP 連接，但當這個連接中出現了丟包的情況，那就會導致整個 TCP 都要開始等待重傳，也就導致了后面的所有資料都被阻塞了，反而對于 HTTP/1.0 來說，可以開啟多個 TCP 連接，出現丟包反倒只會影響其中一個連接，剩余的 TCP 連接還可以正常傳輸資料，出現包阻塞的原因是因為底層TCP協議導致的問題，但是修改TCP協議是不現實的問題，就像typeof null === 'object’一樣，修改這個問題會導致出現更多的問題，既然不能修改你，那就另起一個協議取代你，Google 基于 UDP 協議推出了一個的 QUIC 協議，并且使用在了 HTTP/3 上，

QUIC 基于 UDP，但是UDP本身存在不穩定性等諸多問題，所以QUIC在UDP的基礎上新增了很多功能，比如多路復用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重傳等等功能，優點諸多，參考這里：

• 避免包阻塞： 多個流的資料包在TCP連接上傳輸時，若一個流中的資料包傳輸出現問題，TCP需要等待該包重傳后，才能繼續傳輸其它流的資料包，但在基于UDP的QUIC協議中，不同的流之間的資料傳輸真正實作了相互獨立互不干擾，某個流的資料包在出問題需要重傳時，并不會對其他流的資料包傳輸產生影響，
• 快速重啟會話： 普通基于tcp的連接，是基于兩端的ip和埠和協議來建立的，在網路切換場景，例如手機端切換了無線網，使用4G網路，會改變本身的ip，這就導致tcp連接必須重新創建，而QUIC協議使用特有的UUID來標記每一次連接，在網路環境發生變化的時候，只要UUID不變，就能不需要握手，繼續傳輸資料，

17. HTTP 1.0 和 HTTP 1.1 之間有哪些區別？

• 連接方面，http1.0 默認使用非持久連接，而 http1.1 默認使用持久連接，http1.1 通過使用持久連接來使多個 http 請求復用同一個 TCP 連接，以此來避免使用非持久連接時每次需要建立連接的時延，
• 資源請求方面，在 http1.0 中，存在一些浪費帶寬的現象，例如客戶端只是需要某個物件的一部分，而服務器卻將整個物件送過來了，并且不支持斷點續傳功能，http1.1 則在請求頭引入了 range 頭域，它允許只請求資源的某個部分，即回傳碼是 206（Partial Content），這樣就方便了開發者自由的選擇以便于充分利用帶寬和連接，
• 快取方面，在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 來做為快取判斷的標準，http1.1 則引入了更多的快取控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供選擇的快取頭來控制快取策略，
• http1.1 中新增了 host 欄位，用來指定服務器的域名，http1.0 中認為每臺服務器都系結一個唯一的 IP 地址，因此，請求訊息中的 URL 并沒有傳遞主機名（hostname），但隨著虛擬主機技術的發展，在一臺物理服務器上可以存在多個虛擬主機，并且它們共享一個IP地址，因此有了 host 欄位，這樣就可以將請求發往到同一臺服務器上的不同網站，
• http1.1 相對于 http1.0 還新增了很多請求方法，如 PUT、HEAD、OPTIONS 等，

18. HTTP 1.1 和 HTTP 2.0 之間有哪些區別？

• 二進制協議：HTTP/2 是一個二進制協議，在 HTTP/1.1 版中，報文的頭資訊必須是文本（ASCII 編碼），資料體可以是文本，也可以是二進制，HTTP/2 則是一個徹底的二進制協議，頭資訊和資料體都是二進制，并且統稱為"幀"，可以分為頭資訊幀和資料幀，幀的概念是它實作多路復用的基礎，
• 多路復用： HTTP/2 實作了多路復用，HTTP/2 仍然復用 TCP 連接，但是在一個連接里，客戶端和服務器都可以同時發送多個請求或回應，而且不用按照順序一一發送，這樣就避免了"隊頭堵塞"【1】的問題，
• 資料流： HTTP/2 使用了資料流的概念，因為 HTTP/2 的資料包是不按順序發送的，同一個連接里面連續的資料包，可能屬于不同的請求，因此，必須要對資料包做標記，指出它屬于哪個請求，HTTP/2 將每個請求或回應的所有資料包，稱為一個資料流，每個資料流都有一個獨一無二的編號，資料包發送時，都必須標記資料流 ID ，用來區分它屬于哪個資料流，
• 頭資訊壓縮： HTTP/2 實作了頭資訊壓縮，由于 HTTP 1.1 協議不帶狀態，每次請求都必須附上所有資訊，所以，請求的很多欄位都是重復的，比如 Cookie 和 User Agent ，一模一樣的內容，每次請求都必須附帶，這會浪費很多帶寬，也影響速度，HTTP/2 對這一點做了優化，引入了頭資訊壓碩訓制，一方面，頭資訊使用 gzip 或 compress 壓縮后再發送；另一方面，客戶端和服務器同時維護一張頭資訊表，所有欄位都會存入這個表，生成一個索引號，以后就不發送同樣欄位了，只發送索引號，這樣就能提高速度了，
• 服務器推送： HTTP/2 允許服務器未經請求，主動向客戶端發送資源，這叫做服務器推送，使用服務器推送提前給客戶端推送必要的資源，這樣就可以相對減少一些延遲時間，這里需要注意的是 http2 下服務器主動推送的是靜態資源，和 WebSocket 以及使用 SSE 等方式向客戶端發送即時資料的推送是不同的，

【1】隊頭堵塞：

隊頭阻塞是由 HTTP 基本的“請求 - 應答”模型所導致的，HTTP 規定報文必須是“一發一收”，這就形成了一個先進先出的“串行”佇列，佇列里的請求是沒有優先級的，只有入隊的先后順序，排在最前面的請求會被最優先處理，如果隊首的請求因為處理的太慢耽誤了時間，那么佇列里后面的所有請求也不得不跟著一起等待，結果就是其他的請求承擔了不應有的時間成本，造成了隊頭堵塞的現象，

19. 頁面有多張圖片，HTTP是怎樣的加載表現？

• 在HTTP 1下，瀏覽器對一個域名下最大TCP連接數為6，所以會請求多次，可以用多域名部署解決，這樣可以提高同時請求的數目，加快頁面圖片的獲取速度，
• 在HTTP 2下，可以一瞬間加載出來很多資源，因為，HTTP2支持多路復用，可以在一個TCP連接中發送多個HTTP請求，

20. HTTP協議的性能

HTTP 協議是基于 TCP/IP，并且使用了 請求-應答 的通信模式，所以性能的關鍵就在這兩點里，

長連接

HTTP協議有兩種連接模式，一種是持續連接，一種非持續連接，

（1）非持續連接指的是服務器必須為每一個請求的物件建立和維護一個全新的連接，

（2）持續連接下，TCP 連接默認不關閉，可以被多個請求復用，采用持續連接的好處是可以避免每次建立 TCP 連接三次握手時所花費的時間，

對于不同版本的采用不同的連接方式：

• 在HTTP/1.0 每發起一個請求，都要新建一次 TCP 連接（三次握手），而且是串行請求，做了無畏的 TCP 連接建立和斷開，增加了通信開銷，該版本使用的非持續的連接，但是可以在請求時，加上 Connection: keep-a live 來要求服務器不要關閉 TCP 連接，
• 在HTTP/1.1 提出了 長連接 的通信方式，也叫 持久連接 ，這種方式的好處在于減少了 TCP 連接的重復建立和斷開所造成的額外開銷，減輕了服務器端的負載，該版本及以后版本默認采用的是持續的連接，目前對于同一個域，大多數瀏覽器支持同時建立 6 個持久連接，

管道網路傳輸

HTTP/1.1 采用了長連接的方式，這使得管道（pipeline）網路傳輸成為了可能，

管道（pipeline）網路傳輸是指：可以在同一個 TCP 連接里面，客戶端可以發起多個請求，只要第一個請求發出去了，不必等其回來，就可以發第二個請求出去，可以減少整體的回應時間，但是服務器還是按照順序回應請求，如果前面的回應特別慢，后面就會有許多請求排隊等著，這稱為隊頭堵塞，

隊頭堵塞

HTTP 傳輸的報文必須是一發一收，但是，里面的任務被放在一個任務佇列中串行執行，一旦隊首的請求處理太慢，就會阻塞后面請求的處理，這就是HTTP隊頭阻塞問題，

隊頭阻塞的解決方案

（1）并發連接：對于一個域名允許分配多個長連接，那么相當于增加了任務佇列，不至于一個隊伍的任務阻塞其它所有任務，

（2）域名分片：將域名分出很多二級域名，它們都指向同樣的一臺服務器，能夠并發的長連接數變多，解決了隊頭阻塞的問題，

二、網路模型?

1. OSI七層模型

七層模型傳輸資料程序：

應用層

OSI參考模型中最靠近用戶的一層，是為計算機用戶提供應用介面，也為用戶直接提供各種網路服務，我們常見應用層的網路服務協議有：HTTP，HTTPS，FTP，POP3、SMTP等，

• 客戶端與服務器中經常會有資料的請求，這個時候就是會用到http(hyper text transfer protocol)(超文本傳輸協議)或者https，在后端設計資料介面時，我們常常使用到這個協議，
• FTP是檔案傳輸協議，在開發程序中，個人并沒有涉及到，但是我想，在一些資源網站，比如百度網盤、迅雷應該是基于此協議的，
• SMTP是simple mail transfer protocol（簡單郵件傳輸協議），在一個專案中，在用戶郵箱驗證碼登錄的功能時，使用到了這個協議，

表示層

表示層提供各種用于應用層資料的編碼和轉換功能,確保一個系統的應用層發送的資料能被另一個系統的應用層識別，如果必要，該層可提供一種標準表示形式，用于將計算機內部的多種資料格式轉換成通信中采用的標準表示形式，資料壓縮和加密也是表示層可提供的轉換功能之一，

在專案開發中，為了方便資料傳輸，可以使用base64對資料進行編解碼，如果按功能來劃分，base64應該是作業在表示層，

會話層

會話層就是負責建立、管理和終止表示層物體之間的通信會話，該層的通信由不同設備中的應用程式之間的服務請求和回應組成，

傳輸層

傳輸層建立了主機端到端的鏈接，傳輸層的作用是為上層協議提供端到端的可靠和透明的資料傳輸服務，包括處理差錯控制和流量控制等問題，該層向高層屏蔽了下層資料通信的細節，使高層用戶看到的只是在兩個傳輸物體間的一條主機到主機的、可由用戶控制和設定的、可靠的資料通路，我們通常說的，TCP UDP就是在這一層，埠號既是這里的“端”，

網路層

本層通過IP尋址來建立兩個節點之間的連接，為源端的運輸層送來的分組，選擇合適的路由和交換節點，正確無誤地按照地址傳送給目的端的運輸層，就是通常說的IP層，這一層就是我們經常說的IP協議層，IP協議是Internet的基礎，我們可以這樣理解，網路層規定了資料包的傳輸路線，而傳輸層則規定了資料包的傳輸方式，

資料鏈路層

將位元組合成位元組,再將位元組組合成幀,使用鏈路層地址 (以太網使用MAC地址)來訪問介質,并進行差錯檢測，

網路層與資料鏈路層的對比，通過上面的描述，我們或許可以這樣理解，網路層是規劃了資料包的傳輸路線，而資料鏈路層就是傳輸路線，不過，在資料鏈路層上還增加了差錯控制的功能，

物理層

實際最終信號的傳輸是通過物理層實作的，通過物理介質傳輸位元流，規定了電平、速度和電纜針腳，常用設備有（各種物理設備）集線器、中繼器、調制解調器、網線、雙絞線、同軸電纜，這些都是物理層的傳輸介質，

2. TCP/IP五層協議

TCP/IP五層協議和OSI的七層協議對應關系如下：

在每一層實作的協議也各不同，即每一層的服務也不同，下圖列出了每層主要的傳輸協議：

三、TCP 和 UDP的概念、特點和區別?

該知識點重要且篇幅較長，已開新的文章：詳解 TCP 和 UDP的概念、特點和區別

四、HTTPS協議?

該知識點重要且篇幅較長，已開新的文章：深入理解 HTTPS 作業原理，一文幫你搞懂 HTTPS 加密、解密、驗證及資料傳輸程序！！！

五、WebSocket?

WebSocket 產生的背景

很多網站為了實作推送技術，所用的技術都是輪詢，輪詢是在特定的的時間間隔（如每1秒），由瀏覽器對服務器發出HTTP請求，然后由服務器回傳最新的資料給客戶端的瀏覽器，這種傳統的模式帶來很明顯的缺點，即瀏覽器需要不斷的向服務器發出請求，然而HTTP請求可能包含較長的頭部，其中真正有效的資料可能只是很小的一部分，顯然這樣會浪費很多的帶寬等資源，

而比較新的技術去做輪詢的效果是Comet，這種技術雖然可以雙向通信，但依然需要反復發出請求，而且在Comet中，普遍采用的長鏈接，也會消耗服務器資源，

在這種情況下，HTML5定義了WebSocket協議，能更好的節省服務器資源和帶寬，并且能夠更實時地進行通訊，

WebSocket 的理解

WebSocket是HTML5提供的一種瀏覽器與服務器進行 全雙工通訊 的網路技術，屬于應用層協議，它基于TCP傳輸協議，并復用HTTP的握手通道，瀏覽器和服務器只需要完成一次握手，兩者之間就直接可以創建持久性的連接， 并進行雙向資料傳輸，

WebSocket 的出現就解決了半雙工通信的弊端，它最大的特點是：服務器可以向客戶端主動推動訊息，客戶端也可以主動向服務器推送訊息，

WebSocket原理：客戶端向 WebSocket 服務器通知（notify）一個帶有所有接收者ID（recipients IDs）的事件（event），服務器接收后立即通知所有活躍的（active）客戶端，只有ID在接收者ID序列中的客戶端才會處理這個事件，

WebSocket 特點

• 支持雙向通信，實時性更強
• 可以發送文本，也可以發送二進制資料‘’
• 建立在TCP協議之上，服務端的實作比較容易
• 資料格式比較輕量，性能開銷小，通信高效
• 沒有同源限制，客戶端可以與任意服務器通信
• 協議識別符號是ws（如果加密，則為wss），服務器網址就是 URL
• 與 HTTP 協議有著良好的兼容性，默認埠也是80和443，并且握手階段采用 HTTP 協議，因此握手時不容易屏蔽，能通過各種 HTTP 代理服務器，

Websocket 的使用

Websocket的使用方法如下：

在客戶端中：

// 在index.html中直接寫WebSocket，設定服務端的埠號為 9999
let ws = new WebSocket('ws://localhost:9999');
// 在客戶端與服務端建立連接后觸發
ws.onopen = function() {
    console.log("Connection open."); 
    ws.send('hello');
};
// 在服務端給客戶端發來訊息的時候觸發
ws.onmessage = function(res) {
    console.log(res);       // 列印的是MessageEvent物件
    console.log(res.data);  // 列印的是收到的訊息
};
// 在客戶端與服務端建立關閉后觸發
ws.onclose = function(evt) {
  console.log("Connection closed.");
}; 

參考

• https://juejin.cn/post/6994629873985650696#comment
• https://juejin.cn/post/6844904100035821575
• https://mp.weixin.qq.com/s/PdY5fXKOmTN1idiCYSJisw
• https://www.w3cschool.cn/http/g9prxfmx.html
• https://juejin.cn/post/6844903844216832007
• https://juejin.cn/post/6844903619343581191#heading-9
• https://www.cnblogs.com/dongzhiquan/archive/2011/01/03/1994525.html
• https://mp.weixin.qq.com/s/PdY5fXKOmTN1idiCYSJisw
• https://baike.baidu.com/item/WebSocket/1953845