計算機網絡面試核心知識點梳理

時間 2019-12-09

原文原文鏈接

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

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

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

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：重置鏈接標誌session

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，安全套階層）