计算机网络实验—尝试分析报文
1. 基本信息
| 姓名 | 学号 | 班级 | 网络是否连通 | 能否正常抓取报文 |
|---|---|---|---|---|
| lx | 2022 | 计算 | 是 | 能 |
注：可以用PING来测试网络的连通性
2. 建立网络拓扑结构
3. 配置网络参数
3.1 客户端
3.2 服务端
4. 抓取报文并分析
将Packet Tracer切换到Simulation模式。在客户端的浏览器（在Packet Tracer，点击设备 --> Desktop --> Web Browser）输入设置的域名，按回车，点击Play开始抓取报文。对抓取到的报文进行如下分析。
4.1 概览
4.2 DNS域名解析
报文1~3：DNS域名解析
报文4~6和8：TCP连接建立（三次握手）
报文9~11和7：发送与收取数据（浏览器与目的主机开始HTTP访问过程）
报文12~15：与目的主机断开TCP连接（四次挥手, 但是中间两次被合并）
4.2.1 DNS请求报文
基础结构
1.报文头 DNS Message
QDCOUNT：表示报文请求段中的问题记录数
ANCOUNT：表示报文回答段中的回答记录数
NSCOUNT：表示报文授权段中的授权记录数
ARCOUNT：表示报文附加段中的附加记录数
2.查询报文 DNS Query
NAME：表示查询名，一般为需要查询的域名
TYPE：表示查询类型
CLASS：表示查询类
TTL：表示生存时间，表示的是资源记录可以缓存的时间
LENGTH：表示资源数据长度
4.2.2 DNS响应报文
1.报文头 DNS Message（同请求报文）
2.查询报文 DNS Query（同请求报文）
3. 应答报文 DNS Answer
NAME：表示资源记录包含的域名
TYPE：表示资源记录的类型
CLASS：表示资源记录的类
TTL：表示资源记录可以缓存的时间
LENGTH：表示资源数据长度
IP：表示域名解析的结果
4.2.2 DNS响应报文
注：这里取dns请求报文中的UDP进行分析
SOURCE PORT：源端口为1025
DESTINATION PORT：目的端口为53
LENGTH：标明UDP头部和UDP数据的总长度字节为0x0022
CHECKSUM：校验和，用来对UDP头部和UDP数据进行校验
DATA：UDP数据部分
4.3 TCP连接建立
4.3.1 概述
- 箭头上方的内容如下：
- 编号，你抓取到报文的编号，
4.1节对应的编号。 ID，IP报文首部的标识符，如0x0004。seq，序号。ack，确认号。
- 编号，你抓取到报文的编号，
- 箭头下方的内容如下：
ACK，表示前面的确认号字段是否有效。只有当 ACK=1 时，前面的确认号字段才有效。SYN，在建立连接时使用，用来同步序号。
4.3.2 连接请求报文
客户端首先创建传输控制模块TCB，在建立TCP连接时，向B发出连接请求报文段，同时将首部中的同步位SYN置为1，表示这是一个连接请求报文。初始序号seq = x = 0，显然这里确认号ack = 0。
TCP规定，SYN报文（即SYN=1的报文段）不能携带数据，但要消耗掉一个序号，所以客户端发出的下一个报文序号要加1。
4.3.3 连接接受报文
服务器在收到连接请求报文段后，向客户端发送确认报文。该报文段中需要把SYN和ACK位都置1，表示这是一个连接接受报文。确认号ack = x + 1 = 1，同时为自己选择一个初始序号seq = y = 0。
这个报文段也不能携带数据，但是同样需要消耗掉一个序号。
4.3.4 第三次握手
TCP客户端在收到服务器的确认后，还需要给客户端给出确认。确认报文段的ACK置1，确认号ack = y + 1 = 1，而自己的序号seq = x + 1 = 1，之后才正式建立连接。
TCP的标准规定，ACK报文段可以携带数据，但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是
seq = x + 1 = 1。
4.4 HTTP
4.4.1 HTTP请求报文
初始序号seq = x = 1, 确认号ack = 1(在上面TCP连接建立中服务器发来的最后一条报文的序号为1)
确认位ACK = 1, PSH: 1(告诉对方收到该报文段后是否立即把数据推送给上层。)
HTTP REQUEST:
HTTP Data:Accept-Language: en-us
Accept: */*
Connection: close
Host: xinxin.liu
Accept-Language：客户端可接受的自然语言
Accept：客户端可识别的响应内容类型列表;星号 “ * ” 用于按范围将类型分组，用 “ */* ” 指示可接受全部类型，用“ type/* ”指示可接受 type 类型的所有子类型
connection：连接方式(close 或 keepalive)
Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机
4.4.2 HTTP响应报文
初始序号seq = y =1, ack: 100
确认位ACK = 1, PSH = 1
HTTP RESPONSE:
HTTP Data: Connection: close
Content-Length: 369
Content-Type: text/html
Server: PT-Server/5.2
Content-Length: 包体长度
Content-Type: 包体类型
Server: 服务器应用程序软件的名称和版本
4.4.3 IP数据报
4.5 TCP连接释放
4.5.1 概述
4.5.2 释放请求报文
客户端打算断开连接，向服务器发送FIN报文(FIN标记位被设置为1，1表示为FIN，0表示不是)，FIN报文中会指定一个序列号，之后客户端进入FIN_WAIT_1状态。客户端将初始的序列号seq置为x = 100, 确认号ack置为472, 数据长度为99(osi模型中的数据)。
TCP规定，FIN报文段即使不携带数据，它也消耗掉一个序号。
4.5.3 释放确认报文
客户端在收到连接释放报文段后立即发出确认，确认号为ack = x + 1 = 101，序列号seq置为472，同时将确认号ACK置为1。然后客户端进入关闭等待状态，此时TCP连接进入半关闭状态，即客户端已经没有数据要发送，但是服务器如果要发送数据，客户端仍然要接收。
4.5.4 最终连接释放请求报文
服务器在发送完数据后，向客户端发送断开连接请求。将FIN置为1，表示数据已经发送完毕，要求释放运输连接。同时序号seq = 472，确认号ack = x+1 = 101。
在本次实验中，并没有出现第三次挥手，原因是在第二次挥手过后，服务器并没有数据继续发送给客户端，于是服务器将第二次挥手时就将
FIN置为1，表示数据已经发送完毕，要求释放运输连接。
4.5.5 最终连接释放确认报文
客户端收到来自服务器的连接释放请求报文后，最后发送对这次请求的确认报文。序号seq = x + 1 = 101，确认号ack = y + 1 = 473（显示为472，这个是我的疑问），确认位ACK置为1.
关于这次报文的ack，很明显服务器发来的请求报文中的序号为472，但是本次报文中的确认号却还是472，我将这个问题写到了第五部分。
4.5.5 最终连接释放确认报文
5. 实验过程中遇到的问题及解决办法
**问题1：为什么HTTP响应中的tcp报文的ack为100?（已解决） **
在http请求报文中,我们可以发现序列号
seq和确认号ack都为1, 但是响应报文中的确认号为100, 说明客户端已经成功接受了前面序号0~99的数据, 现在希望收到序号为100的数据, 但是我在请求报文中并没有找到任何关于报文长度的信息.
最终在osi模型界面发现了该信息:
问题2：为什么只有3次挥手？（已解决）
其实我一开始就怀疑是不是两次报文合并发送了，但是因为网上的一些评论诸如“挥手一定是四次，不可能会有合并的情况”所误导，导致我一直认为是软件显示出问题了。但是后来在知乎上发现其实是存在合并的情况，只是现实中发生的比较少，可能只是因为本次实验简单，所以在客户端发出释放连接的请求后，也没有数据继续传送，所以将ACK和FIN合并到一个报文中发送，确实效率更高。
问题3：为什么 “生成” 了两次HTTP请求报文？（模糊）
产生这个问题的原因是因为我一直认为诸如这种形式的报文的意思就是，在PC中产生了这个报文，但是如果是用这种方法来思考就会出现问题了。
在经过‘单步调试’后，我发现第一个HTTP请求报文是在第二次握手—也就是客户端发回连接建立确认报文段后就产生了，但是！！！！！在客户端发出第三次握手的确认报文时，并没有将这个HTTP报文一起发出去，而是将这个报文一直放在了内部—缓冲区，发出最终的确认报文段后一段时间，才将这个请求报文发出……
我陷入了沉思，为什么要用这种效率低的方法呢？与其这样，那为什么不在发出第三次握手的报文后再生成HTTP请求报文呢？简而言之，为什么这个红框会出现两次呢？
在网上查阅了一番，无果，我只能用我自己的角度来解释。因为我了解到一次TCP连接时可以传输多条HTTP请求的，因为如果每个HTTP请求都要经过建立连接—传输—释放连接这样的流程，那么效率将会大大降低，但是日常的使用中，我们又会经常在用一个时间点请求多个HTTP资源，所以TCP连接允许客户端一次传送多个HTTP连接。
在了解了以上这些，我可以大胆推断，客户端会在收到第二次握手的确认报文后开始准备所需要的所有HTTP请求报文，同时发出第三次的握手报文，同时将准备好的HTTP请求报文放在缓冲区。等到所有的请求报文都准备完毕后，再拿出来连续发送给客户端（我有试想过所有的报文打包成一个，但是这样应该会导致某些参数发生冲突，所以应该还是一条条发送）。
问题4：响应报文中的ack？（未解决）
在4.5.5中，我描述了我的问题，在客户端发送最后一次的连接释放请求响应报文时，并没有遵循确认号为请求报文的序号+1的规则（根据计算机网络（第七版）谢仁希），让我感到费解，至今，我还没有想出一个合理的答案，只能暂时认为是软件的错误。
问题5：关于注册。（纯吐槽）
这个问题是花的时间最多的，一开始贪图便宜，下载了6.2免登录版本，还自以为聪明地加了汉化，结果做实验做到一半发现很不好用，包括窗口无法调大小，模拟的界面没法一次看很多报文，ui过于老旧，汉化不全等等，所以还是去下了8.0的版本。
下载还好，问题就是注册，好不容易注册好了CISCO思科的账号，发现登陆还是不行，要我用思科网院的账号登陆，我又去注册了思科网院的账号，再登陆，还是不行。。。还得报个网课班，中间其实还发生了很多问题，查了无数的博客教学，花了一整个下午来搞好这个软件问题，心累。
参考资料：
(10条消息) TCP三次握手详解-深入浅出(有图实例演示)_jun2016425的博客-CSDN博客_tcp三次握手
(10条消息) TCP四次挥手详解_oOoOoOooOO的博客-CSDN博客_tcp四次挥手
TCP报文格式解析 (biancheng.net)
IP数据报格式详解 (biancheng.net)
(10条消息) TCP报文段中的序号和确认号_老王不让用的博客-CSDN博客_报文段序号
TCP四次挥手中间两次会合并成一次吗？ - 知乎 (zhihu.com)
IP数据报格式详解 (biancheng.net)
(10条消息) TCP报文段中的序号和确认号_老王不让用的博客-CSDN博客_报文段序号
TCP四次挥手中间两次会合并成一次吗？ - 知乎 (zhihu.com)
计算机网络（第七版） 谢仁希