目标IP Sequence Number Acknowledgement Number ACK比特位 SYN比特位 172.16.1.2 172.16.1.2 1395441158 3695045942 3695045942 1395441159 172.16.1.2 3695045942 1395441159 172.16.1.2 1395441159 3695045943 1 1 1 0 1 1 1 0 结合步骤3、4所填的表，理解TCP的三次握手建立连接和四次握手的释放连接过程，理解序号、确认号等字段在TCP可靠连接中所起的作用。 练习二：理解TCP数据包的编号与确认
1. 主机B使用Web浏览器访问“http://172.16.1.1”。 2. 设置过滤条件（提取TCP, HTTP协议），捕获数据。
停止捕获数据，在捕获到的数据中观察主机B所发送的报文，并回答以下问题：
目标IP地址为多少？IP首部的协议字段值为多少？ 目的地址为：172.16.1.1 IP首部的协议字段值为：0x6 (代表tcp协议) 源端口和目标端口分别为多少？ 源端口：1026 目的端口：80
TCP首部中Sequence Number为多少？Acknowledgement Number为多少？哪些控制比特置为了1？
Sequence num：0，ack num:0 syn置为了1.
3. 在捕获到的数据中观察主机B所接受的报文，并回答以下问题：
目标IP地址为多少？IP首部的协议字段值为多少？ 目的地址为：172.16.1.2 IP协议字段的值为：0x6 (tcp) 源端口和目标端口分别为多少？ 源端口：80 目的端口：1025
TCP首部中Sequence Number为多少？Acknowledgement Number为多少？哪些控制比特置为了1？ Sequence num:0 ack num:1 练习三：TCP的重传机制
1. 关闭服务器A的HTTP服务。
2. 主机B编辑发送给服务器A的TCP数据报，其中应用选择“HTTP”，源端口设为
“1026”，报文数据大小设为“0”。
3. 设置过滤条件（提取TCP协议），捕获数据。
4. 停止捕获数据。查看捕获的报文，是否相同？为何有这种现象产生？
相同，当服务器没有收到的时候，就会产生重传
【思考问题】
1. 试用具体例子说明为什么在运输连接建立时要使用三次握手。说明如不这样做可能
会出现什么情况。 三次握手完成了两个重要的功能，一个是双方做好发送数据的准备工作，即双方都知道彼此已准备好，一个是允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。假如把三次握手改为两次握手，就会可能出现死锁的情况。如，计算机A和B之间的通信，假定B给A发送一个连接请求分组，A收到了这个分组，并发送了确认应答分组。按照两次握手的协定，A认为连接已经成功地建立了，可以开始发送数据分组。可是，B在A的应答分组在传输中被丢失的情况下，将不知道A是否已准备好，不知道A建议什么样的序列号，B甚至怀疑A是否收到自己的连接请求分组。在这种情况下，B认为连接还未建立成功，将忽略A发来的任何数据分组，只等待连接确认应答分组。而A在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
2. 使用TCP对实时话音数据的传输有没有什么问题？使用UDP在传送数据文件时会
有什么问题？ TCP延时比较大，因为其具有拥塞控制算法，对于实时性要求高的业务来说，有其必然的缺点。UDP没有拥塞控制，只能提供尽力而为的服务，所以会出现丢包现象，且不重传。所以不适合传准确性要求比较高的，不允许有错误的等数据文件。