前端用 websocket 写入数据到后端 netty 时,丢数据

2023-10-31 18:35:13 +08:00
 huskyui

大致流程

目前前端就是 javascript 里面的 websocket. 然后上传一张图片的字节数组到后端 netty ,后端 netty 读取二进制 Frame 后,再返回出来到前端

问题

前端的图片在 130kb 以下,是可以正常上传,返回。 但是大一点的图片,就会丢失,只能返回大概 130kb 的部分数据。打断点,从前端发送时,字节数组的大小是正确的,但是后端接受就丢失了

1352 次点击
所在节点    Java
10 条回复
kilasuelika
2023-10-31 18:42:17 +08:00
要看后端用的什么 websocket 库,有些可能有默认的大小限制
huskyui
2023-10-31 20:26:37 +08:00
@kilasuelika 用的是 netty 实现的 websocket
huskyui
2023-10-31 22:35:02 +08:00
大概找到原因了,大文件传输时,刚刚抓包发现,报了个错,TCP WINDOW FULL
kuanat
2023-11-01 02:39:50 +08:00
看到 130kb 我的第一反应是 128KiB 或者 131072 字节,有少部分平台是 128000/124928 这样,大概率是某个参数限制了 128KiB 。

如果你是用 wireshark 之类抓包的话,TCP WINDOW FULL 有可能是 false positive 的误报。Wireshark 的判断逻辑是,收方那边说我的 TCP Window 是 xxx ,然后发方开始发送,这中间如果没有收方的 ACK 的话,发送超过 xxx 之后,wireshark 会认为 TCP WINDOW FULL 。换句话说,你的 TCP 底层实现没有特殊处理的话,是无法在发送方真正发送超过 xxx 的。

加上你说抓包发现前端能够正确发包,那说明是后端的限制而非 TCP 层面的。

我估计应该是 netty websocket 某个与 frame size 相关的参数限制了 128KiB ,另外还应该有个 message 层面的限制。
julyclyde
2023-11-01 12:04:31 +08:00
@huskyui 首先你用 websocket 就不该关注 TCP 的相关信息吧
huskyui
2023-11-01 17:44:50 +08:00
@kuanat 昨天用 wireshark 看的时候,我看里面的 length 缺失了。netty 里面我确实设置
huskyui
2023-11-01 17:47:02 +08:00
@julyclyde 问了 chatgpt,和通义千问,没找到大致原因。只能死马当活马医
julyclyde
2023-11-01 18:04:23 +08:00
你这个所谓“丢失了”是指没收到中间这一段 130k 但是收到 130k 之后的内容吗?
还是从 130k 开始往后全都丢失了?
huskyui
2023-11-01 18:42:59 +08:00
@julyclyde 我 netty 那边打断点,只收到了前面 130k 数据
julyclyde
2023-11-01 18:57:13 +08:00
@huskyui 把 netty 换掉试试呢?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/987211

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX