計算機網路、計算機作業系統這兩個“兄弟”是所有開發崗位都需要“結拜”的，不管你是 Java、C++還是測試。對於後端開發的童鞋來說，計算機網路的重要性不亞於語言基礎，畢竟平時開發經常會和網路打交道，比如：抓個包等等。所以對這一塊知識點的準備還是要抱著敬畏之心，不要放過任何一個漏網之題。下面分享下我的學習過程：

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

2. 做筆記：計算機網路的知識點還是比較多的，需要看書的時候做好筆記，方便複習。而且做筆記的時候可以就這個知識點去百度下，看看有沒有自己遺漏的點，再給補充進來。在這裡說下，我為什麼一直強調做筆記？好處 1：做筆記是第 1 次你對書中的知識點的回顧，加深記憶；好處 2：而且如果你是發表在公關社群的肯定要保證最大限度的正確性，就需要再去看看這個知識點，核對下自己是否有理解偏差和遺漏等，這樣就完成了知識點的深挖；好處3：正在到面試複習的時候，你是不太可能重新看一本書的，那麼筆記就顯得很重要了，自己做的筆記，複習起來很快，而且最好在筆記裡能有一些自己區別於面經的理解。

3. 看面經：經常刷一刷牛客，看看對於計算機網路，面試官們都是怎麼問的？很多問題你可能會，但是不懂面試官的問法，也會回答不上來；問到的題目自己是否準備了？而且對於計算機網路和計算機作業系統會因為公司和崗位的不同而有所側重的，多看看面經就會發現還是有一點規律的，但是這都不是絕對的，最後還要看面你的面試官的喜好。

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

學習計算機網路時我們一般採用折中的辦法，也就是中和 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）的作用是實現相鄰計算機節點之間位元流的透明傳送，儘可能遮蔽掉具體傳輸介質和物理裝置的差異。使其上面的資料鏈路層不必考慮網路的具體傳輸介質是什麼。“透明傳送位元流”表示經實際電路傳送後的位元流沒有發生變化，對傳送的位元流來說，這個電路好像是看不見的。

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

計算機五層網路體系中涉及的協議非常多，下面就常用的做了列舉：

3、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 查詢失敗。

4、談下你對 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 開頭，保留地址

5、TCP 的主要特點是什麼？

1. TCP 是面向連線的。（就好像打電話一樣，通話前需要先撥號建立連線，通話結束後要掛機釋放連線）； 2. 每一條 TCP 連線只能有兩個端點，每一條 TCP 連線只能是點對點的（一對一）； 3. TCP 提供可靠交付的服務。通過 TCP 連線傳送的資料，無差錯、不丟失、不重複、並且按序到達； 4. TCP 提供全雙工通訊。TCP 允許通訊雙方的應用程式在任何時候都能傳送資料。TCP 連線的兩端都設有傳送快取和接收快取，用來臨時存放雙方通訊的資料； 5. 面向位元組流。TCP 中的“流”（Stream）指的是流入程式或從程式流出的位元組序列。“面向位元組流”的含義是：雖然應用程式和 TCP 的互動是一次一個資料塊（大小不等），但 TCP 把應用程式交下來的資料僅僅看成是一連串的無結構的位元組流。

6、UDP 的主要特點是什麼？

1. UDP 是無連線的； 2. UDP 使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持複雜的連結狀態（這裡面有許多引數）； 3. UDP 是面向報文的； 4. UDP 沒有擁塞控制，因此網路出現擁塞不會使源主機的傳送速率降低（對實時應用很有用，如 直播，實時視訊會議等）； 5. UDP 支援一對一、一對多、多對一和多對多的互動通訊； 6. UDP 的首部開銷小，只有 8 個位元組，比 TCP 的 20 個位元組的首部要短。

7、TCP 和 UDP 的區別？

TCP 提供面向連線的服務。在傳送資料之前必須先建立連線，資料傳送結束後要釋放連線。TCP 不提供廣播或多播服務。由於 TCP 要提供可靠的，面向連線的運輸服務（TCP 的可靠體現在 TCP 在傳遞資料之前，會有三次握手來建立連線，而且在資料傳遞時，有確認、視窗、重傳、擁塞控制機制，在資料傳完後，還會斷開連線用來節約系統資源），這難以避免增加了許多開銷，如確認，流量控制，計時器以及連線管理等。這不僅使協議資料單元的首部增大很多，還要佔用許多處理機資源。 UDP 在傳送資料之前不需要先建立連線，遠地主機在收到 UDP 報文後，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用於即時通訊），比如：QQ 語音、 QQ 視訊 、直播等等。

8、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 服務。

9、詳細說下 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（已建立連線）狀態。

10、為什麼兩次握手不可以呢？

為了防止已經失效的連線請求報文段突然又傳送到了 B，因而產生錯誤。比如下面這種情況：A 發出的第一個連線請求報文段並沒有丟失，而是在網路結點長時間滯留了，以致於延誤到連線釋放以後的某個時間段才到達 B。本來這是一個早已失效的報文段。但是 B 收到此失效的連結請求報文段後，就誤認為 A 又發出一次新的連線請求。於是就向 A 發出確認報文段，同意建立連線。 對於上面這種情況，如果不進行第三次握手，B 發出確認後就認為新的運輸連線已經建立了，並一直等待 A 發來資料。B 的許多資源就這樣白白浪費了。 如果採用了三次握手，由於 A 實際上並沒有發出建立連線請求，所以不會理睬 B 的確認，也不會向 B 傳送資料。B 由於收不到確認，就知道 A 並沒有要求建立連線。

11、為什麼不需要四次握手？

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

我們需要明白一點，完全可靠的通訊協議是不存在的。在經過三次握手之後，客戶端和服務端已經可以確認之前的通訊狀況，都收到了確認資訊。所以即便再增加握手次數也不能保證後面的通訊完全可靠，所以是沒有必要的。

12、Server 端收到 Client 端的 SYN 後，為什麼還要傳回 SYN？

接收端傳回傳送端所傳送的 SYN 是為了告訴傳送端，我接收到的資訊確實就是你所傳送的訊號了。

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

13、傳了 SYN，為什麼還要傳 ACK？

雙方通訊無誤必須是兩者互相傳送資訊都無誤。傳了 SYN，證明傳送方到接收方的通道沒有問題，但是接收方到傳送方的通道還需要 ACK 訊號來進行驗證。

14、詳細說下 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。

15、為什麼 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，就可以使本連線持續的時間內所產生的所有報文段都從網路中消失。這樣就可以使下一個連線中不會出現這種舊的連線請求報文段。

16、為什麼第二次跟第三次不能合併,第二次和第三次之間的等待是什麼?

當伺服器執行第二次揮手之後,此時證明客戶端不會再向服務端請求任何資料,但是服務端可能還正在給客戶端傳送資料（可能是客戶端上一次請求的資源還沒有傳送完畢），所以此時服務端會等待把之前未傳輸完的資料傳輸完畢之後再傳送關閉請求。

17、保活計時器的作用？

除時間等待計時器外，TCP 還有一個保活計時器（keepalive timer）。設想這樣的場景：客戶已主動與伺服器建立了 TCP 連線。但後來客戶端的主機突然發生故障。顯然，伺服器以後就不能再收到客戶端發來的資料。因此，應當有措施使伺服器不要再白白等待下去。這就需要使用保活計時器了。

伺服器每收到一次客戶的資料，就重新設定保活計時器，時間的設定通常是兩個小時。若兩個小時都沒有收到客戶端的資料，服務端就傳送一個探測報文段，以後則每隔 75 秒鐘傳送一次。若連續傳送 10個 探測報文段後仍然無客戶端的響應，服務端就認為客戶端出了故障，接著就關閉這個連線。

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

1. 資料包校驗：目的是檢測資料在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段並且不給出響應，這時 TCP 傳送資料端超時後會重發資料； 2. 對失序資料包重排序：既然 TCP 報文段作為 IP 資料報來傳輸，而 IP 資料報的到達可能會失序，因此 TCP 報文段的到達也可能會失序。TCP 將對失序資料進行重新排序，然後才交給應用層； 3. 丟棄重複資料：對於重複資料，能夠丟棄重複資料； 4. 應答機制：當 TCP 收到發自 TCP 連線另一端的資料，它將傳送一個確認。這個確認不是立即傳送，通常將推遲幾分之一秒； 5. 超時重發：當 TCP 發出一個段後，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發這個報文段； 6. 流量控制：TCP 連線的每一方都有固定大小的緩衝空間。TCP 的接收端只允許另一端傳送接收端緩衝區所能接納的資料，這可以防止較快主機致使較慢主機的緩衝區溢位，這就是流量控制。TCP 使用的流量控制協議是可變大小的滑動視窗協議。

19、談談你對停止等待協議的理解？

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

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

• 自動重傳請求 ARQ 協議
  

停止等待協議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面傳送過的分組（認為剛才傳送過的分組丟失了）。因此每傳送完一個分組需要設定一個超時計時器，其重傳時間應比資料在分組傳輸的平均往返時間更長一些。這種自動重傳方式常稱為自動重傳請求 ARQ。

• 連續 ARQ 協議
  

連續 ARQ 協議可提高通道利用率。傳送方維持一個傳送視窗，凡位於傳送視窗內的分組可以連續傳送出去，而不需要等待對方確認。接收方一般採用累計確認，對按序到達的最後一個分組傳送確認，表明到這個分組為止的所有分組都已經正確收到了。

21、談談你對滑動視窗的瞭解？

TCP 利用滑動視窗實現流量控制的機制。滑動視窗（Sliding window）是一種流量控制技術。早期的網路通訊中，通訊雙方不會考慮網路的擁擠情況直接傳送資料。由於大家不知道網路擁塞狀況，同時傳送資料，導致中間節點阻塞掉包，誰也發不了資料，所以就有了滑動視窗機制來解決此問題。

TCP 中採用滑動視窗來進行傳輸控制，滑動視窗的大小意味著接收方還有多大的緩衝區可以用於接收資料。傳送方可以通過滑動視窗的大小來確定應該傳送多少位元組的資料。當滑動視窗為 0 時，傳送方一般不能再傳送資料報，但有兩種情況除外，一種情況是可以傳送緊急資料，例如，允許使用者終止在遠端機上的執行程式。另一種情況是傳送方可以傳送一個 1 位元組的資料報來通知接收方重新宣告它希望接收的下一位元組及傳送方的滑動視窗大小。

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

TCP 利用滑動視窗實現流量控制。流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。接收方傳送的確認報文中的視窗欄位可以用來控制傳送方視窗大小，從而影響傳送方的傳送速率。將視窗欄位設定為 0，則傳送方不能傳送資料。

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

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

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

為了進行擁塞控制，TCP 傳送方要維持一個擁塞視窗(cwnd) 的狀態變數。擁塞控制視窗的大小取決於網路的擁塞程度，並且動態變化。傳送方讓自己的傳送視窗取為擁塞視窗和接收方的接受視窗中較小的一個。

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

• 慢開始：

慢開始演演算法的思路是當主機開始傳送資料時，如果立即把大量資料位元組注入到網路，那麼可能會引起網路阻塞，因為現在還不知道網路的符合情況。經驗表明，較好的方法是先探測一下，即由小到大逐漸增大傳送視窗，也就是由小到大逐漸增大擁塞視窗數值。cwnd 初始值為 1，每經過一個傳播輪次，cwnd 加倍。

• 擁塞避免：

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

• 快重傳與快恢復：
  

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

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

有了 FRR，就不會因為重傳時要求的暫停被耽誤。當有單獨的資料包丟失時，快速重傳和快恢復（FRR）能最有效地工作。當有多個資料資訊包在某一段很短的時間內丟失時，它則不能很有效地工作。

24、什麼是粘包？

在進行 Java NIO 學習時，可能會發現：如果客戶端連續不斷的向服務端傳送資料包時，服務端接收的資料會出現兩個資料包粘在一起的情況。

1. TCP 是基於位元組流的，雖然應用層和 TCP 傳輸層之間的資料互動是大小不等的資料塊，但是 TCP 把這些資料塊僅僅看成一連串無結構的位元組流，沒有邊界； 2. 從 TCP 的幀結構也可以看出，在 TCP 的首部沒有表示資料長度的欄位。

基於上面兩點，在使用 TCP 傳輸資料時，才有粘包或者拆包現象發生的可能。一個資料包中包含了傳送端傳送的兩個資料包的資訊，這種現象即為粘包。

接收端收到了兩個資料包，但是這兩個資料包要麼是不完整的，要麼就是多出來一塊，這種情況即發生了拆包和粘包。拆包和粘包的問題導致接收端在處理的時候會非常困難，因為無法區分一個完整的資料包。

25、TCP 黏包是怎麼產生的？

• 傳送方產生粘包

採用 TCP 協議傳輸資料的客戶端與伺服器經常是保持一個長連線的狀態（一次連線發一次資料不存在粘包），雙方在連線不斷開的情況下，可以一直傳輸資料。但當傳送的資料包過於的小時，那麼 TCP 協議預設的會啟用 Nagle 演演算法，將這些較小的資料包進行合併傳送（緩衝區資料傳送是一個堆壓的過程）；這個合併過程就是在傳送緩衝區中進行的，也就是說資料傳送出來它已經是粘包的狀態了。

• 接收方產生粘包

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

26、怎麼解決拆包和粘包？

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

1. 特殊字元控制； 2. 在包頭首都新增資料包的長度。 如果使用 netty 的話，就有專門的編碼器和解碼器解決拆包和粘包問題了。 tips：UDP 沒有粘包問題，但是有丟包和亂序。不完整的包是不會有的，收到的都是完全正確的包。傳送的資料單位協議是 UDP 報文或使用者資料報，傳送的時候既不合並，也不拆分。

27、你對 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 ：伺服器暫時處於超負載或正在進行停機維護，現在無法處理請求。

28、HTTP 狀態碼 301 和 302 代表的是什麼？有什麼區別？

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

• 區別：

301 redirect: 301 代表永久性轉移（Permanently Moved） 302 redirect: 302 代表暫時性轉移（Temporarily Moved）

29、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，跨站追蹤）。

31、說下 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 請求則是沒有大小限制的。

32、在瀏覽器中輸入 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. 連線結束。

33、DNS 的解析過程？

1. 主機向本地域名伺服器的查詢一般都是採用遞迴查詢。所謂遞迴查詢就是：如果主機所詢問的本地域名伺服器不知道被查詢的域名的 IP 地址，那麼本地域名伺服器就以 DNS 客戶的身份，向根域名伺服器繼續發出查詢請求報文(即替主機繼續查詢)，而不是讓主機自己進行下一步查詢。因此，遞迴查詢返回的查詢結果或者是所要查詢的 IP 地址，或者是報錯，表示無法查詢到所需的 IP 地址。 2. 本地域名伺服器向根域名伺服器的查詢的迭代查詢。迭代查詢的特點：當根域名伺服器收到本地域名伺服器發出的迭代查詢請求報文時，要麼給出所要查詢的 IP 地址，要麼告訴本地伺服器：“你下一步應當向哪一個域名伺服器進行查詢”。然後讓本地伺服器進行後續的查詢。根域名伺服器通常是把自己知道的頂級域名伺服器的 IP 地址告訴本地域名伺服器，讓本地域名伺服器再向頂級域名伺服器查詢。頂級域名伺服器在收到本地域名伺服器的查詢請求後，要麼給出所要查詢的 IP 地址，要麼告訴本地伺服器下一步應當向哪一個許可權域名伺服器進行查詢。最後，本地域名伺服器得到了所要解析的 IP 地址或報錯，然後把這個結果返回給發起查詢的主機。

34、談談你對域名快取的瞭解？

為了提高 DNS 查詢效率，並減輕伺服器的負荷和減少因特網上的 DNS 查詢報文數量，在域名伺服器中廣泛使用了快取記憶體，用來存放最近查詢過的域名以及從何處獲得域名對映資訊的記錄。

由於名字到地址的繫結並不經常改變，為保持快取記憶體中的內容正確，域名伺服器應為每項內容設定計時器並處理超過合理時間的項（例如：每個專案兩天）。當域名伺服器已從快取中刪去某項資訊後又被請求查詢該項資訊，就必須重新到授權管理該項的域名伺服器繫結資訊。當許可權伺服器回答一個查詢請求時，在響應中都指明繫結有效存在的時間值。增加此時間值可減少網路開銷，而減少此時間值可提高域名解析的正確性。

不僅在本地域名伺服器中需要快取記憶體，在主機中也需要。許多主機在啟動時從本地伺服器下載名字和地址的全部資料庫，維護存放自己最近使用的域名的快取記憶體，並且只在從快取中找不到名字時才使用域名伺服器。維護本地域名伺服器資料庫的主機應當定期地檢查域名伺服器以獲取新的對映資訊，而且主機必須從快取中刪除無效的項。由於域名改動並不頻繁，大多數網點不需花精力就能維護資料庫的一致性。

35、談下你對 HTTP 長連線和短連線的理解？分別應用於哪些場景？

在 HTTP/1.0 中預設使用短連線。也就是說，客戶端和伺服器每進行一次 HTTP 操作，就建立一次連線，任務結束就中斷連線。當客戶端瀏覽器訪問的某個 HTML 或其他型別的 Web 頁中包含有其他的 Web 資源（如：JavaScript 檔案、影象檔案、CSS 檔案等），每遇到這樣一個 Web 資源，瀏覽器就會重新建立一個 HTTP 會話。

而從 HTTP/1.1 起，預設使用長連線，用以保持連線特性。使用長連線的 HTTP 協議，會在響應頭加入這行程式碼

Connection:keep-alive複製程式碼

在使用長連線的情況下，當一個網頁開啟完成後，客戶端和伺服器之間用於傳輸 HTTP 資料的 TCP 連線不會關閉，客戶端再次訪問這個伺服器時，會繼續使用這一條已經建立的連線。

Keep-Alive 不會永久保持連線，它有一個保持時間，可以在不同的伺服器軟體（如：Apache）中設定這個時間。實現長連線需要客戶端和服務端都支援長連線。

36、談下 HTTP 1.0 和 1.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 層。

37、HTTPS 的工作過程？

1. 客戶端傳送自己支援的加密規則給伺服器，代表告訴伺服器要進行連線了； 2. 伺服器從中選出一套加密演演算法和 hash 演演算法以及自己的身份資訊（地址等）以證書的形式傳送給瀏覽器，證書中包含伺服器資訊，加密公鑰，證書的辦法機構； 3. 客戶端收到網站的證書之後要做下面的事情：

• 3.1 驗證證書的合法性；

• 3.2 果驗證通過證書，瀏覽器會生成一串隨機數，並用證書中的公鑰進行加密；

• 3.3 用約定好的 hash 演演算法計算握手訊息，然後用生成的金鑰進行加密，然後一起傳送給伺服器。

4. 伺服器接收到客戶端傳送來的資訊，要做下面的事情：

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

• 4.2 使用金鑰加密訊息；

5. 如果計演演算法 hash 值一致，握手成功。

38、HTTP 和 HTTPS 的區別？

1. 開銷：HTTPS 協議需要到 CA 申請證書，一般免費證書很少，需要交費； 2. 資源消耗：HTTP 是超文字傳輸協議，資訊是明文傳輸，HTTPS 則是具有安全性的 ssl 加密傳輸協議，需要消耗更多的 CPU 和記憶體資源； 3. 埠不同：HTTP 和 HTTPS 使用的是完全不同的連線方式，用的埠也不一樣，前者是 80，後者是 443； 4. 安全性：HTTP 的連線很簡單，是無狀態的；HTTPS 協議是由 TSL+HTTP 協議構建的可進行加密傳輸、身份認證的網路協議，比 HTTP 協議安全。

39、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 加密，如果和簽名一樣，則說明資料確實是真的。

41、什麼是數字證書？

對稱加密中，雙方使用公鑰進行解密。雖然數字簽名可以保證資料不被替換，但是資料是由公鑰加密的，如果公鑰也被替換，則仍然可以偽造資料，因為使用者不知道對方提供的公鑰其實是假的。所以為了保證傳送方的公鑰是真的，CA 證書機構會負責頒發一個證書，裡面的公鑰保證是真的，使用者請求伺服器時，伺服器將證書發給使用者，這個證書是經由系統內建證書的備案的。

42、什麼是對稱加密和非對稱加密？

對稱金鑰加密是指加密和解密使用同一個金鑰的方式，這種方式存在的最大問題就是金鑰傳送問題，即如何安全地將金鑰發給對方。

非對稱加密指使用一對非對稱金鑰，即：公鑰和私鑰，公鑰可以隨意釋出，但私鑰只有自己知道。傳送密文的一方使用對方的公鑰進行加密處理，對方接收到加密資訊後，使用自己的私鑰進行解密。

由於非對稱加密的方式不需要傳送用來解密的私鑰，所以可以保證安全性。但是和對稱加密比起來，它非常的慢，所以我們還是要用對稱加密來傳送訊息，但對稱加密所使用的金鑰我們可以通過非對稱加密的方式傳送出去。