目录
- 数据链路层
- 熟悉 Ethernet 帧结构
- 了解子网内/外通信时的 MAC 地址
- 掌握 ARP 解析过程
- 网络层
- 熟悉 IP 包结构
- 考察 TTL 事件
- 传输层
- 熟悉 TCP 和 UDP 段结构
- 分析 TCP 建立
- 应用层
- 了解 DNS 解析
- 解 HTTP 的请求和应答
数据链路层
熟悉 Ethernet 帧结构
- 使用 Wireshark 任意进行抓包，熟悉 Ethernet 帧的结构，如：目的 MAC、源 MAC、类型、字段等。
- 从图中可以看出目的MAC，源MAC，类型为IPv4，还有padding段，这个表示帧中的数据不足46字节，然后进行补充的。图中下两层网络层和传输层也就是帧的数据部分。
你会发现 Wireshark 展现给我们的帧中没有校验字段，请了解一下原因。
这是因为有时校验和会由网卡计算，这时wireshark抓到的本机发送的数据包的校验和都是错误的，所以默认关闭了WireShark自己的校验。
了解子网内/外通信时的 MAC 地址
- ping 你旁边的计算机（同一子网），同时用 Wireshark 抓这些包（可使用 icmp 关键字进行过滤以利于分析），记录一下发出帧的目的 MAC 地址以及返回帧的源 MAC 地址是多少？这个 MAC 地址是谁的？
源MAC20:16:b9:84:96:c6
目的MAC:d8:c4:97:8c:85:4f
- 然后 ping qige.io （或者本子网外的主机都可以），同时用 Wireshark 抓这些包（可 icmp 过滤），记录一下发出帧的目的 MAC 地址以及返回帧的源 MAC 地址是多少？这个 MAC 地址是谁的？
目的MAC：00:74:9c:9f:40:13
源MAC：20:16:b9:84:96:c6
- 再次 ping www.cqjtu.edu.cn （或者本子网外的主机都可以），同时用 Wireshark 抓这些包（可 icmp 过滤），记录一下发出帧的目的 MAC 地址以及返回帧的源 MAC 地址又是多少？这个 MAC 地址又是谁的？
目的MAC:00:74:9c:9f:40:13
源MAC：20:16:b9:84:96:c6
- 通过以上的实验，你会发现：
访问本子网的计算机时，目的 MAC 就是该主机的
访问非本子网的计算机时，目的 MAC 是网关的
请问原因是什么？
如果本子网内进行访问，只需要在子网中进行MAC寻址即可，不需要通过网关，但是如果访问非本子网内，那就需要通过网关，而使用网关MAC应该是因为外网非常大，只需要先找到网关，进而具体到主机
掌握 ARP 解析过程
- 为防止干扰，先使用 arp -d * 命令清空 arp 缓存
- ping 你旁边的计算机（同一子网），同时用 Wireshark 抓这些包（可 arp 过滤），查看 ARP 请求的格式以及请求的内容，注意观察该请求的目的 MAC 地址是什么。再查看一下该请求的回应，注意观察该回应的源 MAC 和目的 MAC 地址是什么。
- 再次使用 arp -d * 命令清空 arp 缓存
- 然后 ping qige.io （或者本子网外的主机都可以），同时用 Wireshark 抓这些包（可 arp 过滤）。查看这次 ARP 请求的是什么，注意观察该请求是谁在回应
- 通过以上的实验，你应该会发现，
ARP 请求都是使用广播方式发送的
如果访问的是本子网的 IP，那么 ARP 解析将直接得到该 IP 对应的 MAC；如果访问的非本子网的 IP， 那么 ARP 解析将得到网关的 MAC。
请问为什么？
ARP是先看缓存表中是否有目的地址，如果有就直接可以获取到目的MAC。如果没有就需要发送ARP请求，通过广播来获取目的MAC。如果目的地址是属于同一个子网，直接能够进行通信，而不在同一个子网中就需要通过网关才能够访问。
网络层
熟悉 IP 包结构
- 使用 Wireshark 任意进行抓包（可用 ip 过滤），熟悉 IP 包的结构，如：版本、头部长度、总长度、TTL、协议类型等字段。
从图中可以看出有版本为4和对应的二进制，然后有头部长度为20字节，总的长度包括数据有139字节，TTL为64（这个一般是2的整数次幂）然后协议类型为6TCP。
- 为提高效率，我们应该让 IP 的头部尽可能的精简。但在如此珍贵的 IP 头部你会发现既有头部长度字段，也有总长度字段。请问为什么？
总长度字段是在下一层封装时要进行判断是否进行分段，因为以太网帧的数据部分最大为1500字节，这个字节段应该是为了更加节省时间才设置的。头部字节长度是因为头部往往是不确定的，因为有需要可选项，这导致不同的IP包会有不同的头部长度。
考察 TTL 事件
- 在 IP 包头中有一个 TTL 字段用来限定该包可以在 Internet上传输多少跳（hops），一般该值设置为 64、128等。
- 在验证性实验部分我们使用了 tracert 命令进行路由追踪。其原理是主动设置 IP 包的 TTL 值，从 1 开始逐渐增加，直至到达最终目的主机。
请使用 tracert www.baidu.com 命令进行追踪，此时使用 Wireshark 抓包（用 icmp 过滤），分析每个发送包的 TTL 是如何进行改变的，从而理解路由追踪原理。
- 在 IPv4 中，TTL 虽然定义为生命期即 Time To Live，但现实中我们都以跳数/节点数进行设置。如果你收到一个包，其 TTL 的值为 50，那么可以推断这个包从源点到你之间有多少跳？
前面验证性实验提到过ping命令中TTL的相关知识，TTL一般是2的整数次幂，如果TTL为50，那就找到距离50最近的2的整数次幂就是64，然后经过64-50+1=15个，也就是说从64跳到50，这里说明一点，这个就是找到距离最近的数字，不会是从128跳到50的。
传输层
熟悉 TCP 和 UDP 段结构
- 用 Wireshark 任意抓包（可用 tcp 过滤），熟悉 TCP 段的结构，如：源端口、目的端口、序列号、确认号、各种标志位等字段。
- 目的端口号：443
- 源端口号：59341
- 序列号和确认号：0
- SYN标志位
- 用 Wireshark 任意抓包（可用 udp 过滤），熟悉 UDP 段的结构，如：源端口、目的端口、长度等。
- 源Port：10158
- 目的Port：80（熟悉端口）
- 长度：16
- 由上大家可以看到 UDP 的头部比 TCP 简单得多，但两者都有源和目的端口号。请问源和目的端口号用来干什么？
因为当主机上运行不同的程序时，如果只靠网络层IP地址只可以具体到主机，但是通过端口号，就可以进行不同主机之间的程序通信。
分析 TCP 建立
- 打开浏览器访问 qige.io 网站，用 Wireshark 抓包（可用 tcp 过滤后再使用加上 Follow TCP Stream），不要立即停止 Wireshark 捕获，待页面显示完毕后再多等一段时间使得能够捕获释放连接的包。
- 请在你捕获的包中找到三次握手建立连接的包，并说明为何它们是用于建立连接的，有什么特征。
第一次
第二次
第三次
应用层
了解 DNS 解析
- 先使用 ipconfig /flushdns 命令清除缓存，再使用 nslookup qige.io 命令进行解析，同时用 Wireshark 任意抓包（可用 dns 过滤）。
- 你应该可以看到当前计算机使用 UDP，向默认的 DNS 服务器的 53 号端口发出了查询请求，而 DNS 服务器的 53 号端口返回了结果。
- 你可能会发现对同一个站点，我们发出的 DNS 解析请求不止一个，思考一下是什么原因？
如果本机已经缓存了对应IP的DNS解析，那就直接进行域名解析，但是如果没有的话，那就直接上层访问，直到能够解析为止。
解 HTTP 的请求和应答
- 打开浏览器访问 qige.io 网站，用 Wireshark 抓包（可用http 过滤再加上 Follow TCP Stream），不要立即停止 Wireshark 捕获，待页面显示完毕后再多等一段时间以将释放连接的包捕获。
- 请在你捕获的包中找到 HTTP 请求包，查看请求使用的什么命令，如：GET, POST。并仔细了解请求的头部有哪些字段及其意义。
- Accept:告诉WEB服务器自己接受什么介质类型
- Content-Type:WEB 服务器告诉浏览器自己响应的对象的类型
- Content-Length:WEB 服务器告诉浏览器自己响应的对象的长度
- Cache-Control:用来指示缓存系统
请在你捕获的包中找到 HTTP 应答包，查看应答的代码是什么，如：200, 304, 404 等。并仔细了解应答的头部有哪些字段及其意义。
- Server：浏览器服务器的类型,
- Transfer-Encoding：数据的传送格式,
- Date：当前的GMT时间
- Content- Type：MIME类型
- Cache-Control：指定请求和响应遵循的缓存机制
新一次 qige.io 网站的页面同时进行抓包，你会发现不少的 304 代码的应答，这是所请求的对象没有更改的意思，让浏览器使用本地缓存的内容即可。那么服务器为什么会回答 304 应答而不是常见的 200 应答？
因为之前进行过缓存，304代码是缓存中存在一样的没有更改的内容，只需要从缓存中获取即可，不要服务器重新发送一次。
