怎樣設(shè)計(jì)網(wǎng)站或網(wǎng)頁鄭州做網(wǎng)站哪家好
TCP通訊原理：三次握手，四次揮手
TCP（Transmission Control Protocol）通信中的"三次握手"和"四次揮手"是建立和終止TCP連接時的標(biāo)準(zhǔn)過程，用于確保數(shù)據(jù)的可靠傳輸和連接的正確關(guān)閉。
三次握手（Three-Way Handshake）：
-
第一步 - 客戶端發(fā)送請求：
- 客戶端發(fā)送一個SYN（同步）標(biāo)志位的TCP數(shù)據(jù)包到服務(wù)器，用來請求建立連接。
- 此時，客戶端進(jìn)入"SYN_SENT"狀態(tài)，等待服務(wù)器的響應(yīng)。
-
第二步 - 服務(wù)器確認(rèn)請求：
- 服務(wù)器收到客戶端的SYN數(shù)據(jù)包后，會發(fā)送一個包含SYN和ACK（確認(rèn)）標(biāo)志位的數(shù)據(jù)包作為響應(yīng)。
- 此時，服務(wù)器進(jìn)入"SYN_RCVD"狀態(tài)，表示它已經(jīng)同意建立連接。
-
第三步 - 客戶端確認(rèn)連接：
- 客戶端收到服務(wù)器的響應(yīng)后，發(fā)送一個帶有ACK標(biāo)志位的數(shù)據(jù)包給服務(wù)器。
- 此時，客戶端和服務(wù)器都進(jìn)入"ESTABLISHED"狀態(tài)，連接已建立，雙方可以開始進(jìn)行數(shù)據(jù)傳輸。
四次揮手（Four-Way Handshake）：
-
第一步 - 客戶端發(fā)起關(guān)閉：
- 客戶端發(fā)送一個帶有FIN（結(jié)束）標(biāo)志位的數(shù)據(jù)包給服務(wù)器，表示它要關(guān)閉連接，但仍然可以接收數(shù)據(jù)。
- 此時，客戶端進(jìn)入"FIN_WAIT_1"狀態(tài)，等待服務(wù)器的確認(rèn)。
-
第二步 - 服務(wù)器確認(rèn)關(guān)閉：
- 服務(wù)器收到客戶端的FIN數(shù)據(jù)包后，發(fā)送一個帶有ACK標(biāo)志位的數(shù)據(jù)包作為響應(yīng)，表示它接受了客戶端的關(guān)閉請求。
- 此時，服務(wù)器進(jìn)入"CLOSE_WAIT"狀態(tài)，客戶端進(jìn)入"FIN_WAIT_2"狀態(tài)。
-
第三步 - 服務(wù)器發(fā)起關(guān)閉：
- 服務(wù)器發(fā)送一個帶有FIN標(biāo)志位的數(shù)據(jù)包給客戶端，表示服務(wù)器也準(zhǔn)備關(guān)閉連接。
- 此時，服務(wù)器進(jìn)入"LAST_ACK"狀態(tài)。
-
第四步 - 客戶端確認(rèn)關(guān)閉：
- 客戶端收到服務(wù)器的FIN數(shù)據(jù)包后，發(fā)送一個帶有ACK標(biāo)志位的數(shù)據(jù)包作為確認(rèn)。
- 此時，客戶端進(jìn)入"TIME_WAIT"狀態(tài)，等待一段時間后才完全關(guān)閉連接。
- 服務(wù)器收到客戶端的確認(rèn)后，進(jìn)入"CLOSED"狀態(tài)，連接完全關(guān)閉。
這個四步揮手的過程確保了雙方都有機(jī)會完成未完成的數(shù)據(jù)傳輸，以及關(guān)閉連接，同時避免了數(shù)據(jù)的丟失和不完整的傳輸。揮手完成后，雙方的連接被完全關(guān)閉。
服務(wù)器設(shè)置"CLOSE_WAIT"狀態(tài)的目的是啥？
服務(wù)器在設(shè)置"CLOSE_WAIT"狀態(tài)的目的是等待客戶端確認(rèn)關(guān)閉連接。在TCP連接的四次揮手過程中，服務(wù)器在發(fā)送關(guān)閉請求后進(jìn)入"CLOSE_WAIT"狀態(tài)，這表示服務(wù)器已經(jīng)發(fā)送了一個帶有FIN標(biāo)志位的數(shù)據(jù)包，告訴客戶端它要關(guān)閉連接。服務(wù)器進(jìn)入這個狀態(tài)是為了等待客戶端的確認(rèn)，以確保連接被雙方正確地關(guān)閉。
"CLOSE_WAIT"狀態(tài)是暫時的，通常在服務(wù)器端只會停留很短的時間，直到收到客戶端的確認(rèn)，然后服務(wù)器會進(jìn)入"CLOSED"狀態(tài)，連接被完全關(guān)閉。這個等待確認(rèn)的過程允許服務(wù)器確?？蛻舳艘呀?jīng)成功收到了服務(wù)器的關(guān)閉請求，以避免數(shù)據(jù)的丟失或不完整的傳輸。
總之，服務(wù)器設(shè)置"CLOSE_WAIT"狀態(tài)是為了在關(guān)閉連接時等待客戶端的確認(rèn)，以確保連接被正確地關(guān)閉，從而維護(hù)數(shù)據(jù)的完整性和可靠性。這是TCP連接管理中的一個重要步驟，確保數(shù)據(jù)可靠傳輸和連接的正常終止。
UTF-8是怎么進(jìn)行編碼的？
UTF-8（Unicode Transformation Format - 8-bit）是一種可變長度字符編碼方式，用于表示Unicode字符集中的字符。UTF-8編碼的規(guī)則相對簡單，它根據(jù)字符的Unicode碼點(diǎn)值的范圍來確定使用多少字節(jié)來表示一個字符。以下是UTF-8的編碼規(guī)則：
-
ASCII字符（U+0000到U+007F）：
- ASCII字符使用單個字節(jié)（8位）進(jìn)行編碼，最高位（最左邊的位）為0。
- 例如，字母A的Unicode碼點(diǎn)是U+0041，它在UTF-8中編碼為01000001。
-
通用多字節(jié)編碼：
- 大多數(shù)Unicode字符使用多字節(jié)進(jìn)行編碼。
- 每個多字節(jié)序列以一個字節(jié)的起始字節(jié)開始，這個字節(jié)中的高位位表示此序列的長度。
- 例如，兩字節(jié)序列以110xxxxx 10xxxxxx開始，三字節(jié)序列以1110xxxx 10xxxxxx 10xxxxxx開始，四字節(jié)序列以11110xxx 10xxxxxx 10xxxxxx 10xxxxxx開始。
- 剩余的字節(jié)都以10xxxxxx開始。
-
字符值：
- 多字節(jié)序列中的x位用于存儲字符的值，組成了Unicode碼點(diǎn)。
- 字符值的范圍根據(jù)字節(jié)序列的長度不同而變化，不同長度的字節(jié)序列可以表示不同范圍的Unicode字符。
下面是一些UTF-8編碼的示例：
- 字母A（U+0041）編碼為01000001。
- 歐元符號€（U+20AC）編碼為11100010 10000010 10101100。
- 中文字符“你”（U+4F60）編碼為11100100 10111101 10010000。
- 表情符號😀（U+1F600）編碼為11110000 10011111 10011000 10000000。
UTF-8編碼的靈活性使其成為一種廣泛使用的字符編碼方式，因?yàn)樗梢员硎舅蠻nicode字符，包括ASCII字符，同時保持了向后兼容性。這意味著如果一個UTF-8文本只包含ASCII字符，那么它與ASCII編碼是一致的。
http是怎么傳遞參數(shù)的
HTTP請求可以傳遞參數(shù)以向服務(wù)器發(fā)送數(shù)據(jù)或請求特定資源。HTTP請求中傳遞參數(shù)的主要方法包括：
-
查詢字符串參數(shù)：
- 在URL中使用查詢字符串傳遞參數(shù)，通常是在URL的問號后面，多個參數(shù)之間使用"&"符號分隔。
- 例如：
http://example.com/resource?param1=value1¶m2=value2 - 在GET請求中，參數(shù)通常以明文形式附加在URL上，因此對于敏感信息來說不安全。
- 用于傳遞少量參數(shù)，如搜索關(guān)鍵字或分頁信息。
-
請求頭參數(shù)：
- 可以在HTTP請求的頭部（Header）中添加自定義參數(shù)，這些參數(shù)以鍵值對的形式出現(xiàn)。
- 例如，可以在請求頭中添加Authorization頭以進(jìn)行身份驗(yàn)證，或者在Accept頭中指定響應(yīng)的內(nèi)容類型。
- 用于傳遞與請求相關(guān)的元信息和控制參數(shù)。
-
請求體參數(shù)：
- 在POST、PUT等HTTP請求方法中，可以將參數(shù)放置在請求體（Request Body）中。
- 參數(shù)通常以表單數(shù)據(jù)、JSON、XML等格式進(jìn)行編碼，并在請求頭中指定Content-Type來表示數(shù)據(jù)類型。
- 用于傳遞大量參數(shù)或包含復(fù)雜結(jié)構(gòu)的參數(shù)。
-
URL路徑參數(shù)：
- 有時，參數(shù)可以作為URL路徑的一部分來傳遞。
- 例如：
http://example.com/resource/value1/value2，其中"value1"和"value2"可以被服務(wù)器解析為參數(shù)。 - 用于RESTful風(fēng)格的API設(shè)計(jì)中，用于傳遞資源標(biāo)識符或參數(shù)。
-
Cookie參數(shù)：
- 可以使用Cookie來在HTTP請求之間保持狀態(tài)信息。
- 服務(wù)器可以設(shè)置Cookie并在客戶端之間傳遞，客戶端會將Cookie自動包含在后續(xù)的HTTP請求中。
- 用于跟蹤用戶會話和存儲客戶端狀態(tài)信息。
-
會話參數(shù)：
- 通過使用會話（Session）來存儲和管理參數(shù)，通常在服務(wù)器端。
- 客戶端在登錄后會獲得一個會話標(biāo)識符（Session ID），該標(biāo)識符用于關(guān)聯(lián)客戶端與服務(wù)器端的會話數(shù)據(jù)。
- 用于保持用戶狀態(tài)和在多個請求之間共享數(shù)據(jù)。
HTTP請求的參數(shù)傳遞方式取決于應(yīng)用程序的需求和設(shè)計(jì)。不同的HTTP框架和庫可能提供不同的方式來處理參數(shù)。在處理HTTP請求時，服務(wù)器通常會解析請求中的參數(shù)，并根據(jù)參數(shù)的內(nèi)容執(zhí)行相應(yīng)的操作或返回響應(yīng)。
用戶名和密碼等參數(shù)是怎么傳遞，為什么這么傳遞？
用戶名和密碼等敏感信息在網(wǎng)絡(luò)通信中需要以安全的方式傳遞，以保護(hù)用戶的隱私和安全。通常，這些信息是在身份驗(yàn)證過程中傳遞的，以下是一些常見的傳遞方法以及為什么要這樣傳遞的原因：
-
HTTP基本認(rèn)證：
- 用戶名和密碼可以通過HTTP基本認(rèn)證傳遞，這是HTTP協(xié)議的一種內(nèi)置身份驗(yàn)證機(jī)制。
- 客戶端將用戶名和密碼編碼為Base64字符串，并將其添加到HTTP請求頭的"Authorization"字段中。
- 這種方法簡單易用，但不是最安全的方式，因?yàn)锽ase64編碼不是加密，容易受到竊聽攻擊。
- 常用于簡單的身份驗(yàn)證，但不建議在非安全環(huán)境中使用。
-
HTTPS：
- 使用HTTPS（HTTP Secure）協(xié)議來傳遞用戶名和密碼以及其他敏感信息，以加密數(shù)據(jù)傳輸。
- HTTPS使用TLS/SSL加密來保護(hù)通信，確保傳輸?shù)臄?shù)據(jù)在傳輸過程中是安全的。
- 這是一種最安全的傳遞敏感信息的方式，常用于登錄和傳輸敏感數(shù)據(jù)，因?yàn)樗峁┝硕说蕉说募用芎桶踩浴?/li>
-
表單認(rèn)證：
- 用戶名和密碼可以通過HTML表單輸入，并通過POST請求將它們發(fā)送到服務(wù)器。
- 服務(wù)器接收到POST請求后，會驗(yàn)證用戶提供的用戶名和密碼是否正確。
- 這通常用于Web應(yīng)用程序的登錄頁面，用戶可以安全地輸入其憑據(jù)。
-
令牌認(rèn)證：
- 用戶信息可以通過令牌（Token）進(jìn)行傳遞，用戶在登錄后會獲得一個令牌，然后將令牌包含在每個后續(xù)請求的頭部或請求參數(shù)中。
- 服務(wù)器使用令牌來驗(yàn)證用戶的身份，而不需要在每個請求中傳遞明文的用戶名和密碼。
- 令牌可以具有一定的生命周期，并且可以存儲在安全的方式中，減少了暴露密碼的風(fēng)險。
-
OAuth認(rèn)證：
- OAuth是一種開放標(biāo)準(zhǔn)，允許用戶授權(quán)第三方應(yīng)用程序訪問他們的資源，而不需要將密碼傳遞給第三方應(yīng)用。
- 用戶在OAuth中進(jìn)行授權(quán)，然后服務(wù)器生成訪問令牌，第三方應(yīng)用程序使用該令牌來訪問受保護(hù)的資源。
- OAuth提供了一種安全的方式來授權(quán)和傳遞用戶信息，而無需直接傳遞用戶名和密碼。
這些方法的選擇取決于應(yīng)用程序的需求和安全性要求。在設(shè)計(jì)和實(shí)施身份驗(yàn)證和數(shù)據(jù)傳輸方案時，必須考慮安全性，并選擇適當(dāng)?shù)姆椒▉肀Ｗo(hù)用戶信息。HTTPS是一種常用的方式，因?yàn)樗峁┝硕说蕉说臄?shù)據(jù)加密和完整性保護(hù)。同時，令牌認(rèn)證和OAuth等方法也提供了安全且便于管理的方式來處理用戶憑據(jù)和授權(quán)。
如果前端禁用token或者cookies，這樣的敏感信息怎么傳遞
如果前端禁用了使用token或cookies等傳遞敏感信息的方式，仍然需要傳遞敏感信息，可以考慮以下替代方法：
-
在請求頭中使用自定義頭部：
- 可以在HTTP請求頭中添加自定義的頭部字段，將敏感信息放入這些頭部字段中。但請注意，這仍然不是最安全的方式，因?yàn)轭^部字段仍然可以被竊聽或中間人攻擊所威脅。
-
請求參數(shù)加密：
- 將敏感信息加密后，作為請求的參數(shù)進(jìn)行傳遞。前端和后端必須使用相同的加密算法和密鑰來加密和解密數(shù)據(jù)。
- 這可以提供一定程度的保護(hù)，但仍然可能受到中間人攻擊的威脅。
-
使用單次令牌（One-Time Token）：
- 生成一次性令牌，令牌只能用一次，并且在使用后立即失效。這樣可以降低令牌泄露的風(fēng)險。
- 服務(wù)器和客戶端之間必須共享一種機(jī)制來生成和驗(yàn)證這些一次性令牌。
-
IP地址限制：
- 對于一些情況下，可以限制只有特定IP地址或IP地址范圍的請求能夠訪問敏感信息，以增加訪問的限制。
-
使用其他安全傳輸層：
- 使用其他安全傳輸層，如VPN（Virtual Private Network）或?qū)Ｓ镁W(wǎng)絡(luò)連接，以確保數(shù)據(jù)傳輸?shù)陌踩浴?/li>
需要強(qiáng)調(diào)的是，這些方法仍然可能存在一些安全風(fēng)險，因此在選擇和實(shí)施替代方法時，需要根據(jù)應(yīng)用程序的具體需求和安全性要求進(jìn)行仔細(xì)的評估和設(shè)計(jì)。最佳的安全實(shí)踐通常包括使用HTTPS、令牌認(rèn)證、OAuth等安全機(jī)制，以確保敏感信息在傳輸過程中得到保護(hù)。
websocket 鏈接在請求頭中是怎么標(biāo)識的？
WebSocket連接在HTTP請求頭中通過特定的頭部字段來標(biāo)識。在建立WebSocket連接時，客戶端會發(fā)送一個HTTP請求，其中包含一些特殊的頭部字段來指示要升級到WebSocket連接。以下是標(biāo)識WebSocket連接的HTTP請求頭部字段：
-
Upgrade：
- 客戶端在HTTP請求頭中包含一個"Upgrade"字段，其值設(shè)置為"websocket"，表示客戶端希望升級到WebSocket連接。
- 示例：
Upgrade: websocket
-
Connection：
- 客戶端還包含一個"Connection"字段，其值設(shè)置為"Upgrade"，表示客戶端希望升級連接。
- 示例：
Connection: Upgrade
-
Sec-WebSocket-Key：
- 客戶端生成一個隨機(jī)的16字節(jié)的值，并將其轉(zhuǎn)換為Base64編碼后放在"Sec-WebSocket-Key"字段中，以確保服務(wù)器可以驗(yàn)證WebSocket握手請求的合法性。
- 示例：
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
-
Sec-WebSocket-Version：
- 客戶端在"Sec-WebSocket-Version"字段中指定所使用的WebSocket協(xié)議的版本號。
- 示例：
Sec-WebSocket-Version: 13
-
其他頭部字段：
- 除了上述字段外，還可以包含其他自定義的頭部字段，以在建立WebSocket連接時傳遞額外的信息。
當(dāng)服務(wù)器收到包含上述標(biāo)識字段的HTTP請求后，如果支持WebSocket協(xié)議并接受WebSocket連接，它將響應(yīng)一個HTTP 101 Switching Protocols狀態(tài)碼，表示已成功升級到WebSocket連接。此后，客戶端和服務(wù)器之間的通信將通過WebSocket協(xié)議進(jìn)行，而不再是HTTP。
下面是一個WebSocket協(xié)議升級的示例HTTP請求頭：
GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
請注意，WebSocket連接的建立過程需要遵循WebSocket協(xié)議的標(biāo)準(zhǔn)規(guī)范，包括特定的字段和狀態(tài)碼，以確保安全和正確的協(xié)議升級。一旦建立WebSocket連接，客戶端和服務(wù)器之間的數(shù)據(jù)傳輸將以全雙工的方式進(jìn)行，允許雙方實(shí)時地進(jìn)行雙向通信。