快速過一遍計算機網絡

今天來總結一下面試中常常遇到的有關計算機網絡的面試題，主要有如下知識點：

• OSI與TCP/IP各層的結構與功能,都有哪些協議?
• TCP三次握手和四次揮手
• TCP和UDP協議的區別
• TCP協議如何保證可靠傳輸
• 在瀏覽器中輸入url地址到返回頁面這過程發生了什麼
• 各類協議與HTTP協議之間的關係
• HTTP長鏈接、短鏈接
• HTTP 1.0和HTTP 1.1的主要區別是什麼?
• URI和URL的區別是什麼?
• HTTP和HTTPS的區別

OSI與TCP/IP各層的結構與功能,都有哪些協議？

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

結合互聯網的狀況，自上而下地，很是簡要的介紹一下各層的做用。

應用層

應用層(application-layer）的任務是經過應用進程間的交互來完成特定網絡應用。在互聯網中應用層協議不少，如域名系統DNS，支持萬維網應用的HTTP協議等等。咱們把應用層交互的數據單元稱爲報文。

運輸層

運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通訊提供通用的數據傳輸服務。

運輸層主要使用如下兩種協議:

1. 傳輸控制協議 TCP（Transmission Control Protocol）--提供面向鏈接的，可靠的數據傳輸服務。
2. 用戶數據協議 UDP（User Datagram Protocol）--提供無鏈接的，盡最大努力的數據傳輸服務（不保證數據傳輸的可靠性）。

網絡層

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

數據鏈路層

數據鏈路層(data link layer)一般簡稱爲鏈路層。兩臺主機之間的數據傳輸，老是在一段一段的鏈路上傳送的，這就須要使用專門的鏈路層的協議。 在兩個相鄰節點之間傳送數據時，數據鏈路層將網絡層交下來的 IP 數據報組裝成幀，在兩個相鄰節點間的鏈路上傳送幀。

物理層

物理層(physical layer)的做用是實現相鄰計算機節點之間比特流的透明傳送，儘量屏蔽掉具體傳輸介質和物理設備的差別。

總結如下就是下面這張圖

TCP三次握手

爲了準確無誤地把數據送達目標處，TCP協議採用了三次握手策略。

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

爲何要三次握手

三次握手的目的是創建可靠的通訊信道，說到通信，簡單來講就是數據的發送與接收，而三次握手最主要的目的就是雙方確認本身與對方的發送與接收是正常的。

三次握手就能確認雙方收發功能都正常，缺一不可。

爲何TCP連接須要三次握手，兩次不能夠麼，爲何？

爲了防止已失效的連接請求報文忽然又傳送到了服務端，於是產生錯誤。

客戶端發出的鏈接請求報文並未丟失，而是在某個網絡節點長時間滯留了，以至延誤到鏈接釋放之後的某個時間纔到達Server。這時，Server誤覺得這是Client發出的一個新的鏈接請求，因而就向客戶端發送確認數據包，贊成創建鏈接。若不採用「三次握手」，那麼只要Server發出確認數據包，新的鏈接就創建了。因爲client此時並未發出創建鏈接的請求，因此其不會理睬Server的確認，也不與Server通訊；而這時Server一直在等待Client的請求，這樣Server就白白浪費了必定的資源。若採用「三次握手」，在這種狀況下，因爲Server端沒有收到來自客戶端的確認，則就會知道Client並無要求創建請求，就不會創建鏈接。

TCP四次揮手

斷開一個 TCP 鏈接則須要「四次揮手」：

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

爲何要四次揮手

任何一方均可以在數據傳送結束後發出鏈接釋放的通知，待對方確認後進入半關閉狀態。當另外一方也沒有數據再發送的時候，則發出鏈接釋放通知，對方確認後就徹底關閉了TCP鏈接。

TCP和UDP協議的區別

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

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

TCP協議如何保證可靠傳輸

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

在瀏覽器中輸入url地址到返回頁面這過程發生了什麼

各類協議與HTTP協議之間的關係

HTTP長鏈接、短鏈接

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

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

Connection:keep-alive

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

HTTP協議的長鏈接和短鏈接，實質上是TCP協議的長鏈接和短鏈接。

HTTP 1.0和HTTP 1.1的主要區別是什麼?

1. 長鏈接:在HTTP/1.0中，默認使用的是短鏈接，也就是說每次請求都要從新創建一次鏈接。HTTP 是基於TCP/IP協議的,每一次創建或者斷開鏈接都須要三次握手四次揮手的開銷，若是每次請求都要這樣的話，開銷會比較大。所以最好能維持一個長鏈接，能夠用個長鏈接來發多個請求。HTTP 1.1起，默認使用長鏈接,默認開啓Connection： keep-alive。HTTP/1.1的持續鏈接有非流水線方式和流水線方式。流水線方式是客戶在收到HTTP的響應報文以前就能接着發送新的請求報文。與之相對應的非流水線方式是客戶在收到前一個響應後才能發送下一個請求。
2. 錯誤狀態響應碼:在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
3. 緩存處理:在HTTP1.0中主要使用header裏的If-Modified-Since,Expires來作爲緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
4. 帶寬優化及網絡鏈接的使用:HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。

URI和URL的區別是什麼?

• URI(Uniform Resource Identifier) 是統一資源標誌符，能夠惟一標識一個資源。
• URL(Uniform Resource Location) 是統一資源定位符，能夠提供該資源的路徑。它是一種具體的 URI，即 URL 能夠用來標識一個資源，並且還指明瞭如何 locate 這個資源。

URI的做用像身份證號同樣，URL的做用更像家庭住址同樣。URL是一種具體的URI，它不只惟一標識資源，並且還提供了定位該資源的信息。

HTTP和HTTPS的區別

Http協議運行在TCP之上，明文傳輸，客戶端與服務器端都沒法驗證對方的身份；Https是身披SSL(Secure Socket Layer)外殼的Http，運行於SSL上，SSL運行於TCP之上，是添加了加密和認證機制的HTTP。兩者之間存在以下不一樣：

• 端口不一樣：Http與Http使用不一樣的鏈接方式，用的端口也不同，前者是80，後者是443；
• 資源消耗：和HTTP通訊相比，Https通訊會因爲加減密處理消耗更多的CPU和內存資源；
• 開銷：Https通訊須要證書，而證書通常須要向認證機構購買； 
  　 

Https的加密機制是一種共享密鑰加密和公開密鑰加密並用的混合加密機制。

參考

快速過一遍計算機網絡