TCP数据流与窗口管理
2017-02-19 22:06:04 0 举报AI智能生成
tcp数据流与窗口管理
作者其他创作
大纲/内容
1.以SSH为例
1.在ssh中，一个输入字符会有4个TCP数据段
1.客户端的输入
2服务器的确认
3.服务器的回显
4.客户端会服务器回显的确认
PSH置位：表示在发送完该报文之后，发送端无再其他数据包要发送
延时确认
TCP不会对每个数据包都返回ack,而是会积累ack,用于批量数据传输。但是又不能任意时间的延长，因为可能会导致发送端以为数据包丢失而引起不必要的重传，
实际中延时确认时间最大200ms
Linux采用一种动态调节算法，可以在每个数据包都返回ack和传统的延时ack中相互切换
在小数据包传输中，采用另外的算法与延时ack相结合，即Nagle算法
2.Nagle算法
1.算法：在一个TCP连接中，如果还有没有收到确认ACK的在传数据(还有数据在信道中传输)，那么发送端长度小于SMSS的报文段就不能被发送，直到收到全部的ACK。且在收到ACK之后，发送端需要将这些小数据报整合在一起拼成一个数据报进行发送。该方法迫使TCP实现停等(stop and wati)，且它实现了自时钟控制：ACK返回越快，数据传输也就越快
在相对高延迟的广域网传输中，更需要减少小包的数量，该算法使得单位时间内发送的报文段数量更少，即RTT控制着发包的速率
根据实例抓包，可以发现，发送端每次发送数据包的时间呈一定的规律性
原因：每次发包大致上都是已经没有数据包在网络上传输了，然后再发送，再等待，那么间隔就是RTT时间
延时ACK和Nagle算法相结合
存在的问题：
若客户端采用Nagle算法，而服务器采用延时ACK，可能会导致死锁。因为客户端需要服务器返回ack，表明网络中无在传数据，才能继续发送数据包，而服务器的延时ack又在等待客户端接下来的数据包，然后累积返回ack。此时双方都在等待对方，就导致了死锁。
滑动窗口实现流量控制
每个tcp报文段中包含报文段序列号，ack号和窗口大小，窗口大小表示发送方为接下来的数据传输预留了多大的存储空间
如果TCP应用程序空闲，就会处理这些数据，窗口大小就可以保持不变
如果程序繁忙或者是处理不过来，就会导致这些数据需要排队等待处理，然后窗口就会缩小。
若程序一直不处理，则tcp会采取策略，使得发送端完全停止发送新数据，因为可能没有新的空间用来存储数据，此时窗口大小就可以为0
TCP两端以字节为单位，各维护一个发送窗口和接收窗口
1.关闭：左窗口右移，当数据得到ACK确认时，窗口会减小
2.打开：右窗口右移，当接收端中的已确认数据得到处理，可用缓存增大，窗口也就随之增大
3.收缩：右窗口左移，主机需求RFC并不支持该做法，但TCP必须能处理这一问题
左窗口坐边界不能左移，因为它代表的是已确认的ACK的号，具有累积性，不能返回
当左右边界相等的时候，称为0窗口，此时发送端不能再发送数据，发送端将开始探测对方端口
零窗口与TCP持续计时器
接收端在恢复可用空间时，会向发送端发送一个窗口更新（window update,不包含数据），但是该ack不保证可靠传输，可能会丢失。所以发送端会维护一个持续计时器。当超时时，会向服务端查询是否有可用空间，计时器会触发窗口探测的传输，强制要求服务器返回ACK
窗口仅包含一个字节的数据，采用TCP可靠传输（丢失重传），持续计时器采用指数退避时间来计算超时
糊涂窗口综合征（Silly Window Syndrome-SWS）
出现该问题时，交换的数据段大小不是全长的，而是一些较小的数据段。比如，在某一个时刻，服务端可用存储空间为0。发送端暂停发送数据。过了一会，服务端有了十几的空间，此时发送端探测之后发现有十几的空间，就会立即发送长度十几的报文段过来，又占满了空间。如此循环，极大的降低了传输效率
解决办法
客户端
1.不发送小报文段，且需要有Nagle算法来控制何时发送
1.全长的报文段可以发送（Mss）
2.数据段长度>=接收端通告过的最大窗口值的一半
3.满足以下任一一个条件即可
1.某一ACK不是自己期盼的（没有未经确认的在传数据）
2.该连接禁用Nagle算法
服务器端
1.不应通告小的窗口值。在窗口增至MSS或者接收端最大可用缓存的一半（取2者较小值）之前，不应该通告比这小的窗口值
大容量缓存与自动优化
TCP协议上层应用不能指定tcp接收端缓存大小，由操作系统来指定一个较大的固定值或者是动态变化的计算值
与窗口管理相关的攻击
主要形式为资源耗尽
通告窗口较小会使得TCP传输减慢，因此会更长时间的占用连接资源
0 条评论
下一页
