记:排查设备web时慢时快问题,速度提升100%
问题描述
问题1：
发现web登录界面刷新和登录功能都比较卡，开浏览器控制台看了下，让我很惊讶，居然能这么慢：
公司2个局域网内的表现不同，局域网A中的都比较卡，局域网B中的又不存在该现象。
问题2：
同事使用QT开发的UI控制起来也比较慢。控制UI的时候，UI资源加载前需要与API接口通讯。
当QT比较慢的时候web访问和操作也必然会慢，甚至有时候打不开。
问题3：
以前是不存在这个问题的，也是近半年出现的网络访问web较慢的问题。也排除会不会是新代码新功能引起的。
下定决心一定要把这个问题找到，如果找不到的话，后面可能会带来更大的影响。
前期分析
因为设备内的网页比较简单，所以使用了一个简易的http库开发的webserver，设备使用的是httplib.h库开发的。
原本以为是httplib.h库并发不行导致的问题。看网上说httplib.h是线程阻塞的，不适合大型项目。按理说咱们一次才几个请求，最多一次几十个http请求，也只能算微微微微微微微微小型的web项目了吧，不应该出现这么严重的阻塞问题。
设备内部分析
设备内部使用的Linux操作系统，有一些网络和系统分析工具，例如ps、netstat等常用工具。
用netstat命令可以查出来TCP/IP的状态
很多Local和Foreign地址都是本机的127.0.0.1，这是不同进程之间的通讯方式。
root@ZOWIECAM:~# netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:80 127.0.0.1:34902 TIME_WAIT
tcp 0 0 127.0.0.1:8968 127.0.0.1:51810 TIME_WAIT
tcp 0 0 127.0.0.1:80 127.0.0.1:35232 TIME_WAIT
恰恰有几个是ESTABLISHED状态：
tcp 0 0 192.168.1.90:80 192.168.1.146:8604 ESTABLISHED
tcp 0 0 192.168.1.90:22 192.168.1.56:1246 ESTABLISHED
在TCP连接中，TIME_WAIT和ESTABLISHED是两种不同的状态：
- ESTABLISHED：表示TCP连接已经成功建立，正在进行数据传输。
- TIME_WAIT：表示TCP连接已经关闭，但系统仍然在等待一段时间，以确保延迟的数据包不会干扰后续的连接。
为了加快TIME_WAIT状态的TCP连接快点消失掉，特意修改了内核参数：
减少TIME_WAIT状态的持续时间：
调整内核参数来缩短TIME_WAIT状态的持续时间：sysctl -w net.ipv4.tcp_fin_timeout=30增加可用端口范围：
增加系统可用的本地端口范围：
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
启用TCP复用：
允许在TIME_WAIT状态下重新使用端口：批量执行：
sysctl -w net.ipv4.ip_local_port_range="1024 65535"
sysctl -w net.ipv4.tcp_fin_timeout=30
sysctl -w net.ipv4.tcp_tw_reuse=1
sysctl -w net.ipv4.tcp_tw_recycle=1
设置tcp_fin_timeout、tcp_tw_reuse、tcp_tw_recycle后TIME_WAIT状态的TCP连接消失的快了一些。
等待一段时间后TIME_WAIT状态的连接会很快自动消失，但是这几个ESTABLISHED状态的TCP连接很可疑，一直存在，无论如何都消失不了。
决定找一下这个IP的同事，看看同事的PC上为啥一直与这台设备保持着80端口的连接：
tcp 0 0 192.168.1.90:80 192.168.1.146:8604 ESTABLISHED
根据Foreign Address 的IP为192.168.1.146找到了这台设备的同事。
我问：请问你这台设备在访问1.90这台设备吗？
同事回答：没有呀！
我说：你仔细检查下浏览器是否某个标签页打开了1.90的网页？
…
同事最后发现：PC上运行着一个软件，这个软件是PC端控制设备端的软件。
同事关闭这个软件后。
又检查了下netstat的1.146这台TCP连接ESTABLISHED的状态，果然消失了。
然后又把其他TCP连接ESTABLISHED的状态的IP去找到了相应的同事，大概又5-6个都打开了该软件。
当这5-6同事的PC关闭该软件后：
顿时天亮了！！！整个网络世界清净了许多。
Web刷新也不卡了，QT操作也流畅很多。
总结
- 1、webserver需要考虑并发设计；
- 2、webserver需要考虑sock连接状态，对于哪些特殊的连接状态，需要加强关注；
- 3、排查问题时发现有时候127.0.0.1的内部请求有时候有900多个。这个需要保持怀疑的态度，时刻警惕！！！
- 4、对于进程间的通讯我认为如果通讯比较快的话，使用http还是存在风险和稳定性问题的。可以使用：
- （1）共享内存；
- （2）管道；
- （3）dBUS；很合适，支持发布和订阅模式。
- （4）甚至如果有MQTT集成在内部的话，我认为这个也比较合适。支持发布和订阅模式。