日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁 > 云知道 > >

網(wǎng)絡(luò)流量控制 網(wǎng)絡(luò)流量監(jiān)控工具

云知道

TCP流量控制主要由基于接收方確認(rèn)的滑動窗口機(jī)制和基于網(wǎng)絡(luò)情況的發(fā)送方的擁塞控制算法來實(shí)現(xiàn)！
TCP Traffic ControlTCP流量控制主要涉及滑動窗口，擁塞控制算法，RTT(Round-Trip Time,往返時(shí)間)，RTO(Retransmission Timeout,重傳超時(shí))計(jì)算等等 。
  1. 滑動窗口通常認(rèn)為是接收方反饋給發(fā)送方的流量和重傳控制(不考慮網(wǎng)絡(luò))；
  2. 擁塞控制算法通常認(rèn)為是發(fā)送方的流量控制算法(考慮網(wǎng)絡(luò)時(shí)延丟包等)；
  3. RTT計(jì)算會影響到RTO計(jì)算及影響某些擁塞算法運(yùn)行結(jié)果；
  4. RTO計(jì)算會涉及到超時(shí)重傳定時(shí)器設(shè)置 。
滑動窗口滑動窗口(sliding window)是數(shù)據(jù)傳輸時(shí)接收方通告窗口給發(fā)送方，然后發(fā)送方根據(jù)窗口決定一次發(fā)送多少數(shù)據(jù)的機(jī)制，本質(zhì)是ARQ(Automatic Repeat Request, 停等協(xié)議)，滑動窗口一方面利用接收方確認(rèn)報(bào)文反饋的窗口大小控制每次發(fā)包個(gè)數(shù)，另一方面根據(jù)接收方確認(rèn)報(bào)文確認(rèn)號判斷數(shù)據(jù)幀重傳，滑動窗口僅通過接收方反饋的信息進(jìn)行流量控制，不會考慮網(wǎng)絡(luò)帶寬延遲等因素 。
ARQ主要有連續(xù)ARQGo-Back-N和選擇ARQSelective Repeat兩種，TCP中使用Go-back-N，Selective Repeat作為可選實(shí)現(xiàn) 。Go-back-N和Selective Repeat區(qū)別在于，Go-back-N一次發(fā)包只有一個(gè)定時(shí)器，中間出現(xiàn)丟包，則丟的包之后的所有包都需要重傳，Selective Repeat一次發(fā)包需要和包個(gè)數(shù)一樣的定時(shí)器數(shù)量，中間出現(xiàn)丟包則僅重傳丟失的那個(gè)包，簡單來說Go-back-N比較耗網(wǎng)絡(luò)帶寬，Selective Repeat比較耗計(jì)算資源 。
兩種ARQ滑動窗口發(fā)送過程可參考如下網(wǎng)站的動畫：

https://www2.tkn.tu-berlin.de/teaching/rn/animations/gbn_sr/
TCP滑動機(jī)制原理可簡述為：TCP發(fā)送方包含一個(gè)發(fā)送窗口，按序列號發(fā)送數(shù)據(jù)包，TCP接收方根據(jù)收到的包回復(fù)確認(rèn)包，TCP發(fā)送包根據(jù)收到的確認(rèn)包中通告窗口反饋來動態(tài)調(diào)節(jié)發(fā)送窗口大小、滑動窗口右移并發(fā)送后續(xù)的數(shù)據(jù)包 。
如下tcpipguide網(wǎng)站TCP滑動窗口描述，TCP發(fā)送方發(fā)送緩存區(qū)分為4塊區(qū)域:已發(fā)送已確認(rèn)、已發(fā)送未確認(rèn)、未發(fā)送接收方已準(zhǔn)備好和未發(fā)送接收方未準(zhǔn)備好，TCP接收方接收緩存區(qū)分為3塊區(qū)域:已接收已確認(rèn)、未接收被允許發(fā)送、未收到發(fā)生方可能未發(fā)送 。

網(wǎng)絡(luò)流量控制 網(wǎng)絡(luò)流量監(jiān)控工具



網(wǎng)絡(luò)流量控制 網(wǎng)絡(luò)流量監(jiān)控工具


Linux內(nèi)核4.x中滑動窗口代碼示例，大體可以看出來和tcpipguid網(wǎng)站中描述一致：
/* ｕｐｄａｔｅ our send window. * * Window ｕｐｄａｔｅ algorithm, described in RFC793/RFC1122 (used in linux-2.2 * and in FreeBSD. NetBSD's one is even worse.) is wrong. */static int tcp_ack_update_window(struct sock *sk, const struct sk_buff *skb, u32 ack,u32 ack_seq){struct tcp_sock *tp = tcp_sk(sk);int flag = 0;u32 nwin = ntohs(tcp_hdr(skb)->window);if (likely(!tcp_hdr(skb)->syn))nwin <<= tp->rx_opt.snd_wscale;if (tcp_may_update_window(tp, ack, ack_seq, nwin)) {flag |= FLAG_WIN_UPDATE;tcp_update_wl(tp, ack_seq);if (tp->snd_wnd != nwin) {tp->snd_wnd = nwin;/* Note, it is the only place, where* fast path is recovered for sending TCP.*/tp->pred_flags = 0;tcp_fast_path_check(sk);if (!tcp_write_queue_empty(sk))tcp_slow_start_after_idle_check(sk);if (nwin > tp->max_window) {tp->max_window = nwin;tcp_sync_mss(sk, inet_csk(sk)->icsk_pmtu_cookie);}}}tcp_snd_una_update(tp, ack);return flag;}RTT&RTO計(jì)算TCP流量控制中RTT及RTO計(jì)算是一個(gè)很重要的問題，ARQ中針對丟包都需要超時(shí)重傳，超時(shí)的設(shè)置就會涉及到RTO，RTO設(shè)置過短(<2RTT)則可能導(dǎo)致不必要的重傳(丟的包可能在傳輸馬上能到)，超時(shí)重傳時(shí)間設(shè)置過長則可能影響TCP通信效率(一直在等丟的包重傳過來)，RTO計(jì)算需要基于RTT，RTT計(jì)算值直接影響RTO，不少擁塞算法也和RTT直接相關(guān)，TCP流端到端的RTT和RTO都不是一個(gè)固定的值，都是一段時(shí)間網(wǎng)絡(luò)中端到端的估算值，隨著時(shí)間和網(wǎng)絡(luò)的變化而變化 。

推薦閱讀