14道關於計算機網絡的面試題，助你查漏補缺

時間 2020-04-14

原文原文鏈接

最近在整理計算機網絡的時候發現遇到了不少面試中常見的面試題，本部分主要原做者在 Github 等各大論壇收錄的計算機網絡相關知識和一些相關面試題時所作的筆記，分享這份總結給你們，對你們對計算機網絡的能夠來一次全方位的檢漏和排查，感謝原做者 CavsZhouyou 的付出，原文連接放在文章最下方，若是出現錯誤，但願你們共同指出！css

應用層

應用層協議定義了應用進程間的交互和通訊規則，不一樣主機的應用進程間如何相互傳遞報文，好比傳遞的報文的類型、格式、
有哪些字段等等。html

HTTP 協議概況

HTTP 是超文本傳輸協議，它定義了客戶端和服務器之間交換報文的格式和方式，默認使用 80 端口。它使用 TCP 做爲傳
輸層協議，保證了數據傳輸的可靠性。前端

HTTP 是一個無狀態的協議，HTTP 服務器不會保存關於客戶的任何信息。webpack

HTTP 有兩種鏈接模式，一種是持續鏈接，一種非持續鏈接。非持續鏈接指的是服務器必須爲每個請求的對象創建和維護
一個全新的鏈接。持續鏈接下，TCP 鏈接默認不關閉，能夠被多個請求複用。採用持續鏈接的好處是能夠避免每次創建 TCP
鏈接三次握手時所花費的時間。在 HTTP1.0 之前使用的非持續的鏈接，可是能夠在請求時，加上 Connection: keep-a
live 來要求服務器不要關閉 TCP 鏈接。HTTP1.1 之後默認採用的是持續的鏈接。目前對於同一個域，大多數瀏覽器支持
同時創建 6 個持久鏈接。git

HTTP 請求報文

HTTP 報文有兩種，一種是請求報文，一種是響應報文。github

HTTP 請求報文的格式以下：web

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

HTTP 請求報文的第一行叫作請求行，後面的行叫作首部行，首部行後還能夠跟一個實體主體。請求首部以後有一個空行，這
個空行不能省略，它用來劃分首部與實體。面試

請求行包含三個字段：方法字段、URL 字段和 HTTP 版本字段。算法

方法字段能夠取幾種不一樣的值，通常有 GET、POST、HEAD、PUT 和 DELETE。通常 GET 方法只被用於向服務器獲取數據。
POST 方法用於將實體提交到指定的資源，一般會形成服務器資源的修改。HEAD 方法與 GET 方法相似，可是在返回的響應
中，不包含請求對象。PUT 方法用於上傳文件到服務器，DELETE 方法用於刪除服務器上的對象。雖然請求的方法不少，但
更多表達的是一種語義上的區別，並非說 POST 能作的事情，GET 就不能作了，主要看咱們如何選擇。更多的方法能夠參
看文檔。數據庫

HTTP 響應報文

HTTP 報文有兩種，一種是請求報文，一種是響應報文。

HTTP 響應報文的格式以下：

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84

<html>
  <body>Hello World</body>
</html>

HTTP 響應報文的第一行叫作狀態行，後面的行是首部行，最後是實體主體。

狀態行包含了三個字段：協議版本字段、狀態碼和相應的狀態信息。

實體部分是報文的主要部分，它包含了所請求的對象。

常見的狀態有

200-請求成功、202-服務器端已經收到請求消息，可是還沒有進行處理
301-永久移動、302-臨時移動、304-所請求的資源未修改、
400-客戶端請求的語法錯誤、404-請求的資源不存在
500-服務器內部錯誤。

通常 1XX 表明服務器接收到請求、2XX 表明成功、3XX 表明重定向、4XX 表明客戶端錯誤、5XX 表明服務器端錯誤。

更多關於狀態碼的能夠查看：

《HTTP 狀態碼》

首部行

首部能夠分爲四種首部，請求首部、響應首部、通用首部和實體首部。通用首部和實體首部在請求報文和響應報文中均可以設
置，區別在於請求首部和響應首部。

常見的請求首部有 Accept 可接收媒體資源的類型、Accept-Charset 可接收的字符集、Host 請求的主機名。

常見的響應首部有 ETag 資源的匹配信息，Location 客戶端重定向的 URI。

常見的通用首部有 Cache-Control 控制緩存策略、Connection 管理持久鏈接。

常見的實體首部有 Content-Length 實體主體的大小、Expires 實體主體的過時時間、Last-Modified 資源的最後修
改時間。

更多關於首部的資料能夠查看：

《HTTP 首部字段詳細介紹》

《圖解 HTTP》

HTTP/1.1 協議缺點

HTTP/1.1 默認使用了持久鏈接，多個請求能夠複用同一個 TCP 鏈接，可是在同一個 TCP 鏈接裏面，數據請求的通訊次序
是固定的。服務器只有處理完一個請求的響應後，纔會進行下一個請求的處理，若是前面請求的響應特別慢的話，就會形成許
多請求排隊等待的狀況，這種狀況被稱爲「隊頭堵塞」。隊頭阻塞會致使持久鏈接在達到最大數量時，剩餘的資源須要等待其餘
資源請求完成後才能發起請求。

爲了不這個問題，一個是減小請求數，一個是同時打開多個持久鏈接。這就是咱們對網站優化時，使用雪碧圖、合併腳本的
緣由。

HTTP/2 協議

2009 年，谷歌公開了自行研發的 SPDY 協議，主要解決 HTTP/1.1 效率不高的問題。這個協議在 Chrome 瀏覽器上證實
可行之後，就被看成 HTTP/2 的基礎，主要特性都在 HTTP/2 之中獲得繼承。2015 年，HTTP/2 發佈。

HTTP/2 主要有如下新的特性：

二進制協議

HTTP/2 是一個二進制協議。在 HTTP/1.1 版中，報文的頭信息必須是文本（ASCII 編碼），數據體能夠是文本，也能夠是
二進制。HTTP/2 則是一個完全的二進制協議，頭信息和數據體都是二進制，而且統稱爲"幀"，能夠分爲頭信息幀和數據幀。
幀的概念是它實現多路複用的基礎。

多路複用

HTTP/2 實現了多路複用，HTTP/2 仍然複用 TCP 鏈接，可是在一個鏈接裏，客戶端和服務器均可以同時發送多個請求或回
應，並且不用按照順序一一發送，這樣就避免了"隊頭堵塞"的問題。

數據流

HTTP/2 使用了數據流的概念，由於 HTTP/2 的數據包是不按順序發送的，同一個鏈接裏面連續的數據包，可能屬於不一樣的
請求。所以，必需要對數據包作標記，指出它屬於哪一個請求。HTTP/2 將每一個請求或迴應的全部數據包，稱爲一個數據流。每
個數據流都有一個獨一無二的編號。數據包發送的時候，都必須標記數據流 ID ，用來區分它屬於哪一個數據流。

頭信息壓縮

HTTP/2 實現了頭信息壓縮，因爲 HTTP 1.1 協議不帶有狀態，每次請求都必須附上全部信息。因此，請求的不少字段都是
重複的，好比 Cookie 和 User Agent ，如出一轍的內容，每次請求都必須附帶，這會浪費不少帶寬，也影響速度。

HTTP/2 對這一點作了優化，引入了頭信息壓縮機制。一方面，頭信息使用 gzip 或 compress 壓縮後再發送；另外一方面，
客戶端和服務器同時維護一張頭信息表，全部字段都會存入這個表，生成一個索引號，之後就不發送一樣字段了，只發送索引
號，這樣就能提升速度了。

服務器推送

HTTP/2 容許服務器未經請求，主動向客戶端發送資源，這叫作服務器推送。使用服務器推送，提早給客戶端推送必要的資源
，這樣就能夠相對減小一些延遲時間。這裏須要注意的是 http2 下服務器主動推送的是靜態資源，和 WebSocket 以及使用
SSE 等方式向客戶端發送即時數據的推送是不一樣的。

詳細的資料能夠參考：
《HTTP 協議入門》
《HTTP/2 服務器推送（Server Push）教程》

HTTP/2 協議缺點

由於 HTTP/2 使用了多路複用，通常來講同一域名下只須要使用一個 TCP 鏈接。因爲多個數據流使用同一個 TCP 鏈接，遵
守同一個流量狀態控制和擁塞控制。只要一個數據流遭遇到擁塞，剩下的數據流就無法發出去，這樣就致使了後面的全部數據都
會被阻塞。HTTP/2 出現的這個問題是因爲其使用 TCP 協議的問題，與它自己的實現其實並無多大關係。

HTTP/3 協議

因爲 TCP 自己存在的一些限制，Google 就開發了一個基於 UDP 協議的 QUIC 協議，而且使用在了 HTTP/3 上。 QUIC
協議在 UDP 協議上實現了多路複用、有序交付、重傳等等功能

詳細資料能夠參考：
《如何看待 HTTP/3 ？》

HTTPS 協議

HTTP 存在的問題

HTTP 報文使用明文方式發送，可能被第三方竊聽。
HTTP 報文可能被第三方截取後修改通訊內容，接收方沒有辦法發現報文內容的修改。
HTTP 還存在認證的問題，第三方能夠冒充他人蔘與通訊。

HTTPS 簡介

HTTPS 指的是超文本傳輸安全協議，HTTPS 是基於 HTTP 協議的，不過它會使用 TLS/SSL 來對數據加密。使用 TLS/
SSL 協議，全部的信息都是加密的，第三方沒有辦法竊聽。而且它提供了一種校驗機制，信息一旦被篡改，通訊的雙方會立
刻發現。它還配備了身份證書，防止身份被冒充的狀況出現。

TLS 握手過程

第一步，客戶端向服務器發起請求，請求中包含使用的協議版本號、生成的一個隨機數、以及客戶端支持的加密方法。
第二步，服務器端接收到請求後，確認雙方使用的加密方法、並給出服務器的證書、以及一個服務器生成的隨機數。
第三步，客戶端確認服務器證書有效後，生成一個新的隨機數，並使用數字證書中的公鑰，加密這個隨機數，而後發給服
務器。而且還會提供一個前面全部內容的 hash 的值，用來供服務器檢驗。
第四步，服務器使用本身的私鑰，來解密客戶端發送過來的隨機數。並提供前面全部內容的 hash 值來供客戶端檢驗。
第五步，客戶端和服務器端根據約定的加密方法使用前面的三個隨機數，生成對話祕鑰，之後的對話過程都使用這個祕鑰
來加密信息。

實現原理

TLS 的握手過程主要用到了三個方法來保證傳輸的安全。

首先是對稱加密的方法，對稱加密的方法是，雙方使用同一個祕鑰對數據進行加密和解密。可是對稱加密的存在一個問題，就
是如何保證祕鑰傳輸的安全性，由於祕鑰仍是會經過網絡傳輸的，一旦祕鑰被其餘人獲取到，那麼整個加密過程就毫無做用了。
這就要用到非對稱加密的方法。

非對稱加密的方法是，咱們擁有兩個祕鑰，一個是公鑰，一個是私鑰。公鑰是公開的，私鑰是保密的。用私鑰加密的數據，只
有對應的公鑰才能解密，用公鑰加密的數據，只有對應的私鑰才能解密。咱們能夠將公鑰公佈出去，任何想和咱們通訊的客戶，
均可以使用咱們提供的公鑰對數據進行加密，這樣咱們就可使用私鑰進行解密，這樣就能保證數據的安全了。可是非對稱加
密有一個缺點就是加密的過程很慢，所以若是每次通訊都使用非對稱加密的方式的話，反而會形成等待時間過長的問題。

所以咱們可使用對稱加密和非對稱加密結合的方式，由於對稱加密的方式的缺點是沒法保證祕鑰的安全傳輸，所以咱們能夠
非對稱加密的方式來對對稱加密的祕鑰進行傳輸，而後之後的通訊使用對稱加密的方式來加密，這樣就解決了兩個方法各自存
在的問題。

可是如今的方法也不必定是安全的，由於咱們沒有辦法肯定咱們獲得的公鑰就必定是安全的公鑰。可能存在一箇中間人，截取
了對方發給咱們的公鑰，而後將他本身的公鑰發送給咱們，當咱們使用他的公鑰加密後發送的信息，就能夠被他用本身的私鑰
解密。而後他假裝成咱們以一樣的方法向對方發送信息，這樣咱們的信息就被竊取了，然而咱們本身還不知道。

爲了解決這樣的問題，咱們可使用數字證書的方式，首先咱們使用一種 Hash 算法來對咱們的公鑰和其餘信息進行加密生成
一個信息摘要，而後讓有公信力的認證中心（簡稱 CA ）用它的私鑰對消息摘要加密，造成簽名。最後將原始的信息和簽名合
在一塊兒，稱爲數字證書。當接收方收到數字證書的時候，先根據原始信息使用一樣的 Hash 算法生成一個摘要，而後使用公證
處的公鑰來對數字證書中的摘要進行解密，最後將解密的摘要和咱們生成的摘要進行對比，就能發現咱們獲得的信息是否被更改
了。這個方法最要的是認證中心的可靠性，通常瀏覽器裏會內置一些頂層的認證中心的證書，至關於咱們自動信任了他們，只有
這樣咱們才能保證數據的安全。

詳細資料能夠參考：
《一個故事講完 https》
《SSL/TLS 協議運行機制的概述》
《圖解 SSL/TLS 協議》
《RSA 算法原理（一）》
《RSA 算法原理（二）》
《分分鐘讓你理解 HTTPS》

DNS 協議

概況

DNS 協議提供的是一種主機名到 IP 地址的轉換服務，就是咱們常說的域名系統。它是一個由分層的 DNS 服務器組成的分
布式數據庫，是定義了主機如何查詢這個分佈式數據庫的方式的應用層協議。DNS 協議運行在 UDP 協議之上，使用 53 號
端口。

域名的層級結構

域名的層級結構能夠以下

主機名.次級域名.頂級域名.根域名

# 即

host.sld.tld.root

根據域名的層級結構，管理不一樣層級域名的服務器，能夠分爲根域名服務器、頂級域名服務器和權威域名服務器。

查詢過程

DNS 的查詢過程通常爲，咱們首先將 DNS 請求發送到本地 DNS 服務器，由本地 DNS 服務器來代爲請求。

從"根域名服務器"查到"頂級域名服務器"的 NS 記錄和 A 記錄（ IP 地址）。
從"頂級域名服務器"查到"次級域名服務器"的 NS 記錄和 A 記錄（ IP 地址）。
從"次級域名服務器"查出"主機名"的 IP 地址。

好比咱們若是想要查詢 www.baidu.com 的 IP 地址，咱們首先會將請求發送到本地的 DNS 服務器中，本地 DNS 服務
器會判斷是否存在該域名的緩存，若是不存在，則向根域名服務器發送一個請求，根域名服務器返回負責 .com 的頂級域名
服務器的 IP 地址的列表。而後本地 DNS 服務器再向其中一個負責 .com 的頂級域名服務器發送一個請求，負責 .com
的頂級域名服務器返回負責 .baidu 的權威域名服務器的 IP 地址列表。而後本地 DNS 服務器再向其中一個權威域名服
務器發送一個請求，最後權威域名服務器返回一個對應的主機名的 IP 地址列表。

DNS 記錄和報文

DNS 服務器中以資源記錄的形式存儲信息，每個 DNS 響應報文通常包含多條資源記錄。一條資源記錄的具體的格式爲

（Name，Value，Type，TTL）

其中 TTL 是資源記錄的生存時間，它定義了資源記錄可以被其餘的 DNS 服務器緩存多長時間。

經常使用的一共有四種 Type 的值，分別是 A、NS、CNAME 和 MX ，不一樣 Type 的值，對應資源記錄表明的意義不一樣。

若是 Type = A，則 Name 是主機名，Value 是主機名對應的 IP 地址。所以一條記錄爲 A 的資源記錄，提供了標
準的主機名到 IP 地址的映射。
若是 Type = NS，則 Name 是個域名，Value 是負責該域名的 DNS 服務器的主機名。這個記錄主要用於 DNS 鏈式
查詢時，返回下一級須要查詢的 DNS 服務器的信息。
若是 Type = CNAME，則 Name 爲別名，Value 爲該主機的規範主機名。該條記錄用於向查詢的主機返回一個主機名
對應的規範主機名，從而告訴查詢主機去查詢這個主機名的 IP 地址。主機別名主要是爲了經過給一些複雜的主機名提供
一個便於記憶的簡單的別名。
若是 Type = MX，則 Name 爲一個郵件服務器的別名，Value 爲郵件服務器的規範主機名。它的做用和 CNAME 是一
樣的，都是爲了解決規範主機名不利於記憶的缺點。

遞歸查詢和迭代查詢

遞歸查詢指的是查詢請求發出後，域名服務器代爲向下一級域名服務器發出請求，最後向用戶返回查詢的最終結果。使用遞歸
查詢，用戶只須要發出一次查詢請求。

迭代查詢指的是查詢請求後，域名服務器返回單次查詢的結果。下一級的查詢由用戶本身請求。使用迭代查詢，用戶須要發出
屢次的查詢請求。

通常咱們向本地 DNS 服務器發送請求的方式就是遞歸查詢，由於咱們只須要發出一次請求，而後本地 DNS 服務器返回給我
們最終的請求結果。而本地 DNS 服務器向其餘域名服務器請求的過程是迭代查詢的過程，由於每一次域名服務器只返回單次
查詢的結果，下一級的查詢由本地 DNS 服務器本身進行。

DNS 緩存

DNS 緩存的原理很是簡單，在一個請求鏈中，當某個 DNS 服務器接收到一個 DNS 回答後，它可以將回答中的信息緩存在本
地存儲器中。返回的資源記錄中的 TTL 表明了該條記錄的緩存的時間。

DNS 實現負載平衡

DNS 能夠用於在冗餘的服務器上實現負載平衡。由於如今通常的大型網站使用多臺服務器提供服務，所以一個域名可能會對應
多個服務器地址。當用戶發起網站域名的 DNS 請求的時候，DNS 服務器返回這個域名所對應的服務器 IP 地址的集合，但在
每一個回答中，會循環這些 IP 地址的順序，用戶通常會選擇排在前面的地址發送請求。以此將用戶的請求均衡的分配到各個不
同的服務器上，這樣來實現負載均衡。

詳細資料能夠參考：
《DNS 原理入門》
《根域名的知識》

傳輸層

傳輸層協議主要是爲不一樣主機上的不一樣進程間提供了邏輯通訊的功能。傳輸層只工做在端系統中。

多路複用與多路分解

將傳輸層報文段中的數據交付到正確的套接字的工做被稱爲多路分解。

在源主機上從不一樣的套接字中收集數據，封裝頭信息生成報文段後，將報文段傳遞到網絡層，這個過程被稱爲多路複用。

無鏈接的多路複用和多路分解指的是 UDP 套接字的分配過程，一個 UDP 套接字由一個二元組來標識，這個二元組包含了一
個目的地址和一個目的端口號。所以不一樣源地址和端口號的 UDP 報文段到達主機後，若是它們擁有相同的目的地址和目的端
口號，那麼不一樣的報文段將會轉交到同一個 UDP 套接字中。

面向鏈接的多路複用和多路分解指的是 TCP 套接字的分配過程，一個 TCP 套接字由一個四元組來標識，這個四元組包含了
源 IP 地址、源端口號、目的地址和目的端口號。所以，一個 TCP 報文段從網絡中到達一臺主機上時，該主機使用所有 4 個
值來將報文段定向到相應的套接字。

UDP 協議

UDP 是一種無鏈接的，不可靠的傳輸層協議。它只提供了傳輸層須要實現的最低限度的功能，除了複用/分解功能和少許的差
錯檢測外，它幾乎沒有對 IP 增長其餘的東西。UDP 協議適用於對實時性要求高的應用場景。

特色：

使用 UDP 時，在發送報文段以前，通訊雙方沒有握手的過程，所以 UDP 被稱爲是無鏈接的傳輸層協議。由於沒有握手
過程，相對於 TCP 來講，沒有創建鏈接的時延。由於沒有鏈接，因此不須要在端系統中保存鏈接的狀態。
UDP 提供盡力而爲的交付服務，也就是說 UDP 協議不保證數據的可靠交付。
UDP 沒有擁塞控制和流量控制的機制，因此 UDP 報文段的發送速率沒有限制。
由於一個 UDP 套接字只使用目的地址和目的端口來標識，因此 UDP 能夠支持一對1、一對多、多對一和多對多的交互
通訊。
UDP 首部小，只有 8 個字節。

UDP 報文段結構

UDP 報文段由首部和應用數據組成。報文段首部包含四個字段，分別是源端口號、目的端口號、長度和檢驗和，每一個字段的長
度爲兩個字節。長度字段指的是整個報文段的長度，包含了首部和應用數據的大小。校驗和是 UDP 提供的一種差錯校驗機制。
雖然提供了差錯校驗的機制，可是 UDP 對於差錯的恢復無能爲力。

TCP 協議

TCP 協議是面向鏈接的，提供可靠數據傳輸服務的傳輸層協議。

特色：

TCP 協議是面向鏈接的，在通訊雙方進行通訊前，須要經過三次握手創建鏈接。它須要在端系統中維護雙方鏈接的狀態信息。
TCP 協議經過序號、確認號、定時重傳、檢驗和等機制，來提供可靠的數據傳輸服務。
TCP 協議提供的是點對點的服務，即它是在單個發送方和單個接收方之間的鏈接。
TCP 協議提供的是全雙工的服務，也就是說鏈接的雙方的可以向對方發送和接收數據。
TCP 提供了擁塞控制機制，在網絡擁塞的時候會控制發送數據的速率，有助於減小數據包的丟失和減輕網絡中的擁塞程度。
TCP 提供了流量控制機制，保證了通訊雙方的發送和接收速率相同。若是接收方可接收的緩存很小時，發送方會下降發送
速率，避免由於緩存填滿而形成的數據包的丟失。

TCP 報文段結構

TCP 報文段由首部和數據組成，它的首部通常爲 20 個字節。

源端口和目的端口號用於報文段的多路複用和分解。

32 比特的序號和 32 比特的確認號，用與實現可靠數據運輸服務。

16 比特的接收窗口字段用於實現流量控制，該字段表示接收方願意接收的字節的數量。

4 比特的首部長度字段，該字段指示了以 32 比特的字爲單位的 TCP 首部的長度。

6 比特的標誌字段，ACK 字段用於指示確認序號的值是有效的，RST、SYN 和 FIN 比特用於鏈接創建和拆除。設置 PSH 字
段指示接收方應該當即將數據交給上層，URG 字段用來指示報文段裏存在緊急的數據。

校驗和提供了對數據的差錯檢測。

TCP 三次握手的過程

第一次握手，客戶端向服務器發送一個 SYN 鏈接請求報文段，報文段的首部中 SYN 標誌位置爲 1，序號字段是一個任選的
隨機數。它表明的是客戶端數據的初始序號。

第二次握手，服務器端接收到客戶端發送的 SYN 鏈接請求報文段後，服務器首先會爲該鏈接分配 TCP 緩存和變量，而後向
客戶端發送 SYN ACK 報文段，報文段的首部中 SYN 和 ACK 標誌位都被置爲 1，表明這是一個對 SYN 鏈接請求的確認，
同時序號字段是服務器端產生的一個任選的隨機數，它表明的是服務器端數據的初始序號。確認號字段爲客戶端發送的序號加
一。

第三次握手，客戶端接收到服務器的確定應答後，它也會爲此次 TCP 鏈接分配緩存和變量，同時向服務器端發送一個對服務
器端的報文段的確認。第三次握手能夠在報文段中攜帶數據。

在我看來，TCP 三次握手的創建鏈接的過程就是相互確認初始序號的過程，告訴對方，什麼樣序號的報文段可以被正確接收。
第三次握手的做用是客戶端對服務器端的初始序號的確認。若是隻使用兩次握手，那麼服務器就沒有辦法知道本身的序號是否
已被確認。同時這樣也是爲了防止失效的請求報文段被服務器接收，而出現錯誤的狀況。

詳細資料能夠參考：
《TCP 爲何是三次握手，而不是兩次或四次？》
《TCP 的三次握手與四次揮手》

TCP 四次揮手的過程

由於 TCP 鏈接是全雙工的，也就是說通訊的雙方均可以向對方發送和接收消息，因此斷開鏈接須要雙方的確認。

第一次揮手，客戶端認爲沒有數據要再發送給服務器端，它就向服務器發送一個 FIN 報文段，申請斷開客戶端到服務器端的
鏈接。發送後客戶端進入 FIN_WAIT_1 狀態。

第二次揮手，服務器端接收到客戶端釋放鏈接的請求後，向客戶端發送一個確認報文段，表示已經接收到了客戶端釋放鏈接的
請求，之後再也不接收客戶端發送過來的數據。可是由於鏈接是全雙工的，因此此時，服務器端還能夠向客戶端發送數據。服務
器端進入 CLOSE_WAIT 狀態。客戶端收到確認後，進入 FIN_WAIT_2 狀態。

第三次揮手，服務器端發送完全部數據後，向客戶端發送 FIN 報文段，申請斷開服務器端到客戶端的鏈接。發送後進入 LAS
T_ACK 狀態。

第四次揮手，客戶端接收到 FIN 請求後，向服務器端發送一個確認應答，並進入 TIME_WAIT 階段。該階段會持續一段時間，
這個時間爲報文段在網絡中的最大生存時間，若是該時間內服務端沒有重發請求的話，客戶端進入 CLOSED 的狀態。若是收到
服務器的重發請求就從新發送確認報文段。服務器端收到客戶端的確認報文段後就進入 CLOSED 狀態，這樣全雙工的鏈接就被
釋放了。

TCP 使用四次揮手的緣由是由於 TCP 的鏈接是全雙工的，因此須要雙方分別釋放到對方的鏈接，單獨一方的鏈接釋放，只代
表不能再向對方發送數據，鏈接處於的是半釋放的狀態。

最後一次揮手中，客戶端會等待一段時間再關閉的緣由，是爲了防止發送給服務器的確認報文段丟失或者出錯，從而致使服務器
端不能正常關閉。

詳細資料能夠參考：

《前端面試之道》

狀態轉化圖

ARQ 協議

ARQ 協議指的是自動重傳請求，它經過超時和重傳來保證數據的可靠交付，它是 TCP 協議實現可靠數據傳輸的一個很重要的
機制。

它分爲中止等待 ARQ 協議和連續 ARQ 協議。

1、中止等待 ARQ 協議

中止等待 ARQ 協議的基本原理是，對於發送方來講發送方每發送一個分組，就爲這個分組設置一個定時器。當發送分組的確認
回答返回了，則清除定時器，發送下一個分組。若是在規定的時間內沒有收到已發送分組的確定回答，則從新發送上一個分組。

對於接受方來講，每次接受到一個分組，就返回對這個分組的確定應答，當收到冗餘的分組時，就直接丟棄，並返回一個對冗餘
分組的確認。當收到分組損壞的狀況的時候，直接丟棄。

使用中止等待 ARQ 協議的缺點是每次發送分組必須等到分組確認後才能發送下一個分組，這樣會形成信道的利用率太低。

2、連續 ARQ 協議

連續 ARQ 協議是爲了解決中止等待 ARQ 協議對於信道的利用率太低的問題。它經過連續發送一組分組，而後再等待對分組的
確認回答，對於如何處理分組中可能出現的差錯恢復狀況，通常可使用滑動窗口協議和選擇重傳協議來實現。

滑動窗口協議

使用滑動窗口協議，在發送方維持了一個發送窗口，發送窗口之前的分組是已經發送並確認了的分組，發送窗口中包含了已經發
送但未確認的分組和容許發送但還未發送的分組，發送窗口之後的分組是緩存中還不容許發送的分組。當發送方向接收方發送分
組時，會依次發送窗口內的全部分組，而且設置一個定時器，這個定時器能夠理解爲是最先發送但未收到確認的分組。若是在定
時器的時間內收到某一個分組的確認回答，則滑動窗口，將窗口的首部移動到確認分組的後一個位置，此時若是還有已發送但沒
有確認的分組，則從新設置定時器，若是沒有了則關閉定時器。若是定時器超時，則從新發送全部已經發送但還未收到確認的分
組。

接收方使用的是累計確認的機制，對於全部按序到達的分組，接收方返回一個分組的確定回答。若是收到了一個亂序的分組，那
麼接方會直接丟棄，並返回一個最近的按序到達的分組的確定回答。使用累計確認保證了確認號之前的分組都已經按序到達了，
因此發送窗口能夠移動到已確認分組的後面。

滑動窗口協議的缺點是由於使用了累計確認的機制，若是出現了只是窗口中的第一個分組丟失，然後面的分組都按序到達的狀況
的話，那麼滑動窗口協議會從新發送全部的分組，這樣就形成了大量沒必要要分組的丟棄和重傳。

選擇重傳協議

由於滑動窗口使用累計確認的方式，因此會形成不少沒必要要分組的重傳。使用選擇重傳協議能夠解決這個問題。

選擇重傳協議在發送方維護了一個發送窗口。發送窗口的之前是已經發送並確認的分組，窗口內包含了已發送但未被確認的分組，
已確認的亂序分組，和容許發送但還未發送的分組，發送窗口之後的是緩存中還不容許發送的分組。選擇重傳協議與滑動窗口協
議最大的不一樣是，發送方發送分組時，爲一個分組都建立了一個定時器。當發送方接受到一個分組的確認應答後，取消該分組的
定時器，並判斷接受該分組後，是否存在由窗口首部爲首的連續的確認分組，若是有則向後移動窗口的位置，若是沒有則將該分
組標識爲已接收的亂序分組。當某一個分組定時器到時後，則從新傳遞這個分組。

在接收方，它會確認每個正確接收的分組，無論這個分組是按序的仍是亂序的，亂序的分組將被緩存下來，直到全部的亂序分
組都到達造成一個有序序列後，再將這一段分組交付給上層。對於不能被正確接收的分組，接收方直接忽略該分組。

詳細資料能夠參考：
《TCP 連續 ARQ 協議和滑動窗口協議》

TCP 的可靠運輸機制

TCP 的可靠運輸機制是基於連續 ARQ 協議和滑動窗口協議的。

TCP 協議在發送方維持了一個發送窗口，發送窗口之前的報文段是已經發送並確認了的報文段，發送窗口中包含了已經發送但
未確認的報文段和容許發送但還未發送的報文段，發送窗口之後的報文段是緩存中還不容許發送的報文段。當發送方向接收方發
送報文時，會依次發送窗口內的全部報文段，而且設置一個定時器，這個定時器能夠理解爲是最先發送但未收到確認的報文段。
若是在定時器的時間內收到某一個報文段的確認回答，則滑動窗口，將窗口的首部向後滑動到確認報文段的後一個位置，此時如
果還有已發送但沒有確認的報文段，則從新設置定時器，若是沒有了則關閉定時器。若是定時器超時，則從新發送全部已經發送
但還未收到確認的報文段，並將超時的間隔設置爲之前的兩倍。當發送方收到接收方的三個冗餘的確認應答後，這是一種指示，
說明該報文段之後的報文段頗有可能發生丟失了，那麼發送方會啓用快速重傳的機制，就是當前定時器結束前，發送全部的已發
送但確認的報文段。

接收方使用的是累計確認的機制，對於全部按序到達的報文段，接收方返回一個報文段的確定回答。若是收到了一個亂序的報文
段，那麼接方會直接丟棄，並返回一個最近的按序到達的報文段的確定回答。使用累計確認保證了返回的確認號以前的報文段都
已經按序到達了，因此發送窗口能夠移動到已確認報文段的後面。

發送窗口的大小是變化的，它是由接收窗口剩餘大小和網絡中擁塞程度來決定的，TCP 就是經過控制發送窗口的長度來控制報文
段的發送速率。

可是 TCP 協議並不徹底和滑動窗口協議相同，由於許多的 TCP 實現會將失序的報文段給緩存起來，而且發生重傳時，只會重
傳一個報文段，所以 TCP 協議的可靠傳輸機制更像是窗口滑動協議和選擇重傳協議的一個混合體。

TCP 的流量控制機制

TCP 提供了流量控制的服務，這個服務的主要目的是控制發送方的發送速率，保證接收方來得及接收。由於一旦發送的速率大
於接收方所能接收的速率，就會形成報文段的丟失。接收方主要是經過接收窗口來告訴發送方本身所能接收的大小，發送方根據
接收方的接收窗口的大小來調整發送窗口的大小，以此來達到控制發送速率的目的。

TCP 的擁塞控制機制

TCP 的擁塞控制主要是根據網絡中的擁塞狀況來控制發送方數據的發送速率，若是網絡處於擁塞的狀態，發送方就減少發送的
速率，這樣一方面是爲了不繼續增長網絡中的擁塞程度，另外一方面也是爲了不網絡擁塞可能形成的報文段丟失。

TCP 的擁塞控制主要使用了四個機制，分別是慢啓動、擁塞避免、快速重傳和快速恢復。

慢啓動的基本思想是，由於在發送方剛開始發送數據的時候，並不知道網絡中的擁塞程度，因此先以較低的速率發送，進行試探
，每次收到一個確認報文，就將發動窗口的長度加一，這樣每一個 RTT 時間後，發送窗口的長度就會加倍。當發送窗口的大小達
到一個閾值的時候就進入擁塞避免算法。

擁塞避免算法是爲了不可能發生的擁塞，將發送窗口的大小由每過一個 RTT 增加一倍，變爲每過一個 RTT ，長度只加一。
這樣將窗口的增加速率由指數增加，變爲加法線性增加。

快速重傳指的是，當發送方收到三個冗餘的確認應答時，由於 TCP 使用的是累計確認的機制，因此頗有多是發生了報文段的
丟失，所以採用當即重傳的機制，在定時器結束前發送全部已發送但還未接收到確認應答的報文段。

快速恢復是對快速重傳的後續處理，由於網絡中可能已經出現了擁塞狀況，因此會將慢啓動的閥值減少爲原來的一半，而後將擁
塞窗口的值置爲減半後的閥值，而後開始執行擁塞避免算法，使得擁塞窗口緩慢地加性增大。簡單來理解就是，乘性減，加性增。

TCP 認爲網絡擁塞的主要依據是報文段的重傳次數，它會根據網絡中的擁塞程度，經過調整慢啓動的閥值，而後交替使用上面四
種機制來達到擁塞控制的目的。

詳細資料能夠參考：
《TCP 的擁塞控制機制》
《網絡基本功：TCP 擁塞控制機制》

網絡層

網絡層協議主要實現了不一樣主機間的邏輯通訊功能。網絡層協議一共包含兩個主要的組件，一個 IP 網際協議，一個是路由選
擇協議。

IP 網際協議規定了網絡層的編址和轉發方式，好比說咱們接入網絡的主機都會被分配一個 IP 地址，經常使用的好比 IPV4 使用
32 位來分配地址，還有 IPv6 使用 128 位來分配地址。

路由選擇協議決定了數據報從源到目的地所流經的路徑，常見的好比距離向量路由選擇算法等。

數據鏈路層

數據鏈路層提供的服務是如何將數據報經過單一通訊鏈路從一個結點移動到相鄰節點。每一臺主機都有一個惟一的 MAC 地址，
這是由網絡適配器決定的，在全世界都是獨一無二的。

物理層

物理層提供的服務是儘量的屏蔽掉組成網絡的物理設備和傳輸介質間的差別，使數據鏈路層不須要考慮網絡的具體傳輸介質
是什麼。

詳細資料能夠參考：
《搞定計算機網絡面試，看這篇就夠了（補充版）》
《互聯網協議入門（一）》
《互聯網協議入門（二）》

常考面試題

1. Post 和 Get 的區別？

Post 和 Get 是 HTTP 請求的兩種方法。

（1）從應用場景上來講，GET 請求是一個冪等的請求，通常 Get 請求用於對服務器資源不會產生影響的場景，好比說請求一個網
頁。而 Post 不是一個冪等的請求，通常用於對服務器資源會產生影響的情景。好比註冊用戶這一類的操做。

（2）由於不一樣的應用場景，因此瀏覽器通常會對 Get 請求緩存，但不多對 Post 請求緩存。

（3）從發送的報文格式來講，Get 請求的報文中實體部分爲空，Post 請求的報文中實體部分通常爲向服務器發送的數據。

（4）可是 Get 請求也能夠將請求的參數放入 url 中向服務器發送，這樣的作法相對於 Post 請求來講，一個方面是不太安全，
由於請求的 url 會被保留在歷史記錄中。而且瀏覽器因爲對 url 有一個長度上的限制，因此會影響 get 請求發送數據時
的長度。這個限制是瀏覽器規定的，並非 RFC 規定的。還有就是 post 的參數傳遞支持更多的數據類型。

2. TLS/SSL 中什麼必定要用三個隨機數，來生成"會話密鑰"？

客戶端和服務器都須要生成隨機數，以此來保證每次生成的祕鑰都不相同。使用三個隨機數，是由於 SSL 的協議默認不信任每一個主
機都能產生徹底隨機的數，若是隻使用一個僞隨機的數來生成祕鑰，就很容易被破解。經過使用三個隨機數的方式，增長了自由度，
一個僞隨機可能被破解，可是三個僞隨機就很接近於隨機了，所以可使用這種方法來保持生成祕鑰的隨機性和安全性。

3. SSL 鏈接斷開後如何恢復？

一共有兩種方法來恢復斷開的 SSL 鏈接，一種是使用 session ID，一種是 session ticket。

使用 session ID 的方式，每一次的會話都有一個編號，當對話中斷後，下一次從新鏈接時，只要客戶端給出這個編號，服務器
若是有這個編號的記錄，那麼雙方就能夠繼續使用之前的祕鑰，而不用從新生成一把。目前全部的瀏覽器都支持這一種方法。可是
這種方法有一個缺點是，session ID 只可以存在一臺服務器上，若是咱們的請求經過負載平衡被轉移到了其餘的服務器上，那
麼就沒法恢復對話。

另外一種方式是 session ticket 的方式，session ticket 是服務器在上一次對話中發送給客戶的，這個 ticket 是加密的
，只有服務器可以解密，裏面包含了本次會話的信息，好比對話祕鑰和加密方法等。這樣無論咱們的請求是否轉移到其餘的服務器
上，當服務器將 ticket 解密之後，就可以獲取上次對話的信息，就不用從新生成對話祕鑰了。

4. RSA 算法的安全性保障？

對極大整數作因數分解的難度決定了 RSA 算法的可靠性。換言之，對一極大整數作因數分解愈困難，RSA 算法愈可靠。如今102
4位的 RSA 密鑰基本安全，2048位的密鑰極其安全。

5. DNS 爲何使用 UDP 協議做爲傳輸層協議？

DNS 使用 UDP 協議做爲傳輸層協議的主要緣由是爲了不使用 TCP 協議時形成的鏈接時延。由於爲了獲得一個域名的 IP 地
址，每每會向多個域名服務器查詢，若是使用 TCP 協議，那麼每次請求都會存在鏈接時延，這樣使 DNS 服務變得很慢，由於大
多數的地址查詢請求，都是瀏覽器請求頁面時發出的，這樣會形成網頁的等待時間過長。

使用 UDP 協議做爲 DNS 協議會有一個問題，因爲歷史緣由，物理鏈路的最小MTU = 576，因此爲了限制報文長度不超過576，
UDP 的報文段的長度被限制在 512 個字節之內，這樣一旦 DNS 的查詢或者應答報文，超過了 512 字節，那麼基於 UDP 的
DNS 協議就會被截斷爲 512 字節，那麼有可能用戶獲得的 DNS 應答就是不完整的。這裏 DNS 報文的長度一旦超過限制，並不
會像 TCP 協議那樣被拆分紅多個報文段傳輸，由於 UDP 協議不會維護鏈接狀態，因此咱們沒有辦法肯定那幾個報文段屬於同一
個數據，UDP 只會將多餘的數據給截取掉。爲了解決這個問題，咱們可使用 TCP 協議去請求報文。

DNS 還存在的一個問題是安全問題，就是咱們沒有辦法肯定咱們獲得的應答，必定是一個安全的應答，由於應答能夠被他人僞造，
因此如今有了 DNS over HTTPS 來解決這個問題。

詳細資料能夠參考：
《爲何 DNS 使用 UDP 而不是 TCP？》

6. 當你在瀏覽器中輸入 Google.com 而且按下回車以後發生了什麼？

（1）首先會對 URL 進行解析，分析所須要使用的傳輸協議和請求的資源的路徑。若是輸入的 URL 中的協議或者主機名不合法，
將會把地址欄中輸入的內容傳遞給搜索引擎。若是沒有問題，瀏覽器會檢查 URL 中是否出現了非法字符，若是存在非法字
符，則對非法字符進行轉義後再進行下一過程。

（2）瀏覽器會判斷所請求的資源是否在緩存裏，若是請求的資源在緩存裏而且沒有失效，那麼就直接使用，不然向服務器發起新
的請求。

（3）下一步咱們首先須要獲取的是輸入的 URL 中的域名的 IP 地址，首先會判斷本地是否有該域名的 IP 地址的緩存，若是
有則使用，若是沒有則向本地 DNS 服務器發起請求。本地 DNS 服務器也會先檢查是否存在緩存，若是沒有就會先向根域
名服務器發起請求，得到負責的頂級域名服務器的地址後，再向頂級域名服務器請求，而後得到負責的權威域名服務器的地
址後，再向權威域名服務器發起請求，最終得到域名的 IP 地址後，本地 DNS 服務器再將這個 IP 地址返回給請求的用
戶。用戶向本地 DNS 服務器發起請求屬於遞歸請求，本地 DNS 服務器向各級域名服務器發起請求屬於迭代請求。

（4）當瀏覽器獲得 IP 地址後，數據傳輸還須要知道目的主機 MAC 地址，由於應用層下發數據給傳輸層，TCP 協議會指定源
端口號和目的端口號，而後下發給網絡層。網絡層會將本機地址做爲源地址，獲取的 IP 地址做爲目的地址。而後將下發給
數據鏈路層，數據鏈路層的發送須要加入通訊雙方的 MAC 地址，咱們本機的 MAC 地址做爲源 MAC 地址，目的 MAC 地
址須要分狀況處理，經過將 IP 地址與咱們本機的子網掩碼相與，咱們能夠判斷咱們是否與請求主機在同一個子網裏，若是
在同一個子網裏，咱們可使用 APR 協議獲取到目的主機的 MAC 地址，若是咱們不在一個子網裏，那麼咱們的請求應該
轉發給咱們的網關，由它代爲轉發，此時一樣能夠經過 ARP 協議來獲取網關的 MAC 地址，此時目的主機的 MAC 地址應
該爲網關的地址。

（5）下面是 TCP 創建鏈接的三次握手的過程，首先客戶端向服務器發送一個 SYN 鏈接請求報文段和一個隨機序號，服務端接
收到請求後向服務器端發送一個 SYN ACK報文段，確認鏈接請求，而且也向客戶端發送一個隨機序號。客戶端接收服務器的
確認應答後，進入鏈接創建的狀態，同時向服務器也發送一個 ACK 確認報文段，服務器端接收到確認後，也進入鏈接創建
狀態，此時雙方的鏈接就創建起來了。

（6）若是使用的是 HTTPS 協議，在通訊前還存在 TLS 的一個四次握手的過程。首先由客戶端向服務器端發送使用的協議的版
本號、一個隨機數和可使用的加密方法。服務器端收到後，確認加密的方法，也向客戶端發送一個隨機數和本身的數字證
書。客戶端收到後，首先檢查數字證書是否有效，若是有效，則再生成一個隨機數，並使用證書中的公鑰對隨機數加密，而後
發送給服務器端，而且還會提供一個前面全部內容的 hash 值供服務器端檢驗。服務器端接收後，使用本身的私鑰對數據解
密，同時向客戶端發送一個前面全部內容的 hash 值供客戶端檢驗。這個時候雙方都有了三個隨機數，按照以前所約定的加
密方法，使用這三個隨機數生成一把祕鑰，之後雙方通訊前，就使用這個祕鑰對數據進行加密後再傳輸。

（7）當頁面請求發送到服務器端後，服務器端會返回一個 html 文件做爲響應，瀏覽器接收到響應後，開始對 html 文件進行
解析，開始頁面的渲染過程。

（8）瀏覽器首先會根據 html 文件構建 DOM 樹，根據解析到的 css 文件構建 CSSOM 樹，若是遇到 script 標籤，則判端
是否含有 defer 或者 async 屬性，要否則 script 的加載和執行會形成頁面的渲染的阻塞。當 DOM 樹和 CSSOM 樹建
立好後，根據它們來構建渲染樹。渲染樹構建好後，會根據渲染樹來進行佈局。佈局完成後，最後使用瀏覽器的 UI 接口對頁
面進行繪製。這個時候整個頁面就顯示出來了。

（9）最後一步是 TCP 斷開鏈接的四次揮手過程。

詳細資料能夠參考：
《當你在瀏覽器中輸入 Google.com 而且按下回車以後發生了什麼？》

7. 談談 CDN 服務？

CDN 是一個內容分發網絡，經過對源網站資源的緩存，利用自己多臺位於不一樣地域、不一樣運營商的服務器，向用戶提供資就近訪問的
功能。也就是說，用戶的請求並非直接發送給源網站，而是發送給 CDN 服務器，由 CND 服務器將請求定位到最近的含有該資源
的服務器上去請求。這樣有利於提升網站的訪問速度，同時經過這種方式也減輕了源服務器的訪問壓力。

詳細資料能夠參考：
《CDN 是什麼？使用 CDN 有什麼優點？》

8. 什麼是正向代理和反向代理？

咱們常說的代理也就是指正向代理，正向代理的過程，它隱藏了真實的請求客戶端，服務端不知道真實的客戶端是誰，客戶端請求的
服務都被代理服務器代替來請求。

反向代理隱藏了真實的服務端，當咱們請求一個網站的時候，背後可能有成千上萬臺服務器爲咱們服務，但具體是哪一臺，咱們不知
道，也不須要知道，咱們只須要知道反向代理服務器是誰就行了，反向代理服務器會幫咱們把請求轉發到真實的服務器那裏去。反向
代理器通常用來實現負載平衡。

詳細資料能夠參考：
《正向代理與反向代理有什麼區別》
《webpack 配置 proxy 反向代理的原理是什麼？》

9. 負載平衡的兩種實現方式？

一種是使用反向代理的方式，用戶的請求都發送到反向代理服務上，而後由反向代理服務器來轉發請求到真實的服務器上，以此來實
現集羣的負載平衡。

另外一種是 DNS 的方式，DNS 能夠用於在冗餘的服務器上實現負載平衡。由於如今通常的大型網站使用多臺服務器提供服務，所以一
個域名可能會對應多個服務器地址。當用戶向網站域名請求的時候，DNS 服務器返回這個域名所對應的服務器 IP 地址的集合，但在
每一個回答中，會循環這些 IP 地址的順序，用戶通常會選擇排在前面的地址發送請求。以此將用戶的請求均衡的分配到各個不一樣的服
務器上，這樣來實現負載均衡。這種方式有一個缺點就是，因爲 DNS 服務器中存在緩存，因此有可能一個服務器出現故障後，域名解
析仍然返回的是那個 IP 地址，就會形成訪問的問題。

詳細資料能夠參考：
《負載均衡的原理》

10. http 請求方法 options 方法有什麼用？

OPTIONS 請求與 HEAD 相似，通常也是用於客戶端查看服務器的性能。這個方法會請求服務器返回該資源所支持的全部 HTTP 請
 求方法，該方法會用'*'來代替資源名稱，向服務器發送 OPTIONS 請求，能夠測試服務器功能是否正常。JS 的 XMLHttpRequest
 對象進行 CORS 跨域資源共享時，對於複雜請求，就是使用 OPTIONS 方法發送嗅探請求，以判斷是否有對指定資源的訪問權限。

相關資料能夠參考：
《HTTP 請求方法》

11. http1.1 和 http1.0 之間有哪些區別？

http1.1 相對於 http1.0 有這樣幾個區別：
（1）鏈接方面的區別，http1.1 默認使用持久鏈接，而 http1.0 默認使用非持久鏈接。http1.1 經過使用持久鏈接來使多個 http 請求複用同一個 TCP 鏈接，以此來避免使用非持久鏈接時每次須要創建鏈接的時延。
（2）資源請求方面的區別，在 http1.0 中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，http1.1 則在請求頭引入了 range 頭域，它容許只請求資源的某個部分，即返回碼是 206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

（3）緩存方面的區別，在 http1.0 中主要使用 header 裏的 If-Modified-Since,Expires 來作爲緩存判斷的標準，http1.1 則引入了更多的緩存控制策略例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供選擇的緩存頭來控制緩存策略。

（4）http1.1 中還新增了 host 字段，用來指定服務器的域名。http1.0 中認爲每臺服務器都綁定一個惟一的 IP 地址，所以，請求消息中的 URL 並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機，而且它們共享一個IP地址。所以有了 host 字段，就能夠將請求發往同一臺服務器上的不一樣網站。

（5）http1.1 相對於 http1.0 還新增了不少方法，如 PUT、HEAD、OPTIONS 等。

詳細資料能夠參考：
《HTTP1.0、HTTP1.1 和 HTTP2.0 的區別》
《HTTP 協議入門》
《網絡---一篇文章詳解請求頭 Host 的概念》

12. 網站域名加 www 與不加 www 的區別？

詳細資料能夠參考：
《爲何域名前要加 www 前綴 www 是什麼意思？》
《爲何愈來愈多的網站域名不加「www」前綴？》
《域名有 www 與沒有 www 有什麼區別？》

13. 即時通信的實現，短輪詢、長輪詢、SSE 和 WebSocket 間的區別？

短輪詢和長輪詢的目的都是用於實現客戶端和服務器端的一個即時通信。

短輪詢的基本思路就是瀏覽器每隔一段時間向瀏覽器發送 http 請求，服務器端在收到請求後，不管是否有數據更新，都直接進行
響應。這種方式實現的即時通訊，本質上仍是瀏覽器發送請求，服務器接受請求的一個過程，經過讓客戶端不斷的進行請求，使得客
戶端可以模擬實時地收到服務器端的數據的變化。這種方式的優勢是比較簡單，易於理解。缺點是這種方式因爲須要不斷的創建 ht
tp 鏈接，嚴重浪費了服務器端和客戶端的資源。當用戶增長時，服務器端的壓力就會變大，這是很不合理的。

長輪詢的基本思路是，首先由客戶端向服務器發起請求，當服務器收到客戶端發來的請求後，服務器端不會直接進行響應，而是先將
這個請求掛起，而後判斷服務器端數據是否有更新。若是有更新，則進行響應，若是一直沒有數據，則到達必定的時間限制才返回。
客戶端 JavaScript 響應處理函數會在處理完服務器返回的信息後，再次發出請求，從新創建鏈接。長輪詢和短輪詢比起來，它的
優勢是明顯減小了不少沒必要要的 http 請求次數，相比之下節約了資源。長輪詢的缺點在於，鏈接掛起也會致使資源的浪費。

SSE 的基本思想是，服務器使用流信息向服務器推送信息。嚴格地說，http 協議沒法作到服務器主動推送信息。可是，有一種變通
方法，就是服務器向客戶端聲明，接下來要發送的是流信息。也就是說，發送的不是一次性的數據包，而是一個數據流，會接二連三
地發送過來。這時，客戶端不會關閉鏈接，會一直等着服務器發過來的新的數據流，視頻播放就是這樣的例子。SSE 就是利用這種機
制，使用流信息向瀏覽器推送信息。它基於 http 協議，目前除了 IE/Edge，其餘瀏覽器都支持。它相對於前面兩種方式來講，不
須要創建過多的 http 請求，相比之下節約了資源。

上面三種方式本質上都是基於 http 協議的，咱們還可使用 WebSocket 協議來實現。WebSocket 是 Html5 定義的一個新協
議，與傳統的 http 協議不一樣，該協議容許由服務器主動的向客戶端推送信息。使用 WebSocket 協議的缺點是在服務器端的配置
比較複雜。WebSocket 是一個全雙工的協議，也就是通訊雙方是平等的，能夠相互發送消息，而 SSE 的方式是單向通訊的，只能
由服務器端向客戶端推送信息，若是客戶端須要發送信息就是屬於下一個 http 請求了。

詳細資料能夠參考：
《輪詢、長輪詢、長鏈接、websocket》
《Server-Sent Events 教程》
《WebSocket 教程》

14. 怎麼實現多個網站之間共享登陸狀態

在多個網站之間共享登陸狀態指的就是單點登陸。多個應用系統中，用戶只須要登陸一次就能夠訪問全部相互信任的應用系統。

我認爲單點登陸能夠這樣來實現，首先將用戶信息的驗證中心獨立出來，做爲一個單獨的認證中心，該認證中心的做用是判斷客戶端發
送的帳號密碼的正確性，而後向客戶端返回對應的用戶信息，而且返回一個由服務器端祕鑰加密的登陸信息的 token 給客戶端，該
token 具備必定的有效時限。當一個應用系統跳轉到另外一個應用系統時，經過 url 參數的方式來傳遞 token，而後轉移到的應用站
點發送給認證中心，認證中心對 token 進行解密後驗證，若是用戶信息沒有失效，則向客戶端返回對應的用戶信息，若是失效了則將
頁面重定向會單點登陸頁面。

詳細資料能夠參考：
《HTTP 是個無狀態協議，怎麼保持登陸狀態？》