精华内容
下载资源
问答
  • tcp窗口问题mark

    2020-06-28 15:00:44
    slide_windows(滑动窗口大小) ---接收端告诉发送端自己的可接受buffer大小 #两者取较小值作为发送速率限制 在正常的linux机器中,cwnd初始值=10,ssthresh初始值=TCP_INFINITE_SSTHRESH0x7fffffff 在慢启动...

    决定单连接tcp速度的常见机制是

    ssthresh(tcp 拥塞控制门限)

    cwnd(tcp拥塞窗口) ---- 发送端根据对网络质量的测量决定自己发送的报文大小

    slide_windows(滑动窗口大小) ---接收端告诉发送端自己的可接受buffer大小

    #两者取较小值作为发送速率限制

     

    在正常的linux机器中,cwnd初始值=10,ssthresh初始值=TCP_INFINITE_SSTHRESH 0x7fffffff

    在慢启动阶段, cwnd每一个rtt 会增大一倍。

    报文接收端收到out-of-order的分片时会回复duplicated ack,

    发送端收到三次相同的序号的dup ack时,进入拥塞避免。(证明有一个报文对端没有收到)

    此时 ssthresh = cwnd/2  cwnd=ssthresh

     

    有一种场景是:当tcp_metrics缓存了前一次session的ssthresh,则后续使用到这个IP的tcp管道就会使用之前那个session的ssthresh(可能是一个很小的值,例如300)

    ip tcp_metrics show

     

    另一种场景是:在发送端/接收端:人为改小了滑动窗:

    https://www.cnblogs.com/zengkefu/p/5749009.html

     

     

    ss -i -o 可以查看tcp 当前连接的参数

    https://www.cyberciti.biz/files/ss.html

     

    另一个监控工具是阿里tsar:

    可以查看历史监控丢包率

     

     

    https://www.cnblogs.com/zengkefu/p/5749009.html

    展开全文
  • TCP的一端一直接收数据,但是应用层没有及时读取的话,数据一直在TCP模块中缓存,最终受限于接收缓存的大小,window size会变为0,此时我们称呼这个接收窗口为零窗(zero window),对端也不能在发送更多的数据。...

    一、简介

        我们之前介绍过,TCP报文中的window size表示发出这个报文的一端准备多少bytes的数据,当TCP的一端一直接收数据,但是应用层没有及时读取的话,数据一直在TCP模块中缓存,最终受限于接收缓存的大小,window size会变为0,此时我们称呼这个接收窗口为零窗(zero window),对端也不能在发送更多的数据。如果随后本端应用层从TCP接收缓存中读取了足够数据,TCP模块有了足够的新的接收缓存的时候,就会发送一个TCP报文,并带有一个有效非零的Window size来指示对端自己已经可以接收新数据了。这个带有有效Window size的报文我们称为窗口更新(window update)报文。窗口更新一般就是一个普通的ACK报文,并不会带有有效的数据(pure ACK),ACK报文不消耗系列号,如果发生丢失并不会进行重传。因此TCP需要处理window update消息丢失的场景。
    
        如果窗口更新报文发生丢失,那么接收端(这里的接收端是指window update消息的发送端)会等待发送端发送新的数据,而发送端会等待接收window update消息来发送新的数据,这种场景下,两端互相等待对方,就会产生一种deadlock(还记得Nagle算法和延迟ACK同时生效的时候也会产生类似的deadlock吧)。为了阻止这种死锁一直等待下去,TCP的发送端会使用一个persist timer定时器来定时查询接收端的window size是否增长,每当这个定时器超时的时候,发送端就会发送window probes报文。接收端在接收到window probe消息的时候会提供一个带有window size的ACK报文。RFC1122建议初始window probe定时器定时时间为RTO,随后进行window probe 的时候应该进行指数回退,最大指数回退次数为tcp_retries2,如果此时还没收到有效的window size,则会一直进行window probe过程(我们之前通过示例介绍过RTO超时最后会释放连接,这个是与window probe的重要区别)。发送端。window probe报文中可以包含1byte的数据也可能不包含数据。当window probe包含数据的时候,接收端可以选择接收包含的数据也可以选择不接受包含的数据。关于persist timer,我们前面在介绍cork算法的时候就接触过了。
    
        另外在下面的示例中我们将会看到,linux上发出的window probe消息是不带有有效数据的,而且window probe的系列号位于snd_nxt的前面,linux接收到这种报文的时候会认定这种报文为无效的系列号。对于这种类型的报文回复ACK时候受到参数tcp_invalid_ratelimit控制,这个参数控制了TCP对于这类系列号无效的报文的ACK回复速率,例如下面示例中我们设置tcp_invalid_ratelimit=1200,含义就是说linux对于这类无效报文的ACK回复间隔最小为1200ms,只要间隔大于1200ms,linux就会立即回复一个dup ACK报文,并不受我们之前介绍的延迟ACK策略的影响(延迟ACK一般是针对有效数据来说的)。
    

    二、wireshark示例

    1、综合示例

    我们设置tcp_retries2=6,tcp_invalid_ratelimit=1200,通过socket选项SO_RCVBUF设置server端和client端的window size如下图所示,通过这个示例我们还会进一步说明一下之前介绍过的延迟ACK的处理。

    No1-No3:首先client和server端通过三次握手建立TCP连接,其中server端的window size为3000bytes

    接着client端执行一次write操作,一次write写入5000bytes的数据。

    No4:client端内核在从用户空间读取数据前会先获取当前的发送MSS,可以从图中看到,server端的接收窗口大小为3000bytes,但是MSS为65495bytes,显然不能按照这个MSS来发送,当出现这种情况的时候,linux的发送端(即本例中client端)会取对端最大接收窗口的一半1500bytes为发送mss。选定MSS后,接着linux内核会从client端尝试以1500bytes为单位来复制应用程序的数据(共5000bytes)然后发送出去,No4即对应client发出的第一个数据包。

    No5:server端在接收到client端的No4数据包的时候,会初始化quick ACK模式,此时client端的rcv_mss为1500,rcv_wnd为3000,rcv_wnd/(2*rcv_mss)=1,因此quick ACK计数器初始化为1,对No4报文执行quick ACK反馈No5后,quick ACK计数器变为0,关于延迟ACK的相关内容可以参考前面系列文章

    No6:接着client端内核继续从应用层复制1500bytes的数据并发送出去,此时client端一共发出了3000bytes的数据,而server端应用层一直没有读取TCP模块接收的数据。可以看到wireshark提示TCP Window Full信息。

    No7:No5数据包发出去后quick ACK计数器变为0,此时server端对No6数据包执行延迟ACK策略,定时时间为40ms。从wireshark可以看到No7与No6数据包实际间隔大约为38ms,这种定时误差问题是由于TCP模块的tick精度问题造成的,前面相关文章已经解释了,此处不再赘言。server端的3000bytes已经全部被占用了,此时server端只能回复Window size为0的ACK报文,通知client自己不再准备接收新数据了。可以看到wireshark提示了TCP zero Window提示信息。因为No7延迟了40ms回复ACK,所以当client收到这个报文的时候,client端的已经完全把应用层的数据复制到了内核中,之前一次write写入了5000bytes数据,已经发出了3000bytes的数据,此时client端内核中还剩余2000bytes的数据待发送。client端内核虽然在收到No7报文之前就已经准备好发送数据了,但是由于window size限制而没发送出去。此时收到No7的ACK后会再次尝试发送剩余的2000bytes的数据,但是同样由于window size限制而发送失败(如果client忽视window size的限制强制发送,server端会怎么办?我们后面文章在用示例来说明),发送失败后,linux会判断如果当前已经已经发出的还未收到ACK确认包的报文个数为0并且还有待发送数据的话就会启动persist timer定时器,定时时间为RTO(当前RTO大约为208ms)。

    No8:上面设置的persist timer定时器超时后,强制发送No8报文,注意No8报文的seq实际上比No7报文的ack number小1,而且Len=0,发送完这个报文后设置persist timer定时器,定时时间为上一次定时时间的2倍(大约为416ms)。wireshark对于No8报文的提示为TCP Keep-Alive,实际上这个报文的功能并不是Keep-Alive的功能,后面文章我们会介绍TCP Keep-Alive的。

    No9:接着我们看到server端对于No8报文立即回复了一个No9的ACK确认报文,这里起作用的并不是quick ACK模式,而是linux对于类似No8这种window probe报文会认为是无效的系列号,只要当前时间距离上次回复无效系列号报文的ACK确认包时间超过了tcp_invalid_ratelimit参数设置的时间,那么linux就会立即回复ACK确认报文,可以看到这个ACK报文window size仍然为0。

    No10:No8设置的定时器超时后,发出No10的window probe报文,并设置persist timer定时时间为4*RTO。

    可以看到server端收到No10报文后并没有立即回复ACK确认包,原因是No10和No9的间隔时间并没有超过1200ms的ACK发送间隔。

    No11:persist timer再次超时,发出No11报文,并重新设置persist timer的定时时间为8*RTO

    No12:server端在收到No11报文的时候,发现这个报文系列号无效,同时距离上一次回复无效系列号报文ACK确认包的时间(即No9的时间)已经超过了1200ms,因此立即回复ACK确认包。

    No13-No18:这几个报文重复前面的指数回退过程,server端判断无效系列号报文的ACK间隔超过1200ms后立即回复ACK确认包。

    No19:client在发送No19的window probe报文的时候发现,前面已经连续发送了No8、No10、No11、No13、No15、No17共6个window probe报文,已经达到了tcp_retries2的配置值,因此随后client端不在进行指数回退的过程,对persist timer定时器的定时间隔固定为2^6*RTO,大约为13.312ms。可以看到这里没有释放TCP连接,而在RTO重传指数回退过程中,当超过根据tcp_retries2计算的最大重传时间的时候就会释放TCP连接。

    No20-No30:client端持续进行window probe过程,这个与上面处理类似,不再多说
    在这里插入图片描述

    No31:接着在No30之后server端应用程序完全读取出TCP中的3000bytes的缓存数据,server端发送window update消息给client端,通知对端可以发送新的数据

    No32-No33:client端收到window update后,立即把剩余的2000byte分两个数据包发出

    No34:server端收到No32报文的时候,发现距离上一次收到有效数据的时间超过了一个RTO,因此进入quick ACK模式,设置quick ACK计数器为rcv_wnd/(2*rcv_mss)=1,立即回复ACK确认包报文后,quick ACK计数器减1变为0

    No35:server端在收到No33报文后,此时quick ACK计数器为0,进入延迟ACK处理,延迟ACK定时器超时后触发回复No35的ACK确认包。

    在这里插入图片描述

    补充说明:

    1、MSS相对与发送窗口折半的限制处理,请参考tcp_bound_to_half_wnd

    2、persist timer的定时器的初始启动__tcp_push_pending_frames,随后超时处理tcp_probe_timer

    3、linux对于示例中window probe消息的处理以及与参数tcp_invalid_ratelimit的关系,参考tcp_validate_incoming和tcp_sequence

    展开全文
  • 上次转载了一篇文章http://blog.csdn.net/jwybobo2007/archive/2010/12/30/6107419.aspx, 上面提到了TCP窗口大小与SO_RCVBUF选项之间的关系.但其实这篇文章描述的是有问题的.    在以Unix为核心的一些操作系统中...
    上次转载了一篇文章http://blog.csdn.net/jwybobo2007/archive/2010/12/30/6107419.aspx, 上面提到了TCP窗口大小与SO_RCVBUF选项之间的关系.但其实这篇文章描述的是有问题的.
    

     

      在以Unix为核心的一些操作系统中(不一定都是),SO_RCVBUF选项确实决定了TCP窗口的大小.你设置为多少窗口就为多少.但在Windows上确并非如此,通过一些抓包工具分析后,你会发现这两者并不是一一对应关系,MSDN的说明上确实也告知这一事实.

      如使用Windows2003作服务器时,它的SO_RCVBUF在默认不设置的条件下为8192,但是握手时告知的窗口大小为16384,而后在正式的数据通信中又马上通知对方自己的窗口大小为65535.

     

      上面谈的只是一个问题,还有关于设置SO_RCVBUF的时机描述也有问题.服务端在accept前设置了缓冲区后可以向下继承,同样客户端connect前设置缓冲区大小可以在握手时通告窗口(上面说的Windows下的窗口和该设置关系不大,但通过测试还是有一定关系的),但实际上是可以随时设置 的(主要指的是Windows下面,其它系统不一定可以),一但设置后,会随着下一个ACK包,或者普通数据包通告给对方最新的TCP窗口大小,需要注意的是此时窗口只能增大,不能减小,也就是说SO_RCVBUF设置的比上一次小的话,该值是不会作为新窗口大小通告给对方的。

    展开全文
  • TCP滑动窗口和SO_RCVBUF之间的关系

    千次阅读 2017-03-21 19:34:40
    在以Unix为核心的一些操作系统中,SO_RCVBUF选项决定了TCP窗口大小,你设置为多少窗口就为多少。对于客户端,SO_RCVBUF选项必须在connect之前设置;对于服务器,SO_RCVBUF选项必须在listen前设置。因为TCP的窗口...

    在以Unix为核心的一些操作系统中,SO_RCVBUF选项决定了TCP窗口的大小,你设置为多少窗口就为多少。对于客户端,SO_RCVBUF选项必须在connect之前设置;对于服务器,SO_RCVBUF选项必须在listen前设置。因为TCP的窗口规模选项是在建立连接时用SYN与对方互换得到的。
        在Windows上可以随时设置,一但设置后,会随着下一个ACK包,或者普通数据包通告给对方最新的TCP窗口大小,需要注意的是此时窗口只能增大,不能减小,也就是说SO_RCVBUF设置的比上一次小的话,该值是不会作为新窗口大小通告给对方的。
    #########################################################################

    一、TCP的滑动窗口大小实际上就是socket的接收缓冲区大小的字节数

    二、对于server端的socket一定要在listen之间设置缓冲区大小,因为,accept时新产生的socket会继承监听socket的缓冲区大小。对于client端的socket一定要在connet之前设置缓冲区大小,因为connet时需要进行三次握手过程,会通知对方自己的窗口大小。在connet之后再设置缓冲区,已经没有什么意义。

    三、由于缓冲区大小在TCP头部只有16位来表示,所以它的最大值是65536,但是对于一些情况来说需要使用更大的滑动窗口,这时候就要使用扩展的滑动窗口,如光纤高速通信网络,或者是卫星长连接网络,需要窗口尽可能的大。这时会使用扩展的32位的滑动窗口大小。

    四、滑动窗口听移动规则:

    1、窗口合拢:在收到对端数据后,自己确认了数据的正确性,这些数据会被存储到缓冲区,等待应用程序获取。但这时候因为已经确认了数据的正确性,需要向对方发送确认响应ACK,又因为这些数据还没有被应用进程取走,这时候便需要进行窗口合拢,缓冲区的窗口左边缘向右滑动。注意响应的ACK序号是对方发送数据包的序号,一个对方发送的序号,可能因为窗口张开会被响应(ACK)多次。

    2、窗口张开:窗口收缩后,应用进程一旦从缓冲区中取出数据,TCP的滑动窗口需要进行扩张,这时候窗口的右边缘向右扩张,实际上窗口这是一个环形缓冲区,窗口的右边缘扩张会使用原来被应用进程取走内容的缓冲区。在窗口进行扩张后,需要使用ACK通知对端,这时候ACK的序号依然是上次确认收到包的序号。

    3、窗口收缩,窗口的右边缘向左滑动,称为窗口收缩,Host Requirement RFC强烈建议不要这样做,但TCP必须能够在某一端产生这种情况时进行处理。

    展开全文
  • 是否使用初始值不超过32767的TCP窗口,默认值为0(不启用)。 在不启用窗口扩大因子选项时,通告窗口有16bit,最大值为65535。 有些很糟糕的协议实现采用有符号的窗口大小,所以最大值只能为32767。当然,这种协议并...
  • TCP窗口滑动 窗口滑动机制算是TCP最重要的一个机制。 窗口滑动机制,TCP维护一个窗口,来保证数据的可靠性,并且做流量控制,防止网络拥塞,合理的使用网络资源。 TCP发送端,通过接收方的通告,得到一个提供的窗口...
  • 在以Unix为核心的一些操作系统中,SO_RCVBUF选项决定了TCP窗口大小,你设置为多少窗口就为多少。对于客户端,SO_RCVBUF选项必须在connect之前设置;对于服务器,SO_RCVBUF选项必须在listen前设置。因为TCP的窗口...
  • tcp笔记

    万次阅读 2020-09-06 00:10:03
    【1】TCP滑动窗口控制流量的原理 【2】Windows系统下的TCP参数优化 【3】Linux内核 TCP/IP、Socket参数调优 ...TCP协议里窗口机制有2种:一种是固定的窗口大小;一种是滑动的窗口。这个窗口大小就是我们
  • 1) 参数设置区可以设定3个参数:第1个参数为接收窗口大小,因为帧序列号为4位,所以接收窗口大小的设置范围为1~8。其中设为1相当于使用后退n帧技术的滑动窗口协议,设为大于1的值则相当于使用选择性重传策略的滑动...
  • windows下关闭TCP的Nagle纳格算法

    千次阅读 2016-07-07 15:20:41
    nagle算法是为了解决TCP传出过程中出现的“愚笨窗口综合症”的一种TCP传输算法,该算法是在TCP发送小数据包(telnet、ssh等)时候,在收到对端设备的ack确认包之前会将多小数据包缓存起来,直到足够多个小数据包的...
  • TCP Receive Window TCP接收窗口,TCP接收数据到缓冲,应用程序还未处理的那块数据。 TCP Receive Window大小,在TCP三次握手时就已经商量好了。并且还确定了数据包的最大...上面的例图中,Win为windows窗口大小
  • 这个功能本身的目的是为了让操作系统根据网络的实时性能(比如响应时间)来动态调整网络上传输的数据窗口大小,从而达到实时优化网络性能的目的。但是,在某种情况下(具体是怎样的一个环境,目前我也不清楚),.....
  • tcp网络优化工具

    2019-03-16 11:05:16
    该工具使用高级算法,而带宽延迟功能可为您的特定连接速度找到最佳的 TCP 窗口。它提供了对所有相关 TCP/IP 参数(例如 MTU、RWIN)甚至包括 QoS 和 ToS/区分服务优先级等高级参数的简单轻松的调整。该程序适用于...
  • TCP窗口大小(bits) / 延迟(秒) = 每秒吞吐量(bits) 比如说windows系统一般的窗口大小为64K, 中国到美国的网络延迟为150ms. 64KB = 65536 Bytes. 65536 * 8 =524288 bits 每秒吞吐量(bits) =524288 / 0.15 = ...
  • 1.Windows Scale窗口扩大因子 窗口扩大选项使TCP的窗口定义从16位增加为32位。这并不是通过修改TCP首部来实现的...于是TCP在内部将实际的窗口大小维持为32位的值。 [img]http://www-128.ibm.com/developerworks/c
  • #include<iostream> #include<ctime> #include<windows.h> using namespace std; const int RTT = 1; int ssthresh = 20;... //轻度、重度拥塞时窗口大小 int TranRound(int cwnd){ ...
  • 首先让我们来看一下 TCP 的报文头部主要字段: 序列号(Sequence number)字段用来标识TCP 源端设备向目的端设备发送的字节流,它表示在... TCP 的流量控制由连接的每一端通过声明的窗口大小windows size)来提供...
  • windowsnt 技术内幕

    2014-04-09 20:47:17
    回顾微软Windows NT域 回顾Windows NT域委托关系 回顾Windows NT目录服务 创建一个高效的Windows NT目录服务结构 决定所需的域控制器的数量 理解在地理上怎样安排域控制器 理解域控制器的大小和速度 计算所需的主域...
  • spark streaming官方教程有个NetworkWordCount例子,通过 TCP 套接字连接,从流数据中创建了一个 DStream,然后进行处理,时间窗口大小为10s 。 其中需要使用netcat作为数据数据服务器,window下执行: nc -lk ...
  • windows下iperf 2.0.4

    热门讨论 2009-09-23 11:32:08
    对于TCP方式,此设置为TCP窗口大小。对于UDP方式,此设置为接受UDP数据包的缓冲区大小,限制可以接受数据包的最大值。 -B, --bind host $IPERF_BIND 绑定到主机的多个地址中的一个。对于客户端来说,这个参数设置了...
  • Windows 2000下的Raw Socket编程 作者:refdom (refdom@263.net) ... 2002/1/31 ...Windows2000在TCP/IP协议组件上做了很多改进...调整,增大了默认窗口大小,以及高延迟链接新算法。同时在安全性上,可应用IPSec加强...
  • 4.4.2 高速缓存的大小 212 4.4.3 高速缓存的数据结构 214 4.4.4 高速缓存的操作 218 4.4.5 高速缓存支持例程 223 4.4.6 写阻塞 225 4.4.7 小结 225 习题 225 第5章 文件系统 227 5.1 文件概念与实现...

空空如也

空空如也

1 2 3 4 5 ... 12
收藏数 237
精华内容 94
热门标签
关键字:

tcp窗口大小windows