lab 地址 ：lab4-doc
代码实现：lab4-code
完整目录:
0. ByteStream
1. StreamReassembler
2. TCPReceiver
3. TCPSender
4. TCPConnection
5. ARP
6. IP-Router
1. 目标
lab4 的目标是结合 TCPSender 和 TCPReceiver，实现 TCPConnection，完成了 TCPConnection 后 TCP 部分的内容就基本完成了。
TCPSender 和 TCPReceiver 已经完成了基本的收发包操作，支持了定时重传，乱序包重组等特性，接下来需要支持 TCPConnection 的 连接发起/关闭 等功能，根据 TCPConnection 的不同状态，在发包时调整 TCPSegment 的 header flag（ackno，win，rst 等）
这里需要注意的是，lab4 需要在官方提供的 VM 实验环境下运行，否则 ipv4 部分会 timeout ，无法执行通过
2. 实现
这里将 TCPConnection 的几个实现重点划分为如下：
- 发起连接
- 写入数据，发送数据包
- 接收数据包
- 关闭连接
- 丰富超时重传机制
2.1 发起连接
发起连接这个功能 TCPSender 基本已经实现了，只要主动调用 TCPSender::fill_window ，就可以填充一个 SYN 包。
void TCPConnection::connect() {
_sender.fill_window();
flush_send(); // 将 sender 的 segment push 到 connection 的发送队列中
}
2.2 发包
写入数据，发包的流程也相对比较简单，就是将数据写入 TCPSender 的 ByteStream 中，然后填充窗口发送即可。
size_t TCPConnection::write(const string &data) {
size_t write_size = _sender.stream_in().write(data);
_sender.fill_window();
flush_send(); // 将 sender 的 segment push 到 connection 的发送队列中
return write_size;
}
2.3 接收数据包
接收数据包的流程主要如下：
- 调用
TCPReceiver::segment_received接收数据包 - 如果是 ack 包，调用
TCPSender::ack_received更新对端窗口 size 和 对端确认情况。 - 如果数据包有数据（没数据不需要回复，防止无限 ack），需要回复一个 ack 包
- 检查连接关闭情况（2.4 展开）
void TCPConnection::segment_received(const TCPSegment &seg) {
_time = 0;
// if the rst (reset) flag is set, sets both the inbound and outbound streams to the error state and kills the connection permanently
if (seg.header().rst) {
unclean_shutdown();
return;
}
_receiver.segment_received(seg);
if (seg.header().ack) {
_sender.ack_received(seg.header().ackno, seg.header().win);
}
// make sure ack
if (seg.length_in_sequence_space() > 0) {
_sender.fill_window();
if (_sender.segments_out().empty()){
_sender.send_empty_segment();
}
}
flush_send();
clean_shutdown();
}
2.4 连接关闭
连接关闭的情况比较复杂，主要分为 clean shutdown 和 unclean shutdown。
unclean shutdown
unclean shutdown 的情况比较简单，当收到 TCPSegment 的 header.rst 标记为 true 的情况下，此时可以直接关闭连接，同时需要设置 inbound stream 和 outbound stream 为 error 状态。这种方式关闭 TCPConnection 就称为 unclean shutdown
inbound stream 指的是 receiver 的 ByteStream
outbound stream 指的是 sender 的 ByteStream
clean shutdown
clean shutdown 有 3 个前提条件：
- 本地 inbound stream 的
unassembled_bytes == 0（所有字符串都组装完毕）并且已经end_input，也就是收到了 Fin 报文。 - 本地 outbound stream 已经完全发送完毕（
eof == true） - 对端成功收到所有 outbound stream 发送的数据包对应的 ack （注意是对端）
当满足 条件 1 后，根据条件 3 是否百分百成立，会出现两种情况：
- lingering after both streams end
条件 2 满足，本地发送的数据已经全部收到 ack，并且已经成功接收到对端的所有数据，此时还需要等待一段时间，因为接受到数据后发送给对端的 ack 可能会丢失，如果直接关闭的话，对方可能会一直尝试重发数据包。 - passive close
条件 2 未满足，而条件 1 成立的时候，条件 3 也就确定成立了，这样等到条件 2 满足时，就可以直接关闭连接。
为什么条件 2 未满足，而条件 1 成立的时候，条件 3 也就确定成立了？这里是结合了 TCPSegment 的可靠性来实现的。由于普通的 ack 包不会重传，那么只要让它带上数据就可以了。当条件 2 未满足的情况下，说明还有数据需要传输（最起码有个 Fin 包），也就是说后续的包都是可靠的，且会带上 ackno，那么对端在收到包的时候，就能确定自己发送的包都被成功接收了。
那么此时条件 3 也就满足了，当条件 2 也满足的时候，就能直接关闭了。
3. 测试
测试过程中犯的几个错误：
- 没有按照对端窗口大小发包，发了额外的数据包，对端丢弃了，导致需要重传，进而导致 test case 的执行时间超时了。
- 超时时间等配置需要读取 TCPConnection::cfg 的配置变量，而不是直接读取 TCPConfig 中的静态常量，test case 中会动态调整 cfg 的配置，不使用 cfg 在某些情况下会导致超时（配置的重传时间比 TCPConfig 中的短）
