超時重傳是tcp協議保證資料可靠性的另乙個重要機制，其原理是在傳送某乙個資料以後就開啟乙個計時器，在一定時間內如果沒有得到傳送的資料報的ack報文，那麼就重新傳送資料，直到傳送成功為止。
超時時間的計算是超時的核心部分，tcp要求這個演算法能大致估計出當前的網路狀況，雖然這確實很困難。要求精確的原因有兩個：(1)定時長久會造成網路利用率不高。(2)定時太短會造成多次重傳，使得網路阻塞。所以，書中給出了一套經驗公式，和其他的保證計時器準確的措施。
1.1.遞推公式概說
最早的tcp曾經用了乙個非常簡單的公式來估計當前網路的狀況，如下
r<-ar+(1-a)m
rtp=rb
其中a是乙個經驗係數為0.1，b通常為2。注意，這是經驗，沒有推導過程，這個數值是可以被修改的。這個公式是說用舊的rtt(r)和新的rtt(m)綜合到一起來考慮新的rtt(r)的大小。但是，我們又看到，這種估計在網路變化很大的情況下完全不能做出「靈敏的反應」（jacoboson說的，不是偶說的，呵呵），於是就有下面的修正公式：
err=m-a
a<-a+gerr
d<-d+h(|err|-d)
rto=a+4d
具體的解釋請看書的228頁，這個遞推公式甚至把方差這種統計概念也使用了進來，使得偏差更加的小。而且，必須要指出的是，這兩組公式更新，都是在資料成功傳輸的情況下才進行，在發生資料重新傳輸的情況下，並不使用上面的公式進行網路估計，理由很簡單，因為程式已經不在正常狀態下了，估計出來的資料也是沒有意義的。
1.2.rto的初始化
rto的初始化是由公式決定的，例如最初的公式，初始的值應該是1。而修正公式，初始rto應該是a+4d。
1.3.rto的更新
當資料正常傳輸的情況下，我們就會用上面的公式來更新各個資料，並重開定時器，來保證下乙個資料被順利傳輸。要注意的是：重傳的情況下，rto不用上面的公式計算，而採用一種叫做「指數退避」的方式。例如：當rto為1s的情況下，發生了資料重傳，我們就用rto=2s的定時器來重新傳輸資料，下一次用4s。一直增加到64s為止。
1.4.估計器的初始化
在這裡，syn用的估計器初始化似乎和傳輸用的估計器不一樣（我也沒有把握）造我的理解，在修正公式中，syn的情況下，a初始化為0,d初始化為3s。
而在得到傳輸第乙個資料的ack的時候，應該按照下面的公式進行初始化：
a=m+0.5
d=a/2
1.5.估計器的更新
和上面的討論差不多，就是在正常情況下，用上面的公式計算，在重傳的情況下，不更新估計器的各種引數。原因還是因為估計不準確。
1.6.karn演算法
這不算是乙個演算法，這應該是乙個策略，說的就是更新rto和估計器的值的時機選擇問題，1.3.和1.5.所說得更新時機就是karn演算法。
1.7.計時器的使用
兩句話:
乙個連線中，有且僅有乙個測量定時器被使用。也就是說，如果tcp連續發出3組資料，只有一組資料會被測量。
ack資料報不會被測量，原因很簡單，沒有ack的ack回應可以供結束定時器測量。
有了超時就要有重傳，但是就算是重傳也是有策略的，而不是將資料簡單的傳送。
2.1.重傳時傳送資料的大小
前面曾經提到過，資料在傳輸的時候不能只使用乙個視窗協議，我們還需要有乙個擁塞視窗來控制資料的流量，使得資料不會一下子都跑到網路中引起「擁塞」。也曾經提到過，擁塞視窗最初使用指數增長的速度來增加自身的視窗，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免演算法和慢啟動門限就是為此而生。
所謂的慢啟動門限就是說，當擁塞視窗超過這個門限的時候，就使用擁塞避免演算法，而在門限以內就採用慢啟動演算法。所以這個標準才叫做門限，通常，擁塞視窗記做cwnd，慢啟動門限記做ssthresh。下面我們來看看擁塞避免和慢啟動是怎麼一起工作的
演算法概要(直接從書中拷貝)
對乙個給定的連線，初始化cwnd為1個報文段，ssthresh為65535個位元組。
tcp輸出例程的輸出不能超過cwnd和接收方通告視窗的大小。擁塞避免是傳送方使用 的流量控制，而通告視窗則是接收方進行的流量控制。前者是傳送方感受到的網路擁塞的估 計，而後者則與接收方在該連線上的可用快取大小有關。
當擁塞發生時（超時或收到重複確認），ssthresh被設定為當前視窗大小的一半（cwnd 和接收方通告視窗大小的最小值，但最少為2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設定為1個報文段（這就是慢啟動）。
當新的資料被對方確認時，就增加cwnd，但增加的方法依賴於我們是否正在進行慢啟 動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啟動，否則正在進行擁塞避免。 慢啟動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因為我們記錄了在步驟2 中給我們製造麻煩的視窗大小的一半），然後轉為執行擁塞避免。
補充上面的擁塞避免公式在p238頁。這整個的流程讓我聯想到開車換檔的過程。
2.2.快速重傳和快速恢復演算法
這是資料丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之後，但是如果傳送端接受到3個以上的重複ack的情況下，就應該意識到，資料丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢位的，所以叫做快速重傳，而重新傳遞以後，因為走的不是慢啟動而是擁塞避免演算法，所以這又叫做快速恢復演算法。流程如下：
當收到第3個重複的ack時，將ssthresh設定為當前擁塞視窗cwnd的一半。重傳丟失的 報文段。設定cwnd為ssthresh加上3倍的報文段大小。
每次收到另乙個重複的ack時， cwnd增加1個報文段大小並傳送1個分組（如果新的 cwnd允許傳送）。
當下乙個確認新資料的ack到達時，設定cwnd為ssthresh（在第1步中設定的值）。這個 ack應該是在進行重傳後的乙個往返時間內對步驟1中重傳的確認。另外，這個ack也應該 是對丟失的分組和收到的第1個重複的ack之間的所有中間報文段的確認。這一步採用的是擁 塞避免，因為當分組丟失時我們將當前的速率減半。
2.3.icmp會引起重新傳遞麼？
答案是：不會，tcp會堅持用自己的定時器，但是tcp會保留下icmp的錯誤並且通知使用者。
2.4.重新分組
TCP 超時重傳
tcp是一種可靠的協議，在網路互動的過程中，由於tcp報文是封裝在ip協議中的，ip協議的無連線特性導致其可能在互動的過程中丟失，在這種情況下，tcp協議如何保障其傳輸的可靠性呢？t c p通過在傳送資料報文時設定乙個超時定時器來解決這種問題，如果在定時器溢位時還沒有收到來自對端對傳送報文的確認，它...
tcp超時重傳
重傳定時器 tcp 必須維護乙個重傳定時器，以進行超時重傳 問題 如何設定超時時間間隔 rto？時間間隔太短則可能導致大量不必要的重傳 太長則導致效能下降 tcp 採用了乙個高度動態的演算法，來不斷的調整時間間隔，這個演算法就是 jacobson 1988 演算法 在此演算法中，tcp 需要維護幾個...
TCP 的超時重傳
tcp 的超時重傳 版權申明 一直以來都是看 tcp ip 協議 這本書來理解 tcp 的一些概念，但發現講解的不是很清晰 或者是翻譯質量的問題 最近讀tanenbaum 的 計算機網路第4版 驚喜的發現這本書對 tcp 的一些概念做了非常清晰易懂的講解，心頭的一些疑問得到了解答。現整理一下我的理解...