TCP 滑动窗口(发送窗口和接收窗口)

TCP的滑动窗口主要有两个作用,一是提供TCP的可靠性,二是提供TCP的流控特性。同时滑动窗口机制还体现了TCP面向字节流的设计思路。

TCP的Window是一个16bit位字段,它代表的是窗口的字节容量,也就是TCP的标准窗口最大为2^16-1=65535个字节。

另外在TCP的选项字段中还包含了一个TCP窗口扩大因子,option-kind为3,option-length为3个字节,option-data取值范围0-14。窗口扩大因子用来扩大TCP窗口,可把原来16bit的窗口,扩大为31bit。

滑动窗口基本原理

1)对于TCP会话的发送方,任何时候在其发送缓存内的数据都可以分为4类,“已经发送并得到对端ACK的”,“已经发送但还未收到对端ACK的”,“未发送但对端允许发送的”,“未发送且对端不允许发送”。“已经发送但还未收到对端ACK的”和“未发送但对端允许发送的”这两部分数据称之为发送窗口(中间两部分)。

当收到接收方新的ACK对于发送窗口中后续字节的确认是,窗口滑动,滑动原理如下图。

当收到ACK=36时窗口滑动。

2)对于TCP的接收方,在某一时刻在它的接收缓存内存在3种。“已接收”,“未接收准备接收”,“未接收并未准备接收”(由于ACK直接由TCP协议栈回复,默认无应用延迟,不存在“已接收未回复ACK”)。其中“未接收准备接收”称之为接收窗口。

发送窗口与接收窗口关系

TCP是双工的协议,会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制(TCP传输速率不能大于应用的数据处理速率)。各自的“发送窗口”则要求取决于对端通告的“接收窗口”,要求相同。

滑动窗口实现面向流的可靠性

最基本的传输可靠性来源于“确认重传”机制。

TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。

发送窗口只有收到对端对于本段发送窗口内字节的ACK确认,才会移动发送窗口的左边界。

接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下,窗口不会移动,并不对后续字节确认。以此确保对端会对这些数据重传。

滑动窗口的流控特性

TCP的滑动窗口是动态的,我们可以想象成小学常见的一个数学题,一个水池,体积V,每小时进水量V1,出水量V2。当水池满了就不允许再注入了,如果有个液压系统控制水池大小,那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化,通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。

应用程序在需要(如内存不足)时,通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端,对端按通知的窗口来改变发送窗口,以此达到减缓发送速率的目的。

========================END========================

时间: 2024-08-29 21:01:09

TCP 滑动窗口(发送窗口和接收窗口)的相关文章

直观明了的总结TCP滑动窗口机制原理及作用

一. 原理 TCP是全双工通信,因此每一方的滑动窗口都包括了接收窗口+发送窗口,接收窗口负责处理自己接收到的数据,发送窗口负责处理自己要发送出去的数据.滑动窗口的本质其实就是维护几个变量,通过这些变量将TCP处理的数据分为几类,同时在发送出一个报文.接收一个报文对这些变量做一定的处理维护. 发送窗口如上图 : (1)N是发送窗口的起始字节,也就是说:字节序号 < N的字节都已经发送出去且已经收到ack,确认无误了: (2)nextSeq就是下一次发送报文的首部Seq字段(Seq即第一个字节的序号

页面嵌套iframe后,点击里面的链接,然后父窗口跳转(子窗口控制父窗口的链接跳转)

做app的时候遇到一个问题,一个页面,然后里面嵌套了一个另一个页面,想实现点击里面的链接,然后外面进行跳转,不然的话,里面的页面永远出不来, 后面想了个办法,app的页面都是打开打开,不关闭的,然后由上一个页面用postmessage进行监听,然后子窗口发送信息给父窗口,父窗口接到信息后进行 页面跳转,Android可以,然而ios却不行,坑了:只能想另外一种办法, app打开页面不是都不会关闭的嘛,然后让这个top页面去轮询读取cookie,目标页面 判断请求头部,是否为移动端访问(因为目标页

tcp滑动窗口与拥塞控制

TCP协议作为一个可靠的面向流的传输协议,其可靠性和流量控制由滑动窗口协议保证,而拥塞控制则由控制窗口结合一系列的控制算法实现.一.滑动窗口协议     所谓滑动窗口协议,自己理解有两点:1. "窗口"对应的是一段可以被发送者发送的字节序列,其连续的范围称之为"窗口":2. "滑动"则是指这段"允许发送的范围"是可以随着发送的过程而变化的,方式就是按顺序"滑动".在引入一个例子来说这个协议之前,我觉得很有必

TCP滑动窗口

TCP的滑动窗口解决了端到端的流量控制问题,允许接受方对传输进行限制,直到它拥有足够的缓冲空间来容纳更多的数据.滑动窗口的大小由接收方确定,接收方在发送确认信号给发送方的同时告诉发送方自己的缓冲区大小(在TCP头部字段中),发送方根据此大小确定窗口大小,从而控制数据发送量.同时,滑动窗口协议允许发送方在停止并等待确认前可以连续发送多个分组,由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输. 下面是一个例子: 在建立连接时,双方都告知了对方自己的MSS为1024,所以在传输

TCP 滑动窗口的简介(写得太好,转载过来的)

TCP 滑动窗口的简介 POSTED BY ADMIN ON AUG 1, 2012 IN FLOWS34ARTICLES | 0 COMMENTS TCP的滑动窗口主要有两个作用,一是提供TCP的可靠性,二是提供TCP的流控特性.同时滑动窗口机制还体现了TCP面向字节流的设计思路.TCP 段中窗口的相关字段. TCP的Window是一个16bit位字段,它代表的是窗口的字节容量,也就是TCP的标准窗口最大为2^16-1=65535个字节. 另外在TCP的选项字段中还包含了一个TCP窗口扩大因子

TCP滑动窗口 [转]

1. 滑动窗口其实是一种协议,它主要提供两个作用,一是提供TCP的可靠性,二是提供TCP的流量控制特性,我感觉因为其协议动作特征类似窗口在移动所以称为滑动窗口.如图,从TCP首部可以看到滑动窗口的大小占16位,故其最大为2^16-1即65535个字节,另外在TCP的选项字段中还包含了一个TCP窗口扩大因子,窗口扩大因子用来扩大TCP窗口,可把原来16bit的窗口,扩大为31bit. 2. 滑动窗口可以分为发送窗口和接收窗口,因为TCP是双工的协议,所以TCP会话的双方都各自维护一个"发送窗口&q

TCP滑动窗口与回退N针协议

[转]TCP 滑动窗口协议/1比特滑动窗口协议/后退n协议/选择重传协议 2014-1-5阅读884 评论0 本文转自 http://www.cnblogs.com/ulihj/archive/2011/01/06/1927613.html 滑动窗口协议 一图胜千言,看下面的图,简单解释下: 发送和接受方都会维护一个数据帧的序列,这个序列被称作窗口.发送方的窗口大小由接受方确定,目的在于控制发送速度,以免接受方的缓存不够大,而导致溢出,同时控制流量也可以避免网络拥塞.下面图中的4,5,6号数据帧

关于Linux TCP接收缓存以及接收窗口的一个细节解析

关于TCP的接收缓存以及通告窗口,一般而言懂TCP的都能说出个大概,但是涉及到细节的话可能理解就不那么深入了.由于我最近的工作与TCP有关,顺便又想起了很久之前遇到的一个问题:明明在接收端有8192字节的接收缓存,为什么收了不到8000字节的数据就ZeroWindow了呢?当时我的解决方案是直接扩大接收缓存完事,然后就没有然后了.后来深挖了一下细节,发现了很多曾经不知道的东西,如今对TCP的理解想必又深入了一些,趁着国庆假期顺便就把很多想法整理成一篇文章了. 0.network buffer &

TCP/IP(十一)TCP滑动窗口和用赛控制

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