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

TCP三次握手的過程如下：

1. 第一步（SYN）：客戶端向服務器發(fā)送一個帶有SYN（同步）標志的TCP包，指示客戶端希望建立連接。這個包包含一個隨機的初始序列號（ISN）。

2. 第二步（SYN-ACK）：服務器收到客戶端的SYN包后，會發(fā)送一個帶有SYN和ACK（確認）標志的TCP包作為回應。服務器也會為自己選擇一個初始序列號，并將客戶端的初始序列號加一作為確認號。

3. 第三步（ACK）：客戶端收到服務器的SYN-ACK包后，會發(fā)送一個帶有ACK標志的TCP包作為確認?？蛻舳藢⒎掌鞯某跏夹蛄刑柤右蛔鳛榇_認號。

TCP四次揮手的過程如下：

1. 第一步（FIN）：當客戶端決定關閉連接時，它發(fā)送一個帶有FIN（結(jié)束）標志的TCP包給服務器，表示客戶端不再發(fā)送數(shù)據(jù)。

2. 第二步（ACK）：服務器收到客戶端的FIN包后，發(fā)送一個帶有ACK標志的TCP包作為確認。服務器仍然可以發(fā)送數(shù)據(jù)給客戶端，因為這個ACK只是確認收到了客戶端的FIN。

3. 第三步（FIN）：當服務器也決定關閉連接時，它發(fā)送一個帶有FIN標志的TCP包給客戶端，表示服務器不再發(fā)送數(shù)據(jù)。

4. 第四步（ACK）：客戶端收到服務器的FIN包后，發(fā)送一個帶有ACK標志的TCP包作為確認。這個ACK告訴服務器，客戶端已經(jīng)接收到了服務器的FIN，連接可以安全關閉。

5. ?

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

1. 確認雙方的發(fā)送和接收能力：在進行握手之前，無法確定雙方的發(fā)送和接收能力是否正常。通過三次握手，客戶端和服務器都能確保對方能夠接收自己發(fā)送的數(shù)據(jù)。如果只有兩次握手，那么無法確認對方是否能夠正常接收數(shù)據(jù)。

2. 防止已失效的連接請求被接受：考慮這樣一種情況，客戶端發(fā)送了一個連接請求，但由于某種原因在網(wǎng)絡中滯留，導致服務器沒有收到該請求。如果只有兩次握手，那么客戶端會以為連接已經(jīng)建立，但實際上服務器并不知道這個連接，這樣會導致資源的浪費。通過三次握手，服務器可以確認客戶端的請求是有效的，并避免處理無效的連接請求。

3. 防止已失效的連接請求被重復打開：考慮這樣一種情況，客戶端發(fā)送了一個連接請求，服務器接收到并發(fā)送了確認，但由于網(wǎng)絡問題，客戶端沒有收到服務器的確認。如果只有兩次握手，客戶端會重新發(fā)送連接請求，然后連接就建立了。而實際上，之前的連接請求已經(jīng)到達服務器并得到了確認，這樣就會導致重復打開相同的連接。通過三次握手，可以確保之前的連接已經(jīng)失效，并避免重復打開連接。

總而言之，通過三次握手，TCP協(xié)議能夠確保連接的可靠性和一致性，同時避免了因網(wǎng)絡問題或延遲而導致的連接建立錯誤。

3. GET請求和 POST 請求的區(qū)別

1. 數(shù)據(jù)傳輸方式：

   • GET請求：通過URL參數(shù)傳輸數(shù)據(jù)。參數(shù)以鍵值對的形式附加在URL的末尾，例如：http://example.com/path?param1=value1&param2=value2。GET請求將數(shù)據(jù)作為URL的一部分，因此在請求中可以直接看到傳輸?shù)臄?shù)據(jù)。
   • POST請求：通過請求體傳輸數(shù)據(jù)。數(shù)據(jù)被封裝在請求的消息體中發(fā)送給服務器，而不是作為URL的一部分。因此，在請求中無法直接看到傳輸?shù)臄?shù)據(jù)。

2. 數(shù)據(jù)傳輸安全性：

   • GET請求：由于數(shù)據(jù)暴露在URL中，因此在傳輸過程中可能被攔截和截取。這意味著敏感信息（例如密碼）不應該以明文形式出現(xiàn)在GET請求的URL中。
   • POST請求：由于數(shù)據(jù)傳輸在請求體中，并且在傳輸過程中不可見，相對來說比GET請求更安全，適合傳輸敏感信息。

3. 數(shù)據(jù)長度限制：

   • GET請求：由于數(shù)據(jù)通過URL參數(shù)傳輸，URL的長度是有限制的。不同的瀏覽器和服務器對URL長度的限制不同，但通常存在長度限制，超過限制可能導致截斷或請求失敗。
   • POST請求：由于數(shù)據(jù)傳輸在請求體中，沒有明確的長度限制。但是，服務器和應用程序可能有對請求體大小的限制。

4. 數(shù)據(jù)語義：

   • GET請求：GET請求通常用于獲取資源或從服務器獲取數(shù)據(jù)。它是冪等的，即多次相同的GET請求應該返回相同的結(jié)果，不會對服務器產(chǎn)生副作用。
   • POST請求：POST請求通常用于向服務器提交數(shù)據(jù)，用于創(chuàng)建、更新或修改資源。它可能會對服務器產(chǎn)生副作用，例如在數(shù)據(jù)庫中創(chuàng)建新的記錄。

5. 緩存：

   • GET請求：由于GET請求的冪等性，響應可以被緩存。瀏覽器或代理服務器可以緩存GET請求的響應，以提高性能和減少網(wǎng)絡流量。
   • POST請求：POST請求的響應默認情況下不會被緩存，因為POST請求可能會對服務器產(chǎn)生副作用，每次請求的結(jié)果可能不同。

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

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

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

3. 建立TCP連接：使用目標服務器的IP地址和指定的端口號，瀏覽器嘗試建立與服務器的TCP連接。這涉及到三次握手過程，確?？蛻舳撕头掌髦g的可靠連接。

4. 發(fā)起HTTP請求：一旦建立了TCP連接，瀏覽器會構(gòu)建HTTP請求消息。該消息包括請求方法（如GET或POST）、路徑、查詢參數(shù)、請求頭（如User-Agent、Accept等）和請求體（對于POST請求）。然后，瀏覽器將該請求消息發(fā)送給服務器。

5. 服務器處理請求：服務器接收到瀏覽器的請求后，會根據(jù)請求的路徑和參數(shù)執(zhí)行相應的處理邏輯。這可能涉及到讀取文件、調(diào)用后端API、查詢數(shù)據(jù)庫等操作。

6. 服務器發(fā)送響應：服務器根據(jù)請求的處理結(jié)果生成HTTP響應消息。響應消息包括狀態(tài)碼（如200表示成功、404表示未找到等）、響應頭（如Content-Type、Content-Length等）和響應體（包含實際的數(shù)據(jù)或HTML內(nèi)容等）。服務器將響應消息發(fā)送回瀏覽器。

7. 接收和解析響應：瀏覽器接收到服務器的響應后，會根據(jù)響應頭中的信息進行處理。這可能包括處理Cookie、緩存響應、解壓縮響應等操作。同時，瀏覽器會解析響應體中的數(shù)據(jù)，如HTML內(nèi)容、CSS樣式表、JavaScript代碼等。

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

9. 關閉TCP連接：當瀏覽器完成頁面渲染后，它會關閉與服務器的TCP連接。這是通過四次揮手過程完成的，確保雙方都知道連接已經(jīng)關閉。

5. HTTPS 實現(xiàn)原理

HTTPS（HyperText Transfer Protocol Secure）是在傳輸層上基于TLS/SSL協(xié)議的安全版本的HTTP協(xié)議。它使用加密和身份驗證機制，確保在客戶端和服務器之間傳輸?shù)臄?shù)據(jù)的保密性和完整性。下面是HTTPS的實現(xiàn)原理：

1. 客戶端發(fā)起連接請求：當用戶在瀏覽器中輸入HTTPS的URL時，瀏覽器會向服務器發(fā)起連接請求。這個請求是通過默認的HTTPS端口（通常為443）發(fā)送的。

2. 服務器證書：服務器在回應客戶端的連接請求時，會將自己的公鑰和數(shù)字證書一起發(fā)送給客戶端。數(shù)字證書是由受信任的證書頒發(fā)機構(gòu)（CA）頒發(fā)的，用于驗證服務器的身份。

3. 客戶端驗證證書：客戶端收到服務器的證書后，會驗證證書的合法性。它會檢查證書的有效性、是否由受信任的CA簽發(fā)、是否過期等。如果證書驗證通過，客戶端可以繼續(xù)與服務器建立安全連接；否則，會出現(xiàn)警告或錯誤提示。

4. 客戶端生成會話密鑰：如果服務器的證書驗證通過，客戶端會生成一個隨機的會話密鑰，用于后續(xù)的對稱加密通信。會話密鑰是一個對稱密鑰，意味著它在客戶端和服務器之間共享。

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

6. 服務器解密會話密鑰：服務器收到客戶端發(fā)送的加密會話密鑰后，使用自己的私鑰對其進行解密，恢復得到原始的會話密鑰。

7. 客戶端和服務器建立加密通信：客戶端和服務器現(xiàn)在都擁有相同的會話密鑰，它們使用對稱加密算法來加密和解密通過網(wǎng)絡傳輸?shù)臄?shù)據(jù)。這樣，客戶端和服務器之間的通信就變得安全起來，第三方無法輕易地獲取或篡改傳輸?shù)臄?shù)據(jù)。

通過以上步驟，HTTPS實現(xiàn)了數(shù)據(jù)的加密和服務器身份的驗證。它提供了端到端的安全性，確保敏感信息在傳輸過程中不被竊取或篡改。同時，HTTPS還可以防止中間人攻擊，因為第三方無法輕易地解密和篡改通過SSL/TLS協(xié)議加密的數(shù)據(jù)。

6.?對稱加密和非對稱加密區(qū)別

1. 密鑰數(shù)量：

   • 對稱加密：對稱加密使用相同的密鑰進行加密和解密。這意味著加密和解密雙方需要共享相同的密鑰。因此，對稱加密只需要一個密鑰。
   • 非對稱加密：非對稱加密使用一對密鑰，分別是公鑰和私鑰。公鑰用于加密數(shù)據(jù)，私鑰用于解密數(shù)據(jù)。這意味著加密和解密使用的是不同的密鑰。因此，非對稱加密需要兩個密鑰。

2. 加密和解密速度：

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

3. 密鑰分發(fā)：

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

4. 安全性：文章來源地址http://www.zghlxwxcb.cn/news/detail-710472.html

   • 對稱加密：對稱加密算法在加密和解密過程中使用相同的密鑰，因此，如果密鑰被泄露，加密的數(shù)據(jù)將容易受到攻擊。對稱加密的安全性依賴于密鑰的保密性。
   • 非對稱加密：非對稱加密使用不同的密鑰進行加密和解密，并且私鑰必須保持機密。即使公鑰被泄露，攻擊者也無法輕易獲取私鑰，因此非對稱加密提供了更高的安全性。

到了這里，關于計算機網(wǎng)絡 基礎面試第二彈的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！