主要有兩個問題：
- 防止數據沖突
- 降低TCP序列號預測攻擊的可能性
數據沖突
假設客戶端A發給服務端B的一個包在網絡里面停留太久；
最后本次連接已經結束了，后面又重新建立了一次連接；
恰巧這次連接的四元組和上次相同，（其實就是源端口剛好相同）
四元組=源IP地址+源端口號+目標IP地址+目標端口號
這時序號又是從0開始，而卡了很久的包在這時送到了服務端；
因為連接時的序號都是從0開始，這個包的序號如果剛好落在序號段接收的范圍內，就會被接收；
后面客戶端A發送的真正這個序號的包，根據TCP協議，認為是重復，會被丟棄；
TCP序列號預測攻擊
這個需要先了解一下TCP建立連接的過程（三次握手），此處默認都會；
上面的圖中，主機C模擬主機B，向主機A發送連接請求；
這種情況針對於局域網外想和內網里面的主機通信；
比如你在家，想遠程登錄公司內網的一台主機；
這里C是偽造了B的IP地址，也就是主機C發出的包的源地址是B的IP地址；
這一點很容易實現，學過操作系統和計算機網絡的就能理解；
運輸層和網絡層的協議是操作系統實現的，網卡負責轉發幀；
主機A收到連接請求后，因為IP地址是認可的，就會發送確認包
應該是公司內部授權外部這些IP地址的主機可以建立連接
根據TCP三次握手，此時再發送ACK包給主機A，連接就成功建立了
而發送的ACK需要依賴主機A的SYN，如果序號都是從0開始，那可就太簡單了；
連接建立后，主機C繼續偽造主機B的IP，就能隨意發送數據給主機A了；
因為主機A的確認包實際還是發送給主機B，為了防止B響應，這里還涉及到一種DOS的技術，感興趣的可以去了解；
在使用隨機之前，還有一種ISN生成器，它不是從0開始；
比如每4微秒讓序號+1，因為序號有32位，所以周期是4.55h左右；
或者BSD Unix的一小時增加128000，每次連接增加64000；
因為序號生成有一些規律，所以也是存在一定風險；
論文期刊中提到發起多次真實連接請求，通過分析ISN增長規律，去預測之后的ISN；
我疑問的是為什么能夠獲取到ISN的這些包？另外，又是怎么知道主機B的IP地址的？
以上是了解到的一些情況，如果有誤，歡迎指出
找的一些資料：
http://www.wanfangdata.com.cn/details/detail.do?_type=perio&id=jsjyy200212020
https://www.tech-faq.com/tcp-sequence-prediction-attack.html