网络通信端口选择一定要慎重 -- 可恶的 6667 端口！

开篇

本文通过一个真实案例，讲明端口选取的重要性！！！ 没事别 TM 随意选端口～～～，嫌麻烦可以直接看文末总结！

项目背景

如下图所示，有三个 web 应用互相通过 http 协议进行通信。

项目基于 python 的 flask web 框架开发，http 接口请求用的第三方的 requests 模块。

测试环境如下：

• Server 1 【172.16.10.128】
  • app1 - > port 6666
  • app2 - > port 6667
• Server 2 【172.16.10.126】
  • app3 - > port 5001

问题

通过查看日志，以及最终执行效果，已经可以确认三者都能正常接收发 http 消息。

其实一般到此我们会认为三者之间的通信已经没什么问题了。

但是！！！

我们的最终测试结果还是需要通过网络抓包来确认。

然而，当使用 wireshark 分析抓取的网络数据包时，发现部分请求和响应数据包都被分片了，而且HTTP 协议被解析成了 IRC 协议。

如下图所示：

这部分解析错的数据都是源于 126 机器的5001 端口发送给 128 的 6667 端口， 而其他请求都是能正常的解析的。

此时，头上就出现了一堆问号。。。。

因为自己本身没学过计算机网络，只懂得三次握手，四次挥手这些个，还是从面试题中学的，抓包什么的都是最近学的，所以文中有些关于网络的描述不是很准确，并且解题过程也很捉急。。

解决过程

已经验证的结果

• 172.16.10.126:5001 < - > 172.16.10.128:6666

双方互相接收发的数据包能够准确的解析成 http 消息

• 172.16.10.126:5001 -> 172.16.10.128:6667

发出的请求与接收的响应出现解析异常

• 172.16.10.128:6667 -> 172.16.10.126:5001

发送请求异常与接受响应的数据包正常

推论：

因为用的请求工具以及方法是同一个，而且给 128 的其中一个应用（port：6666）发消息是正常的，排除掉封装的工具类的问题

单独用接口测试工具 postman 测试

postman -> 172.16.10.128:6667

解析结果不正常。还是会出现分片，以及协议解析错误

此时，就排除掉发送包频率过快，更加可以确定请求工具类没有问题。

见鬼了？？？

到这里招数就用尽了，然后就开始了无脑操作，因为 6666 应用 和 6667 应用接受请求的代码几乎一毛一样，排除掉框架代码的问题。

难道是 url ？ 参数有问题？？？ 笑死我了，只能想到这些了。

• 先把 url 改成了： http://172.16.10.128:6667/hello， 发现还是不行。

• 接着就怀疑参数有问题，干脆不传参数了， 结果还是不行。。。

～～～ 快绝望了。。。6667 应用 和 6666 应用还有什么区别？？？？

哦，，端口！！！！！！！！ 我尼玛，这么明显。

立即就把端口改成了 8080（当然要确保端口没被占用），请求正常！！！！

我服了。为什么一个 端口就能搞这么大动静？！ 随即百度了 6667端口

结论如下：

通过端口「6667」的数据传输，自动转为「IRC」协议， 具体可以详细查一下。

总结

本文主要讲的是向一个 web 应用的 6667 端口发送 restful 请求，虽然 web 应用可以接收并接收到正确的请求参数，同时也可以获得预期的执行结果。

但是通过网络抓包会发现，发送给 6667 端口的 http 请求消息和响应消息被解析成了 IRC 协议，而且发生了数据分片的问题。

而最终的结论是：通过端口「6667」的数据传输，自动转为「IRC」协议， 具体可以详细查一下。