《計算機網絡》：計算機網絡基礎常見面試問題大全

一切不可能，終將化爲尋常。
喜歡一我的就說喜歡，心存感恩就說謝謝；說反話並不會引發別人的關注，只會把人越推越遠。
本文已收入至個人 GitHub倉庫，歡迎Star： github.com/JavaKongHao,裏面也有我我的聯繫方式有什麼問題也能夠直接找我。

網絡通訊概要

一.操做系統基礎

操做系統:(Operating System，簡稱OS)是管理和控制計算機硬件與軟件資源的 計算機程序，是直接運行在「裸機」上的最基本的系統軟件，任何其餘軟件都必須在操做系統的支持下才能運行。

注：計算機(硬件)－>os－>應用軟件

二.網絡通訊原理

互聯網的本質就是一系列的網絡協議。互聯的概念，就像是兩個不一樣語種國家的人，讓他們溝通交流的就必須定義統一語言，在人類社會中英語就是這個做用。那麼在計算機中，天然也須要一種規範，網絡通訊協議就這麼誕生了。

網絡通訊協議：經過計算機網絡可使多臺計算機實現鏈接。通訊雙方必須同時遵照才能完成數據交換。

三.數據傳輸過程

網絡編程

1.軟件結構

C/S  （Client/Server），是指客戶端和服務器結構
B/S  （Browser/Serve），是指瀏覽器和服務器結構
複製代碼

兩種架構各有優點，但不管那種架構，都離不開網絡的支持。

2.網絡編程三要素

一、 通訊協議:計算機網絡通訊必須遵照的規則。

1.UDP協議：面向無鏈接、效率高、不保證數據完整

2.TCP協議：面向鏈接、效率低、保證數據完整
複製代碼

二、 IP地址：網絡中設備的惟一標識。（分類IPv4，IPv6） （獲取ip地址：命令臺鍵入ipconfig） 特殊IP地址：是回送地址，本機地址，通常用於測試

三、 端口號：軟件一打開，操做系統會爲網絡軟件分配一個端口號。 （普通應用程序使用1024以上的端口號） 使用IP地址加端口號，就能夠保證數據正確無誤的發送到對方計 算機的制定軟件了。

tips：2019年11月26日，全球全部43億個IPv4地址已分配完畢。
複製代碼

使用IP地址加端口號，就能夠保證數據正確無誤的發送到對方計算機的指定軟件了。

TCP/IP協議羣（簇/組）

1.應用層:應用程序間溝通的層，如簡單電子郵件傳輸(SMTP)、文件傳輸協議(FTP)、網絡遠程訪問協議(Telnet)等。

2.傳輸層:在此層中，它提供了節點間的數據傳送，應用程序之間的通訊服務，主要功能是數據格式化、數據確認和丟失重傳等。如傳輸控制協議(TCP)、用戶數據報協議(UDP)等，TCP和UDP給數據包加入傳輸數據並把它傳輸到下一層中，這一層負責傳送數據，而且肯定數據已被送達並接收。

3.網際層:負責提供基本的數據封包傳送功能，讓每一塊數據包都可以到達目的主機(但不檢查是否被正確接收)，如網際協議(IP)。

4.網絡接口層(主機-網絡層):接收IP數據報並進行傳輸，從網絡上接收物理幀，抽取IP數據報轉交給下一層，對實際的網絡媒體的管理，定義如何使用實際網絡(如Ethernet、Serial Line等)來傳送數據。

TCP/UDP

1.TCP/UDP協議概述

1.UDP協議：用戶數據報協議，面向無鏈接鏈接通訊協議，因爲使用UDP協議消耗資源小，通訊效率高，可能會出現數據丟失因此一般都會用於音頻、視頻和普通數據傳輸。（數據包限制在64Kb）

2.TCP協議：傳輸控制協議，面向鏈接的通訊協議。面向鏈接的特性，TCP協議能夠保證傳輸數據的安全，因此應用 十分普遍，例以下載文件、瀏覽網頁。

TCP鏈接

1.三次握手詳解

過程如圖所示：

最初客戶端和服務端都處於 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（已創建鏈接）狀態。

2.四次揮手詳解

第一次揮手：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。

爲何握手須要3次，揮手須要4次？

3次握手分析：

第一次握手：Client 什麼都不能確認；Server 確認了對方發送正常，本身接收正常

第二次握手：Client 確認了：本身發送、接收正常，對方發送、接收正常；Server 確認了：對方發送正常，本身接收正常

第三次握手：Client 確認了：本身發送、接收正常，對方發送、接收正常；Server 確認了：本身發送、接收正常，對方發送、接收正常

四次揮手分析：

第一次揮手：主機1（可使客戶端，也能夠是服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有數據要發送給主機2了

第二次揮手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我「贊成」你的關閉請求

第三次揮手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST_ACK狀態

第四次揮手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

第二次和第三次揮手能合併嗎?

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

TCP如何確保傳輸可靠

一、最優分配：應用數據被分割成TCP認爲最適合發送的數據塊。這和UDP徹底不一樣，應用程序產生的數據報長度將保持不變。

二、確認響應：當TCP收到發自TCP鏈接另外一端的數據，它將發送一個確認。其間可能由於對包校驗而產生延遲。

三、擁塞控制：當網絡擁塞時，減小數據的發送。

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

五、接收校驗： TCP將保持它首部和數據的檢驗和。這是一個端到端的檢驗和，目的是檢測數據在傳輸過程當中的任何變化。若是收到段的檢驗和有差錯，TCP將丟棄這個報文段和不確認收到此報文段。

六、失序重排：TCP報文段做爲IP數據報來傳輸，而IP數據報的到達可能會失序，所以TCP報文段的到達也可能會失序。若是必要，TCP將對收到的數據進行從新排序，將收到的數據以正確的順序交給應用層。

七、丟棄重複數據：既然IP數據報會發生重複，TCP的接收端必須丟棄重複的數據。

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

HTTP鏈接

HTTP協議即超文本傳送協議(Hypertext Transfer Protocol )，是Web聯網的基礎，也是手機聯網經常使用的協議之一，HTTP協議是創建在TCP協議之上的一種應用。

HTTP鏈接最顯著的特色:是客戶端發送的每次請求都須要服務器回送響應，在請求結束後，會主動釋放鏈接。從創建鏈接到關閉鏈接的過程稱爲「一次鏈接」。

1.短鏈接：在HTTP 1.0中，客戶端的每次請求都要求創建一次單獨的鏈接，在處理完本次請求後，就自動釋放鏈接。

2.長鏈接：在HTTP 1.1中則能夠在一次鏈接中處理多個請求，而且多個請求能夠重疊進行，不須要等待一個請求結束後再發送下一個請求。

tip:使用長鏈接的http會在響應頭加上 Connection: keep-alive 
複製代碼

因爲HTTP在每次請求結束後都會主動釋放鏈接，所以HTTP鏈接是一種「短鏈接」，要保持客戶端程序的在線狀態，須要不斷地向服務器發起鏈接請求。一般的作法是即時不須要得到任何數據，客戶端也保持每隔一段固定的時間向服務器發送一次「保持鏈接」的請求，服務器在收到該請求後對客戶端進行回覆，代表知道客戶端「在線」。若服務器長時間沒法收到客戶端的請求，則認爲客戶端「下線」，若客戶端長時間沒法收到服務器的回覆，則認爲網絡已經斷開。

響應狀態碼

1. 1xx：服務器就收客戶端消息，但沒有接受完成，等待一段時間後，
    發送1xx狀態碼
    2. 2xx：成功。
        * 200（成功）
    3. 3xx：重定向。
        * 302(重定向)，
        * 304(訪問緩存)
    4. 4xx：客戶端錯誤。
        * 404（請求路徑沒有對應的資源） 
        * 405：請求方式沒有對應的doXxx方法
    5. 5xx：服務器端錯誤
        * 500(服務器內部出現異常)
複製代碼

cookie和session

cookie
    1. cookie存儲數據在客戶端瀏覽器
    2. 瀏覽器對於單個cookie 的大小有限制(4kb) 以及 對同一個域名下的總cookie數量也有限制(20個)
    3. cookie通常用於存儲少許的不太敏感的數據(建議手動設個失效時間和path）
    4. 在不登陸的狀況下，完成服務器對客戶端的身份識別（建議作加密）

session
    1. session用於存儲一次會話的屢次請求的數據，存在服務器端
    2. session能夠存儲任意類型，任意大小的數據
    3. session做用範圍一次會話（屢次請求，從訪問這個網站開始  到關閉瀏覽器結束）

cookie和session區別：
    1. session存儲數據在服務器端，Cookie在客戶端
    2. session沒有數據大小限制，Cookie有
    3. session數據安全，Cookie相對於不安全
    4. Session是依賴於Cookie的
    5. Session是域對象，Cookie不是域對象
複製代碼

Http和Https的區別

1.https協議須要到CA申請證書，大多數狀況下須要必定費用
    2.Http是超文本傳輸協議，信息採用明文傳輸，Https則是具備安全性SSL加密傳輸協議
    3.Http和Https端口號不同，Http是80端口，Https是443端口
    4.Http鏈接是無狀態的，而Https採用Http+SSL構建可進行加密傳輸、身份認證的網絡協議，更安全。
    5.Http協議創建鏈接的過程比Https協議快。由於Https除了Tcp三次握手，還要通過SSL握手。鏈接創建以後數
      據傳輸速度，兩者無明顯區別。
複製代碼

Socket鏈接

socket（套接字）是通訊的基石，是支持TCP/IP協議的網絡通訊的基本操做單元。

Socket是應用層與TCP/IP協議族通訊的中間軟件抽象層，它是一組接口。在設計模式中，Socket其實就是一個門面模式，它把複雜的TCP/IP協議族隱藏在Socket接口後面，對用戶來講，一組簡單的接口就是所有，讓Socket去組織數據，以符合指定的協議。（簡單的理解：socket就是對下層的封裝，供上層更簡便的使用）

tips : 若是說Http協議是一輛車，那麼Socket就是發動機。

socket執行流程（來源網絡）：

在瀏覽器中輸入url地址 ->> 顯示主頁的過程

1.輸入url地址後，首先進行DNS解析，將相應的域名解析爲IP地址；

2.客戶端根據IP地址去尋找相應的服務器；

3.與服務器進行TCP的三次握手；

4.客戶端找到相應的資源庫；

5.根據資源庫返回頁面信息；

6.瀏覽器根據自身的執行機制解析頁面；（瀏覽器的執行機制？重繪？重排？......）瀏覽器解析頁面時，會找到每個文件夾（css、js、html、img......），每個文件夾下的資源會從新走到第二步，去找到相應的服務器，而後一步步執行。

7.最後服務器將解析信息返回給客戶端，進行TCP的四次揮手。

七種協議和Http的關係

圖片來源：《圖解HTTP》：

若是以爲有用，請點贊，由於你的鼓勵是我寫做的最大動力！

聯繫我/公衆號

空號 | 文 【原創】【轉載請聯繫本人】 若是本篇博客有任何錯誤，請批評指教，不勝感激 ！本文已收入至個人 GitHub倉庫，歡迎Star： github.com/JavaKongHao,裏面也有我我的聯繫方式有什麼問題也能夠直接找我。