TCP可靠传输与重传分析

Posted 2023-02-17 Y0n1an

实验步骤

sysctl -w net.ipv4.tcp_rmem='4096 65536 65536' 

降低缓存数，减少窗口值

sysctl -w net.ipv4.tcp_sack=0

避免使用sack重传算法
然后执行之前的脚本，模拟我上述几篇文章的网络拓扑
执行之后，用iptable设置规则，以10%的丢包率模拟丢包

ip netns exec RA iptables -I FORWARD -d 192.168.57.254 -m statistic --mode random 
--probability 0.1 -j DROP

然后执行

ip netns exec ns56A bash

模拟ns56A终端
执行

ip netns exec ns57C bash

模拟ns57C终端
在ns56A中创建一个大小为100K字节大小的文件

truncate -s 100K 100K.0

同时命名为100k.0
在ns56A中抓包

ip netns exec ns56A wireshark & 

ns57c中4499打开TCP服务，并将输出流重定向到100k.1文件。

nc -lv 4499 > 100K.1

在ns56A中输入套接字中的目的地址的ip和端口

nc 192.168.57.254 4499 < 100K.0

将输入重定向到文件100.k
当读到一个EOF时，会主动断开TCP。

重传分类

本实验要求捕获到TCP超时重传事件，快重传事件和部分ACK事件，你在实验中捕获这几种事件时，操作系统为主机ns56A上的TCP客户程序分配的端口号是多少，如果这些事件是分多次捕获的，请分别给出客户进程的端口号。截图说明。
抓了四次，有一次实验具有超时重传，快重传、另一次有部分ACK事件，主机端口分别为39814，39810

超时重传

根据捕获：可以得到下表


根据序号，找到了一个快重传，而快重传丢掉了后才会触发超时重传

原报文段

通过这个信息，可以看到对前一个报文段得ack确认


结合两张图，一次正常确认+19，总共20次，触发过快重传，快重传和超时重传间隔0.213486144-0.000793191，所以RTT差不多是0.21秒

快重传

可总结得到如上两张表
同样ACK确认总共3+1 = 4：

部分ACK重传

如图，36657的快重传报文的编号，对应丢失报文段是53，ns56A快重传前发送最后一个报文段的编号是68
这是丢失报文段数据

快重传报文

快重传前最后一个报文

部分ACK
因为部分ACK确认字小于快重传前最后一个字节的编号38105<52584，所以是一个部分ACK。对于TCP快重传，如果收到部分ACK，立即重传部分ACK所指向的报文。所以下一个报文重传38105