在秋招過程中看了大量面經极阅，將常見的計算機網絡面試題總結如下虎韵，并按照面試中提問的頻率做了標注（星數越高疗涉，面試中提問頻率越高），如有幫到你吟秩，可以收藏點贊支持哦博敬。

微信搜索公眾號路人zhang，回復面試手冊峰尝，領取本文檔PDF版及更多面試資料。

推薦閱讀：

• 一文搞定所有Java基礎知識面試題
• 一文搞定所有Java集合面試題

什么是網絡協(xié)議收恢，為什么要對網絡協(xié)議分層∥溲А＊

網絡協(xié)議是計算機在通信過程中要遵循的一些約定好的規(guī)則。

網絡分層的原因：

• 易于實現和維護伦意，因為各層之間是獨立的火窒，層與層之間不會收到影響。
• 有利于標準化的制定

計算機網絡的各層協(xié)議及作用⊥匀狻＊＊＊

計算機網絡體系可以大致分為一下三種熏矿，七層模型、五層模型和TCP/IP四層模型离钝，一般面試能流暢回答出五層模型就可以了票编，表示層和會話層被問到的不多。

在這里插入圖片描述

• 應用層

  應用層的任務是通過應用進程之間的交互來完成特定的網絡作用卵渴，常見的應用層協(xié)議有域名系統(tǒng)DNS慧域，HTTP協(xié)議等。

• 表示層

  表示層的主要作用是數據的表示浪读、安全昔榴、壓縮〉忾伲可確保一個系統(tǒng)的應用層所發(fā)送的信息可以被另一個系統(tǒng)的應用層讀取互订。

• 會話層

  會話層的主要作用是建立通信鏈接，保持會話過程通信鏈接的暢通痘拆，同步兩個節(jié)點之間的對話仰禽，決定通信是否被中斷以及通信中斷時決定從何處重新發(fā)送。错负。

• 傳輸層

  傳輸層的主要作用是負責向兩臺主機進程之間的通信提供數據傳輸服務坟瓢。傳輸層的協(xié)議主要有傳輸控制協(xié)議TCP和用戶數據協(xié)議UDP。

• 網絡層

  網絡層的主要作用是選擇合適的網間路由和交換結點犹撒，確保數據及時送達折联。常見的協(xié)議有IP協(xié)議。

• 數據鏈路層

  數據鏈路層的作用是在物理層提供比特流服務的基礎上识颊，建立相鄰結點之間的數據鏈路诚镰，通過差錯控制提供數據幀（Frame）在信道上無差錯的傳輸奕坟，并進行各電路上的動作系列。 常見的協(xié)議有SDLC清笨、HDLC月杉、PPP等。

• 物理層

  物理層的主要作用是實現相鄰計算機結點之間比特流的透明傳輸抠艾，并盡量屏蔽掉具體傳輸介質和物理設備的差異苛萎。

URI和URL的區(qū)別　＊

• URI(Uniform Resource Identifier)：中文全稱為統(tǒng)一資源標志符检号，主要作用是唯一標識一個資源腌歉。
• URL(Uniform Resource Location)：中文全稱為統(tǒng)一資源定位符，主要作用是提供資源的路徑齐苛。

有個經典的比喻是URI像是身份證翘盖，可以唯一標識一個人，而URL更像一個住址凹蜂，可以通過URL找到這個人馍驯。

DNS的工作流程　＊＊＊

DNS的定義：DNS的全稱是domain name system玛痊，即域名系統(tǒng)汰瘫。DNS是因特網上作為域名和IP地址相互映射的一個分布式數據庫，能夠使用戶更方便的去訪問互聯網而不用去記住能夠被機器直接讀取的IP地址擂煞。比如大家訪問百度吟吝，更多地肯定是訪問www.baidu.com，而不是訪問112.80.248.74颈娜，因為這幾乎無規(guī)則的IP地址實在太難記了剑逃。DNS要做的就是將www.baidu.com解析成112.80.248.74。

DNS是集群式的工作方式還是 單點式的官辽，為什么蛹磺？

答案是集群式的，很容易想到的一個方案就是只用一個DNS服務器同仆，包含了所有域名和IP地址的映射萤捆。盡管這種設計方式看起來很簡單梨水，但是缺點顯而易見寞奸，如果這個唯一的DNS服務器出了故障，那么就全完了陨亡，因特網就幾乎崩了岁忘。為了避免這種情況出現辛慰，DNS系統(tǒng)采用的是分布式的層次數據數據庫模式，還有緩存的機制也能解決這種問題干像。

DNS的工作流程

主機向本地域名服務器的查詢一般是采用遞歸查詢帅腌，而本地域名服務器向根域名的查詢一般是采用迭代查詢驰弄。

遞歸查詢主機向本地域名發(fā)送查詢請求報文，而本地域名服務器不知道該域名對應的IP地址時速客，本地域名會繼續(xù)向根域名發(fā)送查詢請求報文戚篙，不是通知主機自己向根域名發(fā)送查詢請求報文。迭代查詢是溺职，本地域名服務器向根域名發(fā)出查詢請求報文后岔擂，根域名不會繼續(xù)向頂級域名服務器發(fā)送查詢請求報文，而是通知本地域名服務器向頂級域名發(fā)送查詢請求報文浪耘。

簡單來說智亮，遞歸查詢就是，小明問了小紅一個問題点待，小紅不知道，但小紅是個熱心腸弃舒，小紅就去問小王了癞埠，小王把答案告訴小紅后，小紅又去把答案告訴了小明聋呢。迭代查詢就是苗踪，小明問了小紅一個問題，小紅也不知道削锰，然后小紅讓小明去問小王通铲，小明又去問小王了，小王把答案告訴了小明器贩。

1. 在瀏覽器中輸入www.baidu.com域名颅夺，操作系統(tǒng)會先檢查自己本地的hosts文件是否有這個域名的映射關系，如果有蛹稍，就先調用這個IP地址映射吧黄，完成域名解析。
2. 如果hosts文件中沒有唆姐，則查詢本地DNS解析器緩存拗慨，如果有，則完成地址解析奉芦。
3. 如果本地DNS解析器緩存中沒有赵抢，則去查找本地DNS服務器，如果查到声功，完成解析烦却。
4. 如果沒有，則本地服務器會向根域名服務器發(fā)起查詢請求先巴。根域名服務器會告訴本地域名服務器去查詢哪個頂級域名服務器短绸。
5. 本地域名服務器向頂級域名服務器發(fā)起查詢請求车吹，頂級域名服務器會告訴本地域名服務器去查找哪個權限域名服務器。
6. 本地域名服務器向權限域名服務器發(fā)起查詢請求醋闭，權限域名服務器告訴本地域名服務器www.baidu.com所對應的IP地址窄驹。
7. 本地域名服務器告訴主機www.baidu.com所對應的IP地址。

了解ARP協(xié)議嗎?≈ぢ摺＊＊

ARP協(xié)議屬于網絡層的協(xié)議乐埠，主要作用是實現從IP地址轉換為MAC地址。在每個主機或者路由器中都建有一個ARP緩存表囚企，表中有IP地址及IP地址對應的MAC地址丈咐。先來看一下什么時IP地址和MAC地址。

• IP地址：IP地址是指互聯網協(xié)議地址龙宏，IP地址是IP協(xié)議提供的一種統(tǒng)一的地址格式棵逊，它為互聯網上的每一個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異银酗。
• MAC地址：MAC地址又稱物理地址辆影，由網絡設備制造商生產時寫在硬件內部，不可更改黍特，并且每個以太網設備的MAC地址都是唯一的蛙讥。

數據在傳輸過程中，會先從高層傳到底層灭衷，然后在通信鏈路上傳輸次慢。從下圖可以看到TCP報文在網絡層會被封裝成IP數據報，在數據鏈路層被封裝成MAC幀翔曲，然后在通信鏈路中傳輸迫像。在網絡層使用的是IP地址，在數據據鏈路層使用的是MAC地址瞳遍。MAC幀在傳送時的源地址和目的地址使用的都是MAC地址侵蒙，在通信鏈路上的主機或路由器也都是根據MAC幀首部的MAC地址接收MAC幀。并且在數據鏈路層是看不到IP地址的傅蹂，只有當數據傳到網絡層時去掉MAC幀的首部和尾部時才能在IP數據報的首部中找到源IP地址和目的地址纷闺。

在這里插入圖片描述

網絡層實現的是主機之間的通信，而鏈路層實現的是鏈路之間的通信份蝴，所以從下圖可以看出犁功，在數據傳輸過程中，IP數據報的源地址(IP1)和目的地址(IP2)是一直不變的婚夫，而MAC地址(硬件地址)卻一直隨著鏈路的改變而改變浸卦。

在這里插入圖片描述

ARP的工作流程(面試時問ARP協(xié)議主要說這個就可以了)：

1. 在局域網內，主機A要向主機B發(fā)送IP數據報時案糙，首先會在主機A的ARP緩存表中查找是否有IP地址及其對應的MAC地址限嫌，如果有靴庆，則將MAC地址寫入到MAC幀的首部，并通過局域網將該MAC幀發(fā)送到MAC地址所在的主機B怒医。
2. 如果主機A的ARP緩存表中沒有主機B的IP地址及所對應的MAC地址炉抒，主機A會在局域網內廣播發(fā)送一個ARP請求分組。局域網內的所有主機都會收到這個ARP請求分組稚叹。
3. 主機B在看到主機A發(fā)送的ARP請求分組中有自己的IP地址焰薄，會像主機A以單播的方式發(fā)送一個帶有自己MAC地址的響應分組。
4. 主機A收到主機B的ARP響應分組后扒袖，會在ARP緩存表中寫入主機B的IP地址及其IP地址對應的MAC地址塞茅。
5. 如果主機A和主機B不在同一個局域網內，即使知道主機B的MAC地址也是不能直接通信的季率，必須通過路由器轉發(fā)到主機B的局域網才可以通過主機B的MAC地址找到主機B野瘦。并且主機A和主機B已經可以通信的情況下，主機A的ARP緩存表中寸的并不是主機B的IP地址及主機B的MAC地址飒泻，而是主機B的IP地址及該通信鏈路上的下一跳路由器的MAC地址鞭光。這就是上圖中的源IP地址和目的IP地址一直不變，而MAC地址卻隨著鏈路的不同而改變蠢络。
6. 如果主機A和主機B不在同一個局域網，參考上圖中的主機H1和主機H2迟蜜，這時主機H1需要先廣播找到路由器R1的MAC地址刹孔，再由R1廣播找到路由器R2的MAC地址，最后R2廣播找到主機H2的MAC地址娜睛，建立起通信鏈路髓霞。

有了IP地址，為什么還要用MAC地址畦戒？》娇狻＊＊

簡單來說，標識網絡中的一臺計算機障斋，比較常用的就是IP地址和MAC地址纵潦，但計算機的IP地址可由用戶自行更改，管理起來相對困難垃环，而MAC地址不可更改邀层，所以一般會把IP地址和MAC地址組合起來使用。具體是如何組合使用的在上面的ARP協(xié)議中已經講的很清楚了遂庄。

那只用MAC地址不用IP地址可不可以呢寥院？其實也是不行的，因為在最早就是MAC地址先出現的涛目，并且當時并不用IP地址秸谢，只用MAC地址凛澎，后來隨著網絡中的設備越來越多，整個路由過程越來越復雜估蹄，便出現了子網的概念塑煎。對于目的地址在其他子網的數據包，路由只需要將數據包送到那個子網即可元媚，這個過程就是上面說的ARP協(xié)議轧叽。

那為什么要用IP地址呢？是因為IP地址是和地域相關的刊棕，對于同一個子網上的設備炭晒，IP地址的前綴都是一樣的，這樣路由器通過IP地址的前綴就知道設備在在哪個子網上了甥角，而只用MAC地址的話网严，路由器則需要記住每個MAC地址在哪個子網，這需要路由器有極大的存儲空間嗤无，是無法實現的震束。

IP地址可以比作為地址，MAC地址為收件人当犯，在一次通信過程中垢村，兩者是缺一不可的。

說一下ping的過程『课馈＊＊

ping是ICMP(網際控制報文協(xié)議)中的一個重要應用嘉栓，ICMP是網絡層的協(xié)議。ping的作用是測試兩個主機的連通性拓诸。

ping的工作過程：

1. 向目的主機發(fā)送多個ICMP回送請求報文
2. 根據目的主機返回的回送報文的時間和成功響應的次數估算出數據包往返時間及丟包率侵佃。

路由器和交換機的區(qū)別？〉熘А＊

TCP與UDP有什么區(qū)別　＊＊＊

有時候面試還會問到TCP的首部都包含什么

• TCP首部(圖片來源于網絡)：

  前20個字節(jié)是固定的倍谜，后面有4n個字節(jié)是根據需而增加的選項迈螟，所以TCP首部最小長度為20字節(jié)。

在這里插入圖片描述

• UDP首部(圖片來源于網絡)：

  UDP的首部只有8個字節(jié)尔崔，源端口號井联、目的端口號、長度和校驗和各兩個字節(jié)您旁。

在這里插入圖片描述

TCP協(xié)議如何保證可靠傳輸±映！＊＊＊

主要有校驗和、序列號、超時重傳蚕脏、流量控制及擁塞避免等幾種方法侦副。

• 校驗和：在發(fā)送算和接收端分別計算數據的校驗和，如果兩者不一致驼鞭，則說明數據在傳輸過程中出現了差錯秦驯，TCP將丟棄和不確認此報文段。

• 序列號：TCP會對每一個發(fā)送的字節(jié)進行編號挣棕，接收方接到數據后译隘，會對發(fā)送方發(fā)送確認應答(ACK報文)，并且這個ACK報文中帶有相應的確認編號洛心，告訴發(fā)送方固耘，下一次發(fā)送的數據從編號多少開始發(fā)。如果發(fā)送方發(fā)送相同的數據词身，接收端也可以通過序列號判斷出厅目，直接將數據丟棄。如果

在這里插入圖片描述

• 超時重傳：在上面說了序列號的作用法严，但如果發(fā)送方在發(fā)送數據后一段時間內（可以設置重傳計時器規(guī)定這段時間）沒有收到確認序號ACK损敷，那么發(fā)送方就會重新發(fā)送數據。

  這里發(fā)送方沒有收到ACK可以分兩種情況深啤，如果是發(fā)送方發(fā)送的數據包丟失了拗馒，接收方收到發(fā)送方重新發(fā)送的數據包后會馬上給發(fā)送方發(fā)送ACK；如果是接收方之前接收到了發(fā)送方發(fā)送的數據包溯街，而返回給發(fā)送方的ACK丟失了诱桂，這種情況，發(fā)送方重傳后苫幢，接收方會直接丟棄發(fā)送方沖重傳的數據包访诱，然后再次發(fā)送ACK響應報文垫挨。

  如果數據被重發(fā)之后還是沒有收到接收方的確認應答韩肝，則進行再次發(fā)送。此時九榔，等待確認應答的時間將會以2倍哀峻、4倍的指數函數延長，直到最后關閉連接哲泊。

• 流量控制：如果發(fā)送端發(fā)送的數據太快剩蟀，接收端來不及接收就會出現丟包問題。為了解決這個問題切威，TCP協(xié)議利用了滑動窗口進行了流量控制育特。在TCP首部有一個16位字段大小的窗口，窗口的大小就是接收端接收數據緩沖區(qū)的剩余大小。接收端會在收到數據包后發(fā)送ACK報文時缰冤，將自己的窗口大小填入ACK中犬缨，發(fā)送方會根據ACK報文中的窗口大小進而控制發(fā)送速度。如果窗口大小為零棉浸，發(fā)送方會停止發(fā)送數據怀薛。

• 擁塞控制：如果網絡出現擁塞，則會產生丟包等問題迷郑，這時發(fā)送方會將丟失的數據包繼續(xù)重傳枝恋，網絡擁塞會更加嚴重，所以在網絡出現擁塞時應注意控制發(fā)送方的發(fā)送數據嗡害，降低整個網絡的擁塞程度焚碌。擁塞控制主要有四部分組成：慢開始、擁塞避免就漾、快重傳呐能、快恢復，如下圖(圖片來源于網絡)抑堡。

  在這里插入圖片描述
  
  

  這里的發(fā)送方會維護一個擁塞窗口的狀態(tài)變量摆出，它和流量控制的滑動窗口是不一樣的，滑動窗口是根據接收方數據緩沖區(qū)大小確定的首妖，而擁塞窗口是根據網絡的擁塞情況動態(tài)確定的偎漫，一般來說發(fā)送方真實的發(fā)送窗口為滑動窗口和擁塞窗口中的最小值。

  1. 慢開始：為了避免一開始發(fā)送大量的數據而產生網絡阻塞有缆，會先初始化cwnd為1象踊，當收到ACK后到下一個傳輸輪次，cwnd為2棚壁，以此類推成指數形式增長杯矩。

  2. 擁塞避免：因為cwnd的數量在慢開始是指數增長的，為了防止cwnd數量過大而導致網絡阻塞袖外，會設置一個慢開始的門限值ssthresh史隆，當cwnd>=ssthresh時，進入到擁塞避免階段曼验，cwnd每個傳輸輪次加1泌射。但網絡出現超時，會將門限值ssthresh變?yōu)槌霈F超時cwnd數值的一半鬓照，cwnd重新設置為1熔酷，如上圖，在第12輪出現超時后豺裆，cwnd變?yōu)?拒秘，ssthresh變?yōu)?2。

  3. 快重傳：在網絡中如果出現超時或者阻塞，則按慢開始和擁塞避免算法進行調整躺酒。但如果只是丟失某一個報文段咙轩，如下圖(圖片來源于網絡)，則使用快重傳算法阴颖。

  在這里插入圖片描述
  
  

  從上圖可知活喊，接收方正確地接收到M1和M2，而M3丟失量愧，由于沒有接收到M3钾菊，在接收方收到M5、M6和M7時偎肃，并不會進行確認煞烫，也就是不會發(fā)送ACK。這時根據前面說的保證TCP可靠性傳輸中的序列號的作用累颂，接收方這時不會接收M5滞详，M6，M7紊馏，接收方可以什么都不會料饥，因為發(fā)送方長時間未收到M3的確認報文，會對M3進行重傳朱监。除了這樣岸啡，接收方也可以重復發(fā)送M2的確認報文，這樣發(fā)送端長時間未收到M3的確認報文也會繼續(xù)發(fā)送M3報文赫编。

  但是根據快重傳算法巡蘸，要求在這種情況下，需要快速向發(fā)送端發(fā)送M2的確認報文擂送，在發(fā)送方收到三個M2的確認報文后悦荒，無需等待重傳計時器所設置的時間，可直接進行M3的重傳嘹吨，這就是快重傳搬味。(面試時說這一句就夠了，前面是幫助理解)

  4. 快恢復：從上上圖圈4可以看到躺苦，當發(fā)送收到三個重復的ACK身腻，會進行快重傳和快恢復产还∑ダ澹快恢復是指將ssthresh設置為發(fā)生快重傳時的cwnd數量的一半，而cwnd不是設置為1而是設置為為門限值ssthresh脐区，并開始擁塞避免階段愈诚。

TCP的三次握手及四次揮手　＊＊＊

必考題

在介紹三次握手和四次揮手之前，先介紹一下TCP頭部的一些常用字段炕柔。

• 序號：seq酌泰，占32位，用來標識從發(fā)送端到接收端發(fā)送的字節(jié)流匕累。
• 確認號：ack陵刹，占32位，只有ACK標志位為1時欢嘿，確認序號字段才有效衰琐，ack=seq+1。
• 標志位：
  • SYN：發(fā)起一個新連接炼蹦。
  • FIN：釋放一個連接羡宙。
  • ACK：確認序號有效。

三次握手

三次握手的本質就是確定發(fā)送端和接收端具備收發(fā)信息的能力掐隐，在能流暢描述三次握手的流程及其中的字段含義作用的同時還需要記住每次握手時接收端和發(fā)送端的狀態(tài)狗热。這個比較容易忽略。

在這里插入圖片描述

假設發(fā)送端為客戶端，接收端為服務端架馋。開始時客戶端和服務端的狀態(tài)都是CLOSE狞山。

• 第一次握手：客戶端向服務端發(fā)起建立連接請求，客戶端會隨機生成一個起始序列號x叉寂，客戶端向服務端發(fā)送的字段中包含標志位SYN=1萍启，序列號seq=100。第一次握手前客戶端的狀態(tài)為CLOSE屏鳍，第一次握手后客戶端的狀態(tài)為SYN-SENT勘纯。此時服務端的狀態(tài)為LISTEN
• 第二次握手：服務端在收到客戶端發(fā)來的報文后，會隨機生成一個服務端的起始序列號y钓瞭，然后給客戶端回復一段報文怖辆，其中包括標志位SYN=1，ACK=1蠢护，序列號seq=y必怜，確認號ack=x+1唆迁。第二次握手前服務端的狀態(tài)為LISTEN，第二次握手后服務端的狀態(tài)為SYN-RCVD竞穷，此時客戶端的狀態(tài)為SYN-SENT唐责。（其中SYN=1表示要和客戶端建立一個連接，ACK=1表示確認序號有效）
• 第三次握手：客戶端收到服務端發(fā)來的報文后瘾带，會再向服務端發(fā)送報文鼠哥，其中包含標志位ACK=1，序列號seq=x+1看政，確認號ack=y+1肴盏。第三次握手前客戶端的狀態(tài)為SYN-SENT，第三次握手后客戶端和服務端的狀態(tài)都為ESTABLISHED帽衙。

需要注意的一點是菜皂，第一次握手，客戶端向服務端發(fā)起建立連接報文厉萝，會占一個序列號恍飘。但是第三次握手，同樣是客戶端向服務端發(fā)送報文谴垫，這次卻不占序列號章母，所以建立連接后，客戶端向服務端發(fā)送的第一個數據的序列號為x+1翩剪。

四次揮手

和三次握手一樣乳怎，先看一張非常經典的圖（圖片來源于網絡），客戶端在四次揮手過程中有ESTABLISHED前弯、FIN-WAIT-1蚪缀、FIN-WAIT-2、TIME-WAIT恕出、CLOSED等五個狀態(tài)询枚，服務端有ESTABLISHED、CLOSE-WAIT浙巫、LAST-ACK金蜀、CLOSED等四種狀態(tài)。最好記住每次揮手時服務端和客戶端的狀態(tài)的畴。
假設客戶端首先發(fā)起的斷開連接請求

在這里插入圖片描述

• 第一次揮手：客戶端向服務端發(fā)送的數據完成后渊抄，向服務端發(fā)起釋放連接報文，報文包含標志位FIN=1丧裁，序列號seq=u护桦。此時客戶端只能接收數據，不能向服務端發(fā)送數據渣慕。
• 第二次揮手：服務端收到客戶端的釋放連接報文后嘶炭，向客戶端發(fā)送確認報文，包含標志位ACK=1逊桦，序列號seq=v眨猎，確認號ack=u+1。此時客戶端到服務端的連接已經釋放掉强经，客戶端不能像服務端發(fā)送數據睡陪，服務端也不能向客戶端發(fā)送數據。但服務端到客戶端的單向連接還能正常傳輸數據匿情。
• 第三次揮手：服務端發(fā)送完數據后向客戶端發(fā)出連接釋放報文兰迫，報文包含標志位FIN=1，標志位ACK=1炬称，序列號seq=w汁果，確認號ack=u+1。
• 第四次揮手：客戶端收到服務端發(fā)送的釋放連接請求玲躯，向服務端發(fā)送確認報文据德，包含標志位ACK=1，序列號seq=u+1跷车，確認號ack=w+1棘利。

為什么TCP連接的時候是3次？兩次是否可以朽缴？

不可以善玫，主要從以下兩方面考慮（假設客戶端是首先發(fā)起連接請求）：

1. 假設建立TCP連接僅需要兩次握手，那么如果第二次握手時密强，服務端返回給客戶端的確認報文丟失了茅郎，客戶端這邊認為服務端沒有和他建立連接，而服務端卻以為已經和客戶端建立了連接或渤，并且可能向服務端已經開始向客戶端發(fā)送數據只洒，但客戶端并不會接收這些數據，浪費了資源劳坑。如果是三次握手毕谴，不會出現雙方連接還未完全建立成功就開始發(fā)送數據的情況。
2. 如果服務端接收到了一個早已失效的來自客戶端的連接請求報文距芬，會向客戶端發(fā)送確認報文同意建立TCP連接涝开。但因為客戶端并不需要向服務端發(fā)送數據，所以此次TCP連接沒有意義并且浪費了資源框仔。

為什么TCP連接的時候是3次舀武，關閉的時候卻是4次？

因為需要確保通信雙方都能通知對方釋放連接离斩，假設客服端發(fā)送完數據向服務端發(fā)送釋放連接請求银舱，當客服端并不知道瘪匿，服務端是否已經發(fā)送完數據，所以此次斷開的是客服端到服務端的單向連接寻馏，服務端返回給客戶端確認報文后棋弥，服務端還能繼續(xù)單向給客戶端發(fā)送數據。當服務端發(fā)送完數據后還需要向客戶端發(fā)送釋放連接請求诚欠，客戶端返回確認報文顽染，TCP連接徹底關閉。所以斷開TCP連接需要客戶端和服務端分別通知對方并分別收到確認報文轰绵，一共需要四次粉寞。

TIME_WAIT和CLOSE_WAIT的區(qū)別在哪?

默認客戶端首先發(fā)起斷開連接請求

• 從上圖可以看出，CLOSE_WAIT是被動關閉形成的左腔，當客戶端發(fā)送FIN報文唧垦，服務端返回ACK報文后進入CLOSE_WAIT。
• TIME_WAIT是主動關閉形成的液样，當第四次揮手完成后业崖，客戶端進入TIME_WAIT狀態(tài)。

為什么客戶端發(fā)出第四次揮手的確認報文后要等2MSL的時間才能釋放TCP連接蓄愁？

MSL的意思是報文的最長壽命双炕，可以從兩方面考慮：

1. 客戶端發(fā)送第四次揮手中的報文后，再經過2MSL撮抓，可使本次TCP連接中的所有報文全部消失妇斤，不會出現在下一個TCP連接中。
2. 考慮丟包問題丹拯，如果第四揮手發(fā)送的報文在傳輸過程中丟失了站超，那么服務端沒收到確認ack報文就會重發(fā)第三次揮手的報文。如果客戶端發(fā)送完第四次揮手的確認報文后直接關閉乖酬，而這次報文又恰好丟失死相，則會造成服務端無法正常關閉。

如果已經建立了連接咬像，但是客戶端突然出現故障了怎么辦算撮？

如果TCP連接已經建立，在通信過程中县昂，客戶端突然故障肮柜，那么服務端不會一直等下去，過一段時間就關閉連接了倒彰。具體原理是TCP有一個鄙蠖矗活機制，主要用在服務器端待讳，用于檢測已建立TCP鏈接的客戶端的狀態(tài)芒澜，防止因客戶端崩潰或者客戶端網絡不可達仰剿，而服務器端一直保持該TCP鏈接，占用服務器端的大量資源(因為Linux系統(tǒng)中可以創(chuàng)建的總TCP鏈接數是有限制的)痴晦。

蹦纤保活機制原理：設置TCP保活機制的痹睦遥活時間keepIdle旨袒，即在TCP鏈接超過該時間沒有任何數據交互時汁针，發(fā)送笔醴活探測報文；設置笔┪蓿活探測報文的發(fā)送時間間隔keepInterval辉词；設置保活探測報文的總發(fā)送次數keepCount猾骡。如果在keepCount次的比鹛桑活探測報文均沒有收到客戶端的回應，則服務器端即關閉與客戶端的TCP鏈接兴想。

具體細節(jié)請看這篇博客TCP通信過程中異常情況整理幢哨。

HTTP 與 HTTPS 的區(qū)別　＊＊＊

什么是對稱加密與非對稱加密“妒邸＊＊

• 對稱加密

  對稱加密指加密和解密使用同一密鑰，優(yōu)點是運算速度快厂画，缺點是如何安全將密鑰傳輸給另一方凸丸。常見的對稱加密算法有DES、AES等等袱院。

• 非對稱加密

  非對稱加密指的是加密和解密使用不同的密鑰屎慢，一把公開的公鑰，一把私有的私鑰忽洛。公鑰加密的信息只有私鑰才能解密抛人，私鑰加密的信息只有公鑰才能解密。優(yōu)點解決了對稱加密中存在的問題脐瑰。缺點是運算速度較慢妖枚。常見的非對稱加密算法有RSA、DSA苍在、ECC等等绝页。

  非對稱加密的工作流程：A生成一對非堆成密鑰荠商，將公鑰向所有人公開，B拿到A的公鑰后使用A的公鑰對信息加密后發(fā)送給A续誉，經過加密的信息只有A手中的私鑰能解密莱没。這樣B可以通過這種方式將自己的公鑰加密后發(fā)送給A，兩方建立起通信酷鸦，可以通過對方的公鑰加密要發(fā)送的信息饰躲，接收方用自己的私鑰解密信息。

HTTPS的加密過程【矢簟＊＊＊

上面已經介紹了對稱加密和非對稱加密的優(yōu)缺點嘹裂，HTTPS是將兩者結合起來，使用的對稱加密和非對稱加密的混合加密算法摔握。具體做法就是使用非對稱加密來傳輸對稱密鑰來保證安全性寄狼，使用對稱加密來保證通信的效率。

簡化的工作流程：服務端生成一對非對稱密鑰氨淌，將公鑰發(fā)給客戶端泊愧。客戶端生成對稱密鑰盛正，用服務端發(fā)來的公鑰進行加密删咱，加密后發(fā)給服務端。服務端收到后用私鑰進行解密豪筝，得到客戶端發(fā)送的對稱密鑰痰滋。通信雙方就可以通過對稱密鑰進行高效地通信了。

但是仔細想想這其中存在一個很大地問題壤蚜，就是客戶端最開始如何判斷收到的這個公鑰就是來自服務端而不是其他人冒充的即寡？

這就需要證書上場了，服務端會向一個權威機構申請一個證書來證明自己的身份袜刷，到時候將證書（證書中包含了公鑰）發(fā)給客戶端就可以了聪富，客戶端收到證書后既證明了服務端的身份又拿到了公鑰就可以進行下一步操作了。

HTTPS的加密過程：

1. 客戶端向服務端發(fā)起第一次握手請求著蟹，告訴服務端客戶端所支持的SSL的指定版本墩蔓、加密算法及密鑰長度等信息。
2. 服務端將自己的公鑰發(fā)給數字證書認證機構萧豆，數字證書認證機構利用自己的私鑰對服務器的公鑰進行數字簽名奸披，并給服務器頒發(fā)公鑰證書。
3. 服務端將證書發(fā)給客服端涮雷。
4. 客服端利用數字認證機構的公鑰阵面，向數字證書認證機構驗證公鑰證書上的數字簽名，確認服務器公開密鑰的真實性。
5. 客服端使用服務端的公開密鑰加密自己生成的對稱密鑰样刷，發(fā)給服務端仑扑。
6. 服務端收到后利用私鑰解密信息，獲得客戶端發(fā)來的對稱密鑰置鼻。
7. 通信雙方可用對稱密鑰來加密解密信息镇饮。

上述流程存在的一個問題是客戶端哪里來的數字認證機構的公鑰，其實箕母，在很多瀏覽器開發(fā)時储藐，會內置常用數字證書認證機構的公鑰。

流程圖如下：

在這里插入圖片描述

常用HTTP狀態(tài)碼∷皇恰＊＊＊

這也是一個面試經常問的題目,背下來就行了.

常見的HTTP狀態(tài)碼

1XX

• 100 Continue：表示正常钙勃，客戶端可以繼續(xù)發(fā)送請求
• 101 Switching Protocols：切換協(xié)議，服務器根據客戶端的請求切換協(xié)議俊啼。

2XX

• 200 OK：請求成功
• 201 Created：已創(chuàng)建肺缕，表示成功請求并創(chuàng)建了新的資源
• 202 Accepted：已接受左医，已接受請求授帕，但未處理完成。
• 204 No Content：無內容浮梢，服務器成功處理跛十，但未返回內容。
• 205 Reset Content：重置內容秕硝，服務器處理成功芥映，客戶端應重置文檔視圖。
• 206 Partial Content：表示客戶端進行了范圍請求远豺，響應報文應包含Content-Range指定范圍的實體內容

3XX

• 301 Moved Permanently：永久性重定向
• 302 Found：臨時重定向
• 303 See Other：和301功能類似奈偏，但要求客戶端采用get方法獲取資源
• 304 Not Modified：所請求的資源未修改，服務器返回此狀態(tài)碼時躯护，不會返回任何資源惊来。
• 305 Use Proxy：所請求的資源必須通過代理訪問
• 307 Temporary Redirect： 臨時重定向，與302類似棺滞，要求使用get請求重定向裁蚁。

4XX

• 400 Bad Request：客戶端請求的語法錯誤，服務器無法理解继准。
• 401 Unauthorized：表示發(fā)送的請求需要有認證信息枉证。
• 403 Forbidden：服務器理解用戶的請求，但是拒絕執(zhí)行該請求
• 404 Not Found：服務器無法根據客戶端的請求找到資源移必。
• 405 Method Not Allowed：客戶端請求中的方法被禁止
• 406 Not Acceptable：服務器無法根據客戶端請求的內容特性完成請求
• 408 Request Time-out：服務器等待客戶端發(fā)送的請求時間過長室谚，超時

5XX

• 500 Internal Server Error：服務器內部錯誤，無法完成請求
• 501 Not Implemented：服務器不支持請求的功能，無法完成請求

常見的HTTP方法∶氤唷＊＊＊

為了方便記憶倒脓，可以將PUT撑螺、DELETE、POST崎弃、GET理解為客戶端對服務端的增刪改查甘晤。

• PUT：上傳文件，向服務器添加數據饲做，可以看作增
• DELETE：刪除文件
• POST：傳輸數據线婚，向服務器提交數據，對服務器數據進行更新盆均。
• GET：獲取資源塞弊，查詢服務器資源

GET和POST區(qū)別　＊＊＊

• 作用

  GET用于獲取資源泪姨，POST用于傳輸實體主體

• 參數位置

  GET的參數放在URL中游沿，POST的參數存儲在實體主體中，并且GET方法提交的請求的URL中的數據做多是2048字節(jié)肮砾，POST請求沒有大小限制诀黍。

• 安全性

  GET方法因為參數放在URL中，安全性相對于POST較差一些

• 冪等性

  GET方法是具有冪等性的仗处，而POST方法不具有冪等性眯勾。這里冪等性指客戶端連續(xù)發(fā)出多次請求，收到的結果都是一樣的.

HTTP 1.0婆誓、HTTP 1.1及HTTP 2.0的主要區(qū)別是什么〕曰贰＊＊

HTTP 1.0和HTTP 1.1的區(qū)別

• 長連接

  HTTP 1.1支持長連接和請求的流水線操作。長連接是指不在需要每次請求都重新建立一次連接洋幻，HTTP 1.0默認使用短連接郁轻，每次請求都要重新建立一次TCP連接，資源消耗較大鞋屈。請求的流水線操作是指客戶端在收到HTTP的響應報文之前可以先發(fā)送新的請求報文范咨，不支持請求的流水線操作需要等到收到HTTP的響應報文后才能繼續(xù)發(fā)送新的請求報文。

• 緩存處理

  在HTTP 1.0中主要使用header中的If-Modified-Since,Expires作為緩存判斷的標準厂庇，HTTP 1.1引入了Entity tag渠啊，If-Unmodified-Since, If-Match等更多可供選擇的緩存頭來控制緩存策略。

• 錯誤狀態(tài)碼

  在HTTP 1.1新增了24個錯誤狀態(tài)響應碼

• HOST域

  在HTTP 1.0 中認為每臺服務器都會綁定唯一的IP地址权旷，所以替蛉，請求中的URL并沒有傳遞主機名贯溅。但后來一臺服務器上可能存在多個虛擬機，它們共享一個IP地址躲查，所以HTTP 1.1中請求消息和響應消息都應該支持Host域它浅。

• 帶寬優(yōu)化及網絡連接的使用

  在HTTP 1.0中會存在浪費帶寬的現象，主要是因為不支持斷點續(xù)傳功能镣煮，客戶端只是需要某個對象的一部分姐霍，服務端卻將整個對象都傳了過來。在HTTP 1.1中請求頭引入了range頭域典唇，它支持只請求資源的某個部分镊折，返回的狀態(tài)碼為206。

HTTP 2.0的新特性

• 新的二進制格式：HTTP 1.x的解析是基于文本介衔，HTTP 2.0的解析采用二進制恨胚，實現方便，健壯性更好炎咖。
• 多路復用：每一個request對應一個id赃泡，一個連接上可以有多個request，每個連接的request可以隨機混在一起乘盼，這樣接收方可以根據request的id將request歸屬到各自不同的服務端請求里升熊。
• header壓縮：在HTTP 1.x中，header攜帶大量信息蹦肴，并且每次都需要重新發(fā)送僚碎，HTTP 2.0采用編碼的方式減小了header的大小猴娩，同時通信雙方各自緩存一份header fields表阴幌，避免了header的重復傳輸。
• 服務端推送：客戶端在請求一個資源時卷中，會把相關資源一起發(fā)給客戶端矛双，這樣客戶端就不需要再次發(fā)起請求。

Session蟆豫、Cookie和Token的主要區(qū)別∫楹觥＊＊＊

HTTP協(xié)議是無狀態(tài)的，即服務器無法判斷用戶身份十减。Session和Cookie可以用來進行身份辨認栈幸。

• Cookie

  Cookie是保存在客戶端一個小數據塊，其中包含了用戶信息帮辟。當客戶端向服務端發(fā)起請求速址，服務端會像客戶端瀏覽器發(fā)送一個Cookie，客戶端會把Cookie存起來由驹，當下次客戶端再次請求服務端時芍锚，會攜帶上這個Cookie，服務端會通過這個Cookie來確定身份。

• Session

  Session是通過Cookie實現的并炮，和Cookie不同的是默刚，Session是存在服務端的。當客戶端瀏覽器第一次訪問服務器時逃魄，服務器會為瀏覽器創(chuàng)建一個sessionid荤西，將sessionid放到Cookie中，存在客戶端瀏覽器伍俘。比如瀏覽器訪問的是購物網站皂冰，將一本《圖解HTTP》放到了購物車，當瀏覽器再次訪問服務器時养篓，服務器會取出Cookie中的sessionid秃流，并根據sessionid獲取會話中的存儲的信息，確認瀏覽器的身份是上次將《圖解HTTP》放入到購物車那個用戶柳弄。

• Token

  客戶端在瀏覽器第一次訪問服務端時舶胀，服務端生成的一串字符串作為Token發(fā)給客戶端瀏覽器，下次瀏覽器在訪問服務端時攜帶token即可無需驗證用戶名和密碼碧注，省下來大量的資源開銷嚣伐。看到這里很多人感覺這不是和sessionid作用一樣嗎萍丐？其實是不一樣的轩端，但是本文章主要針對面試，知識點很多逝变，篇幅有限基茵，幾句話也解釋不清楚，大家可以看看這篇文章壳影，我覺得說的非常清楚了拱层。cookie、session與token的真正區(qū)別

  下面為了方便記憶宴咧，做了一個表格進行對比根灯。

  	存放位置	占用空間	安全性	應用場景
  Cookie	客戶端瀏覽器	小	較低	一般存放配置信息
  Session	服務端	多	較高	存放較為重要的信息

如果客戶端禁止 cookie 能實現 session 還能用嗎？〔粽ぁ＊

可以烙肺，Session的作用是在服務端來保持狀態(tài)，通過sessionid來進行確認身份氧卧，但sessionid一般是通過Cookie來進行傳遞的桃笙。如果Cooike被禁用了，可以通過在URL中傳遞sessionid假抄。

在瀏覽器中輸?url地址到顯示主?的過程≡踉浴＊＊＊

面試超高頻的一道題丽猬，一般能說清楚流程就可以。

1. 對輸入到瀏覽器的url進行DNS解析熏瞄，將域名轉換為IP地址脚祟。
2. 和目的服務器建立TCP連接
3. 向目的服務器發(fā)送HTTP請求
4. 服務器處理請求并返回HTTP報文
5. 瀏覽器解析并渲染頁面

Servlet是線程安全的嗎　＊

Servlet不是線程安全的强饮，多線程的讀寫會導致數據不同步的問題由桌。