** 这个实验我没有约到没有问题的机子（连续三台机子都是坏的...）因此仅供参考
1、根据2.6中步骤3回答：TCP的连接和建立采用的是： 三次握手 方式，PCA是 主动打开方(C) ，PCB是 被动打开方(S) 。先点击发送再点击接收，会出现什么问题？为什么？
答：先点击发送再点击接受会导致连接失败，而且如果没有应用进程被动打开，那么主动打开的应用进程无法建立连接。
因为C/S模式下，若Server没有启动，那么Client就连接不上。服务器和客户端的结合需要看TCP状态机，必须存在被动打开方才能够连接。
2、根据2.6中步骤5，结合预习报告，分析TCP连接的建立过程，根据TCP建立过程的三个报文，先填写下表：
| 字段名称 |
第一条报文 |
第二条报文 |
第三条报文 |
| 报文序号 |
3 |
4 |
5 |
| Sequence Number |
0 |
0 |
1 |
| Acknowledgement Number |
|
1 |
1 |
| Ack |
0 |
1 |
1 |
| Syn |
1 |
1 |
0 |
3、根据2.6中步骤6回答：
TCP连接建立时，其报文首部与其它TCP报文不同，有一个“Option”字段，它的作用是什么，值为多少？结合IEEE802.3协议规定的以太网最大帧长度分析此数据是怎样得出的。
答：Option字段的值中包含一个最大报文段长度（Maximum segment size，MSS），取C/S两方承载的MSS中取较小的值。MSS应用于数据传送阶段，在本实验中得到的MSS值是1460 bytes。
MSS＝最大MTU长度－IP首部固定长度（20）－TCP首部固定长度（20）＝1500－20－20＝1460
4、根据2.6中步骤7：结合预习报告，分析TCP连接的释放过程，选择TCP连接撤消的四个报文，将报文信息填入下表。
| 字段名称 |
第一条报文 |
第二条报文 |
第三条报文 |
第四条报文 |
| 报文序号 |
385 |
386 |
387 |
388 |
| Sequence Number |
355911 |
1 |
1 |
355912 |
| Acknowledgement Number |
1 |
355911 |
355912 |
2 |
| Ack |
1 |
1 |
1 |
1 |
| Fin |
1 |
0 |
1 |
0 |
5、根据2.6中步骤8：分析TCP数据传送阶段的前8个报文，将报文信息填入下表。
| 报文序号 |
报文种类 (发送/确认) |
序号字段 |
确认号字段 |
数据长度 |
被确认报文序号 |
窗口 |
| 6 |
发送 |
1 |
1 |
140 |
|
5840 |
| 7 |
确认 |
1 |
1401 |
0 |
13 |
8400 |
| 8 |
发送 |
1401 |
1 |
1460 |
14 |
5840 |
| 9 |
发送 |
2861 |
1 |
1460 |
|
5840 |
| 10 |
确认 |
1 |
2861 |
0 |
|
11680 |
| 11 |
确认 |
1 |
4321 |
0 |
16 |
14600 |
| 12 |
发送 |
4321 |
1 |
1460 |
17 |
5840 |
| 13 |
确认 |
1 |
5781 |
0 |
19 |
17520 |
请写出TCP数据部分长度的计算公式。数据传送阶段第一个报文的序号字段值是否等于连接建立时第三个报文的序号？
答：TCP数据部分长度 = IP总长度 - IP首都长度 - TCP首部长度
数据传送阶段第一个报文的序号字段值 等于 连接建立时第三个报文的序号。
6. 根据3.6.1中“ 滑动窗口机制和窗口侦查机制分析”步骤6回答：
（1） 分析数据发送部分的前几条报文，描述发送方发送窗口的变化，并解释为什么？
答：发送方发送窗口的大小线性增大，每次递增2920。
因为数据发送部分前几条报文时处于慢启动状态，拥塞窗口cwnd指数规律增长，而滑动窗口rwnd线性增长。一般而言rwnd < cwnd，而且发送窗口=min[cwnd, rwnd]，因此发送窗口的大小也随着rwnd线性增长。
（2） 指出从哪个序号的报文能够看出接收端开始休眠，并解释理由。
如果接收缓存大于65535，在接收窗口值持续减少前接收端已开始休眠。
如果接收缓存小于等于65535，在接收窗口值持续减少时接收端开始休眠。
因为其后通告的接收窗口越来越小，（左边沿在不断向右移动，而右边沿不再移动），接收方在窗口范围外的可用缓存已被使用完，表明接收方在窗口范围外的可用缓存被已确认的数据占据着，应用程序进程没有再从缓存中读取这些已确认的数据，即表明其已开始休眠
（3）分析文件send2-组座号-tcpsndwnddata.txt，选中三次握手连接建立后的前4条报文记录（3条DATA报文、1条ACK报文，序号为4、5、6、7），记下发送方发送窗口的相关值（rcv_wnd , snd_wnd_left , snd_wnd_point , snd_wnd_left+cwnd , snd_wnd_left+rcv_wnd , (snd_wnd_point- left)）。按下表分析计算接收方（及发送方）的窗口的相关值。
5号报文（sender----data---->receiver）
| rcv_wnd |
snd_wnd_left |
snd_wnd_pointer |
snd_wnd_left+cwnd和 snd_wnd_left+rcv_wnd |
snd_wnd_point- left |
|
| 发送方发出报文 |
5840 |
2379935191 |
2379938051 |
2379939571 |
2860 |
| 发送窗口右边沿 |
2379941031 |
||||
| 通告的接收窗口 |
接收窗口左边沿 |
接收窗口指针 |
接收窗口右边沿 |
在接收缓存中的数据量（即未确认的数据） |
|
| 接收方接到DATA前 |
2 |
2379935191 |
2379936591 |
2379935191 |
1400 |
| 接收方接到DATA后 |
3 |
2379935191 |
2379938051 |
2379935191 |
2860 |
6号报文（sender----data---->receiver）
| rcv_wnd |
snd_wnd_left |
snd_wnd_pointer |
snd_wnd_left+cwnd和 snd_wnd_left+rcv_wnd |
snd_wnd_point- left |
|
| 发送方发出报文 |
5840 |
2379935191 |
2379939511 |
2379939571 |
4320 |
| 发送窗口右边沿 |
2379941031 |
||||
| 通告的接收窗口 |
接收窗口左边沿 |
接收窗口指针 |
接收窗口右边沿 |
在接收缓存中的数据量（即未确认的数据） |
|
| 接收方接到DATA前 |
3 |
2379935191 |
2379938051 |
2379935191 |
2860 |
| 接收方接到DATA后 |
3 |
2379935191 |
2379939511 |
2379935191 |
4320 |
7号报文（receiver ----ack----> sender）
| 通告的接收窗口 |
接收窗口左边沿 |
接收窗口指针 |
接收窗口右边沿 |
在接收缓存中的数据量（即未确认的数据） |
|
| 接收方发出ACK |
4 |
2379935191 |
2379935191 |
2379941031 |
0 |
| rcv_wnd |
snd_wnd_left |
snd_wnd_pointer |
snd_wnd_left+cwnd和 snd_wnd_left+rcv_wnd |
snd_wnd_point- left |
|
| 发送方接到ACK后 |
8400 |
2379936591 |
2379939511 |
2379942431 2379944991 |
2920 |
| 发送窗口右边沿 |
2379944991 |
||||
| 发送方接到ACK前 |
5840 |
2379935191 |
2379939511 |
2379939571 |
4320 |
| 发送窗口右边沿 |
2379941031 |
||||
（1） 根据文件send2-组座号-tcpsndwnddata.txt中发送方的发送窗口相关值进行分析，接收方开始休眠后，描述接收窗口的变化，指出窗口收缩、窗口合拢、窗口张开对应的开始报文序号，并记下send2-组座号-tcpsndwnddata.txt文件中的对应报文的数值记录（pkt_seqno，pkt_type，..，……）。
窗口收缩：右边沿向左移动，RFC强烈不建议使用，一般不发生。
窗口合拢：窗口的左边沿向右边沿靠近，发生在接收窗口持续减小期间：
166 snd_data
167 rcv_ack
168 snd_data
169 snd_data
170 snd_data
171 snd_data
172 snd_data
173 rcv_ack
174 snd_data
175 rcv_ack
窗口张开：当窗口的右边沿向右移动时将允许发送更多的数据，一般发生在休眠结束后通告大窗口时
180 rcv_ack
181 snd_data
182 rcv_ack
183 snd_data
184 rcv_ack
7. 根据3.6.1中“ 滑动窗口机制和窗口侦查机制分析”步骤7回答：
写出窗口侦查开始的报文序号，窗口侦查报文数据长度、窗口侦查报文发送的时间规律。
窗口侦查报文指的是Keep-Alive报文，长度为5840
每相邻两条窗口侦查报文Keep-Alive报文 时间差组成的数据序列的规律：成倍增加规律
13、根据4.6中步骤7：
（1）分析UDP报文结构：选中第一个UDP报文，将UDP协议树中各字段名、字段长度、字段值、字段表达信息，填入下表。并绘制UDP报文结构，详细绘制UDP协议树字段。
| 字段名 |
字段长度 |
字段值 |
字段表达信息 |
| Source Port |
2 bytes |
murray(1123) |
源端口：1123 |
| Destination |
2 bytes |
1030 |
目的端口：1030 |
| Length |
2 bytes |
13 |
报文长度：13 |
| Checksum |
2 bytes |
0x301d |
校检码：0x301d |
（2）UDP报文结构与TCP报文结构有什么区别？
答：UDP报文仅有源端口、目的端口、报文长度、校检码和数据组成。
TCP除此之外还有seq、ack、偏移字段等字段，用于保证传输的可靠性。
（3）在步骤5交换机S1和S2之间的网线拔掉期间，PCA向PCB发送的UDP消息，在步骤6交换机S1和S2之间的网线重新插上之后，PCB是否还能收到？请解释为什么会出现这种现象？
答：PCA会向PCB发送i’m fine, and you?
在步骤6交换机S1和S2之间的网线重新插上之后，PCB不能收到。因为UDP是不可靠传输协议，因此因为拔掉网线而发送失败后报文就丢失了。
（4）综合分析TCP协议和UDP协议的不同之处。
| UDP |
TCP |
| 无连接 |
面向连接 |
| 不可靠传输，无流量控制和拥塞控制 |
可靠传输，使用流量控制和拥塞控制 |
| 支持一对一、一对多、多对一、多对多交互通信 |
只支持一对一通信 |
| 面向报文 |
面向字节流 |
| 首部8字节 |
首部20~60字节 |
| 适用于实时应用 |
适用于要求可靠传输的应用。 |