TCP/IP詳解學習筆記(12)-TCP的超時與重傳
超時重傳是TCP協議保證數據可靠性的另一個重要機制，其原理是在發送某一個數據以後就開啓一個計時器，在一定時間內如果沒有得到發送的數據報的ACK報文，那麼就重新發送數據，直到發送成功爲止。
1.超時
超時時間的計算是超時的核心部分，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.計時器的使用
兩句話:
1. 一個連接中，有且僅有一個測量定時器被使用。也就是說，如果TCP連續發出3組數據，只有一組數據會被測量。
2. ACK數據報不會被測量，原因很簡單，沒有ACK的ACK迴應可以供結束定時器測量。
2.重傳
有了超時就要有重傳，但是就算是重傳也是有策略的，而不是將數據簡單的發送。
2.1.重傳時發送數據的大小
前面曾經提到過，數據在傳輸的時候不能只使用一個窗口協議，我們還需要有一個擁塞窗口來控制數據的流量，使得數據不會一下子都跑到網路中引起“擁塞”。也曾經提到過，擁塞窗口最初使用指數增長的速度來增加自身的窗口，直到發生超時重傳，再進行一次微調。但是沒有提到，如何進行微調，擁塞避免算法和慢啓動門限就是爲此而生。
所謂的慢啓動門限就是說，當擁塞窗口超過這個門限的時候，就使用擁塞避免算法，而在門限以內就採用慢啓動算法。所以這個標準才叫做門限，通常，擁塞窗口記做cwnd，慢啓動門限記做ssthresh。下面我們來看看擁塞避免和慢啓動是怎麼一起工作的
算法概要(直接從書中拷貝)
1. 對一個給定的連接，初始化cwnd爲1個報文段，ssthresh爲65535個字節。
2. TCP輸出例程的輸出不能超過cwnd和接收方通告窗口的大小。擁塞避免是發送方使用 的流量控制，而通告窗口則是接收方進行的流量控制。前者是發送方感受到的網絡擁塞的估 計，而後者則與接收方在該連接上的可用緩存大小有關。
3. 當擁塞發生時（超時或收到重複確認），ssthresh被設置爲當前窗口大小的一半（cwnd 和接收方通告窗口大小的最小值，但最少爲2個報文段）。此外，如果是超時引起了擁塞，則 cwnd被設置爲1個報文段（這就是慢啓動）。
4. 當新的數據被對方確認時，就增加cwnd，但增加的方法依賴於我們是否正在進行慢啓 動或擁塞避免。如果cwnd小於或等於ssthresh，則正在進行慢啓動，否則正在進行擁塞避免。 慢啓動一直持續到我們回到當擁塞發生時所處位置的半時候才停止（因爲我們記錄了在步驟2 中給我們製造麻煩的窗口大小的一半），然後轉爲執行擁塞避免。
補充上面的擁塞避免公式在P238頁。這整個的流程讓我聯想到開車換檔的過程。
2.2.快速重傳和快速恢復算法
這是數據丟包的情況下給出的一種修補機制。一般來說，重傳發生在超時之後，但是如果發送端接受到3個以上的重複ACK的情況下，就應該意識到，數據丟了，需要重新傳遞。這個機制是不需要等到重傳定時器溢出的，所以叫做快速重傳，而重新傳遞以後，因爲走的不是慢啓動而是擁塞避免算法，所以這又叫做快速恢復算法。流程如下：
1. 當收到第3個重複的ACK時，將ssthresh設置爲當前擁塞窗口cwnd的一半。重傳丟失的 報文段。設置cwnd爲ssthresh加上3倍的報文段大小。
2. 每次收到另一個重複的ACK時， cwnd增加1個報文段大小併發送1個分組（如果新的 cwnd允許發送）。
3. 當下一個確認新數據的ACK到達時，設置cwnd爲ssthresh（在第1步中設置的值）。這個 ACK應該是在進行重傳後的一個往返時間內對步驟1中重傳的確認。另外，這個ACK也應該 是對丟失的分組和收到的第1個重複的ACK之間的所有中間報文段的確認。這一步採用的是擁 塞避免，因爲當分組丟失時我們將當前的速率減半。
2.3.ICMP會引起重新傳遞麼？
答案是：不會，TCP會堅持用自己的定時器，但是TCP會保留下ICMP的錯誤並且通知用戶。
2.4.重新分組
TCP爲了提高自己的效率，允許再重新傳輸的時候，只要傳輸包含重傳數據報文的報文就可以，而不用只重傳需要傳輸的報文。
