之前總結了一次TCP/HTTP的面試題，這次又補充了一些其他計算機網絡的面試題，為方便閱讀整理到了一起，并按照面試中提問的頻率做了標注（星數越高，面試中提問頻率越高），如有幫到你，可以收藏點贊支持哦。>

推薦閱讀：

• 一文搞懂所有Java基礎知識面試題

• 一文搞懂所有Java集合面試題

  什么是網絡協議，為什么要對網絡協議分層　＊

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

  網絡分層的原因：

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

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

  計算機網絡體系可以大致分為一下三種，七層模型、五層模型和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：確認序號有效。

三次握手

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

假設發送端為客戶端，接收端為服務端。開始時客戶端和服務端的狀態都是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等四種狀態。最好記住每次揮手時服務端和客戶端的狀態。 假設客戶端首先發起的斷開連接請求

image.png

*   第一次揮手：客戶端向服務端發送的數據完成后，向服務端發起釋放連接報文，報文包含標志位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不是線程安全的，多線程的讀寫會導致數據不同步的問題。

本文在開源項目：https://github.com/Android-Alvin/Android-LearningNotes 中已收錄，里面包含不同方向的自學編程路線、面試題集合/面經、及系列技術文章等，資源持續更新中...

Android中高級面試題大全