NAME: 孙浩
ID:2024141530052
可以看到 alice.txt 已经成功上传
# 1.
可以看到客户端 IP： 192.168.1.102
客户端 TCP 端口： 1161
# 2.
服务器 IP： 128.119.245.12
服务器端口： 80
# 3.
我自己抓包时，客户端 IP 地址为 10.35.155.245，客户端使用的 TCP 源端口号为 65125。服务 gaia.cs.umass.edu 的 IP 地址为 128.119.245.12，目标端口为 80。
# 4.
可以看到 SYN 报文的序列号是 0，因为 Flags:0x002 (SYN)
# 5.
SYNACK 的序号： 0
确认号 ACK 字段值： 1
服务器对客户端初始 SYN 的序号 0 加 1
原因：因为 SYN = 1 且 ACK = 1 ，所以这是 SYNACK 段
# 6.
含有 HTTP POST 命令的 TCP 段序号是 164041
# 7.
1）前 6 个段的序号：
Segment 1: 1
Segment 2: 566
Segment 3: 2026
Segment 4: 3486
Segment 5: 4946
Segment 6: 6406
2）发送时间、ACK 到达时间、RTT：
Segment 1: sent 0.026477 , ACK 0.053937 , RTT 0.02746
Segment 2: sent 0.041737 , ACK 0.077294 , RTT 0.035557
Segment 3: sent 0.054026 , ACK 0.124085 , RTT 0.070059
Segment 4: sent 0.054690 , ACK 0.169118 , RTT 0.11443
Segment 5: sent 0.077405 , ACK 0.217299 , RTT 0.13989
Segment 6: sent 0.078157 , ACK 0.267802 , RTT 0.18964
可以使用 wireshark 自带的计算 RTT 的工具
3）EstimatedRTT，按
EstimatedRTT = 0.875 × EstimatedRTT + 0.125 × SampleRTT
计算：
收到 ACK1 后： 0.02746
收到 ACK2 后： 0.0285
收到 ACK3 后： 0.0337
收到 ACK4 后： 0.0438
收到 ACK5 后： 0.0558
收到 ACK6 后： 0.0725
# 8.
前 6 个 TCP 段长度分别是 0，1460，1460，1460，1460，1460
# 9.
最小接收窗口： 5840 bytes ，因为后续窗口变大但是并没有达到限制，没有出现因为接收端缓存不足而限制发送端的情况。
# 10.
Statistics → TCP Stream Graph → Time-Sequence-Graph(Stevens)
看时间 - 序列图时，客户端发往服务器的序号整体单调递增
# 11.
接收端大多数 ACK 是累计确认 1460 字节，也就是一个 MSS；但在部分情况下，会出现延迟确认，每两个段一起确认一次，累计确认 2920 字节。
# 12.
第一个数据段序号： 1
最后一个 ACK 的确认号： 164091
所以数据量： 164091 - 1 = 164090
第一个数据段时间： 0.026477
最后 ACK 时间： 5.455830
所以总时长： 5.455830 - 0.026477 = 5.4294 s
吞吐量： 164090 / 5.4294 ≈ 30.222 KByte/s
# 13.
从 Time-Sequence-Graph (Stevens) 图中可以看出，TCP 连接开始阶段具有明显的慢开始特征，前期发送速率增长较快；大约在 1~1.5 秒后，增长趋势逐渐平缓，可认为进入拥塞避免阶段。与理想模型相比，实际抓包结果没有呈现出完全规则的指数增长和线性增长，而是出现了分批发送、增长不完全平滑的现象。这说明真实网络环境中，TCP 行为还会受到多种因素的影响。
# 14.
根据我自己抓取的 TCP trace，Time-Sequence-Graph (Stevens) 显示连接方向为 客户端向服务器上传文件的方向。图中序列号在连接开始后约 0 ~ 1.5 s 内快速增长到约 150 kB ，说明发送端在初始阶段快速增加发送数据量，可认为这是 TCP 慢开始阶段。约 1.5 s 后序列号基本保持不变，说明文件主体已经发送完成，因此拥塞避免阶段在本次抓包中不明显。与理想模型相比，实际图像不是平滑的指数增长和线性增长，而是呈现阶梯式、成批发送的特征。
