柚子快報(bào)激活碼778899分享：面試 Example Page

http://yzkb.51969.com/

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

ip_hash > weight > 輪詢(xún)

ip_hash是優(yōu)先級(jí)最高，當(dāng)配置了ip_hash，其他兩種配置就會(huì)失效，只會(huì)根據(jù)ip_hash策略。配置了weight也是同樣，輪詢(xún)會(huì)失效。

下面是一些常見(jiàn)的Nginx負(fù)載均衡策略：

輪詢(xún)（Round Robin）：這是默認(rèn)的負(fù)載均衡策略。Nginx按順序?qū)⒚總€(gè)新的請(qǐng)求分發(fā)給下一個(gè)后端服務(wù)器，依次循環(huán)。這對(duì)于均勻地分配請(qǐng)求到所有服務(wù)器很有用。

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

權(quán)重（Weighted Round Robin）：可以為每個(gè)后端服務(wù)器分配不同的權(quán)重，以控制流量分發(fā)的比例。較高權(quán)重的服務(wù)器會(huì)獲得更多的請(qǐng)求。

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

IP哈希（IP Hash）：Nginx使用客戶(hù)端的IP地址來(lái)選擇一個(gè)后端服務(wù)器。這對(duì)于確保特定客戶(hù)端的請(qǐng)求始終路由到同一個(gè)服務(wù)器很有用，例如會(huì)話(huà)保持。

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

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

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

基于響應(yīng)時(shí)間的負(fù)載均衡：Nginx可以根據(jù)后端服務(wù)器的響應(yīng)時(shí)間來(lái)分配請(qǐng)求。它會(huì)優(yōu)先選擇響應(yīng)時(shí)間較短的服務(wù)器。

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

備用服務(wù)器（Backup Servers）：可以指定一個(gè)或多個(gè)備用服務(wù)器，當(dāng)所有主要服務(wù)器都不可用時(shí)，請(qǐng)求將被路由到備用服務(wù)器。

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

1.8 Nginx如何配置長(zhǎng)連接

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

http { keepalive_timeout 120s; keepalive_requests 10000; }

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

配置Server塊：在Nginx配置中，找到或創(chuàng)建一個(gè)Server塊，通常是用于特定虛擬主機(jī)或站點(diǎn)的配置。在該塊內(nèi)，可以進(jìn)一步配置長(zhǎng)連接相關(guān)的選項(xiàng)。

server { listen 80; server_name example.com;

其他服務(wù)器配置

location / {

配置代理或處理長(zhǎng)連接的方式

} }

處理長(zhǎng)連接方式：根據(jù)需求，可以在location塊內(nèi)配置Nginx來(lái)處理長(zhǎng)連接。例如，如果要代理WebSocket連接，可以使用以下配置：

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

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

2 HTTP

2.1 HTTP里有哪些常見(jiàn)的請(qǐng)求方法？

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

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

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

長(zhǎng)連接與短連接介紹

長(zhǎng)連接：客戶(hù)端與服務(wù)端先建立連接，連接建立后不斷開(kāi)，以便在一段時(shí)間內(nèi)進(jìn)行多次請(qǐng)求和響應(yīng)。這減少了TCP連接的建立和關(guān)閉的開(kāi)銷(xiāo)。短連接：客戶(hù)端與服務(wù)端每個(gè)HTTP請(qǐng)求都會(huì)建立一個(gè)新的TCP連接，并在請(qǐng)求完成后立即關(guān)閉連接。

長(zhǎng)連接與短連接的操作過(guò)程

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

長(zhǎng)連接與短連接的使用時(shí)機(jī)

長(zhǎng)連接：長(zhǎng)連接多用于操作頻繁，點(diǎn)對(duì)點(diǎn)的通訊，而且連接數(shù)不能太多的情況。每個(gè)TCP連接的建立都需要三次握手，每個(gè)TCP連接的斷開(kāi)要四次握手。

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

適用于客戶(hù)端和服務(wù)端通信頻繁的場(chǎng)景，例如聊天室，實(shí)時(shí)游戲，數(shù)據(jù)庫(kù)的連接用長(zhǎng)連接，如果用短連接頻繁的通信會(huì)造成socket錯(cuò)誤，頻繁的socket創(chuàng)建也是對(duì)資源的浪費(fèi)。 2. 短連接：適用于一次性請(qǐng)求和響應(yīng)的情況，例如普通的網(wǎng)頁(yè)瀏覽，其中每個(gè)資源都是單獨(dú)請(qǐng)求的。

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

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

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

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

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

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

301 Moved Permanently（永久移動(dòng)）：資源被永久性移動(dòng)到了新的URL?？蛻?hù)端應(yīng)該使用新的URL重新請(qǐng)求。302 Found（臨時(shí)移動(dòng)）：資源被臨時(shí)性移動(dòng)到了新的URL?？蛻?hù)端應(yīng)該使用新的URL重新請(qǐng)求。

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

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

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

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

2.4 GET和POST的區(qū)別

數(shù)據(jù)傳輸方式

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

請(qǐng)求長(zhǎng)度

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

可見(jiàn)性

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

緩存

GET：由于GET請(qǐng)求是冪等的，可以被瀏覽器和代理服務(wù)器緩存，以提高性能。POST：POST請(qǐng)求通常不會(huì)被緩存，因?yàn)樗鼈兛赡軙?huì)導(dǎo)致服務(wù)器狀態(tài)的變化。

請(qǐng)求冪等性

GET：GET請(qǐng)求是冪等的，多次發(fā)送相同的GET請(qǐng)求應(yīng)該產(chǎn)生相同的結(jié)果，而不會(huì)對(duì)服務(wù)器狀態(tài)產(chǎn)生影響。它通常用于獲取資源或執(zhí)行只讀操作。POST：POST請(qǐng)求通常不是冪等的，多次發(fā)送相同的POST請(qǐng)求可能會(huì)對(duì)服務(wù)器狀態(tài)產(chǎn)生不同的影響，因?yàn)樗ǔＳ糜谔峤粩?shù)據(jù)或執(zhí)行會(huì)修改服務(wù)器狀態(tài)的操作。

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

無(wú)狀態(tài)協(xié)議（Stateless Protocol）是指協(xié)議在處理請(qǐng)求時(shí)不會(huì)記住之前的請(qǐng)求或會(huì)話(huà)信息，每個(gè)請(qǐng)求都是獨(dú)立的，服務(wù)器不會(huì)保存客戶(hù)端的狀態(tài)信息。

HTTP是一種無(wú)狀態(tài)協(xié)議，每個(gè)HTTP請(qǐng)求都是相互獨(dú)立的，服務(wù)器不會(huì)記住之前的請(qǐng)求或會(huì)話(huà)信息。這意味著服務(wù)器無(wú)法直接識(shí)別多個(gè)請(qǐng)求之間的關(guān)聯(lián)，每個(gè)請(qǐng)求都需要提供足夠的信息來(lái)說(shuō)明其意圖。

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

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

2.6 HTTP請(qǐng)求的組成

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

請(qǐng)求行（Request Line）：請(qǐng)求行是HTTP請(qǐng)求的第一行，包含了以下三個(gè)要素：

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

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

Host：指定目標(biāo)服務(wù)器的主機(jī)名和端口號(hào)。User-Agent：指定發(fā)起請(qǐng)求的用戶(hù)代理，通常是瀏覽器信息。Accept：指定可接受的響應(yīng)內(nèi)容類(lèi)型。Content-Type：指定請(qǐng)求正文（如果有的話(huà)）的MIME類(lèi)型。

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）：請(qǐng)求行和請(qǐng)求頭部之間必須有一個(gè)空行，用于分隔頭部信息和請(qǐng)求正文。 4. 請(qǐng)求正文（Request Body）：請(qǐng)求正文是可選的，通常用于包含客戶(hù)端向服務(wù)器發(fā)送的數(shù)據(jù)，例如表單數(shù)據(jù)或請(qǐng)求主體。請(qǐng)求正文的存在和格式取決于請(qǐng)求的方法和目的。

當(dāng)請(qǐng)求方式是POST時(shí)，請(qǐng)求體會(huì)有請(qǐng)求參數(shù)格式如下：

username=zhangsan&password=123

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

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

2.7 HTTP響應(yīng)的組成

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

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

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

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

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)行和響應(yīng)頭部之間必須有一個(gè)空行，用于分隔頭部信息和響應(yīng)正文。 4. 響應(yīng)正文（Response Body）：響應(yīng)正文包含了服務(wù)器返回給客戶(hù)端的實(shí)際數(shù)據(jù)。它的內(nèi)容和格式取決于響應(yīng)的性質(zhì)，例如在HTML頁(yè)面請(qǐng)求中，響應(yīng)正文通常包含HTML文檔；在文件下載請(qǐng)求中，響應(yīng)正文包含文件內(nèi)容。 例如：

Example Page

Hello, World!

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

Cookies機(jī)制和Session機(jī)制都是用于在Web應(yīng)用程序中跟蹤用戶(hù)狀態(tài)和維護(hù)會(huì)話(huà)信息的方式，但它們?cè)趯?shí)現(xiàn)和工作原理上有一些重要的區(qū)別：

存儲(chǔ)位置

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

數(shù)據(jù)存儲(chǔ)

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

生命周期

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

安全性

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

性能

Cookies：Cookies需要在每個(gè)HTTP請(qǐng)求中發(fā)送到服務(wù)器，這可能會(huì)增加網(wǎng)絡(luò)流量。同時(shí)，瀏覽器會(huì)將Cookies附加到每個(gè)請(qǐng)求中，可能會(huì)導(dǎo)致一些額外的開(kāi)銷(xiāo)。Session：Session數(shù)據(jù)存儲(chǔ)在服務(wù)器上，不需要在每個(gè)請(qǐng)求中發(fā)送，因此通常不會(huì)增加網(wǎng)絡(luò)流量，但可能會(huì)占用服務(wù)器資源，特別是在大規(guī)模應(yīng)用程序中。

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

2.9 RPC和HTTP的區(qū)別

RPC（Remote Procedure Call，遠(yuǎn)程過(guò)程調(diào)用）和HTTP（Hypertext Transfer Protocol，超文本傳輸協(xié)議）都是用于不同系統(tǒng)之間通信的協(xié)議，但它們?cè)诠ぷ鞣绞胶蛻?yīng)用領(lǐng)域上有一些重要的區(qū)別：

通信模型

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

數(shù)據(jù)格式

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

通信方式

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

應(yīng)用場(chǎng)景

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

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

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

總結(jié)： RPC和HTTP都是用于不同類(lèi)型的通信的協(xié)議，RPC主要用于構(gòu)建分布式系統(tǒng)中不同組件之間的遠(yuǎn)程調(diào)用，而HTTP主要用于構(gòu)建Web應(yīng)用程序中瀏覽器和服務(wù)器之間的通信。選擇哪種協(xié)議取決于應(yīng)用程序需求和架構(gòu)。有時(shí)，它們也可以結(jié)合使用，例如使用HTTP來(lái)傳輸RPC請(qǐng)求和響應(yīng)。

2.10 HTTP的握手是什么樣的

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

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

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

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

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

協(xié)議類(lèi)型：

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

握手過(guò)程：

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

持久連接：

HTTP是一種短連接協(xié)議，每次請(qǐng)求和響應(yīng)之間都會(huì)關(guān)閉連接，需要重新建立連接。WebSocket是一種長(zhǎng)連接協(xié)議，通過(guò)在握手時(shí)建立的連接，保持連接的狀態(tài)，使得客戶(hù)端和服務(wù)器可以在連接上進(jìn)行實(shí)時(shí)的雙向通信。

數(shù)據(jù)格式：

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

端口：

HTTP默認(rèn)使用端口80，而HTTPS使用端口443。WebSocket則通常使用與HTTP相同的端口，例如，如果你的網(wǎng)站使用HTTPS，WebSocket就使用端口443。

雖然WebSocket協(xié)議和HTTP協(xié)議是不同的協(xié)議，但由于WebSocket握手是通過(guò)HTTP協(xié)議進(jìn)行的，因此它們?cè)谀撤N程度上關(guān)聯(lián)在一起。WebSocket協(xié)議的引入主要是為了解決 HTTP協(xié)議在實(shí)時(shí)雙向通信方面的限制，使得Web應(yīng)用能夠更有效地實(shí)現(xiàn)實(shí)時(shí)通信。

3 HTTPS

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

3.1 HTTP和HTTPS的區(qū)別

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

安全性

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

URL前綴

HTTP：HTTP網(wǎng)站的URL通常以"http://"開(kāi)頭，例如：http://www.example.com。HTTPS：HTTPS網(wǎng)站的URL通常以"https://"開(kāi)頭，例如：https://www.example.com。

端口

HTTP：HTTP默認(rèn)使用端口80進(jìn)行通信。HTTPS：HTTPS默認(rèn)使用端口443進(jìn)行通信。

證書(shū)

HTTP：HTTP不需要使用數(shù)字證書(shū)，因?yàn)樗惶峁┘用芎蜕矸蒡?yàn)證。HTTPS：為了建立HTTPS連接，服務(wù)器需要使用數(shù)字證書(shū)來(lái)驗(yàn)證其身份。客戶(hù)端會(huì)驗(yàn)證證書(shū)的有效性，并確保與服務(wù)器的通信是加密的。證書(shū)通常由受信任的第三方機(jī)構(gòu)頒發(fā)，以確保服務(wù)器的身份。

性能

HTTP：HTTP通信速度較快，因?yàn)椴恍枰用芎徒饷軘?shù)據(jù)，但不安全。HTTPS：HTTPS通信速度較慢，因?yàn)樾枰用芎徒饷軘?shù)據(jù)，但更安全。

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

3.2 HTTPS實(shí)現(xiàn)原理

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

加密通信

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

數(shù)字證書(shū)

服務(wù)器通常需要通過(guò)數(shù)字證書(shū)來(lái)驗(yàn)證其身份。數(shù)字證書(shū)由受信任的第三方證書(shū)頒發(fā)機(jī)構(gòu)（Certificate Authority，CA）簽發(fā)，包含了服務(wù)器的公鑰和與服務(wù)器相關(guān)的信息，同時(shí)也包含CA的數(shù)字簽名?？蛻?hù)端可以使用CA的公鑰來(lái)驗(yàn)證服務(wù)器證書(shū)的有效性，確保連接到的服務(wù)器是合法的。

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

總結(jié)： HTTPS的實(shí)現(xiàn)原理涉及使用對(duì)稱(chēng)和非對(duì)稱(chēng)加密，數(shù)字證書(shū)以及握手過(guò)程來(lái)確保通信的安全性?？蛻?hù)端和服務(wù)器之間的通信在加密的環(huán)境下進(jìn)行，同時(shí)服務(wù)器的身份也得到驗(yàn)證，以防止中間人攻擊和數(shù)據(jù)泄漏。這使得HTTPS成為保護(hù)敏感信息和確保通信隱私的重要工具。

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

參考：查看google瀏覽器里的證書(shū)

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

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

3.4 SSL建立連接過(guò)程

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

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

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

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

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

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

加密：TLS使用對(duì)稱(chēng)密鑰和非對(duì)稱(chēng)密鑰加密算法來(lái)保護(hù)數(shù)據(jù)的機(jī)密性，防止第三方截取和讀取數(shù)據(jù)。完整性驗(yàn)證：TLS使用哈希函數(shù)來(lái)驗(yàn)證數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過(guò)程中沒(méi)有被篡改。身份驗(yàn)證：TLS通過(guò)數(shù)字證書(shū)來(lái)驗(yàn)證通信雙方的身份，確?？蛻?hù)端連接到的服務(wù)器是合法的。

總結(jié)： HTTPS的加密協(xié)議通常是TLS，它通過(guò)加密、完整性驗(yàn)證和身份驗(yàn)證來(lái)保護(hù)網(wǎng)絡(luò)通信的安全性。選擇TLS的版本取決于安全性要求和兼容性考慮。

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

HTTPS通過(guò)數(shù)字證書(shū)來(lái)確保客戶(hù)端收到的服務(wù)器公鑰是真實(shí)有效的，而不是中間人偽造的公鑰。這是通過(guò)以下方式實(shí)現(xiàn)的：

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

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

3.7 第三方攻擊者能否讓自己的證書(shū)顯示出來(lái)的信息也是服務(wù)端呢？

第三方攻擊者（中間人攻擊者）通常無(wú)法獲得合法服務(wù)器的有效數(shù)字證書(shū)，因?yàn)榉?wù)器的數(shù)字證書(shū)是由受信任的證書(shū)頒發(fā)機(jī)構(gòu)（CA）頒發(fā)的，而CA通常會(huì)執(zhí)行嚴(yán)格的驗(yàn)證程序來(lái)確保只有合法服務(wù)器才能獲得證書(shū)。但中間人攻擊者可以嘗試使用自己偽造的證書(shū)來(lái)欺騙客戶(hù)端，稱(chēng)為自簽名證書(shū)，以嘗試進(jìn)行攻擊。

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

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

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

3.8 HTTPS優(yōu)缺點(diǎn)

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

總結(jié)： HTTPS在保護(hù)通信的安全性和隱私方面具有很大的優(yōu)勢(shì)，尤其是在處理敏感信息的應(yīng)用程序中。然而，它也需要考慮性能開(kāi)銷(xiāo)和一些配置和維護(hù)工作。對(duì)于大多數(shù)Web應(yīng)用程序來(lái)說(shuō)，使用HTTPS是非常值得的，因?yàn)樗峁┝吮匾谋Ｗo(hù)和用戶(hù)信任。

3.9 HTTPS的證書(shū)是誰(shuí)驗(yàn)證誰(shuí)

在HTTPS通信中，數(shù)字證書(shū)的驗(yàn)證過(guò)程如下：

證書(shū)頒發(fā)機(jī)構(gòu)(CA)驗(yàn)證網(wǎng)站的身份并向其頒發(fā)證書(shū)。網(wǎng)站將證書(shū)發(fā)送給訪問(wèn)的客戶(hù)端。客戶(hù)端獲取證書(shū)后，驗(yàn)證證書(shū)的頒發(fā)機(jī)構(gòu)是否為可信的CA?？蛻?hù)端驗(yàn)證證書(shū)的內(nèi)容是否與網(wǎng)站地址匹配。如果一切驗(yàn)證通過(guò)，客戶(hù)端就可以信任該證書(shū)真實(shí)屬于該網(wǎng)站。

所以簡(jiǎn)單來(lái)說(shuō)：

CA驗(yàn)證網(wǎng)站，向網(wǎng)站頒發(fā)證書(shū)。客戶(hù)端驗(yàn)證CA是否可信任，以及證書(shū)是否與網(wǎng)站匹配。最后客戶(hù)端驗(yàn)證證書(shū)的有效性和網(wǎng)站的合法性。

總結(jié)： HTTPS證書(shū)驗(yàn)證中，CA驗(yàn)證網(wǎng)站，而用戶(hù)驗(yàn)證CA和證書(shū)本身。這個(gè)雙向驗(yàn)證機(jī)制讓HTTPS證書(shū)系統(tǒng)能夠安全可靠地運(yùn)行。

3.10 HTTPS單向認(rèn)證時(shí)誰(shuí)驗(yàn)證誰(shuí)

在HTTPS單向認(rèn)證中，一般情況下是客戶(hù)端驗(yàn)證服務(wù)器的身份，而不是服務(wù)器驗(yàn)證客戶(hù)端的身份。這是HTTPS的標(biāo)準(zhǔn)配置方式，也被稱(chēng)為單向SSL認(rèn)證。

HTTPS通信中的驗(yàn)證通常如下：

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

總結(jié)： HTTPS的標(biāo)準(zhǔn)配置中，通常是客戶(hù)端驗(yàn)證服務(wù)器的身份，而服務(wù)器通常不驗(yàn)證客戶(hù)端的身份?？蛻?hù)端通過(guò)驗(yàn)證服務(wù)器的證書(shū)來(lái)確保連接到的服務(wù)器是合法的，從而防止中間人攻擊。如果需要服務(wù)器驗(yàn)證客戶(hù)端的身份，可以使用雙向認(rèn)證（雙向SSL認(rèn)證）來(lái)實(shí)現(xiàn)，其中客戶(hù)端和服務(wù)器都會(huì)驗(yàn)證對(duì)方的身份。

3.11 HTTPS客戶(hù)端如何驗(yàn)證服務(wù)端證書(shū)的合法性

在HTTPS通信中，客戶(hù)端通過(guò)驗(yàn)證服務(wù)器證書(shū)的合法性來(lái)確認(rèn)連接到的服務(wù)器的身份。這個(gè)驗(yàn)證過(guò)程通常包括以下步驟：

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

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

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

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

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

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

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

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

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

3.13 HTTPS交換的是什么

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

其實(shí)也就是建立連接的過(guò)程。

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

HTTPS數(shù)據(jù)傳輸使用對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密結(jié)合的方式來(lái)保障數(shù)據(jù)的安全性和保密性。

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

對(duì)稱(chēng)加密：對(duì)稱(chēng)加密使用相同的密鑰來(lái)加密和解密數(shù)據(jù)，因此被稱(chēng)為"對(duì)稱(chēng)"。在HTTPS通信中，客戶(hù)端和服務(wù)器在SSL/TLS握手過(guò)程中協(xié)商出一個(gè)對(duì)稱(chēng)的會(huì)話(huà)密鑰（Session Key）。這個(gè)會(huì)話(huà)密鑰用于加密和解密實(shí)際的HTTPS數(shù)據(jù)。常見(jiàn)的對(duì)稱(chēng)加密算法包括：

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

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

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

數(shù)字簽名：數(shù)字簽名是一種非對(duì)稱(chēng)加密的應(yīng)用，用于驗(yàn)證數(shù)字證書(shū)的有效性。服務(wù)器的數(shù)字證書(shū)包含服務(wù)器的公鑰和由證書(shū)頒發(fā)機(jī)構(gòu)（CA）簽名的信息。客戶(hù)端使用CA的公鑰來(lái)驗(yàn)證證書(shū)的簽名，以確保證書(shū)是合法的。

HTTPS通信的基本過(guò)程是：在握手階段，服務(wù)器和客戶(hù)端協(xié)商出一個(gè)對(duì)稱(chēng)的會(huì)話(huà)密鑰，該密鑰用于加密和解密HTTP數(shù)據(jù)。這個(gè)對(duì)稱(chēng)會(huì)話(huà)密鑰由服務(wù)器的非對(duì)稱(chēng)公鑰加密傳輸給客戶(hù)端，客戶(hù)端使用私鑰解密得到該密鑰。之后，客戶(hù)端和服務(wù)器使用對(duì)稱(chēng)密鑰來(lái)加密和解密通信數(shù)據(jù)，保障數(shù)據(jù)的機(jī)密性和完整性。

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

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

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

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

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

總結(jié)： HTTP/2相對(duì)于HTTP/1具有更高的性能、更低的延遲和更高的效率，可以改善網(wǎng)站的加載速度和用戶(hù)體驗(yàn)。因此，許多網(wǎng)站和服務(wù)已經(jīng)采用了HTTP/2來(lái)提供更快的性能。

4.1 GRPC是HTTP2還是HTTP1

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

5 TCP

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

5.1 TCP和HTTP的區(qū)別

HTTP（Hypertext Transfer Protocol）和TCP（Transmission Control Protocol）是計(jì)算機(jī)網(wǎng)絡(luò)中的兩個(gè)不同的協(xié)議，它們?cè)诰W(wǎng)絡(luò)通信中扮演不同的角色，有以下主要區(qū)別：

層級(jí)關(guān)系：

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

功能：

TCP主要負(fù)責(zé)數(shù)據(jù)傳輸?shù)目煽啃院陀行蛐?。它確保數(shù)據(jù)能夠從一個(gè)端點(diǎn)安全地傳輸?shù)搅硪粋€(gè)端點(diǎn)，而不會(huì)損壞、丟失或亂序。HTTP主要負(fù)責(zé)定義客戶(hù)端和服務(wù)器之間的請(qǐng)求和響應(yīng)的格式，以及如何處理和呈現(xiàn)文檔或數(shù)據(jù)。

連接性：

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

端口：

TCP使用端口號(hào)來(lái)標(biāo)識(shí)不同的網(wǎng)絡(luò)應(yīng)用程序或服務(wù)。例如，Web服務(wù)器通常使用TCP端口80或443。HTTP通?；赥CP連接，使用HTTP默認(rèn)端口80（非加密）或443（加密）。

通信內(nèi)容：

TCP傳輸?shù)氖窃级M(jìn)制數(shù)據(jù)流，它沒(méi)有關(guān)于數(shù)據(jù)的上下文或語(yǔ)義。HTTP傳輸?shù)氖腔谖谋镜南?，這些消息包含請(qǐng)求或響應(yīng)的元信息和數(shù)據(jù)，以及用于標(biāo)識(shí)資源的URL。

應(yīng)用領(lǐng)域：

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

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

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

TCP的數(shù)據(jù)包包含源端口和目標(biāo)端口，HTTP不包含端口信息。TCP的包頭簡(jiǎn)單，只包含源端口、目標(biāo)端口、序號(hào)、確認(rèn)號(hào)等信息。HTTP的數(shù)據(jù)包更復(fù)雜，包含請(qǐng)求方法、URL、協(xié)議版本、請(qǐng)求頭部、消息體等信息。TCP關(guān)注傳輸， packets只包含數(shù)據(jù)。HTTP關(guān)注應(yīng)用信息，packets包含具體的請(qǐng)求或響應(yīng)詳情。TCP的packets按順序傳輸，HTTP的packets可以亂序。TCP需要建立連接、流量控制和擁塞控制。HTTP運(yùn)行在TCP連接上，可以忽略這些問(wèn)題。TCP對(duì)數(shù)據(jù)包的大小沒(méi)有限制。HTTP一般將數(shù)據(jù)包限制在1500字節(jié)以?xún)?nèi)。TCP的packets只有頭部。HTTP的packets有頭部、消息體等完整結(jié)構(gòu)。TCP是面向連接的協(xié)議。HTTP本質(zhì)上是無(wú)連接的。

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

5.3 TCP特點(diǎn)

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

總結(jié)： TCP是一種非常可靠的協(xié)議，適用于需要可靠數(shù)據(jù)傳輸和連接性能的應(yīng)用程序，如網(wǎng)頁(yè)瀏覽、電子郵件、文件傳輸、實(shí)時(shí)通信等。它是互聯(lián)網(wǎng)中的基礎(chǔ)協(xié)議之一，確保了數(shù)據(jù)在網(wǎng)絡(luò)中的可靠傳輸。

5.4 TCP使用場(chǎng)景

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

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

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

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

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

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

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

5.6 TCP三次握手

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

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

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

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

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

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

TCP在數(shù)據(jù)傳輸過(guò)程中，包括握手階段之后，會(huì)使用一種校驗(yàn)和機(jī)制來(lái)檢測(cè)數(shù)據(jù)是否被篡改。這個(gè)校驗(yàn)和通常稱(chēng)為T(mén)CP校驗(yàn)和（TCP Checksum）。

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

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

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

總結(jié)： TCP使用校驗(yàn)和機(jī)制來(lái)檢測(cè)和處理數(shù)據(jù)傳輸中的篡改或損壞問(wèn)題，以確保數(shù)據(jù)的可靠性和完整性。這是TCP協(xié)議的一個(gè)重要特性，有助于提高網(wǎng)絡(luò)通信的可靠性。

5.8 TCP三次握手的兩種隊(duì)列

參考1：TCP連接三次握手中的重要數(shù)據(jù)結(jié)構(gòu)：半連接隊(duì)列和全連接隊(duì)列 在TCP三次握手的時(shí)候，服務(wù)端會(huì)維護(hù)兩個(gè)隊(duì)列：監(jiān)聽(tīng)隊(duì)列（Listen Queue）和已完成隊(duì)列（Completed Connection Queue）。

監(jiān)聽(tīng)隊(duì)列（Listen Queue）：

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

已完成隊(duì)列（Completed Connection Queue）：

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

總結(jié)： 監(jiān)聽(tīng)隊(duì)列用于存放等待服務(wù)器確認(rèn)的連接請(qǐng)求，而已完成隊(duì)列用于存放已經(jīng)建立的連接，準(zhǔn)備進(jìn)行數(shù)據(jù)傳輸。這兩個(gè)隊(duì)列在TCP連接建立過(guò)程中起著重要的作用，確保了連接的正常建立和管理。當(dāng)連接終止時(shí)，也有相應(yīng)的隊(duì)列來(lái)管理連接的釋放。

5.8.1 TCP三次握手的兩種隊(duì)列溢出

不管是半連接隊(duì)列還是全連接隊(duì)列，都有最大長(zhǎng)度限制，超過(guò)限制時(shí)，內(nèi)核會(huì)直接丟棄，或返回RST包。

半連接隊(duì)列溢出： 客戶(hù)端發(fā)送SYN報(bào)文和服務(wù)端進(jìn)行第一次握手，此時(shí)服務(wù)端將此請(qǐng)求信息放在半連接隊(duì)列中并回復(fù)SYN+ACK給客戶(hù)端。這里也就是SYN攻擊的點(diǎn)，攻擊方要做的就是不停的建立連接，但是卻不給出ACK確認(rèn)，導(dǎo)致半連接隊(duì)列滿(mǎn)了，其他請(qǐng)求無(wú)法進(jìn)入。

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

全連接隊(duì)列滿(mǎn)了，就只會(huì)丟棄連接嗎？ 實(shí)際上，丟棄連接只是Linux的默認(rèn)行為，我們還可以選擇向客戶(hù)端發(fā)送RST復(fù)位報(bào)文，告訴客戶(hù)端連接已經(jīng)建立失敗。 tcp_abort_on_overflow 共有兩個(gè)值分別是0和1，其分別表示： 0 ：表示如果全連接隊(duì)列滿(mǎn)了，那么server丟棄client發(fā)過(guò)來(lái)的ack； 1 ：表示如果全連接隊(duì)列滿(mǎn)了，那么server發(fā)送一個(gè)reset 包給 client，表示廢掉這個(gè)握手過(guò)程和這個(gè)連接；

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

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

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

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

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

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

總結(jié)： TCP通過(guò)這些機(jī)制和策略，以及其他一些技術(shù)手段，來(lái)實(shí)現(xiàn)可靠性傳輸，確保數(shù)據(jù)在網(wǎng)絡(luò)中的可靠傳輸和正確接收。這使得TCP成為一種非常可靠的協(xié)議，適用于各種需要可靠性傳輸?shù)膽?yīng)用，如網(wǎng)頁(yè)瀏覽、電子郵件、文件傳輸?shù)取?/p>

5.10 TCP建立連接的時(shí)候?yàn)槭裁词侨挝帐?，不是兩次或四?/p>

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

以下是三次握手的原因和過(guò)程：

確保雙方都愿意建立連接：通過(guò)三次握手，確保了客戶(hù)端和服務(wù)器都愿意建立連接。如果只有兩次握手，那么可能會(huì)導(dǎo)致一方不知道對(duì)方是否愿意建立連接，從而引發(fā)不確定性和安全問(wèn)題。防止舊連接的問(wèn)題：在網(wǎng)絡(luò)中，已經(jīng)關(guān)閉連接的數(shù)據(jù)包可能在某段時(shí)間內(nèi)仍然存在，這是因?yàn)榫W(wǎng)絡(luò)中的數(shù)據(jù)包可能會(huì)延遲或復(fù)制。如果只有兩次握手，可能會(huì)導(dǎo)致在新連接中誤認(rèn)為是舊連接的數(shù)據(jù)包，從而引發(fā)問(wèn)題。通過(guò)第三次握手，可以確保是新的連接，防止這種問(wèn)題的發(fā)生。防止連接資源浪費(fèi)：如果連接建立后不進(jìn)行三次握手的確認(rèn)，那么服務(wù)器可能會(huì)浪費(fèi)資源來(lái)處理無(wú)效的連接請(qǐng)求。

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

5.11 TCP四次揮手

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

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

第一次揮手 - 客戶(hù)端發(fā)送連接關(guān)閉請(qǐng)求（FIN from Client）：

客戶(hù)端首先決定關(guān)閉連接，它向服務(wù)器發(fā)送一個(gè)帶有FIN（Finish，結(jié)束）標(biāo)志的TCP數(shù)據(jù)包給服務(wù)器，表示客戶(hù)端不再發(fā)送數(shù)據(jù)給服務(wù)器，但仍然愿意接收來(lái)自服務(wù)器的數(shù)據(jù)?？蛻?hù)端進(jìn)入FIN_WAIT_1狀態(tài)，等待服務(wù)器的確認(rèn)或拒絕。

第二次揮手 - 服務(wù)器確認(rèn)關(guān)閉請(qǐng)求（ACK from Server）：

服務(wù)器接收到客戶(hù)端的FIN后，會(huì)發(fā)送一個(gè)帶有確認(rèn)ACK標(biāo)志的TCP數(shù)據(jù)包給客戶(hù)端，表示服務(wù)器已收到客戶(hù)端的關(guān)閉請(qǐng)求。此時(shí)服務(wù)器進(jìn)入CLOSE_WAIT狀態(tài)，客戶(hù)端繼續(xù)等待來(lái)自服務(wù)器的可能未發(fā)送完的數(shù)據(jù)。

第三次揮手 - 服務(wù)器發(fā)送連接關(guān)閉請(qǐng)求（FIN from Server）：

當(dāng)服務(wù)器確定不再有數(shù)據(jù)要發(fā)送給客戶(hù)端時(shí)，服務(wù)器發(fā)送一個(gè)帶有FIN標(biāo)志的TCP數(shù)據(jù)包給客戶(hù)端，表示服務(wù)器也準(zhǔn)備好關(guān)閉連接。服務(wù)器進(jìn)入LAST_ACK狀態(tài)，等待客戶(hù)端的確認(rèn)。

第四次揮手 - 客戶(hù)端確認(rèn)關(guān)閉請(qǐng)求（ACK from Client）：

客戶(hù)端收到服務(wù)器的FIN包后進(jìn)入TIME_WAIT狀態(tài)，會(huì)發(fā)送一個(gè)ACK包作為確認(rèn)，并等待一段時(shí)間以確保可能在網(wǎng)絡(luò)中滯留的ACK數(shù)據(jù)包到達(dá)服務(wù)器。服務(wù)器收到這個(gè)ACK后，進(jìn)入CLOSED狀態(tài)，連接完全關(guān)閉?？蛻?hù)端則會(huì)等一段時(shí)間再進(jìn)入關(guān)閉狀態(tài)，釋放資源，結(jié)束TIME_WAIT狀態(tài)。因?yàn)榈谒拇螕]手不一定能成功發(fā)給服務(wù)端，所以要等一下，看看服務(wù)端會(huì)不會(huì)因?yàn)闆](méi)收到第四次揮手，而重發(fā)第三次揮手。

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

注意：

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

5.12 TCP前面加個(gè)防火墻，那TCP的包會(huì)在哪一步被攔截掉？

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

三次握手建立連接時(shí)，防火墻可以攔截SYN包，導(dǎo)致無(wú)法建立連接。數(shù)據(jù)傳輸過(guò)程中，防火墻可以攔截任何一個(gè)方向的TCP數(shù)據(jù)包。四次揮手?jǐn)嚅_(kāi)連接時(shí)，防火墻可以攔截FIN/ACK包，導(dǎo)致無(wú)法正常斷開(kāi)。如果啟用了狀態(tài)檢測(cè)，防火墻可以攔截不符合預(yù)期狀態(tài)的TCP包。防火墻也可以攔截重傳的TCP包。防火墻可以過(guò)濾指定端口的TCP包，直接阻止連接。

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

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

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

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

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

5.14 TCP可能有幾萬(wàn)個(gè)、幾十萬(wàn)個(gè)、上百萬(wàn)個(gè)鏈接都在這個(gè)端口上，怎么知道它是哪個(gè)鏈接，對(duì)應(yīng)哪個(gè)用戶(hù)，對(duì)應(yīng)哪個(gè)請(qǐng)求？

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

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

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

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

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

5.15.1 為什么TCP會(huì)粘包，UDP不會(huì)粘包

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

深知大多數(shù)Go語(yǔ)言工程師，想要提升技能，往往是自己摸索成長(zhǎng)或者是報(bào)班學(xué)習(xí)，但對(duì)于培訓(xùn)機(jī)構(gòu)動(dòng)則幾千的學(xué)費(fèi)，著實(shí)壓力不小。自己不成體系的自學(xué)效果低效又漫長(zhǎng)，而且極易碰到天花板技術(shù)停滯不前！

因此收集整理了一份《2024年Go語(yǔ)言全套學(xué)習(xí)資料》，初衷也很簡(jiǎn)單，就是希望能夠幫助到想自學(xué)提升又不知道該從何學(xué)起的朋友，同時(shí)減輕大家的負(fù)擔(dān)。

既有適合小白學(xué)習(xí)的零基礎(chǔ)資料，也有適合3年以上經(jīng)驗(yàn)的小伙伴深入學(xué)習(xí)提升的進(jìn)階課程，基本涵蓋了95%以上Golang知識(shí)點(diǎn)，真正體系化！

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

如果你覺(jué)得這些內(nèi)容對(duì)你有幫助，可以添加V獲?。簐ip1024b （備注Go）

一個(gè)人可以走的很快，但一群人才能走的更遠(yuǎn)。不論你是正從事IT行業(yè)的老鳥(niǎo)或是對(duì)IT行業(yè)感興趣的新人，都?xì)g迎掃碼加入我們的的圈子（技術(shù)交流、學(xué)習(xí)資源、職場(chǎng)吐槽、大廠內(nèi)推、面試輔導(dǎo)），讓我們一起學(xué)習(xí)成長(zhǎng)！

來(lái)源。 6. 網(wǎng)絡(luò)分析工具：網(wǎng)絡(luò)分析工具可以用于監(jiān)視和分析網(wǎng)絡(luò)流量?？梢允褂眠@些工具來(lái)捕獲和分析TCP數(shù)據(jù)包，以查看連接的詳細(xì)信息，包括源IP、目標(biāo)IP、源端口、目標(biāo)端口等。 7. 負(fù)載均衡器和代理服務(wù)器：如果有負(fù)載均衡器或代理服務(wù)器位于服務(wù)器端和客戶(hù)端之間，它們通常會(huì)在處理連接時(shí)添加一些信息，以幫助將連接路由到正確的后端服務(wù)器或應(yīng)用程序?qū)嵗?/p>

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

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

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

5.15.1 為什么TCP會(huì)粘包，UDP不會(huì)粘包

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

深知大多數(shù)Go語(yǔ)言工程師，想要提升技能，往往是自己摸索成長(zhǎng)或者是報(bào)班學(xué)習(xí)，但對(duì)于培訓(xùn)機(jī)構(gòu)動(dòng)則幾千的學(xué)費(fèi)，著實(shí)壓力不小。自己不成體系的自學(xué)效果低效又漫長(zhǎng)，而且極易碰到天花板技術(shù)停滯不前！

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

既有適合小白學(xué)習(xí)的零基礎(chǔ)資料，也有適合3年以上經(jīng)驗(yàn)的小伙伴深入學(xué)習(xí)提升的進(jìn)階課程，基本涵蓋了95%以上Golang知識(shí)點(diǎn)，真正體系化！

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

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

一個(gè)人可以走的很快，但一群人才能走的更遠(yuǎn)。不論你是正從事IT行業(yè)的老鳥(niǎo)或是對(duì)IT行業(yè)感興趣的新人，都?xì)g迎掃碼加入我們的的圈子（技術(shù)交流、學(xué)習(xí)資源、職場(chǎng)吐槽、大廠內(nèi)推、面試輔導(dǎo)），讓我們一起學(xué)習(xí)成長(zhǎng)！

柚子快報(bào)激活碼778899分享：面試 Example Page

http://yzkb.51969.com/

文章來(lái)源