如何解决TCP窗口与拥塞? TCP窗口与拥塞控制的解决办法

这篇具有很好参考价值的文章主要介绍了如何解决TCP窗口与拥塞? TCP窗口与拥塞控制的解决办法。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

  计算机网络中的带宽、交换结点中的缓存和处理机等,都是网络的资源。在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就会变坏。这种情况就叫做拥塞。拥塞控制就是防止过多的数据注入网络中,这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程,和流量控制不同,流量控制指点对点通信量的控制。

  TCP通过滑动窗口机制检测丢包,并在丢包发生时调整数据传输速率。滑动窗口机制利用数据接收端的接收窗口来控制数据流。

  接收窗口值由数据接收端指定,以字节数形式存储于TCP报文头,并告知传输设备有多少数据将会存储在TCP缓冲区。缓冲区就是数据暂时放置的地方,直至传递至应用层协议等待处理。因此,发送端每次只能发送Window Size字段指定的数据量。为了使发送端继续传送数据,接收端必须发送确认信息:之前的数据接收到了。同时必须对占用缓冲区的数据进行处理以释放缓存空间。下图显示了接收窗口是如何工作的:

  上图中,客户端向服务器发送数据,服务器接收窗口是5000字节。客户端发送了2500字节,服务器缓冲区还剩2500字节,之后又发送了2000字节,从而缓冲区只剩500字节。服务器发送确认信息。对缓存中数据进行处理并清空缓存。此过程重复进行,客户端又发送3000字节和1000字节,服务器缓存减少至1000字节,客户端再次确认数据并处理缓存中内容。

  调整窗口大小:

  当TCP堆 栈接收到数据的时候,生成一个确认信息并以回复的方式发送,但是放置在接收端缓存中的数据并不总是立即被处理。当服务器忙于处理从多个客户端接收的报文, 服务器很有可能因为清理缓存而变得缓慢,无法腾出空间接收新的数据,如果没有流控,则可能会造成丢包和数据损坏。好在,接收窗口所设定的速率无法使服务器 正常处理数据时,能够调整接收窗口大小。通过减小返回给发送端的ACK报文的TCP头窗口大小值来实现。如下图所示:

  上图中,服务器初始窗口大小为5000字节。客户端发送2000字节,之后又发送了2000字节,缓冲区中只有1000字节可用。服务器意识到缓冲区正在快速填满,它知道如果数据继续以此速率传输,很快会有报文丢失。为了防止报文丢失,服务器发送确认信息给客户端,更新窗口大小为1000字节。结果,客户端减少数据发送,服务器以可以接受的速率处理缓存内容,即保持数据流以稳定的速率传输。

  调整窗口大小在两个方向都是可行的。当服务器能够更加快速的处理报文时,它会发送一个较大窗口的ACK报文。

  零窗口暂停数据流:

  某些情况下,服务器无法再处理从客户端发送的数据。可能是由于内存不足,处理能力不够,或其他原因。这可能会造成数据被丢弃以及传输暂停,但接收窗口能够帮助减小负面影响。

  当上述情况发生时,服务器会发送窗口为0的报文。当客户端接收到此报文时,它会暂停所有数据传输,但会保持与服务器的连接以传输探测(keep-alive)报文。探测报文在客户端以稳定间隙发送,以查看服务器接收窗口状态。一旦服务器能够再次处理数据,将会返回非零值窗口大小,传输会恢复。下图示例了零窗口通知过程。

  服务器初始接收数据窗口为5000字节大小。从客户端接收4000字节数据之后,服务器负载变得非常繁重,无法继续处理客户端任何数据。服务器于是发送窗口大小值为0的报文。客户端暂停数据传输并发送一个探测报文。探测报文之后,服务器回复以告知客户端现在可以接收数据的报文,以及窗口大小为1000字节。客户端恢复传送数据。

  TCP滑动窗口实战:

  本例中,开始从192.168.0.20发送至192.168.0.30。我们关心的是窗口大小字段,可以从Packet List面板的Info栏以及Packet Details的TCP报文头看到。前三个报文后,可看到该值立刻减小,如下图所示:

  窗口大小值从第一个报文的8760字节变成第二个报文的5840字节到第三个报文的2920字节①。窗口大小值的减小是主机延时的典型标志。在时间栏注意到这一过程发生的非常迅速②。当窗口大小迅速减小的时候,通常就有可能下降为零。这就是第四个报文所发生的,如下图所示:

  第四个报文从192.168.0.20发送至192.168.0.30,目的是告诉192.168.0.30它不再接收任何数据。0值见于TCP报文头①,Wireshark的Packet List面板Info栏,以及TCP报文头的SEQ/ACK Analysis字段②也告诉我们这是一个0窗口报文。

  一旦发送了零窗口报文,192.168.0.30的设备不会再发送任何数据,直到收到从192.168.0.20的窗口更新,告知窗口大小已经增加了。本例中导致零窗口的问题是暂时的,所以在下一个报文中发送了窗口更新信息,如下图所示。

  本例中,窗口大小增加到一个非常健康的数值64,240字节①。Wireshark再次在SEQ/ACK Analysis告诉我们这是一个窗口更新。

  一旦收到更新报文,192.168.0.30的主机就再次开始发送数据,在报文6和报文7中。这一过程发生很快。如果它持续时间再长一点,就可能会导致网络的潜在中断,引起数据传输减慢或失败。

  下一个关于滑动窗口的例子,第一个报文是正常HTTP,从195.81.202.68至172.31.136.85。此报文之后立刻跟随一个从172.31.136.85发送的零窗口报文,如下图所示:

  这与上一个例子中的零窗口报文十分类似,但结果显著不同,172.31.136.85主机不是发送一个窗口更新并回复通讯,而是一个探测报文,如下图所示:

  此报文被Wireshark标注为探测报文①。时间栏告诉我们这一报文发生于最后一个接收到的报文3.4秒之后。这一过程持续若干次,一端发送零窗口报文另一端发送探测报文,如下图所示:

  探测报文发送间隙为3.4,6.8,13.5秒。这一过程可能会持续相当长一段时间,取决于通讯设备的操作系统。该情况下,把时间栏的值加起来,通讯暂停了25秒。

  TCP差错控制和流控排查总结:

  重传报文

  重 传的发生是由于客户端检测到服务器没有接收到它所发送的数据。因此,取决于你所分析的是通讯的哪一端,有可能是看不见重传的。如果从服务器端抓取数据,并 且它确实没有接收到客户端所发送的和重传报文,可能会一无所获因为无法看见重传报文。如果怀疑并不是服务器端导致的报文丢失,可以考虑在客户端尝试抓取报 文,以查看实际是否有重传发生。

  重复ACK

  可以将重复ACK看作重传的“所谓相反面”,因为它是在服务器检测到客户端发送报文丢失的时候产生的。大多数情况下,在通讯两端抓取流量时都可以看到重复ACK。需记住当接收报文乱序时会触发重复ACK。例如,如果服务器之接收到发送的第一个和第三个报文,就会导致发送重复ACK引起客户端对第二个报文的快速重传,因为你已经收到了第一个和第三个报文,因此不管导致第二个报文丢弃的原因是什么,都很有可能是暂时的,因此大多数情况下重复ACK都会成功发送和接收。当然,这种情形并不一定永远会发生,因此当你怀疑在服务器端丢失报文而又看不到任何重复ACK,考虑从通讯的客户端抓取报文。

  零窗口和探测报文

  滑动窗口直接与服务器无法接收和处理报文有关,任何窗口大小的缩小以及零值都是服务器问题的直接结果。所以如果你在哪里看到这两者之一发生,就应该在那里深入研究。通常应当在网络通讯两端一直主机窗口更新报文。

  以上就是解决TCP窗口与拥塞控制的办法,希望能帮到大家,谢谢阅读。文章来源地址https://www.toymoban.com/news/detail-466365.html

到了这里,关于如何解决TCP窗口与拥塞? TCP窗口与拥塞控制的解决办法的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

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

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

相关文章

  • TCP的滑动窗口与拥塞控制

    客户端每发送的一个包,服务器端都应该有个回复,如果服务器端超过一定的时间没有回复,客户端就会重新发送这个包,直到有回复。 为了保证顺序性,每一个包都有一个 ID。在建立连接的时候,会商定起始的 ID 是什么,然后按照 ID 一个个发送。为了保证不丢包,对于发

    2024年02月07日
    浏览(39)
  • TCP的滑动窗口和拥塞控制

    目录 滑动窗口 1.发送窗口和接收窗口 2.滑动窗口的分类 停止等待协议:发送窗口大小 = 1, 接收窗口大小= 1 后退N帧协议(GBN):发送窗口大小 1,接收窗口大小 = 1 选择重传协议(SR) :发送窗口大小 1, 接收窗口大小 1 拥塞控制 慢开始算法和拥塞避免: 快重传和快恢复:

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

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

    2024年02月02日
    浏览(35)
  • TCP重传机制、滑动窗口、拥塞控制

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

    2024年04月10日
    浏览(50)
  • 拥塞控制(TCP限制窗口大小的机制)

            拥塞控制机制可以使滑动窗口在保证可靠性的前提下,提高传输效率         关于滑动窗口的属性以及部分机制推荐看TCP中窗口和滑动窗口的含义以及流量控制         看了上面推荐的博客我们已经知道了,由于接收方接收数据的能力有限,所以要通过流量控制的

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

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

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

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

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

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

    2024年04月15日
    浏览(54)
  • 八股文——TCP四大机制!小白也能懂!(重传机制、滑动窗口、流量控制、拥塞控制)

    TCP巨复杂!同时在八股计算机网络中也经常被问到,必须会!这篇文章将让小白有个大体框架,知道怎么个事,面试中可以有话说,也能让佬更加巩固知识点。 TCP是一个可靠的传输协议,为了保证它的可靠性,出现七七八八的机制,它可能有数据的破坏、丢包、重复以及分片

    2024年04月25日
    浏览(30)
  • 论TCP协议中的拥塞控制机制与网络稳定性

    TCP协议中的拥塞控制机制与网络稳定性的深度探讨 随着互联网的快速发展,网络流量呈现爆炸式增长,网络拥塞问题逐渐凸显。为了维护网络的稳定运行,TCP协议中引入了拥塞控制机制。这一机制的主要目的是防止过多的数据注入网络,从而避免网络拥塞。然而,尽管拥塞控

    2024年04月22日
    浏览(41)

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

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

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

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

二维码1

领取红包

二维码2

领红包