計算機網絡面試基礎知識總結

最近正值秋招，計算機網絡往往是面試易結點，準備做一個總結，算是鞏固下自己的知識，也給大家做個參考。

1. 計算機網絡體系結構*

1. 五層協議

應用層 ：爲特定應用程序提供數據傳輸服務，例如 HTTP、DNS 等。數據單位爲報文。

運輸層 ：提供的是進程間的通用數據傳輸服務。由於應用層協議很多，定義通用的運輸層協議就可以支持不斷增多的應用層協議。
運輸層包括兩種協議：
傳輸控制協議 TCP，提供面向連接、可靠的數據傳輸服務，數據單位爲報文段；
用戶數據報協議 UDP，提供無連接、盡最大努力的數據傳輸服務，數據單位爲用戶數據報。
TCP 主要提供完整性服務，UDP 主要提供及時性服務。

網絡層 ：爲主機間提供數據傳輸服務，而運輸層協議是爲主機中的進程提供服務。網絡層把運輸層傳遞下來的報文段或者用戶數據報封裝成分組。

數據鏈路層 ：網絡層針對的還是主機之間的數據傳輸服務，而主機之間可以有很多鏈路，鏈路層協議就是爲同一鏈路的主機提供服務。數據鏈路層把網絡層傳下來的分組封裝成幀。

物理層 ：考慮的是怎樣在傳輸媒體上傳輸數據比特流，而不是指具體的傳輸媒體。物理層的作用是儘可能屏蔽傳輸媒體和通信手段的差異，使數據鏈路層感覺不到這些差異。

2. OSI（七層協議 多了表示層和會話層）

其中表示層和會話層用途如下：
表示層 ：數據壓縮、加密以及數據描述，這使得應用程序不必擔心在各臺主機中數據內部格式不同的問題。
會話層 ：建立及管理會話。
五層協議沒有表示層和會話層，而是將這些功能留給應用程序開發者處理。

3. TCP/IP

它只有四層，相當於五層協議中數據鏈路層和物理層合併爲網絡接口層。
TCP/IP 體系結構不嚴格遵循 OSI 分層概念，應用層可能會直接使用 IP 層或者網絡接口層。

TCP/IP 協議族是一種沙漏形狀，中間小兩邊大，IP 協議在其中佔用舉足輕重的地位。

4. 數據在各層之間的傳遞過程

在向下的過程中，需要添加下層協議所需要的首部或者尾部，而在向上的過程中不斷拆開首部和尾部。
路由器只有下面三層協議，因爲路由器位於網絡核心中，不需要爲進程或者應用程序提供服務，因此也就不需要運輸層和應用層。

2. 傳輸層*

對於開發人員來說，重點掌握上層的協議就差不多了，傳輸層是核心

1.UDP 和 TCP 的特點

用戶數據報協議 UDP（User Datagram Protocol）是無連接的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程序傳下來的報文不合並也不拆分，只是添加 UDP 首部），支持一對一、一對多、多對一和多對多的交互通信。
傳輸控制協議 TCP（Transmission Control Protocol）是面向連接的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通信，面向字節流（把應用層傳下來的報文看成字節流，把字節流組織成大小不等的數據塊），每一條 TCP 連接只能是點對點的（一對一）。

2.UDP 首部格式

首部字段只有 8 個字節，包括源端口、目的端口、長度、檢驗和。12 字節的僞首部是爲了計算檢驗和臨時添加的。

3.TCP 首部格式

序號 ：用於對字節流進行編號，例如序號爲 301，表示第一個字節的編號爲 301，如果攜帶的數據長度爲 100 字節，那麼下一個報文段的序號應爲 401。
確認號 ：期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號爲 501，攜帶的數據長度爲 200 字節，因此 B 期望下一個報文段的序號爲 701，B 發送給 A 的確認報文段中確認號就爲 701。
數據偏移 ：指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
確認 ACK ：當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立後所有傳送的報文段都必須把 ACK 置 1。
同步 SYN ：在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1。
終止 FIN ：用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，並要求釋放連接。
窗口 ：窗口值作爲接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因爲接收方的數據緩存空間是有限的。

3.TCP 的三次握手

假設 A 爲客戶端，B 爲服務器端。
首先 B 處於 LISTEN（監聽）狀態，等待客戶的連接請求。

1. A 向 B 發送連接請求報文，SYN=1，ACK=0，選擇一個初始的序號 x。
2. B 收到連接請求報文，如果同意建立連接，則向 A 發送連接確認報文，SYN=1，ACK=1，確認號爲 x+1，同時也選擇一個初始的序號 y。
3. A 收到 B 的連接確認報文後，還要向 B 發出確認，確認號爲 y+1，序號爲 x+1。
4. B 收到 A 的確認後，連接建立。

####三次握手的原因
第三次握手是爲了防止失效的連接請求到達服務器，讓服務器錯誤打開連接。
客戶端發送的連接請求如果在網絡中滯留，那麼就會隔很長一段時間才能收到服務器端發回的連接確認。客戶端等待一個超時重傳時間之後，就會重新請求連接。但是這個滯留的連接請求最後還是會到達服務器，如果不進行三次握手，那麼服務器就會打開兩個連接。如果有第三次握手，客戶端會忽略服務器之後發送的對滯留連接請求的連接確認，不進行第三次握手，因此就不會再次打開連接。

4.TCP 的四次揮手

以下描述不討論序號和確認號，因爲序號和確認號的規則比較簡單。並且不討論 ACK，因爲 ACK 在連接建立之後都爲 1。

1. A 發送連接釋放報文，FIN=1。
2. B 收到之後發出確認，此時 TCP 屬於半關閉狀態，B 能向 A 發送數據但是 A 不能向 B 發送數據。
3. 當 B 不再需要連接時，發送連接釋放報文，FIN=1。
4. A 收到後發出確認，進入 TIME-WAIT 狀態，等待 2 MSL（最大報文存活時間）後釋放連接。
5. B 收到 A 的確認後釋放連接。

四次揮手的原因

客戶端發送了 FIN 連接釋放報文之後，服務器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是爲了讓服務器端發送還未傳送完畢的數據，傳送完畢之後，服務器會發送 FIN 連接釋放報文。

TIME_WAIT

客戶端接收到服務器端的 FIN 報文後進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設置的時間 2MSL。這麼做有兩個理由：
確保最後一個確認報文能夠到達。如果 B 沒收到 A 發送來的確認報文，那麼就會重新發送連接釋放請求報文，A 等待一段時間就是爲了處理這種情況的發生。
等待一段時間是爲了讓本連接持續時間內所產生的所有報文都從網絡中消失，使得下一個新的連接不會出現舊的連接請求報文。

5.TCP 可靠傳輸

TCP可靠傳輸方面，主要採用以下4中機制：

1. 字節編號機制。TCP 數據段以字節爲單位對數據段中的「數據」部分進行一一編號，確保每個字節的數據都可以有序傳送和接受。
2. 數據段確認機制。TCP 要求每接受一個數據段都必須由接收端向發送端返回一個確認數據段（可以用一個去人數據段一次確認全面多個數據段），其中的「確認號」表明接收端已正確接受的數據段序號（「確認號」前面的所有數據段，確認號表示將要接收的下一個數據段編號）。
3. 超時重傳機制。在 TCP 中有一個重傳定時器（Retransmission Timer， RTT），在發送一個數據段的同時也啓動了該定時器。如果在定時器過期之前該數據段還沒有被對方確認的話，且定時器停止，然後重傳對應序號的數據段。
4. 選擇性確認（Selective ACK， SACK）機制。在 SACK 支持下，僅可以重傳缺少部分的數據，而不會重傳那些已經正確接受的數據段。

3.應用層

1.常用端口

4. Web 頁面請求過程

這裏採用了《計算機網絡——自頂向下》這本書中的說法，比較全面，面試可以簡化。

1. DHCP 配置主機信息

假設主機最開始沒有 IP 地址以及其它信息，那麼就需要先使用 DHCP 來獲取。
主機生成一個 DHCP 請求報文，並將這個報文放入具有目的端口 67 和源端口 68 的 UDP 報文段中。
該報文段則被放入在一個具有廣播 IP 目的地址(255.255.255.255) 和源 IP 地址（0.0.0.0）的 IP 數據報中。
該數據報則被放置在 MAC 幀中，該幀具有目的地址 FF:FF:FF:FF:FF:FF，將廣播到與交換機連接的所有設備。
連接在交換機的 DHCP 服務器收到廣播幀之後，不斷地向上分解得到 IP 數據報、UDP 報文段、DHCP 請求報文，之後生成 DHCP ACK 報文，該報文包含以下信息：IP 地址、DNS 服務器的 IP 地址、默認網關路由器的 IP 地址和子網掩碼。該報文被放入 UDP 報文段中，UDP 報文段有被放入 IP 數據報中，最後放入 MAC 幀中。
該幀的目的地址是請求主機的 MAC 地址，因爲交換機具有自學習能力，之前主機發送了廣播幀之後就記錄了 MAC 地址到其轉發接口的交換表項，因此現在交換機就可以直接知道應該向哪個接口發送該幀。
主機收到該幀後，不斷分解得到 DHCP 報文。之後就配置它的 IP 地址、子網掩碼和 DNS 服務器的 IP 地址，並在其 IP 轉發表中安裝默認網關。

2.ARP 解析 MAC 地址

主機通過瀏覽器生成一個 TCP 套接字，套接字向 HTTP 服務器發送 HTTP 請求。爲了生成該套接字，主機需要知道網站的域名對應的 IP 地址。
主機生成一個 DNS 查詢報文，該報文具有 53 號端口，因爲 DNS 服務器的端口號是 53。
該 DNS 查詢報文被放入目的地址爲 DNS 服務器 IP 地址的 IP 數據報中。
該 IP 數據報被放入一個以太網幀中，該幀將發送到網關路由器。
DHCP 過程只知道網關路由器的 IP 地址，爲了獲取網關路由器的 MAC 地址，需要使用 ARP 協議。
主機生成一個包含目的地址爲網關路由器 IP 地址的 ARP 查詢報文，將該 ARP 查詢報文放入一個具有廣播目的地址（FF:FF:FF:FF:FF:FF）的以太網幀中，並向交換機發送該以太網幀，交換機將該幀轉發給所有的連接設備，包括網關路由器。
網關路由器接收到該幀後，不斷向上分解得到 ARP 報文，發現其中的 IP 地址與其接口的 IP 地址匹配，因此就發送一個 ARP 回答報文，包含了它的 MAC 地址，發回給主機。

3.DNS 解析域名

知道了網關路由器的 MAC 地址之後，就可以繼續 DNS 的解析過程了。
網關路由器接收到包含 DNS 查詢報文的以太網幀後，抽取出 IP 數據報，並根據轉發表決定該 IP 數據報應該轉發的路由器。
因爲路由器具有內部網關協議（RIP、OSPF）和外部網關協議（BGP）這兩種路由選擇協議，因此路由表中已經配置了網關路由器到達 DNS 服務器的路由表項。
到達 DNS 服務器之後，DNS 服務器抽取出 DNS 查詢報文，並在 DNS 數據庫中查找待解析的域名。
找到 DNS 記錄之後，發送 DNS 回答報文，將該回答報文放入 UDP 報文段中，然後放入 IP 數據報中，通過路由器反向轉發回網關路由器，並經過以太網交換機到達主機。

4. HTTP 請求頁面

有了 HTTP 服務器的 IP 地址之後，主機就能夠生成 TCP 套接字，該套接字將用於向 Web 服務器發送 HTTP GET 報文。 在生成 TCP 套接字之前，必須先與 HTTP 服務器進行三次握手來建立連接。生成一個具有目的端口 80 的 TCP SYN 報文段，並向 HTTP 服務器發送該報文段。 HTTP 服務器收到該報文段之後，生成 TCP SYN ACK 報文段，發回給主機。 連接建立之後，瀏覽器生成 HTTP GET 報文，並交付給 HTTP 服務器。 HTTP 服務器從 TCP 套接字讀取 HTTP GET 報文，生成一個 HTTP 響應報文，將 Web 頁面內容放入報文主體中，發回給主機。 瀏覽器收到 HTTP 響應報文後，抽取出 Web 頁面內容，之後進行渲染，顯示 Web 頁面。