面試：計算機網絡基礎詳解（一）

計算機網絡是計算機、軟工類面試的基礎，無論是軟件/硬件開發、技術支持仍是測試職位，都會涉及到計算機網絡的基礎知識，本文基於筆者以前的面試準備所作的相關知識整理。本文的主要內容：

• OSI 與 TCP/IP 模型
  • OSI 七層模型
  • OSI 的缺陷
  • TCP/IP 五層模型
• TCP 三次握手和四次揮手
  • TCP 創建鏈接
  • TCP三次握手，若是兩次握手會怎麼樣？
  • TCP 關閉鏈接
  • 爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？
  • 爲何須要 TIME_WAIT 狀態？
  • TCP 協議如何保證可靠傳輸
• HTTP 和 HTTPS
  • 基本概念
  • HTTPS 和 HTTP 的區別
  • HTTP 響應的狀態碼
  • HTTP 長鏈接、短鏈接

OSI 與 TCP/IP 模型

OSI 七層模型

OSI（Open System Interconnect），即開放式系統互聯。 通常都叫OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網絡互連模型。

OSI定義了網絡互連的七層框架（物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層），即ISO開放互連繫統參考模型。

從上到下介紹每層的功能：

1. 應用層：OSI參考模型中最靠近用戶的一層，是爲計算機用戶提供應用接口，也爲用戶直接提供各類網絡服務。咱們常見應用層的網絡服務協議有：HTTP，HTTPS，FTP，POP三、SMTP等。
2. 表示層：表示層提供各類用於應用層數據的編碼和轉換功能,確保一個系統的應用層發送的數據能被另外一個系統的應用層識別。若是必要，該層可提供一種標準表示形式，用於將計算機內部的多種數據格式轉換成通訊中採用的標準表示形式。數據壓縮和加密也是表示層可提供的轉換功能之一。
3. 會話層：負責創建、管理和終止表示層實體之間的通訊會話。該層的通訊由不一樣設備中的應用程序之間的服務請求和響應組成。
4. 傳輸層：傳輸層創建了主機端到端的連接，傳輸層的做用是爲上層協議提供端到端的可靠和透明的數據傳輸服務，包括處理差錯控制和流量控制等問題。該層向高層屏蔽了下層數據通訊的細節，使高層用戶看到的只是在兩個傳輸實體間的一條主機到主機的、可由用戶控制和設定的、可靠的數據通路。咱們一般說的，TCP UDP就是在這一層。端口號既是這裏的「端」。
5. 網絡層：本層經過IP尋址來創建兩個節點之間的鏈接，爲源端的運輸層送來的分組，選擇合適的路由和交換節點，正確無誤地按照地址傳送給目的端的運輸層。就是一般說的IP層。這一層就是咱們常常說的IP協議層。IP協議是Internet的基礎。
6. 數據鏈路層：將比特組合成字節,再將字節組合成幀,使用鏈路層地址 (以太網使用MAC地址)來訪問介質,並進行差錯檢測。數據鏈路層又分爲2個子層：邏輯鏈路控制子層（LLC）和媒體訪問控制子層（MAC）。
   • MAC子層處理CSMA/CD算法、數據出錯校驗、成幀等；
   • LLC子層定義了一些字段使上次協議能共享數據鏈路層。 在實際使用中，LLC子層並不是必需的。
7. 物理層
   實際最終信號的傳輸是經過物理層實現的。經過物理介質傳輸比特流。規定了電平、速度和電纜針腳。經常使用設備有（各類物理設備）集線器、中繼器、調制解調器、網線、雙絞線、同軸電纜。這些都是物理層的傳輸介質。

OSI 的缺陷

OSI的七層體系結構概念清楚，理論也很完整，可是它比較複雜並且不實用。在這裏順帶提一下以前一直被一些大公司甚至一些國家政府支持的OSI失敗的緣由：

• OSI的專家缺少實際經驗，他們在完成OSI標準時缺少商業驅動力
• OSI的協議實現起來過度複雜，並且運行效率很低
• OSI制定標準的週期太長，於是使得按OSI標準生產的設備沒法及時進入市場（20世紀90年代初期，雖然整套的OSI國際標準都已經制定出來，但基於TCP/IP的互聯網已經搶先在全球至關大的範圍成功運行了）
• OSI的層次劃分不太合理，有些功能在多個層次中重複出現

TCP/IP 五層模型

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

1. 應用層（application layer）
   應用層的任務是經過應用進程間的交互來完成特定網絡應用。應用層協議定義的是應用進程（進程：主機中正在運行的程序）間的通訊和交互的規則。對於不一樣的網絡應用須要不一樣的應用層協議。在互聯網中應用層協議不少，如域名系統DNS，支持萬維網應用的HTTP協議，支持電子郵件的SMTP協議等等。咱們把應用層交互的數據單元稱爲報文。
2. 運輸層（transport layer）
   運輸層的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。應用進程利用該服務傳送應用層報文。「通用的」是指並不針對某一個特定的網絡應用，而是多種應用可使用同一個運輸層服務。因爲一臺主機可同時運行多個線程，所以運輸層有複用和分用的功能。所謂複用就是指多個應用層進程可同時使用下面運輸層的服務，分用和複用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。 運輸層主要使用如下兩種協議：
   • 傳輸控制協議TCP（Transmisson Control Protocol）--提供面向鏈接的，可靠的數據傳輸服務。
   • 用戶數據協議UDP（User Datagram Protocol）--提供無鏈接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。
3. 網絡層（network layer）
   網絡層負責爲分組交換網上的不一樣主機提供通訊服務。在發送數據時，網絡層把運輸層產生的報文段或用戶數據報封裝成分組和包進行傳送。在TCP/IP體系結構中，因爲網絡層使用IP協議，所以分組也叫IP數據報，簡稱數據報。 這裏要注意：不要把運輸層的「用戶數據報UDP」和網絡層的「IP數據報」弄混。另外，不管是哪一層的數據單元，均可籠統地用「分組」來表示。 網絡層的另外一個任務就是選擇合適的路由，使源主機運輸層所傳下來的分株，能經過網絡層中的路由器找到目的主機。
   互聯網是由大量的異構（heterogeneous）網絡經過路由器（router）相互鏈接起來的。互聯網使用的網絡層協議是無鏈接的網際協議（Intert Prococol）和許多路由選擇協議，所以互聯網的網絡層也叫作網際層或IP層。
4. 數據鏈路層（data link layer）
   數據鏈路層一般簡稱爲鏈路層。兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的IP數據報組裝程幀，在兩個相鄰節點間的鏈路上傳送幀。每一幀包括數據和必要的控制信息（如同步信息，地址信息，差錯控制等）。 在接收數據時，控制信息使接收端可以知道一個幀從哪一個比特開始和到哪一個比特結束。這樣，數據鏈路層在收到一個幀後，就可從中提出數據部分，上交給網絡層。 控制信息還使接收端可以檢測到所收到的幀中有偏差錯。若是發現差錯，數據鏈路層就簡單地丟棄這個出了差錯的幀，以免繼續在網絡中傳送下去白白浪費網絡資源。若是須要改正數據在鏈路層傳輸時出現差錯（這就是說，數據鏈路層不只要檢錯，並且還要糾錯），那麼就要採用可靠性傳輸協議來糾正出現的差錯。這種方法會使鏈路層的協議複雜些。
5. 物理層（physical layer）
   在物理層上所傳送的數據單位是比特。物理層的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。使其上面的數據鏈路層沒必要考慮網絡的具體傳輸介質是什麼。「透明傳送比特流」表示經實際電路傳送後的比特流沒有發生變化，對傳送的比特流來講，這個電路好像是看不見的。
   在互聯網使用的各類協中最重要和最著名的就是TCP/IP兩個協議。如今人們常常提到的TCP/IP並不必定單指TCP和IP這兩個具體的協議，而每每表示互聯網所使用的整個TCP/IP協議族。

TCP 三次握手和四次揮手

TCP建立過程和連接折除過程是由 TCP/IP 協議棧自動建立的。所以開發者並不須要控制這個過程，可是對於理解TCP底層運做機制，至關有幫助。

TCP 創建鏈接

TCP 創建鏈接，即所謂三次握手(Three-way Handshake)，是指創建一個TCP鏈接時，須要客戶端和服務器總共發送3個包。具體過程以下：

• 客戶端發送帶有 SYN 標誌的數據包–-一次握手–服務端；
• 服務端發送帶有 SYN/ACK 標誌的數據包–-二次握手–客戶端；
• 客戶端發送帶有帶有 ACK 標誌的數據包–-三次握手–服務端。

TCP三次握手，若是兩次握手會怎麼樣？

若是是兩次握手，有這樣一種狀況，當 A 發送一個消息給 B，可是因爲網絡緣由，消息被阻塞在了某個節點，而後阻塞的時間超出設定的時間，A 會認爲這個消息丟失了，而後從新發送消息。當 A 和 B 通訊完成後，這個被A認爲失效的消息，到達了 B。

對於 B 而言，覺得這是一個新的請求連接消息，就向 A 發送確認。對於 A 而言，它認爲沒有給 B 再次發送消息（由於上次的通話已經結束）全部 A 不會理睬 B 的這個確認，可是 B 則會一直等待 A 的消息。這就致使了 B 的時間被浪費（對於服務器而言，CPU 等資源是一種浪費），這樣是不可行的，這就是爲何不能兩次握手的緣由了。

因此有了三次握手的修訂，第三次握手看似多餘其實否則，這主要是爲了防止已失效的請求報文段忽然又傳送到了服務端而產生鏈接的誤判。

TCP 關閉鏈接

TCP 鏈接的拆除須要發送四個包，所以稱爲四次揮手(four-way handshake)。客戶端或服務器都可主動發起揮手動做，在socket編程中，任何一方執行close()操做便可產生揮手操做。

• 客戶端發送一個 FIN，用來關閉客戶端到服務器的數據傳送；
• 服務器收到這個 FIN，它發回一個 ACK，確認序號爲收到的序號加 1。和 SYN 同樣，一個 FIN 將佔用一個序號；
• 服務器關閉與客戶端的鏈接，發送一個FIN給客戶端；
• 客戶端發回 ACK 報文確認，並將確認序號設置爲收到序號加 1。

爲何創建鏈接是三次握手，而關閉鏈接倒是四次揮手呢？

創建鏈接時，由於服務端在 LISTEN 狀態下，收到創建鏈接請求的 SYN 報文後，把 ACK 和 SYN 放在一個報文裏發送給客戶端。

關閉鏈接時，當收到對方的 FIN 報文時，僅表示對方再也不發送數據但還能接收收據，咱們也未必把所有數據都發給了對方，因此咱們能夠當即 close，也能夠發送一些數據給對方後，再發送 FIN 報文給對方表示贊成關閉鏈接。所以咱們的 ACK 和 FIN 通常會分開發送。

爲何須要 TIME_WAIT 狀態？

從TCP鏈接關閉的狀態轉換關係能夠看出，主動關閉的一方在發送完對對方 FIN 報文的確認(ACK)報文後，會進入 TIME_WAIT 狀態。TIME_WAIT 狀態也稱爲 2MSL 狀態。

什麼是2MSL？MSL 即 Maximum Segment Lifetime，也就是報文最大生存時間，引用《TCP/IP詳解》中的話：它(MSL)是任何報文段被丟棄前在網絡內的最長時間。那麼，2MSL 也就是這個時間的 2 倍。最後總結爲主動關閉的一方將繼續等待必定時間(2-4分鐘)，使兩端的應用程序結束。

爲何須要 TIME_WAIT 狀態：

1. 爲實現 TCP 這種全雙工鏈接的可靠釋放
   這樣可以讓 TCP 再次發送最後的 ACK 以防這個 ACK 丟失(另外一端超時並重發最後的 FIN)這種 2MSL 等待的另外一個結果是這個 TCP 鏈接在 2MSL 等待期間，定義這個鏈接的插口(客戶的 IP 地址和端口號，服務器的 IP 地址和端口號)不能再被使用。這個鏈接只能在 2MSL 結束後才能再被使用。
2. 爲使舊的數據包在網絡因過時而消失
   每一個具體 TCP 實現必須選擇一個報文段最大生存時間 MSL。它是任何報文段被丟棄前在網絡內的最長時間。

TIME_WAIT 狀態所帶來的影響：

當某個鏈接的一端處於 TIME_WAIT 狀態時，該鏈接將不能再被使用。事實上，對於咱們比較有現實意義的是，這個端口將不能再被使用。某個端口處於 TIME_WAIT 狀態(其實應該是這個鏈接)時，這意味着這個 TCP 鏈接並無斷開(徹底斷開)，那麼，若是你 bind 這個端口，就會失敗。對於服務器而言，若是服務器忽然 crash 掉了，那麼它將沒法再 2MSL 內從新啓動，由於 bind 會失敗。解決這個問題的一個方法就是設置 socket 的 SO_REUSEADDR 選項。這個選項意味着你能夠重用一個地址。

TCP 協議如何保證可靠傳輸

TCP協議保證數據傳輸可靠性的方式主要有：

1. 校驗和： TCP 將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程當中的任何變化。若是收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
2. 確認應答+序列號（累計確認+seq）。接收方收到報文就會確認（累積確認：對全部按序接收的數據的確認），TCP 給發送的每個包進行編號，接收方對數據包進行排序，把有序數據傳送給應用層。TCP 的接收端會丟棄重複的數據。
3. 流量控制： TCP 鏈接的每一方都有固定大小的緩衝空間，TCP的接收端只容許發送端發送接收端緩衝區能接納的數據。當接收方來不及處理髮送方的數據，能提示發送方下降發送的速率，防止包丟失。TCP 使用的流量控制協議是可變大小的滑動窗口協議。 （TCP 利用滑動窗口實現流量控制）
4. 擁塞控制： 當網絡擁塞時，減小數據的發送。
5. 中止等待協議 也是爲了實現可靠傳輸的，它的基本原理就是每發完一個分組就中止發送，等待對方確認。在收到確認後再發下一個分組。
6. 超時重傳： 當 TCP 發出一個段後，它啓動一個定時器，等待目的端確認收到這個報文段。若是不能及時收到一個確認，將重發這個報文段。

HTTP 和 HTTPS

基本概念

HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從 WWW 服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。

HTTPS：是以安全爲目標的 HTTP 通道，簡單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，所以加密的詳細內容就須要 SSL。 HTTPS協議的主要做用能夠分爲兩種：一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

HTTPS 和 HTTP 的區別

1. https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。
2. http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
3. http 和 https 使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是 80，後者是 443。
4. http 的鏈接很簡單，是無狀態的；HTTPS 協議是由 SSL + HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 http 協議安全。

HTTP 響應的狀態碼

做爲程序開發人員對於一些服務器返回的 HTTP 狀態的意思都應該瞭如指掌，只有將這些狀態碼一一弄清楚，工做中遇到的各類問題纔可以處理的駕輕就熟。因此下面就讓咱們來了解一下比較常見的 HTTP 狀態碼吧！

1. 1xx - 信息提示 這些狀態代碼表示臨時的響應。客戶端在收到常規響應以前，應準備接收一個或多個 1xx 響應。如：

   • 100：Continue 初始的請求已經接受，客戶應當繼續發送請求的其他部分。（HTTP 1.1新）
   • 101：Switching Protocols 服務器將聽從客戶的請求轉換到另一種協議（HTTP 1.1 新）

2. 2xx - 成功 這類狀態代碼代表服務器成功地接受了客戶端請求。

   • 200 - OK 一切正常，對GET和POST請求的應答文檔跟在後面。 - 201 - Created 服務器已經建立了文檔，Location頭給出了它的URL。
   • 202 - Accepted 已經接受請求，但處理還沒有完成。

3. 3xx - 重定向 客戶端瀏覽器必須採起更多操做來實現請求。例如，瀏覽器可能不得不請求服務器上的不一樣的頁面，或經過代理服務器重複該請求。如 304 Not Modified

4. 4xx - 客戶端錯誤 發生錯誤，客戶端彷佛有問題。例如，客戶端請求不存在的頁面，客戶端未提供有效的身份驗證信息。如：

   • 400 - Bad Request 請求出現語法錯誤。
   • 401 - Unauthorized 訪問被拒絕，客戶試圖未經受權訪問受密碼保護的頁面。

5. 5xx - 服務器錯誤 服務器因爲遇到錯誤而不能完成該請求。如：

   • 500 - Internal Server Error 服務器遇到了意料不到的狀況，不能完成客戶的請求。
   • 502 - Bad Gateway 服務器做爲網關或者代理時，爲了完成請求訪問下一個服務器，但該服務器返回了非法的應答。

HTTP 長鏈接、短鏈接

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

Connection:keep-alive
複製代碼

在使用長鏈接的狀況下，當一個網頁打開完成後，客戶端和服務器之間用於傳輸 HTTP數據的 TCP 鏈接不會關閉，客戶端再次訪問這個服務器時，會繼續使用這一條已經創建的鏈接。Keep-Alive 不會永久保持鏈接，它有一個保持時間，能夠在不一樣的服務器軟件（如 Apache）中設定這個時間。實現長鏈接須要客戶端和服務端都支持長鏈接。

訂閱最新文章，歡迎關注個人公衆號