首页 资讯 应用 高压 设计 行业 低压 电路图 关于

通信网络

旗下栏目: 电力电子 通信网络 RFID LED

发送/接受窗口与缓存的关系

通信网络 | 发布时间:2018-06-11 | 人气: | #评论# | 本文关键字:TCP
摘要:1,tcp传输报文段,发送窗口与缓存的关系? 2,普通意义上的,TCP传输报文段的时候会产生稍带确认吗? 3,接受方收到字节确认不是按顺序的,那么对这些东西已经收到的确认号如何处理?

1,tcp传输报文段,发送窗口与缓存的关系?2,普通意义上的,TCP传输报文段的时候会产生稍带确认吗?3,接受方收到字节确认不是按顺序的,那么对这些东西已经收到的确认号如何处理?

对于网络通信,tcp发送的都是一些报文段,里面存在一些发送/接受窗口

我们也清楚:发送方的应用进程把字节流写入TCP的发送缓存,接受方的应用进程从TCP的接受缓存中读取字节流

值得注意的是:缓存空间和序号空间(传送时的字节流需要的)都是有限的,并且都是循环使用的

发送缓存:(用来暂时存放)

1,发送应用程序传送给发送方TCP准备发送的数据

2,TCP已发送但尚未收到确认的数据

发送窗口通常只是发送缓存的一部分。已被确认的数据应当从发送缓存中删除,,因此,发送缓存和发送窗口的后沿是重合的。发送应用程序最后写入发送缓存的字节减去最后被确认的字节,就是还保留在发送缓存中的被写入的字节数(也就是等待确认的字节数)。发送应用程序必须控制写入缓存的速率,不能太快,不然发送缓存就会没有存放数据的空间。

接受缓存:(用来暂时存放)

1,按序到达的,但尚未被接受应用程序读取的数据

2,未按序到达的数据(也就是说,不会直接丢弃掉未按序到达的数据,会保留,等待指定的序号到达,此刻,窗口就会向前滑动)

如果收到的分组被检测出有差错,则要丢弃。如果接受应用程序来不及读取收到的数据,接收缓存最终会被填满,使接收窗口减小到零。如果接收应用程序能够及时从接收缓存中读取收到的数据,接收窗口就可以增大,但最大不能超过接受缓存的大小

1,虽然A发送方的发送窗口是根据B接受方的接收窗口设置的,但在同一时刻,A的发送窗口并不总和B的接收窗口一样大。这是因为通过网络传送窗口值需要经历一定的时间(时间不确定)。另外,发送方A还可能根据网络拥塞情况适当减小自己的发送窗口数值

2,对于不按序到达的数据如何处理,TCP标准并无明确规定。如果接受方把不按序到达的数据一律丢弃,那么接受窗口的管理将会比较简单,但这样做对网络资源的利用不利(因为发送方会重复发送特别多的数据)。因此TCP通常对不按序到达的数据是先临时存放在接受窗口中,等到字节流中所缺少的字节收到后,在交付给上层应用进程

3,TCP要求接受方必须有累积确认的功能,这样可以减少传输开销。接受方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便稍带上。值得注意的是:1,接受方不应该过分推迟发送确认,不然会导致发送方不必要的重传,这反而浪费了网络资源,TCP规定:确认推迟时间不应超过0.5s,稍带确认实际上并不经常发生.


责任编辑:发送/接受
首页 | 电气资讯 | 应用技术 | 高压电器 | 电气设计 | 行业应用 | 低压电器 | 电路图 | 关于我们 | 版权声明

Copyright 2017-2018 电气自动化网 版权所有 辽ICP备17010593号-1

电脑版 | 移动版 原创声明:本站大部分内容为原创,转载请注明电气自动化网转载;部分内容来源网络,如侵犯您的权益请发送邮件到[email protected]联系我们删除。

Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。