有关Tcp的堵塞窗口。

问题描述

最近看了TCP/ip详解第一卷，深感此书是超级好书啊。把以前不懂的似懂非懂的东西，都解释的非常清楚啊。感谢作者。 看了第20章的TCP的成块数据流，里面介绍滑动窗口协议，和堵塞窗口协议，说堵塞窗口协议是发送方使用的流量控制，发送方取堵塞窗口和通告窗口中的最小值作为发送上限。问题来了，堵塞窗口的大小是一直增加的，所以除了启动阶段，堵塞窗口的大小肯定是大于通告窗口的，所以两者的最小值肯定是通告窗口的值，那么此时堵塞窗口就没有作用了？那还怎么控制发送方使用的流量呢？ 然道堵塞窗口只有在刚开始的阶段有用？所以称为“慢启动”？那么后面阶段发送方的流量控制如何实现？ 望高人回答，谢谢。 问题补充：anranran 写道

解决方案

是这样的,以后滑动窗口协议来搞定.

时间： 2024-09-20 00:16:40

有关Tcp的堵塞窗口。的相关文章

TCP/IP滑动窗口

T C P使用一种窗口(w i n d o w)机制来控制数据流.当一个连接建立时,连接的每一端分配一个缓冲区来保存输入的数据,并将缓冲区的尺寸发送给另一端.当数据到达时,接收方发送确认,其中包含了自己剩余的缓冲区尺寸.剩余的缓冲区空间的大小被称为窗口( w i n d o w) ,指出窗口大小的通知称为窗口通告(window advertisement) .接收方在发送的每一确认中都含有一个窗口通告.   如果接收方应用程序读数据的速度能够与数据到达的速度一样快,接收方将在每一确认中发送一个正

TCP/IP协议栈遭遇攻击？！

我们的网络游戏采用tcp进行通信,服务端程序绑定8300端口,为游戏客户端提供服务,游戏已经上线稳定运行两年多,从今年9月份开始至今碰到了3次攻击,3次攻击所导致的情况一样,描述如下: (1)从应用层上来看,攻击者每次攻击时,与8300端口都有建立最多两.三百个tcp连接. (2)从防火墙监控来看,攻击的流量非常微小,以至于防火墙的流量报警都未触发. (3)每次攻击产生时,原先的玩家的tcp连接并未断开(应用程序未抛出TCP连接断开的异常),但服务端的再也接收不到来自客户端的任何消息.服务端进程

浅谈黑客攻击

作为一个搞软件的,能有机会经历被黑客攻击.并参与到抵抗攻击方案的讨论与实施中来,我觉得是很幸运的.虽然每天都有很多攻击产生,但是这种攻击能降临到我们这种不是很知名的公司身上,确实非常难得.下面就把我们对攻击相关的一些认识整理一下并记录,我们也是刚开始积累这些经验,所以有什么错误和不足之处,希望大家不吝斧正和补充.      虽然,我们经常看到一些门户网站被攻击,但是攻击者并不局限于只攻击网站,他可以攻击你对外提供的一切服务,比如,攻击你的游戏服务器.攻击DNS服务器等等. 一.为什么会产生攻击?

TCP/IP之TCP交互数据流、成块数据流

建立在TCP协议上的网络协议有telnet,ssh,ftp,http等等.这些协议根据数据吞吐量来分成两大类: (1)交互数据类型,例如telnet,ssh,这种类型的协议在大多数情况下只是做小流量的数据交换,比如说按一下键盘,回显一些文字等等. 交互数据类型在通讯中比例为10%: (2)数据成块类型,例如ftp,这种类型的协议要求TCP能尽量的运载数据,把数据的吞吐量做到最大,并尽可能的提高效率.数据成块类型在通讯中比例为90%: 针对这两种情况,TCP给出了两种不同的策略来进行数据传输: 1

解决TCP网络传输“粘包”问题

当前在网络传输应用中,广泛采用的是TCP/IP通信协议及其标准的socket应用开发编程接口(API).TCP/IP传输层有两个并列的协议:TCP和UDP.其中TCP(transport control protocol,传输控制协议)是面向连接的,提供高可靠性服务.UDP(user datagram protocol,用户数据报协议)是无连接的,提供高效率服务.在实际工程应用中,对可靠性和效率的选择取决于应用的环境和需求.一般情况下,普通数据的网络传输采用高效率的udp,重要数据的网络传输采用

糊涂窗口综合症和Nagle算法

前记:TCP/IP详解系列,毕竟不是一本教材,很多地方讲的不细致.比如SWS未说明是什么就开始介绍其避免方法,还和nagle扯在了一起,直觉告诉我二者一定有猫腻,边搜索一下,果然很有收获.今天贴在这里,分享给大家. 第一部分:SWS 何谓糊涂窗口综合症 当发送端应用进程产生数据很慢.或接收端应用进程处理接收缓冲区数据很慢,或二者兼而有之:就会使应用进程间传送的报文段很小,特别是有效载荷很小. 极端情况下,有效载荷可能只有1个字节:而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种

【转载】糊涂窗口综合症和Nagle算法

第一部分:SWS 何谓糊涂窗口综合症 当发送端应用进程产生数据很慢.或接收端应用进程处理接收缓冲区数据很慢,或二者兼而有之,就会使应用进程间传送的报文段很小,特别是有效载荷很小. 极端情况下,有效载荷可能只有 1 个字节:而传输开销有40 字节(20 字节的 IP 头 + 20 字节的 TCP 头) 这种现象就叫糊涂窗口综合症. 发送端引起的SWS 发送端的 TCP 可能产生糊涂窗口综合症,如果发送端为产生数据很慢的应用程序服务(典型的有 telnet 应用).例如,一次产生一个字节.这个应用程

网络编程-C# 使用TCP UDP混合实现即时通讯(QQ为例)

问题描述 C# 使用TCP UDP混合实现即时通讯(QQ为例) 我的思路是这样的 用户使用UDP IP 端口进行登录 此时开始计时 X秒 X秒内 未收到服务器的确认消息弹出登陆超时 X秒中服务器作出响应 登录失败即显示失败原因 若成功即 建立TCP连接 此时 窗口由登陆界面变成个人面板 上面包含好友列表 等信息 关键问题是!!!当QQ123456想要和QQ456789进行消息互发时 QQ123456发出的消息为Contact:123456|hello!|456789 服务器 想要将此消息转发给4

libjingle源码解析(3)-【PseudoTcp】建立UDP之上的TCP(1)：连接和关闭

PseudoTcp - 建立UDP之上的TCP(1):连接和关闭 mail:lihe21327 [at] gmail [dot] com 最近阅读了Libjingle的PseudoTcp.LibJingle很是下功夫做P2P了,在UDP之上做了可靠的传输协议PseudoTcp. 了解PseudoTcp之前,我们需要了解一些TCP的特性. 根据<TCP/IP详解>卷1,可以总结如下: 1.TCP是面相连接的,他需要3次握手和4次终止过程. 2.TCP支持Nangle算法和经受时延的确认来控制报文