發現一篇 TCP/IP如何確保資料傳送, 寫的淺顯易懂, 轉載過來~ 🙂
附上: TCP/IP 簡介, 此連結 清楚解說 TCP/IP 的歷史, 應用... 等.
TCP/IP如何確保資料傳送
TCP採用三向式握手 (three-way handshake)以建立連線。首先由來源電腦發出SYN訊息要求雙方建立TCP連線，若果對方接納連線要求便會發出SYN/ACK訊息回應，來源電腦在接收到確認訊息便以ACK再回應及進行資料傳送。在傳輸過程中若果因為網路或不明因素而令資料封包出現掉失，故此TCP本身有一套完整的傳輸機制來解決這問題。
Acknowledge (Ack)
在一般網路所使用的TCP/IP協定下，每一個資料封包都需要有acknowledge訊息的回傳。即是網路上傳輸的資料都必須要有一個收到資料的訊息回覆，才能決定是否將後來的資料繼續傳送，及決定是否重新傳遞掉失的資料封包。因此其可靠性較高，這種一來一往的機制叫「握手」(Shake hand)。當接收端收到一段資料即會發出一個確認(Ack)訊息，其中包含一個收到資料段包含序號的認可號碼 (acknowledgement number)，令TCP在回應時認可訊息附帶在可能有的資料段中一併傳給對方，藉以減少單獨的認可訊息對網路頻寬的清耗。
Retransmission (PAR)
TCP另一個確保資料正確傳輸的機制，就是當來源電腦所發出的資料在指定時間內仍未收到另一端發送出資料段的認可訊息時，便會重新送出相同的資料封包，直到對方回應認可訊息之後再送出下一個資料封包。若果重複多次也失敗，TCP便會通知應用層及發出無法連線之類的錯誤訊息。
Sequence Number
當發送一方在發出資料後收不到應答確認，便會重新送出相同的資料封包，但有時也會因為某些原因使得確認封包到達出現延遲情況，令資料在重發後才收到應答確認的封包。此種情況下，接收一方便會接收到多個互相重複的資料，為避免因而造成上層應用程式重新組合資料的時候發生混亂，故此必須把重複收到的資料封包棄掉。所以在資料傳輸時，TCP會將由上層應用程式傳來的資料，加入Sequence Number對資料傳輸加以管理及對所收到的資料進行識別。
Checksum
當TCP收到資料封包時核對表頭內的資料，若果正確便發出認可訊息表示接收無誤。否則便會自動忽略該資料封包及再次等待接收資料封包。
SlidinGWindow
在流量控制方面TCP會利用SlidinGWindow，由於每個資料封包在送出之後不會隨即到達目的地，而是會依據特定的路由路線傳送至目的地，為避免因等待接收端的認可訊息所造成的閒置，發送端可在未收到前一個資料封包凡認可訊息的情況下持續發出數個資料封包，SlidinGWindow的大小可以因應實際的網路連線質素自動調整。