【求助】關於TCP層的Sliding Window

[scb]

想請教各位網友一個很基本且很細的問題，
當A機器(發送端)與B機器(接收端)藉由TCP/IP協定開始溝通時，
在TCP層中A丟了一個SYN序號給B，
當B接收到後會再回傳一個ACK(=A機器的SYN+1)與SYN給A，
而當A收到後救回再丟一個ACK(=B機器的SYN+1)給B，
此時便完成三項交握並可開始傳遞資料，
之後A便先傳送一個封包跟一個SYN給B告知一次要傳三個封包，
而B再傳一個ACK(=A機器的SYN+1)給A！(這樣對嗎？)
接下來A便傳三個封包與SYN給B，
而B收到後再傳給A三個ACK(=個別封包的SYN+1)(這樣對嗎？)
接下來一直傳送直到資料送完為止！
而Sliding Window是將預傳送資料切成編號一到N的封包，
以便當發生Data Lose時可將遺失的編號封包從傳即可！(這觀念對嗎？)
因為小小看了Study-Area 的這篇文章中的Sliding Window及TCP封包表頭格式內所介紹的模擬實例產生了一些疑惑，例如當B回傳給A時的ACK值不是要=A機器的SYN+1嗎？可是該文章中的模擬實例中並沒有加一，只是把傳來的SYN值-資料長度回傳，且在滑動視窗中不是說當建立連線後會一次傳多個封包嗎？但他的模擬實例中也無此機制，小小看完後有點混亂的感覺，因此才來此請教各位大大，感恩！

[不應有恨]

RFC有出了一個新的TCP slide window做法
它是有點改良以前的slide window方式以及重傳機制
用你的例子
以前是等傳三個封包
這個slide window記錄著哪些有接哪些沒接
若有一個漏接了
會告知對方重傳一次(還是三個)
新機制只會通知對方重傳漏接的即可(可能重傳其中之ㄧ)
你上面所說的回應ACK方式也不對
ACK 序號也不加一
要加一的是next sequence+1吧
建議你找RFC看看
不過我忘了這個RFC的編號啦@@"(TCP相關的RFC好幾篇喔不要只看第一篇)