亚洲av成人无遮挡网站在线观看,少妇性bbb搡bbb爽爽爽,亚洲av日韩精品久久久久久,兔费看少妇性l交大片免费,无码少妇一区二区三区

Chinaunix

標(biāo)題: Linux 發(fā)生RTO的段 被ACK 后是會(huì)立刻進(jìn)入Open狀態(tài)嗎? [打印本頁]

作者: goingstudy    時(shí)間: 2018-06-15 20:27
標(biāo)題: Linux 發(fā)生RTO的段 被ACK 后是會(huì)立刻進(jìn)入Open狀態(tài)嗎?
本帖最后由 goingstudy 于 2018-06-15 20:40 編輯

假設(shè)不用SACK和Timestamp選項(xiàng),在發(fā)生RTO后,Linux 是把重傳隊(duì)列全標(biāo)記為丟失:
  1. tcp_retransmit_timer()
  2.     tcp_enter_loss()
  3.         tcp_timeout_mark_lost()
復(fù)制代碼
如果隨后的ACK 應(yīng)答了RTO的段,是會(huì)把重傳隊(duì)列全部恢復(fù)嗎(刪除重傳標(biāo)記,進(jìn)入Open狀態(tài)),這個(gè)代碼是在哪里做的?
這個(gè)我用packetdrill 確認(rèn)了,但是有疑問,而且沒找到代碼在哪里做的
  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. +0.100 < S 0:0(0) win 40000 <mss 1000>
  7. +0.000 > S. 0:0(0) ack 1 <mss 1460>
  8. +0.100 < . 1:1(0) ack 1 win 40000
  9. +0.000 accept(3, ..., ...) = 4

  10. +0.100 write(4, ..., 10000) = 10000     ==> 發(fā)生10個(gè)段
  11. +0.100 < . 1:1(0) ack 4001 win 30000 ==> ACK 4個(gè)
  12. +0.500 %{                                         ==> 500ms,強(qiáng)制RTO
  13. print "ca_state:", tcpi_ca_state             ==> 4(Loss)
  14. print "reordering:", tcpi_reordering        ==> 3
  15. print "lost:", tcpi_lost                            ==> 6(重傳隊(duì)列全部被標(biāo)記為 Loss)
  16. print "retrans:", tcpi_retrans                  ==> 1,4000-5000被重傳
  17. }%
  18. +0.000 < . 1:1(0) ack 6001 win 30000   ==> Ack 6001, 這里還有個(gè)問題,為什么沒有觸發(fā)Reno的partial Ack后的重傳?

  19. +0.100 %{
  20. print "ca_state:", tcpi_ca_state              ==> 0(立刻離開進(jìn)入Open???)
  21. print "reordering:", tcpi_reordering        ==> 3
  22. print "lost:", tcpi_lost                            ==> 0(重傳隊(duì)列的Loss標(biāo)記全部被清除,即使還有沒被Ack的)
  23. print "retrans:", tcpi_retrans                  ==> 0
  24. }%


復(fù)制代碼




作者: goingstudy    時(shí)間: 2018-06-15 20:44
用上面的例子,當(dāng)Ack6001來時(shí),代碼會(huì)
tcp_ack()
tcp_clean_rtx_queue() 會(huì)刪除已經(jīng)被ACK的段,但是不會(huì)全部(Loss標(biāo)記應(yīng)該還存在),
tcp_fastretrans_alert() 在這個(gè)函數(shù)也沒有找到進(jìn)入Open 狀態(tài)的代碼

作者: goingstudy    時(shí)間: 2018-06-16 16:10
明白了。
如果ACK6001,F(xiàn)RTO 會(huì)UNDO
如果ACK5001,那么會(huì)繼續(xù)在CA_Loss。
作者: csg109    時(shí)間: 2018-12-14 16:52
進(jìn)入到FRTO狀態(tài)應(yīng)該是DISORDER,不會(huì)是LOSS狀態(tài)
作者: goingstudy    時(shí)間: 2018-12-18 10:12
回復(fù) 4# csg109 這是你實(shí)際做過實(shí)驗(yàn)得出的還是自己認(rèn)為的?
上面我的列子里得出的是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)

如果沒問題的話,就應(yīng)該是open。




作者: csg109    時(shí)間: 2018-12-19 17:50
回復(fù) 5# goingstudy
這是我打印出來的東西,加了一個(gè)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

進(jìn)入到frto,應(yīng)該是tcp_retransmit_timer中這幾句
if (tcp_use_frto(sk)) {
                tcp_enter_frto(sk);
        } else {
                 tcp_enter_loss(sk, 0);
        }

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



作者: csg109    時(shí)間: 2018-12-19 17:59
回復(fù) 6# csg109

如果把ipv4目錄下的tcp_frto由2變成0,那就關(guān)閉了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

此時(shí)是進(jìn)入到loss狀態(tài),然后開始窗口為1的慢啟動(dòng)狀態(tài),你是什么內(nèi)核版本?

作者: goingstudy    時(shí)間: 2018-12-20 20:20
建議你用最新的代碼試試,
tcp_enter_frto這個(gè)函數(shù)都已經(jīng)找不到了,而且RTO后 ca_state == 1?
還有我是在non-sack 和non-TS下做的測(cè)試
作者: csg109    時(shí)間: 2018-12-21 10:37
回復(fù) 8# goingstudy

最新的代碼是先切換到LOSS狀態(tài),但是你說退回的open的路徑我認(rèn)為可能有誤,因?yàn)槟愕腶ck 6001確認(rèn)了兩個(gè)數(shù)據(jù)包,一個(gè)4001 一個(gè)5001,遍歷的處理4001的時(shí)候,如果數(shù)據(jù)包重傳過,會(huì)給flag打上重傳過的標(biāo)記,處理5001包的時(shí)候,會(huì)給flag加上FLAG_ORIG_SACK_ACKED標(biāo)記        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模式,會(huì)根據(jù)該ack是否含有FLAG_RETRANS_DATA_ACKED標(biāo)記,把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就會(huì)不調(diào)用你說的那個(gè)路徑.



作者: csg109    時(shí)間: 2018-12-21 10:44
回復(fù) 8# goingstudy

我看下的官方的patch,1236f22fbae15,這個(gè)是前幾個(gè)月加的patch,可能你用的內(nèi)核還沒有加這個(gè)patch,所以進(jìn)切換到OPEN狀態(tài)。
作者: goingstudy    時(shí)間: 2018-12-27 13:04
那有可能吧





歡迎光臨 Chinaunix (http://www.72891.cn/) Powered by Discuz! X3.2