一看即懂的TCP首部确认号和序列号解析！！！
仔細檢查序列和確認號碼。它們存在的目的直接關系到互聯網，通常大多數網絡都是分組交換（我們將在短時間內解釋），因為我們幾乎總是發送和接收大于最大傳輸單元（也稱為MTU）的數據 ，大多數網絡是1500。
我們來看看我們要分析的領域：
您可以看到，序列號繼續確認號碼。
我們將要解釋這些數字如何增加，它們的意思是什么，各種操作系統如何以不同的方式處理它們，最后是什么方式，這些數字可能成為那些需要牢固的安全網絡的人的安全隱患。
TCP - 面向連接的協議
序列和確認字段是幫助我們將TCP分類為面向連接協議的許多功能中的兩個。因此，當通過TCP連接發送數據時，它們有助于遠程主機跟蹤連接，并確保在到達目的地的路上沒有數據包丟失。
TCP利用肯定的確認，超時和重傳來確保用戶數據的無差錯的順序傳遞。如果重傳定時器在接收到確認之前到期，則從流中的最后一個確認字節之后的字節開始重發數據。
值得一提的還有一點是，在每個操作系統上產生的序列號不同。使用特殊的算法（有時是弱的），操作系統將產生這些數字，用于跟蹤發送或接收的數據包，并且由于序列和確認字段都是32位，所以有2 ^ 32 = 4,294,967,296種生成不同的號碼！
?
初始序列號（ISN）
當兩臺主機需要使用TCP傳輸協議傳輸數據時，會創建一個新的連接。這涉及希望啟動連接的第一個主機，以生成所謂的初始序列號（ISN），它基本上是我們正在查看的序列字段中包含的第一個序列號。ISN一直是安全問題的主題，因為它似乎是黑客“劫持”TCP連接的最喜歡的方式。
相信與否，劫持新的TCP連接是一個經驗豐富的黑客可以驚人地實現的嘗試很少。此安全問題的根源以生成ISN的方式開始。
每個操作系統都使用自己的算法為每個新的連接生成一個ISN，所以所有的黑客都需要做的就是弄清楚或者預測特定操作系統使用哪種算法，生成下一個預測的序列號并將其置于在發送到另一端的數據包中。如果攻擊者成功，則接收端被愚弄，認為該數據包是從發起連接的主機發出的有效數據包。
同時，攻擊者會對發起TCP連接的主機發起洪水攻擊，保持忙碌狀態，不會將任何數據包發送到遠程主機，因此它嘗試啟動連接。
以下是上述攻擊的簡要說明：
如上所述，黑客必須通過對主機A的所有新連接中使用的初始序列號進行采樣來找到ISN算法。一旦完成，并且黑客知道算法并準備好發起攻擊：
時間對于黑客至關重要，所以他將他的第一個假包發送到網上銀行服務器，同時開始用垃圾數據淹沒主機A，以消耗主機的帶寬和資源。通過這樣做，主機A無法應對所接收的數據，也不會將任何數據包發送到Internet Banking Server。
發送到Internet Banking Server的假包將包含有效的標頭，這意味著它似乎源自Host A的IP地址，并將被發送到InternetBanking Server正在收聽的正確端口。
已經有許多在線發布的報告，討論了每個操作系統用于生成其ISN的方法，以及它是多么容易或難以預測。不要驚慌，發現Windows操作系統的ISN算法是迄今為止最容易預測的！
實際上，像“nmap”這樣的程序將會測試發現在任何操作系統中使用的ISN算法的難度。在大多數情況下，黑客將首先從主機受害者中抽取TCP ISN，在響應連接請求時查找TCP實現選擇的初始序列號中的模式。一旦發現了一個模式，主機被連接發起的連接只需要幾分鐘的時間。
?
序列和確認號的例子
為了幫助我們了解這些新引入的字段如何用于跟蹤連接的數據包，下面給出了一個示例。
在我們繼續之前，我們應該注意，你會遇到“ACK標志”或“SYN標志”的術語;?這些術語不應該與序列和確認號混淆，因為它們是TCP報頭中的不同字段。下面的屏幕截圖是為了幫助您理解：
您可以看到序列號和確認號碼字段，后跟我們引用的TCP標志。
TCP標志（淺紫色部分）將覆蓋在頁面上以進一步深入，但是由于我們現在需要與它們一起工作，以幫助我們檢查序列和確認號碼的工作原理，我們被迫分析一小部分的他們。
為了簡單起見，請記住，當談到序列和確認號碼時，我們指的是藍色部分，而SYN和ACK標志指的是淺??紫色部分。
下圖顯示了建立與Web服務器（Gateway Server）的新連接。前三個數據包是在兩臺主機之間傳輸任何數據之前由TCP執行的三次握手的一部分，而圖中的小屏幕拍攝由我們的數據包嗅探器捕獲：
為了確保我們了解這里發生了什么，我們將逐步分析示例。
?
步驟1
主機A希望從網關服務器下載網頁。這需要建立兩者之間的新連接，因此主機A向網關服務器發送數據包。該數據包具有SYN標志集，并且還包含由主機A的操作系統生成的ISN?，即1293906975。由于主機A正在啟動連接并且尚未從網關服務器接收到答復，因此確認號碼設置為零（0）。
簡而言之，主機A告訴網關服務器如下：“我想與你建立一個新的連接，我的序列號是1293906975?”。
?
第2步
所述網關服務器接收主機A的請求，并產生一個包含其自己的生成ISN的回復，即3455719727，和下一個序列號碼被從期望主機A是1293906976。服務器還具有設置的SYN＆ACK標志，確認其接收到的上一個數據包，并通知主機A自己的序列號。
總之，網關服務器告訴主機A以下內容：“我承認你的序列號和序列號期待您下一個數據包1293906976。我的序列號為3455719727?”。
?
步驟3
主機A收到回復，現在知道網關的序列號。它生成另一個數據包來完成連接。該分組具有設置的ACK標志，并且還包含其期望網關服務器使用的序列號，即3455719728。
簡而言之，主機A告訴網關服務器如下：“我確認你的最后一個數據包，這個數據包的序列號是1293906976，這是你期望的，我也期待你發送給我的下一個數據包序號3455719728?“。
現在，有人可能期望從Gateway Server發送下一個數據包，但事實并非如此。您可能會記得主機A發起連接，因為它想從網關服務器下載一個網頁。由于3路TCP握手已經完成，所以現在兩者之間的虛擬連接已經存在，并且網關服務器準備好收聽主機A的請求。
考慮到這一點，現在現在是主機A要求它想要的網頁的時候了，這使我們進入第4步。
?
步驟4
在此步驟中，主機A生成具有某些數據的數據包，并將其發送到網關服務器。數據告訴網關服務器它要發送的網頁。
請注意，第4行中的段的序列號與第3行相同，因為ACK不占用序列號空間。
因此，請記住，生成的任何數據包，簡單地確認（換句話說，只有ACK標志被設置并且不包含任何數據）到先前接收的數據包，不會增加序列號。
?
最后的筆記
在兩臺主機的通信過程中，序列和確認號碼還有其他重要的作用。因為段（或數據包）在IP數據報中傳播，所以它們可能會丟失或丟失，因此接收器使用序列號重新排序段。接收器從到達的段收集數據，并重建正在發送的流的精確副本。
如果我們仔細看看上面的圖表，我們注意到TCP?確認號碼指定了接收機預期的下一個段的序列號。只需滾動回到步驟2，你會看到我的意思。
?
原文地址：http://www.firewall.cx/networking-topics/protocols/tcp/134-tcp-seq-ack-numbers.html
本文轉自原翻譯作者ChenVast的博客：https://blog.csdn.net/ChenVast/article/details/77978588
總結
以上是生活随笔為你收集整理的一看即懂的TCP首部确认号和序列号解析！！！的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SQL Server2012 序列号 注
- 下一篇： VisualStudio2012的序列号