網絡擁塞—導致傳輸異常—解決方法：重傳
擁塞原理-原因：
1.路由器無限緩存時： 不會丟包，排隊時間無限長
C爲路由器出口帶寬固定，剛開始輸出速率= 輸入速率， 隨着輸入速率逐漸增大， 最終輸出速率 = 路由器帶寬 不再增大， 數據包在路由緩存中無限排隊， 時延越來越大，最終超過計時器，觸發重傳
2.路由器緩存有限時：內存溢出丟包需要重傳，在隊列中未丟失的分組也要被無意義的重傳，浪費帶寬（因爲排隊時延太大觸發重傳計時器）
3.丟包後上遊服務器帶寬被浪費
如何感知是否擁塞？
超時/收到來自接收方的三個冗餘ACK——判定出現擁塞
傳輸異常
丟包：數據報傳輸途中丟失、接收端的ACK確認報文在傳輸途中丟失、接收端異常未響應ACK或被接收端丟棄。
亂序：前面的包丟了
重傳
TCP兩種重傳機制：超時重傳和快速重傳
超時重傳：在請求包發出去的時候，開啓一個計時器（計算重傳時間），當計時器達到時間之後，沒有收到ACK，則就進行重發請求的操作，一直重發直到達到重發上限次數或者收到ACK
快速重傳 ：擁塞控制中應用
當接收方收到的數據包是不正常的序列號，那麼接收方會重複把應該收到的那一條ACK重複發送，這個時候，如果發送方收到連續3條的同一個序列號的ACK，那麼就會啓動快速重傳機制，把這個ACK對應的發送包重新發送一次
TCP定時器—（超時間隔設定問題）
超時間隔必須略大於往返時間(RTT) ：等於RTT會造成不必要的重傳，過大於不能很快重傳數據包導致時延過大。
1.估計往返時間（解決超時間隔大於誰的問題）EstimatedRTT：TCP在某一次成功發送做一次RTT測量（最近的一次成文sampleRTT）,並與之前的平均RTT做加權計算得出新的平均RTT（因爲不同時間網絡的擁塞，系統負載情況不同，所以要保持更新）
RFC給出的α推薦值是0.125—最新的sampleRTT反映了當前的網絡情況，所以權值要很大。
2.RTT偏差值（解決略大多少的問題）DevRTT: DevRTT是SampleRTT和EstimatedRTT的平均差值
3. 計算重傳時間（Timeoutintervel）
爲何快速重傳是選擇3次ACK？
主要的考慮還是要區分包的丟失是由於鏈路故障還是亂序等其他因素引發。兩次duplicated ACK時很可能是亂序造成的！三次duplicated ACK時很可能是丟包造成的！四次duplicated ACK更更更可能是丟包造成的！但是這樣的響應策略太慢。丟包肯定會造成三次duplicated ACK!綜上是選擇收到三個重複確認時窗口減半效果最好，這是實踐經驗。