tcp中兩台裝置在同時建立連線時，為什麼需兩次傳送自己的SYN？

1樓：靈劍

這個應該不是重傳，而是一種特殊的狀態時序，一般建立連線時分主動被動兩種情況，這是第三種，即允許兩個埠同時發起連線，兩邊都是主動。從時間序列上說，兩邊發出SYN前都沒有收到對方的SYN，這種情況下兩邊都做三次握手，進入連線完成序列。實際情況下應該不太可能出現這種情況，因為一般會選擇自動分配的源埠。

同樣關閉連線也有兩邊同時發起的時序。

這種時序是一種「不約而同」，所以不會是故意設計成這樣，只是程式執行中有可能出現，為了協議完整而增加的。

至於為什麼都要再發SYN-ACK，還是三次握手的原理，你需要確認「對方在確認收到了我的SYN之後傳送了SYN表明同意建立連線」，僅僅收到SYN是不夠的，因為對方不一定收到了你的SYN。

2樓：小樓

個人認為是因為幾個原因

1、因為不能保證資料按序到達，3可以先於1到達，如果A在3不設定SYN（A的序列號對於B來說無意義），該ACK對於B來說到按照rfc來說是無意義的。假設該ACK有意義，B進入何種狀態，會出現和被動開啟不相容的情況。

2、如果能保證1先於3到達，那麼3不設定SYN在同時開啟的情況下是可行的，但是在A被動開啟的情況下會出現問題，因為B不知道A是否傳送了SYN報文。

3、如果把1，4隱藏掉，其實在SYN_RCVD和A在被動開啟的情況下傳送的報文是一致的，總是會傳送syn/ack報文，這樣就統一了。

4、總之，按照rfc的設計應該是都考慮到了被動開啟和主動開啟、同時開啟的情況。

5、自己的理解，肯定有不對的地方。

3樓：車小胖

TCP SYN是占用乙個序列號的，即乙個位元組的長度，記住一點：TCP中只要是資料，即使是乙個位元組，即使如SYN，也需要確認的！

當A發SYN（seq:C)給B，A期望收到B 的ACK：C+1可是恰恰B的SYN已經發出，沒有ACKed AB期望收到A的 ACK：K+1，

可是恰恰A的SYN已經發出，沒有ACKed B於是A又重傳了一次 SYN（seq:C，ACK：K+1），同時確認了對方B的SYN（seq:K)

B其實也是重傳了一次SYN ( seq:K, ACK: C+1)，同時確認了對方A的SYN（seq:C)

即然各自的SYN已經被確認，TCP連線就建立起來了。