計算機網絡作為程序員面試的基本題目，在回答面試官問題的時候不僅要抓住重點，還要回答出面試官的擴展問題。參考程序員（尤其是后端程序員）各大佬分享的面經驮俗，我們可以發(fā)現計算機網絡的考查點主要分布在應用層、傳輸層以及網絡層允跑，因此本文主要圍繞這三層中的協議進行總結王凑。
本文參考了大量的文章，形成了自己對計算機網絡常見重要知識點的理解聋丝，這也是我寫本文的初衷荤崇。如有表述不當之處，歡迎指正潮针。
1、網絡分層模型篇
1.1計算機網絡可以劃分成幾層倚喂，各層的作用是什么每篷。
計算機網絡的模型有三種：7層架構的OSI模型瓣戚，4層架構的TCP/IP模型，以及融合OSI模型與TCP/IP模型特點的網絡5層模型焦读。
經常使用的是5層模型子库，各層從上到下分別為應用層、傳輸層矗晃、網絡層仑嗅、數據鏈路層和物理層。
應用層：通過應用進程之間的傳輸報文
傳輸層：通過進程ID在進程之間的傳輸報文段
網絡層：通過IP地址在客戶端和服務端之間的傳輸IP數據報
數據鏈路層：通過MAC地址在兩個確定的物理主機之間傳輸數據幀
物理層：傳輸比特流
1.2URI與URL的區(qū)別
URI：統一資源標志符张症，用于唯一標識一個網絡資源
URL：同一資源定位符仓技，標識一個資源的訪問路徑
1.3在瀏覽器中輸入URL到顯示網頁的過程
瀏覽器先去本機中查找URL對應的IP地址，如果沒有則發(fā)送DNS請求去DNS服務器中尋找對應的IP地址俗他，得到IP地址后進行TCP三次握手建立連接脖捻，連接建立完成后衷掷，瀏覽器向服務器發(fā)送http請求服球，服務器收到之后返回http響應逐样，瀏覽器收到之后就顯示出對應的資源頁面刹衫。
本題還可以從5層模型的角度去詳細解答蚯根，本文已經形成了一個大致的回答思路媒佣。
2粤铭、應用層篇
應用層承常考的協議有HTTP畏铆、HTTPS雷袋、DNS等，其他應用層協議有FTP及志、DHCP等片排。
2.1HTTP0.9、HTPP1.0速侈、HTTP1.1與HTTP2.0的發(fā)展歷程
HTTP0.9：
只有get請求
服務端只能返回html頁面
請求處理完畢就自動釋放TCP連接
HTTP1.0：
新增了POST率寡、PUT等請求方式
支持圖片、視頻倚搬、文字等富文本傳輸
新增了緩存功能冶共，HTTP請求先進入緩存中再依次被服務端響應
新增了HTTP header、狀態(tài)碼等功能
仍然是請求處理完畢就自動釋放TCP連接
HTTP1.1：
增加了多種緩存機制
增加了狀態(tài)碼與請求方式
在header中引入rang域每界，支持只請求某資源的一部分捅僵，這樣便于充分利用帶寬和連接。
新增了connection: keep-alive眨层，支持一個TCP連接處理多個HTTP請求庙楚，當要關閉TCP連接時，客戶端向服務端發(fā)送一個connection: close即可趴樱。同一個域上長連接維持的請求個數是有限制的馒闷。
請求無法并行發(fā)送酪捡，由于HTTP是一種無狀態(tài)協議，它無法知道某一個響應究竟對應了哪一個請求纳账，因此建立了長連接之后必須要等待上一個請求的響應結束才能發(fā)送一個新的請求（不能無序傳輸）逛薇。解決方法：HTTP請求有序傳輸，但是可能會造成首行阻塞（第一個HTTP請求響應時間過長的話就會將后面的請求阻塞资璩妗）可能引起緩存溢出永罚。
HTTP2.0:
二進制傳輸數據。在1.X時header中采用文本傳輸卧秘，body中采用文本或二進制傳輸呢袱，為了更好的擴展性和提高性能，2.0中全部采用二進制傳輸斯议。
多路復用产捞，搭配數據流真正實現了請求和響應并行發(fā)送
頭部壓縮，客戶端和服務端分別維護一張表哼御，實現已經發(fā)送過的頭部信息不用再次發(fā)送
服務端主動推送坯临，服務器收到請求后可以將與請求相關的響應資源發(fā)給瀏覽器，減少了HTTP通信的次數恋昼。只對第一次訪問網站的用戶開啟服務器推送看靠，以避免本地緩存中已經存在引起帶寬浪費。
數據流（幀）液肌，可以標記請求與響應之間的對應關系挟炬，因此可以無序傳輸
2.3HTTP中get請求與post請求的區(qū)別
get請求會將請求參數直接添加到URL的后面，對用戶直接可見嗦哆；而post請求是將參數放到請求體中谤祖。瀏覽器一般會限制URL的長度，因此可能會對get請求造成影響老速。
get請求會被瀏覽器主動緩存粥喜，而post不會
get請求是發(fā)送一個TCP數據包，而post請求是將header和body分別當成一個tcp數據包發(fā)送橘券。
擴展問題：put請求與post請求的區(qū)別
使用put請求额湘，在遇到兩個相同的請求時（兩次發(fā)送的是同一個請求），后一個請求會把前一個請求覆蓋掉旁舰；而使用post時不會進行覆蓋锋华。
2.4Cookie、Session箭窜、Token毯焕、JWT的區(qū)別
Cookie由服務器生成，發(fā)送給瀏覽器磺樱，瀏覽器把Cookie以K-V的形式保存到某個目錄下的文本文件內纳猫，cookie中可以包含用戶訪問網站的身份信息等紧阔，下一次請求同一網站時會把cookie附加到header中發(fā)送給服務器，服務器拿到cookie之后就會直接給瀏覽器返回身份驗證之后的網頁续担。
Session，在用戶第一次訪問服務器時活孩，服務器就使用session把用戶信息臨時保存在了服務器上物遇，并給瀏覽器返回一個sessionID，瀏覽器拿到這個sessionID后憾儒，會將一個鍵值（tomcat中默認是"JSESSIONID"）與這個sessionID值封裝成cookie的鍵值對（這是保存在瀏覽器的臨時內存中的询兴，而非硬盤），當用戶再次發(fā)送一個請求時會將這個cookie附帶在header中起趾，服務器通過提取cookie中的sessionID進行比對就能知道這個用戶是不是同一個用戶诗舰。服務器session超時或者用戶離開網站后session會被銷毀（如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候session會丟失）（如果瀏覽器禁用了cookie训裆，則可以通過重寫URL來使用session）
Token眶根，用戶第一次訪問服務器時，服務器會將用戶信息做成不重復的字符串作為token边琉，并將它返回給瀏覽器属百，服務器也會保留一份到redis中，瀏覽器拿到token后將它保存到本地变姨，下一次訪問服務器時再header中攜帶上token族扰，服務器拿到token之后，就去redis中查找是否存在這個token定欧，如果存在則身份驗證成功渔呵，用戶信息是保存在Token中的。
JWT砍鸠，它由Token和數字簽名組成扩氢，用戶第一次訪問服務器時，服務器將用戶信息進行加密得到一個字符串token睦番，并將這個Token用公鑰進行加密得到一個數字簽名signature类茂，將Token和signature一起返回給瀏覽器，瀏覽器將它們保存到本地托嚣，再次訪問時就將他們附帶在請求報文中巩检，服務器接收到請求后用私鑰來解密這個Token，并將解密得到的簽名與請求報文中的數字簽名signature進行對比示启，如果有效則驗證成功兢哭。（加密Token使用到了非對稱加密）
Cookie與Session的區(qū)別
cookie是保存在客戶端中，而session是保存在服務器內存中的
單個cookie中保存的數據不能超過4kb夫嗓，而session可保存的數據遠高于cookie
cookie只支持字符串類型的數據迟螺，而session可以存任意類型的數據
cookie可以一直保存在客戶端中冲秽，而session是有有效期的
2.5HTTPS與HTTP的區(qū)別
HTTPS是基于SSL/TLS的HTTP協議，它通過對傳輸過程進行加密實現安全傳輸矩父，而HTTP是明文傳輸的锉桑，容易受到中間人攻擊。
HTTPS的默認端口是443窍株，HTTP的默認端口是80民轴。
2.6介紹非對稱加密與對稱加密
對稱加密：加密和解密都采用公鑰
非對稱加密：加密采用公鑰，解密采用私鑰
2.7HTTPS是怎么保證安全傳輸的
對稱加密算法適用于加密數據量偏大的內容球订，而非對稱加密算法適用于小數據量的內容后裸，所以使用對稱加密算法加密傳輸內容，并使用非對稱加密算法加密傳輸內容的秘鑰冒滩。
需要通過HTTPS訪問的進程所在的服務器中保存了由數字認證中心（CA）頒發(fā)的數字證書以及對應的私鑰微驶，數字證書中包含了公鑰和數字簽名簽名，如果數字簽名發(fā)生了改變就意味著證書遭到了篡改开睡。
加解密過程如下：
1）瀏覽器向服務器發(fā)送請求時因苹，服務器會給瀏覽器發(fā)送它的證書（私鑰是保存在服務器中的，不下發(fā)）士八。
2）瀏覽器拿到證書后容燕，進行驗證，驗證成功后就會用公鑰生成一個秘鑰X婚度，然后將秘鑰X發(fā)送給服務器蘸秘。
3）服務器拿到秘鑰X后，會用私鑰去解密傳過來的秘鑰X蝗茁，通信雙方都采用秘鑰X對傳輸內容進行加解密就實現了安全通信醋虏。
如果有中間人攻擊，由于中間人拿不到私鑰哮翘，就無法得到有公鑰生成的秘鑰X颈嚼，進而無法對傳輸內容進行解密。
這里可能存在的情況是如果證書不可信的話饭寺，仍然存在安全問題阻课。中間人拿到公鑰A后，把偽造的公鑰B傳給瀏覽器艰匙，瀏覽器生成一個秘鑰X限煞，中間人用公鑰B對應的私鑰來得到秘鑰X，再把秘鑰X用截取到的公鑰A加密并傳給服務器员凝。這樣中間人就得到了秘鑰X署驻，因此必要要驗證證書可信，在此不做贅述。
參考：https://zhuanlan.zhihu.com/p/43789231
2.8DNS的IP解析過程簡介
域名服務器按層級劃分為根域名服務器旺上、頂級域名服務器瓶蚂、權限域名服務器。
在瀏覽器中輸入域名后宣吱，客戶端會先去本地域名服務器中尋找對應的IP地址窃这，如果本地域名服務器中沒有，則依次去根域名服務器征候、頂級域名服務器钦听、權限域名服務器中尋找。
或者委托上層域名服務器去下層域名服務器中尋找倍奢，找到之后再依次返回到客戶端。
2.8DHCP的作用
IP地址可以劃分為動態(tài)IP和靜態(tài)IP垒棋，對于具有特定功能的服務器而言常采用靜態(tài)IP卒煞，即IP地址固定不變，通常情況下網絡設備都是動態(tài)IP地址叼架。
DHCP服務器就是用來為進入對應網段的網絡設備分配動態(tài)IP的畔裕，他采用的DHCP協議是一種基于UDP的應用層協議。
3乖订、傳輸層篇
3.1UDP與TCP的區(qū)別
| 是否面向連接 | 是否可靠 | 傳輸形式 | 適用場景 | |
|---|---|---|---|---|
| TCP | 面向連接（一對一） | 可靠 | 面向字節(jié)流 | 有可靠性要求的場景扮饶，如文件傳輸 |
| UDP | 無連接（一對多，多對多乍构，一對一） | 不可靠 | 面向報文 | 實時通信的場景甜无，如視頻會議、直播等 |
是否面向連接：在發(fā)送數據前是否要先建立連接哥遮，TCP在數據傳輸前要進行三次握手岂丘，而UDP沒有，即采用UDP通信的發(fā)送方會向接收方發(fā)送數據眠饮，即使發(fā)送方發(fā)送的數據發(fā)生了丟失也沒有關系奥帘。
是否可靠：是否會發(fā)生數據丟失現象。UDP是沒有流量控制的仪召，當接收方緩存區(qū)已經滿了寨蹋，而發(fā)送方還要繼續(xù)發(fā)送數據的話，就會造成數據丟失扔茅。
傳輸形式：TCP是將應用層報文劃分成報文段進行傳輸已旧，接收方會按照編號對報文段進行排序，而UDP是直接傳輸整個報文咖摹。
3.2TCP三次握手及狀態(tài)
在客戶端與服務端建立連接之前评姨，服務端一直處于LISTENING狀態(tài)，監(jiān)聽TCP連接請求。
第一次握手：客戶端向服務端發(fā)送一個SYN尋求建立連接吐句，發(fā)送之后客戶端處于SYN_SENT狀態(tài)胁后。
第二次握手：服務端收到SYN后，向客戶端發(fā)送ACK（確認建立連接）和SYN（連接請求）嗦枢，發(fā)送之后攀芯，服務端處于SYN_RECV狀態(tài)。第二次握手之后服務器為TCP分配資源（單向連接已完成）文虏。
第三次握手：客戶端收到服務端發(fā)送過來的SYN和ACK后侣诺，向服務端發(fā)送一個ACK，此時客戶端狀態(tài)變?yōu)镋STABLISHED氧秘。服務端沒有收到客戶端返回的ACK的話服務端就繼續(xù)向服務端發(fā)送SYN和ACK年鸳，直到服務端收到了ACK，服務端的狀態(tài)才變?yōu)镋STABLISHED丸相。第三次握手完成之后客戶端為TCP分配資源搔确。
3.3SYN攻擊及解決方法
SYN攻擊：攻擊人用偽造的IP地址給服務端發(fā)送一個SYN，服務端收到之后返回一個SYN和ACK灭忠，并為TCP連接分配資源膳算，但是在第三次握手中由于IP地址都是偽造的客戶端根本就返回不了ACK，使得TCP處于半連接狀態(tài)弛作，服務端收不到客戶端發(fā)送的ACK還會繼續(xù)向客戶端發(fā)送SYN和ACK涕蜂。如果這種半連接的狀態(tài)過多，就會造成很大的資源浪費映琳。
SYN解決方法：在服務器端監(jiān)控處于半連接的TCP机隙，超過一定時間后直接釋放資源∪鳎或者當TCP三次握手完成后才為服務器端分配資源（SYN Cookie和SYN Cache）
3.4TCP四次揮手及狀態(tài)
（以客戶端首先先服務端發(fā)出關閉連接的請求為例）
第一次揮手：客戶端發(fā)送一個FIN給服務端黍瞧，客戶端進入FIN_WAIT_1狀態(tài)
第二次揮手：服務端收到FIN之后發(fā)送一個ACK給客戶端，服務端進入CLOSE_WAIT狀態(tài)原杂，客戶端接收到ACK后進入FIN_WAIT_2狀態(tài)印颤。（半關閉狀態(tài)）
第三次揮手：服務端發(fā)送一個FIN給客戶端請求關閉連接，服務端進入LAST_ACK狀態(tài)穿肄。
第四次揮手：客戶端收到FIN后年局，給服務端返回一個ACK，客戶端進入TIME_WAIT狀態(tài)咸产。服務端接收到ACK后進入CLOSED狀態(tài)矢否，TIME_WAIT結束后客戶端也進入CLOSED狀態(tài)（如果服務端重新給客戶端發(fā)送了FIN，客戶端收到后會重新進入TIME_WAIT狀態(tài)）
3.5最后一次揮手后為什么要等待2MSL之后主動關閉方才釋放資源
MSL指報文在網絡內的最大生存時間脑溢，超過這個時間網絡中的報文將被丟棄僵朗。
第四次揮手中如果客戶端向服務端發(fā)送的ACK丟失了赖欣，超過一定時間后服務端還是收不到ACK就會重新向客戶端發(fā)送FIN，如果此時客戶端已經釋放了資源那么就無法給服務端返回ACK了验庙，因此客戶端要等待一定時間后才釋放資源顶吮。
第四次揮手中如果客戶端向服務端發(fā)送的ACK丟失了，超過一定時間后服務端還是收不到ACK就會重新向客戶端發(fā)送FIN粪薛，如果此時客戶端已經釋放了資源那么就無法給服務端返回ACK了悴了，因此客戶端要等待一定時間后才釋放資源。
2MSL是第四次揮手中ACK從客戶端到達服務端违寿，然后第三次揮手中FIN從服務端到達客戶端的最大時間湃交。
3.6TCP是怎么保證可靠傳輸的
TCP是一種可靠的傳輸層協議，它主要通過四個方面來保證可靠傳輸：校驗和藤巢、序號搞莺、確認、重傳掂咒。
校驗和：計算首部校驗和是否相同以判斷報文段是否發(fā)生了變動腮敌，由發(fā)送端計算然后接收端驗證，如果驗證不同則直接丟棄該報文段俏扩。
序號seq：用于標識報文段的編號
確認號ack：接收方接收到報文段之后會返回一個確認號ack=seq+1,發(fā)送方收到ack后就可以把ack之前的報文段從發(fā)送緩存窗口中刪除。發(fā)送方接收到的ack說明接收方已經接收到了ack之前的所有數據弊添。
TCP采用累積確認機制录淡，發(fā)送方發(fā)送報文段的時候不必等到上一個報文段的確認號收到之后才發(fā)送，即可以連續(xù)發(fā)送油坝。如果接收方沒有接收到某一個報文段嫉戚，就返回該報文段的ack，這個ack是從第一個報文段開始沒有被接收到的報文段的ack澈圈。
重傳機制：超時重傳彬檀，如果發(fā)送方超過一定時間還沒有接收到接收方的確認就重新發(fā)送該報文段，TCP采用自適應算法動態(tài)改變重傳時間RTTS（加權平均往返時間）瞬女。快速重傳窍帝，在超時時間之前就重傳的機載（冗余ack），發(fā)送方如果收到了3個冗余的ack就重新發(fā)送該ack對應的報文段诽偷。
參考資料：https://www.bilibili.com/video/BV19E411D78Q?p=67&spm_id_from=pageDriver
3.7TCP是怎么實現流量控制的
TCP采用滑動窗口實現流量控制坤学，接收方根據自己接收緩存的大小動態(tài)調整發(fā)送方的發(fā)送窗口大小，當接收方向發(fā)送方發(fā)送確認信息時同時也會將一個窗口值rwnd返回給發(fā)送方报慕，發(fā)送方就會根據這個返回的窗口值調整發(fā)送窗口的大小深浮。如果收到的rwnd為0則說明發(fā)送方停止發(fā)送數據。
可以將rwnd的值理解成接收方返回確認報文時接收緩存的剩余大小眠冈。
擴展問題：發(fā)送方收到的rwnd為0后飞苇，接收方再次給發(fā)送方發(fā)送了一個rwnd不為0的確認報文，如果這個確認報文丟失了就可能導致類似與死鎖的情況，解決方法如下：
當rwnd為0時布卡，發(fā)送方會設定一個計時器雨让，當計時器值減小到0時則給接收方發(fā)送一個探測報文，然后判斷返回報文中rwnd是否還是0羽利，如果是0則刷新計時器重新計時宫患，如果不是0則按照當前窗口的大小發(fā)送報文段。
參考資料：https://www.cnblogs.com/kubidemanong/p/9987810.html
3.8TCP是怎么實現擁塞控制的
擁塞控制不同于流量控制的是擁塞控制是全局性的控制这弧，防止過多的數據注入到網絡中引入網絡堵塞娃闲，而流量控制是點到點的問題，是指發(fā)送方發(fā)送過快而接收方來不及接收導致丟包匾浪。
擁塞控制通過四種算法來實現：慢開始和擁塞避免皇帮、快重傳和快恢復
慢開始和擁塞避免：慢開始階段，擁塞窗口從1開始隨著傳輸輪次呈指數規(guī)律增長蛋辈，直到增長到了慢開始門限值就進入到擁塞避免階段属拾，呈加法增大，直到出現了網絡擁塞冷溶，重新進入慢開始階段渐白，同時更新慢開始門限為網絡擁塞時窗口大小的一半。
快重傳和快恢復：收到3個冗余的ack時就執(zhí)行快重傳算法逞频。執(zhí)行步驟仍然為慢開始階段纯衍、擁塞避免階段，不同的是產生網絡擁塞時窗口大小降低為新的慢開始門限值（擁塞時窗口大小的一半）苗胀。
什么時候更改擁塞窗口：發(fā)送方只要收到了確認ACK報文就更新擁塞窗口大小襟诸。值得注意的是發(fā)送方的發(fā)送窗口大小取決于接收窗口與擁塞窗口大小中的最小值。接收窗口是反映了接收方容量基协，而擁塞窗口反映了網絡當前的容量歌亲。
傳輸輪次：發(fā)送方發(fā)送一批擁塞窗口內的報文段直到開始發(fā)送下一批擁塞窗口內的報文段所經過的時間。
4澜驮、網絡層篇
4.1數據交換方式
網絡層的數據交換方式可以分為電路交換陷揪、報文交換和分組交換，以太網技術的數據交換方式就是分組交換杂穷。
這里重點介紹分組交換鹅龄，其他的數據交換方式暫且不論。
分組交換是將傳輸層的報文段劃分成IP數據報（分組）亭畜，每個分組包含了數據部分與IP首部扮休，首部中就包含了源IP地址與目的IP地址。分組交換與報文交換（傳輸整個報文段）都采用了存儲轉發(fā)技術拴鸵，每個分組在路由器節(jié)點中按照轉發(fā)表選擇下一跳節(jié)點玷坠。
4.2介紹常見的路由協議及其作用
因特網中使用的是分層次的路由選擇協議蜗搔，將路由選擇協議分成內部網關協議IGP（一個AS內使用的）和外部網關協議EGP（AS之間使用的）。AS是指一個自治系統八堡。
路由算法：路由器在使用路由協議時會根據路由算法選擇出最佳路由（相對某一種特殊情況來說是最佳的）樟凄，并將它填入路由表中。常說的路由算法都是指自適應路由算法兄渺，路由器之間可以彼此交換信息缝龄，并按照路由算法來動態(tài)優(yōu)化路由表項。
一種常用的內部網關協議IGP是OSPF和RIP挂谍，一種常用的外部網關協議EGP是BGP叔壤。
4.3介紹ARP協議
ARP協議是通過接收端IP地址得到接收端MAC地址，這個MAC地址將被添加到數據鏈路層的數據幀中口叙。
數據鏈路層中封裝數據幀時會先從ARP高速緩存中尋找該IP地址是否有對應的MAC地址炼绘，有的話就可以直接使用，沒有的話就使用ARP協議去獲得對應的MAC地址妄田。發(fā)送端會向網絡中廣播信息要獲取某個IP地址主機的MAC地址俺亮，對應主機收到該廣播信息后就向發(fā)送端返回自己的MAC地址和IP地址，如果該主機不和發(fā)送端在同一個網段內疟呐，則返回默認網關的MAC地址和IP地址脚曾，并將這個默認網關作為數據傳輸的下一個節(jié)點。
4.4介紹ICMP協議
ICMP協議是網絡控制報文協議启具，主要用于當路由器接收到的IP數據報數據部分（而校驗和是針對IP首部的）發(fā)生錯誤時向主機返回差錯報告報文本讥，比如終點不可達報文，時間超過報文（IP數據報的生存時間TTL為0）富纸，改變路由報文等。
ICMP另一種報文是詢問報文旨椒，主機或路由器向特定的主機發(fā)出詢問晓褪，收到此報文的主機必須返回ICMP回送回答報文。這種報文主要用來測試目的主機是否可達并了解其相關的狀態(tài)综慎。Ping命令就是基于ICMP詢問報文實現的涣仿。
4.5介紹ping命令的過程
（這個過程是在網絡層及以下進行的）
先封裝一個ICMP請求數據報文
在ICMP報文的基礎上添加IP地址封裝成IP數據報
在ARP高速緩存中獲取目的主機的MAC地址或者使用ARP協議獲取MAC地址
獲得MAC地址構建一個數據幀，并將數據發(fā)送出去
目的主機接收到數據幀后示惊，從中提取出IP數據報好港，再將IP數據報中的ICMP請求報文交給ICMP協議處理并構建出一個ICMP應答報文，再返回給源主機米罚。
參考資料：https://blog.csdn.net/guoweimelon/article/details/50859658
