HTTP2和1.1的區(qū)別

HTTP 2.0 和 HTTP 1.1 相比有哪些優(yōu)勢(shì)呢？

HTTP1.1的隊(duì)頭阻塞問(wèn)題

服務(wù)器必須按照請(qǐng)求接收的順序來(lái)響應(yīng)，為什么

是因?yàn)閭鹘y(tǒng)的1.1中沒(méi)有特定字段來(lái)區(qū)分一個(gè)請(qǐng)求屬于哪個(gè)，只能按照請(qǐng)求的物理順序返回，

HTTP2解決隊(duì)頭阻塞問(wèn)題的思路是，額外定義一個(gè)幀結(jié)構(gòu)字段，使得發(fā)送方收到響應(yīng)后能夠根據(jù)流id進(jìn)行重排序，比如同時(shí)請(qǐng)求5張圖片，流id分別為1-5，那么響應(yīng)時(shí)不必按照物理的請(qǐng)求順序響應(yīng)，對(duì)嗎？

正如你所說(shuō)，HTTP/2通過(guò)引入“流”的概念來(lái)解決隊(duì)頭阻塞問(wèn)題。每個(gè)流都有一個(gè)唯一的標(biāo)識(shí)符（流ID），這使得多個(gè)請(qǐng)求和響應(yīng)可以在同一個(gè)TCP連接上并行進(jìn)行，而不會(huì)互相干擾。這樣，如果一個(gè)流的響應(yīng)被延遲，它不會(huì)阻礙其他流的處理。

確切地說(shuō)，HTTP/2中的“幀”結(jié)構(gòu)允許多種類(lèi)型的信息在一個(gè)TCP連接上進(jìn)行交換。其中的“流ID”字段標(biāo)識(shí)了幀屬于哪一個(gè)流。當(dāng)客戶(hù)端收到響應(yīng)時(shí)，它可以根據(jù)流ID對(duì)響應(yīng)進(jìn)行排序或處理，而不是依賴(lài)物理的發(fā)送順序。這使得服務(wù)器可以在準(zhǔn)備好響應(yīng)時(shí)立即發(fā)送它，而不需要等待其他請(qǐng)求的響應(yīng)。

總之，HTTP/2的設(shè)計(jì)允許更高的并行性和效率，避免了HTTP/1.1中的隊(duì)頭阻塞問(wèn)題。

HTTP2的這種解決隊(duì)頭阻塞問(wèn)題的思路在其他的地方有應(yīng)用嘛（實(shí)際上是一種多路復(fù)用機(jī)制）

HTTP/2 的解決隊(duì)頭阻塞問(wèn)題的思路基于多路復(fù)用和幀的概念，確實(shí)為其他技術(shù)領(lǐng)域提供了啟示。其背后的基本原理是允許多個(gè)獨(dú)立的交互在同一個(gè)連接上并行進(jìn)行，而每個(gè)交互都有其獨(dú)特的標(biāo)識(shí)符，使其在被發(fā)送和接收時(shí)能夠被正確地識(shí)別和處理。

這種思路在以下領(lǐng)域也有應(yīng)用：

1. 計(jì)算機(jī)網(wǎng)絡(luò)的其他協(xié)議：例如在某些現(xiàn)代傳輸層協(xié)議如QUIC中，也使用了類(lèi)似于流的概念，允許在單一的連接上并行處理多個(gè)獨(dú)立的數(shù)據(jù)流。

2. 數(shù)據(jù)庫(kù)管理：在處理多個(gè)并發(fā)事務(wù)時(shí)，一些數(shù)據(jù)庫(kù)使用標(biāo)識(shí)符來(lái)區(qū)分和正確地處理每個(gè)事務(wù)，確保每個(gè)事務(wù)的獨(dú)立性和完整性。

3. 計(jì)算機(jī)操作系統(tǒng)：在操作系統(tǒng)的多任務(wù)處理中，每個(gè)任務(wù)或進(jìn)程都有其獨(dú)特的標(biāo)識(shí)符，允許它們?cè)谝粋€(gè)系統(tǒng)中并行運(yùn)行，而操作系統(tǒng)能夠正確地管理和調(diào)度這些任務(wù)。

4. 消息隊(duì)列和流處理：在處理大量并發(fā)消息時(shí)，像Kafka這樣的消息隊(duì)列系統(tǒng)使用分區(qū)或其他標(biāo)識(shí)符來(lái)并行處理消息，確保消息的正確和高效處理。

5. 網(wǎng)格計(jì)算和并行計(jì)算：在處理分布式任務(wù)時(shí)，每個(gè)任務(wù)都可能有其獨(dú)特的標(biāo)識(shí)符，允許它們?cè)诙鄠€(gè)節(jié)點(diǎn)上并行運(yùn)行，而系統(tǒng)能夠正確地收集和組合結(jié)果。

這種將大型任務(wù)或請(qǐng)求分解為可獨(dú)立處理的小塊，并為每塊分配唯一標(biāo)識(shí)符的思路，在計(jì)算機(jī)科學(xué)和工程的許多領(lǐng)域中都有應(yīng)用。

阿里面試時(shí)遇到多路復(fù)用機(jī)制場(chǎng)景題(這里的IO多路復(fù)用類(lèi)似于HTTP2.0中加入流id的字段，而面試官提到的方案是在資源足夠充足的時(shí)候的一種解決方案，類(lèi)似于HTTP1.1建立多個(gè)TCP連接的解決方案)

背景：架構(gòu)實(shí)例反向同步到架構(gòu)定義表，涉及到6張表的同步，后續(xù)表還有可能增多

## 2.6 同步過(guò)程你是如何保證數(shù)據(jù)的一致性的

答：我這個(gè)同步的過(guò)程是六張實(shí)例表同步到對(duì)應(yīng)的六張定義表中（其實(shí)它們都在一張表，只不過(guò)存在架構(gòu)定義和架構(gòu)實(shí)例字段以表示區(qū)別）；我當(dāng)時(shí)沒(méi)有保證他的一致性，但是我現(xiàn)在想到的一個(gè)解決方案是將其加入到消息隊(duì)列中，消息隊(duì)列定期消費(fèi)，如果消息隊(duì)列本身是raft集群部署，本身可以保證一致性的。

### 2.6.1 你整個(gè)消息隊(duì)列的消息體是什么？包含哪些核心數(shù)據(jù)

答：比如說(shuō)序列號(hào)，消息體中應(yīng)該還包含我定義的那些模板，比如說(shuō)表名，表類(lèi)結(jié)構(gòu)，需要同步的字段啊

### 2.6.2 你們那邊應(yīng)該是有節(jié)點(diǎn)實(shí)例id吧，如果一個(gè)節(jié)點(diǎn)多次發(fā)生了變更，你投放到消息隊(duì)列，實(shí)際消費(fèi)的時(shí)候，會(huì)不會(huì)出現(xiàn)亂序的問(wèn)題？

答：有可能啊，那就開(kāi)六個(gè)隊(duì)列吧，每一個(gè)隊(duì)列單線(xiàn)程消費(fèi)

### 2.6.3 從A同步到B，比如是從淘寶的買(mǎi)家數(shù)據(jù)到賣(mài)家的同步，是不是不能用你的單隊(duì)列單線(xiàn)程的模式去走？因?yàn)檫@樣會(huì)限制消費(fèi)速率，遇到這種場(chǎng)景，如何去設(shè)計(jì)他呢？避免亂序。

答：可以借鑒tcp的序列號(hào)機(jī)制，給每一個(gè)隊(duì)列都加上兩個(gè)字段，一個(gè)是表名，一個(gè)是序列號(hào)，不同表名下的序列號(hào)空間隔離，這樣接收端收到消息后可以依據(jù)這個(gè)序列號(hào)空間的連續(xù)性進(jìn)行重排序。

### 2.6.4 你這里有一個(gè)問(wèn)題，如果發(fā)送端節(jié)點(diǎn)實(shí)例變化頻繁，發(fā)送和接收的地方是不知道的，所以你這個(gè)方案是不太行的

針對(duì)感知變更號(hào)的優(yōu)化方案：

答：我在消息體上再加一個(gè)字段，表示變更的版本，這樣接收端收到發(fā)送端的消息時(shí)，會(huì)比較發(fā)送端發(fā)送的版本和自己期望的版本是否一致，一致則加入到那個(gè)版本的緩沖區(qū)中，不一致則放入到其他版本的緩沖區(qū)中，延遲到接收到期望的變更號(hào)

面試官的方案（他說(shuō)我的方案是一種思路，但是比較復(fù)雜）：\
可以采用多節(jié)點(diǎn)方案，比如針對(duì)同一個(gè)節(jié)點(diǎn)的版本的變更號(hào)的消息統(tǒng)一經(jīng)由一個(gè)消息隊(duì)列節(jié)點(diǎn)發(fā)送，通過(guò)節(jié)點(diǎn)隔離實(shí)現(xiàn)變更號(hào)隔離。

我：你這種方案更我前面說(shuō)的按照表拆分隊(duì)列有什么不同呢？

面試官：你的這種方式拆分的節(jié)點(diǎn)數(shù)和表的數(shù)量相同，但是我說(shuō)的這種相當(dāng)于按照"節(jié)點(diǎn)+變更號(hào)"的方式拆分節(jié)點(diǎn)，每一個(gè)消息隊(duì)列節(jié)點(diǎn)負(fù)責(zé)某一個(gè)節(jié)點(diǎn)實(shí)例id（這個(gè)實(shí)例id是邏輯id，用于解耦合）的某一個(gè)版本，拆分的粒度更細(xì)，整個(gè)的吞吐量會(huì)大很多，比如說(shuō)一個(gè)同步六張表，每張表有10個(gè)變更號(hào)，按照你的方案最多拆分成6個(gè)隊(duì)列，但是按照我的方案可以拆分成60個(gè)隊(duì)列。

HTTP2的Multiplexing

HTTP2 Multiplexing是什么，有什么作用，機(jī)制是什么

在HTTP/1.1中，每個(gè)HTTP請(qǐng)求需要一個(gè)獨(dú)立的TCP連接，這使得同時(shí)發(fā)送多個(gè)請(qǐng)求需要開(kāi)啟多個(gè)TCP連接。但在HTTP/2中，引入了多路復(fù)用（Multiplexing）技術(shù)，允許在單個(gè)TCP連接上同時(shí)發(fā)送多個(gè)HTTP請(qǐng)求和接收響應(yīng)。

HTTP中的流水線(xiàn)和Multiplexing

流水線(xiàn)和Multiplexing是HTTP協(xié)議中兩種不同的技術(shù)，它們都旨在提高網(wǎng)絡(luò)傳輸?shù)男省?/p>

流水線(xiàn)（Pipelining）：在HTTP/1.1中引入，允許在一個(gè)持久連接中，客戶(hù)端可以連續(xù)發(fā)送多個(gè)請(qǐng)求，而無(wú)需等待每個(gè)響應(yīng)。但是，HTTP/1.1規(guī)定響應(yīng)必須按照請(qǐng)求的順序返回，這就引發(fā)了“隊(duì)頭阻塞”問(wèn)題，即如果一個(gè)請(qǐng)求的處理需要很長(zhǎng)時(shí)間，那么后續(xù)的響應(yīng)也會(huì)被阻塞。

Multiplexing（多路復(fù)用）：在HTTP/2中引入，允許在一個(gè)持久連接中，客戶(hù)端和服務(wù)器可以同時(shí)處理多個(gè)請(qǐng)求和響應(yīng)。Multiplexing通過(guò)將每個(gè)請(qǐng)求和響應(yīng)分割為多個(gè)幀，這些幀可以在一個(gè)連接中混合發(fā)送，并在接收端進(jìn)行重新組裝。由于沒(méi)有了隊(duì)頭阻塞問(wèn)題，Multiplexing的效率更高。

HTTP/2 的多路復(fù)用（Multiplexing）機(jī)制通過(guò)引入“流”（Stream）的概念來(lái)保證請(qǐng)求和響應(yīng)的順序性。

在 HTTP/2 中，每個(gè)請(qǐng)求響應(yīng)對(duì)都被視為一個(gè)獨(dú)立的流。每個(gè)流都有一個(gè)唯一的標(biāo)識(shí)符，稱(chēng)為“流 ID”（Stream ID）。流可以并行發(fā)送，因?yàn)槊總€(gè)幀都被標(biāo)記為屬于某個(gè)流，這通過(guò)幀的頭部中的流 ID 來(lái)實(shí)現(xiàn)。

以下是如何保證順序性的：

1. 幀的順序：盡管多個(gè)流的幀可以在一個(gè)連接上混合發(fā)送，但單個(gè)流內(nèi)的幀的順序是固定的。例如，流 A 的幀1、幀2、幀3 的發(fā)送順序不會(huì)被打亂。

2. 流 ID：每個(gè)流都有一個(gè)唯一的流 ID，這使得接收端可以根據(jù)幀的流 ID 將其正確地關(guān)聯(lián)到相應(yīng)的請(qǐng)求或響應(yīng)上。

3. 流控制：HTTP/2 還引入了流控制機(jī)制，允許接收端控制其接收數(shù)據(jù)的速率，這進(jìn)一步確保了數(shù)據(jù)的有序接收和處理。

總之，多路復(fù)用允許多個(gè)請(qǐng)求和響應(yīng)在一個(gè)連接上并行發(fā)送，但每個(gè)流內(nèi)部的幀的順序是保持一致的。接收端根據(jù)幀的流 ID 和順序重新組裝每個(gè)流，從而確保請(qǐng)求和響應(yīng)的正確和順序處理。

為什么允許瀏覽器同服務(wù)端建立多個(gè)tcp連接？不是有流水線(xiàn)技術(shù)嗎？

雖然HTTP/1.1中的流水線(xiàn)技術(shù)和HTTP/2中的Multiplexing技術(shù)都可以在一個(gè)TCP連接中處理多個(gè)HTTP請(qǐng)求，但是由于隊(duì)頭阻塞問(wèn)題，流水線(xiàn)技術(shù)在實(shí)踐中使用得并不多。因此，HTTP/1.1的客戶(hù)端通常會(huì)為同一個(gè)服務(wù)器建立多個(gè)TCP連接，以并行處理多個(gè)HTTP請(qǐng)求。而在HTTP/2中，由于引入了Multiplexing技術(shù)，一個(gè)TCP連接就可以并行處理多個(gè)請(qǐng)求，因此一般不再需要建立多個(gè)連接。

如果允許建立多個(gè)tcp連接，接收端如何區(qū)分和按照規(guī)則重組同時(shí)接收的多個(gè)報(bào)文段？

TCP協(xié)議保證了每個(gè)連接的數(shù)據(jù)的有序性和完整性。在TCP協(xié)議中，每個(gè)數(shù)據(jù)段都有一個(gè)序號(hào)，接收端可以根據(jù)這個(gè)序號(hào)來(lái)重新組裝數(shù)據(jù)。所以，即使有多個(gè)TCP連接，接收端也可以正確地處理每個(gè)連接的數(shù)據(jù)。這是由于每個(gè)TCP連接都有獨(dú)立的序列號(hào)空間和確認(rèn)機(jī)制，因此，盡管這些連接可能同時(shí)存在，但它們是完全獨(dú)立的。

1 問(wèn)：每個(gè)TCP連接都有獨(dú)立的序列號(hào)空間和確認(rèn)機(jī)制來(lái)保證即使建立多個(gè)TCP連接，接收方也能正確重組，講講這種機(jī)制？

在TCP協(xié)議中，每個(gè)TCP連接都被定義為一個(gè)四元組：源IP地址、源端口、目的IP地址、目的端口。這個(gè)四元組唯一地標(biāo)識(shí)了一個(gè)TCP連接，這也是獨(dú)立序列號(hào)空間的保證，每個(gè)TCP連接都有自己獨(dú)立的序列號(hào)空間，這是由TCP協(xié)議保證的。序列號(hào)用于標(biāo)識(shí)在TCP連接中發(fā)送的數(shù)據(jù)字節(jié)的順序。

當(dāng)建立一個(gè)新的TCP連接時(shí)，發(fā)送方和接收方都會(huì)在握手過(guò)程中交換它們的初始序列號(hào)（ISN）。之后，發(fā)送方發(fā)送的每一個(gè)字節(jié)都會(huì)有一個(gè)序列號(hào)，這個(gè)序列號(hào)就是該字節(jié)的ISN加上它在發(fā)送數(shù)據(jù)流中的偏移量。接收方可以根據(jù)這個(gè)序列號(hào)來(lái)判斷接收的數(shù)據(jù)字節(jié)的順序，以及是否有數(shù)據(jù)丟失。

此外，TCP還使用確認(rèn)機(jī)制來(lái)確認(rèn)數(shù)據(jù)的接收。當(dāng)接收方接收到數(shù)據(jù)后，它會(huì)發(fā)送一個(gè)確認(rèn)（ACK），確認(rèn)號(hào)是接收方期望接收的下一個(gè)字節(jié)的序列號(hào)。如果發(fā)送方?jīng)]有收到接收方的確認(rèn)，它會(huì)重新發(fā)送數(shù)據(jù)。

所以，通過(guò)獨(dú)立的序列號(hào)空間和確認(rèn)機(jī)制，即使有多個(gè)TCP連接，接收方也能正確地接收和重組每個(gè)連接的數(shù)據(jù)。

2 建立多個(gè)TCP連接就會(huì)占用多個(gè)端口對(duì)嗎？

是的，每個(gè)新的TCP連接都需要一個(gè)新的端口。但需要注意的是，通常情況下，客戶(hù)端（也就是發(fā)起連接的一方）會(huì)使用一個(gè)新的端口，而服務(wù)器端（接收連接的一方）通常會(huì)使用一個(gè)固定的、已知的端口（例如HTTP的默認(rèn)端口是80，HTTPS的默認(rèn)端口是443）。操作系統(tǒng)會(huì)為客戶(hù)端自動(dòng)選擇一個(gè)未被使用的臨時(shí)端口。

3 這里的TCP四元組源IP地址、源端口、目的IP地址、目的端口唯一標(biāo)識(shí)了每一個(gè)TCP序列號(hào)的空間對(duì)不對(duì)？

對(duì)的，TCP四元組（源IP地址、源端口、目的IP地址、目的端口）確實(shí)唯一標(biāo)識(shí)了一個(gè)TCP連接。序列號(hào)是在每個(gè)TCP連接內(nèi)部使用的，用于保證連接中數(shù)據(jù)的正確順序和完整性。這意味著每個(gè)TCP連接都有自己獨(dú)立的序列號(hào)空間，不會(huì)和其他TCP連接沖突。這是因?yàn)槊總€(gè)TCP連接都是獨(dú)立的，其狀態(tài)（包括序列號(hào)）不會(huì)影響其他連接。

4 所以即使建立了多個(gè)TCP連接，目的端口依然不變，但是變化的是源端口，這樣也唯一標(biāo)識(shí)了命名空間？

是的，你的理解是正確的。即使多個(gè)TCP連接的目的端口（通常是服務(wù)器端的端口）相同，只要源端口（通常是客戶(hù)端的端口）或源IP地址有所不同，這就足以在網(wǎng)絡(luò)層面唯一標(biāo)識(shí)一個(gè)TCP連接。這就是為什么我們可以同時(shí)從同一臺(tái)設(shè)備（同一IP）打開(kāi)多個(gè)連接到同一服務(wù)器的同一端口（比如瀏覽器的多個(gè)標(biāo)簽頁(yè)連接到同一網(wǎng)站）。

5 在“所以即使建立了多個(gè)TCP連接，目的端口依然不變，但是變化的是源端口，這樣也唯一標(biāo)識(shí)了命名空間” 成立的條件下，目的端口都相同，所以就會(huì)發(fā)生復(fù)用和分用對(duì)吧？

對(duì)的，你的理解是準(zhǔn)確的。我們稱(chēng)之為復(fù)用和分用是因?yàn)榉?wù)器端的同一端口能夠服務(wù)于來(lái)自不同客戶(hù)端的多個(gè)連接（復(fù)用，服務(wù)即指發(fā)送或者響應(yīng)數(shù)據(jù)），同時(shí)也能夠根據(jù)每個(gè)連接的唯一標(biāo)識(shí)（源IP和源端口）將接收到的數(shù)據(jù)正確地傳送給對(duì)應(yīng)的連接/進(jìn)程（分用）。

復(fù)用和分用

復(fù)用(multiplexing)：指的是在網(wǎng)絡(luò)發(fā)送端，較高層協(xié)議可以通過(guò)同一個(gè)較低層的服務(wù)接口發(fā)送數(shù)據(jù)到不同的接收端。例如，你的計(jì)算機(jī)（作為客戶(hù)端）可以通過(guò)同一個(gè)網(wǎng)絡(luò)層接口（即同一個(gè)IP地址和端口）發(fā)送數(shù)據(jù)到服務(wù)器的不同端口，或者發(fā)送到不同的服務(wù)器。這個(gè)過(guò)程我們稱(chēng)之為復(fù)用。

分用(demultiplexing)：相應(yīng)的，在網(wǎng)絡(luò)接收端，較低層協(xié)議可以將接收到的數(shù)據(jù)按照一定的規(guī)則（比如目標(biāo)IP和端口）分發(fā)給較高層的不同服務(wù)接口。例如，服務(wù)器可以將收到的數(shù)據(jù)根據(jù)數(shù)據(jù)的源IP和源端口信息分發(fā)到不同的應(yīng)用程序。這個(gè)過(guò)程我們稱(chēng)之為分用。

下面這個(gè)是詳細(xì)地址: 《計(jì)算機(jī)網(wǎng)絡(luò)》知識(shí)總結(jié)-3.復(fù)用和分用

詳細(xì)講講HTTP/2的Multiplexing實(shí)現(xiàn)機(jī)制

HTTP/2的Multiplexing實(shí)現(xiàn)機(jī)制：在HTTP/2中，所有通信都在一個(gè)TCP連接上完成，這個(gè)連接可以承載任意數(shù)量的雙向數(shù)據(jù)流。每個(gè)數(shù)據(jù)流都有一個(gè)唯一的整數(shù)ID。數(shù)據(jù)流的請(qǐng)求和響應(yīng)都是由HTTP幀組成的，這些幀可以在TCP連接中交錯(cuò)發(fā)送，然后在接收端根據(jù)數(shù)據(jù)流ID重新組裝。

更具體地，HTTP/2定義了以下幾種類(lèi)型的幀：HEADERS和DATA用于請(qǐng)求和響應(yīng)的元數(shù)據(jù)和主體；SETTINGS, PING, and GOAWAY等用于連接管理；PUSH_PROMISE用于服務(wù)器推送等。

由于HTTP/2的幀可以在一個(gè)TCP連接中交錯(cuò)發(fā)送，因此可以解決HTTP/1.x的隊(duì)頭阻塞問(wèn)題，并使得連接的利用率更高。
因?yàn)閭鹘y(tǒng)的流水線(xiàn)技術(shù)需要前面的包完整且正確到達(dá)接收端，如果在發(fā)送端混合發(fā)送一個(gè)被切割的多個(gè)報(bào)文段并且和其他應(yīng)用的報(bào)文段無(wú)序組合在一起，然后發(fā)送給接收端，接收端收到第一個(gè)幀后還會(huì)再等待該幀的剩余部分到達(dá)，全部接收后才會(huì)解除阻塞。

這里涉及到的“幀”是指數(shù)據(jù)鏈路層的幀嗎？

HTTP/2中的"幀"是在應(yīng)用層的概念，它不是數(shù)據(jù)鏈路層的幀。在HTTP/2中，一個(gè)"幀"代表了HTTP/2通信中的最小單位，每一個(gè)幀包括幀頭和幀體，其中幀頭包含了該幀的類(lèi)型、標(biāo)志、長(zhǎng)度、以及數(shù)據(jù)流的標(biāo)識(shí)符。

這里的Multiplexing和TCP層的I/O多路復(fù)用是同一個(gè)概念嗎？

HTTP/2的Multiplexing和TCP層的I/O多路復(fù)用不是同一個(gè)概念。HTTP/2的Multiplexing是指在一個(gè)TCP連接中可以并行處理多個(gè)請(qǐng)求和響應(yīng)。而TCP層的I/O多路復(fù)用是指在底層操作系統(tǒng)中，可以使用單個(gè)線(xiàn)程來(lái)同時(shí)監(jiān)控和操作多個(gè)I/O流，如select、poll、epoll等。

這里的Multiplexing 和linux的epoll，select等多路復(fù)用機(jī)制有什么區(qū)別？

HTTP/2的Multiplexing和Linux的epoll、select等多路復(fù)用機(jī)制的主要區(qū)別在于他們工作的層次不同：

HTTP/2的Multiplexing工作在應(yīng)用層，它是HTTP/2協(xié)議的一部分，主要用于在一個(gè)TCP連接中并行處理多個(gè)HTTP請(qǐng)求和響應(yīng)。

epoll、select等工作在操作系統(tǒng)層，它們是操作系統(tǒng)提供的接口，主要用于在一個(gè)線(xiàn)程中同時(shí)處理多個(gè)網(wǎng)絡(luò)連接或其他I/O操作。

另外，epoll、select等多路復(fù)用機(jī)制是事件驅(qū)動(dòng)的，當(dāng)某個(gè)I/O流就緒（比如有數(shù)據(jù)可讀）時(shí)，會(huì)觸發(fā)相應(yīng)的事件。而HTTP/2的Multiplexing則是數(shù)據(jù)驅(qū)動(dòng)的，當(dāng)有新的幀發(fā)送到TCP連接時(shí)，會(huì)立即處理這個(gè)幀。

這里HTTP的Multiplexing和TCP層的I/O多路復(fù)用應(yīng)該有類(lèi)似的原理吧？

HTTP/2的Multiplexing和TCP層的I/O多路復(fù)用的核心概念都是通過(guò)單一的連接或資源處理多個(gè)數(shù)據(jù)流或操作，所以在這個(gè)意義上，它們的原理是類(lèi)似的。但是，如我在上一個(gè)回答中所述，它們工作的層次和具體的機(jī)制是不同的。

Multiplexing通過(guò)將每個(gè)請(qǐng)求和響應(yīng)分割為多個(gè)幀，這些幀可以在一個(gè)連接中混合發(fā)送，可以理解為A請(qǐng)求的數(shù)據(jù)幀和B請(qǐng)求的一些數(shù)據(jù)幀混合在一個(gè)TCP報(bào)文段中然后發(fā)送給接收方，接收方的應(yīng)用層根據(jù)分隔符，長(zhǎng)度，套接字等字段的方式進(jìn)行重組嗎？

大致上你的理解是正確的，但細(xì)節(jié)上需要一些調(diào)整。在HTTP/2中，一個(gè)請(qǐng)求或響應(yīng)的幀不會(huì)混合在一個(gè)TCP報(bào)文段中，而是作為獨(dú)立的幀在TCP連接中（HTTP請(qǐng)求）發(fā)送。每個(gè)幀的頭部都有一個(gè)數(shù)據(jù)流ID，這個(gè)ID用于指示這個(gè)幀屬于哪個(gè)請(qǐng)求或響應(yīng)。接收方的應(yīng)用層可以根據(jù)這個(gè)數(shù)據(jù)流ID來(lái)將接收到的幀重新組裝成完整的請(qǐng)求或響應(yīng)。因此，不是根據(jù)分隔符、長(zhǎng)度、套接字等字段來(lái)進(jìn)行重組，而是根據(jù)每個(gè)幀的數(shù)據(jù)流ID來(lái)進(jìn)行重組。

HTTPS和HTTP

HTTPS的交互流程

大概的交互流程：

是的，HTTPS基于HTTP協(xié)議，但是在HTTP和TCP之間增加了一個(gè)SSL/TLS的安全層。這個(gè)安全層為HTTP協(xié)議提供了數(shù)據(jù)加密服務(wù)，以保護(hù)數(shù)據(jù)在傳輸過(guò)程中不會(huì)被竊取或篡改，同時(shí)還可以進(jìn)行服務(wù)器身份驗(yàn)證，以保護(hù)用戶(hù)不會(huì)被引向假冒的服務(wù)器。

在實(shí)際使用中，HTTPS協(xié)議的工作流程大致可以分為兩步：

1. 握手階段：在客戶(hù)端和服務(wù)器之間建立SSL/TLS會(huì)話(huà)。在這個(gè)過(guò)程中，會(huì)進(jìn)行服務(wù)器身份驗(yàn)證（通過(guò)服務(wù)器的SSL/TLS證書(shū)），同時(shí)雙方還會(huì)協(xié)商出一套加密參數(shù)（例如使用哪種加密算法，密鑰是什么等）。這個(gè)會(huì)話(huà)一旦建立，就可以提供加密服務(wù)。

2. 數(shù)據(jù)傳輸階段：客戶(hù)端和服務(wù)器使用HTTP協(xié)議進(jìn)行數(shù)據(jù)的傳輸，但是在數(shù)據(jù)發(fā)送出去之前，會(huì)先用握手階段協(xié)商出的加密參數(shù)對(duì)數(shù)據(jù)進(jìn)行加密，接收方在接收到數(shù)據(jù)后再進(jìn)行解密。

所以，可以說(shuō)HTTPS是基于HTTP的，但是增加了數(shù)據(jù)加密和服務(wù)器身份驗(yàn)證的功能，從而提供了更高的安全性。

更詳細(xì)的交互可以參考下面：HTTPS的交互流程

針對(duì)SSL層的報(bào)文重放攻擊如何處理？

上述操作看似是實(shí)現(xiàn)了對(duì)安全通信的三個(gè)基本需求，但是其對(duì)整個(gè)會(huì)話(huà)過(guò)程中報(bào)文流的數(shù)據(jù)完整性的保障并未達(dá)到天衣無(wú)縫，雖然單個(gè)記錄的報(bào)文完整性可以由 MAC 保障，但是若是入侵者惡意調(diào)換兩個(gè) SSL 記錄的順序，或者故意多次重放同一個(gè) SSL 記錄多次，這樣會(huì)導(dǎo)致接收方收到的最終報(bào)文不正確，這也就是 “報(bào)文重放攻擊”。

報(bào)文重放攻擊時(shí)指針對(duì)ssl層的嘛？因?yàn)閠cp層次存在一個(gè)序號(hào)和確認(rèn)號(hào)字段，能過(guò)濾掉重復(fù)的tcp報(bào)文段，但是過(guò)濾不掉tcp序號(hào)不同，但是ssl證書(shū)重放的tcp報(bào)文段對(duì)不對(duì)

是的，你理解得正確。報(bào)文重放攻擊是對(duì)應(yīng)用層，特別是那些使用加密和認(rèn)證機(jī)制（例如SSL或TLS）的協(xié)議來(lái)說(shuō)的。由于SSL/TLS在TCP層之上，它們通常不會(huì)處理TCP層面的問(wèn)題，如數(shù)據(jù)重傳或者丟包等，這些問(wèn)題通常由TCP自身處理。因此，SSL/TLS需要處理一些TCP無(wú)法處理的安全問(wèn)題，其中包括報(bào)文重放攻擊。

在TCP層面，序列號(hào)和確認(rèn)號(hào)確實(shí)可以過(guò)濾掉重復(fù)的TCP段，也能在一定程度上防止數(shù)據(jù)重排。然而，這并不能防止在SSL/TLS層面上的報(bào)文重放攻擊。為什么呢？因?yàn)楣粽呖赡芙厝〔⒋鎯?chǔ)一個(gè)完整的SSL/TLS會(huì)話(huà)，然后在稍后的時(shí)間里，再重放這個(gè)會(huì)話(huà)。盡管這些報(bào)文在TCP層面看起來(lái)都是新的（因?yàn)樗鼈兙哂行碌腡CP序列號(hào)），但在SSL/TLS層面，它們其實(shí)是舊的報(bào)文，因此可能導(dǎo)致報(bào)文重放攻擊。
因此，SSL/TLS必須在協(xié)議層面實(shí)現(xiàn)一些防御措施來(lái)防止這種攻擊，例如通過(guò)在每個(gè)記錄中包含一個(gè)隱式的序列號(hào)，并在計(jì)算MAC時(shí)考慮這個(gè)序列號(hào)，以此來(lái)確保報(bào)文的順序和完整性。

業(yè)界通用的解決方案是什么樣的呢？

業(yè)界的通用做法是在協(xié)議設(shè)計(jì)時(shí)考慮這種攻擊場(chǎng)景，然后提供相應(yīng)的保護(hù)措施。例如，SSL/TLS協(xié)議通過(guò)在MAC計(jì)算中引入序列號(hào)（即使這個(gè)序列號(hào)在發(fā)送的報(bào)文中并不可見(jiàn)，也就是"隱式"的）來(lái)防止重放攻擊。除此之外，對(duì)于某些關(guān)鍵操作（例如支付操作），業(yè)務(wù)系統(tǒng)自己也會(huì)設(shè)計(jì)一些防重放機(jī)制，如在請(qǐng)求中包含一個(gè)時(shí)間戳，或者一個(gè)只能使用一次的隨機(jī)數(shù)（nonce）等。

講講使用序列號(hào)的方式來(lái)防重放攻擊的具體C/S交互流程

具體的C/S交互流程可能會(huì)因?yàn)榫唧w的協(xié)議和應(yīng)用場(chǎng)景而有所不同。但是對(duì)于SSL/TLS協(xié)議來(lái)說(shuō)，它在握手階段就會(huì)建立起雙方共享的密鑰，然后雙方就可以開(kāi)始安全地交換數(shù)據(jù)了。在這個(gè)過(guò)程中，為了防止重放攻擊，每一側(cè)的發(fā)送端會(huì)為它發(fā)送的每一條記錄維護(hù)一個(gè)序列號(hào)，并在計(jì)算MAC值時(shí)使用這個(gè)序列號(hào)。當(dāng)接收端收到一條記錄后，它會(huì)用同樣的方法來(lái)計(jì)算MAC值，如果計(jì)算出的MAC值與記錄中的MAC值匹配，那么這條記錄就會(huì)被接受。否則，如果MAC值不匹配，那么這條記錄就會(huì)被拒絕，因?yàn)樗赡苁且粋€(gè)重放的記錄。

重放會(huì)導(dǎo)致這個(gè)MAC不匹配，為什么

在SSL/TLS中，每次發(fā)送一條新的記錄，發(fā)送端都會(huì)自增序列號(hào)（這個(gè)特性很重要，其實(shí)跟TCP的重沖機(jī)制很類(lèi)似）。這個(gè)序列號(hào)被包含在了MAC（消息認(rèn)證碼）的計(jì)算過(guò)程中。MAC是通過(guò)將共享密鑰、序列號(hào)、消息內(nèi)容等數(shù)據(jù)進(jìn)行特定算法運(yùn)算得到的。這個(gè)MAC會(huì)被一同發(fā)送到接收端。

接收端在收到消息后，會(huì)使用同樣的密鑰和它自己維護(hù)的序列號(hào)進(jìn)行同樣的算法運(yùn)算，得到一個(gè)新的MAC。然后接收端會(huì)比較這個(gè)新計(jì)算出的MAC和接收到的MAC是否一致。

如果發(fā)送端的消息被惡意重放，那么重放的消息中的MAC是在原發(fā)送時(shí)計(jì)算的，當(dāng)時(shí)的序列號(hào)已經(jīng)過(guò)時(shí)。而接收端在收到重放消息后，會(huì)使用當(dāng)前的（已經(jīng)增加的）序列號(hào)進(jìn)行MAC計(jì)算，得到的MAC值和接收到的消息中的MAC是不一致的，因此接收端能夠識(shí)別出這是一個(gè)重放的消息，并拒絕接收。

也就是說(shuō)，序列號(hào)的自增機(jī)制和序列號(hào)在MAC計(jì)算中的使用，聯(lián)合起來(lái)防止了重放攻擊，這也是為什么重放會(huì)導(dǎo)致MAC不匹配的原因。

使用HTTPS通信，每次接收端收到一個(gè)請(qǐng)求都會(huì)對(duì)SSL的有效性進(jìn)行校驗(yàn)嘛，校驗(yàn)過(guò)程中使用到了MAC的驗(yàn)證機(jī)制嘛，然后可以順帶去重？

使用HTTPS通信時(shí)，接收端會(huì)對(duì)每個(gè)SSL/TLS記錄進(jìn)行完整性和真實(shí)性的校驗(yàn)，這個(gè)過(guò)程中會(huì)使用到MAC。在每個(gè)記錄接收和發(fā)送的過(guò)程中，都會(huì)維護(hù)一個(gè)序列號(hào)，這個(gè)序列號(hào)將被包含在MAC的計(jì)算過(guò)程中，所以通過(guò)驗(yàn)證MAC值的合法性，可以實(shí)現(xiàn)對(duì)重放攻擊的防護(hù)。

MAC的加密、解密流程說(shuō)一下，是不是使用對(duì)稱(chēng)密鑰和非對(duì)稱(chēng)密鑰的情況下，MAC的生成和校驗(yàn)流程不一樣

MAC (Message Authentication Code) 是使用共享密鑰和消息內(nèi)容計(jì)算得出的一個(gè)值。其主要作用是用來(lái)驗(yàn)證消息的完整性和真實(shí)性，它不涉及到數(shù)據(jù)加密的過(guò)程。在SSL/TLS通信中，MAC的使用并不受對(duì)稱(chēng)加密還是非對(duì)稱(chēng)加密的影響，生成和驗(yàn)證的流程是一樣的。

• 在生成MAC時(shí)，首先會(huì)有一個(gè)預(yù)共享的密鑰，這個(gè)密鑰在通信雙方之間是已知的。然后會(huì)將消息內(nèi)容（包括序列號(hào)、消息長(zhǎng)度等信息）和這個(gè)預(yù)共享密鑰一起輸入到一個(gè)特定的哈希函數(shù)（如HMAC-SHA256），輸出的哈希值就是MAC。

• 在驗(yàn)證MAC時(shí)，接收方將同樣的預(yù)共享密鑰和接收到的消息內(nèi)容輸入到同樣的哈希函數(shù)中，計(jì)算得到一個(gè)新的MAC。然后比較這個(gè)新計(jì)算得到的MAC和接收到的MAC是否一致。如果一致，說(shuō)明消息是由預(yù)期的發(fā)送方發(fā)送的，且在傳輸過(guò)程中沒(méi)有被修改。如果不一致，說(shuō)明消息可能被篡改，或者不是由預(yù)期的發(fā)送方發(fā)送的。

需要注意的是，MAC機(jī)制能夠保證消息的完整性和真實(shí)性，但它不能保證消息的機(jī)密性，也就是說(shuō)，消息本身并沒(méi)有被加密，如果要保證消息的機(jī)密性，還需要其他的加密技術(shù)，如對(duì)稱(chēng)加密或非對(duì)稱(chēng)加密。

在請(qǐng)求中包含一個(gè)時(shí)間戳，為什么能防止ssl防重放攻擊呢，是因?yàn)榭梢愿鶕?jù)時(shí)間戳過(guò)濾掉太久遠(yuǎn)的https請(qǐng)求嗎？

時(shí)間戳通常用來(lái)防止重放攻擊的一種方法。服務(wù)端在接收到請(qǐng)求后，會(huì)檢查請(qǐng)求中的時(shí)間戳是否在一個(gè)合理的時(shí)間窗口內(nèi)（例如，過(guò)去的5分鐘）。如果請(qǐng)求的時(shí)間戳過(guò)舊，服務(wù)器就可以認(rèn)為這是一個(gè)重放的請(qǐng)求并將其拒絕。這就需要客戶(hù)端和服務(wù)器的系統(tǒng)時(shí)間保持一致，或者至少要相差不大。

使用“一個(gè)只能使用一次的隨機(jī)數(shù)”策略，是不是得要求雙方存儲(chǔ)這個(gè)隨機(jī)數(shù)并且標(biāo)記是否過(guò)期？（其實(shí)對(duì)序列號(hào)而言也是這樣的，需要雙方維護(hù)一個(gè)最近一次使用成功的序列號(hào)列表）

對(duì)于“一個(gè)只能使用一次的隨機(jī)數(shù)”策略，通常需要服務(wù)端維護(hù)一份列表，記錄所有的隨機(jī)數(shù)以及他們是否被使用過(guò)。當(dāng)服務(wù)端接收到一個(gè)請(qǐng)求，它會(huì)檢查這個(gè)隨機(jī)數(shù)是否在列表中，如果不在，說(shuō)明這是一個(gè)新的請(qǐng)求，接受處理。如果在列表中且未使用，同樣接受處理，并標(biāo)記為已使用。如果在列表中且已被使用，那么拒絕這個(gè)請(qǐng)求。

MAC和JWT的關(guān)系，JWT會(huì)用到MAC嘛

MAC的全稱(chēng)Message Authentication Code，關(guān)于JWT可以參考這篇文章：想全面理解JWT？一文足矣
JWT (JSON Web Token) 和 MAC 的關(guān)系是，JWT 的簽名部分可以使用 HMAC（一種基于密鑰的哈希算法，是 MAC 的一種）生成。這種簽名可以保證 JWT 的完整性和驗(yàn)證消息的發(fā)出者。

網(wǎng)站上輸入一個(gè)URL涉及到的協(xié)議

過(guò)程

dns+arp+ip+tcp+http+ssl+websocket

一定得用到dns協(xié)議嗎

不一定，如果url是直接使用ip+端口號(hào)訪問(wèn)則無(wú)語(yǔ)dns，如果只有域名則需要dns協(xié)議解析到dns協(xié)議

mac和ip的不同之處

MAC地址：物理地址，用于網(wǎng)絡(luò)設(shè)備之間在同一局域網(wǎng)內(nèi)進(jìn)行通信。它是全球唯一的，由網(wǎng)絡(luò)設(shè)備制造商在生產(chǎn)時(shí)分配，通常硬編碼在網(wǎng)絡(luò)接口卡（NIC）硬件中。
IP地址：邏輯地址，用于在網(wǎng)絡(luò)上唯一標(biāo)識(shí)一個(gè)網(wǎng)絡(luò)接口。IP地址可能是靜態(tài)分配的，也可能是動(dòng)態(tài)從DHCP服務(wù)器上獲取的。同一個(gè)網(wǎng)絡(luò)設(shè)備在不同的網(wǎng)絡(luò)環(huán)境下可能會(huì)有不同的IP地址。

arp是一種什么報(bào)文呢，用什么實(shí)現(xiàn)的呢，知道嗎

ARP (Address Resolution Protocol) 是一種解析協(xié)議，可以將IP地址解析為對(duì)應(yīng)的MAC地址。當(dāng)一個(gè)設(shè)備需要向網(wǎng)絡(luò)上的另一個(gè)設(shè)備發(fā)送數(shù)據(jù)時(shí)，它會(huì)首先使用ARP協(xié)議找到目標(biāo)設(shè)備的MAC地址。ARP請(qǐng)求和回應(yīng)都是封裝在以太網(wǎng)幀中進(jìn)行發(fā)送的。

到了主機(jī)之后，我怎么知道你要處理的是https還是http

這通常是通過(guò)所使用的端口來(lái)區(qū)分的。默認(rèn)情況下，HTTP使用的是80端口，HTTPS使用的是443端口。當(dāng)然，這些端口是可以配置的，不一定非要使用默認(rèn)端口。（我答成了https的建立過(guò)程去了）
https不是建立在http之上嗎，http的端口是80，打算https的是443，建立起http后還可以更改端口號(hào)嗎？
HTTPS確實(shí)是建立在HTTP之上的，但它們使用的端口號(hào)是不同的。HTTP默認(rèn)的端口號(hào)是80，HTTPS默認(rèn)的端口號(hào)是443。這是由于HTTP和HTTPS實(shí)際上是兩種不同的協(xié)議，盡管它們的內(nèi)容和格式非常相似。當(dāng)我們說(shuō)將HTTP升級(jí)為HTTPS時(shí)，實(shí)際上是指在HTTP的基礎(chǔ)上增加了SSL/TLS的加密層，從而使得數(shù)據(jù)傳輸更加安全。至于能否在建立起HTTP連接后更改端口號(hào)，一般來(lái)說(shuō)，這是不可以的。端口號(hào)是在TCP連接建立時(shí)確定的，一旦TCP連接建立，端口號(hào)就不能改變。如果需要改變端口號(hào)，就必須斷開(kāi)現(xiàn)有的TCP連接，然后重新建立新的TCP連接。

建立ssl的第一個(gè)請(qǐng)求是由客戶(hù)端發(fā)起還是服務(wù)端發(fā)起的呢？

在SSL/TLS協(xié)議中，連接的建立一般是由客戶(hù)端發(fā)起的?？蛻?hù)端會(huì)首先發(fā)送一個(gè)“ClientHello”消息給服務(wù)器，表示它希望建立一個(gè)SSL/TLS連接。然后服務(wù)器會(huì)回應(yīng)一個(gè)“ServerHello”消息，以及服務(wù)器的證書(shū)和“ServerHelloDone”消息。之后的握手過(guò)程中還會(huì)涉及到密鑰交換和握手結(jié)束等步驟。
為什么是客戶(hù)端發(fā)起的呢，因?yàn)榭蛻?hù)端知道一開(kāi)始就得使用https協(xié)議嗎？
通常情況下，客戶(hù)端是知道是否需要使用HTTPS的。比如當(dāng)你在瀏覽器中輸入一個(gè)URL時(shí)，你會(huì)指定是使用http://還是https://。如果你指定的是https://，那么瀏覽器就知道需要使用HTTPS，從而在建立TCP連接后，立即開(kāi)始SSL/TLS握手過(guò)程。這個(gè)握手過(guò)程是由客戶(hù)端發(fā)起的，因?yàn)樵赟SL/TLS協(xié)議中，客戶(hù)端負(fù)責(zé)提供加密參數(shù)的選擇，并開(kāi)始握手過(guò)程。

數(shù)字證書(shū)里面有什么呢？

數(shù)字證書(shū)通常包含以下信息：
證書(shū)所有者的公開(kāi)密鑰
證書(shū)所有者的信息（包括名稱(chēng)、電子郵件地址、使用證書(shū)的權(quán)限等）
發(fā)行證書(shū)的證書(shū)頒發(fā)機(jī)構(gòu)（CA）的信息
證書(shū)的有效期
證書(shū)頒發(fā)機(jī)構(gòu)對(duì)上述信息的數(shù)字簽名

客戶(hù)端拿到證書(shū)怎么驗(yàn)證是否有效呢？

驗(yàn)證證書(shū)是否是上級(jí)CA 簽發(fā)的, 在驗(yàn)證證書(shū)的時(shí)候，瀏覽器會(huì)調(diào)用系統(tǒng)的證書(shū)管理器接口對(duì)證書(shū)路徑中的所有證書(shū)一級(jí)一級(jí)的進(jìn)行驗(yàn)證，只有路徑中所有的證書(shū)都是受信的，整個(gè)驗(yàn)證的結(jié)果才是受信。

客戶(hù)端在收到服務(wù)器的證書(shū)后，會(huì)做以下檢查來(lái)驗(yàn)證證書(shū)的有效性：

• 驗(yàn)證證書(shū)的簽名：客戶(hù)端會(huì)使用證書(shū)頒發(fā)機(jī)構(gòu)的公鑰來(lái)驗(yàn)證證書(shū)的簽名，以此來(lái)確認(rèn)證書(shū)的內(nèi)容沒(méi)有被篡改。
• 驗(yàn)證證書(shū)的有效期：證書(shū)都有一個(gè)有效期，如果當(dāng)前日期不在證書(shū)的有效期內(nèi)，那么證書(shū)就是無(wú)效的。
• 驗(yàn)證證書(shū)的頒發(fā)機(jī)構(gòu)：客戶(hù)端會(huì)檢查證書(shū)的頒發(fā)機(jī)構(gòu)是否是信任的，這通常是通過(guò)檢查操作系統(tǒng)或?yàn)g覽器中的信任的CA列表來(lái)完成的。

驗(yàn)證證書(shū)的簽名：客戶(hù)端會(huì)使用證書(shū)頒發(fā)機(jī)構(gòu)的公鑰來(lái)驗(yàn)證證書(shū)的簽名，以此來(lái)確認(rèn)證書(shū)的內(nèi)容沒(méi)有被篡改。你能看開(kāi)講講其中的流程嗎？
對(duì)于數(shù)字證書(shū)的簽名驗(yàn)證過(guò)程，以下是一種可能的簡(jiǎn)化描述：

• 客戶(hù)端收到服務(wù)器的數(shù)字證書(shū)后，首先從證書(shū)中獲取證書(shū)頒發(fā)機(jī)構(gòu)（CA）的公鑰。
• 客戶(hù)端使用CA的公鑰來(lái)解密證書(shū)中的數(shù)字簽名，得到一個(gè)摘要值。
• 客戶(hù)端同時(shí)也會(huì)對(duì)證書(shū)中的除了數(shù)字簽名之外的所有內(nèi)容進(jìn)行哈希計(jì)算，得到另一個(gè)摘要值。
• 客戶(hù)端將這兩個(gè)摘要值進(jìn)行比較，如果它們相同，那么就說(shuō)明證書(shū)的內(nèi)容沒(méi)有被篡改過(guò)，證書(shū)是有效的。如果它們不同，那么就說(shuō)明證書(shū)的內(nèi)容可能被篡改過(guò)，證書(shū)是無(wú)效的。

這個(gè)過(guò)程中的關(guān)鍵是，只有真正的CA才能生成一個(gè)能夠被它的公鑰正確解密的數(shù)字簽名，因此通過(guò)這種方式可以驗(yàn)證證書(shū)是否是由真正的CA頒發(fā)的，以及證書(shū)的內(nèi)容是否被篡改過(guò)。

udp有哪些優(yōu)點(diǎn)，分別對(duì)應(yīng)哪些場(chǎng)景呢？

UDP (User Datagram Protocol) 是一種無(wú)連接的協(xié)議，它的主要優(yōu)點(diǎn)包括：
簡(jiǎn)單：UDP不需要建立和斷開(kāi)連接，也不需要進(jìn)行復(fù)雜的錯(cuò)誤檢查和恢復(fù)，這使得UDP的實(shí)現(xiàn)相對(duì)簡(jiǎn)單。
高效：由于UDP不需要進(jìn)行連接管理和錯(cuò)誤恢復(fù)，因此它比TCP更加高效。
UDP常常用于那些不需要可靠傳輸，或者可以在應(yīng)用層處理錯(cuò)誤恢復(fù)的場(chǎng)景。例如：視頻流傳輸、實(shí)時(shí)游戲、VoIP等。

udp包能裝多少數(shù)據(jù)呢？

UDP數(shù)據(jù)報(bào)的大小是有限的。它的頭部占用8字節(jié)，包括源端口、目標(biāo)端口、長(zhǎng)度和校驗(yàn)和。UDP數(shù)據(jù)報(bào)的長(zhǎng)度字段是16位的，因此UDP數(shù)據(jù)報(bào)的最大大小是2^16 - 1 = 65535字節(jié)。減去8字節(jié)的頭部，以及IP頭部的最小大?。?0字節(jié)），剩下的最大有效載荷是65507字節(jié)。

轉(zhuǎn)發(fā)的時(shí)候真正的能一次性將支持的最大字節(jié)數(shù)的包轉(zhuǎn)出去嗎

實(shí)際上，雖然理論上UDP數(shù)據(jù)報(bào)的最大大小是65535字節(jié)，但在實(shí)際網(wǎng)絡(luò)中，往往受到各種限制。例如，IP協(xié)議規(guī)定，如果一個(gè)數(shù)據(jù)包的大小超過(guò)MTU（最大傳輸單元），那么這個(gè)數(shù)據(jù)包就需要被分片，然后在接收端再重新組裝。一般來(lái)說(shuō)，以太網(wǎng)的MTU是1500字節(jié)，因此在以太網(wǎng)環(huán)境下，如果一個(gè)UDP數(shù)據(jù)報(bào)的大小超過(guò)了這個(gè)值，就可能需要被分片。但是，UDP是一個(gè)無(wú)連接的協(xié)議，它沒(méi)有像TCP那樣的重傳機(jī)制，因此如果一個(gè)UDP數(shù)據(jù)報(bào)的某個(gè)分片丟失了，那么整個(gè)數(shù)據(jù)報(bào)都會(huì)被丟棄。所以，在實(shí)際應(yīng)用中，我們通常會(huì)盡量避免發(fā)送過(guò)大的UDP數(shù)據(jù)報(bào)，以避免分片和可能的數(shù)據(jù)丟失。

是的，為了避免UDP數(shù)據(jù)報(bào)過(guò)大導(dǎo)致的分片和可能的數(shù)據(jù)丟失，一般來(lái)說(shuō)，應(yīng)用層需要負(fù)責(zé)控制每個(gè)UDP數(shù)據(jù)報(bào)的大小(也可以負(fù)責(zé)它的可靠性)。這是因?yàn)閁DP本身是一個(gè)簡(jiǎn)單的、無(wú)連接的協(xié)議，它并沒(méi)有提供任何關(guān)于擁塞控制、流量控制或者錯(cuò)誤恢復(fù)的機(jī)制。因此，對(duì)于這些問(wèn)題，通常需要在應(yīng)用層進(jìn)行處理。

在一些需要實(shí)時(shí)數(shù)據(jù)傳輸?shù)膽?yīng)用中，比如視頻會(huì)議或者在線(xiàn)游戲，UDP是一個(gè)非常常用的協(xié)議。在這些應(yīng)用中，通常會(huì)通過(guò)一些策略來(lái)避免發(fā)送過(guò)大的UDP數(shù)據(jù)報(bào)。比如，可以通過(guò)調(diào)整視頻編碼的參數(shù)來(lái)控制每個(gè)視頻幀的大小，或者只在每個(gè)UDP數(shù)據(jù)報(bào)中包含一部分的視頻幀，以保證每個(gè)UDP數(shù)據(jù)報(bào)的大小不會(huì)超過(guò)MTU。當(dāng)然，這樣做可能會(huì)增加編程的復(fù)雜性，因?yàn)樾枰幚頂?shù)據(jù)的分片和組裝，但是通過(guò)這種方式可以避免網(wǎng)絡(luò)層的數(shù)據(jù)報(bào)文分片，從而提高數(shù)據(jù)傳輸?shù)男屎头€(wěn)定性。

http如何跨域？

HTTP如何跨域：在HTTP中，跨域是由于瀏覽器的同源策略限制。但有一些常用的方式可以進(jìn)行跨域：

• JSONP（JSON with Padding）：只能進(jìn)行GET請(qǐng)求。
• CORS（跨域資源共享）：服務(wù)器設(shè)置響應(yīng)頭Access-Control-Allow-Origin允許來(lái)源進(jìn)行訪問(wèn)，還可以通過(guò)Access-Control-Allow-Methods，Access-Control-Allow-Headers等設(shè)置允許的方法和頭部。
• 使用代理：例如設(shè)置Nginx進(jìn)行反向代理(此時(shí)代理服務(wù)器必須和客戶(hù)機(jī)同源，然后再由代理服務(wù)器設(shè)置完成跨域請(qǐng)求)，或者在Node.js中設(shè)置HTTP代理。
• 使用Websocket進(jìn)行通信。
• 使用服務(wù)器間通信或者存儲(chǔ)共享等方式繞過(guò)瀏覽器。

websocket

websocket和http的關(guān)系

1. WebSocket 和 HTTP 的關(guān)系：

   WebSocket 和 HTTP 都是通信協(xié)議，它們都基于 TCP/IP 協(xié)議。WebSocket 是獨(dú)立的、創(chuàng)建在 TCP 上的協(xié)議。HTTP 和 WebSocket 都可以使用 URL Scheme 來(lái)定義地址，HTTP 使用 http 或 https，而 WebSocket 使用 ws 或 wss（對(duì)應(yīng)于 HTTP 和 HTTPS 的加密連接）。

websocket是建立在http之上的嗎

2. WebSocket 是否建立在 HTTP 之上：

   WebSocket 不是建立在 HTTP 之上的，它是一個(gè)獨(dú)立的協(xié)議。但是 WebSocket 握手使用的是 HTTP 協(xié)議，這是為了兼容現(xiàn)有的 HTTP 基礎(chǔ)設(shè)施。

websocket和發(fā)布訂閱機(jī)制的關(guān)系

3. WebSocket 和發(fā)布訂閱模式的關(guān)系：

   WebSocket 是一種全雙工的通信協(xié)議，它允許服務(wù)器主動(dòng)向客戶(hù)端推送信息，客戶(hù)端也可以主動(dòng)向服務(wù)器發(fā)送信息，這樣就使得它成為實(shí)現(xiàn)發(fā)布-訂閱模式的一個(gè)很好的選擇。在使用 WebSocket 進(jìn)行實(shí)時(shí)通信時(shí)，常常會(huì)結(jié)合發(fā)布-訂閱模式來(lái)設(shè)計(jì)。

websocket的建立流程

4. WebSocket 的建立流程：

   • 客戶(hù)端通過(guò) HTTP 請(qǐng)求與 WebSocket 服務(wù)端協(xié)商建立連接。這個(gè)過(guò)程通常被稱(chēng)為“握手”（handshake）。如果服務(wù)器接受了連接請(qǐng)求，就會(huì)發(fā)回一個(gè)成功的 HTTP 響應(yīng)，這個(gè) HTTP 連接就升級(jí)成了 WebSocket 連接。
   • 握手過(guò)程中，客戶(hù)端會(huì)發(fā)送一個(gè) HTTP 請(qǐng)求到服務(wù)器，該請(qǐng)求包含一個(gè) Upgrade: websocket 的頭信息，表示嘗試升級(jí)連接到 WebSocket。
   • 服務(wù)器在接收到這個(gè)請(qǐng)求并同意連接后，會(huì)返回一個(gè)包含 Upgrade: websocket 頭的 HTTP 響應(yīng)，這樣，握手過(guò)程就完成了，客戶(hù)端和服務(wù)器之間的通信就切換到了 WebSocket 協(xié)議。

以上這些都是 WebSocket 協(xié)議的基本內(nèi)容。在實(shí)際應(yīng)用中，你可能還需要根據(jù)需求和環(huán)境進(jìn)行更深入的了解和研究。

TCP連接和釋放

關(guān)于tcp的連接和釋放，推薦看這篇文章理論經(jīng)典：TCP協(xié)議的3次握手與4次揮手過(guò)程詳解，有詳細(xì)的流程

為什么需要三次握手，兩次不行嗎？

試想如果是用兩次握手，則會(huì)出現(xiàn)下面這種情況：

如客戶(hù)端發(fā)出連接請(qǐng)求，但因連接請(qǐng)求報(bào)文丟失而未收到確認(rèn)，于是客戶(hù)端再重傳一次連接請(qǐng)求。后來(lái)收到了確認(rèn)，建立了連接。數(shù)據(jù)傳輸完畢后，就釋放了連接，客戶(hù)端共發(fā)出了兩個(gè)連接請(qǐng)求報(bào)文段，其中第一個(gè)丟失，第二個(gè)到達(dá)了服務(wù)端，但是第一個(gè)丟失的報(bào)文段只是在某些網(wǎng)絡(luò)結(jié)點(diǎn)長(zhǎng)時(shí)間滯留了，延誤到連接釋放以后的某個(gè)時(shí)間才到達(dá)服務(wù)端，此時(shí)服務(wù)端誤認(rèn)為客戶(hù)端又發(fā)出一次新的連接請(qǐng)求，于是就向客戶(hù)端發(fā)出確認(rèn)報(bào)文段，同意建立連接，不采用三次握手，只要服務(wù)端發(fā)出確認(rèn)，就建立新的連接了，此時(shí)客戶(hù)端忽略服務(wù)端發(fā)來(lái)的確認(rèn)，也不發(fā)送數(shù)據(jù)，則服務(wù)端一致等待客戶(hù)端發(fā)送數(shù)據(jù)，浪費(fèi)資源。

為什么第四次揮手后，客戶(hù)端要等待2MSL時(shí)間才能釋放客戶(hù)端的資源？

1. TCP斷開(kāi)連接為什么要有四次揮手？

TCP是一種可靠的雙向通信協(xié)議，所以每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這個(gè)過(guò)程需要四步來(lái)確保雙方都可以關(guān)閉他們的連接。前兩次揮手是用來(lái)關(guān)閉初始的發(fā)送方的連接，后兩次揮手是用來(lái)關(guān)閉另一方的連接。也就是說(shuō)，發(fā)送“FIN”只是表示發(fā)送方不再發(fā)送數(shù)據(jù)，但是仍然可以接收數(shù)據(jù)；收到對(duì)方的“FIN”標(biāo)志后才表示對(duì)方也不再發(fā)送數(shù)據(jù)，連接可以完全關(guān)閉。

2. TCP斷開(kāi)連接的最后一次揮手時(shí)，客戶(hù)端和服務(wù)器為什么都要等待2MSL的時(shí)間？（可能面試官會(huì)問(wèn)為什么客戶(hù)端發(fā)完最后一個(gè)ACK給服務(wù)器后進(jìn)入time_wait狀態(tài)）

客戶(hù)端在發(fā)送完最后一個(gè)ACK包后需要等待2MSL（Maximum Segment Lifetime，最大報(bào)文段生存時(shí)間）的時(shí)間，這主要有兩個(gè)原因：

• 確保最后一個(gè)ACK能夠到達(dá)服務(wù)端。如果ACK丟失，服務(wù)端會(huì)重發(fā)FIN包，客戶(hù)端再次發(fā)送ACK。

• 避免“老的重復(fù)分組”在網(wǎng)絡(luò)中滯留太久。在TCP連接關(guān)閉后的2MSL時(shí)間內(nèi)，不允許同一源ip地址、目的ip地址、源端口、目的端口的連接建立，**這主要是為了防止老的連接的延遲數(shù)據(jù)包在新連接中被誤認(rèn)為是有效數(shù)據(jù)。**如果讓客戶(hù)端等待2MSL時(shí)間，則

舉一個(gè)例子：

假設(shè)你有一個(gè)客戶(hù)端和服務(wù)器之間的TCP連接，其源地址和端口為C1:1234，目的地址和端口為S1:80。在這個(gè)連接中，你發(fā)送了一個(gè)數(shù)據(jù)包P，但是由于網(wǎng)絡(luò)延遲，P在網(wǎng)絡(luò)中滯留了很久，沒(méi)有立即到達(dá)服務(wù)器。然后你關(guān)閉了這個(gè)連接。

現(xiàn)在，你想要在同一個(gè)客戶(hù)端和服務(wù)器之間開(kāi)啟一個(gè)新的連接，仍然使用C1:1234和S1:80。如果你在關(guān)閉舊連接后立即開(kāi)啟新連接，那么滯留在網(wǎng)絡(luò)中的數(shù)據(jù)包P可能會(huì)到達(dá)服務(wù)器，被服務(wù)器誤認(rèn)為是新連接中的有效數(shù)據(jù)，這會(huì)導(dǎo)致數(shù)據(jù)混淆和錯(cuò)誤。

為了防止這種情況，TCP規(guī)定在關(guān)閉連接后的2MSL時(shí)間內(nèi)，不允許同一源地址、目的地址、源端口、目的端口的連接建立。這樣，滯留在網(wǎng)絡(luò)中的數(shù)據(jù)包P就有足夠的時(shí)間在網(wǎng)絡(luò)中消失，不會(huì)影響到新的連接。

所以2MSL是服務(wù)器和客戶(hù)端都需要等待的嗎？

是的，2MSL（Maximum Segment
Lifetime，最大報(bào)文段生存時(shí)間）是TCP連接在完全關(guān)閉前需要經(jīng)過(guò)的時(shí)間，這段時(shí)間既適用于客戶(hù)端，也適用于服務(wù)器。這是因?yàn)門(mén)CP連接是全雙工的，也就是說(shuō)，客戶(hù)端和服務(wù)器兩端都可以發(fā)送和接收數(shù)據(jù)。因此，無(wú)論是客戶(hù)端還是服務(wù)器，都需要確保其發(fā)送的最后一個(gè)數(shù)據(jù)包（或者確認(rèn)包）能夠到達(dá)對(duì)端，并且需要等待足夠的時(shí)間以便所有滯留在網(wǎng)絡(luò)中的數(shù)據(jù)包都有機(jī)會(huì)到達(dá)對(duì)端或者被丟棄。這樣，當(dāng)新的連接在相同的端口和地址上建立時(shí)，就不會(huì)被這些“老的”數(shù)據(jù)包所影響。

3. MSL是多少

MSL的具體數(shù)值因系統(tǒng)和網(wǎng)絡(luò)環(huán)境的不同而不同，但常見(jiàn)的數(shù)值為2分鐘。這個(gè)值足夠長(zhǎng)，可以確保TCP的報(bào)文段在網(wǎng)絡(luò)中的所有數(shù)據(jù)包都不再存在。然而，這個(gè)值在實(shí)際的網(wǎng)絡(luò)環(huán)境中并不是固定的，可以根據(jù)實(shí)際的網(wǎng)絡(luò)環(huán)境和需求進(jìn)行設(shè)置。

4. 如果客戶(hù)端的ACK丟失，那么服務(wù)端有超時(shí)機(jī)制，一定是小于MSL時(shí)間，所以會(huì)在這個(gè)時(shí)間內(nèi)重傳FIN，如果重傳的FIN又丟失了呢？

如果服務(wù)端重發(fā)的FIN一直丟失，根據(jù)TCP的設(shè)計(jì)，服務(wù)器會(huì)嘗試重發(fā)一定次數(shù)或者等待一段時(shí)間，如果仍然沒(méi)有收到客戶(hù)端的ACK，服務(wù)器會(huì)假設(shè)客戶(hù)端已經(jīng)接收到了FIN，并將連接視為關(guān)閉。雖然這可能會(huì)有一些資源沒(méi)有被立即回收，但這個(gè)過(guò)程通常是自動(dòng)的，不需要額外的干預(yù)。實(shí)際上，因?yàn)榫W(wǎng)絡(luò)的可靠性，F(xiàn)IN包一直丟失的情況在現(xiàn)實(shí)中很少發(fā)生。

5. 服務(wù)端的第二次揮手到第三次揮手之間，服務(wù)端是不是還可以傳輸其他的數(shù)據(jù)給客戶(hù)端？

是的，在服務(wù)器收到客戶(hù)端的FIN報(bào)文并且回復(fù)ACK報(bào)文后，到發(fā)送自己的FIN報(bào)文這段時(shí)間，服務(wù)器是可以繼續(xù)發(fā)送數(shù)據(jù)給客戶(hù)端的。這是因?yàn)門(mén)CP是全雙工的，一端發(fā)送FIN報(bào)文意味著“我已經(jīng)沒(méi)有數(shù)據(jù)要發(fā)送給你了”，并不影響另一端發(fā)送數(shù)據(jù)。

DDOS/DOS/SYN洪范攻擊

三者之間的一些區(qū)別

1 DDOS為什么這么叫，它不是客戶(hù)端拒絕做出第三次響應(yīng)嗎
2 和DOS有什么區(qū)別
3 和SYN攻擊有什么區(qū)別

1. DDoS（Distributed Denial of Service，分布式拒絕服務(wù)）攻擊被這樣稱(chēng)呼是因?yàn)檫@種攻擊方式通常涉及到利用許多分散的系統(tǒng)（例如被感染的計(jì)算機(jī)或其他網(wǎng)絡(luò)設(shè)備）發(fā)起大規(guī)模的攻擊，以使目標(biāo)系統(tǒng)無(wú)法提供正常的服務(wù)。DDoS攻擊并不僅僅指拒絕做出第三次tcp響應(yīng)，它是一類(lèi)攻擊方式的總稱(chēng)，包括SYN洪水攻擊、UDP洪水攻擊、ICMP洪水攻擊等。

2. DOS（Denial of Service，拒絕服務(wù)）攻擊和DDoS攻擊的主要區(qū)別在于攻擊的發(fā)起者。DOS攻擊通常由單個(gè)源發(fā)起，而DDoS攻擊則由多個(gè)源（分布在不同的網(wǎng)絡(luò)位置）發(fā)起。由于DDoS攻擊的分散性和規(guī)模，它比DOS攻擊更難防御。

3. SYN洪水攻擊是一種具體的DoS/DDoS攻擊方式，它利用TCP的三次握手機(jī)制。在SYN洪水攻擊中，攻擊者會(huì)發(fā)送大量的SYN請(qǐng)求到服務(wù)器，但不會(huì)對(duì)服務(wù)器的SYN+ACK響應(yīng)進(jìn)行確認(rèn)（即不發(fā)出第三次握手），從而導(dǎo)致大量半開(kāi)連接占用服務(wù)器資源，使正常用戶(hù)無(wú)法連接服務(wù)器。因此，SYN洪水攻擊可以看作是一種特殊的DoS/DDoS攻擊。

常見(jiàn)的防御 SYN 攻擊的方法有如下幾種：

縮短超時(shí)（SYN Timeout）時(shí)間
增加最大半連接數(shù)
過(guò)濾網(wǎng)關(guān)防護(hù)
SYN cookies技術(shù)

解釋一下上面幾種預(yù)防方法

1. 縮短超時(shí)（SYN Timeout）時(shí)間：在這種方法中，服務(wù)器會(huì)縮短等待客戶(hù)端完成TCP三次握手的超時(shí)時(shí)間。如果在這個(gè)縮短的時(shí)間內(nèi)，客戶(hù)端沒(méi)有發(fā)出第三次握手（即ACK），服務(wù)器將關(guān)閉半開(kāi)放的連接，釋放資源。這樣，服務(wù)器就可以更快地處理掉那些不完全的連接，從而有更多的資源處理新的連接請(qǐng)求。

2. 增加最大半連接數(shù)：服務(wù)器可以通過(guò)提高其允許的最大半開(kāi)連接數(shù)來(lái)防御SYN洪水攻擊。這可以增加服務(wù)器處理大量半開(kāi)連接的能力。但是，這個(gè)方法并不能完全解決問(wèn)題，因?yàn)楣粽呖赡軙?huì)通過(guò)不斷增加SYN請(qǐng)求的數(shù)量來(lái)超過(guò)服務(wù)器的最大半開(kāi)連接數(shù)。

3. 過(guò)濾網(wǎng)關(guān)防護(hù)：在網(wǎng)絡(luò)的邊界處（例如防火墻或路由器）部署過(guò)濾網(wǎng)關(guān)可以幫助防御SYN洪水攻擊。這種設(shè)備可以分析進(jìn)入網(wǎng)絡(luò)的流量，識(shí)別出可能的SYN洪水攻擊，并阻止這些攻擊流量進(jìn)入內(nèi)部網(wǎng)絡(luò)。

4. SYN cookies技術(shù)：SYN cookies是一種非常有效的防御SYN洪水攻擊的技術(shù)。在使用SYN cookies技術(shù)的服務(wù)器中，當(dāng)收到SYN請(qǐng)求時(shí)，服務(wù)器并不立即分配資源創(chuàng)建半開(kāi)連接（半開(kāi)連接也很耗費(fèi)資源），而是計(jì)算一個(gè)cookie（一個(gè)加密的哈希值），并將這個(gè)cookie作為初始序列號(hào)（ISN）在SYN+ACK響應(yīng)中發(fā)送回客戶(hù)端。如果客戶(hù)端是合法的，并且真的想要建立連接，那么在第三次握手時(shí)，它將會(huì)發(fā)送一個(gè)ACK，其確認(rèn)號(hào)是之前的ISN加一。這時(shí)，服務(wù)器收到ACK后，可以通過(guò)cookie驗(yàn)證這個(gè)ACK是否合法，如果合法就創(chuàng)建連接，否則忽略。這樣，對(duì)于合法的連接請(qǐng)求，資源只在真正建立連接時(shí)才分配，而對(duì)于攻擊造成的SYN請(qǐng)求，服務(wù)器并不分配資源，從而有效地防御了SYN洪水攻擊。

SYN cookies 的設(shè)計(jì)目的就是為了防御 SYN 洪水攻擊。在這種攻擊中，攻擊者發(fā)送大量的 SYN 請(qǐng)求以嘗試耗盡服務(wù)器資源，但他們并不完成 TCP 三次握手，因此從不發(fā)送 ACK 響應(yīng)。

SYN cookies 技術(shù)的核心思想是，服務(wù)端在未真正分配資源之前不完全信任客戶(hù)端。為了確認(rèn)客戶(hù)端的真實(shí)意圖，服務(wù)端發(fā)送一個(gè)加密的哈希值（cookie）作為初始序列號(hào) (ISN)。合法的客戶(hù)端會(huì)基于這個(gè) ISN 回應(yīng)一個(gè) ACK。

這里的服務(wù)器收到ACK后，如何通過(guò)cookie驗(yàn)證這個(gè)ACK是否合法

SYN cookies 技術(shù)背后的原理是在不完全創(chuàng)建連接的情況下驗(yàn)證客戶(hù)端的合法性。具體的工作流程如下：

1. 生成 Cookie：當(dāng)服務(wù)器收到一個(gè)SYN請(qǐng)求時(shí)，它不會(huì)立刻為這個(gè)連接分配內(nèi)存或其他資源，而是會(huì)基于客戶(hù)端的IP地址、端口號(hào)、自己的IP地址和端口號(hào)以及一個(gè)密鑰，通過(guò)一個(gè)哈希函數(shù)生成一個(gè)cookie。這個(gè)cookie然后作為初始序列號(hào)（Initial Sequence Number，ISN）發(fā)送給客戶(hù)端。

2. 客戶(hù)端響應(yīng)：如果客戶(hù)端是合法的，它會(huì)將該ISN值加一后作為ACK響應(yīng)的確認(rèn)號(hào)發(fā)送給服務(wù)器。

3. 驗(yàn)證Cookie：當(dāng)服務(wù)器收到ACK時(shí)，它會(huì)再次根據(jù)之前的算法重新計(jì)算cookie，然后檢查這個(gè)重新計(jì)算的值是否與客戶(hù)端返回的確認(rèn)號(hào)相匹配（具體地說(shuō)，是否比客戶(hù)端返回的確認(rèn)號(hào)少一）。如果匹配，則這個(gè)SYN請(qǐng)求是合法的，服務(wù)器將完整地建立這個(gè)連接。

這種機(jī)制的關(guān)鍵在于cookie的生成算法是偽隨機(jī)的，但在短時(shí)間內(nèi)是可預(yù)測(cè)的。因此，只有合法的、知道了正確的ISN的客戶(hù)端才可能返回正確的ACK確認(rèn)號(hào)。這樣，服務(wù)器就可以有效地在資源分配前篩選出惡意的SYN請(qǐng)求，從而避免資源被過(guò)度消耗。

需要注意的是，由于SYN cookies技術(shù)在初始握手階段并沒(méi)有真正地為連接分配資源，因此在使用這種技術(shù)時(shí)，某些TCP特性（如最大段大小）可能不會(huì)被正常地處理。這是這種防護(hù)機(jī)制的一個(gè)小缺點(diǎn)。

只有合法的、知道了正確的ISN的客戶(hù)端才可能返回正確的ACK確認(rèn)號(hào)。難道大量被偽造的客戶(hù)端不知道ISN號(hào)嗎，為什么

是的，你指出了一個(gè)重要的點(diǎn)。在SYN flood攻擊中，攻擊者發(fā)送大量的SYN請(qǐng)求，但大多數(shù)時(shí)候這些請(qǐng)求來(lái)自偽造的IP地址。這意味著攻擊者可能沒(méi)有真正地接收到SYN+ACK響應(yīng)，因?yàn)轫憫?yīng)會(huì)發(fā)送到偽造的IP地址，而不是攻擊者的真實(shí)地址。因此，攻擊者通常無(wú)法看到正確的ISN（因?yàn)樗赟YN+ACK響應(yīng)中）。

考慮以下步驟：

1. 攻擊者從偽造的IP地址發(fā)送SYN請(qǐng)求。
2. 服務(wù)器接收到SYN請(qǐng)求并計(jì)算cookie，然后將其作為ISN發(fā)送在SYN+ACK響應(yīng)中到偽造的IP地址。
3. 由于IP地址是偽造的，因此攻擊者可能永遠(yuǎn)不會(huì)看到這個(gè)SYN+ACK響應(yīng)，因此也看不到正確的ISN。

如果攻擊者不知道正確的ISN，那么他們就無(wú)法發(fā)送一個(gè)匹配的ACK，從而無(wú)法通過(guò)服務(wù)器的cookie驗(yàn)證。

但請(qǐng)注意，這種策略對(duì)于來(lái)源真實(shí)的SYN flood攻擊可能不太有效，因?yàn)楣粽呖梢钥吹絊YN+ACK響應(yīng)并發(fā)送正確的ACK。不過(guò)，在實(shí)際情況中，大多數(shù)的SYN flood攻擊都使用偽造的IP地址，因?yàn)檫@使得追蹤攻擊者變得更加困難。

SYN Flood主要消耗的是服務(wù)端的哪些資源呢

當(dāng)遭受SYN flood攻擊時(shí)，攻擊者發(fā)送大量的偽造源地址的SYN請(qǐng)求，目的是耗盡服務(wù)器的相關(guān)資源，導(dǎo)致合法的用戶(hù)無(wú)法與服務(wù)器建立連接。主要受到影響的資源包括：

1. 半連接隊(duì)列：當(dāng)服務(wù)器接收到SYN請(qǐng)求時(shí)，它會(huì)在一個(gè)名為半連接（half-open）隊(duì)列中創(chuàng)建一個(gè)條目來(lái)跟蹤這個(gè)連接。這個(gè)隊(duì)列有大小限制，當(dāng)遭受SYN flood攻擊時(shí)，這個(gè)隊(duì)列很快就會(huì)被填滿(mǎn)，從而使得合法的連接請(qǐng)求無(wú)法被跟蹤。

2. 內(nèi)存：每個(gè)在半連接隊(duì)列中的條目都需要一些內(nèi)存來(lái)存儲(chǔ)關(guān)于連接的信息。大量的偽造SYN請(qǐng)求會(huì)導(dǎo)致服務(wù)器為這些偽造連接分配大量的內(nèi)存。

3. CPU：處理偽造的SYN請(qǐng)求和發(fā)送SYN-ACK響應(yīng)都需要CPU資源。當(dāng)遭受大量的偽造SYN請(qǐng)求時(shí)，這會(huì)增加服務(wù)器的CPU負(fù)載。

4. 帶寬：攻擊者發(fā)送大量的SYN請(qǐng)求會(huì)消耗網(wǎng)絡(luò)帶寬。此外，服務(wù)器響應(yīng)這些請(qǐng)求也會(huì)消耗額外的帶寬。在某些情況下，這可能導(dǎo)致網(wǎng)絡(luò)擁塞。

5. 文件描述符：每個(gè)新的連接請(qǐng)求都需要一個(gè)文件描述符。在UNIX和Linux系統(tǒng)中，每個(gè)進(jìn)程都有一個(gè)最大文件描述符的限制。當(dāng)這些描述符被耗盡時(shí)，服務(wù)器可能無(wú)法處理新的連接或執(zhí)行其他與文件、套接字相關(guān)的操作。

6. 其他系統(tǒng)資源：此外，還有一些其他的系統(tǒng)資源也可能受到影響，例如ARP緩存、路由表等。

為了抵御SYN flood攻擊，可以采取多種策略，其中最著名的就是SYN cookies技術(shù)。這種技術(shù)允許服務(wù)器在不預(yù)分配大量資源的情況下處理SYN請(qǐng)求。

SYN機(jī)制總結(jié)

這其實(shí)是一種嗅探機(jī)制，跟DCL，三階段分布式事務(wù)，hashcode+equals判斷對(duì)象是否相等，很像；它們都是通過(guò)事先發(fā)送一些預(yù)檢請(qǐng)求/命令進(jìn)行檢測(cè)工作，一般檢測(cè)工作不會(huì)讓服務(wù)器或者cpu消耗過(guò)多的資源

為什么沒(méi)有SSL層沒(méi)有SYN攻擊

答：SSL/TLS 是應(yīng)用于傳輸層（例如 TCP）之上的協(xié)議，它在應(yīng)用層與傳輸層之間為通信提供加密和身份驗(yàn)證。SYN 攻擊是針對(duì)傳輸層（特別是 TCP）的攻擊，攻擊者通過(guò)發(fā)送大量的 SYN 包，但從不完成三次握手過(guò)程來(lái)消耗服務(wù)器資源。

當(dāng)開(kāi)始一個(gè) SSL/TLS 會(huì)話(huà)時(shí)，TCP 連接已經(jīng)建立，三次握手已經(jīng)完成。因此，SSL/TLS 本身不受 SYN 攻擊影響。但是，它可能受到其它類(lèi)型的攻擊，如 SSL 握手洪水攻擊，其中攻擊者嘗試使用大量的 SSL/TLS 握手來(lái)消耗服務(wù)器的計(jì)算資源。

其中攻擊者嘗試使用大量的 SSL/TLS 握手來(lái)消耗服務(wù)器的計(jì)算資源,這里的握手是指ssl重放攻擊嘛

當(dāng)提到攻擊者嘗試使用大量的 SSL/TLS 握手來(lái)消耗服務(wù)器的計(jì)算資源時(shí)，我指的并不是重放攻擊。我指的是攻擊者嘗試大量地與服務(wù)器建立新的 SSL/TLS 連接，從而觸發(fā)大量的加密握手過(guò)程。SSL/TLS 握手涉及到的公鑰加密和數(shù)字證書(shū)驗(yàn)證都是計(jì)算密集型的操作，大量的此類(lèi)握手會(huì)占用大量的服務(wù)器資源，這可能導(dǎo)致合法的用戶(hù)請(qǐng)求無(wú)法得到處理。這種攻擊被稱(chēng)為 “SSL 握手洪水攻擊”。

SSL的攻擊說(shuō)明攻擊者使用的都是真實(shí)的IP地址對(duì)吧

在執(zhí)行 SSL/TLS 攻擊時(shí)，攻擊者確實(shí)通常會(huì)使用真實(shí)的 IP 地址，因?yàn)樗麄円头?wù)器完成握手。但這并不意味著他們不能使用假的或偽造的 IP 地址。使用真實(shí)的 IP 地址確實(shí)使攻擊更容易被追蹤和定位，但是攻擊者可能會(huì)使用僵尸網(wǎng)絡(luò)或者其它方法來(lái)隱匿自己的真實(shí)位置。在網(wǎng)絡(luò)安全中，很少有事情是確定的，攻擊者常常使用各種技巧和策略來(lái)達(dá)到他們的目標(biāo)。

SYN只能攔住tcp層以及應(yīng)用層的洪水攻擊，那IP層，數(shù)據(jù)鏈路層有沒(méi)有這種攻擊呢，采取的措施和這種相似嘛？

為什么沒(méi)有SSL層沒(méi)有SYN攻擊
SSL/TLS 是應(yīng)用于傳輸層（例如 TCP）之上的協(xié)議，它在應(yīng)用層與傳輸層之間為通信提供加密和身份驗(yàn)證。SYN 攻擊是針對(duì)傳輸層（特別是 TCP）的攻擊，攻擊者通過(guò)發(fā)送大量的 SYN 包，但從不完成三次握手過(guò)程來(lái)消耗服務(wù)器資源。

當(dāng)開(kāi)始一個(gè) SSL/TLS 會(huì)話(huà)時(shí)，TCP 連接已經(jīng)建立，三次握手已經(jīng)完成。因此，SSL/TLS 本身不受 SYN 攻擊影響。但是，它可能受到其它類(lèi)型的攻擊，如 SSL 握手洪水攻擊，其中攻擊者嘗試使用大量的 SSL/TLS 握手來(lái)消耗服務(wù)器的計(jì)算資源。

IP層，數(shù)據(jù)鏈路層的攻擊
IP 層攻擊:

• ICMP Flood (Ping Flood): 攻擊者發(fā)送大量的 ICMP Echo (ping) 請(qǐng)求到目標(biāo)，使其不停地進(jìn)行回應(yīng)。

• IP Fragmentation Attack: 攻擊者發(fā)送大量的片段化數(shù)據(jù)包給目標(biāo)，使其耗費(fèi)資源嘗試重新組合這些數(shù)據(jù)包。
  數(shù)據(jù)鏈路層攻擊:

• MAC Flooding: 攻擊者嘗試填滿(mǎn)交換機(jī)的 MAC 地址表，導(dǎo)致正常流量無(wú)法通過(guò)。

• ARP Spoofing: 攻擊者發(fā)送偽造的 ARP 消息到局域網(wǎng)，目的是將某些流量從它的正常路徑重定向到攻擊者。

對(duì)于這些攻擊，應(yīng)對(duì)措施因具體情況而異。一般來(lái)說(shuō)，可以使用防火墻、入侵檢測(cè)系統(tǒng)、流量限制、過(guò)濾等手段來(lái)防范。對(duì)于數(shù)據(jù)鏈路層的攻擊，網(wǎng)絡(luò)設(shè)備通常具有內(nèi)建的安全機(jī)制和策略來(lái)進(jìn)行抵御。

SYN注入攻擊

TCP序列號(hào)預(yù)測(cè)攻擊（有時(shí)也被稱(chēng)為SYN注入攻擊）是一個(gè)相對(duì)復(fù)雜的攻擊，需要對(duì)TCP協(xié)議有深入的了解。以下是該攻擊的基本流程：

1. 監(jiān)視目標(biāo)連接：首先，攻擊者需要監(jiān)聽(tīng)或觀察兩個(gè)目標(biāo)之間的TCP連接。攻擊者的目標(biāo)通常是一對(duì)正在通信的機(jī)器，如用戶(hù)和web服務(wù)器。

2. 捕獲SYN和SYN-ACK：當(dāng)新的TCP連接開(kāi)始時(shí)，會(huì)進(jìn)行三次握手。在此過(guò)程中，客戶(hù)端發(fā)送SYN包，服務(wù)器回復(fù)SYN-ACK包。攻擊者捕獲這兩個(gè)包以獲取它們的序列號(hào)。

3. 預(yù)測(cè)序列號(hào)：基于捕獲的序列號(hào)，攻擊者嘗試預(yù)測(cè)后續(xù)數(shù)據(jù)包的序列號(hào)。這需要知道TCP實(shí)現(xiàn)的特定細(xì)節(jié)和行為。

4. 發(fā)送偽造的數(shù)據(jù)包：一旦攻擊者確定了預(yù)測(cè)的序列號(hào)，他們就可以創(chuàng)建偽造的TCP數(shù)據(jù)包。這些數(shù)據(jù)包會(huì)看起來(lái)像它們來(lái)自合法的客戶(hù)端或服務(wù)器，因?yàn)樗鼈兪褂昧祟A(yù)測(cè)的序列號(hào)。

5. 劫持連接：由于偽造的數(shù)據(jù)包看起來(lái)像合法的數(shù)據(jù)包，所以它們可能會(huì)被接收并處理，導(dǎo)致合法的數(shù)據(jù)包被偽造的數(shù)據(jù)包替換。

6. 防止合法的數(shù)據(jù)包到達(dá)目標(biāo)：為了確保偽造的數(shù)據(jù)包被接受并處理，攻擊者可能還需要確保合法的數(shù)據(jù)包不會(huì)到達(dá)目標(biāo)。這可以通過(guò)DoS攻擊或其他方法來(lái)實(shí)現(xiàn)，目的是讓偽造的數(shù)據(jù)包在合法數(shù)據(jù)包之前或代替合法數(shù)據(jù)包到達(dá)。

需要注意的是，這種攻擊依賴(lài)于能夠預(yù)測(cè)或確定TCP序列號(hào)，這是TCP設(shè)計(jì)中的一個(gè)安全隱患。為了緩解這一問(wèn)題，許多現(xiàn)代的TCP實(shí)現(xiàn)采用了隨機(jī)化的序列號(hào)，使得這種攻擊變得更加困難。

重放攻擊？

重放攻擊（Replay Attack），也叫再生攻擊或重復(fù)播放攻擊，是指攻擊者重新發(fā)送或重復(fù)發(fā)送有效的數(shù)據(jù)傳輸，從而欺騙計(jì)算機(jī)系統(tǒng)進(jìn)行未授權(quán)的操作。這種攻擊主要發(fā)生在認(rèn)證環(huán)節(jié)，其中攻擊者嘗試通過(guò)捕獲、復(fù)制并重新發(fā)送有效的用戶(hù)認(rèn)證信息（如密碼、token或密鑰）以欺騙系統(tǒng)或網(wǎng)絡(luò)。

以下是一些重放攻擊的簡(jiǎn)單示例：

1. 無(wú)線(xiàn)網(wǎng)絡(luò)中的攻擊: 如果一個(gè)攻擊者可以在無(wú)線(xiàn)網(wǎng)絡(luò)中捕獲其他設(shè)備的認(rèn)證握手，他們可以稍后再次使用這個(gè)握手來(lái)訪問(wèn)網(wǎng)絡(luò)，即使原始設(shè)備已經(jīng)斷開(kāi)連接。

2. 網(wǎng)上支付: 攻擊者截獲了一個(gè)用戶(hù)的在線(xiàn)支付交易，并在不久之后再次發(fā)送相同的交易，導(dǎo)致用戶(hù)被多次計(jì)費(fèi)。

3. 登錄憑據(jù): 攻擊者捕獲了用戶(hù)的登錄令牌或密碼，并用它來(lái)再次訪問(wèn)系統(tǒng)。

為了防御重放攻擊，通常會(huì)使用以下策略：

1. 時(shí)間戳: 為每次請(qǐng)求加入一個(gè)時(shí)間戳，并在服務(wù)器端驗(yàn)證這個(gè)時(shí)間戳來(lái)確保請(qǐng)求是新的并且在一個(gè)特定的時(shí)間窗口內(nèi)。

2. 序列號(hào): 類(lèi)似于時(shí)間戳，為每個(gè)消息提供一個(gè)獨(dú)特的、遞增的序列號(hào)，并在服務(wù)器端驗(yàn)證。

3. 一次性令牌: 使用一種機(jī)制，如HOTP或TOTP，生成一次性的、短時(shí)效的憑證或令牌，以確保每次的登錄請(qǐng)求都是獨(dú)特的。

4. 加密和完整性檢查: 使用適當(dāng)?shù)募用芎?或HMAC來(lái)確保數(shù)據(jù)的保密性和完整性，這樣攻擊者即使能截獲數(shù)據(jù)也不能輕易地進(jìn)行重放。

總的來(lái)說(shuō)，重放攻擊是一個(gè)涉及重新發(fā)送有效數(shù)據(jù)的威脅，但可以通過(guò)多種策略進(jìn)行緩解和防護(hù)。

你覺(jué)得 HTTPS 能防止重放攻擊嗎？為什么可以，HTTP呢

HTTPS 主要基于 SSL/TLS 協(xié)議，它包括一系列設(shè)計(jì)來(lái)防止重放攻擊的機(jī)制。下面來(lái)解釋為什么 HTTPS 可以防止重放攻擊，以及為什么 HTTP 不能做到這一點(diǎn)：

1. HTTPS 和重放攻擊的防護(hù):

   • 隨機(jī)數(shù): 在 TLS 握手過(guò)程中，客戶(hù)端和服務(wù)器都會(huì)生成隨機(jī)數(shù)。這些隨機(jī)數(shù)用于建立會(huì)話(huà)密鑰。即使攻擊者截獲了握手?jǐn)?shù)據(jù)并嘗試重放，由于隨機(jī)數(shù)的存在，他們無(wú)法正確地建立會(huì)話(huà)密鑰。
   • 會(huì)話(huà)恢復(fù)與會(huì)話(huà)ID: 如果客戶(hù)端和服務(wù)器決定重新使用之前的會(huì)話(huà)參數(shù)，他們會(huì)使用一個(gè)會(huì)話(huà)ID進(jìn)行會(huì)話(huà)恢復(fù)。如果攻擊者嘗試使用截獲的會(huì)話(huà)ID進(jìn)行重放，他們會(huì)失敗，因?yàn)榉?wù)器上與該ID關(guān)聯(lián)的會(huì)話(huà)參數(shù)已經(jīng)過(guò)期或無(wú)效。
   • 序列號(hào): 在TLS中，每個(gè)記錄都有一個(gè)序列號(hào)。如果服務(wù)器收到一個(gè)已經(jīng)看過(guò)的序列號(hào)，它會(huì)拒絕該記錄，從而阻止了重放攻擊。

2. HTTP 和重放攻擊:

   • 無(wú)內(nèi)置保護(hù): HTTP 是一個(gè)明文協(xié)議，它沒(méi)有為數(shù)據(jù)完整性、機(jī)密性或重放攻擊提供內(nèi)置的防護(hù)。因此，如果攻擊者截獲了一個(gè) HTTP 請(qǐng)求，他們可以簡(jiǎn)單地再次發(fā)送它來(lái)進(jìn)行重放攻擊。
   • 不使用隨機(jī)數(shù)或序列號(hào): 與 HTTPS 不同，HTTP 沒(méi)有在請(qǐng)求中包含隨機(jī)數(shù)或序列號(hào)，這意味著重放攻擊更加容易。

綜上所述，HTTPS 提供了多種機(jī)制來(lái)防止重放攻擊，而 HTTP 本身沒(méi)有這樣的保護(hù)。這也是許多網(wǎng)站和應(yīng)用程序選擇使用 HTTPS 而不是 HTTP 的原因之一，因?yàn)樗鼮閿?shù)據(jù)傳輸提供了額外的安全性。

黑客直接利用捕獲的對(duì)稱(chēng)密鑰完成重放不行嘛

你提出了一個(gè)很好的問(wèn)題。確實(shí)，如果黑客成功捕獲了對(duì)稱(chēng)密鑰，那么他們可以解密捕獲的數(shù)據(jù)，但僅僅擁有對(duì)稱(chēng)密鑰并不能直接使他們成功進(jìn)行重放攻擊，原因如下：

1. 短暫的會(huì)話(huà)密鑰：在TLS/SSL中使用的對(duì)稱(chēng)密鑰（會(huì)話(huà)密鑰）通常只存在于一個(gè)會(huì)話(huà)期間。每次握手都會(huì)生成一個(gè)新的會(huì)話(huà)密鑰。所以，即使攻擊者獲取了密鑰，它也只對(duì)那一特定會(huì)話(huà)有效。如果攻擊者想在新會(huì)話(huà)中進(jìn)行重放攻擊，他們需要獲得新會(huì)話(huà)的密鑰。

2. 序列號(hào)和時(shí)效性：如前所述，TLS中的每個(gè)記錄都有一個(gè)序列號(hào)。服務(wù)器會(huì)跟蹤這些序列號(hào)以檢測(cè)重放攻擊。即使攻擊者有對(duì)稱(chēng)密鑰并嘗試重放某個(gè)記錄，服務(wù)器會(huì)因?yàn)樾蛄刑?hào)問(wèn)題而拒絕這個(gè)記錄。

3. 完整性檢查：TLS不僅僅是加密，它還提供了數(shù)據(jù)完整性檢查。每個(gè)消息都伴隨著一個(gè)校驗(yàn)值（如HMAC）。攻擊者在不被檢測(cè)的情況下無(wú)法修改這些消息。

4. PFS（Perfect Forward Secrecy）：許多現(xiàn)代的TLS配置使用完美的前向保密。這意味著，即使長(zhǎng)期的私鑰（或其他會(huì)話(huà)的密鑰）被泄露，也不會(huì)威脅到其他會(huì)話(huà)的安全性。每個(gè)會(huì)話(huà)都有一個(gè)獨(dú)特的、不依賴(lài)于其他會(huì)話(huà)的密鑰。

當(dāng)然，如果攻擊者在會(huì)話(huà)期間捕獲了密鑰并立即嘗試重放，理論上這是可能的，但他們只有很短的時(shí)間窗口可以這樣做，并且需要在網(wǎng)絡(luò)上有相當(dāng)高的位置和能力。而且，現(xiàn)代的安全配置和措施（如上述的PFS）使得這種類(lèi)型的攻擊在實(shí)踐中變得非常困難。

總的來(lái)說(shuō)，僅僅擁有對(duì)稱(chēng)密鑰并不足以進(jìn)行成功的重放攻擊，但這當(dāng)然增加了攻擊者的能力，這也強(qiáng)調(diào)了密鑰管理和保護(hù)的重要性。

XSS、CSRF、SQL注入等安全問(wèn)題

XSS（Cross-Site Scripting）：

是一種注入攻擊，攻擊者通過(guò)在目標(biāo)網(wǎng)站上注入惡意腳本，當(dāng)其他用戶(hù)訪問(wèn)該網(wǎng)站時(shí)，這些腳本會(huì)被執(zhí)行。
防御方法：過(guò)濾用戶(hù)輸入、轉(zhuǎn)義輸出、使用內(nèi)容安全策略（CSP）。

CSRF（Cross-Site Request Forgery）：

攻擊者誘使受害者的瀏覽器發(fā)送一個(gè)請(qǐng)求到目標(biāo)網(wǎng)站（在受害者已經(jīng)登錄的情況下），這樣攻擊者可以偽造用戶(hù)的行為。
防御方法：使用 anti-CSRF tokens，確保只有真正的用戶(hù)能夠執(zhí)行敏感操作。

SQL注入：

攻擊者在應(yīng)用程序的輸入字段中插入SQL代碼。如果應(yīng)用程序沒(méi)有正確地處理這些輸入，那么這些代碼可能會(huì)被數(shù)據(jù)庫(kù)服務(wù)器執(zhí)行。
防御方法：使用參數(shù)化查詢(xún)，避免直接拼接SQL語(yǔ)句。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-682402.html

到了這里，關(guān)于深度思考計(jì)算機(jī)網(wǎng)絡(luò)面經(jīng)之二的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！