三次握手的流程和基礎(chǔ)我都知道，各位不用跟我講解基礎(chǔ)概念

問題在于為什么不能進(jìn)行二次握手的問題

1.從客戶端傳送到服務(wù)器的信息在網(wǎng)絡(luò)中延遲了很久才傳到，服務(wù)器接受到消息后，返回確認(rèn)信息，但是此時客戶端的連接已近關(guān)閉，但服務(wù)器還是一直等待，這樣會造成服務(wù)器資源的浪費

這種能理解

2.從客戶端傳送到服務(wù)器的信息在網(wǎng)絡(luò)中延遲了很久才傳到，服務(wù)器接受到消息后，返回確認(rèn)信息，但是客戶端已經(jīng)放棄了第一次的連接，發(fā)送了第二次連接的請求，當(dāng)客戶端收到請求后會認(rèn)為這是第二次請求的確認(rèn)，從而建立連接。

好，問題就在這，在發(fā)送連接請求和確認(rèn)連接請求的時候，我們都會發(fā)送序號和確認(rèn)號，假設(shè)第一次客戶端發(fā)送請求時的序號為x,那么服務(wù)器返回確認(rèn)信息的包中的確認(rèn)號就應(yīng)該是x+1,那客戶端發(fā)送的第二次連接請求的序號顯然不會為x，假設(shè)為y，那么當(dāng)客戶端收到服務(wù)器返回的確認(rèn)信息中確認(rèn)號為x+1，就應(yīng)該不會建立連接，因為他需要等待是一個確認(rèn)號為y+1的。
那么這第二種問題就不應(yīng)該存在。
本人對tcp的理解只停留在概念上，沒有做過實際上對于tcp的研究，所以可能有某些地方理解上出現(xiàn)了問題，希望大家能指出。
我覺得可能的答案：
1.客戶端不會對確認(rèn)號進(jìn)行確認(rèn)，但是為什么？
2.兩次發(fā)送請求的序號相同（應(yīng)該不可能，隨機(jī)生成的）
3.這種問題不存在