計算機網絡面試核心梳理

計算機網絡是互聯網企業研發崗面試的基礎，本人針對一些面試經驗和網絡上的資料對本部分內容進行了複習和簡單的梳理，希望對大家有幫助。

1. OSI參考模型與TCP/IP參考模型

OSI（Open System Interconnection）參考模型是國際標準化組織（ISO）制定的一個用於計算機或通信系統間互聯的標準體系，一般稱爲OSI參考模型或七層模型。

TCP/IP參考模型是計算機網絡的祖父ARPANET和其後繼的因特網使用的參考模型。

二者的對應關係、每層功能和協議族如下表所示：

OSI七層模型	TCP/IP模型	功能	TCP/IP協議族
應用層	應用層	直接向用戶提供服務，完成用戶希望完成的各種網絡操作	HTTP，FTP，TFTP，DNS，Telnet，SMTP
表示層		進行數據編解碼，數據加解密和格式轉換	沒有協議
會話層		解除或建立與別的節點的聯繫，組織和協調兩個會話進程之間的通信，並對數據交換進行管理	沒有協議
傳輸層	傳輸層	向兩臺主機中進程之間的通信提供通用的數據傳輸服務，實現端到端連接	TCP，UDP
網絡層	網絡層	爲分組交換網上的不同主機提供通信服務，也就是進行IP選址和路由選擇	IP，ICMP，RIP，IGMP
數據鏈路層	數據鏈路層	在物理層提供的比特流基礎上，通過差錯控制、流量控制的方法，將由差錯的物理線路變爲無差錯的、能可靠傳輸數據幀的數據鏈路	SLIP，CSLIP，PPP，ARP，RARP，
物理層	物理層	利用傳輸介質爲數據鏈路層提供物理連接，實現相鄰計算機節點之間比特流的透明傳輸	IEEE802.1 A，IEEE802.2到IEEE802.11

說明：有時爲了方便，也可以把TCP/IP模型中最下面兩層成爲網絡接口層。

2. TCP的三次握手

2.1 傳輸控制協議TCP簡介：

面向連接的、可靠的、基於字節流的傳輸層通信協議
將應用層的數據流分割成報文段併發送給目標節點的TCP層
數據包有序號，對方收到則發送ACK確認，未收到則重傳
使用校驗和來檢驗數據在傳輸過程中是否有誤

2.2 TCP報文頭：

TCP Flags：

URG：緊急指針標誌

ACK：確認序號標誌

PSH：push標誌

RST：重置連接標誌

SYN：同步序號，用戶建立連接過程

FIN：finish標誌，用於釋放連接

2.3 三次握手

“握手”是爲了建立連接，TCP三次握手的流程圖：

第一次握手：建立連接時，客戶端發送SYN包（syn=x）到服務器，並進入SYN_SEND狀態，等待服務器確認；

第二次握手：服務器收到SYN包，必須確認客戶的SYN（ack=x+1），同時自己發送一個SYN包（syn=y），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

第三次握手：客戶端接收到服務器的SYN+ACK包，向服務器發送確認包ACK（ack=y+1），此包發送完畢，客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

3. TCP的四次揮手

3.1 四次揮手的過程

“揮手”是爲了終止連接，TCP四次揮手流程圖：

第一次揮手：Client發送一個FIN，用來關閉Client到Server的數據傳輸，Client進入FIN_WAIT_1；

第二次揮手：Server收到FIN後，發送一個ACK給Client，確認序號爲收到序號+1，Server進入CLOSE_WAIT狀態；

第三次揮手：Server發送一個FIN，用來關閉Server到Client的數據傳輸，Server進入LAST_ACK狀態；

第四次揮手：Client收到FIN後，Client進入TIME_WAIT狀態，接着發送一個ACK給Server，確認序號爲收到序號+1，Server進入CLOSED狀態，完成四次揮手。

3.2 爲什麼會有TIME_WAIT狀態？

確保有足夠的時間讓對方收到ACK包。如果服務端沒有收到，到達等待時間會請求客戶端重新發送，如果客戶端在2MSL中沒有收到消息，證明客戶端已經收到了斷開連接的確認信息，這時可以關閉客戶端了。

3.3 爲什麼需要四次揮手才能斷開連接？

因爲全雙工，發送方和接收方都需要FIN和ACK報文才會斷開連接。

4. TCP和UDP的區別

4.1 UDP特點

面向非連接
不維護連接狀態，支持同時向多個客戶端傳輸相同的消息
數據包報頭只有8個字節，額外開銷較小
吞吐量值受限於數據生成速率、傳輸速率以及機器性能
盡最大努力，不保證可靠交付，不需要維持複雜的連接狀態表

4.2 TCP和UDP區別：

	TCP	UDP
連接	面向連接	面向無連接
可靠性	可靠，無差錯，不丟失，不重複	不保證可靠
速度	慢	快
量級	重	輕

5. HTTP詳解

5.1 協議簡介

HTTP（HyperText Transfer Protocol）超文本傳輸協議，是TCP/IP協議集中的一個應用層協議，用於定義瀏覽器和Web服務器之間交換數據的過程以及數據本身的格式。HTTP 1.0的會話方式：

這個過程是短暫的，始於瀏覽器發出請求，終於服務器返回結果，與瀏覽器窗口打開時間無關。

瀏覽器訪問一個包含許多圖像的網頁的時候，需要多次請求和響應。HTTP 1.0的時候，每次請求和響應都會建立一個單獨的連接，每次連接只傳輸一個文件，上一次和下一次請求完全分離，導致需要建立多次連接，建立連接是一個費時的過程，嚴重影響了客戶機和服務器的性能。

HTTP 1.1支持持久連接，在一個TCP連接上可以傳送多個請求和響應，減少建立連接和關閉連接的消耗和延時。類似於Redis的Pipeline功能，建立一次連接，執行多條命令。如下圖所示：

HTTP 1.1增加請求頭來實現實現持續連接，例如Host、Connection

Connection:keep-alive：客戶端通知服務器返回本次請求結果後保持連接
Connection:close：客戶端通知服務器返回本次請求結果後關閉連接

5.2 HTTP主要特點

支持客戶機/服務器模式
簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不同。由於HTTP協議簡單，使得HTTP服務器的程序規模小，因而通信速度很快。
靈活：HTTP允許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。
無連接：無連接的含義是限制每次連接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開連接。採用這種方式可以節省傳輸時間。
無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味着如果後續處理需要前面的信息，則它必須重傳，這樣可能導致每次連接傳送的數據量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

5.3 請求/響應的步驟

客戶端連接web服務器
發送HTTP請求
服務器接受請求並返回HTTP響應
釋放連接TCP連接
客戶端瀏覽器解析HTML內容

5.4 在瀏覽器地址欄鍵入url，按下回車之後經歷的流程

DNS解析瀏覽器緩存-系統緩存-路由器緩存IPS
TCP連接（三次握手）
發送HTTP請求
服務器處理請求返回HTTP報文
瀏覽器解析渲染頁面
連接結束

5.5 HTTP請求方式

GET方式：當使用GET方式提交表單內容的時候，瀏覽器將各個表單自斷元素及其數據按照URL參數的格式附加在請求行中的資源路徑後面。使用GET方式傳送的數據量是有限制的，一般限制在1KB一下。表單提交的時候默認是GET方式。

POST方式：當使用POST方式提交表單的時候，瀏覽器將各表單元素及其數據作爲HTTP消息的實體內容發送給Web服務器，而不是作爲URL地址的參數傳遞。因此，使用POST方式傳送的數據量要比使用GET方式傳送的數據量大得多。使用POST方式傳遞數據時，必須設置Content-Type消息頭和Content-length消息頭。

5.6 Cookie和Session的區別

Cookie是由服務器發送給客戶端的特殊信息，以文本的形式存放在客戶端；客戶端再次請求的時候，會把Cookie回發；服務器收到後，會解析Cookie生成與客戶端相對應的內容

Session是服務器端的機制，在服務器上保存信息；解析客戶端請求並操作session id，按需保存狀態信息；

Session的實現方式：使用Cookie來實現；使用url會寫來實現

Cookie數據村凡在客戶的瀏覽器上，Session數據放在服務器上
Session相對於Cookie更安全
若考慮減輕服務器負擔，應當使用Cookie

5.7 HTTP狀態碼分類和常用狀態碼

HTTP狀態碼分類：

分類	分類描述
1**	信息，服務器收到請求，需要請求者繼續執行操作
2**	成功，操作被成功接收並處理
3**	重定向，需要進一步的操作以完成請求
4**	客戶端錯誤，請求包含語法錯誤或無法完成請求
5**	服務器錯誤，服務器在處理請求的過程中發生了錯誤

常見HTTP響應狀態碼：

請求收到，繼續處理：
            100      客戶端必須繼續發出請求
            101      客戶端要求服務器根據請求轉換HTTP協議版本
操作成功收到，分析，接受：
            200      交易成功
            201      提示知道新文件的URL
            202      接受和處理、但處理未完成
            203      返回信息不確定或不完整
            204      請求收到，但返回信息爲空
            205      服務器完成了請求，用戶代理必須復位當前已經瀏覽過的文件
            206      服務器已經完成了部分用戶的GET請求
重定向：
            300      請求的資源可在多處得到
            301      永久重定向，在Location響應首部的值仍爲當前URL(隱式重定向)
            302      臨時重定向，在Location響應首部的值仍爲新的URL(顯示重定向)
            303      建議客戶端訪問其他URL或訪問方式
            304      Not Modified 請求的資源沒有改變 可以繼續使用緩存
            305      請求的資源必須從服務器指定的地址得到
            306      前一版本HTTP中使用的代碼，現行版本中不再使用
            307      聲明請求的資源臨時性刪除
客戶端錯誤：
            400      錯誤請求，如語法錯誤
            401      未授權
               HTTP 401.1    未授權，登錄失敗
               HTTP 401.2    未授權，服務器配置問題導致登錄失敗
               HTTP 401.3    ACL  禁止訪問資源
               HTTP 401.4    未授權  授權被篩選器拒絕
               HTTP 401.5    未授權  ISAPI或CGI授權失敗
            402      保留有效ChargeTo頭響應
            403      禁止訪問
               HTTP 403.1    禁止訪問  禁止可執行訪問
               HTTP 403.2    禁止訪問  禁止讀訪問
               HTTP 403.3    禁止訪問  禁止寫訪問
               HTTP 403.4    禁止訪問  要求SSL
               HTTP 403.5    禁止訪問  要求SSL 128
               HTTP 403.6    禁止訪問  IP地址被拒絕
               HTTP 403.7    禁止訪問  要求客戶端證書
               HTTP 403.8    禁止訪問  禁止站點訪問
               HTTP 403.9    禁止訪問  連接的用戶過多
               HTTP 403.10   禁止訪問  配置無效
               HTTP 403.11   禁止訪問  密碼更改
               HTTP 403.12   禁止訪問  映射器拒絕訪問
               HTTP 403.13   禁止訪問  客戶端證書已被吊銷
               HTTP 403.15   禁止訪問  客戶端訪問許可過多
               HTTP 403.16   禁止訪問  客戶端證書不可信或者無效
               HTTP 403.17   禁止訪問  客戶端證書已經到期或者尚未生效
            404       沒有發現文件、查詢或URL
            405       用戶在Request-Line字段定義的方法不允許
            406       根據用戶發送的Accept拖，請求資源不可訪問
            407       類似401，用戶必須首先在代理服務器上得到授權
            408       客戶端沒有在用戶指定的餓時間內完成請求
            409       對當前資源狀態，請求不能完成
            410       服務器上不再有此資源且無進一步的參考地址
            411       服務器拒絕用戶定義的Content-Length屬性請求   
            412       一個或多個請求頭字段在當前請求中錯誤
            413       請求的資源大於服務器允許的大小
            414       請求的資源URL長於服務器允許的長度
            415       請求資源不支持請求項目格式
            416       請求中包含Range請求頭字段，在當前請求資源範圍內沒有range指示值，       請求也不包含If-Range請求頭字段
            417       服務器不滿足請求Expect頭字段指定的期望值，如果是代理服務器，可能是下一級服務器不能滿足請求長
服務器端錯誤:
            500 - 內部服務器錯誤
            HTTP 500.100 - 內部服務器錯誤
            HTTP 500-11 服務器關閉
            HTTP 500-12 應用程序重新啓動
            HTTP 500-13 - 服務器太忙
            HTTP 500-14 - 應用程序無效
            HTTP 500-15 - 不允許請求
            501 - 未實現
            502 - 網關錯誤
            503 - 服務不可用
            504 - 網關超時

5.8 HTTP信息頭

通用信息頭：

Cache-Control：①位於請求頭，用於通知位於客戶機和服務器之間的代理服務器如何使用已緩存的頁面（no-cache、no-store、max-age、max-stale、no-transform、only-if-cached……）；②位於響應頭，用於通知客戶端和代理服務器如何緩存該頁面（public、private、no-chche、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage……）
Connection：用於指定處理完本次請求/響應之後，客戶端和服務器之間是否還要繼續保持連接（Keep-Alive、close）
Date：用於表示HTTP消息產生的當前時間，必須是GMT格式。例如：date:Fri, 03 Aug 2018 09:35:08 GMT
Pragma：設置值只能固定爲no-cache
Trailer：對於放置在尾部的頭字段，需要使用Trailer字段說明。例如：Trailer:Date
Transfer-Encoding：目前的標準設置值只有chunked
Upgrade：允許客戶機指定他所支持並希望將當前協議切換到的通信協議
Via：用於指定HTTP消息所途徑的中介代理服務器名稱和所使用的協議，這個頭字段由代理服務器產生，每個代理服務器必須把它的信息追加到Via字段的最後，以反映HTTP消息途徑的多個代理服務器的順序
Warning：用於說明其他頭字段和狀態嗎不能說明的一些附加警告信息，例如，返回的實體內容可能已經過時。

請求頭：

Accept：用於指出客戶端程序（通常是瀏覽器）能夠處理的MIME（Multipurpose Internet Mail Extension，多用途Internet郵件擴展）類型
Accept-Charset：用於指出客戶端程序可以使用的字符集
Accept-Encoding：用於指定客戶機能夠解碼的數據編碼方式，通常是指某種壓縮方式
Accept-Language：用於指定客戶機期望服務器返回那個國家語言的文檔，可以指定多個，以逗號隔開。例如：

Accept:image/webp,image/apng,image/*,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:zh-CN,zh;q=0.9
Connection:keep-alive

Authorization：當客戶端訪問受口令保護的網頁文件時，web服務器要求客戶機使用Authorization請求頭來應答。
Expect：用於指定客戶機請求服務器採取的特殊行動
Form：用於指定請求發送者的Email地址
Host：用於指定資源所在的主機名和端口號，格式與資源的完整URL中的主機名和端口號部分一樣，如果端口號等於連接服務器時所使用的端口號，則可以省略。

Host:analytics.163.com

User-Agent：用於指定瀏覽器或者其他客戶端程序的類型和名稱，以便服務器針對不同類型的瀏覽器返回不同的內容
```
User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36
```
Referer：瀏覽器向服務器發出的請求，可能是直接在瀏覽器地址欄中輸入URL而發出，也可以是單擊另一個網頁上面的超鏈接而發出的。對於第二種情況，瀏覽器使用Referer頭字段指定發出請求的超鏈接源的URL。對於第一種情況，瀏覽器不應發送Referer請求頭。
```
Referer:http://mp.163.com/article/postpage/W3324714890220385556?wemediaId=W3324714890220385556
If-Modified-Since:Wed, 24 May 2017 14:07:32 Asia/Shanghai
If-None-Match:5b54f9bd1d3396a5bc687a18ce578363
```

響應頭：

HTTP/1.1 200 OK 
Server: nginx 
Date: Sun, 05 Aug 2018 01:43:41 GMT 
Content-Type: image/gif 
Content-Length: 43 
Connection: keep-alive 
Cache-Control: must-revalidate, no-cache, private 
Pragma: no-cache 
Last-Modified: Sat, 1 Jan 2000 00:00:00 GMT 
Expires: Sat, 1 Jan 2000 00:00:00 GMT 
X-Server-ID: S170
 
 
Accept-Ranges:bytes
Access-Control-Allow-Credentials:false
Access-Control-Allow-Methods:GET
Access-Control-Allow-Origin:*
Age:1
Cache-Control:max-age=5184000
cdn-ip:116.242.0.33
cdn-source:chinanetcenter
cdn-user-ip:14.131.25.108
Connection:keep-alive
Content-Encoding:gzip
Content-Type:application/font-woff
Date:Sun, 05 Aug 2018 01:35:06 GMT
Expires:Fri, 24 Aug 2018 11:17:12 GMT
Last-Modified:Mon, 19 Jan 2015 06:08:45 GMT
Transfer-Encoding:chunked
Vary:Accept-Encoding
X-Via:1.1 shuangxian186:1 (Cdn Cache Server V2.0), 1.1 hangkuan193:6 (Cdn Cache Server V2.0), 1.1 hkuan33:1 (Cdn Cache Server V2.0)
X_cache:HIT from bjzw-img-proxy3

Server：用於指定服務器軟件的產品名稱

Content-Type：用於告訴瀏覽器多接受的數據是那種格式的數據

Expires：用於指定當前文檔應該在什麼時候被認爲過期，瀏覽器到那個時候以後不能再繼續使用本地的緩存，而是在有需要的時候向服務器發出新的訪問請求

6. HTTP和HTTPS的區別

6.1 HTTPS簡介

HTTPS（全稱：Hyper Text Transfer Protocol over Secure Socket Layer 或 Hypertext Transfer Protocol Secure，超文本傳輸安全協議），是以安全爲目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。

SSL（Security Socket Layer，安全套階層）

爲網絡通信提供安全及數據完整性的一種安全協議
是操作系統對外的API，SSL3.0後更名爲TLS
採用身份驗證和數據加密保證網絡通信的安全和數據的安全性

加密的方式

對稱加密：加密和解密都使用同一個祕鑰

非對稱加密：加密使用的祕鑰和解密使用的祕鑰是不相同的

哈希算法：將任意長度的信息轉換爲固定長度的值，算法不可逆

數字簽名：證明某個消息或者文件時從某人發出/認同的

6.2 HTTPS數據傳輸流程

瀏覽器鍵支持的加密算法信息發送給服務器
服務器選擇一套瀏覽器支持的算法加密，以證書的形式回發瀏覽器
瀏覽器驗證證書的合法性，並結合證書公鑰加密信息發送給服務器
服務器使用私鑰解密信息，驗證哈希，加密響應消息回發瀏覽器
瀏覽器解密響應信息，並對消息進行驗真，之後進行加密交互數據

6.3 HTTP和HTTPS的區別

HTTPS需要到CA申請證書，HTTP不需要
HTTPS密文傳輸，HTTP明文傳輸
連接方式不同，HTTPS默認使用443端口，HTTP使用80端口
HTTPS=HTTP+加密+認證+完整性保護，較HTTP安全

計算機網絡面試核心梳理

1. OSI參考模型與TCP/IP參考模型

2. TCP的三次握手

2.1 傳輸控制協議TCP簡介：

2.2 TCP報文頭：

2.3 三次握手

3. TCP的四次揮手

3.1 四次揮手的過程

3.2 爲什麼會有TIME_WAIT狀態？

3.3 爲什麼需要四次揮手才能斷開連接？

4. TCP和UDP的區別

4.1 UDP特點

4.2 TCP和UDP區別：

5. HTTP詳解

5.1 協議簡介

5.2 HTTP主要特點

5.3 請求/響應的步驟

5.4 在瀏覽器地址欄鍵入url，按下回車之後經歷的流程

5.5 HTTP請求方式

5.6 Cookie和Session的區別

5.7 HTTP狀態碼分類和常用狀態碼

5.8 HTTP信息頭

6. HTTP和HTTPS的區別

6.1 HTTPS簡介

6.2 HTTPS數據傳輸流程

6.3 HTTP和HTTPS的區別

【親測管用】解決IDEA控制檯Tomcat Localhost Log和Catalina Log亂碼

使用Host和Nginx把自定義域名映射到本地

計算機網絡面試核心梳理

我的2019——菜鳥互聯網找實習和工作記錄

Python網絡爬蟲——Appuim+夜神模擬器爬取得到APP課程數據

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結