TCP滑动窗口原理终于清楚了!

这篇具有很好参考价值的文章主要介绍了TCP滑动窗口原理终于清楚了!。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

我们在学习计算机网络的时候,遇到很多知识点。即便是背的滚瓜烂熟,让你去辨别知识点背后的深层逻辑的时候,可能就手足无措了。

比如小邱去面A公司的时候就被问到:

TCP滑动窗口原理终于清楚了!

事实上,这个问题很大程度弥补我计算机网络的“漏洞”。正应了那句古话“有心栽花花不开,无心插柳柳成荫”。

话不多说,上热菜勒!

一、TCP的优势

TCP经过多年厮杀,早已确立了坚实的江湖基础。其武功号称“面向连接,可靠,基于字节流的传输层协议”,与其一并称霸传输界武林的还有UDP协议,不过在TCP面前,稍逊“亿”筹。

所谓可靠,就是确保数据准确的,不重复,无延迟的到达目的地;

TCP的武林秘籍总结如下:

①数据分片:在发送端对用户数据进行分片,在接收端进行重组,由TCP确定分片的大小并控制分片和重组;

②到达确认:接收端接收到分片数据时,根据分片数据序号向发送端发送一个确认;

③超时重发:发送方在发送分片时启动超时定时器,如果在定时器超时之后没有收到相应的确认,重发分片;

④滑动窗口:TCP连接每一方的接收缓冲空间大小都固定,接收端只允许另一端发送接收端缓冲区所能接纳的数据,TCP在滑动窗口的基础上提供流量控制,防止较快主机致使较慢主机的缓冲区溢出;

⑤失序处理:作为IP数据报来传输的TCP分片到达时可能会失序,TCP将对收到的数据进行重新排序,将收到的数据以正确的顺序交给应用层;

⑥重复处理:作为IP数据报来传输的TCP分片会发生重复,TCP的接收端必须丢弃重复的数据;

⑦数据校验:TCP将保持它首部和数据的检验和,这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到分片的检验和有差错,TCP将丢弃这个分片,并不确认收到此报文段导致对端超时并重发。

其中很重要的一环就是“滑动窗口”,下面我们重点关注一下。

二、滑动窗口的引入

IP 层协议属于不可靠的协议,IP 层并不关系数据是否发送到了对端,在复杂的网络中,由于各种各样的原因,接收到数据包的顺序不一定和发送的顺序相同,这就是乱序问题。这种情况下,有必要为每个包定义一个序号seq,每个包用一个校验和确保数据完整性。

然后发送方不能不管接收方的承受能力,只顾着发。举个栗子,一个高速公路如果没有收费站,那么车辆就会一拥而入,此时不凑巧,发生了追尾事故,导致公路拥塞,如果不控制公路的进入车辆,那么整个高速公路都会变成“露天停车场”。说到这里你可能就明白了,TCP需要这样的“收费站”,而这个收费站就是“滑动窗口”。

TCP滑动窗口原理终于清楚了!

然后,平时在高速上的时候,细心的你注意到了:除了入口有个收费站,出口也有个收费站。TCP也是一样的,除了入口有发送方滑动窗口,出口处也设立有接收方滑动窗口。

收费站除了限制流速以外还有什么作用鸭?是不是要收费呢,毕竟这是国家修的路,不能白走是吧。

对于发送方滑动窗口(入口收费站),我们把数据包看成车辆,枚举它们的状态:

  1. 还未进入入口收费站车辆。对应的是下图Not Sent,Recipient Not Ready to Receive。这些数据属于发送端未发送,同时接收端也未准备接收的

  2. 进入收费站,但未进入高速路。对应的是图中的Not Sent,Recipient Ready to Receive。这部分数据是发送端未发送但已经告知接收方的,这部分其实已经在窗口中(发送端缓存)了,等待发送。

  3. 在高速公路上行驶的车辆。对应的是Send But Not Yet Acknowledged。这部分数据称为发送但没有被确认,数据被发送出去,没有收到接收端的 ACK,认为并没有完成发送,这个属于窗口内的数据

  4. 到达出口收费站的车辆。对应的是Sent and Acknowledged。这些数据表示已经发送成功并已经被确认的数据,这些数据已经离开窗口了。

TCP滑动窗口原理终于清楚了!

对于接收方滑动窗口(出口收费站),类似发送端,接收端的数据有 4 个分类,因为接收端并不需要等待 ACK 所以它没有类似的接收并确认了的分类,情况如下

  1. 车辆还未到达出口收费站。对应Not Received:有空位,还没有被接收的数据

  2. 车辆到达出口收费站,但未完成缴费。对应Received Not ACK: 已经接收并,但是还没有回复 ACK,这些包可能输属于 Delay ACK 的范畴了。

  3. 车辆完成缴费,但不知道走哪条路。对应Received and ACK Not Send to Process:这部分数据属于接收了数据但是还没有被上层的应用程序接收,也是被缓存在窗口内。

  4. 车辆离开出口收费站。对应Received and ACK Send to Process。离开了窗口缓存。

这样讲是不是就很明白了,下面给出滑动窗口的正式定义。

TCP滑动窗口原理终于清楚了!

  1. Left edge和Right edge分别表示滑动窗口的左边界和右边界。

  2. Usable Window:表示窗口的缓冲区。

  3. Send Window :发送窗口, 这部分值是有接收方在三次握手的时候进行设置的,同时在接收过程中也不断的通告可以发送的窗口大小,来进行适应。

  4. Window Already Sent: 已经发送的数据,但是并没有收到 ACK。

滑动窗口所谓的“滑动”,并不是说窗口在动,而是因为数据在不断进入和离开窗口,也就是说真正“动”的是数据,下面一幅图就表示了这点:

TCP滑动窗口原理终于清楚了!

滑动窗口在TCP首部中的位置如下图所示:

TCP滑动窗口原理终于清楚了!

RFC793对它的解释是"发送方希望接收到的以ACK标志开头的数据字节数"。滑动窗口是跟ACK一起的,因此ACK标志必须置为1,同时指定窗口大小。可以看到,滑动窗口大小通过16个bit来描述,所以变化范围0-65535(这个范围其实是可以缩放的)。

Window:  16 bits
   The number of data octets beginning with the one indicated in the
   acknowledgment field which the sender of this segment is willing to
   accept.

三、滑动窗口的工作原理

首先,TCP不是每个报文段都会返回TCP的,可能对多个报文返回一个ACK

我们再举一个栗子,制造某机器需要A,B,C三种零件,并且组装顺序A→B→C,某天不凑巧,B,C零件先到,这个时候往往把A的位置预留出来,等待A到达之后,再进行组装;如果A丢失了,那么B,C也丧失作用,被丢弃了。

在TCP中也有这样一个“预留的地方”,我们称之为“空洞(hole)”。假设我们依次发送3个报文(A,B,C)。如果B,C报文先到,那么先把A的位置预留出来,只有A报文到达了,接收端才返回一个ACK(不是3个)进行确认

在介绍滑动窗口原理之前,我们先讲解一个重要概念——MSS (Max Segment Size,最大段大小),数据被TCP分割成合适发送的数据块,称为段(Segment)。注意:这里说的段(Segment)不包括协议首部,只包含数据

与MSS最为相关的一个参数就是网络设备接口的MTU(Max Transfer Unit)。

我们完整讲一下滑动窗口的原理:

  1. 有一组数据通过TCP传输,TCP先 将其分成若干段,假设有四个段seg1,seg2,seg3,seg4,依次发送出去,此时假设接收端接收到了 seg1 seg2 seg4;

  2. 此时接收端的行为是回复一个 ACK 包说明已经接收到,并将 seg4 进行缓存(保证顺序,产生一个保存 seg3 的 hole);

  3. 发送端收到 ACK 之后,就会将对应的数据包变为已确认状态,这个时候窗口向右移动;

  4. 假设接收端通告的 Window Size 仍然不变,此时窗口右移,产生一些新的空位,这些是接收端允许发送的范畴;

  5. 对于丢失的 seg3,如果超过一定时间,TCP 就会重新传送(重传机制),重传成功会 seg3 seg4 一块被确认,不成功,seg4 也将被丢弃。

前面我们讲到,这个滑动窗口是可以动态调整的,下面讲一下滑动窗口动态调整的原理。

四、滑动窗口的动态调整原理

这一部分可能需要阅读Linux源码。有兴趣的读者可以来肝哦。

内核版本: linux3.2.12

文件目录:linux-3.2.12\include\linux\tcp.h

struct tcp_sock {    ...    /* 最早接收但未确认的段的序号,即当前接收窗口的左端*/    u32 rcv_wup; /* rcv_nxt on last window update sent */    u16 advmss; /* Advertised MSS. 本端能接收的MSS上限,建立连接时用来通告对端*/    u32 rcv_ssthresh; /* Current window clamp. 当前接收窗口大小的阈值*/    u32 rcv_wnd; /* Current receiver window,当前的接收窗口大小*/    u32 window_clamp; /* 接收窗口的最大值,这个值也会动态调整*/    ...    struct tcp_options_received rx_opt; /* 接收选项 */     u32  mss_cache;  /* Cached effective mss, not including SACKS */}
struct tcp_options_received {    ...        snd_wscale : 4, /* Window scaling received from sender, 对端接收窗口扩大因子 */        rcv_wscale : 4; /* Window scaling to send to receiver, 本端接收窗口扩大因子 */    u16 user_mss; /* mss requested by user in ioctl */    u16 mss_clamp; /* Maximal mss, negotiated at connection setup,对端的最大mss */}
struct tcp_options_received {/*  PAWS/RTTM data  */  long  ts_recent_stamp;/* Time we stored ts_recent (for aging) */  u32  ts_recent;  /* Time stamp to echo next    */  u32  rcv_tsval;  /* Time stamp value               */  u32  rcv_tsecr;  /* Time stamp echo reply          */  u16   saw_tstamp : 1,  /* Saw TIMESTAMP on last packet    */    tstamp_ok : 1,  /* TIMESTAMP seen on SYN packet    */    dsack : 1,  /* D-SACK is scheduled      */    wscale_ok : 1,  /* Wscale seen on SYN packet    */    sack_ok : 4,  /* SACK seen on SYN packet    */    snd_wscale : 4,  /* Window scaling received from sender  */    rcv_wscale : 4;  /* Window scaling to send to receiver  */  u8  cookie_plus:6,  /* bytes in authenticator/cookie option  */    cookie_out_never:1,    cookie_in_always:1;  u8  num_sacks;  /* Number of SACK blocks    */  u16  user_mss;  /* mss requested by user in ioctl  */  u16  mss_clamp;  /* Maximal mss, negotiated at connection setup */};

tcp_sock表示的是TCP结构体。我们只关注里面最重要的几个成员:

(1)tp->advmss

这里的adv是advertised告知的意思。本端在建立连接时使用的MSS,是本端能接收的MSS上限。这是从路由缓存中获得的(dst->metrics[RTAX_ADVMSS - 1]),一般是1460。

(2)tp->rx_opt.mss_clamp

对端的能接收的MSS上限,其值为tcp_sock->rx_opt.user_mss和 对端在建立连接时通告的MSS的较小值。

(3)tp->mss_cache

本端当前有效的发送MSS,不包括SACKS。显然不能超过对端接收的上限,即tp->mss_cache <= tp->mss_clamp

(4)tcp_sock->rx_opt.user_mss

用户通过TCP_MAXSEG选项设置的MSS上限,用于决定本端和对端的接收MSS上限。

文件目录:linux-3.2.12\include\net\sock.h

struct sock {    ...    struct sk_buff_head sk_receive_queue;    /* 表示接收队列sk_receive_queue中所有段的数据总长度*/#define sk_rmem_alloc sk_backlog.rmem_alloc     int sk_rcvbuf; /* 接收缓冲区长度的上限*/    int sk_sndbuf; /* 发送缓冲区长度的上限*/     struct sk_buff_head sk_write_queue;    ...}

主要对接收和发送缓冲区进行定义。

接收缓存sk->sk_rcvbuf分为两部分:
(1) network buffer,一般占3/4,这部分是协议能够使用的。
(2)application buffer,一般占1/4。
我们在计算连接可用接收缓存的时候,并不会使用整个的sk_rcvbuf,防止应用程序读取数据的速度比网络数据包到达的速度慢时,接收缓存被耗尽的情况。

下面是根据RFC793和RFC1122定义的窗口更新参数。

TCP滑动窗口原理终于清楚了!

我们先从初始情况开始进行分析。

/* Determine a window scaling and initial window to offer. * Based on the assumption that the given amount of space will be offered. * Store the results in the tp structure. * NOTE: for smooth operation initial space offering should be a multiple of mss * if possible. We assume here that mss >= 1. This MUST be enforced by all calllers. */void tcp_select_initial_window (int __space, __u32 mss, __u32 *rcv_wnd, __u32 *window_clamp,                                int wscale_ok, __u8 *rcv_wscale, __u32 init_rcv_wnd){    unsigned int space = (__space < 0 ? 0 : __space); /* 接收缓存不能为负*/     /* If no clamp set the clamp to the max possible scaled window。     * 如果接收窗口上限的初始值为0,则把它设成最大。     */    if (*window_clamp == 0)        (*window_clamp) = (65535 << 14); /*这是接收窗口的最大上限*/     /* 接收窗口不能超过它的上限 */    space = min(*window_clamp, space);      /* Quantize space offering to a multiple of mss if possible.     * 接收窗口大小最好是mss的整数倍。     */    if (space > mss)        space = (space / mss) * mss; /* 让space为mss的整数倍*/     /* NOTE: offering an initial window larger than 32767 will break some     * buggy TCP stacks. If the admin tells us it is likely we could be speaking     * with such a buggy stack we will truncate our initial window offering to     * 32K - 1 unless the remote has sent us a window scaling option, which     * we interpret as a sign the remote TCP is not misinterpreting the window     * field as a signed quantity.     */    /* 当协议使用有符号的接收窗口时,则接收窗口大小不能超过32767*/    if (sysctl_tcp_workaround_signed_windows)        (*rcv_wnd) = min(space, MAX_TCP_WINDOW);    esle        (*rcv_wnd) = space;     (*rcv_wscale) = 0;    /* 计算接收窗口扩大因子rcv_wscale,需要多大才能表示本连接的最大接收窗口大小?*/    if (wscale_ok) {        /* Set window scaling on max possible window         * See RFC1323 for an explanation of the limit to 14         * tcp_rmem[2]为接收缓冲区长度上限的最大值,用于调整sk_rcvbuf。          * rmem_max为系统接收窗口的最大大小。          */        space = max_t(u32, sysctl_tcp_rmem[2], sysctl_rmem_max);        space = min_t(u32, space, *window_clamp); /*受限于具体连接*/         while (space > 65535 && (*rcv_wscale) < 14) {            space >>= 1;            (*rcv_wscale)++;        }   }     /* Set initial window to a value enough for senders starting with initial     * congestion window of TCP_DEFAULT_INIT_RCVWND. Place a limit on the      * initial window when mss is larger than 1460.     *     * 接收窗口的初始值在这里确定,一般是10个数据段大小左右。     */    if (mss > (1 << *rcv_wscale)) {        int init_cwnd = TCP_DEFAULT_INIT_RCVWND; /* 10 */        if (mss > 1460)            init_cwnd = max_t(u32, 1460 * TCP_DEFAULT_INIT_RCVWND) / mss, 2);                /* when initializing use the value from init_rcv_wnd rather than the          * default from above.         * 决定初始接收窗口时,先考虑路由缓存中的,如果没有,再考虑系统默认的。          */        if (init_rcv_wnd) /* 如果路由缓存中初始接收窗口大小不为0*/            *rcv_wnd = min(*rcv_wnd, init_rcv_wnd * mss);        else             *rcv_wnd = min(*rcv_wnd, init_cwnd *mss);    }     /* Set the clamp no higher than max representable value */    (*window_clamp) = min(65535 << (*rcv_wscale), *window_clamp);}

初始的接收窗口的取值(mss的整数倍):
(1)先考虑路由缓存中的RTAX_INITRWND
(2)在考虑系统默认的TCP_DEFAULT_INIT_RCVWND(10)
(3)最后考虑min(3/4 * sk_rcvbuf, window_clamp),如果这个值很低.

接下来我们可以看到,接收窗口的大小主要取决于剩余的接收缓存,以及接收窗口当前阈值。

决定接收窗口大小的函数tcp_select_window()tcp_transmit_skb()中调用,也就是说每次我们要发送数据包时,都要使用tcp_select_window()来决定通告的接收窗口大小。

static int tcp_transmit_skb (struct sock *sk, struct sk_buff *skb, int clone_it,                              gfp_t gfp_mask){    const struct inet_connection_sock *icsk = inet_csk(sk);    struct inet_sock *inet;    struct tcp_sock *tp;    struct tcp_skb_cb *tcb;    struct tcphdr *th;    ...    /* Build TCP header and checksum it,以下是TCP头的赋值*/    th = tcp_hdr(skb); /* skb->transport_header */    th->source = inet->inet_sport;    th->dest = inet->inet_dport;    th->seq = htonl(tcb->seq);    th->ack_seq = htonl(tp->rcv_nxt);    /* 这个语句可以看出C语言的强大*/    *(((__be16 *) th) + 6) = htons(((tcp_header_size >> 2) << 12) | tcb->tcp_flags);        if (unlikely(tcb->tcp_flags & TCPHDR_SYN)) {        /* RFC1323: The window in SYN & SYN/ACK segments in never scaled.         * 从这里我们可以看到,在三次握手阶段,接收窗口并没有按扩大因子缩放。          */        th->window = htons(min(tp->rcv_wnd, 65535U));     } else {        th->window = htons(tcp_select_window(sk)); /* 更新接收窗口的大小*/    }    th->check = 0;    th->urg_ptr = 0;    ...}

这里有几个函数,大家可能没见过,所以稍微解释一下:

网络字节顺序NBO(Network Byte Order)

按从高到低的顺序存储,在网络上使用同一的网络字节顺序,可避免兼容性问题;

主机字节顺序HBO(Host Byte Order)

不同的机器HBO不相同,与CPU的设计有关,数据的顺序是由CPU决定的,而与操作系统无关;

如Intel x86结构下,short型数0x1234表示为34 12,int型数0x12345678表示为78 56 34 12;

如IBM power PC结构下,short型数0x1234表示为 12 34,int型数0x12345678表示为 12 34 56 78.

由于这个原因,不同体系结构的机器之间不能直接通信,所以要转换成一种约定的顺序,也就是网络字节顺序,其实就是如同power pc那样的顺序。

ntohs =net to host short int 16位
htons=host to net short int 16位
ntohl =net to host long int 32位
htonl=host to net long int 32位

接下来看一下tcp_select_window(),这个是核心函数。

static u16 tcp_select_window(struct sock *sk){    struct tcp_sock *tp = tcp_sk(sk);     u32 cur_win = tcp_receive_window(tp); /* 当前接收窗口的剩余大小*/    u32 new_win = __tcp_select_window(sk); /*根据剩余的接收缓存,计算新的接收窗口的大小 */     /* Never shrink the offered window,不允许缩小已分配的接收窗口*/    if (new_win < cur_win) {        /* Danger Will Robinson!         * Don't update rcv_wup/rcv_wnd here or else         * we will not be able to advertise a zero window in time. --DaveM         * Relax Will Robinson.         */        new_win = ALIGN(cur_win, 1 << tp->rx_opt.rcv_wscale);    }     /* 更新接收窗口大小。个人觉得这句代码应该后移,因为此时接收窗口的大小还未最终确定!*/    tp->rcv_wnd = new_win;    tp->rcv_wup = tp->rcv_nxt; /* 更新接收窗口的左边界,把未确认的数据累积确认*/     /* 确保接收窗口大小不超过规定的最大值。      * Make sure we do not exceed the maximum possible scaled window.     */    if (! tp->rx_opt.rcv_wscale && sysctl_tcp_workaround_signed_windows)        /* 不能超过32767,因为一些奇葩协议采用有符号的接收窗口大小*/        new_win = min(new_win, MAX_TCP_WINDOW);      else        new_win = min(new_win, (65535U << tp->rx_opt.rcv_wscale));     /* RFC1323 scaling applied. 按比例因子缩小接收窗口,这样最多能表示30位*/    new_win >>= tp->rx_opt.rcv_wscale;     /* If we advertise zero window, disable fast path. */    if (new_win == 0)        tp->pred_flags = 0;     return new_win; /* 返回最终的接收窗口大小*/}

每次发送一个TCP数据段,都要构建TCP首部,这时会调用tcp_select_window选择接收窗口大小。窗口大小选择的基本算法:

  1. 计算当前接收窗口的剩余大小cur_win

  2. 计算新的接收窗口大小new_win,这个值为剩余接收缓存的3/4,且不能超过rcv_ssthresh

  3. cur_winnew_win中值较大者作为接收窗口大小。

计算当前接收窗口的剩余大小cur_win。

/*  * Compute the actual receive window we are currently advertising. * rcv_nxt can be after the window if our peer push more data than * the offered window. */static inline u32 tcp_receive_window (const struct tcp_sock *tp){    s32 win = tp->rcv_wup + tp->rcv_wnd - tp->rcv_nxt;     if (win < 0)        win = 0;     return (u32) win;}

__tcp_select_window计算新的接收窗口大小new_win,这个是关键函数,我们将看到rcv_ssthresh所起的作用。

/*  * calculate the new window to be advertised. */u32 __tcp_select_window(struct sock *sk){    struct inet_connection_sock *icsk = inet_csk(sk);    struct tcp_sock *tp = tcp_sk(sk);     /* MSS for the peer's data. Previous versions used mss_clamp here.     * I don't know if the value based on our guesses of peer's MSS is better     * for the performance. It's more correct but may be worse for the performance     * because of rcv_mss fluctuations. —— SAW 1998/11/1     */    int mss = icsk->icsk_ack.rcv_mss;/*这个是估计目前对端有效的发送mss,而不是最大的*/      int free_space = tcp_space(sk); /* 剩余接收缓存的3/4 */    int full_space = min_t(int, tp->window_clamp, tcp_full_space(sk)); /* 总的接收缓存 */    int window;     if (mss > full_space)        mss = full_space; /* 减小mss,因为接收缓存太小了*/     /* receive buffer is half full,接收缓存使用一半以上时要小心了 */    if (free_space < (full_space >> 1)) {        icsk->icsk_ack.quick = 0; /* 可以快速发送ACK段的数量置零*/         if (tcp_memory_pressure)/*有内存压力时,把接收窗口限制在5840字节以下*/            tp->rcv_ssthresh = min(tp->rcv_ssthresh, 4U * tp->advmss);         if (free_space < mss) /* 剩余接收缓存不足以接收mss的数据*/            return 0;    }     if (free_space > tp->rcv_ssthresh)        /* 看!不能超过当前接收窗口阈值,这可以达接收窗口平滑增长的效果*/        free_space = tp->rcv_ssthresh;       /* Don't do rounding if we are using window scaling, since the scaled window will     * not line up with the MSS boundary anyway.     */    window = tp->rcv_wnd;    if (tp->rx_opt.rcv_wscale) { /* 接收窗口扩大因子不为零*/        window = free_space;         /* Advertise enough space so that it won't get scaled away.         * Import case: prevent zero window announcement if 1 << rcv_wscale > mss.         * 防止四舍五入造通告的接收窗口偏小。          */        if (((window >> tp->rx_opt.rcv_wscale) << tp->rx_opt.rcv_wscale) != window)            window =(((window >> tp->rx_opt.rcv_wscale) + 1) << tp->rx_opt.rcv_wscale);     } else {        /* Get the largest window that is a nice multiple of mss.         * Window clamp already applied above.         * If our current window offering is within 1 mss of the free space we just keep it.         * This prevents the divide and multiply from happening most of the time.         * We also don't do any window rounding when the free space is too small.         */        /* 截取free_space中整数个mss,如果rcv_wnd和free_space的差距在一个mss以上*/        if (window <= free_space - mss || window > free_space)             window = (free_space / mss) * mss;        /* 如果free space过小,则直接取free space值*/        else if (mss = full_space && free_space > window + (full_space >> 1))            window = free_space;        /* 当free_space -mss < window < free_space时,直接使用rcv_wnd,不做修改*/    }         return window;}
/* 剩余接收缓存的3/4。 * Note: caller must be prepared to deal with negative returns. */static inline int tcp_space (const struct sock *sk){    return tcp_win_from_space(sk->sk_rcvbuf - atomic_read(&sk->sk_rmem_alloc));} static inline int tcp_win_from_space(int space){    return sysctl_tcp_adv_win_scale <= 0 ? (space >> (-sysctl_tcp_adv_win_scale)) :        space - (space >> sysctl_tcp_adv_win_scale);} /* 最大的接收缓存的3/4 */static inline int tcp_full_space(const struct sock *sk){    return tcp_win_from_space(sk->sk_rcvbuf);}

总体来说,新的接收窗口大小值为:剩余接收缓存的3/4,但不能超过接收缓存的阈值。

小结

接收窗口的调整算法主要涉及:

(1)window_clampsk_rcvbuf的调整。

(2)rcv_ssthresh接收窗口当前阈值的动态调整,一般增长2*advmss

(3)rcv_wnd接收窗口的动态调整,一般为min(3/4 free space in sk_rcvbuf, rcv_ssthresh)

如果剩余的接收缓存够大,rcv_wnd受限于rcv_ssthresh。这个时候每收到一个大的数据包,rcv_wnd就增大2920字节(由于缩放原因这个值可能波动)。这就像慢启动一样,接收窗口指数增长。

接收窗口当然不能无限制增长,当它增长到一定大小时,就会受到一系列因素的限制,比如window_clampsk_rcvbuf,或者剩余接收缓存区大小。

当应用程序读取接收缓冲区数据不够快时,或者发生了丢包时,接收窗口会变小,这主要受限于剩余的接收缓存的大小。

五、实验环节

这里要给大家推荐一个超好用的网络协议分析工具,wireshark。网上可以免费下载。

我选择的是无线网卡WLAN

TCP滑动窗口原理终于清楚了!

这里使用wireshark抓取baidu.com的TCP报文。可以看到,No.36是本机对服务器之前发送数据(No.31)的一个ACK确认(ACK的Flag标记成1),同时声明窗口大小(window size)为1040。

紧接着是No.37对No.30发送一个ACK确认,受系统进程资源的影响,这时窗口的大小动态调整为948。

TCP滑动窗口原理终于清楚了!

可以看到滑动窗口确实是会自动调整的。

六、总结

本期我们认真,全面的探讨了TCP滑动窗口的原理,从基本定义到源码分析应有尽有。一般而言,准备面试的话不需要到源码那一步的。文章来源地址https://www.toymoban.com/news/detail-411502.html

到了这里,关于TCP滑动窗口原理终于清楚了!的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • TCP重传机制、滑动窗口、拥塞控制

    一、总述 TCP,Transmission Control Protocol,是一个面向连接、基于 流式传输 的 可靠传输 协议,考虑到的内容很多,比如数据包的丢失、损坏、分片和乱序等,TCP协议通过多种不同的机制来实现可靠传输。今天,重点分析 重传机制 、 滑动窗口 ,以及 拥塞控制 。 二、重传机制

    2024年04月10日
    浏览(50)
  • TCP重传, 滑动窗口, 流量控制, 拥塞控制

    1. 重传机制 TCP 实现可靠传输的方式之一,是通过 序列号与确认应答 。 在 TCP 中,当发送端的数据到达接收主机时,接收端主机会返回一个确认应答消息,表示已收到消息。 针对数据可能丢失的情况, 用重传机制来解决, 四种常见的重传机制: 超时重传 快速重传 SACK D-SACK 1.

    2024年01月22日
    浏览(47)
  • TCP的滑动窗口协议有什么用?

    滑动窗口协议: TCP协议的使用 维持发送方/接收方缓冲区 缓冲区是 用来解决网络之间数据不可靠的问题,例如丢包,重复包,出错,乱序 在TCP协议中,发送方和接受方通过各自维护自己的缓冲区。通过商定包的重传机制等一系列操作,来解决不可靠的问题。 提出问题:在我

    2024年02月10日
    浏览(34)
  • TCP滑动窗口、流量控制及拥塞控制详解

    TCP虽然是面向字节流的,但是TCP传输的单元确实报文段。一个TCP报文段分为首部和数据部分。TCP首部前20个字节是固定的,后面有4N个字节是可选的。因此,TCP首部最小字节数是20个字节。 下面我们看下一TCP首部中几个重要的字段: 源端口 和 目的端口 各占两个字节 序号 ,占

    2024年02月02日
    浏览(36)
  • TCP 滑动窗口停等与多路径传输

    滑动窗口停等与多路径乱序传输天然不容。 多路径传输,每条路径对数据的接收是平等的,因此乱序是自然的,如果 receiver 从某条路径收到了不连续数据,回sack 吗?如果不回,回什么?如果回,sender 会频繁误解,切换拥塞状态机。 而 mptcp 则将简单问题复杂化了,它明显是

    2024年02月06日
    浏览(28)
  • 网路原理-传输层UDP,TCP/IP(确认应答,超时重传,连接管理,三次握手,四次挥手,状态转换,流量控制,滑动窗口,拥塞控制,延时应答,捎带应答,异常情况,面向字节流)-网络层(IP协议,地址管理)

    本节重点 • 理解传输层的作⽤,深⼊理解TCP的各项特性和机制 • 对整个TCP/IP协议有系统的理解 • 对TCP/IP协议体系下的其他重要协议和技术有⼀定的了解 我们之前编写完了基本的 java socket ,要知道,我们之前所写的所有代码都在应⽤层,都是为了 完成某项业务,如翻译等。

    2024年04月15日
    浏览(55)
  • 网络编程(12): TCP重传、滑动窗口、流量控制、拥塞控制

    通过序列号和确认号确保可靠传输,当发送端发送数据给接收到,接收端会返回一个确认号,表示收到消息了 超时重传 :没有在指定时间内收到 ACK 报文 超时重传的两种可能: 数据包丢失 、 确认包丢失 超时重传时间 RTO : RTO 较大:重发就变慢了,丢包之后需要半天才能重

    2024年02月12日
    浏览(52)
  • TCP通讯(三次握手、四次挥手;滑动窗口;TCP状态转换;端口复用;TCP心跳检测机制)

     前言:建议看着图片,根据文字描述走一遍TCP通讯过程,加深理解。 目录 TCP通信时序: 1)建立连接(三次握手)的过程: 2)数据传输的过程: 3)关闭连接(四次挥手)的过程: 滑动窗口 (TCP流量控制): TCP状态转换: 半关闭: 2MSL: 程序设计中的问题: 端口复用:

    2024年02月03日
    浏览(85)
  • 【网络】传输层——TCP(滑动窗口&&流量控制&&拥塞控制&&延迟应答&&捎带应答)

    🐱作者:一只大喵咪1201 🐱专栏:《网络》 🔥格言: 你只管努力,剩下的交给时间! 上篇文章对TCP可靠性机制讲解了一部分,这篇文章接着继续讲解。 在上篇文章中,本喵讲解了TCP的确认应答机制: 如上图所示,主机A每发送一个数据段,主机B都要给一个 ACK 确认应答,

    2024年02月12日
    浏览(55)
  • sentinel---滑动窗口的实现原理

    sentinel有多种规则,包括:降级、限流、热点等等规则,这些规则均会涉及到时间因素,既在单位时间内的请求量满足各种条件之后的各种动作。 这里我们一起来探针一下sentinel中滑动窗口的实现  如上是一个滑动窗口的示意图。 这里先不说sentinel中滑动窗口的实现代码,咱

    2024年02月14日
    浏览(43)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包