柚子快報激活碼778899分享：面試 Example Page

http://yzkb.51969.com/

輪詢不需要特殊設置，是直接的默認方式。這三種方式優(yōu)先級是不同，如下：

ip_hash > weight > 輪詢

ip_hash是優(yōu)先級最高，當配置了ip_hash，其他兩種配置就會失效，只會根據ip_hash策略。配置了weight也是同樣，輪詢會失效。

下面是一些常見的Nginx負載均衡策略：

輪詢（Round Robin）：這是默認的負載均衡策略。Nginx按順序將每個新的請求分發(fā)給下一個后端服務器，依次循環(huán)。這對于均勻地分配請求到所有服務器很有用。

upstream backend { server server1.example.com; server server2.example.com; }

權重（Weighted Round Robin）：可以為每個后端服務器分配不同的權重，以控制流量分發(fā)的比例。較高權重的服務器會獲得更多的請求。

upstream backend { server server1.example.com weight=3; server server2.example.com weight=2; server server3.example.com weight=1; }

IP哈希（IP Hash）：Nginx使用客戶端的IP地址來選擇一個后端服務器。這對于確保特定客戶端的請求始終路由到同一個服務器很有用，例如會話保持。

upstream backend { ip_hash; server server1.example.com; server server2.example.com; }

最少連接（Least Connections）：Nginx會將新的請求路由到當前連接數(shù)最少的后端服務器，以平衡服務器的負載。

upstream backend { least_conn; server server1.example.com; server server2.example.com; }

基于響應時間的負載均衡：Nginx可以根據后端服務器的響應時間來分配請求。它會優(yōu)先選擇響應時間較短的服務器。

upstream backend { least_time first_byte; server server1.example.com; server server2.example.com; }

備用服務器（Backup Servers）：可以指定一個或多個備用服務器，當所有主要服務器都不可用時，請求將被路由到備用服務器。

upstream backend { server server1.example.com; server server2.example.com backup; }

1.8 Nginx如何配置長連接

HTTP塊配置：首先，需要在Nginx配置中找到或創(chuàng)建一個HTTP塊。在這個塊內部，可以配置全局的HTTP選項。

http { keepalive_timeout 120s; keepalive_requests 10000; }

keepalive_timeout：HTTP連接的最大空閑時間（以秒為單位）。在超過這個時間后，連接將被關閉，為0的時候禁用長連接。keepalive_requests：設置一個客戶端可以在單個連接上發(fā)送的最大請求數(shù)。設置它有助于防止單個連接過度使用資源。當達到最大請求數(shù)目且所有已有請求結束后，連接被關閉，默認值為100。

配置Server塊：在Nginx配置中，找到或創(chuàng)建一個Server塊，通常是用于特定虛擬主機或站點的配置。在該塊內，可以進一步配置長連接相關的選項。

server { listen 80; server_name example.com;

其他服務器配置

location / {

配置代理或處理長連接的方式

} }

處理長連接方式：根據需求，可以在location塊內配置Nginx來處理長連接。例如，如果要代理WebSocket連接，可以使用以下配置：

location /websocket { proxy_pass http://backend-server; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection “upgrade”; }

這個示例配置了Nginx以代理WebSocket請求，并通過proxy_set_header指令設置升級頭部，以確保WebSocket連接正常工作。 4. 測試配置：在完成配置后，確保使用nginx -t命令檢查配置文件的語法是否正確。如果一切正常，請使用nginx -s reload重新加載Nginx以應用新配置。

2 HTTP

2.1 HTTP里有哪些常見的請求方法？

GET：用于請求服務器發(fā)送特定資源（通常是網頁或文件）。GET請求是冪等的，它只是從服務器獲取信息，不應該對服務器狀態(tài)產生影響。POST：用于向服務器提交數(shù)據，通常用于提交表單數(shù)據或執(zhí)行對服務器狀態(tài)產生影響的操作。POST請求不冪等，因為它可能會修改服務器上的數(shù)據。PUT：用于請求服務器存儲一個資源，通常用于更新或創(chuàng)建資源。PUT請求是冪等的，多次相同的PUT請求應該具有相同的結果。DELETE：用于請求服務器刪除指定的資源。DELETE請求是冪等的，多次相同的DELETE請求應該具有相同的結果。HEAD：類似于GET請求，但不返回響應正文。它用于獲取與GET請求相同的響應頭信息，但不獲取響應正文，通常用于檢查資源的元數(shù)據或確認資源是否存在。OPTIONS：用于請求服務器提供有關資源的通信選項，例如支持的請求方法、允許的來源等信息。它用于CORS（跨域資源共享）和預檢請求。PATCH：用于部分更新資源，通常用于更新資源的一部分而不是整個資源。PATCH請求是冪等的，多次相同的PATCH請求應該具有相同的結果。TRACE：用于在調試和診斷中回顯服務器接收到的請求，通常不常用，并且可能會存在安全風險。CONNECT：用于在客戶端和服務器之間建立網絡連接，通常用于代理服務器。它用于將客戶端連接到目標服務器。

2.2 HTTP的長連接和短連接有什么區(qū)別

參考1：http的長連接和短連接的區(qū)別

長連接與短連接介紹

長連接：客戶端與服務端先建立連接，連接建立后不斷開，以便在一段時間內進行多次請求和響應。這減少了TCP連接的建立和關閉的開銷。短連接：客戶端與服務端每個HTTP請求都會建立一個新的TCP連接，并在請求完成后立即關閉連接。

長連接與短連接的操作過程

長連接的操作步驟是：建立連接——數(shù)據傳輸…（保持連接）…數(shù)據傳輸——關閉連接。短連接的操作步驟是：建立連接——數(shù)據傳輸——關閉連接…建立連接——數(shù)據傳輸——關閉連接。

長連接與短連接的使用時機

長連接：長連接多用于操作頻繁，點對點的通訊，而且連接數(shù)不能太多的情況。每個TCP連接的建立都需要三次握手，每個TCP連接的斷開要四次握手。

如果每次操作都要建立連接然后再操作的話處理速度會降低，所以每次操作下次操作時直接發(fā)送數(shù)據就可以了，不用再建立TCP連接。

適用于客戶端和服務端通信頻繁的場景，例如聊天室，實時游戲，數(shù)據庫的連接用長連接，如果用短連接頻繁的通信會造成socket錯誤，頻繁的socket創(chuàng)建也是對資源的浪費。 2. 短連接：適用于一次性請求和響應的情況，例如普通的網頁瀏覽，其中每個資源都是單獨請求的。

2.3 HTTP的狀態(tài)碼，504有遇到過嗎

1xx - 信息性狀態(tài)碼：

100 Continue（繼續(xù)）：客戶端可以繼續(xù)發(fā)送請求。通常用于客戶端發(fā)送帶有大型請求體的POST請求，服務器在接收一部分后發(fā)送此狀態(tài)碼以通知客戶端繼續(xù)發(fā)送。101 Switching Protocols （切換協(xié)議）：服務器已經理解客戶端的請求，將切換到不同的協(xié)議，如WebSocket。

2xx - 成功狀態(tài)碼：

200 OK（成功）：服務器已成功處理了請求。201 Created（已創(chuàng)建）：請求成功并且服務器創(chuàng)建了新的資源。202（已接受）：服務器已接受請求，但尚未處理。204 No Content（無內容）：服務器成功處理了請求，但沒有返回任何內容。一般在只需要從客戶端往服務器發(fā)送信息，而對客戶端不需要發(fā)送新信息內容的情況下使用。

3xx - 重定向狀態(tài)碼：

301 Moved Permanently（永久移動）：資源被永久性移動到了新的URL。客戶端應該使用新的URL重新請求。302 Found（臨時移動）：資源被臨時性移動到了新的URL。客戶端應該使用新的URL重新請求。

4xx - 客戶端錯誤狀態(tài)碼：

400 Bad Request（錯誤請求)：服務器端無法理解客戶端發(fā)送的請求，請求報文中可能存在語法錯誤。401 Unauthorized(未授權) ：需要身份驗證才能訪問資源。403 Forbidden（禁止)： 服務器拒絕了請求，通常由于權限問題。404 Not Found（未找到)：請求的資源不存在。405（方法禁用) ：禁用請求中指定的方法。

5xx - 服務器錯誤狀態(tài)碼：

500 Internal Server Error（服務器內部錯誤）： 服務器在處理請求時發(fā)生了內部錯誤。502 Bad Gateway：服務器作為網關或代理服務器時，從上游服務器接收到無效的響應。503（服務不可用）：服務器當前無法處理請求，通常由于過載或維護。504 Gateway Timeout（網關超時）：服務器作為網關或代理，但是沒有及時從上游服務器收到請求。505（HTTP 版本不受支持）：服務器不支持請求中所用的HTTP協(xié)議版本。

2.4 GET和POST的區(qū)別

數(shù)據傳輸方式

GET：GET請求將數(shù)據附加在URL的末尾，以查詢字符串的形式發(fā)送。數(shù)據以鍵值對的形式出現(xiàn)在URL中，使用?分隔參數(shù)，使用&分隔多個參數(shù)。由于數(shù)據在URL中可見，GET請求不適合傳輸敏感信息。POST：POST請求將數(shù)據包含在請求的正文中，而不是在URL中。因此，POST請求對于傳輸敏感信息更安全，因為數(shù)據不會在URL中可見。POST請求通常用于提交表單數(shù)據、上傳文件等情況。

請求長度

GET：由于數(shù)據附加在URL上，GET請求對于發(fā)送的數(shù)據長度有限制，通常在2048個字符左右，這取決于瀏覽器和服務器的配置。因此，GET請求適合用于發(fā)送較小的數(shù)據。POST：POST請求沒有特定的長度限制，可以用于發(fā)送較大的數(shù)據，例如上傳文件或包含大量文本的表單。

可見性

GET：由于GET請求中的數(shù)據出現(xiàn)在URL中，因此數(shù)據是可見的，容易被用戶和瀏覽器記錄。這使得GET請求適合用于書簽、歷史記錄等場景。POST：POST請求中的數(shù)據在請求正文中，不會顯示在URL中，因此更適合用于傳輸敏感數(shù)據，但不能像GET請求那樣輕松地進行書簽和共享。

緩存

GET：由于GET請求是冪等的，可以被瀏覽器和代理服務器緩存，以提高性能。POST：POST請求通常不會被緩存，因為它們可能會導致服務器狀態(tài)的變化。

請求冪等性

GET：GET請求是冪等的，多次發(fā)送相同的GET請求應該產生相同的結果，而不會對服務器狀態(tài)產生影響。它通常用于獲取資源或執(zhí)行只讀操作。POST：POST請求通常不是冪等的，多次發(fā)送相同的POST請求可能會對服務器狀態(tài)產生不同的影響，因為它通常用于提交數(shù)據或執(zhí)行會修改服務器狀態(tài)的操作。

2.5 什么是無狀態(tài)協(xié)議，HTTP是無狀態(tài)協(xié)議嗎，怎么解決

無狀態(tài)協(xié)議（Stateless Protocol）是指協(xié)議在處理請求時不會記住之前的請求或會話信息，每個請求都是獨立的，服務器不會保存客戶端的狀態(tài)信息。

HTTP是一種無狀態(tài)協(xié)議，每個HTTP請求都是相互獨立的，服務器不會記住之前的請求或會話信息。這意味著服務器無法直接識別多個請求之間的關聯(lián)，每個請求都需要提供足夠的信息來說明其意圖。

為了解決HTTP的無狀態(tài)性，通常使用以下方法：

Cookies：Cookies是一種在客戶端和服務器之間存儲狀態(tài)信息的機制。服務器可以在響應中設置一個Cookie，客戶端將它保存并在后續(xù)的請求中發(fā)送回服務器。這允許服務器跟蹤客戶端的會話信息，例如用戶的登錄狀態(tài)或購物車內容。會話管理：服務器可以為每個客戶端創(chuàng)建一個唯一的會話標識符（Session ID），并在客戶端的請求中包含該標識符。服務器可以使用會話標識符來關聯(lián)多個請求，從而跟蹤用戶的會話狀態(tài)。URL參數(shù)：在URL中包含參數(shù)來傳遞狀態(tài)信息。這通常用于在Web應用程序中實現(xiàn)RESTful API，但不適合敏感信息，因為參數(shù)在URL中可見。隱藏表單字段：在HTML表單中添加隱藏字段來傳遞狀態(tài)信息。這通常用于Web應用程序，以便在不使用Cookies的情況下維護會話狀態(tài)。URL重寫：一些Web框架和服務器可以通過URL重寫來隱藏會話標識符，以改善安全性和可用性。JWT（JSON Web Tokens）：JWT是一種用于在客戶端和服務器之間傳遞可驗證的信息的標準。它可以包含有關用戶身份和狀態(tài)的信息，并由服務器簽名以確保數(shù)據的完整性和安全性。

2.6 HTTP請求的組成

參考1：Http協(xié)議的組成

請求行（Request Line）：請求行是HTTP請求的第一行，包含了以下三個要素：

請求方法（HTTP Method）：指定客戶端的動作或操作類型，比如GET、POST、PUT、DELETE等。請求的資源路徑（Request URI）：指定要請求的資源的路徑，通常是相對于服務器的根目錄的路徑，例如/index.html。協(xié)議版本（HTTP Version）：指定使用的HTTP協(xié)議版本，例如HTTP/1.1。

請求頭部（Request Headers）：請求頭部包含了一系列的元數(shù)據，用于提供請求的相關信息，例如：

Host：指定目標服務器的主機名和端口號。User-Agent：指定發(fā)起請求的用戶代理，通常是瀏覽器信息。Accept：指定可接受的響應內容類型。Content-Type：指定請求正文（如果有的話）的MIME類型。

Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.150 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8

3. 空行（Blank Line）：請求行和請求頭部之間必須有一個空行，用于分隔頭部信息和請求正文。 4. 請求正文（Request Body）：請求正文是可選的，通常用于包含客戶端向服務器發(fā)送的數(shù)據，例如表單數(shù)據或請求主體。請求正文的存在和格式取決于請求的方法和目的。

當請求方式是POST時，請求體會有請求參數(shù)格式如下：

username=zhangsan&password=123

當請求方式時GET時，請求參數(shù)是不會出現(xiàn)在請求體中，會拼接在URL地址后面：

http://localhost:8080…？username=zhangsan&password=123

2.7 HTTP響應的組成

狀態(tài)行（Status Line）：狀態(tài)行是HTTP響應的第一行，包含了以下三個要素：

協(xié)議版本（HTTP Version）：指定使用的HTTP協(xié)議版本，例如HTTP/1.1。狀態(tài)碼（Status Code）：指定了響應的處理結果，是一個三位數(shù)的數(shù)字，例如200表示成功，404表示資源未找到。狀態(tài)消息（Status Message）：與狀態(tài)碼相關的人類可讀的描述，用于提供關于狀態(tài)碼的更多信息。

響應頭部（Response Headers）：響應頭部包含了一系列的元數(shù)據，用于提供響應的相關信息，例如：

Content-Type：指定響應正文的MIME類型，告訴客戶端如何解析響應的內容。Content-Length：指定響應正文的長度（字節(jié)數(shù)）。Server：指定響應的服務器信息。Date：指定響應生成的日期和時間。其他自定義或標準頭部字段。

Content-Type: text/html; charset=utf-8 Content-Length: 12345 Server: Apache/2.4.41 (Ubuntu) Date: Thu, 01 Sep 2023 12:00:00 GMT

3. 空行（Blank Line）：狀態(tài)行和響應頭部之間必須有一個空行，用于分隔頭部信息和響應正文。 4. 響應正文（Response Body）：響應正文包含了服務器返回給客戶端的實際數(shù)據。它的內容和格式取決于響應的性質，例如在HTML頁面請求中，響應正文通常包含HTML文檔；在文件下載請求中，響應正文包含文件內容。 例如：

Example Page

Hello, World!

2.8 Cookies機制和Session機制的區(qū)別

Cookies機制和Session機制都是用于在Web應用程序中跟蹤用戶狀態(tài)和維護會話信息的方式，但它們在實現(xiàn)和工作原理上有一些重要的區(qū)別：

存儲位置

Cookies：Cookies是在客戶端（通常是瀏覽器）中存儲的小型文本文件。服務器在響應中設置Cookies，然后瀏覽器將它們存儲在客戶端的文件系統(tǒng)中。每次請求都會將Cookies發(fā)送回服務器，以便服務器可以讀取和修改它們。Session：Session數(shù)據通常存儲在服務器上。服務器為每個會話創(chuàng)建一個唯一的標識符（通常是會話ID），并將此標識符存儲在Cookies中或通過URL參數(shù)傳遞給客戶端。然后，服務器使用這個標識符來查找和維護與客戶端會話相關的數(shù)據。

數(shù)據存儲

Cookies：Cookies可以存儲在客戶端的瀏覽器中，但由于安全性和隱私考慮，通常只存儲一些小型的標識符或少量的非敏感數(shù)據。Cookies通常有大小限制（通常是幾KB）。Session：Session數(shù)據存儲在服務器上，可以存儲大量的數(shù)據，包括敏感信息。服務器根據會話ID來關聯(lián)客戶端的數(shù)據，因此客戶端無法直接訪問或修改會話數(shù)據。

生命周期

Cookies：Cookies可以具有不同的生命周期。它們可以是會話Cookies，只在瀏覽器會話期間存在，或者可以設置為持久Cookies，可以在指定的時間段內存在。Session：Session數(shù)據通常與用戶會話相關聯(lián)，一旦會話結束，通常會話數(shù)據也會被銷毀。會話的生命周期通常由服務器管理，可以在服務器上配置。

安全性

Cookies：Cookies可以存儲在客戶端，因此可能會受到一些安全威脅，例如跨站腳本攻擊（XSS）或跨站請求偽造攻擊（CSRF）。為了增加安全性，Cookies可以標記為HTTP Only，以防止JavaScript訪問它們。Session：Session數(shù)據通常存儲在服務器上，客戶端無法直接訪問或修改它們，因此通常比Cookies更安全。

性能

Cookies：Cookies需要在每個HTTP請求中發(fā)送到服務器，這可能會增加網絡流量。同時，瀏覽器會將Cookies附加到每個請求中，可能會導致一些額外的開銷。Session：Session數(shù)據存儲在服務器上，不需要在每個請求中發(fā)送，因此通常不會增加網絡流量，但可能會占用服務器資源，特別是在大規(guī)模應用程序中。

選擇Cookies還是Session取決于應用程序的需求和安全性考慮。通常，Cookies用于存儲較小且不敏感的數(shù)據，而Session用于存儲更大和敏感的數(shù)據。在實際應用中，它們經常一起使用，例如，使用Cookies存儲會話ID，然后使用會話ID關聯(lián)服務器上的Session數(shù)據。

2.9 RPC和HTTP的區(qū)別

RPC（Remote Procedure Call，遠程過程調用）和HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）都是用于不同系統(tǒng)之間通信的協(xié)議，但它們在工作方式和應用領域上有一些重要的區(qū)別：

通信模型

RPC：RPC是一種遠程通信協(xié)議，用于不同計算機或進程之間的函數(shù)調用。它允許一個程序在另一個程序上調用函數(shù)，就像本地函數(shù)一樣，而不需要直接管理底層通信細節(jié)。RPC通常用于跨越網絡的分布式應用程序。HTTP：HTTP是一種應用層協(xié)議，用于在客戶端和服務器之間傳輸超文本文檔和其他資源。HTTP通常用于Web應用程序中，它的主要目標是在瀏覽器和服務器之間傳遞HTML頁面、圖像、樣式表和其他Web資源。

數(shù)據格式

RPC：RPC協(xié)議可以使用多種數(shù)據格式，如XML-RPC、JSON-RPC、Protocol Buffers等，用于序列化和反序列化函數(shù)參數(shù)和返回值。HTTP：HTTP主要使用文本或二進制格式來傳輸數(shù)據。通常，HTTP使用HTML、XML、JSON等格式來表示資源。

通信方式

RPC：RPC通常采用請求-響應方式進行通信?？蛻舳税l(fā)起請求，服務器執(zhí)行請求并返回響應。HTTP：HTTP也使用請求-響應模型，但它可以支持不同的HTTP方法（如GET、POST、PUT、DELETE）來表示不同的操作，從而實現(xiàn)更復雜的交互。

應用場景

RPC：RPC通常用于構建分布式系統(tǒng)，例如微服務架構，其中不同的服務需要相互調用。它更適合用于應用程序內部的通信，以便不同的組件之間可以相互調用函數(shù)。HTTP：HTTP主要用于構建Web應用程序，支持瀏覽器與服務器之間的通信。它適用于提供Web頁面、API、資源傳輸和Web服務。

協(xié)議與規(guī)范

RPC：RPC通常需要使用特定的RPC框架或庫，如gRPC、Apache Thrift、Java RMI等。這些框架提供了遠程調用的支持。HTTP：HTTP是一種通用的應用層協(xié)議，任何具備HTTP支持的系統(tǒng)都可以使用，無需依賴特定的框架。

總結： RPC和HTTP都是用于不同類型的通信的協(xié)議，RPC主要用于構建分布式系統(tǒng)中不同組件之間的遠程調用，而HTTP主要用于構建Web應用程序中瀏覽器和服務器之間的通信。選擇哪種協(xié)議取決于應用程序需求和架構。有時，它們也可以結合使用，例如使用HTTP來傳輸RPC請求和響應。

2.10 HTTP的握手是什么樣的

HTTP協(xié)議本身并不包括握手過程，但它通常是在底層的傳輸層協(xié)議（如TCP）上進行握手的。以下是基于TCP的HTTP握手過程：

建立TCP連接：HTTP通常在傳輸層使用TCP協(xié)議?？蛻舳耸紫扰c服務器的IP地址和端口建立TCP連接。這是一個三步握手的過程，包括客戶端發(fā)送一個SYN包（請求建立連接），服務器回應SYN-ACK包（確認并同意建立連接），最后客戶端發(fā)送ACK包（確認連接建立）?？蛻舳税l(fā)送HTTP請求：一旦TCP連接建立，客戶端可以發(fā)送HTTP請求。HTTP請求由HTTP方法（如GET、POST、PUT等）、請求頭（包括主機名、User-Agent等信息）和請求體（如果有的話）組成。服務器接收和處理請求：服務器接收到客戶端的HTTP請求后，會根據請求中的信息進行處理。這可能包括查找請求的資源、執(zhí)行相關操作或生成HTTP響應。服務器發(fā)送HTTP響應：服務器生成HTTP響應，包括響應狀態(tài)碼、響應頭和響應體。響應狀態(tài)碼指示請求的結果，如200表示成功，404表示資源未找到，500表示服務器內部錯誤等?？蛻舳私邮誋TTP響應：客戶端接收到服務器的HTTP響應后，會解析響應，處理響應頭和響應體，并采取相應的行動，例如渲染網頁內容或執(zhí)行其他操作。關閉TCP連接：一旦HTTP事務完成，TCP連接可以被關閉。關閉TCP連接是一個四步揮手的過程，包括客戶端發(fā)送FIN包（請求關閉連接），服務器回應ACK包（確認關閉請求），服務器發(fā)送FIN包（請求關閉連接），最后客戶端回應ACK包（確認關閉請求）。這個過程是為了確保數(shù)據的完整性和可靠性。

總結： HTTP握手是建立在TCP連接之上的，它包括建立TCP連接、發(fā)送HTTP請求、接收HTTP響應和關閉TCP連接的步驟。這些步驟使客戶端能夠與服務器進行通信并交換數(shù)據。握手過程的細節(jié)可能會因使用的HTTP版本、傳輸層協(xié)議（如HTTPS）、安全性協(xié)議等而有所不同。

2.11 Websocket協(xié)議和HTTP的關系是什么？

WebSocket（WS）協(xié)議和HTTP（Hypertext Transfer Protocol）協(xié)議是兩種不同的協(xié)議，但它們之間存在一定的關系。以下是它們之間的一些關鍵區(qū)別和聯(lián)系：

協(xié)議類型：

HTTP是一種請求-響應協(xié)議，通常用于在客戶端和服務器之間傳輸文本和二進制數(shù)據。它是無狀態(tài)的，每個請求和響應之間是獨立的。WebSocket是一種全雙工通信協(xié)議，允許在客戶端和服務器之間建立持久連接，實現(xiàn)實時的雙向通信。它是建立在HTTP基礎上的協(xié)議，通過HTTP/1.1協(xié)議的升級機制實現(xiàn)。

握手過程：

HTTP協(xié)議是基于請求-響應模型的，每次通信都需要進行握手，發(fā)送請求并等待服務器的響應。這種模式適用于單次請求的場景。WebSocket則是通過HTTP握手建立連接，之后就可以在已建立的連接上進行雙向通信，無需重新握手。WebSocket握手通常使用HTTP協(xié)議的升級頭（Upgrade Header）來切換協(xié)議。

持久連接：

HTTP是一種短連接協(xié)議，每次請求和響應之間都會關閉連接，需要重新建立連接。WebSocket是一種長連接協(xié)議，通過在握手時建立的連接，保持連接的狀態(tài)，使得客戶端和服務器可以在連接上進行實時的雙向通信。

數(shù)據格式：

HTTP數(shù)據的傳輸通常使用明文的文本或者二進制格式，如JSON或XML。WebSocket允許在已建立的連接上直接發(fā)送二進制數(shù)據，同時也支持文本數(shù)據的傳輸。

端口：

HTTP默認使用端口80，而HTTPS使用端口443。WebSocket則通常使用與HTTP相同的端口，例如，如果你的網站使用HTTPS，WebSocket就使用端口443。

雖然WebSocket協(xié)議和HTTP協(xié)議是不同的協(xié)議，但由于WebSocket握手是通過HTTP協(xié)議進行的，因此它們在某種程度上關聯(lián)在一起。WebSocket協(xié)議的引入主要是為了解決 HTTP協(xié)議在實時雙向通信方面的限制，使得Web應用能夠更有效地實現(xiàn)實時通信。

3 HTTPS

參考1：HTTP和HTTPS協(xié)議，看一篇就夠了

3.1 HTTP和HTTPS的區(qū)別

HTTP（Hypertext Transfer Protocol）和HTTPS（Hypertext Transfer Protocol Secure）是兩種用于在客戶端和服務器之間傳輸數(shù)據的協(xié)議，它們之間的主要區(qū)別在于安全性和數(shù)據傳輸方式：

安全性

HTTP：HTTP是一種不安全的協(xié)議，數(shù)據在傳輸過程中以明文形式傳輸。這意味著如果惡意方在網絡中截取HTTP通信，他們可以輕松地讀取和修改傳輸?shù)臄?shù)據，包括敏感信息，如用戶名、密碼、信用卡號等。因此，HTTP不適合用于傳輸敏感信息的應用程序。HTTPS：HTTPS是HTTP的安全版本，使用SSL/TLS協(xié)議進行數(shù)據加密和身份驗證。通過HTTPS傳輸?shù)臄?shù)據被加密，因此即使被截取，也無法輕松讀取或修改。HTTPS通信使用公鑰和私鑰，確保客戶端和服務器之間的通信是安全的。這使得HTTPS非常適合用于處理敏感信息的應用程序，如在線支付、網上銀行、電子郵件等。

URL前綴

HTTP：HTTP網站的URL通常以"http://"開頭，例如：http://www.example.com。HTTPS：HTTPS網站的URL通常以"https://"開頭，例如：https://www.example.com。

端口

HTTP：HTTP默認使用端口80進行通信。HTTPS：HTTPS默認使用端口443進行通信。

證書

HTTP：HTTP不需要使用數(shù)字證書，因為它不提供加密和身份驗證。HTTPS：為了建立HTTPS連接，服務器需要使用數(shù)字證書來驗證其身份?？蛻舳藭炞C證書的有效性，并確保與服務器的通信是加密的。證書通常由受信任的第三方機構頒發(fā)，以確保服務器的身份。

性能

HTTP：HTTP通信速度較快，因為不需要加密和解密數(shù)據，但不安全。HTTPS：HTTPS通信速度較慢，因為需要加密和解密數(shù)據，但更安全。

總結： HTTP和HTTPS之間的主要區(qū)別在于安全性。HTTP是一種不安全的協(xié)議，適用于不涉及敏感信息的普通網站，而HTTPS通過加密和身份驗證提供了更高的安全性，適用于需要保護敏感信息的應用程序。在現(xiàn)代互聯(lián)網中，推薦在處理用戶數(shù)據時使用HTTPS以提供更高的安全性。

3.2 HTTPS實現(xiàn)原理

HTTPS（Hypertext Transfer Protocol Secure）實現(xiàn)了HTTP協(xié)議的安全版本，其主要原理是通過加密和身份驗證來確保通信的機密性和完整性。HTTPS的實現(xiàn)原理涉及以下關鍵概念和步驟：

加密通信

對稱加密：在HTTPS通信開始時，客戶端和服務器之間建立一個對稱密鑰，該密鑰用于加密和解密通信中的數(shù)據。對稱密鑰是一種快速加密和解密數(shù)據的方法，但必須在通信開始時安全地傳輸。非對稱加密：在對稱密鑰協(xié)商期間，服務器會向客戶端發(fā)送自己的CA證書，證書里包含公鑰，客戶端使用該公鑰加密對稱密鑰，然后將其發(fā)送回服務器。服務器使用其私鑰解密對稱密鑰。這個過程稱為非對稱加密，其中公鑰用于加密，私鑰用于解密。

數(shù)字證書

服務器通常需要通過數(shù)字證書來驗證其身份。數(shù)字證書由受信任的第三方證書頒發(fā)機構（Certificate Authority，CA）簽發(fā)，包含了服務器的公鑰和與服務器相關的信息，同時也包含CA的數(shù)字簽名?？蛻舳丝梢允褂肅A的公鑰來驗證服務器證書的有效性，確保連接到的服務器是合法的。

握手過程：當客戶端嘗試連接到HTTPS服務器時，會發(fā)生一個握手過程，其中包括以下步驟：客戶端向服務器發(fā)送一個隨機數(shù)和支持的加密算法列表。服務器選擇一個加密算法和使用自己的私鑰生成一個隨機數(shù)，然后將這些信息與數(shù)字證書一起發(fā)送給客戶端?？蛻舳耸褂梅掌鞯墓€解密服務器發(fā)送的信息，并驗證證書的有效性。如果一切正常，客戶端生成一個會話密鑰（對稱密鑰），然后使用服務器的公鑰加密該密鑰并發(fā)送回服務器。服務器使用其私鑰解密會話密鑰，然后雙方都具備了相同的對稱密鑰，用于加密和解密通信數(shù)據。加密通信：一旦握手成功，客戶端和服務器之間的通信將使用對稱密鑰進行加密和解密。這確保了數(shù)據在傳輸過程中的機密性和完整性，使第三方無法輕松地讀取或修改數(shù)據。

總結： HTTPS的實現(xiàn)原理涉及使用對稱和非對稱加密，數(shù)字證書以及握手過程來確保通信的安全性?？蛻舳撕头掌髦g的通信在加密的環(huán)境下進行，同時服務器的身份也得到驗證，以防止中間人攻擊和數(shù)據泄漏。這使得HTTPS成為保護敏感信息和確保通信隱私的重要工具。

3.3 CA的數(shù)字證書中包括哪些信息

參考：查看google瀏覽器里的證書

頒發(fā)者（Issuer）：證書頒發(fā)機構（CA）的名稱和相關信息，用于標識頒發(fā)該證書的機構。頒發(fā)對象：證書持有者的相關信息。主題（Subject）：證書持有者（通常是網站）的名稱和相關信息，用于標識該證書所屬實體。公鑰（Public Key）：證書持有者的公鑰，用于加密通信和驗證數(shù)字簽名。有效期（Validity）：證書的生效日期和失效日期，指示證書的有效期限。序列號（Serial Number）：證書的唯一序列號，用于標識該證書的唯一性。簽名算法（Signature Algorithm）：用于生成證書簽名的算法類型，例如RSA、DSA、ECDSA等。簽名（Signature）：由證書頒發(fā)機構使用其私鑰對證書數(shù)據進行簽名生成的數(shù)字簽名，用于驗證證書的完整性和真實性。擴展字段（Extensions）：包含一些額外的信息，如證書用途、密鑰用法、頒發(fā)者信息等。

這些信息組成了證書數(shù)據的主要內容，用于驗證證書的有效性和真實性。瀏覽器和其他應用程序使用這些信息來建立信任鏈，確認證書的合法性，并確保安全的通信。

3.4 SSL建立連接過程

SSL（Secure Sockets Layer，安全套接字層）是一種用于在網絡上建立安全連接的協(xié)議，它的后續(xù)版本被稱為TLS（Transport Layer Security，傳輸層安全性）。SSL/TLS協(xié)議的建立連接過程通常包括以下步驟：

客戶端Hello：客戶端向服務器發(fā)送一個ClientHello消息，其中包含以下信息：客戶端支持的SSL/TLS協(xié)議版本。一個隨機數(shù)，該隨機數(shù)將用于生成會話密鑰。支持的密碼套件列表，包括加密算法、哈希算法等。服務器Hello服務器從客戶端發(fā)送的ClientHello消息中選擇一個支持的SSL/TLS協(xié)議版本。服務器生成一個隨機數(shù)，將其發(fā)送給客戶端。服務器選擇一個密碼套件，通知客戶端使用哪種加密算法和哈希算法。服務器發(fā)送其數(shù)字證書，證書包含服務器的公鑰以及與證書相關的信息。身份驗證和密鑰交換客戶端驗證服務器的證書有效性。包括檢查證書是否過期、證書頒發(fā)機構是否可信任，證書的頒發(fā)機構（CA）的信任鏈，以確保服務器的身份。客戶端生成一個預主密鑰（Pre-Master Secret），并使用數(shù)字證書的公鑰加密它，然后發(fā)送給服務器。服務器使用其私鑰解密客戶端發(fā)送的預主密鑰，然后雙方都使用預主密鑰生成主密鑰（Master Secret）。會話密鑰的生成客戶端和服務器使用各自的隨機數(shù)以及主密鑰生成會話密鑰。會話密鑰是對稱密鑰，用于加密和解密通信中的數(shù)據。完成握手客戶端發(fā)送一個Finished消息，該消息包含前面握手消息的哈希值，以驗證握手消息的完整性。服務器發(fā)送一個Finished消息，同樣包含前面握手消息的哈希值。一旦客戶端和服務器都收到對方的Finished消息，握手過程完成。安全通信 現(xiàn)在，客戶端和服務器都使用會話密鑰加密和解密通信中的數(shù)據。通信過程中的數(shù)據都會使用這個密鑰進行保護。

一旦握手完成，SSL/TLS會話建立，雙方可以安全地通信，保護數(shù)據的機密性和完整性。這個過程確保了通信雙方的身份驗證、密鑰交換和安全通信。一旦建立了SSL/TLS連接，通信雙方可以開始在加密的環(huán)境中傳輸數(shù)據，防止數(shù)據泄露和中間人攻擊。這是安全的HTTPS連接的基礎。

3.5 HTTPS的加密協(xié)議是什么

HTTPS（Hypertext Transfer Protocol Secure）的加密協(xié)議通常是TLS（Transport Layer Security，傳輸層安全性）協(xié)議。TLS是SSL（Secure Sockets Layer，安全套接字層）的后續(xù)版本，目前廣泛用于保護網絡通信的安全性。TLS協(xié)議提供了數(shù)據的加密、完整性驗證和身份驗證，以確保通信在傳輸過程中是安全的。

TLS協(xié)議的核心功能包括：

加密：TLS使用對稱密鑰和非對稱密鑰加密算法來保護數(shù)據的機密性，防止第三方截取和讀取數(shù)據。完整性驗證：TLS使用哈希函數(shù)來驗證數(shù)據的完整性，確保數(shù)據在傳輸過程中沒有被篡改。身份驗證：TLS通過數(shù)字證書來驗證通信雙方的身份，確?？蛻舳诉B接到的服務器是合法的。

總結： HTTPS的加密協(xié)議通常是TLS，它通過加密、完整性驗證和身份驗證來保護網絡通信的安全性。選擇TLS的版本取決于安全性要求和兼容性考慮。

3.6 HTTPS怎么保證服務器給客戶端下發(fā)的公鑰是真正的公鑰，而不是中間人偽造的公鑰呢？

HTTPS通過數(shù)字證書來確?？蛻舳耸盏降姆掌鞴€是真實有效的，而不是中間人偽造的公鑰。這是通過以下方式實現(xiàn)的：

數(shù)字證書：服務器必須獲得數(shù)字證書，由受信任的第三方機構（Certificate Authority，CA）頒發(fā)。數(shù)字證書包含以下信息：服務器的公鑰。服務器的標識信息，如域名。CA的數(shù)字簽名。CA信任鏈：客戶端的瀏覽器或操作系統(tǒng)內置了一組受信任的根證書頒發(fā)機構（Root Certificate Authorities）。這些根CA的公鑰已被預安裝在客戶端設備中，并被廣泛信任。服務器的數(shù)字證書必須由其中一個受信任的CA頒發(fā)，否則客戶端將不信任該證書。數(shù)字簽名驗證：當客戶端連接到服務器時，服務器會將其數(shù)字證書發(fā)送給客戶端?？蛻舳耸褂妙A先安裝的根CA的公鑰來驗證服務器證書的數(shù)字簽名。如果數(shù)字簽名驗證通過，客戶端就可以確信證書是由受信任的CA頒發(fā)的。域名匹配：客戶端還會檢查證書中的域名信息是否與用戶試圖連接的域名匹配。這是為了防止中間人攻擊，其中攻擊者可能會偽造證書，并嘗試欺騙客戶端連接到錯誤的服務器。

總結： HTTPS通過數(shù)字證書和CA信任鏈來確保服務器提供的公鑰是真實有效的。只有在證書由受信任的CA頒發(fā)，并且數(shù)字簽名驗證通過且域名匹配時，客戶端才會信任服務器的公鑰。這種機制防止了中間人攻擊，確保了通信的安全性和服務器的身份驗證。如果數(shù)字證書無效或被篡改，客戶端將拒絕建立連接。

3.7 第三方攻擊者能否讓自己的證書顯示出來的信息也是服務端呢？

第三方攻擊者（中間人攻擊者）通常無法獲得合法服務器的有效數(shù)字證書，因為服務器的數(shù)字證書是由受信任的證書頒發(fā)機構（CA）頒發(fā)的，而CA通常會執(zhí)行嚴格的驗證程序來確保只有合法服務器才能獲得證書。但中間人攻擊者可以嘗試使用自己偽造的證書來欺騙客戶端，稱為自簽名證書，以嘗試進行攻擊。

中間人攻擊的工作原理通常如下：

攻擊者與客戶端建立加密通道，同時與服務器建立另一個加密通道。攻擊者同時偽裝成客戶端和服務器。攻擊者向客戶端提供自己偽造的數(shù)字證書，宣稱它是服務器的數(shù)字證書?？蛻舳送ǔL試驗證偽造證書的有效性，但攻擊者可以提供自己偽造的根證書，聲稱它是受信任的CA的根證書。如果客戶端不對證書進行嚴格的驗證，它可能會相信攻擊者偽造的證書。一旦客戶端相信了攻擊者偽造的證書，它會使用攻擊者提供的公鑰來加密通信數(shù)據，攻擊者也可以解密這些數(shù)據，然后將其重新加密并傳遞給真正的服務器。攻擊者以類似的方式偽裝成客戶端，向服務器發(fā)送數(shù)據，然后將服務器的響應重新加密并傳遞給客戶端。這使得攻擊者可以竊聽、修改或篡改通信內容。

為了防止中間人攻擊，客戶端應嚴格驗證服務器的數(shù)字證書，確保它是由受信任的CA頒發(fā)的，而且證書中的信息與服務器的域名匹配。此外，服務器也可以采用一些安全措施，如公鑰固定（Pin）或使用證書透明度（Certificate Transparency）來增加安全性。如果客戶端在驗證數(shù)字證書時發(fā)現(xiàn)任何問題，應立即中斷連接，以防止建立不安全的通信渠道。

3.8 HTTPS優(yōu)缺點

HTTPS（Hypertext Transfer Protocol Secure）是一種用于在網絡上建立安全連接的協(xié)議，它通過數(shù)據加密、身份驗證和完整性驗證來保護通信的安全性。HTTPS具有許多優(yōu)點，但也有一些缺點。

優(yōu)點：

數(shù)據加密：HTTPS使用加密算法來保護數(shù)據在傳輸過程中的機密性。這意味著即使數(shù)據被截取，也無法輕松讀取其內容，因此能夠有效防止信息泄漏。完整性驗證：HTTPS使用哈希函數(shù)來驗證數(shù)據的完整性，確保數(shù)據在傳輸過程中沒有被篡改。這有助于防止中間人攻擊和數(shù)據篡改。身份驗證：HTTPS通過數(shù)字證書來驗證服務器的身份?？蛻舳丝梢源_保連接到的服務器是合法的，這防止了偽裝和中間人攻擊。用戶信任：HTTPS使用受信任的第三方證書頒發(fā)機構（CA）頒發(fā)的數(shù)字證書。這增加了用戶對網站的信任，因為他們可以相信其連接是安全的。SEO優(yōu)化：搜索引擎（如Google）更喜歡使用HTTPS保護的網站，因此使用HTTPS可以提高網站的搜索引擎排名。法規(guī)合規(guī)性：許多法規(guī)和合規(guī)性要求要求網站使用HTTPS來保護用戶數(shù)據，特別是對于敏感信息的處理，如支付信息和個人身份信息。Cookie安全：HTTPS可以幫助防止Cookie劫持攻擊，因為Cookie在傳輸過程中也會被加密。

缺點：

性能開銷：加密和解密數(shù)據會引入一些性能開銷，使HTTPS通信相對于HTTPS略顯慢一些。然而，現(xiàn)代硬件和TLS協(xié)議的改進已經減小了這種性能開銷。成本：獲得有效的數(shù)字證書可能需要支付一些費用，尤其是如果選擇使用受信任的商業(yè)CA頒發(fā)的證書。配置和維護：配置和維護HTTPS服務器可能比HTTP更復雜，尤其是在大型網絡中。不是絕對安全：雖然HTTPS提供了很高的安全性，但它也不是絕對安全的。它仍然可能受到一些攻擊，如某些類型的中間人攻擊或惡意軟件感染。

總結： HTTPS在保護通信的安全性和隱私方面具有很大的優(yōu)勢，尤其是在處理敏感信息的應用程序中。然而，它也需要考慮性能開銷和一些配置和維護工作。對于大多數(shù)Web應用程序來說，使用HTTPS是非常值得的，因為它提供了必要的保護和用戶信任。

3.9 HTTPS的證書是誰驗證誰

在HTTPS通信中，數(shù)字證書的驗證過程如下：

證書頒發(fā)機構(CA)驗證網站的身份并向其頒發(fā)證書。網站將證書發(fā)送給訪問的客戶端?？蛻舳双@取證書后，驗證證書的頒發(fā)機構是否為可信的CA?？蛻舳蓑炞C證書的內容是否與網站地址匹配。如果一切驗證通過，客戶端就可以信任該證書真實屬于該網站。

所以簡單來說：

CA驗證網站，向網站頒發(fā)證書?？蛻舳蓑炞CCA是否可信任，以及證書是否與網站匹配。最后客戶端驗證證書的有效性和網站的合法性。

總結： HTTPS證書驗證中，CA驗證網站，而用戶驗證CA和證書本身。這個雙向驗證機制讓HTTPS證書系統(tǒng)能夠安全可靠地運行。

3.10 HTTPS單向認證時誰驗證誰

在HTTPS單向認證中，一般情況下是客戶端驗證服務器的身份，而不是服務器驗證客戶端的身份。這是HTTPS的標準配置方式，也被稱為單向SSL認證。

HTTPS通信中的驗證通常如下：

服務器驗證：服務器獲得數(shù)字證書，其中包含服務器的公鑰以及一些服務器相關的信息，如域名。服務器將其數(shù)字證書發(fā)送給客戶端?？蛻舳蓑炞C（可選）：在標準的單向SSL認證中，客戶端可以選擇驗證服務器的證書。客戶端使用受信任的根CA的公鑰來驗證服務器證書的有效性，包括證書的簽名和域名匹配。如果客戶端選擇驗證服務器的證書并且驗證通過，它可以信任服務器的身份。連接建立：一旦服務器的證書被驗證通過（如果客戶端進行了驗證），客戶端和服務器之間建立連接，并使用服務器的公鑰加密通信數(shù)據。

總結： HTTPS的標準配置中，通常是客戶端驗證服務器的身份，而服務器通常不驗證客戶端的身份?？蛻舳送ㄟ^驗證服務器的證書來確保連接到的服務器是合法的，從而防止中間人攻擊。如果需要服務器驗證客戶端的身份，可以使用雙向認證（雙向SSL認證）來實現(xiàn)，其中客戶端和服務器都會驗證對方的身份。

3.11 HTTPS客戶端如何驗證服務端證書的合法性

在HTTPS通信中，客戶端通過驗證服務器證書的合法性來確認連接到的服務器的身份。這個驗證過程通常包括以下步驟：

獲取服務器證書：服務器在握手過程中將其數(shù)字證書發(fā)送給客戶端。驗證證書的簽發(fā)機構（CA）：客戶端使用本地受信任的根證書頒發(fā)機構（CA）的公鑰來驗證服務器證書是否由受信任的CA簽發(fā)。根證書通常是預裝在操作系統(tǒng)或瀏覽器中的。驗證證書的有效期：客戶端檢查服務器證書的有效期，確保它沒有過期。如果證書已過期，客戶端將認為連接不安全。驗證證書的域名匹配：客戶端檢查服務器證書中的域名信息是否與用戶試圖連接的域名匹配。這是為了防止中間人攻擊，其中攻擊者可能會偽造證書并欺騙客戶端連接到錯誤的服務器。驗證證書的簽名：客戶端使用根CA的公鑰來驗證服務器證書的數(shù)字簽名。如果簽名驗證通過，客戶端可以確信證書未被篡改。

如果服務器證書通過上述驗證步驟，客戶端就可以信任服務器的身份，并繼續(xù)建立安全連接，使用服務器的公鑰來加密通信數(shù)據。 注意： 客戶端可以選擇是否驗證服務器證書。在某些情況下，如果客戶端無法驗證服務器的證書或不進行驗證，連接仍然可以建立，但會警告用戶連接不安全。然而，為了最大程度地確保安全，建議客戶端始終驗證服務器證書的合法性。

3.12 HTTPS信息摘要的算法是什么

HTTPS使用一種稱為消息摘要算法（Message Digest Algorithm）的算法來確保數(shù)據的完整性。具體來說，HTTPS通常使用SHA-256（Secure Hash Algorithm 256位）或其他類似的消息摘要算法。

在HTTPS安全通信中，數(shù)字簽名和消息摘要使用了以下幾種算法：

MD5(Message-Digest Algorithm 5)：MD5是一個128位長度的消息摘要算法，用于產生數(shù)據的數(shù)字簽名，校驗數(shù)據完整性。但MD5已被證實存在弱點，可以被碰撞攻擊。SHA-1(Secure Hash Algorithm 1)：SHA-1是160位長度輸出的密碼HASH算法，相比MD5更加安全可靠，但理論上也可能受到碰撞攻擊。SHA-2：SHA-2代表了一系列SHA算法，包括SHA-224、SHA-256、SHA-384、SHA-512等變種。其中SHA-256是目前廣泛使用的數(shù)字簽名和消息摘要算法。SHA-3：SHA-3是最新的安全HASH算法標準，采用Keccak算法，可以產生224、256、384、512位長度的消息摘要。其安全性得到廣泛認可。HMAC：HMAC(Hash-based Message Authentication Code)是將HASH算法與密鑰結合，生成包含HASH算法和密鑰的消息摘要，提高了安全性。

總結： HTTPS中常用的消息摘要和數(shù)字簽名算法是SHA-2(特別是SHA-256)和HMAC，以及最新的SHA-3算法。這些算法安全性強，抗破解能力高。

SHA-256是SHA-2家族中的一種，它是一種密碼學安全的哈希函數(shù)，用于生成數(shù)據的固定長度的哈希值。SHA-256會將輸入數(shù)據（如HTTP報文或HTTPS數(shù)據）轉換成256位（32字節(jié)）的哈希值。如果在傳輸過程中數(shù)據被篡改，即使是微小的更改，也會導致哈希值發(fā)生顯著變化，從而使客戶端能夠檢測到數(shù)據的篡改。

SHA-256被廣泛用于HTTPS通信中的消息摘要生成，以確保傳輸?shù)臄?shù)據在傳輸過程中沒有被篡改。這有助于防止中間人攻擊和確保數(shù)據的完整性。同時，SHA-256也是當前廣泛使用的加密哈希算法之一，具有較高的安全性和廣泛的應用范圍。

3.13 HTTPS交換的是什么

HTTPS通信主要交換的內容包括SSL/TLS握手信息、加密的HTTP請求和響應以及用于驗證數(shù)據完整性的消息摘要。這些機制確保了HTTPS通信的安全性和隱私。

其實也就是建立連接的過程。

3.14 HTTPS數(shù)據傳輸用什么加密方式

HTTPS數(shù)據傳輸使用對稱加密和非對稱加密結合的方式來保障數(shù)據的安全性和保密性。

以下是HTTPS通信中常用的加密方式：

對稱加密：對稱加密使用相同的密鑰來加密和解密數(shù)據，因此被稱為"對稱"。在HTTPS通信中，客戶端和服務器在SSL/TLS握手過程中協(xié)商出一個對稱的會話密鑰（Session Key）。這個會話密鑰用于加密和解密實際的HTTPS數(shù)據。常見的對稱加密算法包括：

AES（Advanced Encryption Standard）：目前廣泛使用的對稱加密算法之一，支持不同的密鑰長度，如AES-128、AES-256等。

非對稱加密：非對稱加密使用一對密鑰，包括公鑰和私鑰，其中一個用于加密，另一個用于解密。在HTTPS通信中，服務器擁有一對公鑰和私鑰，其中公鑰被包含在服務器的數(shù)字證書中，而私鑰是服務器保密的。非對稱加密主要用于SSL/TLS握手階段，以安全地協(xié)商對稱會話密鑰。常見的非對稱加密算法包括：

RSA（Rivest–Shamir–Adleman）：常用于數(shù)字證書中的非對稱加密算法。

數(shù)字簽名：數(shù)字簽名是一種非對稱加密的應用，用于驗證數(shù)字證書的有效性。服務器的數(shù)字證書包含服務器的公鑰和由證書頒發(fā)機構（CA）簽名的信息?？蛻舳耸褂肅A的公鑰來驗證證書的簽名，以確保證書是合法的。

HTTPS通信的基本過程是：在握手階段，服務器和客戶端協(xié)商出一個對稱的會話密鑰，該密鑰用于加密和解密HTTP數(shù)據。這個對稱會話密鑰由服務器的非對稱公鑰加密傳輸給客戶端，客戶端使用私鑰解密得到該密鑰。之后，客戶端和服務器使用對稱密鑰來加密和解密通信數(shù)據，保障數(shù)據的機密性和完整性。

總結： HTTPS使用對稱加密和非對稱加密（包括數(shù)字簽名）來保障通信數(shù)據的安全性和保密性。這種綜合使用不同的加密方式，使得HTTPS通信變得安全可靠。

4 HTTP2相比HTTP1有什么優(yōu)勢

注意：HTTP2不是HTTPS，兩者別搞成一個了。

HTTP/2是HTTP/1的后續(xù)版本，它引入了一些重要的改進，以提高性能和效率。以下是HTTP/2相比HTTP/1的一些主要優(yōu)勢：

多路復用（Multiplexing）：HTTP/2允許多個請求和響應同時在一個連接上進行傳輸，而不像HTTP/1那樣需要建立多個連接。這意味著可以在一個連接上并行發(fā)送多個請求和響應，減少了連接建立和維護的開銷，提高了性能。二進制格式：HTTP/2采用了二進制傳輸格式，而HTTP/1使用文本格式。二進制格式更加緊湊和高效，減少了數(shù)據傳輸?shù)拇笮?，從而提高了效率。頭部壓縮：HTTP/2支持頭部字段的壓縮，減少了請求和響應中的重復頭部信息的傳輸，降低了帶寬使用，加快了頁面加載速度。服務器推送（Server Push）：HTTP/2允許服務器在客戶端請求之前主動推送資源。這使得服務器可以預測客戶端可能需要的資源，并在請求之前發(fā)送，減少了往返延遲，提高了加載速度。優(yōu)化的流量控制：HTTP/2引入了更有效的流量控制機制，可以更精細地管理數(shù)據流的傳輸和優(yōu)先級，確保關鍵資源能夠更快地加載。支持Header壓縮算法：HTTP/2使用HPACK壓縮算法來壓縮頭部信息，減少了數(shù)據傳輸?shù)拈_銷。這有助于提高性能，特別是在低帶寬或高延遲網絡環(huán)境下。安全性：雖然不是HTTP/2的本質特性，但它鼓勵網站采用加密（通過HTTPS），因為大多數(shù)現(xiàn)代瀏覽器只支持HTTP/2超過HTTPS。因此，HTTP/2可以提高通信的安全性。

總結： HTTP/2相對于HTTP/1具有更高的性能、更低的延遲和更高的效率，可以改善網站的加載速度和用戶體驗。因此，許多網站和服務已經采用了HTTP/2來提供更快的性能。

4.1 GRPC是HTTP2還是HTTP1

GRPC使用HTTP/2作為其底層的傳輸協(xié)議，而不是HTTP/1。GRPC是一個高性能的遠程過程調用（RPC）框架，它使用HTTP/2來實現(xiàn)通信，具有諸多優(yōu)勢，包括多路復用、頭部壓縮、流控制等特性，使其成為現(xiàn)代分布式系統(tǒng)中的常用工具。HTTP/2的性能和效率改進使得GRPC可以更高效地處理大量的并發(fā)請求，同時提供更小的延遲和更低的帶寬消耗。因此，GRPC的底層協(xié)議是HTTP/2，而不是HTTP/1。

5 TCP

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是計算機網絡中的一種常用的傳輸層協(xié)議，它提供可靠的、面向連接、點到點的數(shù)據傳輸服務。

5.1 TCP和HTTP的區(qū)別

HTTP（Hypertext Transfer Protocol）和TCP（Transmission Control Protocol）是計算機網絡中的兩個不同的協(xié)議，它們在網絡通信中扮演不同的角色，有以下主要區(qū)別：

層級關系：

TCP是傳輸層協(xié)議，負責在網絡上可靠地傳輸數(shù)據，處理數(shù)據的分段、順序控制、流量控制等網絡傳輸?shù)牡讓蛹毠?jié)。HTTP是應用層協(xié)議，構建在傳輸層之上，用于定義客戶端和服務器之間的通信規(guī)則，以便請求和傳輸超文本（通常是網頁）和其他數(shù)據。

功能：

TCP主要負責數(shù)據傳輸?shù)目煽啃院陀行蛐浴Ｋ_保數(shù)據能夠從一個端點安全地傳輸?shù)搅硪粋€端點，而不會損壞、丟失或亂序。HTTP主要負責定義客戶端和服務器之間的請求和響應的格式，以及如何處理和呈現(xiàn)文檔或數(shù)據。

連接性：

TCP是一種面向連接的協(xié)議，它建立持久的連接來傳輸數(shù)據，通常使用客戶端-服務器模型。HTTP可以基于TCP連接，但它是一種無狀態(tài)協(xié)議，每個請求都是獨立的，服務器不會保持與客戶端的持久連接。

端口：

TCP使用端口號來標識不同的網絡應用程序或服務。例如，Web服務器通常使用TCP端口80或443。HTTP通?；赥CP連接，使用HTTP默認端口80（非加密）或443（加密）。

通信內容：

TCP傳輸?shù)氖窃级M制數(shù)據流，它沒有關于數(shù)據的上下文或語義。HTTP傳輸?shù)氖腔谖谋镜南ⅲ@些消息包含請求或響應的元信息和數(shù)據，以及用于標識資源的URL。

應用領域：

TCP是一個通用的協(xié)議，用于支持各種應用程序和服務的可靠通信，包括HTTP。HTTP主要用于互聯(lián)網上的超文本傳輸，用于在Web瀏覽器和Web服務器之間傳輸網頁、圖像、視頻、API數(shù)據等。

總結： TCP提供了網絡通信的底層基礎，而HTTP構建在TCP之上，定義了用于Web數(shù)據傳輸?shù)囊?guī)則和語義。HTTP使用TCP作為它的傳輸層協(xié)議之一，但還包括其他應用層協(xié)議，如HTTPS（HTTP over TLS/SSL）等，以提供安全性和隱私保護。

5.2 HTTP是在TCP之上運行，兩者的包會有什么區(qū)別

TCP的數(shù)據包包含源端口和目標端口，HTTP不包含端口信息。TCP的包頭簡單，只包含源端口、目標端口、序號、確認號等信息。HTTP的數(shù)據包更復雜，包含請求方法、URL、協(xié)議版本、請求頭部、消息體等信息。TCP關注傳輸， packets只包含數(shù)據。HTTP關注應用信息，packets包含具體的請求或響應詳情。TCP的packets按順序傳輸，HTTP的packets可以亂序。TCP需要建立連接、流量控制和擁塞控制。HTTP運行在TCP連接上，可以忽略這些問題。TCP對數(shù)據包的大小沒有限制。HTTP一般將數(shù)據包限制在1500字節(jié)以內。TCP的packets只有頭部。HTTP的packets有頭部、消息體等完整結構。TCP是面向連接的協(xié)議。HTTP本質上是無連接的。

總結： 兩者分別工作在不同層次，TCP負責底層傳輸，HTTP負責具體的應用數(shù)據交互，兩者的包結構和功能有著明顯的區(qū)別。

5.3 TCP特點

可靠性：TCP提供可靠的數(shù)據傳輸。它確保數(shù)據從發(fā)送端準確地傳輸?shù)浇邮斩?，通過使用序號、確認和重傳機制來實現(xiàn)數(shù)據的可靠性。如果數(shù)據包丟失、損壞或亂序，TCP將負責重新發(fā)送數(shù)據，以確保完整性和正確性。面向連接：TCP是一種面向連接的協(xié)議，連接的建立需要經過三次握手過程，以確保雙方都準備好進行數(shù)據傳輸。連接的關閉也需要經過四次揮手過程。流量控制：TCP使用流量控制機制來防止數(shù)據包的積壓和數(shù)據傳輸過程中的數(shù)據流過快。接收端可以通知發(fā)送端其可接受的數(shù)據量，從而調整發(fā)送速率，以適應接收端的處理能力。擁塞控制：TCP具有擁塞控制機制，它可以在網絡擁塞時減緩數(shù)據發(fā)送速率，以防止過度擁塞，保持網絡的穩(wěn)定性。擁塞控制通過檢測丟失的數(shù)據包和計算往返時間來實現(xiàn)。面向字節(jié)：TCP將數(shù)據視為一系列字節(jié)的流，而不是消息或數(shù)據包。這允許TCP在傳輸時對數(shù)據進行分段、重組和流動控制，以適應不同的網絡條件。雙工通信：TCP支持全雙工通信，允許雙方同時發(fā)送和接收數(shù)據，這使得實時應用和互動應用能夠進行高效的雙向通信。端口和套接字：TCP使用端口來區(qū)分不同的應用程序和服務。套接字是應用程序與TCP協(xié)議交互的接口，通過套接字可以進行數(shù)據的讀取和寫入。可靠性和復雜性：TCP提供高度的可靠性和數(shù)據完整性，但它也引入了一些復雜性和額外的開銷，如握手、確認和擁塞控制。這些機制確保了數(shù)據的可靠傳輸，但有時也會引入一些延遲。

總結： TCP是一種非?？煽康膮f(xié)議，適用于需要可靠數(shù)據傳輸和連接性能的應用程序，如網頁瀏覽、電子郵件、文件傳輸、實時通信等。它是互聯(lián)網中的基礎協(xié)議之一，確保了數(shù)據在網絡中的可靠傳輸。

5.4 TCP使用場景

TCP（Transmission Control Protocol，傳輸控制協(xié)議）適用于需要可靠的、面向連接的數(shù)據傳輸?shù)膱鼍?。以下是一些常見的TCP使用場景：

Web瀏覽：當在瀏覽器中訪問網頁時，瀏覽器使用HTTP協(xié)議（通常是HTTP over TCP）與Web服務器建立TCP連接來請求網頁內容。TCP確保了網頁數(shù)據的可靠傳輸，以便正確顯示網頁。電子郵件：SMTP（Simple Mail Transfer Protocol）和POP3（Post Office Protocol）或IMAP（Internet Message Access Protocol）等電子郵件協(xié)議使用TCP來傳輸電子郵件消息，以確保郵件的可靠傳輸和正確接收。文件傳輸：FTP（File Transfer Protocol）和SFTP（SSH File Transfer Protocol）等協(xié)議使用TCP來傳輸文件。這些協(xié)議需要可靠的數(shù)據傳輸，以防止文件損壞或丟失。遠程登錄：SSH（Secure Shell）和Telnet等協(xié)議用于遠程登錄到計算機系統(tǒng)。SSH使用TCP來提供加密的、安全的遠程訪問。數(shù)據庫訪問：許多數(shù)據庫管理系統(tǒng)（如MySQL、PostgreSQL、Oracle）使用TCP來進行數(shù)據庫查詢和數(shù)據傳輸。可靠性對于數(shù)據庫操作至關重要。VoIP電話：Voice over Internet Protocol（VoIP）電話系統(tǒng)使用TCP或UDP（在某些情況下）來傳輸音頻數(shù)據。雖然UDP在VoIP中更常見，但某些應用也使用TCP以確保更可靠的音頻傳輸。在線游戲：某些在線游戲使用TCP來傳輸游戲數(shù)據，特別是需要高度可靠性的游戲。雖然UDP更常用于實時游戲，但TCP適用于一些策略性或回合制游戲。HTTPS安全通信：HTTPS協(xié)議使用TLS/SSL建立在TCP上，以確保加密和安全性，用于保護敏感數(shù)據的傳輸，如信用卡信息和登錄憑據。Web服務：當使用SOAP、RESTful API等協(xié)議進行Web服務調用時，通常會使用HTTP over TCP來進行通信。

總結： TCP適用于需要可靠性、面向連接和數(shù)據完整性的應用場景。它確保數(shù)據的可靠傳輸，適用于許多互聯(lián)網應用，尤其是需要高度可靠性的應用。然而，由于TCP引入了一些額外的開銷，可能會引入一些延遲，因此在某些實時性要求較高的應用中，可能會使用UDP等協(xié)議。

注釋："HTTP over TCP" 就是使用傳輸控制協(xié)議（TCP）作為HTTP協(xié)議的底層傳輸協(xié)議。在這種情況下，HTTP數(shù)據通過TCP連接進行傳輸，以確保數(shù)據的可靠性和完整性。

5.5 基于（使用）TCP的協(xié)議有哪些

HTTP（Hypertext Transfer Protocol）：HTTP是用于在Web瀏覽器和Web服務器之間傳輸超文本文檔的協(xié)議。它是互聯(lián)網上最常見的應用層協(xié)議之一，通常使用TCP作為傳輸層協(xié)議。HTTPS（HTTP Secure）：HTTPS是HTTP的安全版本，通過在HTTP上加入TLS/SSL層來加密數(shù)據傳輸。它使用TCP作為底層傳輸協(xié)議，以確保加密的、安全的通信。FTP（File Transfer Protocol）：FTP是用于文件傳輸?shù)膮f(xié)議，它使用TCP來傳輸文件。FTP允許用戶上傳和下載文件到和從遠程服務器。SMTP（Simple Mail Transfer Protocol）：SMTP是用于電子郵件傳輸?shù)膮f(xié)議，用于從發(fā)送方電子郵件客戶端發(fā)送電子郵件到接收方電子郵件服務器。SMTP使用TCP來傳輸電子郵件消息。POP3（Post Office Protocol version 3） 和 IMAP（Internet Message Access Protocol）：這兩個協(xié)議用于從電子郵件服務器上檢索電子郵件。POP3和IMAP都使用TCP來建立連接并下載電子郵件。SSH（Secure Shell）：SSH是用于安全遠程登錄和文件傳輸?shù)膮f(xié)議。它使用TCP作為底層傳輸協(xié)議，并提供加密和認證功能，以保護遠程會話的安全。Telnet：Telnet是一種用于遠程登錄到遠程主機的協(xié)議，但它不提供加密，因此安全性較低。它使用TCP來傳輸終端會話。MySQL：MySQL是一種流行的關系型數(shù)據庫管理系統(tǒng)，它使用TCP來建立與數(shù)據庫服務器的連接并進行數(shù)據查詢和操作。RDP（Remote Desktop Protocol）：RDP用于遠程桌面連接，允許用戶遠程控制和操作遠程計算機。它使用TCP來傳輸桌面會話數(shù)據。XMPP（Extensible Messaging and Presence Protocol）：XMPP是一種實時通信協(xié)議，用于即時消息傳遞和在線狀態(tài)。它使用TCP來傳輸消息。

總結： 這些協(xié)議是構建互聯(lián)網和計算機網絡中各種應用和服務的關鍵組成部分，它們依賴于TCP來提供可靠的數(shù)據傳輸。每個協(xié)議都具有不同的用途和特性，但它們都使用TCP作為傳輸層協(xié)議，以確保數(shù)據的可靠性和正確性。

5.6 TCP三次握手

參考1：HTTP協(xié)議常問的面試題（吐血整理） 看 16 TCP三次握手和四次揮手。

TCP的三次握手（Three-Way Handshake）是建立TCP連接的過程，用于確保通信的雙方都準備好傳輸數(shù)據。以下是TCP三次握手的過程：

第一步 - 客戶端發(fā)送連接請求：客戶端首先向服務器發(fā)送一個特殊的TCP包，稱為SYN（同步）包。這個包包含客戶端隨機選擇的一個初始序列號（Client ISN，Initial Sequence Number），該序列號用于標識客戶端發(fā)送的數(shù)據，以及一個標志位SYN=1，表示這是一個連接請求。第二步 - 服務器確認連接請求：服務器收到客戶端的連接請求（SYN包）后，如果同意建立連接，會回復一個包，通常稱為SYN-ACK包。這個包包含了服務器分配用于標識服務器發(fā)送的數(shù)據的初始序列號（Server ISN），以及標志位SYN=1和ACK=1，表示這是對客戶端請求的確認，并且服務器也準備好建立連接。第三步 - 客戶端確認服務器的確認：客戶端收到服務器的確認（SYN-ACK包）后，會向服務器發(fā)送一個確認包（ACK包）。這個包包含標志位ACK=1，表示客戶端接受了服務器的確認，并且連接已建立。此時，雙方都已確認連接的建立，可以開始傳輸數(shù)據。

完成了這個三次握手過程后，TCP連接就建立成功了，客戶端和服務器都可以開始在連接上進行數(shù)據傳輸。每個數(shù)據包都會包含一個序列號，用于標識數(shù)據的順序和完整性，以確保數(shù)據能夠正確地傳輸和接收。

注意： 三次握手是用于建立TCP連接的過程。在連接結束后，會使用四次揮手過程來正常關閉連接。這些握手和揮手過程是TCP協(xié)議中的關鍵步驟，以確保數(shù)據的可靠傳輸和連接的正確終止。

5.7 TCP在握手完成之后，A到B發(fā)送數(shù)據，中間有個數(shù)據被篡改，它會怎處理

TCP在數(shù)據傳輸過程中，包括握手階段之后，會使用一種校驗和機制來檢測數(shù)據是否被篡改。這個校驗和通常稱為TCP校驗和（TCP Checksum）。

當數(shù)據從發(fā)送端A到接收端B時，TCP發(fā)送端會計算校驗和并將其附加到數(shù)據包的頭部。接收端B收到數(shù)據包后會進行以下處理：

校驗和驗證：接收端B會計算接收到的數(shù)據包的校驗和，并將結果與數(shù)據包頭部中的校驗和進行比較。比較校驗和：如果接收端計算出的校驗和與數(shù)據包頭部中的校驗和匹配，說明數(shù)據包在傳輸過程中沒有被篡改，數(shù)據被接受并繼續(xù)傳遞給上層應用程序。校驗和不匹配：如果接收端計算出的校驗和與數(shù)據包頭部中的校驗和不匹配，說明數(shù)據包在傳輸過程中可能受到了篡改或損壞。接收端會丟棄這個數(shù)據包，不傳遞給上層應用程序，并可以選擇發(fā)送一個通知給發(fā)送端A請求重新發(fā)送數(shù)據。

這種校驗和機制幫助確保了TCP傳輸中數(shù)據的完整性。如果數(shù)據包在傳輸過程中被篡改或損壞，接收端會檢測到這一問題，并丟棄損壞的數(shù)據包，從而保護了數(shù)據的可靠性。如果發(fā)生數(shù)據包丟失或篡改，TCP會負責重新傳輸數(shù)據，直到接收端確認接收到正確的數(shù)據。

總結： TCP使用校驗和機制來檢測和處理數(shù)據傳輸中的篡改或損壞問題，以確保數(shù)據的可靠性和完整性。這是TCP協(xié)議的一個重要特性，有助于提高網絡通信的可靠性。

5.8 TCP三次握手的兩種隊列

參考1：TCP連接三次握手中的重要數(shù)據結構：半連接隊列和全連接隊列 在TCP三次握手的時候，服務端會維護兩個隊列：監(jiān)聽隊列（Listen Queue）和已完成隊列（Completed Connection Queue）。

監(jiān)聽隊列（Listen Queue）：

監(jiān)聽隊列也稱為“半連接隊列”或“未完全建立連接的隊列”。在服務端（通常是服務器）調用listen函數(shù)后，它會等待客戶端的連接請求。當客戶端發(fā)送SYN（同步）包進行連接請求時，服務器會將這個請求放入監(jiān)聽隊列中，等待后續(xù)的第二次握手。監(jiān)聽隊列的大小可以通過操作系統(tǒng)的配置進行設置，這個設置限制了同時等待連接的數(shù)量。如果隊列已滿，新的連接請求會被拒絕。

已完成隊列（Completed Connection Queue）：

已完成隊列也稱為“全連接隊列”或“已建立連接的隊列”。在服務器成功進行了第二次握手，接受了客戶端的連接請求后，連接就會從監(jiān)聽隊列移動到已完成隊列中。已完成隊列中的連接表示已經建立，可以進行數(shù)據傳輸。服務器會從已完成隊列中取出連接，分配資源，為連接提供服務，并在完成后進行釋放。

總結： 監(jiān)聽隊列用于存放等待服務器確認的連接請求，而已完成隊列用于存放已經建立的連接，準備進行數(shù)據傳輸。這兩個隊列在TCP連接建立過程中起著重要的作用，確保了連接的正常建立和管理。當連接終止時，也有相應的隊列來管理連接的釋放。

5.8.1 TCP三次握手的兩種隊列溢出

不管是半連接隊列還是全連接隊列，都有最大長度限制，超過限制時，內核會直接丟棄，或返回RST包。

半連接隊列溢出： 客戶端發(fā)送SYN報文和服務端進行第一次握手，此時服務端將此請求信息放在半連接隊列中并回復SYN+ACK給客戶端。這里也就是SYN攻擊的點，攻擊方要做的就是不停的建立連接，但是卻不給出ACK確認，導致半連接隊列滿了，其他請求無法進入。

全連接隊列溢出： 當服務端并發(fā)處理大量請求時，如果TCP全連接隊列過小，就容易溢出。發(fā)生TCP全連接隊溢出的時候，后續(xù)的請求就會被丟棄，這樣就會出現(xiàn)服務端請求數(shù)量上不去的現(xiàn)象。

全連接隊列滿了，就只會丟棄連接嗎？ 實際上，丟棄連接只是Linux的默認行為，我們還可以選擇向客戶端發(fā)送RST復位報文，告訴客戶端連接已經建立失敗。 tcp_abort_on_overflow 共有兩個值分別是0和1，其分別表示： 0 ：表示如果全連接隊列滿了，那么server丟棄client發(fā)過來的ack； 1 ：表示如果全連接隊列滿了，那么server發(fā)送一個reset 包給 client，表示廢掉這個握手過程和這個連接；

如果要想知道客戶端連接不上服務端，是不是服務端TCP全連接隊列滿的原因，可以把tcp_abort_on_overflow設置為1，這時如果在客戶端異常中可以看到很多connection reset by peer的錯誤，那么就可以證明是由于服務端 TCP 全連接隊列溢出的問題。

通常情況下，應當把tcp_abort_on_overflow設置為0，因為這樣更有利于應對突發(fā)流量。 舉個例子，當TCP全連接隊列滿導致服務器丟掉了ACK，與此同時，客戶端的連接狀態(tài)卻是ESTABLISHED，進程就在建立好的連接上發(fā)送請求。只要服務器沒有為請求回復ACK，請求就會被多次重發(fā)。如果服務器上的進程只是短暫的繁忙造成accept隊列滿，那么當TCP全連接隊列有空位時，再次接收到的請求報文由于含有ACK，仍然會觸發(fā)服務器端成功建立連接。

5.9 TCP如何實現(xiàn)可靠性傳輸

TCP（Transmission Control Protocol，傳輸控制協(xié)議）通過一系列機制來實現(xiàn)可靠性傳輸，確保數(shù)據從發(fā)送端到接收端的可靠傳輸。

以下是TCP實現(xiàn)可靠性傳輸?shù)闹饕獧C制：

序列號和確認號：TCP在每個數(shù)據包中包含序列號（Sequence Number）和確認號（Acknowledgment Number）。序列號用于標識數(shù)據的順序，確認號用于確認接收到的數(shù)據。接收端會發(fā)送確認，指示它已經成功接收并準備好接收下一個數(shù)據包。數(shù)據重傳：如果發(fā)送端沒有收到來自接收端的確認，或者接收端檢測到丟失的數(shù)據包，TCP會觸發(fā)數(shù)據重傳機制。發(fā)送端會重新發(fā)送丟失的數(shù)據包，直到接收到確認為止。流量控制：TCP使用流量控制機制，確保發(fā)送端不會以過快的速度發(fā)送數(shù)據，從而防止數(shù)據包的積壓和網絡擁塞。接收端可以通知發(fā)送端其可接受的數(shù)據量，以調整發(fā)送速率。擁塞控制：TCP還具有擁塞控制機制，可以在網絡擁塞時減緩數(shù)據發(fā)送速率，以防止過度擁塞并提高網絡的穩(wěn)定性。擁塞控制通過檢測丟失的數(shù)據包和計算往返時間來實現(xiàn)。有序交付：TCP確保數(shù)據按正確的順序交付給應用層。即使數(shù)據包在傳輸過程中到達的順序與發(fā)送順序不同，TCP也會將它們按正確的順序交給應用程序。校驗和驗證：TCP使用校驗和機制來檢測數(shù)據包在傳輸過程中是否發(fā)生了損壞。如果數(shù)據包在傳輸過程中損壞，接收端會通知發(fā)送端丟棄損壞的數(shù)據包，并要求重新發(fā)送。超時和重傳策略：TCP使用超時和重傳策略來處理丟失的數(shù)據包。如果一個數(shù)據包的確認沒有及時到達，TCP將觸發(fā)重傳機制，重新發(fā)送該數(shù)據包。窗口機制：TCP使用窗口機制來調整發(fā)送和接收的數(shù)據量，以提高效率。窗口大小可以根據網絡條件進行動態(tài)調整。連接建立和斷開的握手過程：TCP的連接建立和斷開過程也是可靠性的一部分。三次握手確保了雙方都準備好建立連接，四次揮手確保了連接的正常終止。

總結： TCP通過這些機制和策略，以及其他一些技術手段，來實現(xiàn)可靠性傳輸，確保數(shù)據在網絡中的可靠傳輸和正確接收。這使得TCP成為一種非?？煽康膮f(xié)議，適用于各種需要可靠性傳輸?shù)膽?，如網頁瀏覽、電子郵件、文件傳輸?shù)取?/p>

5.10 TCP建立連接的時候為什么是三次握手，不是兩次或四次

TCP建立連接采用三次握手的過程，而不是兩次或四次，是為了確保雙方都準備好進行可靠的數(shù)據傳輸，并且避免出現(xiàn)不必要的連接建立。

以下是三次握手的原因和過程：

確保雙方都愿意建立連接：通過三次握手，確保了客戶端和服務器都愿意建立連接。如果只有兩次握手，那么可能會導致一方不知道對方是否愿意建立連接，從而引發(fā)不確定性和安全問題。防止舊連接的問題：在網絡中，已經關閉連接的數(shù)據包可能在某段時間內仍然存在，這是因為網絡中的數(shù)據包可能會延遲或復制。如果只有兩次握手，可能會導致在新連接中誤認為是舊連接的數(shù)據包，從而引發(fā)問題。通過第三次握手，可以確保是新的連接，防止這種問題的發(fā)生。防止連接資源浪費：如果連接建立后不進行三次握手的確認，那么服務器可能會浪費資源來處理無效的連接請求。

總結： 三次握手確保了雙方都準備好建立連接，避免了可能導致數(shù)據傳輸問題的情況。它是TCP協(xié)議設計的一部分，旨在提供可靠性和安全性，確保通信的正常進行。雖然三次握手引入了一些額外的開銷，但這個開銷在大多數(shù)情況下是合理的，以確保數(shù)據傳輸?shù)目煽啃浴?/p>

5.11 TCP四次揮手

參考：你需要知道的 TCP 四次揮手

TCP的四次揮手是用于正常關閉TCP連接的過程，確保數(shù)據的可靠傳輸和連接的正確終止。以下是TCP四次揮手的過程：

第一次揮手 - 客戶端發(fā)送連接關閉請求（FIN from Client）：

客戶端首先決定關閉連接，它向服務器發(fā)送一個帶有FIN（Finish，結束）標志的TCP數(shù)據包給服務器，表示客戶端不再發(fā)送數(shù)據給服務器，但仍然愿意接收來自服務器的數(shù)據。客戶端進入FIN_WAIT_1狀態(tài)，等待服務器的確認或拒絕。

第二次揮手 - 服務器確認關閉請求（ACK from Server）：

服務器接收到客戶端的FIN后，會發(fā)送一個帶有確認ACK標志的TCP數(shù)據包給客戶端，表示服務器已收到客戶端的關閉請求。此時服務器進入CLOSE_WAIT狀態(tài)，客戶端繼續(xù)等待來自服務器的可能未發(fā)送完的數(shù)據。

第三次揮手 - 服務器發(fā)送連接關閉請求（FIN from Server）：

當服務器確定不再有數(shù)據要發(fā)送給客戶端時，服務器發(fā)送一個帶有FIN標志的TCP數(shù)據包給客戶端，表示服務器也準備好關閉連接。服務器進入LAST_ACK狀態(tài)，等待客戶端的確認。

第四次揮手 - 客戶端確認關閉請求（ACK from Client）：

客戶端收到服務器的FIN包后進入TIME_WAIT狀態(tài)，會發(fā)送一個ACK包作為確認，并等待一段時間以確保可能在網絡中滯留的ACK數(shù)據包到達服務器。服務器收到這個ACK后，進入CLOSED狀態(tài)，連接完全關閉?？蛻舳藙t會等一段時間再進入關閉狀態(tài)，釋放資源，結束TIME_WAIT狀態(tài)。因為第四次揮手不一定能成功發(fā)給服務端，所以要等一下，看看服務端會不會因為沒收到第四次揮手，而重發(fā)第三次揮手。

在四次揮手的過程中，雙方都有機會發(fā)送FIN和ACK包，以確保連接的正常關閉。這可以防止出現(xiàn)連接的半關閉狀態(tài)，確保數(shù)據的可靠傳輸和連接的正常終止。

注意：

和TCP三次握手不同。TCP關閉連接的揮手足足有四次。這是因為第二次揮手和第三次揮手之間可能有一些服務端需要發(fā)送的處理比較慢的數(shù)據要返回，所以沒有將這兩次揮手合并。TIME_WAIT狀態(tài)的存在是為了處理可能在網絡中延遲的ACK包，以確保連接正常關閉。這個狀態(tài)的持續(xù)時間相對較短，通常在幾分鐘內自動結束，以釋放資源。

5.12 TCP前面加個防火墻，那TCP的包會在哪一步被攔截掉？

如果在TCP連接前面加上一個防火墻，那么TCP的數(shù)據包會在以下幾個步驟被防火墻攔截：

三次握手建立連接時，防火墻可以攔截SYN包，導致無法建立連接。數(shù)據傳輸過程中，防火墻可以攔截任何一個方向的TCP數(shù)據包。四次揮手斷開連接時，防火墻可以攔截FIN/ACK包，導致無法正常斷開。如果啟用了狀態(tài)檢測，防火墻可以攔截不符合預期狀態(tài)的TCP包。防火墻也可以攔截重傳的TCP包。防火墻可以過濾指定端口的TCP包，直接阻止連接。

總結： 防火墻可以在TCP連接的任何一個階段進行數(shù)據包的攔截、過濾或state檢測，從而達到阻止某些連接或限制某些通信的目的。最直接的方法是直接過濾目標端口的TCP數(shù)據包。

5.13 TCP一個端口可以并發(fā)接收多少請求

TCP協(xié)議本身并沒有限制一個端口能夠接收的并發(fā)請求的數(shù)量，而是受限于多個因素，包括操作系統(tǒng)的設置、硬件資源、應用程序的設計和負載等。以下是影響一個端口能夠接收多少并發(fā)請求的一些關鍵因素：

操作系統(tǒng)的資源限制：操作系統(tǒng)在內核級別管理網絡連接，因此它會限制一個端口可以接受的并發(fā)連接數(shù)量。這個限制通常受操作系統(tǒng)的配置和資源限制（如文件描述符限制）的影響。不同的操作系統(tǒng)和版本可能會有不同的默認設置，但通?？梢酝ㄟ^操作系統(tǒng)的配置來調整這些限制。硬件資源：硬件資源如處理器、內存和網絡適配器的性能也會影響一個端口能夠處理的并發(fā)請求數(shù)量。更強大的硬件可以處理更多的并發(fā)連接。應用程序的設計：應用程序的設計和實現(xiàn)方式對并發(fā)請求的處理有重要影響。例如，使用多線程或多進程模型可以提高并發(fā)性，或者使用事件驅動的非阻塞I/O可以有效地處理大量并發(fā)請求。負載均衡：負載均衡器可以幫助分發(fā)來自不同客戶端的請求到多個服務器端口上，從而提高整個系統(tǒng)的并發(fā)處理能力。請求處理時間：請求處理的時間長度也會影響端口的并發(fā)請求處理能力。如果請求需要較長的時間來處理，那么端口可能會在某一時刻積累大量的等待請求。網絡拓撲和帶寬：網絡拓撲和帶寬限制也可能對并發(fā)連接產生影響。如果網絡連接速度較慢或帶寬有限，那么可能會限制并發(fā)請求的處理速度。

需要注意的是，不同的應用場景和需求會對并發(fā)請求的要求產生不同的影響。因此，在設計和部署應用程序時，需要考慮到上述因素，并根據具體需求進行優(yōu)化和配置，以確保能夠滿足所需的并發(fā)請求處理能力。同時，監(jiān)測和性能測試也是評估系統(tǒng)能夠處理多少并發(fā)請求的重要手段。

5.14 TCP可能有幾萬個、幾十萬個、上百萬個鏈接都在這個端口上，怎么知道它是哪個鏈接，對應哪個用戶，對應哪個請求？

TCP是傳輸層協(xié)議，可以通過上面的應用層以及以下條件獲取到。

源IP地址和目標IP地址：每個TCP連接都有一個源IP地址和一個目標IP地址，通過這些IP地址，可以確定連接的兩端。這可以幫助區(qū)分不同的用戶或請求，特別是在多個客戶端同時連接到同一個服務器端口的情況下。源端口和目標端口：每個TCP連接都有一個源端口和一個目標端口。源端口通常是客戶端隨機選擇的，而目標端口通常是服務器上監(jiān)聽的端口。通過這些端口，可以將連接與特定應用程序或服務相關聯(lián)。會話標識符：有些應用層協(xié)議在TCP連接上使用會話標識符或令牌，以將連接與特定的用戶或請求相關聯(lián)。例如，HTTP協(xié)議使用會話標識符來跟蹤用戶的會話狀態(tài)。日志記錄：在服務器上，可以配置日志記錄，以跟蹤連接和請求的詳細信息。通過查看服務器日志，可以了解哪個IP地址在哪個端口上建立了連接，以及與之相關的請求或操作。應用層協(xié)議：有些應用層協(xié)議在其數(shù)據包中包含有關用戶或請求的信息。例如，HTTP請求包括URL和HTTP頭，這些信息可以幫助確定請求的內容和來源。網絡分析工具：網絡分析工具可以用于監(jiān)視和分析網絡流量?？梢允褂眠@些工具來捕獲和分析TCP數(shù)據包，以查看連接的詳細信息，包括源IP、目標IP、源端口、目標端口等。負載均衡器和代理服務器：如果有負載均衡器或代理服務器位于服務器端和客戶端之間，它們通常會在處理連接時添加一些信息，以幫助將連接路由到正確的后端服務器或應用程序實例。

綜合使用這些方法，可以幫助確定特定TCP連接對應哪個用戶或請求。這在網絡管理、安全監(jiān)控和故障排除等方面都非常有用。不過，具體的方法可能因網絡配置和應用程序的不同而異。

5.15 tcp粘包拆包是怎么發(fā)生的？該怎么解決？就是接到數(shù)據以后怎么解決呢？

參考1：TCP粘包現(xiàn)象分析及處理方式

5.15.1 為什么TCP會粘包，UDP不會粘包

自我介紹一下，小編13年上海交大畢業(yè)，曾經在小公司待過，也去過華為、OPPO等大廠，18年進入阿里一直到現(xiàn)在。

深知大多數(shù)Go語言工程師，想要提升技能，往往是自己摸索成長或者是報班學習，但對于培訓機構動則幾千的學費，著實壓力不小。自己不成體系的自學效果低效又漫長，而且極易碰到天花板技術停滯不前！

因此收集整理了一份《2024年Go語言全套學習資料》，初衷也很簡單，就是希望能夠幫助到想自學提升又不知道該從何學起的朋友，同時減輕大家的負擔。

既有適合小白學習的零基礎資料，也有適合3年以上經驗的小伙伴深入學習提升的進階課程，基本涵蓋了95%以上Golang知識點，真正體系化！

由于文件比較大，這里只是將部分目錄大綱截圖出來，每個節(jié)點里面都包含大廠面經、學習筆記、源碼講義、實戰(zhàn)項目、講解視頻，并且后續(xù)會持續(xù)更新

如果你覺得這些內容對你有幫助，可以添加V獲?。簐ip1024b （備注Go）

一個人可以走的很快，但一群人才能走的更遠。不論你是正從事IT行業(yè)的老鳥或是對IT行業(yè)感興趣的新人，都歡迎掃碼加入我們的的圈子（技術交流、學習資源、職場吐槽、大廠內推、面試輔導），讓我們一起學習成長！

來源。 6. 網絡分析工具：網絡分析工具可以用于監(jiān)視和分析網絡流量?？梢允褂眠@些工具來捕獲和分析TCP數(shù)據包，以查看連接的詳細信息，包括源IP、目標IP、源端口、目標端口等。 7. 負載均衡器和代理服務器：如果有負載均衡器或代理服務器位于服務器端和客戶端之間，它們通常會在處理連接時添加一些信息，以幫助將連接路由到正確的后端服務器或應用程序實例。

綜合使用這些方法，可以幫助確定特定TCP連接對應哪個用戶或請求。這在網絡管理、安全監(jiān)控和故障排除等方面都非常有用。不過，具體的方法可能因網絡配置和應用程序的不同而異。

5.15 tcp粘包拆包是怎么發(fā)生的？該怎么解決？就是接到數(shù)據以后怎么解決呢？

參考1：TCP粘包現(xiàn)象分析及處理方式

5.15.1 為什么TCP會粘包，UDP不會粘包

自我介紹一下，小編13年上海交大畢業(yè)，曾經在小公司待過，也去過華為、OPPO等大廠，18年進入阿里一直到現(xiàn)在。

深知大多數(shù)Go語言工程師，想要提升技能，往往是自己摸索成長或者是報班學習，但對于培訓機構動則幾千的學費，著實壓力不小。自己不成體系的自學效果低效又漫長，而且極易碰到天花板技術停滯不前！

因此收集整理了一份《2024年Go語言全套學習資料》，初衷也很簡單，就是希望能夠幫助到想自學提升又不知道該從何學起的朋友，同時減輕大家的負擔。 [外鏈圖片轉存中…(img-2QkMU8nD-1713072817675)] [外鏈圖片轉存中…(img-oGRiQw31-1713072817676)] [外鏈圖片轉存中…(img-k3Kawf1J-1713072817676)] [外鏈圖片轉存中…(img-6dCzXuB5-1713072817677)] [外鏈圖片轉存中…(img-HmMmkIbW-1713072817677)]

既有適合小白學習的零基礎資料，也有適合3年以上經驗的小伙伴深入學習提升的進階課程，基本涵蓋了95%以上Golang知識點，真正體系化！

由于文件比較大，這里只是將部分目錄大綱截圖出來，每個節(jié)點里面都包含大廠面經、學習筆記、源碼講義、實戰(zhàn)項目、講解視頻，并且后續(xù)會持續(xù)更新

如果你覺得這些內容對你有幫助，可以添加V獲?。簐ip1024b （備注Go） [外鏈圖片轉存中…(img-pBLvMcQJ-1713072817678)]

一個人可以走的很快，但一群人才能走的更遠。不論你是正從事IT行業(yè)的老鳥或是對IT行業(yè)感興趣的新人，都歡迎掃碼加入我們的的圈子（技術交流、學習資源、職場吐槽、大廠內推、面試輔導），讓我們一起學習成長！

柚子快報激活碼778899分享：面試 Example Page

http://yzkb.51969.com/

文章來源