实验八_传输层 应用层协议分析（笔记）
实验内容：
实验过程：
1.
1)
2）
以管理员运行模式执行以下终端命令：
可知网站ip:123.125.114.144
Dns:114.114.114.114
如上图可知dns解析的是tcp；
3)
如上图可知；
HTTP版本号：1.1
可知服务器向浏览器返回的状态码： 200 OK
从上图可知请求的是：/apipic/app/icon5/MobilInputBundLe.ico
数量是1
2.
1)
- SYN(Synchronize sequence numbers):同步***，用来发起一个连接请求
- FIN(No more data from sender):表示发送端发送任务已经完成（既断开连接）
原端口/目的端口(16bit)：
我们都知道网络之前的通信是不通主机之间的通信，就windows系统而言通过查看任务管理器我们可以知道一台主机有许多进程，当我们发送数据时怎 么知道要发送到对方主机那个进程里呢，所以这就是端口号的作用，在TCP报文中包涵了源端口/目的端口，源端口标识了发送进程，目的端口标识了接收方进 程。在此报文中我们的源端口号是0xc4b7 = 50359, 目的端口是0x01bb = 443如下图所示:
***(32bit)：
Sequence Number这个是发送***，用来标识从源端向目的端发送的数据字节流，它表示在这个报文端中的第一个数据字节的顺序号，系列号是32位的无符号类型， 序号表达达到2^32 - 1后又从0开始， 当建立一个新的连接时，SYN标志为1，系列号将由主机随机选择一个顺序号ISN(Initial Sequence Number)。此报文中的***是0x2eb35ac1早已超过了2^32 - 1 所以这里的***为0，如下图:
确认号(32bit)：
Acknowledgment Number它包涵了发送确认一端所期望收到的下一个顺序号。因此确认***应当是上次成功接收到数据的顺序号加1。只有ACK标志为1时确认序号字段才 有效。TCP为应用层提供全双工服务，这意味着数据能在两个方向上独立的进行传输，因此连接的两端必须要保证每个方向上的传输数据顺序。
窗口大小(16bit)：
表示源主机最大能接收多少字节，下图大小是0x2000。
TCP的三次握手和四次挥手
整个过程如下图所示：
TCP的三次握手
Tcp3次握手是如下所示，我们通过分析数据包来验证是否如下图所示：
第一次握手：
主机192.168.1.54向主机42.81.93.34发起连接请求，可以看在这时的SYN被置为1了，***Seq = 0，如下图
第二次握手：
主机42.81.93.34应答主机192.168.1.54，可以看到这个时候的应答包含了SYN，ACK，ACK = Seq + 1 = 1， 这里的Seq是第一次握手发起请求的Seq值，并不是下图报文中红框表示的Seq值。
第三次握手：
主机192.168.1.54应答主机42.81.93.34，可以看到这个时候的应答包是ACK， ACK = Seq + 1 = 1，这里的Seq是第二次握手主机42.81.93.34产生的序列值
至此，便可验证三次握手
TCP四次挥手
第一次挥手
将设客户端首先发起断开连接，那么客户端回想服务端发送FIN置为1的TCP包，请求断开连接，意思就是我要断开和你的连接了，但是如果你还有数据没有发送完给我你不必立即关闭连接。
第二次挥手
服务端收到客户端的断开连接请求立即响应一个ACK报文，意思是告诉客户端你发起的断开连接请求我已经收到了，但是我还没有准备好，你在等一会，这个时候服务器端可能还有数据要发送给客户端，也可能正在准备释放资源。这个时候客户端进入FIN_WAIT状态，继续等待服务端的FIN报文。
第三次挥手
服务端确认已经发往客户端的数据已经发送完成，则向客户端发送FIN报文，告诉客户端我已准备好关闭连接了。
第四次挥手
客户端收到服务端的FIN报文后就知道可以关闭连接了，当时它还是不确定，怕服务端还是不知道我要关闭连接了，所以发送一个ACK包后进入TIME_WAIT状态，如果服务端没有收到ACK那么服务端则可以发起重传，如果收到了ACK报文，客户端等待2MSL后已然没有收到回复，则证明服务端已经正常关闭了，那我也就可以关闭连接了。
3.DNS协议分析;
1）
如上图我们可知默认DNS服务器地址是：114.114.114.114
ping www.baidu.com
将自动进行域名解析,默认发送4个ICMP报文.
启动Wireshark,选择一个有效网卡,启动抓包.
默认ping一次百度发送4个icmp包（数量自己设置，添加选项-n即可设置数量），一次DNS解析，在控制台回车执行完毕后停止监控.
可以发现DNS为应用层协议,下层传输层采用UDP,再下层网络层是IP协议,然后是数据链路层的以太网帧.
2）查询百度的IP及CNAME记录
命令及反馈：
如果没有记录显示，则表示解析不成功
3）使用指定的DNS查询
命令及反馈：
4）
客服端口：52906
服务器端口是53
查询的类型是：IN(0X0001)
4.OICQ协议分析
1）抓包接口设置成本地连接
点击start,登录qq，输入oicq进行过滤qq包
找到第一个OICQ,点击后，点击oicq-IM software
可以看到自己登录的QQ号码为1244657296
本机ip：
本机IP=192.168.3.1，第一个是从本机发送到目的IP的，第二个是从服务器返回来的
分析数据报协议
百度qq端口历史：
QQ是通过UDP协议进行数据传输的，8000是腾讯QQ服务器的端口。
早先的版本QQ客户端所用的端口是4000，如果再开第2，3个QQ时会依次打开4001，4002端口。
现在的版本QQ客户端所用的端口是5000，如果再开第2，3个QQ时会依次打开5001，5002端口。
即是qq服务器端口80，客服端动态分配；
如上图查看运行端口55362
这是UDP协议部分的信息，destination port = 8000，这在国内主要是QQ服务器使用的端口号，
Source port:55362这是qq服务端当前使用的端口
分析以太网（数据链路层）
如上图可知ip src:192.168.3.1 && ip des:182.254.33.149
、
如上图可知Hangzhou_8d:28:3c(0c:da:41:8d:28:3c) 表明路由器厂商是杭州的一个厂商
如上图可知qq传输数据是加了密的；使用的hash单向加密，所以我们查看上述这样的qq数据流是乱码的，哈哈。
5.
1）
我要分析的DHCP包如下：
2）DHCP发现包：
从以上图可知，客服端目前没有ip地址，因为发现阶段是以广播的形式发送。也就是网络上的DHCP服务器都是可以收到此数据包。
现在我们分析包里面各选项的值的情况如下：
从以上图可知：DHCP消息类型是53;客服端标识符：长度为7，硬件类型以太网0x01等信息都可获取
3）分析DHCP提供阶段数据
各选项分析：
4）DHCP请求包分析：
各选项分析：
5）DHCP确认包分析：
各选项分析：
以上就是DHCP的四个阶段
- 实验注意事项：
1)HTTP协议分析较难，在此只是进行简单的分析；注意抓包之前清空arp表与刷新dns
2)TCP协议中的三次握手，四次挥手要先掌握原理，然后进行抓包分析，这样易上手
3）DNS主要使用nslookup命令进行相关信息查询
4）OICQ即qq使用的协议，在抓取的相关包中，可以清楚的查看相关各项信息，需要注意的是，该协议是单向加密，打个比方，即用户编辑的信息是A，发送到服务器为B，A->B是通过相应的**进行加密，这只有生产，**的人可知，其他角色无法获取
4）对于DHCP我们只要理解到它的四个阶段；分别是发现，提供，请求，确认即可
- 实验参考资料：
1)https://blog.****.net/qq_39290490/article/details/81784324
2)https://www.cnblogs.com/jiangzhaowei/p/7998515.html
3) https://www.cnblogs.com/kabi/p/6113768.html
4)https://blog.****.net/qq_40770143/article/details/84347364
5）https://wenku.baidu.com/view/e62e588fbe23482fb5da4cce.html