唐门问心

为论文做Linux内核编程实验总能遇到一些神奇的现象，现记录如下。一、修改IP Fragment Offset（失败）根据导师的需求，我在Netfilter Local Out钩子函数中把13bit fragment offset填为自定义的数据，同时保证flag DF位=1，即“不能分片”（Don‘t Fragment），希望各种网络软硬件设施能允许我发送这样的包。我装载

两台Ubuntu Server，采用Cubic TCP协议通信。故意让接收方丢弃iperf报文。重传时间分别为1s，2s，4s，8s，16s，以此类推。理论依据是RFC 6298，RTO的初始值设定为1s 。参考2.1节内容：Until a round-trip time (RTT) measurement has been made for a segment s

在某次TCP反复重传中，观察IP checksum的变化规律。由于只有identification在增加，可以发现checksum的值在减小。这其实和checksum的反码计算有关，参考谢希仁《计算机网络》4.2节首部检验和的计算：先把IP首部划分成16位字的序列，并把checksum置0. 用反码运算把所有16位字相加后，把得到的结果求反码写入检验和。第1个数据包：

答案：不是。以下分别给出发送方和接收方的wireshark抓包情况。发送方：接收方：可以看到，发送方33和34两个大包被接收方合成了33号大包。备注：发送方TCP checksum没有计算是因为TSO。截图时，接收方忘了开启wireshark的TCP checksum验证。事实上，开启TSO后，发包的那方在wireshark中的看到的总是TCP chec

IP头的identification的值由IP层维持的计数器产生，每产生一个数据包，计数器就加1,，并赋值给ID。ID并不是序号，因为IP是无连接服务。在IP分片（fragmentation）时，此值将被复制到各个片的ID，这样能使各个片最终能被重新组装为原来的数据包。一 、在开启TSO后，内核每次发送大包，观察到连续两个大包的ID值和MTU、大包大小有关。Iperf TCP发包如下图

操作系统采用Ubuntu 14.04，CPU有4物理核8逻辑核。10G网卡为Intel X520。关掉主机网卡的TSO、GSO功能。sudo ethtool –K p1p1 tso offsudo ethtool –K p1p1 gso offiperf服务器端使用10G网卡，执行iperf -s -p 12003 -i1客户端多次执行如下命令，但每次启动的进程数会变化：

1.  准备知识1.1  Iperf命令假设iperf服务端为主机tian04，使用TCP协议，那么在控制台执行以下两个命令开启服务器进程。iperf-s -p 12000 -i1iperf-s -p 12001 -i1假设iperf客户端为主机tian05，tian06。注意，与1G的实验环境使用的命令不同，当关闭网卡TSO、GSO时，R320服务器无法使用一个进程达到满带宽

需要主动开启时间戳选项，命令为：sysctl net.ipv4.tcp_timestamps=1实验发现精度太低，太多的包采用同样的值，这样不便于实现基于时间戳识别数据包的功能。随手摘录网上其他的人写的文档：双方各自维护自己的时间戳，时间戳的值随时间单调递增（规定为1ms-1s/次，常见值为1ms、10ms）。