計算機網路 基礎面試第二彈

空慧居士發表於2023-10-07
計算機網路面試

1. TCP三次握手和四次揮手

TCP三次握手的過程如下：

  1. 第一步（SYN）：客戶端向伺服器傳送一個帶有SYN（同步）標誌的TCP包，指示客戶端希望建立連線。這個包包含一個隨機的初始序列號（ISN）。

  2. 第二步（SYN-ACK）：伺服器收到客戶端的SYN包後，會傳送一個帶有SYN和ACK（確認）標誌的TCP包作為回應。伺服器也會為自己選擇一個初始序列號，並將客戶端的初始序列號加一作為確認號。

  3. 第三步（ACK）：客戶端收到伺服器的SYN-ACK包後，會傳送一個帶有ACK標誌的TCP包作為確認。客戶端將伺服器的初始序列號加一作為確認號。

TCP四次揮手的過程如下：

  1. 第一步（FIN）：當客戶端決定關閉連線時，它傳送一個帶有FIN（結束）標誌的TCP包給伺服器，表示客戶端不再傳送資料。

  2. 第二步（ACK）：伺服器收到客戶端的FIN包後，傳送一個帶有ACK標誌的TCP包作為確認。伺服器仍然可以傳送資料給客戶端，因為這個ACK只是確認收到了客戶端的FIN。

  3. 第三步（FIN）：當伺服器也決定關閉連線時，它傳送一個帶有FIN標誌的TCP包給客戶端，表示伺服器不再傳送資料。

  4. 第四步（ACK）：客戶端收到伺服器的FIN包後，傳送一個帶有ACK標誌的TCP包作為確認。這個ACK告訴伺服器，客戶端已經接收到了伺服器的FIN，連線可以安全關閉。

  5.  

2. 為什麼TCP需要三次握手而不是二次

  1. 確認雙方的傳送和接收能力：在進行握手之前，無法確定雙方的傳送和接收能力是否正常。透過三次握手，客戶端和伺服器都能確保對方能夠接收自己傳送的資料。如果只有兩次握手，那麼無法確認對方是否能夠正常接收資料。

  2. 防止已失效的連線請求被接受：考慮這樣一種情況，客戶端傳送了一個連線請求，但由於某種原因在網路中滯留，導致伺服器沒有收到該請求。如果只有兩次握手，那麼客戶端會以為連線已經建立，但實際上伺服器並不知道這個連線，這樣會導致資源的浪費。透過三次握手，伺服器可以確認客戶端的請求是有效的，並避免處理無效的連線請求。

  3. 防止已失效的連線請求被重複開啟：考慮這樣一種情況，客戶端傳送了一個連線請求，伺服器接收到併傳送了確認，但由於網路問題，客戶端沒有收到伺服器的確認。如果只有兩次握手，客戶端會重新傳送連線請求，然後連線就建立了。而實際上，之前的連線請求已經到達伺服器並得到了確認，這樣就會導致重複開啟相同的連線。透過三次握手，可以確保之前的連線已經失效，並避免重複開啟連線。

總而言之，透過三次握手，TCP協議能夠確保連線的可靠性和一致性，同時避免了因網路問題或延遲而導致的連線建立錯誤。

3. GET請求和 POST 請求的區別

  1. 資料傳輸方式：

    • GET請求：透過URL引數傳輸資料。引數以鍵值對的形式附加在URL的末尾，例如：http://example.com/path?param1=value1&param2=value2。GET請求將資料作為URL的一部分，因此在請求中可以直接看到傳輸的資料。
    • POST請求：透過請求體傳輸資料。資料被封裝在請求的訊息體中傳送給伺服器，而不是作為URL的一部分。因此，在請求中無法直接看到傳輸的資料。

  2. 資料傳輸安全性：

    • GET請求：由於資料暴露在URL中，因此在傳輸過程中可能被攔截和擷取。這意味著敏感資訊（例如密碼）不應該以明文形式出現在GET請求的URL中。
    • POST請求：由於資料傳輸在請求體中，並且在傳輸過程中不可見，相對來說比GET請求更安全，適合傳輸敏感資訊。

  3. 資料長度限制：

    • GET請求：由於資料透過URL引數傳輸，URL的長度是有限制的。不同的瀏覽器和伺服器對URL長度的限制不同，但通常存在長度限制，超過限制可能導致截斷或請求失敗。
    • POST請求：由於資料傳輸在請求體中，沒有明確的長度限制。但是，伺服器和應用程式可能有對請求體大小的限制。

  4. 資料語義：

    • GET請求：GET請求通常用於獲取資源或從伺服器獲取資料。它是冪等的，即多次相同的GET請求應該返回相同的結果，不會對伺服器產生副作用。
    • POST請求：POST請求通常用於向伺服器提交資料，用於建立、更新或修改資源。它可能會對伺服器產生副作用，例如在資料庫中建立新的記錄。

  5. 快取：

    • GET請求：由於GET請求的冪等性，響應可以被快取。瀏覽器或代理伺服器可以快取GET請求的響應，以提高效能和減少網路流量。
    • POST請求：POST請求的響應預設情況下不會被快取，因為POST請求可能會對伺服器產生副作用，每次請求的結果可能不同。

4. 瀏覽器輸入URL處理過程

  1. URL解析：瀏覽器會解析輸入的URL，將其分解成不同的組成部分。這些部分包括協議（如HTTP或HTTPS）、主機名（如example.com）、埠號（如果指定了特定埠，預設為80或443）、路徑（如/page）和查詢引數（如?param1=value1）等。

  2. DNS解析：瀏覽器將主機名（例如example.com）傳送給DNS（域名系統）伺服器，以獲取對應的IP地址。DNS伺服器會返回一個或多個IP地址，瀏覽器會選擇其中一個作為目標伺服器的IP地址。

  3. 建立TCP連線：使用目標伺服器的IP地址和指定的埠號，瀏覽器嘗試建立與伺服器的TCP連線。這涉及到三次握手過程，確保客戶端和伺服器之間的可靠連線。

  4. 發起HTTP請求：一旦建立了TCP連線，瀏覽器會構建HTTP請求訊息。該訊息包括請求方法（如GET或POST）、路徑、查詢引數、請求頭（如User-Agent、Accept等）和請求體（對於POST請求）。然後，瀏覽器將該請求訊息傳送給伺服器。

  5. 伺服器處理請求：伺服器接收到瀏覽器的請求後，會根據請求的路徑和引數執行相應的處理邏輯。這可能涉及到讀取檔案、呼叫後端API、查詢資料庫等操作。

  6. 伺服器傳送響應：伺服器根據請求的處理結果生成HTTP響應訊息。響應訊息包括狀態碼（如200表示成功、404表示未找到等）、響應頭（如Content-Type、Content-Length等）和響應體（包含實際的資料或HTML內容等）。伺服器將響應訊息傳送回瀏覽器。

  7. 接收和解析響應：瀏覽器接收到伺服器的響應後，會根據響應頭中的資訊進行處理。這可能包括處理Cookie、快取響應、解壓縮響應等操作。同時，瀏覽器會解析響應體中的資料，如HTML內容、CSS樣式表、JavaScript程式碼等。

  8. 渲染頁面：一旦瀏覽器解析完響應體中的HTML、CSS和JavaScript，它會開始渲染頁面。這包括將HTML解析為DOM樹、應用CSS樣式、執行JavaScript程式碼、載入和顯示影像等操作。

  9. 關閉TCP連線：當瀏覽器完成頁面渲染後，它會關閉與伺服器的TCP連線。這是透過四次揮手過程完成的，確保雙方都知道連線已經關閉。

5. HTTPS 實現原理

HTTPS（HyperText Transfer Protocol Secure）是在傳輸層上基於TLS/SSL協議的安全版本的HTTP協議。它使用加密和身份驗證機制，確保在客戶端和伺服器之間傳輸的資料的保密性和完整性。下面是HTTPS的實現原理：

  1. 客戶端發起連線請求：當使用者在瀏覽器中輸入HTTPS的URL時，瀏覽器會向伺服器發起連線請求。這個請求是透過預設的HTTPS埠（通常為443）傳送的。

  2. 伺服器證照：伺服器在回應客戶端的連線請求時，會將自己的公鑰和數字證照一起傳送給客戶端。數字證照是由受信任的證照頒發機構（CA）頒發的，用於驗證伺服器的身份。

  3. 客戶端驗證證照：客戶端收到伺服器的證照後，會驗證證照的合法性。它會檢查證照的有效性、是否由受信任的CA簽發、是否過期等。如果證照驗證透過，客戶端可以繼續與伺服器建立安全連線；否則，會出現警告或錯誤提示。

  4. 客戶端生成會話金鑰：如果伺服器的證照驗證透過，客戶端會生成一個隨機的會話金鑰，用於後續的對稱加密通訊。會話金鑰是一個對稱金鑰，意味著它在客戶端和伺服器之間共享。

  5. 客戶端傳送加密請求：客戶端會使用伺服器的公鑰對會話金鑰進行加密，然後將加密後的會話金鑰傳送給伺服器。這樣，只有伺服器能夠解密會話金鑰，確保了會話金鑰的安全傳輸。

  6. 伺服器解密會話金鑰：伺服器收到客戶端傳送的加密會話金鑰後，使用自己的私鑰對其進行解密，恢復得到原始的會話金鑰。

  7. 客戶端和伺服器建立加密通訊：客戶端和伺服器現在都擁有相同的會話金鑰，它們使用對稱加密演演算法來加密和解密透過網路傳輸的資料。這樣，客戶端和伺服器之間的通訊就變得安全起來，第三方無法輕易地獲取或篡改傳輸的資料。

透過以上步驟，HTTPS實現了資料的加密和伺服器身份的驗證。它提供了端到端的安全性，確保敏感資訊在傳輸過程中不被竊取或篡改。同時，HTTPS還可以防止中間人攻擊，因為第三方無法輕易地解密和篡改透過SSL/TLS協議加密的資料。

6. 對稱加密和非對稱加密區別

  1. 金鑰數量：

    • 對稱加密：對稱加密使用相同的金鑰進行加密和解密。這意味著加密和解密雙方需要共享相同的金鑰。因此，對稱加密只需要一個金鑰。
    • 非對稱加密：非對稱加密使用一對金鑰，分別是公鑰和私鑰。公鑰用於加密資料，私鑰用於解密資料。這意味著加密和解密使用的是不同的金鑰。因此，非對稱加密需要兩個金鑰。

  2. 加密和解密速度：

    • 對稱加密：對稱加密演演算法通常比非對稱加密演演算法更快速和高效，因為加密和解密使用相同的金鑰，演演算法較為簡單。
    • 非對稱加密：非對稱加密演演算法相對較慢，因為加密和解密使用不同的金鑰，演演算法較為複雜。

  3. 金鑰分發：

    • 對稱加密：在對稱加密中，金鑰需要在加密和解密雙方之間進行安全地分發。這可能存在安全性問題，因為如果金鑰在傳輸過程中被竊取，加密的資料也將不再安全。
    • 非對稱加密：非對稱加密中，公鑰可以公開分發，而私鑰必須保持機密。這樣，無需在加密和解密雙方之間共享私鑰，提供了更好的金鑰管理和分發的安全性。

  4. 安全性：

    • 對稱加密：對稱加密演演算法在加密和解密過程中使用相同的金鑰，因此，如果金鑰被洩露，加密的資料將容易受到攻擊。對稱加密的安全性依賴於金鑰的保密性。
    • 非對稱加密：非對稱加密使用不同的金鑰進行加密和解密，並且私鑰必須保持機密。即使公鑰被洩露，攻擊者也無法輕易獲取私鑰，因此非對稱加密提供了更高的安全性。

相關文章