TCP的滑动窗口机制       TCP这个协议是网络中使用的比较广泛,他是一个面向连接的可靠的传输协议.既然是一个可靠的传输协议就需要对数据进行确认.TCP协议里窗口机制有2种:一种是固定的窗口大小:一种是滑动的窗口.这个窗口大小就是我们一次传输几个数据.对所有数据帧按顺序赋予编号,发送方在发送过程中始终保持着一个发送窗口,只有落在发送窗口内的帧才允许被发送:同时接收方也维持着一个接收窗口,只有落在接收窗口内的帧才允许接收.这样通过调整发送方窗口和接收方窗口的大小可以实现流量控制. TCP滑动

1.可靠传输 (1)三次握手 TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接: (1)第一次握手:建立连接时,客户端A发送SYN包(SYN=j)到服务器B,并进入SYN_SEND状态,等待服务器B确认. (2)第二次握手:服务器B收到SYN包,必须确认客户A的SYN(ACK=j+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器B进入SYN_RECV状态. (3)第三次握手:客户端A收到服务器B的SYN+ACK包,向服务器B发送确认包ACK

参考文章 TCP 的那些事儿(下) http://coolshell.cn/articles/11609.html tcp/ip详解--拥塞控制 & 慢启动 快恢复 拥塞避免 http://blog.csdn.net/kinger0/article/details/48206999 TCP window Full http://blog.csdn.net/abccheng/article/details/50503457 tcp队列优化 http://www.tuicool.com/articl

目录 1.RTT和RTO 2.TCP使用滑动窗口做流量控制与乱序重排 3.滑动窗口的基本原理 八.TCP的滑动窗口 TCP头部中的窗口字段:滑动窗口大小,用来告知发送端接受端的缓存大小,以此控制发送端发送数据的速率,从而达到流量控制 1.RTT和RTO (1)RTT:发送一个数据包到收到对应的ACK,所花费的时间 (2)RTO:重传时间间隔 2.TCP使用滑动窗口做流量控制与乱序重排 (1)保证TCP的可靠性 (2)保证TCP的流控特性 3.滑动窗口的基本原理 (1)TCP会话的发送方 可分为四

一.TCP流控 之前我们介绍过TCP是基于窗口的流量控制,在TCP的发送端会维持一个发送窗口,我们假设发送窗口的大小为N比特,网络环回时延为RTT,那么在网络状况良好没有发生拥塞的情况下,发送端每个RTT就可以发送N比特的数据,发送端的速率应该与N/RTT成正比,因此通过改变发送窗口的大小就可以控制发送端的发送速率,那么接收端就可以通过控制发送端发送窗口的大小来控制发送速率.这样接收端需要有一种方式通告发送端接收端期望的发送窗口大小,这种方式就叫做窗口通告(window advertisemen

看这篇文章: http://www.cnblogs.com/woaiyy/p/3554182.html 窗口滑动,如下图: 流量控制 流量控制方面主要有两个要点需要掌握.一是TCP利用滑动窗口实现流量控制的机制:二是如何考虑流量控制中的传输效率. 关于二,一个显而易见的问题是:单个发送字节单个确认,和窗口有一个空余即通知发送方发送一个字节,无疑增加了网络中的许多不必要的报文(请想想为了一个字节数据而添加的40字节头部吧!),所以我们的原则是尽可能一次多发送几个字节,或者窗口空余较多的时候通知发送

https://technet.microsoft.com/zh-cn/magazine/2007.01.cableguy.aspx 欢迎来到 TechNet 杂志“网络专家”的第一部分.TechNet 网站上的专栏爱好者都知道我们探讨各种网络问题,我们每个月都将继续保持这个传统.如果您是新手,要查找以前专栏的存档,请访问网络专家站点. 现在开始介绍我们的第一个主题 - TCP 接收窗口. TCP 连接的吞吐量可以通过发送和接收应用程序.发送和接收 TCP 的实现以及 TCP 对等方之间的传输路

每日一句英语学习,每天进步一点点: 前言 前一篇「硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可,在此特别感谢你们的认可,大家都暖暖的. 来了,今天又来图解 TCP 了,小林可能会迟到,但不会缺席. 迟到的原因,主要是 TCP 巨复杂,它为了保证可靠性,用了巨多的机制来保证,真是个「伟大」的协议,写着写着发现这水太深了... 本文的全部图片都是小林绘画的,非常的辛苦且累,不废话了,直接进入正文,Go! 正文 相信大家都知道 TCP 是一个可靠

在这篇文章中我们看一下server端在接收到异常数据系列时的处理,主要目的是通过wireshark示例对这些异常数据系列的处理有一个直观的认识,感兴趣的自行阅读相关代码和协议,这里不再进行详细介绍 在进行下面的测试前,首先如下设置相关的参数,其中window参数指定了到127.0.0.2的tcp连接的最大接收窗口. root@Inspiron:/home/******/tcp12# ip route change local 127.0.0.2 dev lo window 40 一.wiresh

今天用wireshark抓取TCP连接时的报文发现客户端的Win变大了,这里是使用了Window Scale来扩张TCP接收窗口,使得接收窗口可以大于65535字节. 首先1号包是TCP第一次握手连接时客户端的请求包,客户端如果窗口大于65535,那么就先将Window size value设置为65535,并且将Options中Shift count设置为8(根据实际情况而定),表示客户端窗口将大于65535,具体是多大,在3号数据包会给出窗口的基数. 下面是3号包截图,可以看到窗口的基数是3

一.滑动窗口 滑动窗口协议是传输层进行流控的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,从而达到防止发送方发送速度过快而导致自己被淹没的目的.   对ACK的再认识,ack通常被理解为收到数据后给出的一个确认ACK,ACK包含两个非常重要的信息: 一是期望接收到的下一字节的序号n,该n代表接收方已经接收到了前n-1字节数据,此时如果接收方收到第n+1字节数据而不是第n字节数据,接收方是不会发送序号为n+2的ACK的.举个例子,假如接收端收到1-1024字节,它会发送一

原文链接:http://www.cnblogs.com/luoquan/p/4886345.html      TCP这个协议是网络中使用的比较广泛,他是一个面向连接的可靠的传输协议.既然是一个可靠的传输协议就需要对数据进行确认.TCP协议里窗口机制有2种:一种是固定的窗口大小:一种是滑动的窗口.这个窗口大小就是我们一次传输几个数据.对所有数据帧按顺序赋予编号,发送方在发送过程中始终保持着一个发送窗口,只有落在发送窗口内的帧才允许被发送:同时接收方也维持着一个接收窗口,只有落在接收窗口内的帧才允

TCP流量控制机制通过动态调整窗口大小来控制发送端的操作,确保路由器/接收端消息不会溢出. 交互式TCP连接 交互式TCP连接指该连接需要在客户端和服务器之间传输用户输入信息,如按键操作.短消息.操作杆或鼠标操作.对于这些操作,如果用较小的报文段来承载信息,则传输协议需要耗费很高的代价:反之采用较大的报文段则会引入更大的延时,对延迟敏感类应用造成负面影响.因此需要权衡相关因素来找到适合的方法. 以ssh(安全外壳)应用为例,对一个ssh连接,每个交互按键通常都会生成一个单独的数据报(每个按键独立

TCP的滑动窗口协议是什么 滑动窗口协议,用于网络数据传输时的流量控制,以避免拥塞的发生.该协议允许发送方在停止并等待确认前发送多个数据分组.由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,提高网络吞吐量.它本质上是描述接收方的TCO数据报缓冲区大小的数据,发送方根据这个数据来计算自己最多能发送多长的数据.这个窗口大小为0时,发送方将停止发送数据.启动定时器,等待这个窗口变成非0.   滑动窗口协议必须保证数据包的按序传输,发送窗口中的序列号代表已发送但尚未收到确认的数

什么是滑动窗口? 滑动窗口机制是TCP协议的一种流量控制和防拥塞的机制. 滑动窗口的工作原理? 简单来讲,就是接收方和发送方分别保留一块缓冲区,作为接收和发送数据来使用,发送数据过程中,如果发送方发的快了,处理方处理不过来,缓冲区放不下了,接收方就会通过消息交互告诉发送方,慢点发,等接收方处理完,可接收了,又会通知发送方可以继续发送了,通过这种方式来防止由于双方能力不一致导致的拥塞和丢包. 工作原理举例,以发送方为例 老规矩,先上图,直观看一下 滑动窗口组成 可以看到,滑动窗口被分成了四部分,分

学过网络相关课程的,都知道TCP中,有两个窗口: 滑动窗口(在我们的上一篇文章中有讲),接收方通过通告发送方自己的可以接受缓冲区大小(这个字段越大说明网络吞吐量越高),从而控制发送方的发送速度. 拥塞窗口,也就是本文要讲的. 概念 一个连接的TCP双端只是网络最边缘的两台主机,他们不知道整个网络是如何工作的,因此他们不知道彼此之间的有效吞吐量.因此,他们必须找到一种方法来确定它.我们称之为拥塞窗口 (CWND).这是在我们必须停止并等待确认之前可以发送的字节数. 拥塞窗口是决定任何时候可以发出的

一.概述 我们之前介绍过一种具有大的带宽时延乘积(band-delay product.BDP)的网络,这种网络称为长肥网络(LongFatNetwork,即LFN).我们想象一种简单的场景,假设发送端的发送窗口为5000bytes,网络的RTT为200ms,那么每秒的最大速率则为5000*(1000/200)=25000bytes/s,这大约为24kb/s,可以看到这个速率是非常低的,这就是TCP发送窗口对于发送速率的限制,实际的window size应该至少为带宽时延积才能高效的利用网络传输

一.SWS介绍 前面我们已经通过示例看到如果接收端的应用层一直没有读取数据,那么window size就会慢慢变小最终可能变为0,此时我们假设一种场景,如果应用层读取少量数据(比如十几bytes),接收端TCP有了少量的新的接收缓存后如果立即进行window update把新的window size通告发送端的话,发送端如果立即发送数据,那么接收端缓存可能又会立即耗尽,window size又变为0,接着应用层重复读取少量数据,这个过程重复的话,那么发送端就会频繁的发送大量的小包,这种场景我们就

一.简介 我们之前介绍过,TCP报文中的window size表示发出这个报文的一端准备多少bytes的数据,当TCP的一端一直接收数据,但是应用层没有及时读取的话,数据一直在TCP模块中缓存,最终受限于接收缓存的大小,window size会变为0,此时我们称呼这个接收窗口为零窗(zero window),对端也不能在发送更多的数据.如果随后本端应用层从TCP接收缓存中读取了足够数据,TCP模块有了足够的新的接收缓存的时候,就会发送一个TCP报文,并带有一个有效非零的Window size来指

一.简介 之前的内容中我们多次提到延迟ACK(Delayed Ack),延迟ACK是在RFC1122协议中定义的,协议指出,一个TCP实现应该实现延迟ACK,但是ACK不能被过度延迟,协议给出延迟ACK的最大时间为0.5s.如果发送端连续发送最大的数据报文,那么没两个数据报文就需要回复一次ACK.延迟ACK主要目的是等待接收者应用层接收到数据处理后有可能会发送一个响应,这样ACK报文就可以和这个响应报文一起发送了,这样减少了网络中的数据包的同时,也降低了主机的负载处理压力. 二.linux实现概

TCP发送方的窗口可以划分成四个部分: 1.已经发送并且确认的TCP段: 2.已经发送但是没有确认的TCP段: 3.未发送但是接收方准备接收的TCP段, 4.未发送并且接收方也为准备接受的TCP段. 第3部分是可用窗口,长度为snd_una + snd_wnd - snd_nxt. 第2部分和第3部分合并起来,成为发送窗口,简称窗口. 发送窗口的左边界是snd_una,右边界是snd_una + snd_wnd . 同理,TCP接受方的窗口可以划分成四个部分: 1.已经接收并且已经确认的TCP段