Linux 發(fā)生RTO的段 被ACK 后是會立刻進入Open狀態(tài)嗎？

goingstudy

假設不用SACK和Timestamp選項，在發(fā)生RTO后，Linux 是把重傳隊列全標記為丟失：

1. tcp_retransmit_timer()
   
2.     tcp_enter_loss()
   
3.         tcp_timeout_mark_lost()

復制代碼

如果隨后的ACK 應答了RTO的段，是會把重傳隊列全部恢復嗎（刪除重傳標記，進入Open狀態(tài)），這個代碼是在哪里做的？
這個我用packetdrill 確認了，但是有疑問，而且沒找到代碼在哪里做的

1. +0.000 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
   
2. +0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
   
3. +0.000 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [131072], 4) = 0
   
4. +0.000 bind(3, ..., ...) = 0
   
5. +0.000 listen(3, 1) = 0
   
6. 
   
7. +0.100 < S 0:0(0) win 40000 <mss 1000>
   
8. +0.000 > S. 0:0(0) ack 1 <mss 1460>
   
9. +0.100 < . 1:1(0) ack 1 win 40000
   
10. +0.000 accept(3, ..., ...) = 4
    
11. 
    
12. +0.100 write(4, ..., 10000) = 10000     ==> 發(fā)生10個段
    
13. +0.100 < . 1:1(0) ack 4001 win 30000 ==> ACK 4個
    
14. +0.500 %{                                         ==> 500ms,強制RTO
    
15. print "ca_state:", tcpi_ca_state             ==> 4(Loss)
    
16. print "reordering:", tcpi_reordering        ==> 3
    
17. print "lost:", tcpi_lost                            ==> 6(重傳隊列全部被標記為 Loss)
    
18. print "retrans:", tcpi_retrans                  ==> 1，4000-5000被重傳
    
19. }%
    
20. +0.000 < . 1:1(0) ack 6001 win 30000   ==> Ack 6001, 這里還有個問題，為什么沒有觸發(fā)Reno的partial Ack后的重傳？
    
21. 
    
22. +0.100 %{
    
23. print "ca_state:", tcpi_ca_state              ==> 0(立刻離開進入Open？？？)
    
24. print "reordering:", tcpi_reordering        ==> 3
    
25. print "lost:", tcpi_lost                            ==> 0(重傳隊列的Loss標記全部被清除，即使還有沒被Ack的)
    
26. print "retrans:", tcpi_retrans                  ==> 0
    
27. }%
    
28. 
    
29. 
    

復制代碼

goingstudy

用上面的例子，當Ack6001來時，代碼會
tcp_ack()
tcp_clean_rtx_queue() 會刪除已經被ACK的段，但是不會全部（Loss標記應該還存在），
tcp_fastretrans_alert() 在這個函數(shù)也沒有找到進入Open 狀態(tài)的代碼

goingstudy

明白了。
如果ACK6001，F(xiàn)RTO 會UNDO
如果ACK5001，那么會繼續(xù)在CA_Loss。

csg109

進入到FRTO狀態(tài)應該是DISORDER，不會是LOSS狀態(tài)

goingstudy

回復 4# csg109 這是你實際做過實驗得出的還是自己認為的？
上面我的列子里得出的是Open，而且從代碼分析
timeout ->
tcp_enter_loss -> tp->frto = 1, LOSS

Ack6001->
snd_una_advanced
prior_fack = tp->snd_una
tcp_ack_update_window
tcp_clean_rtx_queue  --> FLAG_ORIGI_SACK_ACKED
tcp_ack_is_dubious --> tcp_fastretrans_alert -->
tcp_process_loss-->
tcp_try_undo_loss-> tcp_set_ca_state(TCP_CA_Open)

如果沒問題的話，就應該是open。

csg109

回復 5# goingstudy
這是我打印出來的東西，加了一個snd_cwnd和packets_out
ca_state: 1
reordering: 3
lost: 0
retrans: 1
snd_cwnd: 5
packets_out: 5

ca_state: 1
reordering: 3
lost: 0
retrans: 0
snd_cwnd: 5
packets_out: 4

進入到frto，應該是tcp_retransmit_timer中這幾句
if (tcp_use_frto(sk)) {
                tcp_enter_frto(sk);
        } else {
                 tcp_enter_loss(sk, 0);
        }

而調用tcp_enter_frto()后面是切換到Disorder狀態(tài).

csg109

回復 6# csg109

如果把ipv4目錄下的tcp_frto由2變成0，那就關閉了FRTO功能，然后打印的信息ca_state: 4
reordering: 3
lost: 5
retrans: 1
snd_cwnd: 1
packets_out: 5

ca_state: 4
reordering: 3
lost: 3
retrans: 2
snd_cwnd: 2
packets_out: 3

此時是進入到loss狀態(tài)，然后開始窗口為1的慢啟動狀態(tài)，你是什么內核版本？

goingstudy

建議你用最新的代碼試試，
tcp_enter_frto這個函數(shù)都已經找不到了，而且RTO后 ca_state == 1?
還有我是在non-sack 和non-TS下做的測試

csg109

回復 8# goingstudy

最新的代碼是先切換到LOSS狀態(tài)，但是你說退回的open的路徑我認為可能有誤，因為你的ack 6001確認了兩個數(shù)據包，一個4001 一個5001,遍歷的處理4001的時候，如果數(shù)據包重傳過，會給flag打上重傳過的標記，處理5001包的時候，會給flag加上FLAG_ORIG_SACK_ACKED標記        if (unlikely(sacked & TCPCB_RETRANS)) {
            if (sacked & TCPCB_SACKED_RETRANS)
                tp->retrans_out -= acked_pcount;
            flag |= FLAG_RETRANS_DATA_ACKED;
        } else if (!(sacked & TCPCB_SACKED_ACKED)) {


            last_ackt = tcp_skb_timestamp_us(skb);
            WARN_ON_ONCE(last_ackt == 0);
            if (!first_ackt)
                first_ackt = last_ackt;

            last_in_flight = TCP_SKB_CB(skb)->tx.in_flight;
            if (before(start_seq, reord))
                reord = start_seq;
            if (!after(scb->end_seq, tp->high_seq))
                flag |= FLAG_ORIG_SACK_ACKED;
        }

退出循環(huán)后，如果是reno模式，會根據該ack是否含有FLAG_RETRANS_DATA_ACKED標記，把FLAG_ORIG_SACK_ACKED清除
        if (tcp_is_reno(tp)) {
            tcp_remove_reno_sacks(sk, pkts_acked);

            /* If any of the cumulatively ACKed segments was
             * retransmitted, non-SACK case cannot confirm that
             * progress was due to original transmission due to
             * lack of TCPCB_SACKED_ACKED bits even if some of
             * the packets may have been never retransmitted.
             */
            if (flag & FLAG_RETRANS_DATA_ACKED)
                flag &= ~FLAG_ORIG_SACK_ACKED;
        }

原因代碼的英文注釋也寫的很清除了，所以之后的tcp_process_loss就會不調用你說的那個路徑.

csg109

回復 8# goingstudy

我看下的官方的patch，1236f22fbae15，這個是前幾個月加的patch，可能你用的內核還沒有加這個patch，所以進切換到OPEN狀態(tài)。