大致流程
目前前端就是 javascript 里面的 websocket. 然后上传一张图片的字节数组到后端 netty ,后端 netty 读取二进制 Frame 后,再返回出来到前端
问题
前端的图片在 130kb 以下,是可以正常上传,返回。 但是大一点的图片,就会丢失,只能返回大概 130kb 的部分数据。打断点,从前端发送时,字节数组的大小是正确的,但是后端接受就丢失了
目前前端就是 javascript 里面的 websocket. 然后上传一张图片的字节数组到后端 netty ,后端 netty 读取二进制 Frame 后,再返回出来到前端
前端的图片在 130kb 以下,是可以正常上传,返回。 但是大一点的图片,就会丢失,只能返回大概 130kb 的部分数据。打断点,从前端发送时,字节数组的大小是正确的,但是后端接受就丢失了
1
kilasuelika Oct 31, 2023 via Android
要看后端用的什么 websocket 库,有些可能有默认的大小限制
|
2
huskyui OP @kilasuelika 用的是 netty 实现的 websocket
|
3
huskyui OP 大概找到原因了,大文件传输时,刚刚抓包发现,报了个错,TCP WINDOW FULL
|
4
kuanat Nov 1, 2023
看到 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 层面的限制。 |
8
julyclyde Nov 1, 2023
你这个所谓“丢失了”是指没收到中间这一段 130k 但是收到 130k 之后的内容吗?
还是从 130k 开始往后全都丢失了? |