我曾是一名后端研发工程师，写过业务代码，做过架构，也研发过中间件，研发过云原生调度器。更早的时候也是一名Android应用开发者，现在是一名iOS应用开发者，也写过网站，算是全栈开发者，了解后端和客户端开发。
作为一名开发者，我们需要了解网络技术吗？我以前在知乎上回答过类似问题，今天我不想展开说，简单总结就是：非常有必要，无论是前端、客户端、后端，当我们遇到网络问题时，基础的网络知识和抓包分析技能能帮我们快速解决问题。
只是，我们并不需要像研究网络安全方面的专业人士那样，需要掌握非常深的网络知识。人的精力是有限的，选择一个方向深耕就不会有精力在另一个方向钻研。
对开发者来说，基础的网络知识就够用了，无论是做架构，还是问题排查。即便我以前做中间件、云原生，遇到的网络问题也只需要一点基础的网络知识，即：对TCP协议的掌握了解、对HTTP和WebSocket等应用层协议的了解，以及一些CDN原理的理解，然后就是能够通过抓包分析问题。我在我的个人博客网站《吴就业的网络日记》上还分享了好几篇实际工作中遇到的网络问题，以及最后是如何通过抓包分析找出问题的。
而Wireshrk对于开发者来说，上手门槛太高，需要花很多精力去学习，特别是怎么看数据包，以及怎么写过滤表达式。而要看懂数据包就必须要先掌握TCP协议，两者叠加让很多开发者望而却步。
我深有体会，因为我也曾被折磨过。我记性非常不好，每次记住TCP协议的标志位是什么意思后，如果大半年工作中用不到，我就完全忘记了。而Wireshark的过滤表达式我更记不住。
基于以上痛点，我开始自己研发ChatTCP，他不需要像Wireshark那样强大，而是解决开发者对网络方面知识的学习需求，以及作为实际工作中可能会需要的工具。他需要做到非常简单，简单到完全不懂TCP协议也能用，不懂分析问题软件自己分析，更是引入AI助手辅助分析。在用的过程中还能掌握协议，以及如何分析问题。这是我做ChatTCP的初衷。
ChatTCP不支持TLS协议，因为大多数时候，在测试环境抓包流量不经过TLS加密。而正式环境，或者k8s容器环境，流量都被网关脱了TLS那层壳了。
ChatTCP的抓包分析可能更多是后端开发者会用到，所以ChatTCP提供了远程服务器实时抓包分析功能，不需要重复“复现问题-抓包下载到本机-用工具分析”的循环。也为开发阶段的问题排查提供IDEA插件，直接在IDEA里面抓包看问题。
可以说，ChatTCP是更倾向后端开发者的。那客户端有没有抓包分析需求呢？毋庸置疑，并且客户端的需求与服务端还有区别。
作为一名iOS开发者，同时也是一名后端开发者，我对客户端抓包工具的需求是这样的。
首先，他能抓取HTTPS流量，即便是在测试环境，客户端也是用HTTPS请求。
然后就是重放功能、重写功能，这对测试非常有帮助，比如修改参数重放测接口定位问题；比如Mock响应测不同结果的客户端交互流程，而不需要服务端造数据，或是写一堆mock代码。
我还有这样的需求，就是需要知道某个功能用到哪些接口。以前可能需要让客户端协助分析代码提取接口，这不仅麻烦，如果遇到一个客户端也刚接手并不清楚的项目，就很头疼。所以我希望可以通过抓包的方式自动生成接口文档，直接传到团队内的Apifox或者Postman、Bruno。这还附带上了实际请求响应案例，是最高效的沟通方式。
出于以上目的，我开发了ApiCatcher。解决在客户端抓包分析、抓接口、调试接口的需求。
从七层抓包分析，有些问题可能无法定位。比如HTTP Event Stream，可能因为开启压缩导致看到的现象是：卡到最后Done之后才一次性收到响应。对于没有经验的开发者，可能无法从请求头看出问题，因为抓包工具都默认解压缩显示了。而如果从四层分析TCP数据包，就能一眼看出问题。
ApiCatcher和ChatTCP就是我为开发者们量身定做的两款网络数据包抓包调试/分析工具。这是非常有创意的、独特的、简洁易用的小工具。我个人非常喜欢这两款工具，也可能是黄婆卖瓜自卖自夸。
我记得我之前做中间件研发的时候，我的领导问过我一个关于我的职业发展方向的问题。我当时的回答是，我希望自己能在某个领域，比如网络方向，达到资深或专家的水平。虽然我没能实现那个时候的目标，现在也偏离了目标，但至少做到了有深耕、有产出。
AI时代，还有多少人在意基础技能呢？
