一、介紹
當TCP連續大量的發送數據的時候，當出現丟包的時候可以有足夠的dup ACK來觸發快速重傳。但是internet上還有大量的交互式服務，這類服務一般都是由小包組成，而且一次操作中需要傳輸的數據包一般比較少，比如在線游戲、股票交易等，這一類數據流我們就稱呼為thin stream。在一次交互式操作觸發一次TCP傳輸的時候，如果傳輸的這個數據包發生丟包，很可能后面沒有足夠的dup ACK來觸發快速重傳，最終只能依賴RTO超時來進行重傳。還有一種受限傳輸的場景，如果發送窗口受到擁塞控制的限制只能發送出少量的TCP報文的時候，如果丟包也可能會因為收不到足夠的dup ACK而不能觸發快速重傳。關於擁塞控制我們后續內容會介紹。這樣會降低用戶體驗。同時如果RTO多次指數回退，可能會進一步進一步降低用戶體驗。之前我們介紹過RTO指數回退的目的是降低網絡擁塞，而實際上交互式操作一般數據量很小，沒有必要通過指數回退來降低網絡擁塞。
綜上介紹，為了改善thin stream的傳輸，linux針對引入了兩個控制參數
/proc/sys/net/ipv4/tcp_thin_dupack：當該開關打開的時候，只需要一個dup ACK且緩存中沒有待發送數據就可以觸發快速重傳
/proc/sys/net/ipv4/tcp_thin_linear_timeouts：當該參數打開的時候，前6次RTO超時觸發的重傳並不進行指數回退。
linux中會判斷如果當前沒有處於初始的慢啟動過程(慢啟動后續擁塞控制介紹)並且已經發出去的還沒有收到ACK的數據包的個數小於4則會認定為thin stream。
二、wireshark示例
設置tcp_retries2=8,tcp_early_retrans=0,tcp_retrans_collapse=0,tcp_thin_dupack=1,tcp_thin_linear_timeouts=1,tcp_discard_on_port =9877;進行如下測試。
1、緩存中沒有待發送數據，正常觸發thin stream
- 其中No7-No8處的RTO超時重傳時候，server端發出去的未收到ACK的包個數為1(No6包)，當RTO超時的時候，TCP退出初始的慢啟動過程，因此linux判定為thin stream，進而我們看到RTO超時時候沒有觸發指數回退（No6-No9之間每個數據包的發送間隔大約都是1.5s左右）。
- 接着重傳成功后，連續發送兩個數據包（No11和No12），此時server端發出的但尚未收到ACK確認包的數據包個數為2個。因為收到擁塞控制中慢啟動的限制，此時server端最多只能發送這兩個數據包。client模擬No11數據包傳輸丟失，響應No12數據包回復一個ACK確認包，注意這個確認包的ack number與No10確認包一樣，同時包含一個SACK選項告訴server端已經收到了No12數據包
- server端認定這個數據包為dup ACK，同時數據流為thin stream，因此一個dup ACK就會觸發快速重傳，即No14數據包。對於No14數據包，wireshark顯示為亂序包實際是一個快速重傳包。另外對於No13報文，wireshark顯示為No10的dup ACK，實際上linux的處理是因為No13攜帶有有效的SACK選項才被認定為dup ACK報文的，相關內容參考前面SACK重傳的介紹。
- 快速重傳沒有收到ACK確認包的時候，接着觸發RTO超時重傳，可以看到前6次重傳(No15-No20) 都沒有觸發指數會退，RTO一直是1.5s左右。直到第7次重傳（No21）后，RTO開始進行指數回退。
2、緩存中有待發送數據不會觸發thin stream重傳
這個示例與之前類似，不同的是在第一次RTO超時重傳成功后，server端應用層寫入3個TCP報文，但是由於擁塞控制，server端TCP只能發出兩個報文No11和No12。接着cilent模擬丟失No11報文，對No12亂序報文回復一個ACK確認包，同時包含一個SACK選項告訴server端已經收到了No12數據包。此時因為緩存中還有一個TCP報文待發送就不會觸發thin stream的快速重傳而是選則發送新數據來進一步觸發dup ACK。
補充說明：
1、http://home.ifi.uio.no/paalh/students/AndreasPetlund-phd.pdf