本实验使用Wireshark抓取通信数据包。1）观察IP数据包的结构。2）观察TCP的三次握手与四次挥手过程。
预备知识：IP数据报结构、TCP数据报结构。
目录
原理
1. IP数据报结构
2. TCP数据报结构
3. TCP三次握手与四次挥手流程
步骤与结果
1. 使用Wireshark抓取ping命令的完整通信过程的数据包
2. TCP的“三次握手”和“四次挥手”的过程
问题讨论：
总结：
原理
1. IP数据报结构
2. TCP数据报结构
3. TCP三次握手与四次挥手流程
1）三次握手
A 客户进程向B服务器进程发出连接请求报文段，其首部中的SYN=1，并选择一个序列号 SN=i，表明传送数据的第一个字节的序号是 i。此时，TCP客户进程进入SYN-SENT状态。
B 服务器收到A的连接请求报文段后，如同意连接，则回答确认报文段。确认报文段首部中的 SYN=1，ACK=1，其序列号SN=j，确认号AN=i+1。此时，TCP服务器进程进入SYN-RCVD状态。
③ A 客户进程收到确认报 文段后，还要向 B 回送确认。确认报文段首部中的ACK=1，确认号AN=j+1，序列号SN=i+1。此时，运行客户进程的A告知上层应用进程连接已建立(或打开)，进入ESTABLISHED状态。而运行服务器进程的 B 收到 A 的确认后，也通知上层应用进程，同样也进入ESTABLISHED状态。
2）四次挥手
若由A向B发出连接释放报文段，其首部中的FIN=1，选择一个序列号 SN=u，它是前面已传送过的数据的最后一个字节的序列号加1，表示发送数据已告结束，主动关闭TCP连接。此时A进入FIN-WAIT-1状态，等待来自B的确认。
② B收到释放连接报文后，如同意连接，则回答确认报文段。确认报文段首部中的SYN=1，ACK=1，其序列号SN=v，确认号AN=u+1。然后B进入CLOSED-WAIT状态，同时通知高层应用进程。这样，从A到B的连接就释放了，连接处于半关闭(half-close)状态。A收到来自B的确认报文段后，就进入FIN-WAIT-2状态，等待B再发来连接释放报文段。
③ 此后，B不再接收来自A的数据，但B若有数据要发往A，仍可继续发送。若B向A的数据发送完毕后，就向A发出连接释放报文段。在此报文段中应将FIN=1，SN=v (它是前面已传送过的数据的最后一个字节的序号加1)。另外，必须重复上次已发送过的确认号AN=u+1。此时B进入LAST-ACK状态，等待A发来的确认报文段。
④ A收到连接释放报文段后，必须对此发出确认，其确认号为AN=v+1，而序列号SN=u+1。然后进入到TIME-WAIT状态。B收到了来自A的确认报文段后，就进入CLOSED状态，并撤消相应的传输控制块TCB，就结束了本次的TCP连接。
注意：进入到TIME-WAIT状态后，本次TCP接还没有完全释放掉，必须再经过时间等待计时器设置的时间(=2MSL)后，A才进入到CLOSED状态，此时整个连接才全部释放。
步骤与结果
1. 使用Wireshark抓取ping命令的完整通信过程的数据包
1）抓包过程：
① 确定目标地址：选择www.baidu.com作为目标地址；② 配置过滤器：针对协议进行过滤设置，ping使用的是ICMP协议，抓包前使用捕捉过滤器，过滤设置为icmp；③ 启动抓包：点击start开始抓包，在命令提示符下键入“ping www.baidu.com”；④ 抓包结束后退出。
2）抓包结果：
（图1）是抓包结果。从图中可见，一共有8个ICMP数据包，其中4个本机至服务器的ICMP数据包，4个服务器至本机的ICMP数据包。与Windows的ping命令发送四个测试数据包一致。
以第一条本机至服务器的ICMP数据包为例，可在中间窗格看到帧的成分，其中第三行为IP数据报的首部部分，第四行为IP数据报的数据部分。选中第三行，可在下方窗格看见IP首部对应的十六进制代码，共有20位十六进制数，即首部一共20B。
展开中间窗格第三行，可以看见已经解析出的IP首部的详细信息。也可根据IP协议包结构，依据下方窗格的十六进制数解析出IP首部详细信息。
图1 抓包结果
3）分析抓取的IP头结构：
版本号 | 头长度 | 封包长度 | 封包标志 | 标志 | 片段偏移 |
IPv4 | 5×4B = 20B | 60B | 0xE621 | 0 | 0 |
存活时间 | 协议 | 校验和 | 源地址 | 目的地址 | |
64 | ICMP | 0x3FBD | 192.168.43.157 | 112.80.248.76 |
2. TCP的“三次握手”和“四次挥手”的过程
HTTP协议需要可靠的数据传输，因此在传输层使用的TCP协议。
1）抓包步骤：
① 多次试验后，选择一个合适的网站，例如：中国知网（www.cnki.net）。② 在命令提示符中键入“ping www.cnki.net”，查看中国知网的IP地址为103.52.172.83。③ 打开Wireshark软件，不设置输入捕获条件，直接开启抓包。④ 在浏览器中访问中国知网，此时Wireshark中将会出现大量的数据包。⑤ 等待片刻后，结束抓包。并在显示过滤器中输入“tcp&&ip.addr==103.52.172.83”，来筛选TCP数据包，并且源地址或目的地址中包含“103.52.172.83”。⑥ 观察筛选出的数据包，选定合适的本机应用端口，如“55131”。⑦ 继续在显示过滤器中输入“&&tcp.port==55131”，确定后将可看见完整流程的TCP交互数据包。⑧ 为了更直观的观看“三次握手”与“四次挥手”流程，可进一步限制帧长度，将较长的帧过滤掉。如“&&frame.len<100”。
2）抓包结果：
（图2）为筛选后的“中国知网”的TCP抓包结果。从图中上方窗格，可清晰看见“三次握手”流程（前三行）和“四次挥手”流程（后五行），其中倒数第二行黑色结果为错误报文。
图2 “中国知网”抓包结果
3）结果分析：
① 第一次握手：选中（图2）第一条数据包，并在中间窗格选中IP数据报的数据部分。在下方窗格将会高亮数据部分的十六进制代码（图3）。
（图3）十六进制代码中“b1 fe 11 8f”为Seq序列号，“80 02”部分即包含了ACK、SYN、FIN等标志。根据分析可知，SYN位已经被置1，其余位均为0。
图3 “中国知网”第一次握手
② 第二次握手：（图4）中，可以看到，产生了新的序列号Seq，为“8f fa f4 5a”。并且确认序列号为第一次握手的Seq+1，为“b1 fe 11 90”。且ACK和SYN位均被置1。
图4 “中国知网”第二次握手
③ 第三次握手：（图5）中，可见确认序列号为第二次握手的Seq+1，为“8f fa f4 5b”，且ACK被置1。
图5 “中国知网”第三次握手
④ 第一次挥手：（图6）中，Seq为“8f fa fb 4b”，确认序列号为“b1 fe 1a f5”，且FIN和ACK标志均被置1。中国知网为主动方。
图6 “中国知网”第一次挥手
⑤ 第二次挥手：（图7）中，Seq为第一次挥手的确认序列号“b1 fe 1a f5”，确认序列号为第一次挥手的Seq+1，“8f fa fb 4c”。且ACK标志位被置1。表明被动方已经收到主动方发送的FIN请求。
图7 “中国知网”第二次挥手
⑥ 第三次挥手：（图8）中，相比（图7）的第三次挥手，此次挥手FIN标志和ACK标志位均被置1，表明被动方也无更多数据需要发送，可以断开连接。
图8 “中国知网”第三次挥手
⑦ 第四次挥手：（图9）中，ACK标志位被置1，主动方向被动方发送收到FIN的回复，此时四次挥手完成。
图9 “中国知网”第四次挥手
4）问题分析：
绝大多数服务器的四次挥手流程并非发送四次数据包，通常仅有三个数据包，如（图10）。
服务器收到请求后，如果没有更多数据需要发送，则将第二次挥手与第三次挥手合为一个数据包同时发送给本机。选中第二个挥手数据包，可以看到FIN和ACK标志同时被置1了。
图10 “四次挥手”仅发三个数据包示例
问题讨论：
1. 有哪些常用的应用是需要TCP的三次握手和四次挥手建立、释放连接的？
使用TCP协议的应用均需要三次握手和四次挥手来建立、释放连接。如：HTTP、FTP、SMTP、SNMP、Telnet等。
2. TCP三次握手过程中出现无应答现象时，该协议是如何工作的？
在服务器安全领域中，其中一种常见的拒绝服务（Denial of Service, DoS）攻击就是SYN泛洪攻击。如果TCP三次握手过程中出现了无应答现象，就相当于请求方发起了SYN泛洪攻击。
当攻击方发送第一次握手后，服务器方会返回SYN-ACK进行确认。如果此时攻击方采用源地址欺骗等手段使服务器收不到ACK，服务器将会在一定时间内处于等待ACK的半连接状态。由于TCP连接数是有限的，如果同时有大量的虚假连接，服务器将会停止响应，形成DoS（拒绝服务）攻击。
通过优化服务器系统设置，降低SYN超时时间，可以使服务器尽快释放半连接的资源占用。也可采用SYN Cookie方式保存请求方的IP地址，如果某个IP短时间内重复SYN请求，可以对其进行拦截。
总结：
本次实验采用Wireshark软件抓取ping包，分析了IP协议的首部字段，验证了IP协议的理论学习内容。同时，抓取了TCP“三次握手”和“四次挥手”的数据包，直观的感受了TCP协议的工作流程。
在本次实验抓取TCP包的过程中，经验证发现多数服务器在“四次挥手”过程中，如果主动方发起请求后被动方无更多数据需要发送，则通常将第二次握手和第三次握手过程合二为一发送给主动方，可减少对资源的占用。
TCP三次握手过程有一个缺陷至今仍未有更好的替代标准从根源上解决。在三次握手过程中，如果请求方发起第一次握手后消失，不对被请求方的确认进行回复，则会导致被请求方在一段时间内挂起。如果同时出现多个这类请求，则会导致被请求方拒绝服务。在服务器中，需合理设置SYN超时时间，防止SYN泛洪攻击。
