Contents
TCP协议简单介绍
1.TCP的应用场景
TCP为应用层协议提供可靠传输服务，发送端按顺序发送数据，接收端按顺序接收数据，其间若发生丢包、乱序等情况，TCP须负责重传和排序。
TCP的应用场景：
（1）应用程序传输的文件需要分段传输，比如在浏览器访问网页或者QQ传输文件时，在传输层均会选用TCP进行分段传输。
（2）客户端程序和服务端程序需要多次交互才能实现应用程序的功能，比如接收电子邮件使用的POP3和发送电子邮件使用的SMTP，传输文件使用的FTP，在传输层使用的都是TCP。
2.TCP 连接建立
“三次握手”
客户端向服务端发起通信，客户端的TCP模块与服务端的TCP模块之间将通过“三次握手”来建立TCP会话。
所谓三次握手，是指在TCP会话的建立过程中总共交换3个TCP数据包。
3.TCP连接释放
“四次握手”
为了确认最后发送的数据接收方正确收到，数据发送结束后，还需要给接收端发送释放连接的请求，得到接收方的确认报文后，才能释放连接。
可以看到客户端和服务端释放连接，需要四个报文，又称为四次握手。
4.抓包分析TCP协议工作过程
4.1.实验一、FTP的抓包实验
打开服务管理器
打开IIS服务
添加FTP站点
关闭防火墙
打开命令行，关闭防火墙
C:\Users\Administrator>wf.msc
客户端操作，输入账号密码
4.1.1.没有加密的FTP可以找到账号密码
从抓包中找到 USER 和 PASSWORD
红色字体是客户端发出的指令
可以找到上传的文件
还原报文中文件的文字
4.1.2.FTP添加使用命令规则
4.2.实验二、抓包邮箱发送过程查看TCP
确认本机邮件服务器的IP地址
打开WIN7的OUTLOOK，需要提前安装好OFFICE
完成后，打开ETHEREAL
打开OUTLOOK，给自己发一封邮件
收到邮件之后”STOP”ETHEREAL，接着查看可以查看TCP的”三次握手”，”四次挥手”
比较奇怪的是，没有出现第一次的FIN包，根据DEEPSEEK的回答是这样
结合图片日志的分析与解释：
根据你提供的图片信息，图中的TCP连接终止过程看似缺少了第一次挥手的FIN包，但实际上可能是由于FIN与ACK合并发送或被动关闭方主动触发关闭导致流程简化。以下是具体分析：
2. 可能的原因：
- FIN与ACK合并发送（隐藏的第一次挥手）：
- 正常流程中，主动关闭方（客户端）应发送`FIN`，被动方（服务器）回复`ACK`。
- 但在你的日志中，客户端在发送`QUIT`后直接发送了`FIN,ACK`包（步骤3）。这可能意味着：
- FIN包被合并到之前的ACK中（例如，在SMTP传输过程中，服务器已提前发送了ACK，但日志未明确展示）。
- 客户端主动关闭连接，但FIN包被合并到`QUIT`命令触发的TCP层操作中，导致看似缺少第一次FIN。
- 被动关闭方（服务器）直接终止：
- 服务器在回复`221`后，可能直接进入`LAST_ACK`状态并发送`FIN`（但日志中未显示），客户端回复`ACK`（步骤4）。
- 若服务器未发送`FIN`，可能是异常终止（如进程崩溃），但图中无`RST`包，因此可能性较低。
4. 验证日志中的关键细节：
- 检查`FIN`包的来源：
- 客户端发送的`FIN,ACK`（步骤3）是否为第一次挥手？
- 若是，则缺少服务器的`ACK`（步骤4应为第二次挥手）。
- 但根据日志，步骤4的`ACK`是对客户端`FIN`的确认，服务器应进入`CLOSE_WAIT`，但后续未发送`FIN`，导致连接未完全关闭。
- 结论：可能服务器未正常关闭，或日志不完整。
- 观察序列号（Seq）和确认号（Ack）：
- 客户端`FIN,ACK`的`Seq=2842`与服务器`ACK`的`Ack=2843`匹配，说明服务器确认了客户端的`FIN`。
- 若服务器未发送自己的`FIN`，则连接处于半关闭状态（客户端在`FIN_WAIT_2`，服务器在`CLOSE_WAIT`），需依赖超时机制终止。
总结：图中现象可能是TCP协议灵活性（合并包）或日志截取不完整导致的误解，实际连接终止过程需结合完整交互分析。