CS144（2024 Winter）Lab Checkpoint 4: interoperating in the world

0.Overview

check4.pdf

与预想中不同的是，今年的 checkpoint4 相当简单，没有 TCP 状态机实现、没有新的 C++ 代码要写，只需要测试能否使用 tcp_minnow_socket.hh 中对先前实验代码进行封装得到的 socket，完成 checkpoint0 中最先写好的 webget.cc 的功能。

如果你是从我的 checkpoint0 说明一路跟着写上来、并且使用了 WSL2 + Docker 搭建实验环境的，那么这里有一个很不幸的消息：因为微软商店中 WSL 没有开启所有的 Linux 内核功能（如本次实验需要使用的 CONNMARK），因此在使用 Docker 创建的容器的情况下运行实验代码中的脚本 tun.sh 会出现包括但不限于如下的错误提示：

根本原因是脚本 tun.sh 需要使用 /dev/net/tun 创建多个虚拟的隧道网络设备，但是因为 WSL 没有开启这部分的功能，所以导致了报错出现。
当然也可能是我问题没有找对，不过我实际使用时更换一个新环境就能够直接通过测试。
总之有什么新见解或者解决方案欢迎留言告诉我。

我能够找到的解决方法主要有两种：

1. 自己从源码开始编译一个完整的 WSL2 内核，并用这个新内核替换你自己电脑上的 WSL2；
   • Warning: Extension CONNMARK revision 0 not supported, missing kernel module
   • Run Wireguard as a client on Win10 with WSL2
   • Include module nf_conntrack in WSL2 kernel
2. 整一个完整的 Ubuntu 23.10 环境。

很显然这次实验不值得我去花时间重新编译一个 WSL2，我采取的方法是使用 VirtualBox 重新安装一个 Ubuntu Server 23.10.

选择 server 版的好处有很多，比如不用承担因为 GUI 界面引入的更大体积的安装包、不用考虑安装过程中因为分辨率问题点不到哪些确认按钮等等之类的问题。

安装过程很简单，下载 iso 镜像，根据一些别的教程在 vbox 中添加虚拟机、添加启动盘，启动虚拟机，一路选择 default 选项并设置好用户名，最后根据 lab0 的软件需求部署环境即可。反正本次实验也不需要添加更多的 C++ 代码，所以之后就可以使用 SSH 连接开始测试。

1.Using your TCP implementation in the real world

言归正传，本次实验需要使用之前的实验代码封装一个 TCPSocket，在代码中也被称为 CS144TCPSocket。

文档提示：每次你重启虚拟机时，都需要执行指令 ./scripts/tun.sh start 144。其他部分跟着给出的指令来就好。

如果之前的实验都很符合文档需求，那么测试结果应该是没有问题的。如果不行，就需要跟随文档使用 tshark 之类的工具进行 debug 了。

2.Collecting data

虽然本次实验的代码量很少，但是最后反倒新加了一个收集网络数据并分析的环节。

具体来说，我们需要从文档给定的 3 个地址中，任选一个距离实验设备有至少 100 ms 延迟的地址，并使用指令 ping -D -n -i 0.2 hostname | tee data.txt 收集至少两个小时的 ping 日志数据。

我个人选择的是 41.186.255.86（南非移动通信网络集团），因为只有这个域名在不开启代理的情况下，是可以连接并且距离我的实验设备（地理位置在中国广东）的延迟是大于 100 ms 的。

3.Analyzing data

收集了至少两个小时的数据后，这里就需要对数据进行分析了。如果每 0.2 秒收到一个 ICMP 报文响应，那么两个小时的数据预计能够收到 36000 条报文响应。当然这可能因为网络波动、物理设备性能比较好，会有一定的上下波动。

文档要求我们使用随便哪一个程序语言和可视化工具分析我们的 ICMP 响应报文日志数据。这里可以选择 MATLAB 或者什么别的语言，我用的是 Python + numpy + matplotlib，好用强大还简单。

文档要我们回答以下几个问题：

1. 计算丢失了多少个报文响应，找出实际上发送了多少个报文，并计算总交付率。
2. 最长的连续响应报文长度是多少？
3. 最长的连续丢失响应报文长度是多少？
4. 随着时间的推移，丢包事件是趋向于独立还是相关？即：
   • 假设 request #N 被接收，那么 request #(N+1) 也被接收的概率是多少？
   • 假定 request #N 丢失，那么 request #(N+1) 没有丢失的概率是多少？
   • 这些数字与 1 中的总交付率相比如何？能否判断出丢包是独立的还是突发性的？
5. 最小的 RTT 是多少？
6. 最大的 RTT 又是多少？
7. 画一个 RTT 随时间变化的曲线，将 x 轴标记为真实时间，y 轴为 RTT 的毫秒数。
8. 绘制 RTT 的分布直方图或累积分布函数，观察其分布形状。
9. 绘制 ping #N 的 RTT 与 ping #N+1 的 RTT 之间的散点图；x 轴应当是第一个 RTT 的毫秒数，y 轴应当是第二个 RTT 的毫秒数。RTT 的相关性如何？
10. 有什么总结？

analyzer.py

这些东西整体上不难，分析好问题需求后猛猛写代码就行。需要注意的是：如果你给的数据范围特别大（大到超出了 65536 条），可能会导致图表因为个别 RTT 极值而被放大到失真的程度。

虽然只要网络质量够差劲，极少条数据也能达到这样的效果就是。

这里给出我关于问题 1-9 的图表和数据分析报告。因为代码只是随便搓的，所以可能有些数据的算法不太严谨/正确，看个乐就好。

反正我也不用交 pdf 报告。