甲:发送“seq:x,len:y”给乙;
乙:回复的确认号,x+y,表示它收到了x+y之前的所有字节;
综合上面SEQ和ACK的计算,可以发现:
(1)理论上,接收方回复的Ack恰好就等于发送方的下一个seq号;
(2)TCP的确认是可以累积的;
(3)这几个参数的意义:
包乱序时,接收方只要根据Seq号从小到大重新排好就行了,保证了TCP的有序性;
有包丢失时,接收方判断丢了哪些包的方法:通过前一个Seq+Len的值与下一个Seq的差,保证了TCP的可靠性;
现实中存在一些限制,如接收方的缓存(接收窗口)可能一下子接受不了这么多数据,而网络的带宽也不一定足够大,一口气发太多会导致丢包事故,TCP的发送窗口就是发送方一口气可以发送的数据量。
Tcp Dup Ack xxx#y 代表了数据段丢失的TCP状态,xxx代表数据丢失的位置,#后代表第几次丢失文;
快速重传是对超时重传的优化,当触发3个及以上dup ack包时,会触发重传;但是如果丢了报,且没有触发快速重传,就只能等待超时重传了。
下面是丢包对大文件和小文件影响的区别,原因就在于上面一段的描述:
说明乱序了,前一个包没有收到,收到后面的包了。
下面抓包来自于手机利用FTP下载文件速率小的案例。
tcp重复确认:表示该ACK包发生了丢失,导致发送方对包进行了重传,网关测抓包,发现,最严重的一个丢包是,一个包重传了37次:(同一个包的dup ack的时间间隔约10ms,可以以725这个包为例分析,该包重传了37次);
“SACK方案”
同样对网关测抓包TCP头中的sack信息进行分析:
一个dup ack包,725#3,是725号包的第三次重传ack,内容如下:
SACK=32121~33581和35041~37961,而ACK=29201,这样,FTP server就会知道:
32121~33581和35041~37961都已经收到了,而前面的29201~32120之间的2920个字节没有收到;
故:
原文:http://www.cnblogs.com/studyofadeerlet/p/7485298.html