TCP為什麼可以可靠傳輸：深度解析網路世界中的承諾與實現

TCP（傳輸控制協定）之所以能實現可靠傳輸，主要歸功於其一系列精巧且協同運作的機制：首先，透過三次握手穩固地建立連接；其次，利用序號與確認應答（ACK）確保數據的有序性、完整性和不重複；接著，強大的重傳機制能在數據包遺失或損壞時進行恢復；此外，流量控制機制能防止發送端過度負荷接收端；擁塞控制則有效避免網路擁塞；最後，校驗和機制負責檢查數據在傳輸過程中是否遭到損壞。這些環環相扣的策略共同構築了一個堅實的數據傳輸堡壘，確保即使在底層網路不可靠的情況下，數據也能被準確無誤地傳遞。

想像一下，你正急著從網路上傳送一份超級重要的合約給客戶，這份合約可攸關數百萬的生意。你點擊了「發送」，然後…卻不知道這份檔案到底有沒有完整抵達，甚至有沒有在正確的順序上被接收？這聽起來是不是很讓人焦慮？在現實的數位世界裡，網路環境變幻莫測，資料傳輸的路上充滿了各種不確定性：封包可能會丟失、重複、損壞，甚至延遲亂序。這時候，我們就得仰賴一個超可靠的幕後英雄——TCP（Transmission Control Protocol，傳輸控制協定）。它就像一位經驗老到的郵差，不僅保證你的信件會送達，還會確保信件是完整的、按照正確順序抵達，並且會在你收到後給你一個「我收到了！」的回覆。

「TCP為什麼可以可靠傳輸？」這個問題，其實是許多網路工程師、開發者，甚至是對網路世界充滿好奇的朋友們，都曾經問過的核心問題。身為一個長年在網路世界打滾的工程師，我深深體會到TCP的設計哲學是多麼的巧妙與實用。它不是單靠某一個「大絕招」來達成可靠性，而是一套環環相扣、互相支援的機制。今天，我就來跟大家深入聊聊，TCP是如何一步步打造出這份「網路傳輸的承諾」。

Table of Contents

建立連結的儀式：三次握手

你可能會覺得，傳個資料還要先「握手」是不是有點多此一舉？其實不然，這個「三次握手」（Three-way Handshake）是TCP建立可靠連接的基石。它就像是兩個人在通話前，先互相確認對方是否在線、能不能聽見自己說話，以及雙方都準備好要進行溝通。沒有這個步驟，後續的資料傳輸就少了信任基礎。

這三次握手的過程是這樣的：

第一次握手 (SYN)：

發起連接的一方（通常稱為客戶端）會發送一個「同步序列號」（SYN, Synchronize Sequence Numbers）封包給接收方（通常稱為伺服器）。這個封包裡面會帶上客戶端自己選擇的初始序列號（Initial Sequence Number, ISN）。這就像客戶端對伺服器說：「哈囉，我想跟你連線，我準備好了，我的起始號碼是X。」
第二次握手 (SYN-ACK)：

伺服器收到SYN封包後，如果同意建立連接，就會回傳一個「同步確認」（SYN-ACK）封包。這個封包裡包含兩個重要資訊：一個是對客戶端SYN的確認號（ACK），這個確認號通常是客戶端ISN加一；另一個是伺服器自己選擇的初始序列號（ISN）。這就像伺服器說：「好的，我收到你的請求了，我也準備好了，確認你的號碼是X+1，我的起始號碼是Y。」
第三次握手 (ACK)：

客戶端收到SYN-ACK封包後，會再次回傳一個「確認」（ACK）封包，確認號是伺服器ISN加一。這就像客戶端說：「太棒了，我也收到你的確認了，現在我們都可以開始傳資料了！」

經過這三步，雙方都確認了對方存在、能正常收發訊息，並且交換了各自的初始序列號。這個初始序列號在後續的資料傳輸中至關重要，它保證了數據的唯一性和順序性。我的經驗是，很多網路連線問題，特別是卡在建立連線階段，往往都可以從三次握手有沒有正常完成去著手排查，可以說它是TCP可靠性的第一個守門員。

確保資料有序不丟失：序號與確認應答機制

光是握手還不夠，資料在傳輸過程中，怎麼知道哪些已經送達？哪些還沒到？萬一亂序了怎麼辦？這就得靠TCP的「序號」（Sequence Number）與「確認應答」（Acknowledgement Number, ACK）機制了，它們是TCP可靠傳輸的核心所在，就像是郵局的掛號信服務加上收件簽收。

序號 (Sequence Number)：

TCP會將應用程式的數據分割成許多較小的「報文段」（Segments）。每個報文段都會帶有一個唯一的序號，這個序號標識了該報文段中數據的起始位元組在整個數據流中的位置。發送端依序發送帶有序號的數據。舉例來說，如果一個檔案有1000個位元組，第一個報文段可能包含位元組0-99，序號就是0；第二個報文段包含100-199，序號就是100，以此類推。這樣一來，即使報文段在網路中亂序到達，接收端也能根據序號將它們重新組裝成正確的順序。
確認應答 (Acknowledgement Number, ACK)：

當接收端收到一個報文段後，它不會馬上就說「我收到了」，而是會回傳一個確認應答（ACK）封包給發送端。這個ACK封包裡面包含的確認號，其實是接收端期望收到的下一個報文段的序號。例如，如果接收端收到了序號為0-99的報文段，它會發送一個ACK，確認號為100，這表示「我已經成功收到序號到99的數據了，現在我期望收到序號為100的數據」。這樣發送端就知道哪些數據已經被成功接收，哪些還沒有。

這兩個機制簡直是天作之合。序號保證了數據的排序，而確認應答則提供了送達證明。發送端會維護一個「未確認」的數據緩衝區，只有收到對應數據的ACK後，才會將這些數據從緩衝區中移除。這套機制可以有效處理數據丟失、重複以及亂序的問題，保證了數據傳輸的完整性與準確性。我常跟同事開玩笑說，TCP的序號和ACK就像是網路傳輸的「點對點追蹤系統」，少了它，網路世界大概早就亂成一團了。

資料丟失的救星：重傳機制

網路環境瞬息萬變，數據包在傳輸過程中丟失是家常便飯。如果只是單純的發送和接收，一旦丟失，數據就永遠失去了。這時候，TCP的「重傳機制」就成了救命稻草，它確保了即使有丟失，數據也能最終送達。這就像你寄了一封重要的信，如果對方遲遲沒有回覆說收到，你就會再寄一次。

TCP的重傳機制主要有兩種：

超時重傳 (Timeout Retransmission)：

這是最基本、也是最保險的重傳方式。發送端在發送一個數據報文段後，會啟動一個定時器。如果在定時器超時之前，沒有收到對該報文段的確認應答（ACK），那麼發送端就會認為這個報文段已經丟失了，於是會重新發送一次。這個「超時時間」（Retransmission Timeout, RTO）的設定非常關鍵，它不能太短（否則會導致不必要的重傳，增加網路負擔），也不能太長（否則會影響傳輸效率）。TCP會根據網路的往返時間（Round-Trip Time, RTT）動態調整RTO的值，這是其智慧所在。
快速重傳 (Fast Retransmit)：

超時重傳雖然可靠，但如果RTO設得比較長，一旦有封包丟失，等待超時的時間可能會導致傳輸效率下降。為了解決這個問題，TCP引入了「快速重傳」機制。它的原理是：如果接收端收到一個「失序」的數據報文段，它不會等待丟失的報文段，而是會立即對它已收到的、但序號較小的（之前一個）報文段再次發送確認應答（Duplicate ACK）。當發送端連續收到三個或更多個相同的重複ACK時（這通常意味著某個報文段真的丟失了，而不是簡單的亂序），它就會在定時器超時之前，立即重傳那個被重複ACK所指的丟失報文段。這大大縮短了恢復丟失數據的時間，提高了傳輸效率。

這兩種重傳機制互相配合，共同築起了TCP可靠性的第二道防線。在網路狀況不佳時，快速重傳能快速應對突發的丟包，而超時重傳則作為最後的保障，確保任何情況下的數據最終都能被傳遞。我曾經遇過一個跨國網路服務，因為網路延遲和丟包率很高，如果沒有快速重傳機制，整個服務的響應時間根本無法接受，足見其重要性。

保護接收端不被淹沒：流量控制（滑動視窗）

有了序號、ACK和重傳，數據好像就能安全傳輸了。但有沒有想過，如果發送端一股腦地把數據全部發出去，而接收端因為處理速度慢，來不及接收怎麼辦？這就像你給朋友寄了一大箱禮物，結果他家門口根本沒地方放了。這時，「流量控制」（Flow Control）機制就登場了，它的目的就是防止發送端發送數據的速度過快，以致於接收端來不及處理而丟失數據。而實現流量控制的關鍵，就是「滑動視窗」（Sliding Window）機制。

滑動視窗的運作方式是這樣的：

接收端告知視窗大小 (Window Size)：

接收端在回傳ACK封包時，會帶上一個「視窗大小」（Window Size）的資訊。這個視窗大小代表了接收端目前還有多少可用的緩衝區空間，可以接收多少個位元組的數據。這就像接收端告訴發送端：「我現在還能收X個包裹，請不要超過這個數量。」
發送端根據視窗大小發送數據：

發送端收到視窗大小後，就會限制自己發送未經確認的數據量，使其不超過接收端所宣告的視窗大小。這就是所謂的「發送視窗」（Sending Window）。隨著接收端處理完數據並將其從緩衝區中移除，它會再次發送ACK並更新更大的視窗大小，發送端的發送視窗也會隨之「滑動」，允許發送更多的數據。

這是一個動態調整的過程。如果接收端處理速度快，視窗就會變大，發送端就能更快地傳輸數據；如果接收端處理速度慢，視窗就會變小，發送端就會放慢速度。透過這種協商機制，TCP確保了數據傳輸的速度能夠適應接收端的處理能力，有效避免了緩衝區溢出導致的數據丟失，這對於確保傳輸的穩定性非常重要。在我看來，滑動視窗就像網路世界裡的一種「禮貌」，保證了雙方的節奏能夠同步，避免了不必要的衝突。

緩解網路塞車：擁塞控制

流量控制解決了接收端過載的問題，但如果問題不是出在接收端，而是整個網路路徑上的「交通堵塞」呢？大量的數據湧入網路，超過了網路路由器、交換機的處理能力，這就會造成數據包丟失，甚至導致整個網路癱瘓。這就是「擁塞」（Congestion）。為了解決這個「公地悲劇」，TCP引入了「擁塞控制」（Congestion Control）機制，它的目標是在不導致網路擁塞的前提下，盡可能地提高數據傳輸效率。

擁塞控制不像流量控制那樣只關注單個接收端，它把整個網路看作一個整體。核心思想是：當網路出現擁塞時，發送方應該降低發送速率；當網路通暢時，發送方可以逐漸提高發送速率。TCP擁塞控制主要包含以下幾個演算法：

慢啟動 (Slow Start)：

當TCP連接建立之初，發送端會從一個非常小的「擁塞視窗」（Congestion Window, CWND）開始發送數據（通常是幾個報文段）。每收到一個ACK，擁塞視窗就會翻倍（實際上是每收到一個ACK就增加一個MSS，一個往返時間內翻倍）。這就像新車上路，先慢速行駛，如果路況良好就快速加速，以指數級增長的方式快速試探網路的承載能力。
擁塞避免 (Congestion Avoidance)：

當擁塞視窗達到一個「慢啟動閾值」（Slow Start Threshold, ssthresh）時，慢啟動階段結束。進入擁塞避免階段後，擁塞視窗的增長速度會放緩，從指數級增長變為線性增長（通常是每收到一個往返時間內的ACK，擁塞視窗增加一個MSS）。這就像車速達到一定程度後，會更謹慎地加速，避免一下子衝太快。
發生擁塞後的處理：
- 超時重傳觸發擁塞：
  
  如果發生超時重傳（這通常意味著網路擁塞非常嚴重），TCP會判斷網路已經嚴重擁塞。這時，它會將慢啟動閾值設置為當前擁塞視窗的一半，並將擁塞視窗重置為初始的最小值，重新進入慢啟動階段。這相當於直接把車停下來，重新慢慢起步。
- 快速重傳/快速恢復 (Fast Retransmit/Fast Recovery) 觸發擁塞：
  
  如果是由「快速重傳」觸發的丟包（收到三個重複ACK），TCP會認為擁塞程度沒有那麼嚴重，只是部分數據包丟失。這時，它會將慢啟動閾值和擁塞視窗都設置為當前擁塞視窗的一半，然後直接進入擁塞避免階段，而不是重新回到慢啟動。這就像車速過快時踩了一下剎車，然後繼續謹慎行駛，而不是完全停下來。這比超時重傳的處理方式更溫和，效率更高。

擁塞控制是TCP一個非常複雜但又極其精妙的部分，它不斷地在效率和穩定性之間尋找平衡點。透過動態調整發送速率，TCP像一個經驗老道的司機，在車流中小心翼翼地穿梭，既保證了速度，又避免了碰撞。業界對TCP擁塞控制演算法的研究也從未停止，像是BBR (Bottleneck Bandwidth and Round-trip propagation time) 演算法就是近年來Google提出的一個基於頻寬和延遲的新型擁塞控制演算法，旨在更高效地利用網路資源。

終結連結的藝術：四次揮手

當數據傳輸完畢，發送端和接收端不再需要通訊時，就必須「優雅地」斷開連接。這就是「四次揮手」（Four-way Handshake）的過程。為什麼是四次而不是三次？這是因為TCP是全雙工的，發送端和接收端都可以獨立地發送和接收數據。在斷開連接時，每一方都需要明確地告知對方，自己已經沒有數據要發送了，並且收到對方對此的確認。

四次揮手的過程如下：

第一次揮手 (FIN)：

當一方（比如客戶端）沒有數據要發送了，它會發送一個「結束」（FIN, Finish）封包，表示自己已經準備好關閉發送通道了。這就像客戶端說：「我這邊沒話說了，準備掛電話囉。」
第二次揮手 (ACK)：

伺服器收到FIN封包後，會立即回傳一個ACK封包，確認收到了客戶端的關閉請求。此時，伺服器可能還有數據要發送給客戶端，所以它會保持自己的發送通道開啟，繼續發送剩餘數據。這就像伺服器說：「我收到你要掛電話的通知了，但等我把剩下要說的說完再說。」
第三次揮手 (FIN)：

當伺服器也把所有數據發送完畢後，它也會發送一個FIN封包給客戶端，表示自己也準備好關閉發送通道了。這就像伺服器說：「好了，我這邊也說完了，現在可以掛電話了。」
第四次揮手 (ACK)：

客戶端收到伺服器的FIN封包後，會再次回傳一個ACK封包，確認收到了伺服器的關閉請求。在發送這個最終ACK後，客戶端會進入一個「TIME_WAIT」狀態，等待一段時間（通常是2MSL，Maximum Segment Lifetime），以確保伺服器能夠收到這個最終的ACK，並處理掉任何可能在網路中延遲的數據包。等待期過後，客戶端才會真正關閉連接。這就像客戶端說：「好的，我確認你說完了，我會稍等一下，確認你真的聽見我說完再掛電話。」

四次揮手確保了數據傳輸的雙向通道都能被妥善地關閉，避免了數據丟失或資源佔用的問題。尤其是TIME_WAIT狀態，它雖然會暫時佔用埠口資源，但卻是防止舊的、重複的報文段重新出現而干擾新連接的關鍵，確保了連接的清晰分離。

檢查資料完整性：校驗和

即使我們有了序號、ACK、重傳等機制來處理丟失和亂序，但如果數據在傳輸過程中被竄改或損壞了怎麼辦？這時候就需要一個「品質檢查員」——「校驗和」（Checksum）機制。它負責檢測數據在傳輸過程中是否發生了位元錯誤（例如電磁干擾導致的位元翻轉）。

運作方式：

發送端計算校驗和：

發送端在發送每個TCP報文段之前，會對報文段的頭部和數據內容執行一個特定的算術運算，計算出一個校驗和值。這個校驗和會被填入TCP報文頭部的「校驗和」欄位中。
接收端驗證校驗和：

接收端收到TCP報文段後，也會對報文段的頭部和數據內容執行同樣的算術運算，得到一個新的校驗和值。然後，接收端會將自己計算出來的校驗和與報文頭部中攜帶的校驗和進行比較。如果兩者不匹配，就表示數據在傳輸過程中被損壞了。此時，接收端通常會丟棄這個損壞的報文段，不發送ACK，等待發送端的重傳。

儘管校驗和不是100%完美（它無法檢測到所有的錯誤，尤其是一些複雜的錯誤模式），但它足以應對大多數常見的數據損壞情況，為TCP的可靠性增添了最後一道保障。你可以把它想像成包裹上的「防偽標籤」，確保包裹裡的東西沒有被動過手腳。

為何這些機制協同運作如此重要？我的體會

從三次握手到四次揮手，從序號與確認應答到重傳，再從流量控制到擁塞控制，以及最後的校驗和，TCP的可靠性並非單一機制所能成就，而是這些精妙的設計環環相扣、互相補充的結果。它們共同構築了一個強大且彈性的框架，能夠在惡劣的網路環境下，依然提供高質量的數據傳輸服務。

我的體會是，理解TCP的這些機制，就像是理解一輛跑車的引擎、變速箱、剎車、懸吊系統是如何協調運作的。如果只了解其中一個部分，你可能只知道它是「快」或「穩」，但無法真正理解其背後的「為什麼」。在面對網路問題時，例如連線延遲、數據傳輸慢、連線中斷等，如果能從TCP的這些機制入手去分析，往往能更快地找到問題的根源。例如，流量控制問題可能導致接收端緩衝區溢出，擁塞控制問題可能導致發送速率過低，而重傳頻繁則暗示著網路丟包嚴重。

這些設計不僅在學術上令人讚嘆，更在實務上支撐著整個網際網路的穩定運作。我們每天使用的網路應用，從網頁瀏覽到影音串流，從線上遊戲到雲端服務，幾乎都離不開TCP的默默貢獻。它就像網路世界裡一位經驗豐富、值得信賴的工程師，始終在幕後為我們提供可靠的服務。

常見問題與深度解答

TCP和UDP有什麼不同？為什麼TCP可靠而UDP不可靠？

這是網路領域最經典的問題之一，也最能突顯TCP的價值。簡而言之，TCP（傳輸控制協定）和UDP（使用者數據報協定）最大的不同就在於：TCP提供的是可靠的、基於連接的服務，而UDP提供的是不可靠的、無連接的數據報服務。

TCP之所以可靠，正是因為我們前面詳細解釋的那些機制：

它在傳輸數據前必須透過「三次握手」建立連接，確保雙方都準備好；
每個數據段都有「序號」來確保數據的正確順序和唯一性；
接收方會發送「確認應答（ACK）」來告訴發送方數據已收到；
如果數據丟失或損壞，發送方會使用「重傳機制」重新發送；
它有「流量控制」來防止發送方淹沒接收方；
還有「擁塞控制」來避免整個網路塞車；
最後，透過「校驗和」來檢查數據完整性。

這些機制層層疊疊，就像為數據傳輸戴上了多重保險，犧牲了一些效率，換來了高度的可靠性和有序性。

而UDP之所以不可靠（或說「盡力而為」），是因為它沒有以上提到的任何機制：

UDP沒有連接建立的過程，直接發送數據，因此是「無連接」的。
它不保證數據的傳輸順序，數據包可能會亂序到達。
它不保證數據的完整性，不提供丟包重傳機制。
它沒有流量控制和擁塞控制，發送方可以無限制地發送數據，容易導致網路擁塞或接收方緩衝區溢出。
雖然UDP也有校驗和，但主要用於檢測數據報頭部的錯誤，對數據內容的檢測不如TCP那麼全面嚴謹，且即使檢測到錯誤也不會主動重傳。

由於UDP不做這些額外的處理，它的優點是傳輸效率高、延遲低、開銷小。因此，對於那些允許少量丟失、對實時性要求高、或應用層自己處理可靠性的場景，UDP就非常適用，例如：線上遊戲、語音通話（VoIP）、影片直播、DNS查詢等。而TCP則適用於對數據完整性和可靠性有嚴格要求的場場景，如網頁瀏覽、檔案下載、電子郵件等。

TCP的連接狀態轉換是怎麼回事？為什麼會有TIME_WAIT狀態？

TCP連接在建立和終止的過程中，會經歷一系列定義好的狀態轉換，這是一個有限狀態機的過程。理解這些狀態有助於診斷網路問題。從初始的`CLOSED`狀態開始，經過三次握手會達到`ESTABLISHED`（已建立）狀態，這個狀態下雙方可以正常傳輸數據。而四次揮手則負責從`ESTABLISHED`狀態平穩地轉換回`CLOSED`。

我們來簡要看看關閉連接的幾個關鍵狀態：

FIN_WAIT_1 (等待遠端終止連接請求)：當客戶端主動關閉連接，發送FIN報文後，它會進入這個狀態。
CLOSE_WAIT (等待本地應用程式關閉)：伺服器收到客戶端的FIN報文後，發送ACK，並進入這個狀態。此時，伺服器可能還有數據要發送給客戶端，它會等待應用程式處理完畢。
FIN_WAIT_2 (等待遠端終止連接請求的確認)：客戶端收到伺服器對FIN的ACK後，進入這個狀態。它知道伺服器已收到關閉請求，但還沒關閉自己的發送通道。
LAST_ACK (等待本地應用程式對遠端終止連接請求的最終確認)：伺服器在發送完自己的FIN報文後，進入這個狀態。它等待客戶端的最終ACK。
TIME_WAIT (等待時間結束)：這是客戶端在收到伺服器的FIN報文並發送最終ACK後進入的狀態。這個狀態是理解TCP關閉連接的重點。

那麼，為什麼會有TIME_WAIT狀態呢？這主要是基於兩個重要的原因：

確保可靠地終止TCP連接：

即使客戶端發送了最終的ACK，這個ACK報文也可能在網路中丟失。如果沒有TIME_WAIT狀態，客戶端發送完ACK後就直接關閉連接，一旦ACK丟失，伺服器就永遠收不到這個確認。伺服器可能會一直重發它的FIN報文，而客戶端因為已經關閉連接，無法響應。TIME_WAIT狀態的存在，就是為了讓客戶端在發送完最終ACK後，等待足夠長的時間（通常是2MSL，MSL是最大報文段壽命），以確保伺服器能夠收到這個ACK。如果在等待期間伺服器重發了FIN報文（因為它沒收到ACK），客戶端還能重新發送ACK，確保伺服器成功關閉。
防止舊的報文段影響新的連接：

想像一下，一個端口對（源IP+端口、目的IP+端口）的連接被關閉後，馬上又建立了一個具有相同端口對的新連接。如果在網路中還殘留著屬於舊連接的延遲報文段（例如，因為網路擁塞導致很晚才到達），這些報文段可能會被新的連接錯誤地接收，導致數據混亂。TIME_WAIT狀態的等待時間（2MSL）通常會足夠長，足以讓網路中所有屬於舊連接的報文段都消失或過期，從而避免了這種「幽靈報文段」干擾新連接的問題。

雖然TIME_WAIT狀態會暫時佔用端口資源（特別是在高併發的伺服器上，可能會導致端口耗盡），但在絕大多數情況下，它的存在對於TCP連接的健壯性和數據的隔離性是至關重要的。雖然有些操作系統允許調整甚至跳過這個狀態，但這通常需要非常謹慎，並仔細評估可能帶來的風險。

TCP的超時重傳時間（RTO）是如何確定的？為什麼不能是固定值？

TCP的超時重傳時間（Retransmission Timeout, RTO）是一個非常關鍵的參數，它直接影響著TCP的傳輸效率和可靠性。如果RTO太短，還沒等應答回來就重傳，會造成不必要的網路流量浪費；如果RTO太長，數據丟失後恢復時間會很長，影響性能。因此，RTO不能是一個固定的值，它必須是動態調整的，以適應不斷變化的網路狀況。

TCP動態調整RTO的核心是基於對「往返時間」（Round-Trip Time, RTT）的測量。RTT是從發送一個數據報文段到收到對應確認應答（ACK）為止所花費的時間。然而，網路環境複雜多變，單次測量的RTT可能並不能代表真實的網路狀況，而且每次測量的RTT都會有所波動。為了解決這個問題，TCP使用了以下幾個關鍵值和演算法：

採樣RTT (Sample RTT, SRTT)：

發送方會對每個發送的數據報文段和其對應的ACK進行時間測量，得到多個SRTT值。但不能對重傳的報文段進行採樣，因為無法判斷收到的ACK是針對初始發送的報文還是重傳的報文（這就是Karn演算法提出的問題，即模糊現象）。
平滑的往返時間 (Smoothed RTT, SRTT)：

直接使用單次SRTT來計算RTO是不準確的。TCP採用了一種加權平均的方法來計算「平滑的往返時間」（通常也簡稱為SRTT）。常用的演算法是：
SRTT = (1 - α) * SRTT + α * Sample_RTT
其中，α 是一個平滑因子，通常取0.125（即1/8）。這個公式讓SRTT能夠反映最新的網路狀況，同時也保留了歷史數據的影響，使得它不會因為單次波動而劇烈變化。
RTT的偏差 (RTT Variation, RTTVAR)：

網路的RTT不僅會變化，其變化的幅度（即抖動）也是一個重要指標。TCP會同時計算RTT的平均偏差（或方差）。這通常用以下公式計算：
RTTVAR = (1 - β) * RTTVAR + β * |Sample_RTT - SRTT|
其中，β 是一個平滑因子，通常取0.25（即1/4）。RTTVAR反映了RTT變化的不確定性，RTO的計算必須考慮到這種不確定性。
RTO的計算：

最終的RTO值是基於SRTT和RTTVAR來計算的。標準的計算公式是：
RTO = SRTT + 4 * RTTVAR
這裡的因子4是一個經驗值，用於確保RTO足夠長，能夠覆蓋絕大多數的網路延遲情況。同時，RTO還有一個最小值（通常為1秒）和一個最大值（例如60秒），以防止在極端情況下RTO過短或過長。

正是因為有這些精巧的動態調整機制，TCP才能在各種複雜且變幻莫測的網路環境中，始終保持高效且可靠的數據傳輸。如果RTO是固定值，那麼在網路延遲高時會頻繁重傳造成擁塞，在網路延遲低時則會浪費時間等待，大大降低了TCP的適應性和性能。

總結來說，TCP的可靠傳輸是一個綜合性工程，每一項機制都不可或缺。理解這些細節，不僅能幫助我們更好地使用和調優網路應用，也能更深刻地體會到網際網路設計者的智慧。

TCP為什麼可以可靠傳輸