這些必會的計算機網路知識點你都掌握了嗎

學習計算機網路必會的知識點，看看你是否全面掌握，如有幫到你，可以收藏點贊支援哦。

目錄

• 什麼是網路協議，為什麼要對網路協議分層　＊
• 計算機網路的各層協議及作用　＊＊＊
• URI和URL的區別　＊
• DNS的工作流程　＊＊＊
• 瞭解ARP協議嗎?　＊＊
• 有了IP地址，為什麼還要用MAC地址？　＊＊
• 說一下ping的過程　＊＊
• 路由器和交換機的區別？　＊
• TCP與UDP有什麼區別　＊＊＊
• TCP協議如何保證可靠傳輸　＊＊＊
• TCP的三次握手及四次揮手　＊＊＊
  • 三次握手
  • 四次揮手
  • 為什麼TCP連線的時候是3次？兩次是否可以？
  • 為什麼TCP連線的時候是3次，關閉的時候卻是4次？
  • TIME_WAIT和CLOSE_WAIT的區別在哪?
  • 為什麼客戶端發出第四次揮手的確認報文後要等2MSL的時間才能釋放TCP連線？
  • 如果已經建立了連線，但是客戶端突然出現故障了怎麼辦？
• HTTP 與 HTTPS 的區別　＊＊＊
• 什麼是對稱加密與非對稱加密　＊＊
• HTTPS的加密過程　＊＊＊
• 常用HTTP狀態碼　＊＊＊
• 常見的HTTP方法　＊＊＊
• GET和POST區別　＊＊＊
• HTTP 1.0、HTTP 1.1及HTTP 2.0的主要區別是什麼　＊＊
• Session、Cookie和Token的主要區別　＊＊＊
• 如果客戶端禁止 cookie 能實現 session 還能用嗎？　＊
• 在瀏覽器中輸⼊url地址到顯示主⻚的過程　＊＊＊
• Servlet是執行緒安全的嗎　＊

什麼是網路協議，為什麼要對網路協議分層　＊

網路協議是計算機在通訊過程中要遵循的一些約定好的規則。

網路分層的原因：

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

計算機網路的各層協議及作用　＊＊＊

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

• 應用層

  應用層的任務是通過應用程式之間的互動來完成特定的網路作用，常見的應用層協議有域名系統DNS，HTTP協議等。

• 表示層

  表示層的主要作用是資料的表示、安全、壓縮。可確保一個系統的應用層所傳送的資訊可以被另一個系統的應用層讀取。

• 會話層

  會話層的主要作用是建立通訊連結，保持會話過程通訊連結的暢通，同步兩個節點之間的對話，決定通訊是否被中斷以及通訊中斷時決定從何處重新傳送。。

• 傳輸層

  傳輸層的主要作用是負責向兩臺主機程式之間的通訊提供資料傳輸服務。傳輸層的協議主要有傳輸控制協議TCP和使用者資料協議UDP。

• 網路層

  網路層的主要作用是選擇合適的網間路由和交換結點，確保資料及時送達。常見的協議有IP協議。

• 資料鏈路層

  資料鏈路層的作用是在物理層提供位元流服務的基礎上，建立相鄰結點之間的資料鏈路，通過差錯控制提供資料幀（Frame）在通道上無差錯的傳輸，並進行各電路上的動作系列。 常見的協議有SDLC、HDLC、PPP等。

• 物理層

  物理層的主要作用是實現相鄰計算機結點之間位元流的透明傳輸，並儘量遮蔽掉具體傳輸介質和物理裝置的差異。

URI和URL的區別　＊

• URI(Uniform Resource Identifier)：中文全稱為統一資源標誌符，主要作用是唯一標識一個資源。
• URL(Uniform Resource Location)：中文全稱為統一資源定位符，主要作用是提供資源的路徑。

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

DNS的工作流程　＊＊＊

DNS的定義：DNS的全稱是domain name system，即域名系統。DNS是因特網上作為域名和IP地址相互對映的一個分散式資料庫，能夠使使用者更方便的去訪問網際網路而不用去記住能夠被機器直接讀取的IP地址。比如大家訪問百度，更多地肯定是訪問www.baidu.com，而不是訪問112.80.248.74，因為這幾乎無規則的IP地址實在太難記了。DNS要做的就是將www.baidu.com解析成112.80.248.74。

DNS是叢集式的工作方式還是 單點式的，為什麼？

​ 答案是叢集式的，很容易想到的一個方案就是隻用一個DNS伺服器，包含了所有域名和IP地址的對映。儘管這種設計方式看起來很簡單，但是缺點顯而易見，如果這個唯一的DNS伺服器出了故障，那麼就全完了，因特網就幾乎崩了。為了避免這種情況出現，DNS系統採用的是分散式的層次資料資料庫模式，還有快取的機制也能解決這種問題。

DNS的工作流程

主機向本地域名伺服器的查詢一般是採用遞迴查詢，而本地域名伺服器向根域名的查詢一般是採用迭代查詢。

遞迴查詢主機向本地域名傳送查詢請求報文，而本地域名伺服器不知道該域名對應的IP地址時，本地域名會繼續向根域名傳送查詢請求報文，不是通知主機自己向根域名傳送查詢請求報文。迭代查詢是，本地域名伺服器向根域名發出查詢請求報文後，根域名不會繼續向頂級域名伺服器傳送查詢請求報文，而是通知本地域名伺服器向頂級域名傳送查詢請求報文。

簡單來說，遞迴查詢就是，小明問了小紅一個問題，小紅不知道，但小紅是個熱心腸，小紅就去問小王了，小王把答案告訴小紅後，小紅又去把答案告訴了小明。迭代查詢就是，小明問了小紅一個問題，小紅也不知道，然後小紅讓小明去問小王，小明又去問小王了，小王把答案告訴了小明。

1. 在瀏覽器中輸入www.baidu.com域名，作業系統會先檢查自己本地的hosts檔案是否有這個域名的對映關係，如果有，就先呼叫這個IP地址對映，完成域名解析。
2. 如果hosts檔案中沒有，則查詢本地DNS解析器快取，如果有，則完成地址解析。
3. 如果本地DNS解析器快取中沒有，則去查詢本地DNS伺服器，如果查到，完成解析。
4. 如果沒有，則本地伺服器會向根域名伺服器發起查詢請求。根域名伺服器會告訴本地域名伺服器去查詢哪個頂級域名伺服器。
5. 本地域名伺服器向頂級域名伺服器發起查詢請求，頂級域名伺服器會告訴本地域名伺服器去查詢哪個許可權域名伺服器。
6. 本地域名伺服器向許可權域名伺服器發起查詢請求，許可權域名伺服器告訴本地域名伺服器www.baidu.com所對應的IP地址。
7. 本地域名伺服器告訴主機www.baidu.com所對應的IP地址。

瞭解ARP協議嗎?　＊＊

ARP協議屬於網路層的協議，主要作用是實現從IP地址轉換為MAC地址。在每個主機或者路由器中都建有一個ARP快取表，表中有IP地址及IP地址對應的MAC地址。先來看一下什麼時IP地址和MAC地址。

• IP地址：IP地址是指網際網路協議地址，IP地址是IP協議提供的一種統一的地址格式，它為網際網路上的每一個網路和每一臺主機分配一個邏輯地址，以此來遮蔽實體地址的差異。
• MAC地址：MAC地址又稱實體地址，由網路裝置製造商生產時寫在硬體內部，不可更改，並且每個乙太網裝置的MAC地址都是唯一的。

資料在傳輸過程中，會先從高層傳到底層，然後在通訊鏈路上傳輸。從下圖可以看到TCP報文在網路層會被封裝成IP資料包，在資料鏈路層被封裝成MAC幀，然後在通訊鏈路中傳輸。在網路層使用的是IP地址，在資料據鏈路層使用的是MAC地址。MAC幀在傳送時的源地址和目的地址使用的都是MAC地址，在通訊鏈路上的主機或路由器也都是根據MAC幀首部的MAC地址接收MAC幀。並且在資料鏈路層是看不到IP地址的，只有當資料傳到網路層時去掉MAC幀的首部和尾部時才能在IP資料包的首部中找到源IP地址和目的地址。

網路層實現的是主機之間的通訊，而鏈路層實現的是鏈路之間的通訊，所以從下圖可以看出，在資料傳輸過程中，IP資料包的源地址(IP1)和目的地址(IP2)是一直不變的，而MAC地址(硬體地址)卻一直隨著鏈路的改變而改變。

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

1. 在區域網內，主機A要向主機B傳送IP資料包時，首先會在主機A的ARP快取表中查詢是否有IP地址及其對應的MAC地址，如果有，則將MAC地址寫入到MAC幀的首部，並通過區域網將該MAC幀傳送到MAC地址所在的主機B。
2. 如果主機A的ARP快取表中沒有主機B的IP地址及所對應的MAC地址，主機A會在區域網內廣播傳送一個ARP請求分組。區域網內的所有主機都會收到這個ARP請求分組。
3. 主機B在看到主機A傳送的ARP請求分組中有自己的IP地址，會像主機A以單播的方式傳送一個帶有自己MAC地址的響應分組。
4. 主機A收到主機B的ARP響應分組後，會在ARP快取表中寫入主機B的IP地址及其IP地址對應的MAC地址。
5. 如果主機A和主機B不在同一個區域網內，即使知道主機B的MAC地址也是不能直接通訊的，必須通過路由器轉發到主機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協議中已經講的很清楚了。

那隻用MAC地址不用IP地址可不可以呢？其實也是不行的，因為在最早就是MAC地址先出現的，並且當時並不用IP地址，只用MAC地址，後來隨著網路中的裝置越來越多，整個路由過程越來越複雜，便出現了子網的概念。對於目的地址在其他子網的資料包，路由只需要將資料包送到那個子網即可，這個過程就是上面說的ARP協議。

那為什麼要用IP地址呢？是因為IP地址是和地域相關的，對於同一個子網上的裝置，IP地址的字首都是一樣的，這樣路由器通過IP地址的字首就知道裝置在在哪個子網上了，而只用MAC地址的話，路由器則需要記住每個MAC地址在哪個子網，這需要路由器有極大的儲存空間，是無法實現的。

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

說一下ping的過程　＊＊

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

ping的工作過程：

1. 向目的主機傳送多個ICMP回送請求報文
2. 根據目的主機返回的回送報文的時間和成功響應的次數估算出資料包往返時間及丟包率。

路由器和交換機的區別？　＊

	所屬網路模型的層級	功能
路由器	網路層	識別IP地址並根據IP地址轉發資料包，維護資料表並基於資料表進行最佳路徑選擇
交換機	資料鏈庫層	識別MAC地址並根據MAC地址轉發資料幀

TCP與UDP有什麼區別　＊＊＊

	是否面向連線	可靠性	傳輸形式	傳輸效率	消耗資源	應用場景	首部位元組
TCP	面向連線	可靠	位元組流	慢	多	檔案/郵件傳輸	20~60
UDP	無連線	不可靠	資料包文段	快	少	視訊/語音傳輸	8

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

• TCP首部(圖片來源於網路)：

  前20個位元組是固定的，後面有4n個位元組是根據需而增加的選項，所以TCP首部最小長度為20位元組。

• UDP首部(圖片來源於網路)：

  UDP的首部只有8個位元組，源埠號、目的埠號、長度和校驗和各兩個位元組。

TCP協議如何保證可靠傳輸　＊＊＊

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

• 校驗和：在傳送算和接收端分別計算資料的校驗和，如果兩者不一致，則說明資料在傳輸過程中出現了差錯，TCP將丟棄和不確認此報文段。

• 序列號：TCP會對每一個傳送的位元組進行編號，接收方接到資料後，會對傳送方傳送確認應答(ACK報文)，並且這個ACK報文中帶有相應的確認編號，告訴傳送方，下一次傳送的資料從編號多少開始發。如果傳送方傳送相同的資料，接收端也可以通過序列號判斷出，直接將資料丟棄。如果

• 超時重傳：在上面說了序列號的作用，但如果傳送方在傳送資料後一段時間內（可以設定重傳計時器規定這段時間）沒有收到確認序號ACK，那麼傳送方就會重新傳送資料。

  這裡傳送方沒有收到ACK可以分兩種情況，如果是傳送方傳送的資料包丟失了，接收方收到傳送方重新傳送的資料包後會馬上給傳送方傳送ACK；如果是接收方之前接收到了傳送方傳送的資料包，而返回給傳送方的ACK丟失了，這種情況，傳送方重傳後，接收方會直接丟棄傳送方衝重傳的資料包，然後再次傳送ACK響應報文。

  如果資料被重發之後還是沒有收到接收方的確認應答，則進行再次傳送。此時，等待確認應答的時間將會以2倍、4倍的指數函式延長，直到最後關閉連線。

• 流量控制：如果傳送端傳送的資料太快，接收端來不及接收就會出現丟包問題。為了解決這個問題，TCP協議利用了滑動視窗進行了流量控制。在TCP首部有一個16位欄位大小的視窗，視窗的大小就是接收端接收資料緩衝區的剩餘大小。接收端會在收到資料包後傳送ACK報文時，將自己的視窗大小填入ACK中，傳送方會根據ACK報文中的視窗大小進而控制傳送速度。如果視窗大小為零，傳送方會停止傳送資料。

• 擁塞控制：如果網路出現擁塞，則會產生丟包等問題，這時傳送方會將丟失的資料包繼續重傳，網路擁塞會更加嚴重，所以在網路出現擁塞時應注意控制傳送方的傳送資料，降低整個網路的擁塞程度。擁塞控制主要有四部分組成：慢開始、擁塞避免、快重傳、快恢復，如下圖(圖片來源於網路)。

  
  這裡的傳送方會維護一個擁塞視窗的狀態變數，它和流量控制的滑動視窗是不一樣的，滑動視窗是根據接收方資料緩衝區大小確定的，而擁塞視窗是根據網路的擁塞情況動態確定的，一般來說傳送方真實的傳送視窗為滑動視窗和擁塞視窗中的最小值。

  1. 慢開始：為了避免一開始傳送大量的資料而產生網路阻塞，會先初始化cwnd為1，當收到ACK後到下一個傳輸輪次，cwnd為2，以此類推成指數形式增長。

  2. 擁塞避免：因為cwnd的數量在慢開始是指數增長的，為了防止cwnd數量過大而導致網路阻塞，會設定一個慢開始的門限值ssthresh，當cwnd>=ssthresh時，進入到擁塞避免階段，cwnd每個傳輸輪次加1。但網路出現超時，會將門限值ssthresh變為出現超時cwnd數值的一半，cwnd重新設定為1，如上圖，在第12輪出現超時後，cwnd變為1，ssthresh變為12。

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

  
  從上圖可知，接收方正確地接收到M1和M2，而M3丟失，由於沒有接收到M3，在接收方收到M5、M6和M7時，並不會進行確認，也就是不會傳送ACK。這時根據前面說的保證TCP可靠性傳輸中的序列號的作用，接收方這時不會接收M5，M6，M7，接收方可以什麼都不會，因為傳送方長時間未收到M3的確認報文，會對M3進行重傳。除了這樣，接收方也可以重複傳送M2的確認報文，這樣傳送端長時間未收到M3的確認報文也會繼續傳送M3報文。

  但是根據快重傳演算法，要求在這種情況下，需要快速向傳送端傳送M2的確認報文，在傳送方收到三個M2的確認報文後，無需等待重傳計時器所設定的時間，可直接進行M3的重傳，這就是快重傳。(面試時說這一句就夠了，前面是幫助理解)

  4. 快恢復：從上上圖圈4可以看到，當傳送收到三個重複的ACK，會進行快重傳和快恢復。快恢復是指將ssthresh設定為發生快重傳時的cwnd數量的一半，而cwnd不是設定為1而是設定為為門限值ssthresh，並開始擁塞避免階段。

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

必考題

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

• 序號：seq，佔32位，用來標識從傳送端到接收端傳送的位元組流。
• 確認號：ack，佔32位，只有ACK標誌位為1時，確認序號欄位才有效，ack=seq+1。
• 標誌位：
  • SYN：發起一個新連線。
  • FIN：釋放一個連線。
  • ACK：確認序號有效。

三次握手

三次握手的本質就是確定傳送端和接收端具備收發資訊的能力，在能流暢描述三次握手的流程及其中的欄位含義作用的同時還需要記住每次握手時接收端和傳送端的狀態。這個比較容易忽略。

先看一張很經典的圖（圖片來源於網路），傳送端有CLOSED、SYN-SENT、ESTABLISHED三種狀態，接收端有CLOSED、LISTEN、SYN-RCVD、ESTABLISHED四種狀態。

假設傳送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是CLOSE。

• 第一次握手：客戶端向服務端發起建立連線請求，客戶端會隨機生成一個起始序列號x，客戶端向服務端傳送的欄位中包含標誌位SYN=1，序列號seq=100。第一次握手前客戶端的狀態為CLOSE，第一次握手後客戶端的狀態為SYN-SENT。此時服務端的狀態為LISTEN
• 第二次握手：服務端在收到客戶端發來的報文後，會隨機生成一個服務端的起始序列號y，然後給客戶端回覆一段報文，其中包括標誌位SYN=1，ACK=1，序列號seq=y，確認號ack=x+1。第二次握手前服務端的狀態為LISTEN，第二次握手後服務端的狀態為SYN-RCVD，此時客戶端的狀態為SYN-SENT。（其中SYN=1表示要和客戶端建立一個連線，ACK=1表示確認序號有效）
• 第三次握手：客戶端收到服務端發來的報文後，會再向服務端傳送報文，其中包含標誌位ACK=1，序列號seq=x+1，確認號ack=y+1。第三次握手前客戶端的狀態為SYN-SENT，第三次握手後客戶端和服務端的狀態都為ESTABLISHED。

需要注意的一點是，第一次握手，客戶端向服務端發起建立連線報文，會佔一個序列號。但是第三次握手，同樣是客戶端向服務端傳送報文，這次卻不佔序列號，所以建立連線後，客戶端向服務端傳送的第一個資料的序列號為x+1。

四次揮手

和三次握手一樣，先看一張非常經典的圖（圖片來源於網路），客戶端在四次揮手過程中有ESTABLISHED、FIN-WAIT-1、FIN-WAIT-2、TIME-WAIT、CLOSED等五個狀態，服務端有ESTABLISHED、CLOSE-WAIT、LAST-ACK、CLOSED等四種狀態。最好記住每次揮手時服務端和客戶端的狀態。
假設客戶端首先發起的斷開連線請求

• 第一次揮手：客戶端向服務端傳送的資料完成後，向服務端發起釋放連線報文，報文包含標誌位FIN=1，序列號seq=u。此時客戶端只能接收資料，不能向服務端傳送資料。
• 第二次揮手：服務端收到客戶端的釋放連線報文後，向客戶端傳送確認報文，包含標誌位ACK=1，序列號seq=v，確認號ack=u+1。此時客戶端到服務端的連線已經釋放掉，客戶端不能像服務端傳送資料，服務端也不能向客戶端傳送資料。但服務端到客戶端的單向連線還能正常傳輸資料。
• 第三次揮手：服務端傳送完資料後向客戶端發出連線釋放報文，報文包含標誌位FIN=1，標誌位ACK=1，序列號seq=w，確認號ack=u+1。
• 第四次揮手：客戶端收到服務端傳送的釋放連線請求，向服務端傳送確認報文，包含標誌位ACK=1，序列號seq=u+1，確認號ack=w+1。

為什麼TCP連線的時候是3次？兩次是否可以？

不可以，主要從以下兩方面考慮（假設客戶端是首先發起連線請求）：

1. 假設建立TCP連線僅需要兩次握手，那麼如果第二次握手時，服務端返回給客戶端的確認報文丟失了，客戶端這邊認為服務端沒有和他建立連線，而服務端卻以為已經和客戶端建立了連線，並且可能向服務端已經開始向客戶端傳送資料，但客戶端並不會接收這些資料，浪費了資源。如果是三次握手，不會出現雙方連線還未完全建立成功就開始傳送資料的情況。
2. 如果服務端接收到了一個早已失效的來自客戶端的連線請求報文，會向客戶端傳送確認報文同意建立TCP連線。但因為客戶端並不需要向服務端傳送資料，所以此次TCP連線沒有意義並且浪費了資源。

為什麼TCP連線的時候是3次，關閉的時候卻是4次？

因為需要確保通訊雙方都能通知對方釋放連線，假設客服端傳送完資料向服務端傳送釋放連線請求，當客服端並不知道，服務端是否已經傳送完資料，所以此次斷開的是客服端到服務端的單向連線，服務端返回給客戶端確認報文後，服務端還能繼續單向給客戶端傳送資料。當服務端傳送完資料後還需要向客戶端傳送釋放連線請求，客戶端返回確認報文，TCP連線徹底關閉。所以斷開TCP連線需要客戶端和服務端分別通知對方並分別收到確認報文，一共需要四次。

TIME_WAIT和CLOSE_WAIT的區別在哪?

預設客戶端首先發起斷開連線請求

• 從上圖可以看出，CLOSE_WAIT是被動關閉形成的，當客戶端傳送FIN報文，服務端返回ACK報文後進入CLOSE_WAIT。
• TIME_WAIT是主動關閉形成的，當第四次揮手完成後，客戶端進入TIME_WAIT狀態。

為什麼客戶端發出第四次揮手的確認報文後要等2MSL的時間才能釋放TCP連線？

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

1. 客戶端傳送第四次揮手中的報文後，再經過2MSL，可使本次TCP連線中的所有報文全部消失，不會出現在下一個TCP連線中。
2. 考慮丟包問題，如果第四揮手傳送的報文在傳輸過程中丟失了，那麼服務端沒收到確認ack報文就會重發第三次揮手的報文。如果客戶端傳送完第四次揮手的確認報文後直接關閉，而這次報文又恰好丟失，則會造成服務端無法正常關閉。

如果已經建立了連線，但是客戶端突然出現故障了怎麼辦？

如果TCP連線已經建立，在通訊過程中，客戶端突然故障，那麼服務端不會一直等下去，過一段時間就關閉連線了。具體原理是TCP有一個保活機制，主要用在伺服器端，用於檢測已建立TCP連結的客戶端的狀態，防止因客戶端崩潰或者客戶端網路不可達，而伺服器端一直保持該TCP連結，佔用伺服器端的大量資源(因為Linux系統中可以建立的總TCP連結數是有限制的)。

保活機制原理：設定TCP保活機制的保活時間keepIdle，即在TCP連結超過該時間沒有任何資料互動時，傳送保活探測報文；設定保活探測報文的傳送時間間隔keepInterval；設定保活探測報文的總髮送次數keepCount。如果在keepCount次的保活探測報文均沒有收到客戶端的回應，則伺服器端即關閉與客戶端的TCP連結。

具體細節請看這篇部落格TCP通訊過程中異常情況整理。

HTTP 與 HTTPS 的區別　＊＊＊

	HTTP	HTTPS
埠	80	443
安全性	無加密，安全性較差	有加密機制，安全性較高
資源消耗	較少	由於加密處理，資源消耗更多
是否需要證書	不需要	需要
協議	執行在TCP協議之上	執行在SSL協議之上，SSL執行在TCP協議之上

什麼是對稱加密與非對稱加密　＊＊

• 對稱加密

  對稱加密指加密和解密使用同一金鑰，優點是運算速度快，缺點是如何安全將金鑰傳輸給另一方。常見的對稱加密演算法有DES、AES等等。

• 非對稱加密

  非對稱加密指的是加密和解密使用不同的金鑰，一把公開的公鑰，一把私有的私鑰。公鑰加密的資訊只有私鑰才能解密，私鑰加密的資訊只有公鑰才能解密。優點解決了對稱加密中存在的問題。缺點是運算速度較慢。常見的非對稱加密演算法有RSA、DSA、ECC等等。

  非對稱加密的工作流程：A生成一對非堆成金鑰，將公鑰向所有人公開，B拿到A的公鑰後使用A的公鑰對資訊加密後傳送給A，經過加密的資訊只有A手中的私鑰能解密。這樣B可以通過這種方式將自己的公鑰加密後傳送給A，兩方建立起通訊，可以通過對方的公鑰加密要傳送的資訊，接收方用自己的私鑰解密資訊。

HTTPS的加密過程　＊＊＊

上面已經介紹了對稱加密和非對稱加密的優缺點，HTTPS是將兩者結合起來，使用的對稱加密和非對稱加密的混合加密演算法。具體做法就是使用非對稱加密來傳輸對稱金鑰來保證安全性，使用對稱加密來保證通訊的效率。

簡化的工作流程：服務端生成一對非對稱金鑰，將公鑰發給客戶端。客戶端生成對稱金鑰，用服務端發來的公鑰進行加密，加密後發給服務端。服務端收到後用私鑰進行解密，得到客戶端傳送的對稱金鑰。通訊雙方就可以通過對稱金鑰進行高效地通訊了。

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

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

HTTPS的加密過程：

1. 客戶端向服務端發起第一次握手請求，告訴服務端客戶端所支援的SSL的指定版本、加密演算法及金鑰長度等資訊。
2. 服務端將自己的公鑰發給數字證書認證機構，數字證書認證機構利用自己的私鑰對伺服器的公鑰進行數字簽名，並給伺服器頒發公鑰證書。
3. 服務端將證書發給客服端。
4. 客服端利用數字認證機構的公鑰，向數字證書認證機構驗證公鑰證書上的數字簽名，確認伺服器公開金鑰的真實性。
5. 客服端使用服務端的公開金鑰加密自己生成的對稱金鑰，發給服務端。
6. 服務端收到後利用私鑰解密資訊，獲得客戶端發來的對稱金鑰。
7. 通訊雙方可用對稱金鑰來加密解密資訊。

上述流程存在的一個問題是客戶端哪裡來的數字認證機構的公鑰，其實，在很多瀏覽器開發時，會內建常用數字證書認證機構的公鑰。

流程圖如下：

常用HTTP狀態碼　＊＊＊

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

狀態碼	類別
1XX	資訊性狀態碼
2XX	成功狀態碼
3XX	重定向狀態碼
4XX	客戶端錯誤狀態碼
5XX	服務端錯誤狀態碼

常見的HTTP狀態碼

1XX

• 100 Continue：表示正常，客戶端可以繼續傳送請求
• 101 Switching Protocols：切換協議，伺服器根據客戶端的請求切換協議。

2XX

• 200 OK：請求成功
• 201 Created：已建立，表示成功請求並建立了新的資源
• 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：所請求的資源未修改，伺服器返回此狀態碼時，不會返回任何資源。
• 305 Use Proxy：所請求的資源必須通過代理訪問
• 307 Temporary Redirect： 臨時重定向，與302類似，要求使用get請求重定向。

4XX

• 400 Bad Request：客戶端請求的語法錯誤，伺服器無法理解。
• 401 Unauthorized：表示傳送的請求需要有認證資訊。
• 403 Forbidden：伺服器理解使用者的請求，但是拒絕執行該請求
• 404 Not Found：伺服器無法根據客戶端的請求找到資源。
• 405 Method Not Allowed：客戶端請求中的方法被禁止
• 406 Not Acceptable：伺服器無法根據客戶端請求的內容特性完成請求
• 408 Request Time-out：伺服器等待客戶端傳送的請求時間過長，超時

5XX

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

常見的HTTP方法　＊＊＊

方法	作用
GET	獲取資源
POST	傳輸實體主體
PUT	上傳檔案
DELETE	刪除檔案
HEAD	和GET方法類似，但只返回報文首部，不返回報文實體主體部分
PATCH	對資源進行部分修改
OPTIONS	查詢指定的URL支援的方法
CONNECT	要求用隧道協議連線代理
TRACE	伺服器會將通訊路徑返回給客戶端

為了方便記憶，可以將PUT、DELETE、POST、GET理解為客戶端對服務端的增刪改查。

• PUT：上傳檔案，向伺服器新增資料，可以看作增
• DELETE：刪除檔案
• POST：傳輸資料，向伺服器提交資料，對伺服器資料進行更新。
• GET：獲取資源，查詢伺服器資源

GET和POST區別　＊＊＊

• 作用

  GET用於獲取資源，POST用於傳輸實體主體

• 引數位置

  GET的引數放在URL中，POST的引數儲存在實體主體中，並且GET方法提交的請求的URL中的資料做多是2048位元組，POST請求沒有大小限制。

• 安全性

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

• 冪等性

  GET方法是具有冪等性的，而POST方法不具有冪等性。這裡冪等性指客戶端連續發出多次請求，收到的結果都是一樣的.

HTTP 1.0、HTTP 1.1及HTTP 2.0的主要區別是什麼　＊＊

HTTP 1.0和HTTP 1.1的區別

• 長連線

  HTTP 1.1支援長連線和請求的流水線操作。長連線是指不在需要每次請求都重新建立一次連線，HTTP 1.0預設使用短連線，每次請求都要重新建立一次TCP連線，資源消耗較大。請求的流水線操作是指客戶端在收到HTTP的響應報文之前可以先傳送新的請求報文，不支援請求的流水線操作需要等到收到HTTP的響應報文後才能繼續傳送新的請求報文。

• 快取處理

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

• 錯誤狀態碼

  在HTTP 1.1新增了24個錯誤狀態響應碼

• HOST域

  在HTTP 1.0 中認為每臺伺服器都會繫結唯一的IP地址，所以，請求中的URL並沒有傳遞主機名。但後來一臺伺服器上可能存在多個虛擬機器，它們共享一個IP地址，所以HTTP 1.1中請求訊息和響應訊息都應該支援Host域。

• 頻寬優化及網路連線的使用

  在HTTP 1.0中會存在浪費頻寬的現象，主要是因為不支援斷點續傳功能，客戶端只是需要某個物件的一部分，服務端卻將整個物件都傳了過來。在HTTP 1.1中請求頭引入了range頭域，它支援只請求資源的某個部分，返回的狀態碼為206。

HTTP 2.0的新特性

• 新的二進位制格式：HTTP 1.x的解析是基於文字，HTTP 2.0的解析採用二進位制，實現方便，健壯性更好。
• 多路複用：每一個request對應一個id，一個連線上可以有多個request，每個連線的request可以隨機混在一起，這樣接收方可以根據request的id將request歸屬到各自不同的服務端請求裡。
• header壓縮：在HTTP 1.x中，header攜帶大量資訊，並且每次都需要重新傳送，HTTP 2.0採用編碼的方式減小了header的大小，同時通訊雙方各自快取一份header fields表，避免了header的重複傳輸。
• 服務端推送：客戶端在請求一個資源時，會把相關資源一起發給客戶端，這樣客戶端就不需要再次發起請求。

Session、Cookie和Token的主要區別　＊＊＊

HTTP協議是無狀態的，即伺服器無法判斷使用者身份。Session和Cookie可以用來進行身份辨認。

• Cookie

  Cookie是儲存在客戶端一個小資料塊，其中包含了使用者資訊。當客戶端向服務端發起請求，服務端會像客戶端瀏覽器傳送一個Cookie，客戶端會把Cookie存起來，當下次客戶端再次請求服務端時，會攜帶上這個Cookie，服務端會通過這個Cookie來確定身份。

• Session

  Session是通過Cookie實現的，和Cookie不同的是，Session是存在服務端的。當客戶端瀏覽器第一次訪問伺服器時，伺服器會為瀏覽器建立一個sessionid，將sessionid放到Cookie中，存在客戶端瀏覽器。比如瀏覽器訪問的是購物網站，將一本《圖解HTTP》放到了購物車，當瀏覽器再次訪問伺服器時，伺服器會取出Cookie中的sessionid，並根據sessionid獲取會話中的儲存的資訊，確認瀏覽器的身份是上次將《圖解HTTP》放入到購物車那個使用者。

• Token

  客戶端在瀏覽器第一次訪問服務端時，服務端生成的一串字串作為Token發給客戶端瀏覽器，下次瀏覽器在訪問服務端時攜帶token即可無需驗證使用者名稱和密碼，省下來大量的資源開銷。看到這裡很多人感覺這不是和sessionid作用一樣嗎？其實是不一樣的，但是本文章主要針對面試，知識點很多，篇幅有限，幾句話也解釋不清楚，大家可以看看這篇文章，我覺得說的非常清楚了。cookie、session與token的真正區別

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

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

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

可以，Session的作用是在服務端來保持狀態，通過sessionid來進行確認身份，但sessionid一般是通過Cookie來進行傳遞的。如果Cooike被禁用了，可以通過在URL中傳遞sessionid。

在瀏覽器中輸⼊url地址到顯示主⻚的過程　＊＊＊

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

1. 對輸入到瀏覽器的url進行DNS解析，將域名轉換為IP地址。
2. 和目的伺服器建立TCP連線
3. 向目的伺服器傳送HTTP請求
4. 伺服器處理請求並返回HTTP報文
5. 瀏覽器解析並渲染頁面

Servlet是執行緒安全的嗎　＊

Servlet不是執行緒安全的，多執行緒的讀寫會導致資料不同步的問題。