HTTP2和1.1的區(qū)別

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

HTTP1.1的隊頭阻塞問題

服務器必須按照請求接收的順序來響應，為什么

是因為傳統(tǒng)的1.1中沒有特定字段來區(qū)分一個請求屬于哪個，只能按照請求的物理順序返回，

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

正如你所說，HTTP/2通過引入“流”的概念來解決隊頭阻塞問題。每個流都有一個唯一的標識符（流ID），這使得多個請求和響應可以在同一個TCP連接上并行進行，而不會互相干擾。這樣，如果一個流的響應被延遲，它不會阻礙其他流的處理。

確切地說，HTTP/2中的“幀”結構允許多種類型的信息在一個TCP連接上進行交換。其中的“流ID”字段標識了幀屬于哪一個流。當客戶端收到響應時，它可以根據(jù)流ID對響應進行排序或處理，而不是依賴物理的發(fā)送順序。這使得服務器可以在準備好響應時立即發(fā)送它，而不需要等待其他請求的響應。

總之，HTTP/2的設計允許更高的并行性和效率，避免了HTTP/1.1中的隊頭阻塞問題。

HTTP2的這種解決隊頭阻塞問題的思路在其他的地方有應用嘛（實際上是一種多路復用機制）

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

這種思路在以下領域也有應用：

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

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

3. 計算機操作系統(tǒng)：在操作系統(tǒng)的多任務處理中，每個任務或進程都有其獨特的標識符，允許它們在一個系統(tǒng)中并行運行，而操作系統(tǒng)能夠正確地管理和調(diào)度這些任務。

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

5. 網(wǎng)格計算和并行計算：在處理分布式任務時，每個任務都可能有其獨特的標識符，允許它們在多個節(jié)點上并行運行，而系統(tǒng)能夠正確地收集和組合結果。

這種將大型任務或請求分解為可獨立處理的小塊，并為每塊分配唯一標識符的思路，在計算機科學和工程的許多領域中都有應用。

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

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

## 2.6 同步過程你是如何保證數(shù)據(jù)的一致性的答：我這個同步的過程是六張實例表同步到對應的六張定義表中（其實它們都在一張表，只不過存在架構定義和架構實例字段以表示區(qū)別）；我當時沒有保證他的一致性，但是我現(xiàn)在想到的一個解決方案是將其加入到消息隊列中，消息隊列定期消費，如果消息隊列本身是raft集群部署，本身可以保證一致性的。### 2.6.1 你整個消息隊列的消息體是什么？包含哪些核心數(shù)據(jù)答：比如說序列號，消息體中應該還包含我定義的那些模板，比如說表名，表類結構，需要同步的字段啊### 2.6.2 你們那邊應該是有節(jié)點實例id吧，如果一個節(jié)點多次發(fā)生了變更，你投放到消息隊列，實際消費的時候，會不會出現(xiàn)亂序的問題？答：有可能啊，那就開六個隊列吧，每一個隊列單線程消費### 2.6.3 從A同步到B，比如是從淘寶的買家數(shù)據(jù)到賣家的同步，是不是不能用你的單隊列單線程的模式去走？因為這樣會限制消費速率，遇到這種場景，如何去設計他呢？避免亂序。答：可以借鑒tcp的序列號機制，給每一個隊列都加上兩個字段，一個是表名，一個是序列號，不同表名下的序列號空間隔離，這樣接收端收到消息后可以依據(jù)這個序列號空間的連續(xù)性進行重排序。### 2.6.4 你這里有一個問題，如果發(fā)送端節(jié)點實例變化頻繁，發(fā)送和接收的地方是不知道的，所以你這個方案是不太行的針對感知變更號的優(yōu)化方案：答：我在消息體上再加一個字段，表示變更的版本，這樣接收端收到發(fā)送端的消息時，會比較發(fā)送端發(fā)送的版本和自己期望的版本是否一致，一致則加入到那個版本的緩沖區(qū)中，不一致則放入到其他版本的緩沖區(qū)中，延遲到接收到期望的變更號面試官的方案（他說我的方案是一種思路，但是比較復雜）：\
可以采用多節(jié)點方案，比如針對同一個節(jié)點的版本的變更號的消息統(tǒng)一經(jīng)由一個消息隊列節(jié)點發(fā)送，通過節(jié)點隔離實現(xiàn)變更號隔離。我：你這種方案更我前面說的按照表拆分隊列有什么不同呢？面試官：你的這種方式拆分的節(jié)點數(shù)和表的數(shù)量相同，但是我說的這種相當于按照"節(jié)點+變更號"的方式拆分節(jié)點，每一個消息隊列節(jié)點負責某一個節(jié)點實例id（這個實例id是邏輯id，用于解耦合）的某一個版本，拆分的粒度更細，整個的吞吐量會大很多，比如說一個同步六張表，每張表有10個變更號，按照你的方案最多拆分成6個隊列，但是按照我的方案可以拆分成60個隊列。

HTTP2的Multiplexing

HTTP2 Multiplexing是什么，有什么作用，機制是什么

在HTTP/1.1中，每個HTTP請求需要一個獨立的TCP連接，這使得同時發(fā)送多個請求需要開啟多個TCP連接。但在HTTP/2中，引入了多路復用（Multiplexing）技術，允許在單個TCP連接上同時發(fā)送多個HTTP請求和接收響應。

HTTP中的流水線和Multiplexing

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

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

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

HTTP/2 的多路復用（Multiplexing）機制通過引入“流”（Stream）的概念來保證請求和響應的順序性。

在 HTTP/2 中，每個請求響應對都被視為一個獨立的流。每個流都有一個唯一的標識符，稱為“流 ID”（Stream ID）。流可以并行發(fā)送，因為每個幀都被標記為屬于某個流，這通過幀的頭部中的流 ID 來實現(xiàn)。

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

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

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

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

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

為什么允許瀏覽器同服務端建立多個tcp連接？不是有流水線技術嗎？

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

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

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

1 問：每個TCP連接都有獨立的序列號空間和確認機制來保證即使建立多個TCP連接，接收方也能正確重組，講講這種機制？

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

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

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

所以，通過獨立的序列號空間和確認機制，即使有多個TCP連接，接收方也能正確地接收和重組每個連接的數(shù)據(jù)。

2 建立多個TCP連接就會占用多個端口對嗎？

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

3 這里的TCP四元組源IP地址、源端口、目的IP地址、目的端口唯一標識了每一個TCP序列號的空間對不對？

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

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

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

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

對的，你的理解是準確的。我們稱之為復用和分用是因為服務器端的同一端口能夠服務于來自不同客戶端的多個連接（復用，服務即指發(fā)送或者響應數(shù)據(jù)），同時也能夠根據(jù)每個連接的唯一標識（源IP和源端口）將接收到的數(shù)據(jù)正確地傳送給對應的連接/進程（分用）。

復用和分用

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

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

下面這個是詳細地址: 《計算機網(wǎng)絡》知識總結-3.復用和分用

詳細講講HTTP/2的Multiplexing實現(xiàn)機制

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

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

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

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

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

這里的Multiplexing和TCP層的I/O多路復用是同一個概念嗎？

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

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

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

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

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

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

這里HTTP的Multiplexing和TCP層的I/O多路復用應該有類似的原理吧？

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

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

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

HTTPS和HTTP

HTTPS的交互流程

大概的交互流程：

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

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

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

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

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

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

針對SSL層的報文重放攻擊如何處理？

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

報文重放攻擊時指針對ssl層的嘛？因為tcp層次存在一個序號和確認號字段，能過濾掉重復的tcp報文段，但是過濾不掉tcp序號不同，但是ssl證書重放的tcp報文段對不對

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

在TCP層面，序列號和確認號確實可以過濾掉重復的TCP段，也能在一定程度上防止數(shù)據(jù)重排。然而，這并不能防止在SSL/TLS層面上的報文重放攻擊。為什么呢？因為攻擊者可能截取并存儲一個完整的SSL/TLS會話，然后在稍后的時間里，再重放這個會話。盡管這些報文在TCP層面看起來都是新的（因為它們具有新的TCP序列號），但在SSL/TLS層面，它們其實是舊的報文，因此可能導致報文重放攻擊。
因此，SSL/TLS必須在協(xié)議層面實現(xiàn)一些防御措施來防止這種攻擊，例如通過在每個記錄中包含一個隱式的序列號，并在計算MAC時考慮這個序列號，以此來確保報文的順序和完整性。

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

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

講講使用序列號的方式來防重放攻擊的具體C/S交互流程

具體的C/S交互流程可能會因為具體的協(xié)議和應用場景而有所不同。但是對于SSL/TLS協(xié)議來說，它在握手階段就會建立起雙方共享的密鑰，然后雙方就可以開始安全地交換數(shù)據(jù)了。在這個過程中，為了防止重放攻擊，每一側的發(fā)送端會為它發(fā)送的每一條記錄維護一個序列號，并在計算MAC值時使用這個序列號。當接收端收到一條記錄后，它會用同樣的方法來計算MAC值，如果計算出的MAC值與記錄中的MAC值匹配，那么這條記錄就會被接受。否則，如果MAC值不匹配，那么這條記錄就會被拒絕，因為它可能是一個重放的記錄。

重放會導致這個MAC不匹配，為什么

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

接收端在收到消息后，會使用同樣的密鑰和它自己維護的序列號進行同樣的算法運算，得到一個新的MAC。然后接收端會比較這個新計算出的MAC和接收到的MAC是否一致。

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

也就是說，序列號的自增機制和序列號在MAC計算中的使用，聯(lián)合起來防止了重放攻擊，這也是為什么重放會導致MAC不匹配的原因。

使用HTTPS通信，每次接收端收到一個請求都會對SSL的有效性進行校驗嘛，校驗過程中使用到了MAC的驗證機制嘛，然后可以順帶去重？

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

MAC的加密、解密流程說一下，是不是使用對稱密鑰和非對稱密鑰的情況下，MAC的生成和校驗流程不一樣

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

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

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

需要注意的是，MAC機制能夠保證消息的完整性和真實性，但它不能保證消息的機密性，也就是說，消息本身并沒有被加密，如果要保證消息的機密性，還需要其他的加密技術，如對稱加密或非對稱加密。

在請求中包含一個時間戳，為什么能防止ssl防重放攻擊呢，是因為可以根據(jù)時間戳過濾掉太久遠的https請求嗎？

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

使用“一個只能使用一次的隨機數(shù)”策略，是不是得要求雙方存儲這個隨機數(shù)并且標記是否過期？（其實對序列號而言也是這樣的，需要雙方維護一個最近一次使用成功的序列號列表）

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

MAC和JWT的關系，JWT會用到MAC嘛

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

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

過程

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

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

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

mac和ip的不同之處

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

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

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

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

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

建立ssl的第一個請求是由客戶端發(fā)起還是服務端發(fā)起的呢？

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

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

數(shù)字證書通常包含以下信息：
證書所有者的公開密鑰
證書所有者的信息（包括名稱、電子郵件地址、使用證書的權限等）
發(fā)行證書的證書頒發(fā)機構（CA）的信息
證書的有效期
證書頒發(fā)機構對上述信息的數(shù)字簽名

客戶端拿到證書怎么驗證是否有效呢？

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

客戶端在收到服務器的證書后，會做以下檢查來驗證證書的有效性：

• 驗證證書的簽名：客戶端會使用證書頒發(fā)機構的公鑰來驗證證書的簽名，以此來確認證書的內(nèi)容沒有被篡改。
• 驗證證書的有效期：證書都有一個有效期，如果當前日期不在證書的有效期內(nèi)，那么證書就是無效的。
• 驗證證書的頒發(fā)機構：客戶端會檢查證書的頒發(fā)機構是否是信任的，這通常是通過檢查操作系統(tǒng)或瀏覽器中的信任的CA列表來完成的。

驗證證書的簽名：客戶端會使用證書頒發(fā)機構的公鑰來驗證證書的簽名，以此來確認證書的內(nèi)容沒有被篡改。你能看開講講其中的流程嗎？
對于數(shù)字證書的簽名驗證過程，以下是一種可能的簡化描述：

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

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

udp有哪些優(yōu)點，分別對應哪些場景呢？

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

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

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

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

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

是的，為了避免UDP數(shù)據(jù)報過大導致的分片和可能的數(shù)據(jù)丟失，一般來說，應用層需要負責控制每個UDP數(shù)據(jù)報的大小(也可以負責它的可靠性)。這是因為UDP本身是一個簡單的、無連接的協(xié)議，它并沒有提供任何關于擁塞控制、流量控制或者錯誤恢復的機制。因此，對于這些問題，通常需要在應用層進行處理。

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

http如何跨域？

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

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

websocket

websocket和http的關系

1. WebSocket 和 HTTP 的關系：

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

websocket是建立在http之上的嗎

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

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

websocket和發(fā)布訂閱機制的關系

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

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

websocket的建立流程

4. WebSocket 的建立流程：

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

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

TCP連接和釋放

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

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

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

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

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

1. TCP斷開連接為什么要有四次揮手？

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

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

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

• 確保最后一個ACK能夠到達服務端。如果ACK丟失，服務端會重發(fā)FIN包，客戶端再次發(fā)送ACK。

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

舉一個例子：

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

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

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

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

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

3. MSL是多少

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

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

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

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

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

DDOS/DOS/SYN洪范攻擊

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

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

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

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

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

常見的防御 SYN 攻擊的方法有如下幾種：

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

解釋一下上面幾種預防方法

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

2. 增加最大半連接數(shù)：服務器可以通過提高其允許的最大半開連接數(shù)來防御SYN洪水攻擊。這可以增加服務器處理大量半開連接的能力。但是，這個方法并不能完全解決問題，因為攻擊者可能會通過不斷增加SYN請求的數(shù)量來超過服務器的最大半開連接數(shù)。

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

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

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

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

這里的服務器收到ACK后，如何通過cookie驗證這個ACK是否合法

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

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

2. 客戶端響應：如果客戶端是合法的，它會將該ISN值加一后作為ACK響應的確認號發(fā)送給服務器。

3. 驗證Cookie：當服務器收到ACK時，它會再次根據(jù)之前的算法重新計算cookie，然后檢查這個重新計算的值是否與客戶端返回的確認號相匹配（具體地說，是否比客戶端返回的確認號少一）。如果匹配，則這個SYN請求是合法的，服務器將完整地建立這個連接。

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

需要注意的是，由于SYN cookies技術在初始握手階段并沒有真正地為連接分配資源，因此在使用這種技術時，某些TCP特性（如最大段大小）可能不會被正常地處理。這是這種防護機制的一個小缺點。

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

是的，你指出了一個重要的點。在SYN flood攻擊中，攻擊者發(fā)送大量的SYN請求，但大多數(shù)時候這些請求來自偽造的IP地址。這意味著攻擊者可能沒有真正地接收到SYN+ACK響應，因為響應會發(fā)送到偽造的IP地址，而不是攻擊者的真實地址。因此，攻擊者通常無法看到正確的ISN（因為它包含在SYN+ACK響應中）。

考慮以下步驟：

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

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

但請注意，這種策略對于來源真實的SYN flood攻擊可能不太有效，因為攻擊者可以看到SYN+ACK響應并發(fā)送正確的ACK。不過，在實際情況中，大多數(shù)的SYN flood攻擊都使用偽造的IP地址，因為這使得追蹤攻擊者變得更加困難。

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

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

1. 半連接隊列：當服務器接收到SYN請求時，它會在一個名為半連接（half-open）隊列中創(chuàng)建一個條目來跟蹤這個連接。這個隊列有大小限制，當遭受SYN flood攻擊時，這個隊列很快就會被填滿，從而使得合法的連接請求無法被跟蹤。

2. 內(nèi)存：每個在半連接隊列中的條目都需要一些內(nèi)存來存儲關于連接的信息。大量的偽造SYN請求會導致服務器為這些偽造連接分配大量的內(nèi)存。

3. CPU：處理偽造的SYN請求和發(fā)送SYN-ACK響應都需要CPU資源。當遭受大量的偽造SYN請求時，這會增加服務器的CPU負載。

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

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

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

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

SYN機制總結

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

為什么沒有SSL層沒有SYN攻擊

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

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

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

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

SSL的攻擊說明攻擊者使用的都是真實的IP地址對吧

在執(zhí)行 SSL/TLS 攻擊時，攻擊者確實通常會使用真實的 IP 地址，因為他們要和服務器完成握手。但這并不意味著他們不能使用假的或偽造的 IP 地址。使用真實的 IP 地址確實使攻擊更容易被追蹤和定位，但是攻擊者可能會使用僵尸網(wǎng)絡或者其它方法來隱匿自己的真實位置。在網(wǎng)絡安全中，很少有事情是確定的，攻擊者常常使用各種技巧和策略來達到他們的目標。

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

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

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

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

• ICMP Flood (Ping Flood): 攻擊者發(fā)送大量的 ICMP Echo (ping) 請求到目標，使其不停地進行回應。

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

• MAC Flooding: 攻擊者嘗試填滿交換機的 MAC 地址表，導致正常流量無法通過。

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

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

SYN注入攻擊

TCP序列號預測攻擊（有時也被稱為SYN注入攻擊）是一個相對復雜的攻擊，需要對TCP協(xié)議有深入的了解。以下是該攻擊的基本流程：

1. 監(jiān)視目標連接：首先，攻擊者需要監(jiān)聽或觀察兩個目標之間的TCP連接。攻擊者的目標通常是一對正在通信的機器，如用戶和web服務器。

2. 捕獲SYN和SYN-ACK：當新的TCP連接開始時，會進行三次握手。在此過程中，客戶端發(fā)送SYN包，服務器回復SYN-ACK包。攻擊者捕獲這兩個包以獲取它們的序列號。

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

4. 發(fā)送偽造的數(shù)據(jù)包：一旦攻擊者確定了預測的序列號，他們就可以創(chuàng)建偽造的TCP數(shù)據(jù)包。這些數(shù)據(jù)包會看起來像它們來自合法的客戶端或服務器，因為它們使用了預測的序列號。

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

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

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

重放攻擊？

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

以下是一些重放攻擊的簡單示例：

1. 無線網(wǎng)絡中的攻擊: 如果一個攻擊者可以在無線網(wǎng)絡中捕獲其他設備的認證握手，他們可以稍后再次使用這個握手來訪問網(wǎng)絡，即使原始設備已經(jīng)斷開連接。

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

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

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

1. 時間戳: 為每次請求加入一個時間戳，并在服務器端驗證這個時間戳來確保請求是新的并且在一個特定的時間窗口內(nèi)。

2. 序列號: 類似于時間戳，為每個消息提供一個獨特的、遞增的序列號，并在服務器端驗證。

3. 一次性令牌: 使用一種機制，如HOTP或TOTP，生成一次性的、短時效的憑證或令牌，以確保每次的登錄請求都是獨特的。

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

總的來說，重放攻擊是一個涉及重新發(fā)送有效數(shù)據(jù)的威脅，但可以通過多種策略進行緩解和防護。

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

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

1. HTTPS 和重放攻擊的防護:

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

2. HTTP 和重放攻擊:

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

綜上所述，HTTPS 提供了多種機制來防止重放攻擊，而 HTTP 本身沒有這樣的保護。這也是許多網(wǎng)站和應用程序選擇使用 HTTPS 而不是 HTTP 的原因之一，因為它為數(shù)據(jù)傳輸提供了額外的安全性。

黑客直接利用捕獲的對稱密鑰完成重放不行嘛

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

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

2. 序列號和時效性：如前所述，TLS中的每個記錄都有一個序列號。服務器會跟蹤這些序列號以檢測重放攻擊。即使攻擊者有對稱密鑰并嘗試重放某個記錄，服務器會因為序列號問題而拒絕這個記錄。

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

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

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

總的來說，僅僅擁有對稱密鑰并不足以進行成功的重放攻擊，但這當然增加了攻擊者的能力，這也強調(diào)了密鑰管理和保護的重要性。

XSS、CSRF、SQL注入等安全問題

XSS（Cross-Site Scripting）：

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

CSRF（Cross-Site Request Forgery）：

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

SQL注入：

攻擊者在應用程序的輸入字段中插入SQL代碼。如果應用程序沒有正確地處理這些輸入，那么這些代碼可能會被數(shù)據(jù)庫服務器執(zhí)行。
防御方法：使用參數(shù)化查詢，避免直接拼接SQL語句。