學習計算機網絡必會的知識點，你學廢了嗎

推薦閱讀：

• 一文搞定全部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，在接收方收到M五、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-一、FIN-WAIT-二、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不是線程安全的，多線程的讀寫會致使數據不一樣步的問題。