LogoChatTCP
menu-icon

ChatTCP MCP Server已上线，用AI查看和分析PCAP文件

ChatTCP MCP Server已上线

ChatTCP已提供MCP Server，这是一个远程的MCP Server，用户不需要安装。

该MCP Server提供以下工具：

  1. 获取所有TCP链接
  2. 获取指定连接的诊断分析结果
  3. 获取指定连接的详细数据包，会解码应用层协议
  4. 获取所有tcp连接的诊断分析结果
  5. 解码指定连接的应用层协议，返回应用层协议解码结果
  6. 支持按TCP标志位、按应用层协议搜索数据包，模糊搜索支持直接匹配tcp的payload，以及解码为应用层协议后的payload。

AI+ChatTCP，让TCP分析和问题排查变得更加简单，AI可以基于ChatTCP提供的诊断结果和延迟、丢包、重传等数据，以及获取到可读的数据包信息，进一步分析，发现ChatTCP未发现的问题，以解决用户问题为目的，精简分析结论，给出更为完善的建议。

如何使用

  1. 登陆ChatTCP在线网页版-切换到MCP集成，获取到apikey。
  2. MCP集成页面提供mcpServer的配置。

要使用ChatTCP MCP Server分析pcap文件，首先是将pcap文件上传到mcpServer，有两种上传方式：

  1. 对于小文件（<10M），可以直接AI对话上传，让AI将文件base64编码上传。
  2. 对于大文件（>10M），您需要在网页版上传pcap文件，或让AI调用mcp提供一个用于临时上传本地文件的curl命令，在终端执行curl命令完成文件上传，上传完成后告诉AI，您已上传完成。

上传完成后，AI会列出您上传的所有pcap文件，后续的AI对话中，需要告诉AI您要分析哪个文件。

点击前往：MCP集成。

一个使用案例

User Input

@mcp:chattcp: 我都上传了哪些文件

Planner Response

I'll check what files you have uploaded to the chattcp MCP server.

Running MCP tool

Planner Response

您已经上传了2个PCAP文件到chattcp服务器：

  1. 30.pcap

    • 文件ID: 20250730103547.pcap
    • 上传时间: 2025-07-30 10:35:47
    • 文件大小: 2.81M

  2. 28.pcap

    • 文件ID: 20250730103440.pcap
    • 上传时间: 2025-07-30 10:34:40
    • 文件大小: 1.14K

您可以使用这些文件ID来进行网络流量分析，比如查看TCP连接、数据包内容、协议解析等。需要分析哪个文件吗？

User Input

帮我分析 30.pcap 文件中服务端端口为 8080 的连接，为什么客户端发送请求后没收到响应。

Planner Response

我来帮您分析30.pcap文件中服务端端口为8080的连接问题。首先让我获取所有TCP连接信息。

Running MCP tool

Planner Response

我看到这个文件中没有端口8080的连接，所有连接都是到端口36780的。让我搜索一下是否有端口8080相关的数据包：

Running MCP tool

Planner Response

看起来30.pcap文件中没有端口8080的连接。让我检查一下另一个文件28.pcap是否包含端口8080的连接：

Running MCP tool

Planner Response

让我搜索28.pcap文件中的端口8080：

Running MCP tool

Planner Response

根据分析结果，我发现：

分析结果

30.pcap文件中没有端口8080的连接

在30.pcap文件中，我发现了14个TCP连接，但都是连接到端口36780，没有任何端口8080的流量。具体连接信息：

  • 源IP: 192.168.12.223 (客户端)
  • 目标IP: 172.16.2.116 和 172.16.2.120 (服务端)
  • 目标端口: 36780 (不是8080)

可能的情况

  1. 文件内容不匹配: 您可能需要检查是否上传了正确的PCAP文件
  2. 端口号记错: 实际的服务端口可能是36780而不是8080
  3. 时间范围问题: 端口8080的流量可能在其他时间段，不在这个抓包文件中

建议

  1. 确认端口号: 检查服务端实际监听的端口是否为8080
  2. 重新抓包: 如果需要分析端口8080的流量，请重新抓取包含该端口流量的数据包
  3. 分析现有连接: 如果您想分析端口36780的连接问题，我可以帮您详细分析这些连接中存在的问题（我注意到有些连接有重传和未确认的标记）

您是否想要我分析端口36780的连接问题，还是您有其他包含端口8080流量的PCAP文件？

User Input

你帮我分析一下有没有什么问题，下载的图片都是只有损坏的，似乎只有一半的图片。

Planner Response

我来帮您分析30.pcap文件中的连接问题，特别是图片下载不完整的问题。让我先查看连接的详细诊断信息。

Running MCP tool

Planner Response

现在让我查看一些有问题的连接的详细数据包信息，特别是那些有重传和未确认标记的连接：

Running MCP tool

Planner Response

现在让我解码这个连接的HTTP应用层协议数据：

Running MCP tool

Planner Response

让我查看另一个有问题的连接：

Running MCP tool

Planner Response

基于对30.pcap文件的详细分析，我发现了导致图片下载不完整的几个关键问题：

🔍 分析结果

主要问题

  1. 服务器响应不完整

    • 在连接 192.168.12.223:63267->172.16.2.116:36780 中，客户端请求图片文件 /public/5345617217620803711.jpg
    • 服务器只发送了196字节的HTTP响应，然后立即发起连接关闭（FIN包）
    • 这解释了为什么图片只有一半或损坏

  2. 连接异常终止

    • 服务器在数据传输未完成时就主动关闭连接
    • 出现了TCP重传（retransmission）和重复ACK（duplicate ACK）
    • 多个连接都存在 has_not_ack 和 has_retransmission 标记

  3. 网络传输问题

    • 检测到低传输速度（0 bytes/s）
    • 存在乱序包（Out-of-Order）和重传包
    • 连接不稳定，频繁出现Keep-Alive包
具体问题连接

连接1: 192.168.12.223:63267->172.16.2.116:36780

  • 请求: GET /public/5345617217620803711.jpg
  • 问题: 服务器只返回196字节就关闭连接
  • 状态: 有重传标记

连接2: 192.168.12.223:51851->172.16.2.120:36780

  • 请求: GET /metrics_state
  • 问题: 大量乱序包和重复ACK
  • 状态: 有未确认包标记

🛠️ 解决建议

  1. 服务器端问题

    • 检查服务器应用程序是否正确处理大文件传输
    • 确认服务器没有过早关闭连接
    • 检查服务器内存和磁盘空间

  2. 网络问题

    • 检查网络连接稳定性
    • 可能存在防火墙或代理干扰
    • 考虑调整TCP窗口大小和超时设置

  3. 客户端优化

    • 实现断点续传功能
    • 增加重试机制
    • 检查客户端接收缓冲区设置

图片下载不完整的根本原因是服务器在文件传输完成前就主动关闭了连接，这可能是服务器应用程序的bug或配置问题导致的。

User Input

能告诉我这些连接中http传输的内容吗？如果是文件告诉我是文件就可以，否则显示完整的http传输的数据。

Planner Response

我来查看这些连接中的HTTP传输内容。让我逐个检查有HTTP数据的连接：

Running MCP tool

Planner Response

这个连接只有Keep-Alive包，没有HTTP数据。让我检查另一个连接：

Running MCP tool

Planner Response

现在让我检查另一个有HTTP数据的连接：

Running MCP tool

Planner Response

基于对这些连接的详细分析，我现在可以总结30.pcap文件中的HTTP传输内容：

📋 HTTP传输内容总结

🖼️ 文件下载请求

连接1: 192.168.12.223:63267->172.16.2.116:36780

  • 请求: GET /public/5345617217620803711.jpg HTTP/1.1
  • 内容: 图片文件下载
  • 问题: 服务器只返回196字节就关闭连接，导致图片不完整

连接2: 192.168.12.223:49459->172.16.2.116:36780

  • 请求: GET /public/5345617217620803711.jpg HTTP/1.1
  • 内容: 同一图片文件的重复请求
  • 问题: 同样只返回196字节，存在重传问题
📊 API接口请求

连接3: 192.168.12.223:51851->172.16.2.120:36780

  • 请求: GET /metrics_state HTTP/1.1
  • 内容: 【省略】
  • 响应: 返回了大量JSON数据（约72KB），包含系统状态信息
  • 问题: 存在乱序包和重复ACK

连接4: 192.168.12.223:53972->172.16.2.120:36780

  • 请求: GET /metrics_delay HTTP/1.1
  • 内容: 【省略】
  • 响应: 返回了大量JSON数据（约72KB），包含延迟指标信息
  • 问题: 存在大量乱序包和未确认包
🔗 其他连接

其余10个连接主要是Keep-Alive连接，没有实际的HTTP数据传输，只有TCP握手和保持连接的包。

🚨 主要问题

  1. 图片文件传输不完整 - 服务器过早关闭连接
  2. 网络传输不稳定 - 大量重传、乱序和重复ACK
  3. API响应虽然完整，但传输过程中存在网络问题

User Input

你能给我看http响应的json数据吗

Planner Response

我需要从数据包中提取HTTP响应的JSON数据。让我查看那些有大量数据传输的连接中的服务器响应包。

从之前的分析中，我看到连接 192.168.12.223:51851->172.16.2.120:36780 和 192.168.12.223:53972->172.16.2.120:36780 都有大量的JSON响应数据。

让我提取其中一个连接的HTTP响应数据。从之前的数据包分析中，我可以看到服务器返回的JSON数据。让我整理一下：

📄 HTTP响应JSON数据

/metrics_state 接口响应

从连接 192.168.12.223:51851->172.16.2.120:36780 中提取的JSON响应数据：

【省略json数据】

📊 数据说明

这些JSON响应包含了网络连接的详细分析数据：

  1. 连接状态信息 - 每个TCP连接的详细统计
  2. 网络质量评估 - 包括重传率、丢包率、延迟等指标
  3. 延迟测量 - 客户端到服务器和服务器到客户端的延迟统计
  4. 性能建议 - 基于分析结果的网络优化建议

这些数据表明服务器正在提供网络监控和分析服务，监控TCP连接的性能指标。

发布时间：2025年8月2日