网络流量控制网络流量监控工具 _生活百科

TCP流量控制主要由基于接收方确认的滑动窗口机制和基于网络情况的发送方的拥塞控制算法来实现！

TCP Traffic ControlTCP流量控制主要涉及滑动窗口，拥塞控制算法，RTT(Round-Trip Time,往返时间)，RTO(Retransmission Timeout,重传超时)计算等等。

滑动窗口通常认为是接收方反馈给发送方的流量和重传控制(不考虑网络)；
拥塞控制算法通常认为是发送方的流量控制算法(考虑网络时延丢包等)；
RTT计算会影响到RTO计算及影响某些拥塞算法运行结果；
RTO计算会涉及到超时重传定时器设置。

滑动窗口滑动窗口(sliding window)是数据传输时接收方通告窗口给发送方，然后发送方根据窗口决定一次发送多少数据的机制，本质是ARQ(Automatic Repeat Request, 停等协议)，滑动窗口一方面利用接收方确认报文反馈的窗口大小控制每次发包个数，另一方面根据接收方确认报文确认号判断数据帧重传，滑动窗口仅通过接收方反馈的信息进行流量控制，不会考虑网络带宽延迟等因素。
ARQ主要有连续ARQGo-Back-N和选择ARQSelective Repeat两种，TCP中使用Go-back-N，Selective Repeat作为可选实现。Go-back-N和Selective Repeat区别在于，Go-back-N一次发包只有一个定时器，中间出现丢包，则丢的包之后的所有包都需要重传，Selective Repeat一次发包需要和包个数一样的定时器数量，中间出现丢包则仅重传丢失的那个包，简单来说Go-back-N比较耗网络带宽，Selective Repeat比较耗计算资源。
两种ARQ滑动窗口发送过程可参考如下网站的动画：

https://www2.tkn.tu-berlin.de/teaching/rn/animations/gbn_sr/
TCP滑动机制原理可简述为：TCP发送方包含一个发送窗口，按序列号发送数据包，TCP接收方根据收到的包回复确认包，TCP发送包根据收到的确认包中通告窗口反馈来动态调节发送窗口大小、滑动窗口右移并发送后续的数据包。
如下tcpipguide网站TCP滑动窗口描述，TCP发送方发送缓存区分为4块区域:已发送已确认、已发送未确认、未发送接收方已准备好和未发送接收方未准备好，TCP接收方接收缓存区分为3块区域:已接收已确认、未接收被允许发送、未收到发生方可能未发送。

Linux内核4.x中滑动窗口代码示例，大体可以看出来和tcpipguid网站中描述一致：

/* ｕｐｄａｔｅ 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计算TCP流量控制中RTT及RTO计算是一个很重要的问题，ARQ中针对丢包都需要超时重传，超时的设置就会涉及到RTO，RTO设置过短(<2RTT)则可能导致不必要的重传(丢的包可能在传输马上能到)，超时重传时间设置过长则可能影响TCP通信效率(一直在等丢的包重传过来)，RTO计算需要基于RTT，RTT计算值直接影响RTO，不少拥塞算法也和RTT直接相关，TCP流端到端的RTT和RTO都不是一个固定的值，都是一段时间网络中端到端的估算值，随着时间和网络的变化而变化。