計算機網絡太難？瞭解這一篇就夠了

時間 2019-11-05

標籤計算機網絡太難瞭解一篇夠了简体版

原文原文鏈接

計算機網絡、計算機操做系統這兩個「兄弟」是全部開發崗位都須要「結拜」的，無論你是 Java、C++仍是測試。對於後端開發的童鞋來講，計算機網絡的重要性不亞於語言基礎，畢竟平時開發常常會和網絡打交道，好比：抓個包等等。因此對這一塊知識點的準備仍是要抱着敬畏之心，不要放過任何一個漏網之題。下面分享下個人學習過程：
css

1. 看書：對於計算機比較基礎的模塊，我都是比較推薦找一本經典的書籍來好好學習下，不能夠只看面經就去面試了。我一共看了兩本書：湯小丹的《計算機操做系統》和《圖解HTTP》。《計算機操做系統》是教科書，因此知識點相對比較基礎，覆蓋範圍也比較廣，非科班的學生仍是頗有必要看一看的。《圖解HTTP》這本書用不少插圖將一些知識點講的通俗易懂，看起來也很快，仍是比較推薦的。

2. 作筆記：計算機網絡的知識點仍是比較多的，須要看書的時候作好筆記，方便複習。並且作筆記的時候能夠就這個知識點去百度下，看看有沒有本身遺漏的點，再給補充進來。在這裏說下，我爲何一直強調作筆記？好處 1：作筆記是第 1 次你對書中的知識點的回顧，加深記憶；好處 2：並且若是你是發表在公關社區的確定要保證最大限度的正確性，就須要再去看看這個知識點，覈對下本身是否有理解誤差和遺漏等，這樣就完成了知識點的深挖；好處3：正在到面試複習的時候，你是不太可能從新看一本書的，那麼筆記就顯得很重要了，本身作的筆記，複習起來很快，並且最好在筆記裏能有一些本身區別於面經的理解。面試

3. 看面經：常常刷一刷牛客，看看對於計算機網絡，面試官們都是怎麼問的？不少問題你可能會，可是不懂面試官的問法，也會回答不上來；問到的題目本身是否準備了？並且對於計算機網絡和計算機操做系統會由於公司和崗位的不一樣而有所側重的，多看看面經就會發現仍是有一點規律的，可是這都不是絕對的，最後還要看面你的面試官的喜愛。算法

一、談下你對五層網絡協議體系結構的理解？

學習計算機網絡時咱們通常採用折中的辦法，也就是中和 OSI 和 TCP/IP 的優勢，採用一種只有五層協議的體系結構，這樣既簡潔又能將概念闡述清楚。數據庫

1. 應用層

應用層（application-layer）的任務是經過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通訊和交互的規則。對於不一樣的網絡應用須要不一樣的應用層協議。在互聯網中應用層協議不少，如域名系統 DNS，支持萬維網應用的 HTTP 協議，支持電子郵件的 SMTP 協議等等。咱們把應用層交互的數據單元稱爲報文。

2. 運輸層

運輸層（transport layer）的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。「通用的」是指並不針對某一個特定的網絡應用，而是多種應用能夠使用同一個運輸層服務。

因爲一臺主機可同時運行多個線程，所以運輸層有複用和分用的功能。所謂複用就是指多個應用層進程可同時使用下面運輸層的服務，分用和複用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。

3. 網絡層

在計算機網絡中進行通訊的兩個計算機之間可能會通過不少個數據鏈路，也可能還要通過不少通訊子網。網絡層的任務就是選擇合適的網間路由和交換結點，確保數據及時傳送。在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在 TCP / IP 體系結構中，因爲網絡層使用 IP 協議，所以分組也叫 IP 數據報，簡稱數據報。後端

4. 數據鏈路層

數據鏈路層（data link layer）一般簡稱爲鏈路層。兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議。在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息（如：同步信息，地址信息，差錯控制等）。

在接收數據時，控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。這樣，數據鏈路層在收到一個幀後，就可從中提出數據部分，上交給網絡層。控制信息還使接收端可以檢測到所收到的幀中有無差錯。若是發現差錯，數據鏈路層就簡單地丟棄這個出了差錯的幀，以免繼續在網絡中傳送下去白白浪費網絡資源。若是須要改正數據在鏈路層傳輸時出現差錯（這就是說，數據鏈路層不只要檢錯，並且還要糾錯），那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。

5. 物理層

在物理層上所傳送的數據單位是比特。物理層（physical layer）的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。使其上面的數據鏈路層沒必要考慮網絡的具體傳輸介質是什麼。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化，對傳送的比特流來講，這個電路好像是看不見的。瀏覽器

二、簡單說下每一層對應的網絡協議有哪些？

計算機五層網絡體系中涉及的協議很是多，下面就經常使用的作了列舉：
緩存

三、ARP 協議的工做原理？

網絡層的 ARP 協議完成了 IP 地址與物理地址的映射。首先，每臺主機都會在本身的 ARP 緩衝區中創建一個 ARP 列表，以表示 IP 地址和 MAC 地址的對應關係。當源主機須要將一個數據包要發送到目的主機時，會首先檢查本身 ARP 列表中是否存在該 IP 地址對應的 MAC 地址：若是有，就直接將數據包發送到這個 MAC 地址；若是沒有，就向本地網段發起一個 ARP 請求的廣播包，查詢此目的主機對應的 MAC 地址。安全

此 ARP 請求數據包裏包括源主機的 IP 地址、硬件地址、以及目的主機的 IP 地址。網絡中全部的主機收到這個 ARP 請求後，會檢查數據包中的目的 IP 是否和本身的 IP 地址一致。若是不相同就忽略此數據包；若是相同，該主機首先將發送端的 MAC 地址和 IP 地址添加到本身的 ARP 列表中，若是 ARP 表中已經存在該 IP 的信息，則將其覆蓋，而後給源主機發送一個 ARP 響應數據包，告訴對方本身是它須要查找的 MAC 地址；源主機收到這個 ARP 響應數據包後，將獲得的目的主機的 IP 地址和 MAC 地址添加到本身的 ARP 列表中，並利用此信息開始數據的傳輸。若是源主機一直沒有收到 ARP 響應數據包，表示 ARP 查詢失敗。bash

四、談下你對 IP 地址分類的理解？

IP 地址是指互聯網協議地址，是 IP 協議提供的一種統一的地址格式，它爲互聯網上的每個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差別。IP 地址編址方案將 IP 地址空間劃分爲 A、B、C、D、E 五類，其中 A、B、C 是基本類，D、E 類做爲多播和保留使用，爲特殊地址。服務器

每一個 IP 地址包括兩個標識碼（ID），即網絡 ID 和主機 ID。同一個物理網絡上的全部主機都使用同一個網絡 ID，網絡上的一個主機（包括網絡上工做站，服務器和路由器等）有一個主機 ID 與其對應。A~E 類地址的特色以下：

A 類地址：以 0 開頭，第一個字節範圍：0~127；

B 類地址：以 10 開頭，第一個字節範圍：128~191；

C 類地址：以 110 開頭，第一個字節範圍：192~223；

D 類地址：以 1110 開頭，第一個字節範圍爲 224~239；

E 類地址：以 1111 開頭，保留地址

五、TCP 的主要特色是什麼？

1. TCP 是面向鏈接的。（就好像打電話同樣，通話前須要先撥號創建鏈接，通話結束後要掛機釋放鏈接）；

2. 每一條 TCP 鏈接只能有兩個端點，每一條 TCP 鏈接只能是點對點的（一對一）；

3. TCP 提供可靠交付的服務。經過 TCP 鏈接傳送的數據，無差錯、不丟失、不重複、而且按序到達；

4. TCP 提供全雙工通訊。TCP 容許通訊雙方的應用進程在任什麼時候候都能發送數據。TCP 鏈接的兩端都設有發送緩存和接收緩存，用來臨時存放雙方通訊的數據；

5. 面向字節流。TCP 中的「流」（Stream）指的是流入進程或從進程流出的字節序列。「面向字節流」的含義是：雖然應用程序和 TCP 的交互是一次一個數據塊（大小不等），但 TCP 把應用程序交下來的數據僅僅當作是一連串的無結構的字節流。

六、UDP 的主要特色是什麼？

1. UDP 是無鏈接的；

2. UDP 使用盡最大努力交付，即不保證可靠交付，所以主機不須要維持複雜的連接狀態（這裏面有許多參數）；

3. UDP 是面向報文的；

4. UDP 沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如直播，實時視頻會議等）；

5. UDP 支持一對1、一對多、多對一和多對多的交互通訊；

6. UDP 的首部開銷小，只有 8 個字節，比 TCP 的 20 個字節的首部要短。

七、TCP 和 UDP 的區別？

TCP 提供面向鏈接的服務。在傳送數據以前必須先創建鏈接，數據傳送結束後要釋放鏈接。TCP 不提供廣播或多播服務。因爲 TCP 要提供可靠的，面向鏈接的運輸服務（TCP 的可靠體如今 TCP 在傳遞數據以前，會有三次握手來創建鏈接，並且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開鏈接用來節約系統資源），這難以免增長了許多開銷，如確認，流量控制，計時器以及鏈接管理等。這不只使協議數據單元的首部增大不少，還要佔用許多處理機資源。

UDP 在傳送數據以前不須要先創建鏈接，遠地主機在收到 UDP 報文後，不須要給出任何確認。雖然 UDP 不提供可靠交付，但在某些狀況下 UDP 確是一種最有效的工做方式（通常用於即時通訊），好比：QQ 語音、 QQ 視頻、直播等等。

八、TCP 和 UDP 分別對應的常見應用層協議有哪些？

1. TCP 對應的應用層協議

FTP：定義了文件傳輸協議，使用 21 端口。常說某某計算機開了 FTP 服務即是啓動了文件傳輸服務。下載文件，上傳主頁，都要用到 FTP 服務。

Telnet：它是一種用於遠程登錄的端口，用戶能夠以本身的身份遠程鏈接到計算機上，經過這種端口能夠提供一種基於 DOS 模式下的通訊服務。如之前的 BBS 是-純字符界面的，支持 BBS 的服務器將 23 端口打開，對外提供服務。

SMTP：定義了簡單郵件傳送協議，如今不少郵件服務器都用的是這個協議，用於發送郵件。如常見的免費郵件服務中用的就是這個郵件服務端口，因此在電子郵件設置-中常看到有這麼 SMTP 端口設置這個欄，服務器開放的是 25 號端口。

POP3：它是和 SMTP 對應，POP3 用於接收郵件。一般狀況下，POP3 協議所用的是 110 端口。也是說，只要你有相應的使用 POP3 協議的程序（例如 Fo-xmail 或 Outlook），就能夠不以 Web 方式登錄進郵箱界面，直接用郵件程序就能夠收到郵件（如是163 郵箱就沒有必要先進入網易網站，再進入本身的郵-箱來收信）。

HTTP：從 Web 服務器傳輸超文本到本地瀏覽器的傳送協議。

2. UDP 對應的應用層協議

DNS：用於域名解析服務，將域名地址轉換爲 IP 地址。DNS 用的是 53 號端口。

SNMP：簡單網絡管理協議，使用 161 號端口，是用來管理網絡設備的。因爲網絡設備不少，無鏈接的服務就體現出其優點。

TFTP(Trival File Transfer Protocal)：簡單文件傳輸協議，該協議在熟知端口 69 上使用 UDP 服務。

九、詳細說下 TCP 三次握手的過程？

1. 三次握手

TCP 創建鏈接的過程叫作握手，握手須要在客戶和服務器之間交換三個 TCP 報文段。

最初客戶端和服務端都處於 CLOSED(關閉) 狀態。本例中 A（Client）主動打開鏈接，B（Server）被動打開鏈接。

一開始，B 的 TCP 服務器進程首先建立傳輸控制塊TCB，準備接受客戶端進程的鏈接請求。而後服務端進程就處於 LISTEN(監聽) 狀態，等待客戶端的鏈接請求。若有，當即做出響應。

第一次握手：A 的 TCP 客戶端進程也是首先建立傳輸控制塊 TCB。而後，在打算創建 TCP 鏈接時，向 B 發出鏈接請求報文段，這時首部中的同步位 SYN=1，同時選擇一個初始序號 seq = x。TCP 規定，SYN 報文段（即 SYN = 1 的報文段）不能攜帶數據，但要消耗掉一個序號。這時，TCP 客戶進程進入 SYN-SENT（同步已發送）狀態。

第二次握手：B 收到鏈接請求報文後，若是贊成創建鏈接，則向 A 發送確認。在確認報文段中應把 SYN 位和 ACK 位都置 1，確認號是 ack = x + 1，同時也爲本身選擇一個初始序號 seq = y。請注意，這個報文段也不能攜帶數據，但一樣要消耗掉一個序號。這時 TCP 服務端進程進入 SYN-RCVD（同步收到）狀態。

第三次握手：TCP 客戶進程收到 B 的確認後，還要向 B 給出確認。確認報文段的 ACK 置 1，確認號 ack = y + 1，而本身的序號 seq = x + 1。這時 ACK 報文段能夠攜帶數據。但若是不攜帶數據則不消耗序號，這種狀況下，下一個數據報文段的序號還是 seq = x + 1。這時，TCP 鏈接已經創建，A 進入 ESTABLISHED（已創建鏈接）狀態。

十、爲何兩次握手不能夠呢？

爲了防止已經失效的鏈接請求報文段忽然又傳送到了 B，於是產生錯誤。好比下面這種狀況：A 發出的第一個鏈接請求報文段並無丟失，而是在網路結點長時間滯留了，以至於延誤到鏈接釋放之後的某個時間段纔到達 B。原本這是一個早已失效的報文段。可是 B 收到此失效的連接請求報文段後，就誤認爲 A 又發出一次新的鏈接請求。因而就向 A 發出確認報文段，贊成創建鏈接。

對於上面這種狀況，若是不進行第三次握手，B 發出確認後就認爲新的運輸鏈接已經創建了，並一直等待 A 發來數據。B 的許多資源就這樣白白浪費了。

若是採用了三次握手，因爲 A 實際上並無發出創建鏈接請求，因此不會理睬 B 的確認，也不會向 B 發送數據。B 因爲收不到確認，就知道 A 並無要求創建鏈接。

十一、爲何不須要四次握手？

有人可能會說 A 發出第三次握手的信息後在沒有接收到 B 的請求就已經進入了鏈接狀態，那若是 A 的這個確認包丟失或者滯留了怎麼辦？

咱們須要明白一點，徹底可靠的通訊協議是不存在的。在通過三次握手以後，客戶端和服務端已經能夠確認以前的通訊情況，都收到了確認信息。因此即使再增長握手次數也不能保證後面的通訊徹底可靠，因此是沒有必要的。

十二、Server 端收到 Client 端的 SYN 後，爲何還要傳回 SYN？

接收端傳回發送端所發送的 SYN 是爲了告訴發送端，我接收到的信息確實就是你所發送的信號了。

SYN 是 TCP / IP 創建鏈接時使用的握手信號。在客戶機和服務器之間創建正常的 TCP 網絡鏈接時，客戶機首先發出一個 SYN 消息，服務器使用 SYN-ACK 應答表示接收到了這個消息，最後客戶機再以 ACK(Acknowledgement[漢譯：確認字符，在數據通訊傳輸中，接收站發給發送站的一種傳輸控制字符。它表示確認發來的數據已經接受無誤]）消息響應。這樣在客戶機和服務器之間才能創建起可靠的 TCP 鏈接，數據才能夠在客戶機和服務器之間傳遞。

1三、傳了 SYN，爲何還要傳 ACK？

雙方通訊無誤必須是二者互相發送信息都無誤。傳了 SYN，證實發送方到接收方的通道沒有問題，可是接收方到發送方的通道還須要 ACK 信號來進行驗證。

1四、詳細說下 TCP 四次揮手的過程？

據傳輸結束後，通訊的雙方均可以釋放鏈接。如今 A 和 B 都處於 ESTABLISHED 狀態。

第一次揮手：A 的應用進程先向其 TCP 發出鏈接釋放報文段，並中止再發送數據，主動關閉 TCP 鏈接。A 把鏈接釋放報文段首部的終止控制位 FIN 置 1，其序號 seq = u（等於前面已傳送過的數據的最後一個字節的序號加 1），這時 A 進入 FIN-WAIT-1（終止等待1）狀態，等待 B 的確認。請注意：TCP 規定，FIN 報文段即便不攜帶數據，也將消耗掉一個序號。

第二次揮手：B 收到鏈接釋放報文段後當即發出確認，確認號是 ack = u + 1，而這個報文段本身的序號是 v（等於 B 前面已經傳送過的數據的最後一個字節的序號加1），而後 B 就進入 CLOSE-WAIT（關閉等待）狀態。TCP 服務端進程這時應通知高層應用進程，於是從 A 到 B 這個方向的鏈接就釋放了，這時的 TCP 鏈接處於半關閉（half-close）狀態，即 A 已經沒有數據要發送了，但 B 若發送數據，A 仍要接收。也就是說，從 B 到 A 這個方向的鏈接並未關閉，這個狀態可能會持續一段時間。A 收到來自 B 的確認後，就進入 FIN-WAIT-2(終止等待2)狀態，等待 B 發出的鏈接釋放報文段。

第三次揮手：若 B 已經沒有要向 A 發送的數據，其應用進程就通知 TCP 釋放鏈接。這時 B 發出的鏈接釋放報文段必須使 FIN = 1。假定 B 的序號爲 w（在半關閉狀態，B 可能又發送了一些數據）。B 還必須重複上次已發送過的確認號 ack = u + 1。這時 B 就進入 LAST-ACK(最後確認)狀態，等待 A 的確認。

第四次揮手：A 在收到 B 的鏈接釋放報文後，必須對此發出確認。在確認報文段中把 ACK 置 1，確認號 ack = w + 1，而本身的序號 seq = u + 1（前面發送的 FIN 報文段要消耗一個序號）。而後進入 TIME-WAIT(時間等待) 狀態。請注意，如今 TCP 鏈接尚未釋放掉。必須通過時間等待計時器設置的時間 2MSL（MSL：最長報文段壽命）後，A 才能進入到 CLOSED 狀態，而後撤銷傳輸控制塊，結束此次 TCP 鏈接。固然若是 B 一收到 A 的確認就進入 CLOSED 狀態，而後撤銷傳輸控制塊。因此在釋放鏈接時，B 結束 TCP 鏈接的時間要早於 A。

1五、爲何 TIME-WAIT 狀態必須等待 2MSL 的時間呢？

1. 爲了保證 A 發送的最後一個 ACK 報文段可以到達 B。這個 ACK 報文段有可能丟失，於是使處在 LAST-ACK 狀態的 B 收不到對已發送的 FIN + ACK 報文段的確認。B 會超時重傳這個 FIN+ACK 報文段，而 A 就能在 2MSL 時間內（超時 + 1MSL 傳輸）收到這個重傳的 FIN+ACK 報文段。接着 A 重傳一次確認，從新啓動 2MSL 計時器。最後，A 和 B 都正常進入到 CLOSED 狀態。若是 A 在 TIME-WAIT 狀態不等待一段時間，而是在發送完 ACK 報文段後當即釋放鏈接，那麼就沒法收到 B 重傳的 FIN + ACK 報文段，於是也不會再發送一次確認報文段，這樣，B 就沒法按照正常步驟進入 CLOSED 狀態。

2. 防止已失效的鏈接請求報文段出如今本鏈接中。A 在發送完最後一個 ACK 報文段後，再通過時間 2MSL，就能夠使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣就能夠使下一個鏈接中不會出現這種舊的鏈接請求報文段。

1六、爲何第二次跟第三次不能合併, 第二次和第三次之間的等待是什麼?

當服務器執行第二次揮手以後, 此時證實客戶端不會再向服務端請求任何數據, 可是服務端可能還正在給客戶端發送數據（多是客戶端上一次請求的資源尚未發送完畢），因此此時服務端會等待把以前未傳輸完的數據傳輸完畢以後再發送關閉請求。

1七、保活計時器的做用？

除時間等待計時器外，TCP 還有一個保活計時器（keepalive timer）。設想這樣的場景：客戶已主動與服務器創建了 TCP 鏈接。但後來客戶端的主機忽然發生故障。顯然，服務器之後就不能再收到客戶端發來的數據。所以，應當有措施使服務器不要再白白等待下去。這就須要使用保活計時器了。

服務器每收到一次客戶的數據，就從新設置保活計時器，時間的設置一般是兩個小時。若兩個小時都沒有收到客戶端的數據，服務端就發送一個探測報文段，之後則每隔 75 秒鐘發送一次。若連續發送 10個探測報文段後仍然無客戶端的響應，服務端就認爲客戶端出了故障，接着就關閉這個鏈接。

1八、TCP 協議是如何保證可靠傳輸的？

1. 數據包校驗：目的是檢測數據在傳輸過程當中的任何變化，若校驗出包有錯，則丟棄報文段而且不給出響應，這時 TCP 發送數據端超時後會重發數據；

2. 對失序數據包重排序：既然 TCP 報文段做爲 IP 數據報來傳輸，而 IP 數據報的到達可能會失序，所以 TCP 報文段的到達也可能會失序。TCP 將對失序數據進行從新排序，而後才交給應用層；

3. 丟棄重複數據：對於重複數據，可以丟棄重複數據；

4. 應答機制：當 TCP 收到發自 TCP 鏈接另外一端的數據，它將發送一個確認。這個確認不是當即發送，一般將推遲幾分之一秒；

5. 超時重發：當 TCP 發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段；

6. 流量控制：TCP 鏈接的每一方都有固定大小的緩衝空間。TCP 的接收端只容許另外一端發送接收端緩衝區所能接納的數據，這能夠防止較快主機導致較慢主機的緩衝區溢出，這就是流量控制。TCP 使用的流量控制協議是可變大小的滑動窗口協議。

1九、談談你對中止等待協議的理解？

中止等待協議是爲了實現可靠傳輸的，它的基本原理就是每發完一個分組就中止發送，等待對方確認。在收到確認後再發下一個分組；在中止等待協議中，若接收方收到重複分組，就丟棄該分組，但同時還要發送確認。主要包括如下幾種狀況：無差錯狀況、出現差錯狀況（超時重傳）、確認丟失和確認遲到、確認丟失和確認遲到。

20、談談你對 ARQ 協議的理解？

自動重傳請求 ARQ 協議

中止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發送過的分組（認爲剛纔發送過的分組丟失了）。所以每發送完一個分組須要設置一個超時計時器，其重傳時間應比數據在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱爲自動重傳請求 ARQ。

連續 ARQ 協議

連續 ARQ 協議可提升信道利用率。發送方維持一個發送窗口，凡位於發送窗口內的分組能夠連續發送出去，而不須要等待對方確認。接收方通常採用累計確認，對按序到達的最後一個分組發送確認，代表到這個分組爲止的全部分組都已經正確收到了。

2一、談談你對滑動窗口的瞭解？

TCP 利用滑動窗口實現流量控制的機制。滑動窗口（Sliding window）是一種流量控制技術。早期的網絡通訊中，通訊雙方不會考慮網絡的擁擠狀況直接發送數據。因爲你們不知道網絡擁塞情況，同時發送數據，致使中間節點阻塞掉包，誰也發不了數據，因此就有了滑動窗口機制來解決此問題。

TCP 中採用滑動窗口來進行傳輸控制，滑動窗口的大小意味着接收方還有多大的緩衝區能夠用於接收數據。發送方能夠經過滑動窗口的大小來肯定應該發送多少字節的數據。當滑動窗口爲 0 時，發送方通常不能再發送數據報，但有兩種狀況除外，一種狀況是能夠發送緊急數據，例如，容許用戶終止在遠端機上的運行進程。另外一種狀況是發送方能夠發送一個 1 字節的數據報來通知接收方從新聲明它但願接收的下一字節及發送方的滑動窗口大小。

2二、談下你對流量控制的理解？

TCP 利用滑動窗口實現流量控制。流量控制是爲了控制發送方發送速率，保證接收方來得及接收。接收方發送的確認報文中的窗口字段能夠用來控制發送方窗口大小，從而影響發送方的發送速率。將窗口字段設置爲 0，則發送方不能發送數據。

2三、談下你對 TCP 擁塞控制的理解？使用了哪些算法？

擁塞控制和流量控制不一樣，前者是一個全局性的過程，然後者指點對點通訊量的控制。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就要變壞。這種狀況就叫擁塞。

擁塞控制就是爲了防止過多的數據注入到網絡中，這樣就能夠使網絡中的路由器或鏈路不致於過載。擁塞控制所要作的都有一個前提，就是網絡可以承受現有的網絡負荷。擁塞控制是一個全局性的過程，涉及到全部的主機，全部的路由器，以及與下降網絡傳輸性能有關的全部因素。相反，流量控制每每是點對點通訊量的控制，是個端到端的問題。流量控制所要作到的就是抑制發送端發送數據的速率，以便使接收端來得及接收。

爲了進行擁塞控制，TCP 發送方要維持一個擁塞窗口(cwnd) 的狀態變量。擁塞控制窗口的大小取決於網絡的擁塞程度，而且動態變化。發送方讓本身的發送窗口取爲擁塞窗口和接收方的接受窗口中較小的一個。

TCP 的擁塞控制採用了四種算法，即：慢開始、擁塞避免、快重傳和快恢復。在網絡層也能夠使路由器採用適當的分組丟棄策略（如：主動隊列管理 AQM），以減小網絡擁塞的發生。

慢開始：

慢開始算法的思路是當主機開始發送數據時，若是當即把大量數據字節注入到網絡，那麼可能會引發網絡阻塞，由於如今還不知道網絡的符合狀況。經驗代表，較好的方法是先探測一下，即由小到大逐漸增大發送窗口，也就是由小到大逐漸增大擁塞窗口數值。cwnd 初始值爲 1，每通過一個傳播輪次，cwnd 加倍。

擁塞避免：

擁塞避免算法的思路是讓擁塞窗口 cwnd 緩慢增大，即每通過一個往返時間 RTT 就把發送方的 cwnd 加 1。

快重傳與快恢復：

在 TCP/IP 中，快速重傳和快恢復（fast retransmit and recovery，FRR）是一種擁塞控制算法，它能快速恢復丟失的數據包。

沒有 FRR，若是數據包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內，沒有新的或複製的數據包被髮送。有了 FRR，若是接收機接收到一個不按順序的數據段，它會當即給發送機發送一個重複確認。若是發送機接收到三個重複確認，它會假定確認件指出的數據段丟失了，並當即重傳這些丟失的數據段。

有了 FRR，就不會由於重傳時要求的暫停被耽誤。當有單獨的數據包丟失時，快速重傳和快恢復（FRR）能最有效地工做。當有多個數據信息包在某一段很短的時間內丟失時，它則不能頗有效地工做。

2四、什麼是粘包？

在進行 Java NIO 學習時，可能會發現：若是客戶端接二連三的向服務端發送數據包時，服務端接收的數據會出現兩個數據包粘在一塊兒的狀況。

1. TCP 是基於字節流的，雖然應用層和 TCP 傳輸層之間的數據交互是大小不等的數據塊，可是 TCP 把這些數據塊僅僅當作一連串無結構的字節流，沒有邊界；

2. 從 TCP 的幀結構也能夠看出，在 TCP 的首部沒有表示數據長度的字段。

基於上面兩點，在使用 TCP 傳輸數據時，纔有粘包或者拆包現象發生的可能。一個數據包中包含了發送端發送的兩個數據包的信息，這種現象即爲粘包。

接收端收到了兩個數據包，可是這兩個數據包要麼是不完整的，要麼就是多出來一塊，這種狀況即發生了拆包和粘包。拆包和粘包的問題致使接收端在處理的時候會很是困難，由於沒法區分一個完整的數據包。

2五、TCP 黏包是怎麼產生的？

發送方產生粘包

採用 TCP 協議傳輸數據的客戶端與服務器常常是保持一個長鏈接的狀態（一次鏈接發一次數據不存在粘包），雙方在鏈接不斷開的狀況下，能夠一直傳輸數據。但當發送的數據包過於的小時，那麼 TCP 協議默認的會啓用 Nagle 算法，將這些較小的數據包進行合併發送（緩衝區數據發送是一個堆壓的過程）；這個合併過程就是在發送緩衝區中進行的，也就是說數據發送出來它已是粘包的狀態了。

接收方產生粘包

接收方採用 TCP 協議接收數據時的過程是這樣的：數據到接收方，從網絡模型的下方傳遞至傳輸層，傳輸層的 TCP 協議處理是將其放置接收緩衝區，而後由應用層來主動獲取（C 語言用 recv、read 等函數）；這時會出現一個問題，就是咱們在程序中調用的讀取數據函數不能及時的把緩衝區中的數據拿出來，而下一個數據又到來並有一部分放入的緩衝區末尾，等咱們讀取數據時就是一個粘包。（放數據的速度 > 應用層拿數據速度）

2六、怎麼解決拆包和粘包？

分包機制通常有兩個通用的解決方法：

1. 特殊字符控制；

2. 在包頭首都添加數據包的長度。

若是使用 netty 的話，就有專門的編碼器和解碼器解決拆包和粘包問題了。

tips：UDP 沒有粘包問題，可是有丟包和亂序。不完整的包是不會有的，收到的都是徹底正確的包。傳送的數據單位協議是 UDP 報文或用戶數據報，發送的時候既不合並，也不拆分。

2七、你對 HTTP 狀態碼有了解嗎？

1XX 信息

1. 100 Continue ：代表到目前爲止都很正常，客戶端能夠繼續發送請求或者忽略這個響應。

2XX 成功

1. 200 OK

2. 204 No Content ：請求已經成功處理，可是返回的響應報文不包含實體的主體部分。通常在只須要從客戶端往服務器發送信息，而不須要返回數據時使用。

3. 206 Partial Content ：表示客戶端進行了範圍請求，響應報文包含由 Content-Range 指定範圍的實體內容。

3XX 重定向

1. 301 Moved Permanently ：永久性重定向；

2. 302 Found ：臨時性重定向；

3. 303 See Other ：和 302 有着相同的功能，可是 303 明確要求客戶端應該採用 GET 方法獲取資源。

4. 304 Not Modified ：若是請求報文首部包含一些條件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，若是不知足條件，則服務器會返回 304 狀態碼。

5. 307 Temporary Redirect ：臨時重定向，與 302 的含義相似，可是 307 要求瀏覽器不會把重定向請求的 POST 方法改爲 GET 方法。

4XX 客戶端錯誤

1. 400 Bad Request ：請求報文中存在語法錯誤。

2. 401 Unauthorized ：該狀態碼錶示發送的請求須要有認證信息（BASIC 認證、DIGEST 認證）。若是以前已進行過一次請求，則表示用戶認證失敗。

3. 403 Forbidden ：請求被拒絕。

4. 404 Not Found

5XX 服務器錯誤

1. 500 Internal Server Error ：服務器正在執行請求時發生錯誤；

2. 503 Service Unavailable ：服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

2八、HTTP 狀態碼 301 和 302 表明的是什麼？有什麼區別？

301，302 都是 HTTP 狀態的編碼，都表明着某個 URL 發生了轉移。

區別：

301 redirect: 301 表明永久性轉移（Permanently Moved）

302 redirect: 302 表明暫時性轉移（Temporarily Moved）

2九、forward 和 redirect 的區別？

Forward 和 Redirect 表明了兩種請求轉發方式：直接轉發和間接轉發。

直接轉發方式（Forward）：客戶端和瀏覽器只發出一次請求，Servlet、HTML、JSP 或其它信息資源，由第二個信息資源響應該請求，在請求對象 request 中，保存的對象對於每一個信息資源是共享的。

間接轉發方式（Redirect）：實際是兩次 HTTP 請求，服務器端在響應第一次請求的時候，讓瀏覽器再向另一個 URL 發出請求，從而達到轉發的目的。

舉個通俗的例子：

直接轉發就至關於：「A 找 B 借錢，B 說沒有，B 去找 C 借，借到借不到都會把消息傳遞給 A」；

間接轉發就至關於："A 找 B 借錢，B 說沒有，讓 A 去找 C 借"。

30、HTTP 方法有哪些？

客戶端發送的請求報文第一行爲請求行，包含了方法字段。

1. GET：獲取資源，當前網絡中絕大部分使用的都是 GET；

2. HEAD：獲取報文首部，和 GET 方法相似，可是不返回報文實體主體部分；

3. POST：傳輸實體主體

4. PUT：上傳文件，因爲自身不帶驗證機制，任何人均可以上傳文件，所以存在安全性問題，通常不使用該方法。

5. PATCH：對資源進行部分修改。PUT 也能夠用於修改資源，可是隻能徹底替代原始資源，PATCH 容許部分修改。

6. OPTIONS：查詢指定的 URL 支持的方法；

7. CONNECT：要求在與代理服務器通訊時創建隧道。使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

8. TRACE：追蹤路徑。服務器會將通訊路徑返回給客戶端。發送請求時，在 Max-Forwards 首部字段中填入數值，每通過一個服務器就會減 1，當數值爲 0 時就中止傳輸。一般不會使用 TRACE，而且它容易受到 XST 攻擊（Cross-Site Tracing，跨站追蹤）。

3一、說下 GET 和 POST 的區別？

GET 和 POST 本質都是 HTTP 請求，只不過對它們的做用作了界定和適配，而且讓他們適應各自的場景。

本質區別：GET 只是一次 HTTP請求，POST 先發請求頭再發請求體，其實是兩次請求。

1. 從功能上講，GET 通常用來從服務器上獲取資源，POST 通常用來更新服務器上的資源；

2. 從 REST 服務角度上說，GET 是冪等的，即讀取同一個資源，老是獲得相同的數據，而 POST 不是冪等的，由於每次請求對資源的改變並非相同的；進一步地，GET 不會改變服務器上的資源，而 POST 會對服務器資源進行改變；

3. 從請求參數形式上看，GET 請求的數據會附在 URL 以後，即將請求數據放置在 HTTP 報文的請求頭中，以 ? 分割 URL 和傳輸數據，參數之間以 & 相連。特別地，若是數據是英文字母/數字，原樣發送；不然，會將其編碼爲 application/x-www-form-urlencoded MIME 字符串(若是是空格，轉換爲+，若是是中文/其餘字符，則直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX 中的 XX 爲該符號以 16 進製表示的 ASCII)；而 POST 請求會把提交的數據則放置在是 HTTP 請求報文的請求體中；

4. 就安全性而言，POST 的安全性要比 GET 的安全性高，由於 GET 請求提交的數據將明文出如今 URL 上，並且 POST 請求參數則被包裝到請求體中，相對更安全；

5. 從請求的大小看，GET 請求的長度受限於瀏覽器或服務器對 URL 長度的限制，容許發送的數據量比較小，而 POST 請求則是沒有大小限制的。

3二、在瀏覽器中輸入 URL 地址到顯示主頁的過程？

1. DNS 解析：瀏覽器查詢 DNS，獲取域名對應的 IP 地址：具體過程包括瀏覽器搜索自身的 DNS 緩存、搜索操做系統的 DNS 緩存、讀取本地的 Host 文件和向本地 DNS 服務器進行查詢等。對於向本地 DNS 服務器進行查詢，若是要查詢的域名包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析(此解析具備權威性)；若是要查詢的域名不禁本地 DNS 服務器區域解析，但該服務器已緩存了此網址映射關係，則調用這個 IP 地址映射，完成域名解析（此解析不具備權威性）。若是本地域名服務器並未緩存該網址映射關係，那麼將根據其設置發起遞歸查詢或者迭代查詢；

2. TCP 鏈接：瀏覽器得到域名對應的 IP 地址之後，瀏覽器向服務器請求創建連接，發起三次握手；

3. 發送 HTTP 請求：TCP 鏈接創建起來後，瀏覽器向服務器發送 HTTP 請求；

4. 服務器處理請求並返回 HTTP 報文：服務器接收到這個請求，並根據路徑參數映射到特定的請求處理器進行處理，並將處理結果及相應的視圖返回給瀏覽器；

5. 瀏覽器解析渲染頁面：瀏覽器解析並渲染視圖，若遇到對 js 文件、css 文件及圖片等靜態資源的引用，則重複上述步驟並向服務器請求這些資源；瀏覽器根據其請求到的資源、數據渲染頁面，最終向用戶呈現一個完整的頁面。

6. 鏈接結束。

3三、DNS 的解析過程？

1. 主機向本地域名服務器的查詢通常都是採用遞歸查詢。所謂遞歸查詢就是：若是主機所詢問的本地域名服務器不知道被查詢的域名的 IP 地址，那麼本地域名服務器就以 DNS 客戶的身份，向根域名服務器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機本身進行下一步查詢。所以，遞歸查詢返回的查詢結果或者是所要查詢的 IP 地址，或者是報錯，表示沒法查詢到所需的 IP 地址。

2. 本地域名服務器向根域名服務器的查詢的迭代查詢。迭代查詢的特色：當根域名服務器收到本地域名服務器發出的迭代查詢請求報文時，要麼給出所要查詢的 IP 地址，要麼告訴本地服務器：「你下一步應當向哪個域名服務器進行查詢」。而後讓本地服務器進行後續的查詢。根域名服務器一般是把本身知道的頂級域名服務器的 IP 地址告訴本地域名服務器，讓本地域名服務器再向頂級域名服務器查詢。頂級域名服務器在收到本地域名服務器的查詢請求後，要麼給出所要查詢的 IP 地址，要麼告訴本地服務器下一步應當向哪個權限域名服務器進行查詢。最後，本地域名服務器獲得了所要解析的 IP 地址或報錯，而後把這個結果返回給發起查詢的主機。

3四、談談你對域名緩存的瞭解？

爲了提升 DNS 查詢效率，並減輕服務器的負荷和減小因特網上的 DNS 查詢報文數量，在域名服務器中普遍使用了高速緩存，用來存放最近查詢過的域名以及從何處得到域名映射信息的記錄。

因爲名字到地址的綁定並不常常改變，爲保持高速緩存中的內容正確，域名服務器應爲每項內容設置計時器並處理超過合理時間的項（例如：每一個項目兩天）。當域名服務器已從緩存中刪去某項信息後又被請求查詢該項信息，就必須從新到受權管理該項的域名服務器綁定信息。當權限服務器回答一個查詢請求時，在響應中都指明綁定有效存在的時間值。增長此時間值可減小網絡開銷，而減小此時間值可提升域名解析的正確性。

不只在本地域名服務器中須要高速緩存，在主機中也須要。許多主機在啓動時從本地服務器下載名字和地址的所有數據庫，維護存放本身最近使用的域名的高速緩存，而且只在從緩存中找不到名字時才使用域名服務器。維護本地域名服務器數據庫的主機應當按期地檢查域名服務器以獲取新的映射信息，並且主機必須從緩存中刪除無效的項。因爲域名改動並不頻繁，大多數網點不需花精力就能維護數據庫的一致性。

3五、談下你對 HTTP 長鏈接和短鏈接的理解？分別應用於哪些場景？

在 HTTP/1.0 中默認使用短鏈接。也就是說，客戶端和服務器每進行一次 HTTP 操做，就創建一次鏈接，任務結束就中斷鏈接。當客戶端瀏覽器訪問的某個 HTML 或其餘類型的 Web 頁中包含有其餘的 Web 資源（如：JavaScript 文件、圖像文件、CSS 文件等），每遇到這樣一個 Web 資源，瀏覽器就會從新創建一個 HTTP 會話。

而從 HTTP/1.1 起，默認使用長鏈接，用以保持鏈接特性。使用長鏈接的 HTTP 協議，會在響應頭加入這行代碼

Connection:keep-alive複製代碼

在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸 HTTP 數據的 TCP 鏈接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經創建的鏈接。

Keep-Alive 不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如：Apache）中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接。

3六、談下 HTTP 1.0 和 1.一、1.2 的主要變化？

HTTP1.1 的主要變化：

1. HTTP1.0 通過多年發展，在 1.1 提出了改進。首先是提出了長鏈接，HTTP 能夠在一次 TCP 鏈接中不斷髮送請求。

2. 而後 HTTP1.1 支持只發送 header 而不發送 body。緣由是先用 header 判斷可否成功，再發數據，節約帶寬，事實上，post 請求默認就是這樣作的。

3. HTTP1.1 的 host 字段。因爲虛擬主機能夠支持多個域名，因此通常將域名解析後獲得 host。

HTTP2.0 的主要變化：

1. HTTP2.0 支持多路複用，同一個鏈接能夠併發處理多個請求，方法是把 HTTP數據包拆爲多個幀，併發有序的發送，根據序號在另外一端進行重組，而不須要一個個 HTTP請求順序到達；

2. HTTP2.0 支持服務端推送，就是服務端在 HTTP 請求到達後，除了返回數據以外，還推送了額外的內容給客戶端；

3. HTTP2.0 壓縮了請求頭，同時基本單位是二進制幀流，這樣的數據佔用空間更少；

4. HTTP2.0 適用於 HTTPS 場景，由於其在 HTTP和 TCP 中間加了一層 SSL 層。

3七、HTTPS 的工做過程？

1. 客戶端發送本身支持的加密規則給服務器，表明告訴服務器要進行鏈接了；

2. 服務器從中選出一套加密算法和 hash 算法以及本身的身份信息（地址等）以證書的形式發送給瀏覽器，證書中包含服務器信息，加密公鑰，證書的辦法機構；

3. 客戶端收到網站的證書以後要作下面的事情：

3.1 驗證證書的合法性；
3.2 果驗證經過證書，瀏覽器會生成一串隨機數，並用證書中的公鑰進行加密；
3.3 用約定好的 hash 算法計算握手消息，而後用生成的密鑰進行加密，而後一塊兒發送給服務器。

4. 服務器接收到客戶端傳送來的信息，要作下面的事情：

4.1 用私鑰解析出密碼，用密碼解析握手消息，驗證 hash 值是否和瀏覽器發來的一致；
4.2 使用密鑰加密消息；

5. 若是計算法 hash 值一致，握手成功。

3八、HTTP 和 HTTPS 的區別？

1. 開銷：HTTPS 協議須要到 CA 申請證書，通常免費證書不多，須要交費；

2. 資源消耗：HTTP 是超文本傳輸協議，信息是明文傳輸，HTTPS 則是具備安全性的 ssl 加密傳輸協議，須要消耗更多的 CPU 和內存資源；

3. 端口不一樣：HTTP 和 HTTPS 使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是 80，後者是 443；

4. 安全性：HTTP 的鏈接很簡單，是無狀態的；HTTPS 協議是由 TSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全。

3九、HTTPS 的優缺點？

優勢：

1. 使用 HTTPS 協議可認證用戶和服務器，確保數據發送到正確的客戶機和服務器；

2. HTTPS 協議是由 SSL + HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，要比 HTTP 協議安全，可防止數據在傳輸過程當中不被竊取、改變，確保數據的完整性；

3. HTTPS 是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增長了中間人攻擊的成本。

缺點：

1. HTTPS 協議握手階段比較費時，會使頁面的加載時間延長近 50%，增長 10% 到 20% 的耗電；

2. HTTPS 鏈接緩存不如 HTTP 高效，會增長數據開銷和功耗，甚至已有的安全措施也會所以而受到影響；

3. SSL 證書須要錢，功能越強大的證書費用越高，我的網站、小網站沒有必要通常不會用；

4. SSL 證書一般須要綁定 IP，不能在同一 IP 上綁定多個域名，IPv4 資源不可能支撐這個消耗；

5. HTTPS 協議的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什麼做用。最關鍵的，SSL 證書的信用鏈體系並不安全，特別是在某些國家能夠控制 CA 根證書的狀況下，中間人攻擊同樣可行。

40、什麼是數字簽名？

爲了不數據在傳輸過程當中被替換，好比黑客修改了你的報文內容，可是你並不知道，因此咱們讓發送端作一個數字簽名，把數據的摘要消息進行一個加密，好比 MD5，獲得一個簽名，和數據一塊兒發送。而後接收端把數據摘要進行 MD5 加密，若是和簽名同樣，則說明數據確實是真的。

4一、什麼是數字證書？

對稱加密中，雙方使用公鑰進行解密。雖然數字簽名能夠保證數據不被替換，可是數據是由公鑰加密的，若是公鑰也被替換，則仍然能夠僞造數據，由於用戶不知道對方提供的公鑰實際上是假的。因此爲了保證發送方的公鑰是真的，CA 證書機構會負責頒發一個證書，裏面的公鑰保證是真的，用戶請求服務器時，服務器將證書發給用戶，這個證書是經由系統內置證書的備案的。