TCP通訊原理：三次握手，四次揮手

TCP（Transmission Control Protocol）通信中的"三次握手"和"四次揮手"是建立和終止TCP連接時(shí)的標(biāo)準(zhǔn)過(guò)程，用于確保數(shù)據(jù)的可靠傳輸和連接的正確關(guān)閉。

三次握手（Three-Way Handshake）：

1. 第一步 - 客戶端發(fā)送請(qǐng)求：

   • 客戶端發(fā)送一個(gè)SYN（同步）標(biāo)志位的TCP數(shù)據(jù)包到服務(wù)器，用來(lái)請(qǐng)求建立連接。
   • 此時(shí)，客戶端進(jìn)入"SYN_SENT"狀態(tài)，等待服務(wù)器的響應(yīng)。

2. 第二步 - 服務(wù)器確認(rèn)請(qǐng)求：

   • 服務(wù)器收到客戶端的SYN數(shù)據(jù)包后，會(huì)發(fā)送一個(gè)包含SYN和ACK（確認(rèn)）標(biāo)志位的數(shù)據(jù)包作為響應(yīng)。
   • 此時(shí)，服務(wù)器進(jìn)入"SYN_RCVD"狀態(tài)，表示它已經(jīng)同意建立連接。

3. 第三步 - 客戶端確認(rèn)連接：

   • 客戶端收到服務(wù)器的響應(yīng)后，發(fā)送一個(gè)帶有ACK標(biāo)志位的數(shù)據(jù)包給服務(wù)器。
   • 此時(shí)，客戶端和服務(wù)器都進(jìn)入"ESTABLISHED"狀態(tài)，連接已建立，雙方可以開(kāi)始進(jìn)行數(shù)據(jù)傳輸。

四次揮手（Four-Way Handshake）：

1. 第一步 - 客戶端發(fā)起關(guān)閉：

   • 客戶端發(fā)送一個(gè)帶有FIN（結(jié)束）標(biāo)志位的數(shù)據(jù)包給服務(wù)器，表示它要關(guān)閉連接，但仍然可以接收數(shù)據(jù)。
   • 此時(shí)，客戶端進(jìn)入"FIN_WAIT_1"狀態(tài)，等待服務(wù)器的確認(rèn)。

2. 第二步 - 服務(wù)器確認(rèn)關(guān)閉：

   • 服務(wù)器收到客戶端的FIN數(shù)據(jù)包后，發(fā)送一個(gè)帶有ACK標(biāo)志位的數(shù)據(jù)包作為響應(yīng)，表示它接受了客戶端的關(guān)閉請(qǐng)求。
   • 此時(shí)，服務(wù)器進(jìn)入"CLOSE_WAIT"狀態(tài)，客戶端進(jìn)入"FIN_WAIT_2"狀態(tài)。

3. 第三步 - 服務(wù)器發(fā)起關(guān)閉：

   • 服務(wù)器發(fā)送一個(gè)帶有FIN標(biāo)志位的數(shù)據(jù)包給客戶端，表示服務(wù)器也準(zhǔn)備關(guān)閉連接。
   • 此時(shí)，服務(wù)器進(jìn)入"LAST_ACK"狀態(tài)。

4. 第四步 - 客戶端確認(rèn)關(guān)閉：

   • 客戶端收到服務(wù)器的FIN數(shù)據(jù)包后，發(fā)送一個(gè)帶有ACK標(biāo)志位的數(shù)據(jù)包作為確認(rèn)。
   • 此時(shí)，客戶端進(jìn)入"TIME_WAIT"狀態(tài)，等待一段時(shí)間后才完全關(guān)閉連接。
   • 服務(wù)器收到客戶端的確認(rèn)后，進(jìn)入"CLOSED"狀態(tài)，連接完全關(guān)閉。

這個(gè)四步揮手的過(guò)程確保了雙方都有機(jī)會(huì)完成未完成的數(shù)據(jù)傳輸，以及關(guān)閉連接，同時(shí)避免了數(shù)據(jù)的丟失和不完整的傳輸。揮手完成后，雙方的連接被完全關(guān)閉。

服務(wù)器設(shè)置"CLOSE_WAIT"狀態(tài)的目的是啥？

服務(wù)器在設(shè)置"CLOSE_WAIT"狀態(tài)的目的是等待客戶端確認(rèn)關(guān)閉連接。在TCP連接的四次揮手過(guò)程中，服務(wù)器在發(fā)送關(guān)閉請(qǐng)求后進(jìn)入"CLOSE_WAIT"狀態(tài)，這表示服務(wù)器已經(jīng)發(fā)送了一個(gè)帶有FIN標(biāo)志位的數(shù)據(jù)包，告訴客戶端它要關(guān)閉連接。服務(wù)器進(jìn)入這個(gè)狀態(tài)是為了等待客戶端的確認(rèn)，以確保連接被雙方正確地關(guān)閉。

"CLOSE_WAIT"狀態(tài)是暫時(shí)的，通常在服務(wù)器端只會(huì)停留很短的時(shí)間，直到收到客戶端的確認(rèn)，然后服務(wù)器會(huì)進(jìn)入"CLOSED"狀態(tài)，連接被完全關(guān)閉。這個(gè)等待確認(rèn)的過(guò)程允許服務(wù)器確?？蛻舳艘呀?jīng)成功收到了服務(wù)器的關(guān)閉請(qǐng)求，以避免數(shù)據(jù)的丟失或不完整的傳輸。

總之，服務(wù)器設(shè)置"CLOSE_WAIT"狀態(tài)是為了在關(guān)閉連接時(shí)等待客戶端的確認(rèn)，以確保連接被正確地關(guān)閉，從而維護(hù)數(shù)據(jù)的完整性和可靠性。這是TCP連接管理中的一個(gè)重要步驟，確保數(shù)據(jù)可靠傳輸和連接的正常終止。

UTF-8是怎么進(jìn)行編碼的？

UTF-8（Unicode Transformation Format - 8-bit）是一種可變長(zhǎng)度字符編碼方式，用于表示Unicode字符集中的字符。UTF-8編碼的規(guī)則相對(duì)簡(jiǎn)單，它根據(jù)字符的Unicode碼點(diǎn)值的范圍來(lái)確定使用多少字節(jié)來(lái)表示一個(gè)字符。以下是UTF-8的編碼規(guī)則：

1. ASCII字符（U+0000到U+007F）：

   • ASCII字符使用單個(gè)字節(jié)（8位）進(jìn)行編碼，最高位（最左邊的位）為0。
   • 例如，字母A的Unicode碼點(diǎn)是U+0041，它在UTF-8中編碼為01000001。

2. 通用多字節(jié)編碼：

   • 大多數(shù)Unicode字符使用多字節(jié)進(jìn)行編碼。
   • 每個(gè)多字節(jié)序列以一個(gè)字節(jié)的起始字節(jié)開(kāi)始，這個(gè)字節(jié)中的高位位表示此序列的長(zhǎng)度。
   • 例如，兩字節(jié)序列以110xxxxx 10xxxxxx開(kāi)始，三字節(jié)序列以1110xxxx 10xxxxxx 10xxxxxx開(kāi)始，四字節(jié)序列以11110xxx 10xxxxxx 10xxxxxx 10xxxxxx開(kāi)始。
   • 剩余的字節(jié)都以10xxxxxx開(kāi)始。

3. 字符值：

   • 多字節(jié)序列中的x位用于存儲(chǔ)字符的值，組成了Unicode碼點(diǎn)。
   • 字符值的范圍根據(jù)字節(jié)序列的長(zhǎng)度不同而變化，不同長(zhǎng)度的字節(jié)序列可以表示不同范圍的Unicode字符。

下面是一些UTF-8編碼的示例：

• 字母A（U+0041）編碼為01000001。
• 歐元符號(hào)€（U+20AC）編碼為11100010 10000010 10101100。
• 中文字符“你”（U+4F60）編碼為11100100 10111101 10010000。
• 表情符號(hào)😀（U+1F600）編碼為11110000 10011111 10011000 10000000。

UTF-8編碼的靈活性使其成為一種廣泛使用的字符編碼方式，因?yàn)樗梢员硎舅蠻nicode字符，包括ASCII字符，同時(shí)保持了向后兼容性。這意味著如果一個(gè)UTF-8文本只包含ASCII字符，那么它與ASCII編碼是一致的。

http是怎么傳遞參數(shù)的

HTTP請(qǐng)求可以傳遞參數(shù)以向服務(wù)器發(fā)送數(shù)據(jù)或請(qǐng)求特定資源。HTTP請(qǐng)求中傳遞參數(shù)的主要方法包括：

1. 查詢字符串參數(shù)：

   • 在URL中使用查詢字符串傳遞參數(shù)，通常是在URL的問(wèn)號(hào)后面，多個(gè)參數(shù)之間使用"&"符號(hào)分隔。
   • 例如：http://example.com/resource?param1=value1&param2=value2
   • 在GET請(qǐng)求中，參數(shù)通常以明文形式附加在URL上，因此對(duì)于敏感信息來(lái)說(shuō)不安全。
   • 用于傳遞少量參數(shù)，如搜索關(guān)鍵字或分頁(yè)信息。

2. 請(qǐng)求頭參數(shù)：

   • 可以在HTTP請(qǐng)求的頭部（Header）中添加自定義參數(shù)，這些參數(shù)以鍵值對(duì)的形式出現(xiàn)。
   • 例如，可以在請(qǐng)求頭中添加Authorization頭以進(jìn)行身份驗(yàn)證，或者在Accept頭中指定響應(yīng)的內(nèi)容類(lèi)型。
   • 用于傳遞與請(qǐng)求相關(guān)的元信息和控制參數(shù)。

3. 請(qǐng)求體參數(shù)：

   • 在POST、PUT等HTTP請(qǐng)求方法中，可以將參數(shù)放置在請(qǐng)求體（Request Body）中。
   • 參數(shù)通常以表單數(shù)據(jù)、JSON、XML等格式進(jìn)行編碼，并在請(qǐng)求頭中指定Content-Type來(lái)表示數(shù)據(jù)類(lèi)型。
   • 用于傳遞大量參數(shù)或包含復(fù)雜結(jié)構(gòu)的參數(shù)。

4. URL路徑參數(shù)：

   • 有時(shí)，參數(shù)可以作為URL路徑的一部分來(lái)傳遞。
   • 例如：http://example.com/resource/value1/value2，其中"value1"和"value2"可以被服務(wù)器解析為參數(shù)。
   • 用于RESTful風(fēng)格的API設(shè)計(jì)中，用于傳遞資源標(biāo)識(shí)符或參數(shù)。

5. Cookie參數(shù)：

   • 可以使用Cookie來(lái)在HTTP請(qǐng)求之間保持狀態(tài)信息。
   • 服務(wù)器可以設(shè)置Cookie并在客戶端之間傳遞，客戶端會(huì)將Cookie自動(dòng)包含在后續(xù)的HTTP請(qǐng)求中。
   • 用于跟蹤用戶會(huì)話和存儲(chǔ)客戶端狀態(tài)信息。

6. 會(huì)話參數(shù)：

   • 通過(guò)使用會(huì)話（Session）來(lái)存儲(chǔ)和管理參數(shù)，通常在服務(wù)器端。
   • 客戶端在登錄后會(huì)獲得一個(gè)會(huì)話標(biāo)識(shí)符（Session ID），該標(biāo)識(shí)符用于關(guān)聯(lián)客戶端與服務(wù)器端的會(huì)話數(shù)據(jù)。
   • 用于保持用戶狀態(tài)和在多個(gè)請(qǐng)求之間共享數(shù)據(jù)。

HTTP請(qǐng)求的參數(shù)傳遞方式取決于應(yīng)用程序的需求和設(shè)計(jì)。不同的HTTP框架和庫(kù)可能提供不同的方式來(lái)處理參數(shù)。在處理HTTP請(qǐng)求時(shí)，服務(wù)器通常會(huì)解析請(qǐng)求中的參數(shù)，并根據(jù)參數(shù)的內(nèi)容執(zhí)行相應(yīng)的操作或返回響應(yīng)。

用戶名和密碼等參數(shù)是怎么傳遞，為什么這么傳遞？

用戶名和密碼等敏感信息在網(wǎng)絡(luò)通信中需要以安全的方式傳遞，以保護(hù)用戶的隱私和安全。通常，這些信息是在身份驗(yàn)證過(guò)程中傳遞的，以下是一些常見(jiàn)的傳遞方法以及為什么要這樣傳遞的原因：

1. HTTP基本認(rèn)證：

   • 用戶名和密碼可以通過(guò)HTTP基本認(rèn)證傳遞，這是HTTP協(xié)議的一種內(nèi)置身份驗(yàn)證機(jī)制。
   • 客戶端將用戶名和密碼編碼為Base64字符串，并將其添加到HTTP請(qǐng)求頭的"Authorization"字段中。
   • 這種方法簡(jiǎn)單易用，但不是最安全的方式，因?yàn)锽ase64編碼不是加密，容易受到竊聽(tīng)攻擊。
   • 常用于簡(jiǎn)單的身份驗(yàn)證，但不建議在非安全環(huán)境中使用。

2. HTTPS：

   • 使用HTTPS（HTTP Secure）協(xié)議來(lái)傳遞用戶名和密碼以及其他敏感信息，以加密數(shù)據(jù)傳輸。
   • HTTPS使用TLS/SSL加密來(lái)保護(hù)通信，確保傳輸?shù)臄?shù)據(jù)在傳輸過(guò)程中是安全的。
   • 這是一種最安全的傳遞敏感信息的方式，常用于登錄和傳輸敏感數(shù)據(jù)，因?yàn)樗峁┝硕说蕉说募用芎桶踩浴?/li>

3. 表單認(rèn)證：

   • 用戶名和密碼可以通過(guò)HTML表單輸入，并通過(guò)POST請(qǐng)求將它們發(fā)送到服務(wù)器。
   • 服務(wù)器接收到POST請(qǐng)求后，會(huì)驗(yàn)證用戶提供的用戶名和密碼是否正確。
   • 這通常用于Web應(yīng)用程序的登錄頁(yè)面，用戶可以安全地輸入其憑據(jù)。

4. 令牌認(rèn)證：

   • 用戶信息可以通過(guò)令牌（Token）進(jìn)行傳遞，用戶在登錄后會(huì)獲得一個(gè)令牌，然后將令牌包含在每個(gè)后續(xù)請(qǐng)求的頭部或請(qǐng)求參數(shù)中。
   • 服務(wù)器使用令牌來(lái)驗(yàn)證用戶的身份，而不需要在每個(gè)請(qǐng)求中傳遞明文的用戶名和密碼。
   • 令牌可以具有一定的生命周期，并且可以存儲(chǔ)在安全的方式中，減少了暴露密碼的風(fēng)險(xiǎn)。

5. OAuth認(rèn)證：

   • OAuth是一種開(kāi)放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方應(yīng)用程序訪問(wèn)他們的資源，而不需要將密碼傳遞給第三方應(yīng)用。
   • 用戶在OAuth中進(jìn)行授權(quán)，然后服務(wù)器生成訪問(wèn)令牌，第三方應(yīng)用程序使用該令牌來(lái)訪問(wèn)受保護(hù)的資源。
   • OAuth提供了一種安全的方式來(lái)授權(quán)和傳遞用戶信息，而無(wú)需直接傳遞用戶名和密碼。

這些方法的選擇取決于應(yīng)用程序的需求和安全性要求。在設(shè)計(jì)和實(shí)施身份驗(yàn)證和數(shù)據(jù)傳輸方案時(shí)，必須考慮安全性，并選擇適當(dāng)?shù)姆椒▉?lái)保護(hù)用戶信息。HTTPS是一種常用的方式，因?yàn)樗峁┝硕说蕉说臄?shù)據(jù)加密和完整性保護(hù)。同時(shí)，令牌認(rèn)證和OAuth等方法也提供了安全且便于管理的方式來(lái)處理用戶憑據(jù)和授權(quán)。

如果前端禁用token或者cookies，這樣的敏感信息怎么傳遞

如果前端禁用了使用token或cookies等傳遞敏感信息的方式，仍然需要傳遞敏感信息，可以考慮以下替代方法：

1. 在請(qǐng)求頭中使用自定義頭部：

   • 可以在HTTP請(qǐng)求頭中添加自定義的頭部字段，將敏感信息放入這些頭部字段中。但請(qǐng)注意，這仍然不是最安全的方式，因?yàn)轭^部字段仍然可以被竊聽(tīng)或中間人攻擊所威脅。

2. 請(qǐng)求參數(shù)加密：

   • 將敏感信息加密后，作為請(qǐng)求的參數(shù)進(jìn)行傳遞。前端和后端必須使用相同的加密算法和密鑰來(lái)加密和解密數(shù)據(jù)。
   • 這可以提供一定程度的保護(hù)，但仍然可能受到中間人攻擊的威脅。

3. 使用單次令牌（One-Time Token）：

   • 生成一次性令牌，令牌只能用一次，并且在使用后立即失效。這樣可以降低令牌泄露的風(fēng)險(xiǎn)。
   • 服務(wù)器和客戶端之間必須共享一種機(jī)制來(lái)生成和驗(yàn)證這些一次性令牌。

4. IP地址限制：

   • 對(duì)于一些情況下，可以限制只有特定IP地址或IP地址范圍的請(qǐng)求能夠訪問(wèn)敏感信息，以增加訪問(wèn)的限制。

5. 使用其他安全傳輸層：

   • 使用其他安全傳輸層，如VPN（Virtual Private Network）或?qū)Ｓ镁W(wǎng)絡(luò)連接，以確保數(shù)據(jù)傳輸?shù)陌踩浴?/li>

需要強(qiáng)調(diào)的是，這些方法仍然可能存在一些安全風(fēng)險(xiǎn)，因此在選擇和實(shí)施替代方法時(shí)，需要根據(jù)應(yīng)用程序的具體需求和安全性要求進(jìn)行仔細(xì)的評(píng)估和設(shè)計(jì)。最佳的安全實(shí)踐通常包括使用HTTPS、令牌認(rèn)證、OAuth等安全機(jī)制，以確保敏感信息在傳輸過(guò)程中得到保護(hù)。

websocket 鏈接在請(qǐng)求頭中是怎么標(biāo)識(shí)的？

WebSocket連接在HTTP請(qǐng)求頭中通過(guò)特定的頭部字段來(lái)標(biāo)識(shí)。在建立WebSocket連接時(shí)，客戶端會(huì)發(fā)送一個(gè)HTTP請(qǐng)求，其中包含一些特殊的頭部字段來(lái)指示要升級(jí)到WebSocket連接。以下是標(biāo)識(shí)WebSocket連接的HTTP請(qǐng)求頭部字段：

1. Upgrade：

   • 客戶端在HTTP請(qǐng)求頭中包含一個(gè)"Upgrade"字段，其值設(shè)置為"websocket"，表示客戶端希望升級(jí)到WebSocket連接。
   • 示例：Upgrade: websocket

2. Connection：

   • 客戶端還包含一個(gè)"Connection"字段，其值設(shè)置為"Upgrade"，表示客戶端希望升級(jí)連接。
   • 示例：Connection: Upgrade

3. Sec-WebSocket-Key：

   • 客戶端生成一個(gè)隨機(jī)的16字節(jié)的值，并將其轉(zhuǎn)換為Base64編碼后放在"Sec-WebSocket-Key"字段中，以確保服務(wù)器可以驗(yàn)證WebSocket握手請(qǐng)求的合法性。
   • 示例：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

4. Sec-WebSocket-Version：

   • 客戶端在"Sec-WebSocket-Version"字段中指定所使用的WebSocket協(xié)議的版本號(hào)。
   • 示例：Sec-WebSocket-Version: 13

5. 其他頭部字段：

   • 除了上述字段外，還可以包含其他自定義的頭部字段，以在建立WebSocket連接時(shí)傳遞額外的信息。

當(dāng)服務(wù)器收到包含上述標(biāo)識(shí)字段的HTTP請(qǐng)求后，如果支持WebSocket協(xié)議并接受WebSocket連接，它將響應(yīng)一個(gè)HTTP 101 Switching Protocols狀態(tài)碼，表示已成功升級(jí)到WebSocket連接。此后，客戶端和服務(wù)器之間的通信將通過(guò)WebSocket協(xié)議進(jìn)行，而不再是HTTP。

下面是一個(gè)WebSocket協(xié)議升級(jí)的示例HTTP請(qǐng)求頭：

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

請(qǐng)注意，WebSocket連接的建立過(guò)程需要遵循WebSocket協(xié)議的標(biāo)準(zhǔn)規(guī)范，包括特定的字段和狀態(tài)碼，以確保安全和正確的協(xié)議升級(jí)。一旦建立WebSocket連接，客戶端和服務(wù)器之間的數(shù)據(jù)傳輸將以全雙工的方式進(jìn)行，允許雙方實(shí)時(shí)地進(jìn)行雙向通信。