gatewayWorker中连续接受tcp数据时候丢包
用gateway在做一个转发的网关，一边是tcp socket，一边是websocket，当tcp连续发十多条数据，每条30字节左右的数据时，gateway有时只收到七八条数据，可是我加了sleep函数1s发送一条时候，又能完整接受所有数据，按理说tcp是不会出现丢包现象吧，而且我的tcp端每次send都是返回成功（没有加延时）的啊，而网关端却接受得不对？是client问题还是server问题呢？求大神解答
5066 7 0
7个回答
相似问题
年代过于久远，无法发表回答
月贡献榜
赞助商
热门问答
workerman 里面的redis 队列是基于redis的什么特性实现的？
webman有没有可能考虑内置Macro宏功能呢？
webman移植到linux报错Cannot redeclare……
workerman/http-client 是否需要手动关闭连接
关于webman使用fastcgi_finish_request函数的类似效果的方案
workerman/workerman (v4.2.0 => v4.2.1)后webman报错
webman不错，但不建议官方做webman-admin
Webman AI 发布5.2版本，支持画廊功能，支持史上最强gpt-4o模型
wokerman think-worker 内存一直增长
关于 webman/think-orm 和 topthink/think-orm 重复类名的问题
tcp会粘包的，你要处理下粘包，你的问题应该是粘包引起的。
解决方法参考workerman手册协议部分。
在linux用tcpdump抓包，客户端发过来14条数据，全部抓取到，而且每条数据长度正确，就是转发给websocket时候转少了几条，是我的处理器问题吗？
补充一下：我是用text协议接收的
18:01:24.583714 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 389:417, ack 7, win 3650, options , length 28
18:01:24.588340 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 417:445, ack 7, win 3650, options , length 28
18:01:24.661216 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 445:473, ack 7, win 3650, options , length 28
18:01:24.661586 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 473:501, ack 7, win 3650, options , length 28
18:01:24.661663 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 501:528, ack 7, win 3650, options , length 27
18:01:24.661702 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 528:556, ack 7, win 3650, options , length 28
18:01:24.661771 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 556:583, ack 7, win 3650, options , length 27
18:01:24.661807 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 583:611, ack 7, win 3650, options , length 28
18:01:24.661837 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 583:611, ack 7, win 3650, options , length 28
18:01:25.255745 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 611:639, ack 7, win 3650, options , length 28
18:01:25.257262 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 639:666, ack 7, win 3650, options , length 27
18:01:25.258095 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 666:694, ack 7, win 3650, options , length 28
18:01:25.259566 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 694:722, ack 7, win 3650, options , length 28
18:01:25.261078 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 722:749, ack 7, win 3650, options , length 27
18:01:25.263096 IP 113.106.12.63.45181 > 192.168.1.135.7272: Flags , seq 749:777, ack 7, win 3650, options , length 28
可能是业务逻辑问题，或者客户端问题。我也只能是猜测，这种问题只能自己定位了，别人没环境没法定位的。
另外tcp不会丢包的。workerman也不会丢包。
我想应该是gateway的业务逻辑问题，tcp客户端过来的数据一条不少，可是在转发的时候，我先将tcp的包经过了一轮判断和封装再send给websocket的客户端，会不会应为tcp发过来太快了，第一条还没封装好发给websocket的数据又接着来第二条，致使有的数据漏发？
还是那句话，单凭描述无法定位的，没环境，没代码，没报错。应该就是业务问题，自己多打打日志就出来了。