HTTPS總結+相關面試問題解答

LuckyRoc發表於2019-01-17
HTTP面試

TCP/IP

TCP/IP 不是一個協議，而是一個協議族的統稱。裡面包括了 IP 協議，IMCP 協議，TCP 協議，以及我們更加熟悉的http、ftp、pop3協議等等。電腦有了這些，就好像學會了外語一樣，就可以和其他的計算機終端做自由的交流了。

TCP / IP 協議分層

  • 應用層

向使用者提供一組常用的應用程式，如電子郵件（簡單郵件傳輸協議，SMTP），檔案傳輸訪問（檔案傳輸協議，FTP），遠端登入（TELNET）等。

  • 傳輸層: 負責提供應用程式間的通訊 格式化資訊流； 提供可靠傳輸。為實現後者，傳輸層協議規定接收端必須發回確認，並且假如分組丟失，必須重新傳送

  • 網路層:負責相鄰計算機之間的通訊

    • 處理來自傳輸層的分組傳送請求：收到請求之後，將分組裝入 IP 資料包，填充報頭，選擇去往信宿機的路徑，然後將資料包發往適當的網路介面；
    • 處理輸入資料包：首先檢查其合法性，然後進行定址：如果該資料包已經到達信宿機，則去掉報頭，將剩下一部分交給適當的傳輸協議；如果該資料包尚未到達信宿機，則轉發該資料包；
    • 處理路徑、流控、擁塞等問題；

  • 網路介面層: 這是 TCP / IP 的最底層，負責接收 IP 資料包並通過網路傳送資料包，或者從網路上接收物理幀，抽出 IP 資料包，交給 IP 層；

TCP的三次握手

  • 第一次握手(SYN=1, seq=x):

客戶端傳送一個 TCP 的 SYN標誌位置1的包，指明客戶端打算連線的伺服器的埠，以及初始序號 X,儲存在包頭的序列號(Sequence Number)欄位裡。

傳送完畢後，客戶端進入 SYN_SEND 狀態。

  • 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

伺服器發回確認包(ACK)應答。即 SYN 標誌位和 ACK 標誌位均為1。伺服器端選擇自己 ISN 序列號，放到 Seq 域裡，同時將確認序號(Acknowledgement Number)設定為客戶的 ISN 加1，即X+1。

傳送完畢後，伺服器端進入 SYN_RCVD 狀態。

  • 第三次握手(ACK=1，ACKnum=y+1)

客戶端再次傳送確認包(ACK)，SYN 標誌位為0，ACK 標誌位為1，並且把伺服器發來 ACK 的序號欄位+1，放在確定欄位中傳送給對方，並且在資料段放寫ISN的+1

傳送完畢後，客戶端進入 ESTABLISHED 狀態，當伺服器端接收到這個包時，也進入 ESTABLISHED 狀態，連線建立成功，TCP 握手結束。

白話解釋大概是這樣的：

1. 隔壁老王：李四麼，我隔壁老王哈，聽得到麼？
2. 李四：老王哈，聽得到，你聽得到我麼？
3. 隔壁老王：聽得到，你說
接下來就可以進行愉快的對話了。。。
複製程式碼

可不可以1次握手？

1. 隔壁老王：老李麼，我隔壁老王哈，聽得到麼？
複製程式碼

如果只有一次握手，隔壁老王根本不知道李四是否聽到了？

溝通失敗！

可不可以2次握手？

1. 隔壁老王：老李麼，我隔壁老王哈，聽得到麼？
2. 李四：老王哈，聽得到，你聽得到我麼？
複製程式碼

李四聽到了老王的對話，但是呢？李四不知道老王是否聽到了？

溝通失敗！

只有老王回覆了，雙方才知道： 哦！我們說的話對方都是可以聽到的。

TCP的4次揮手

  • 第一次揮手：主機1（可以使客戶端，也可以是伺服器端），設定Sequence Number和Acknowledgment Number，向主機2傳送一FIN報文段；此時，主機1進入FIN_WAIT_1狀態；這表示主機1沒有資料要傳送給主機2了；
  • 第二次揮手：主機2收到了主機1傳送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number和Sequence Number加1；主機1進入FIN_WAIT_2狀態；主機2告訴主機1，我“同意”你的關閉請求；
  • 第三次揮手：主機2向主機1傳送FIN報文段，請求關閉連線，同時主機2進入LAST_ACK狀態；
  • 第四次揮手：主機1收到主機2傳送的FIN報文段，向主機2傳送ACK報文段，然後主機1進入TIME_WAIT狀態；主機2收到主機1的ACK報文段以後，就關閉連線；此時，主機1等待2MSL後依然沒有收到回覆，則證明Server端已正常關閉，那好，主機1也可以關閉連線了。

HTTP

HTTP（HyperText Transfer Protocol），超文字傳輸協議，是一個基於TCP實現的應用層協議。

HTTPS

HTTPS 是最流行的 HTTP 安全形式。它是由網景公司首創的，所有主要的瀏覽器和 伺服器都支援此協議。

使用 HTTPS 時，所有的 HTTP 請求和響應資料在傳送到網路之前，都要進行加密。 HTTPS 在 HTTP 下面提供了一個傳輸級的密碼安全層——可以使用 SSL，也可以使用其後繼者—— 傳輸層安全(Transport Layer Security，TLS)。由於 SSL 和 TLS 非常類似，所以我們不太嚴格地用術語 SSL 來表示 SSL 和 TLS。

httpsImage

SSL/TLS

不使用SSL/TLS的HTTP通訊，就是不加密的通訊。所有資訊明文傳播，帶來了三大風險。

  • 竊聽風險（eavesdropping）：第三方可以獲知通訊內容。
  • 篡改風險（tampering）：第三方可以修改通訊內容。
  • 冒充風險（pretending）：第三方可以冒充他人身份參與通訊。

SSL/TLS協議是為了解決這三大風險而設計的，希望達到：

  • 所有資訊都是加密傳播，第三方無法竊聽。
  • 具有校驗機制，一旦被篡改，通訊雙方會立刻發現。
  • 配備身份證書，防止身份被冒充。

SSL握手

開始加密通訊之前，客戶端和伺服器首先必須建立連線和交換引數，這個過程叫做握手（handshake）,握手階段分成五步：

  1. 客戶端給出協議版本號、一個客戶端生成的 隨機數 A（Client random），以及客戶端支援的加密方法。 客戶端（A）
  2. 伺服器確認雙方使用的加密方法，獲取到A，並給出數字證書、以及一個伺服器生成的隨機數B（Server random）。伺服器（A、B）
  3. 客戶端確認數字證書有效，獲取到B，然後生成一個新的 隨機數 C（Premaster secret），並使用數字證書中的公鑰，加密這個隨機數，發給伺服器。客戶端（A、B、C）
  4. 伺服器使用自己的私鑰，獲取客戶端發來的隨機數C（即Premaster secret）。伺服器（A、B、C）
  5. 客戶端和伺服器根據約定的加密方法，使用前面的三個隨機數 A、B、C 生成 對話金鑰（session key），用來加密接下來的整個對話過程。

HTTPS總結+相關面試問題解答

常見面試題：

HTTP和HTTPS的區別？

  • HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭
  • HTTP 是不安全的，而 HTTPS 是安全的
  • HTTP 標準埠是80 ，而 HTTPS 的標準埠是443
  • 在OSI 網路模型中，HTTP工作於應用層，而HTTPS 的安全傳輸機制工作在傳輸層
  • HTTP 無法加密，而HTTPS 對傳輸的資料進行加密
  • HTTP無需證書，而HTTPS 需要CA機構wosign的頒發的SSL證書

如何理解HTTP是無狀態的協議？

無狀態協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊 也就是說，當客戶端一次HTTP請求完成以後，客戶端再傳送一次HTTP請求，HTTP並不知道當前客戶端是一個”老使用者“

如何解決HTTP的無狀態協議？

使用Cookie來解決無狀態的問題，Cookie就相當於一個通行證，第一次訪問的時候給客戶端傳送一個Cookie，當客戶端再次來的時候，拿著Cookie(通行證)，那麼伺服器就知道這個是”老使用者“。

常用的HTTP方法有哪些？

  • GET： 用於請求訪問已經被URI（統一資源識別符號）識別的資源，可以通過URL傳參給伺服器
  • POST：用於傳輸資訊給伺服器，主要功能與GET方法類似，但一般推薦使用POST方式。
  • PUT： 傳輸檔案，報文主體中包含檔案內容，儲存到對應URI位置。
  • HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用於驗證URI是否有效。
  • DELETE：刪除檔案，與PUT方法相反，刪除對應URI位置的檔案。
  • OPTIONS：查詢相應URI支援的HTTP方法。

GET/POST的區別？

  • GET的語義是請求獲取指定的資源。GET方法是安全、冪等、可快取的（除非有 Cache-ControlHeader的約束）,GET方法的報文主體沒有任何語義。

  • POST的語義是根據請求負荷（報文主體）對指定的資源做出處理，具體的處理方式視資源型別而不同。POST不安全，不冪等，（大部分實現）不可快取。

安全、冪等、快取是什麼？

  • 安全

如果一個方法的語義在本質上是「只讀」的，那麼這個方法就是安全的。客戶端向服務端的資源發起的請求如果使用了是安全的方法，就不應該引起服務端任何的狀態變化，因此也是無害的。 此RFC定義，GET, HEAD, OPTIONS 和 TRACE 這幾個方法是安全的。

  • 冪等

指同一個請求方法執行多次和僅執行一次的效果完全相同

  • 快取

顧名思義就是一個方法是否可以被快取，此RFC裡GET，HEAD和某些情況下的POST都是可快取的，但是絕大多數的瀏覽器的實現裡僅僅支援GET和HEAD。

為什麼要三次握手？

防止伺服器端的一直等待而浪費資源。防止接收方收不到資訊而已，傳送方也不知道接收方收到還是沒收到

相關文章