网站开发非常之旅:ajax从入门到精通 pdf,百姓网网站建设,冠县 网站建设,wordpress 评论上传图片一、窗口机制的分类在TCP协议当中窗口机制分为两种#xff1a;1.固定的窗口大小2.滑动窗口二、固定窗口存在的问题如下图所示#xff1a;我们假设这个固定窗口的大小为1#xff0c;也就是每次只能发送一个数据#xff0c;只有接收方对这个数据进行了确认后才能发送第二个数…一、窗口机制的分类在TCP协议当中窗口机制分为两种1.固定的窗口大小2.滑动窗口二、固定窗口存在的问题如下图所示我们假设这个固定窗口的大小为1也就是每次只能发送一个数据只有接收方对这个数据进行了确认后才能发送第二个数据。在图中我们可以看到发送方每发送一个数据接收方就要给发送方一个ACK对这个数据进行确认。只有接收了这个确认数据以后发送方才能传输下个数据。存在的问题如果窗口过小当传输比较大的数据的时候需要不停的对数据进行确认这个时候就会造成很大的延迟。如果窗口过大我们假设发送方一次发送100个数据但接收方只能处理50个数据这样每次都只对这50个数据进行确认。发送方下一次还是发送100个数据但接受方还是只能处理50个数据。这样就避免了不必要的数据来拥塞我们的链路。因此我们引入了滑动窗口二、滑动窗口(以字节为单位)1.概述滑动窗口通俗来讲就是一种流量控制技术。它本质上是描述接收方的TCP数据报缓冲区大小的数据发送方根据这个数据来计算自己最多能发送多长的数据如果发送方收到接收方的窗口大小为0的TCP数据报那么发送方将停止发送数据等到接收方发送窗口大小不为0的数据报的到来2.工作原理第一次发送数据这个时候的窗口大小是根据链路带宽的大小来决定的。假设这时候的窗口是3.这个时候接收方收到数据以后会对数据进行确认告诉哦发送方我下次希望收到的数据是多少。在上图中我们看到接收方发送的ACK 3(这是对发送方发送序列2的回答确认下一次接收方期望接收到的是3序列信号)这个时候发送方收到这个数据以后就知道我第一次发送的3个数据对方只收到了两个就知道第三个数据对方没有收到下次返送的时候就从第3个数据开始发。这时候窗口大小就变为了2.如下图所示看到接收方发送的ACK是5就表示他下一次希望收到的数据是5发送方就知道我刚才发送的2个数据对方收到了这个时候开始发送第5个数据。*****当链路变好或者变差这个窗口还会发生变化并不是第一次协商好了以后就永远不会变化了。3.死锁状态(1)概述当接收端向发送端发送零窗口报文段后不久接收端的接收缓存又有了一些存储空间于是接收端向发送端发送了Windows size 2的报文段然而这个报文段在传输过程中丢失了。发送端一直等待收到接收端发送的非零窗口的通知而接收端一直等待发送端发送数据这样就死锁了。(2)解决方法TCP为每个连接设有一个持续计时器。只要TCP连接的一方收到对方的零窗口通知就启动持续计时器若持续计时器设置的时间到期就发送一个零窗口探测报文段(仅携带1字节的数据)而对方就在确认这个探测报文段时给出了现在的窗口值。4.TCP报文段的发送时机(传输效率问题)可以用以下三种不同的机制控制TCP报文段的发送时机(1)TCP维持一个变量MSS等于最大报文段的长度。只要缓冲区存放的数据达到MSS字节时就组装成了一个TCP报文段发送出去(2)由发送方的应用进程指明要发送的报文段即TCP支持推送操作(3)发送方的一个计时器期限到了这时就把当前已有的缓存数据装入报文段(但长度不能超过MSS)发送出去。5.Nagle算法(控制TCP报文段的发送时机)(1)主旨避免大量发送小包(2)初衷避免发送大量的小包防止小包泛滥于网络在理想情况下对于一个TCP连接而言网络上每次只能有一个小包存在。它更多的是端到端意义上的优化【CORK算法提高网络利用率理想情况下完全避免发送小包仅仅发送满包以及不得不发的小包】发送方将第一个数据字节发送出去把后面到达的数据字节缓存起来。当发送方接收对第一个数据字符的确认后再把发送缓存中的所有数据组装成一个报文段再发送出去同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认之后才继续发送下一个报文段。规定一个TCP连接最多只能有一个未被确认的未完成的小分组在该分组的确认到达之前不能发送其它的小分组。当数据到达较快而网络速率较慢时用这样的方法可以明显的减少所用的网络带宽。Nagle算法还规定当达到的数据已经达到发送窗口大小的一半或者已经达到报文段的最大长度时就可以立即发送一个报文段。6.糊涂窗口综合症(接收端糊涂网络上小包泛滥的原因之一)(1)概述TCP接收方的缓存已满而交互式的应用进程一次只从接收缓存区中读取1字节(这样就使接收缓存空间仅腾出1字节)然后向发送方发送确认并把窗口设置为1个字节(但发送的数据报为40字节的话)然后发送方又发来1字节的数据(发送方的IP数据报是41字节)接收方发回确认仍将窗口设置为1个字节这样网络效率就会很低(2)解决办法a.你糊涂我不糊涂法。即Nagle算法。可让接收方等待一段时间使得或者 接收缓存已有足够的空间容纳一个 最长的报文段或者等到接收方缓存已有一半的空闲空间。只要出现这两种情况接收方就发回确认报文并向发送方通知当前的窗口大小。此外发送方也不要发送太小的报文段而是把数据报文积累为足够大的报文段或达到接收方缓存的空间的一半大小。b.治疗接收端的糊涂(其中一种机制是延迟ACK(还有其它机制例如不发送小窗口通告等))对于接收方而言 延迟ACK可以拖延ACK发送时间进而延迟窗口通告在这段时间内接收窗口有机会进一步放大对于发送方而言 不理会接收端的小窗口通告等于说不马上1发送小包小包有时间积累成大包————————————————版权声明本文为CSDN博主「m0_37962600」的原创文章遵循 CC 4.0 BY-SA 版权协议转载请附上原文出处链接及本声明。原文链接https://blog.csdn.net/m0_37962600/java/article/details/79951780
