论坛有多个帖子在讨论使用webnet后浏览器加载资源的时候被挂起（网页加载不完整）
帖子列表如下，一般大家认为是页面资源较多，浏览器会通过多个socket链路来加载资源，由于设备资源有限就会导致页面被挂起。
WebNet是否不适合比较复杂的网页开发
webnet网页被挂起
webnet使用浏览器刷新异常问题
理论上来讲页面内容被加载后socket和内存都会释放，资源不足的话大家排队加载就行了，不应该出现永久的阻塞。通过不断的调试，页面被挂起的原因终于找到了，在webnet的接收函数webnet_session_read()中增加dump信息发现凡是被挂起的资源其HTTP GET请求的头部的若干字节会被清零，从而导致webnet无法解析HTTP包头最终链接被挂起。
/* wn_session.c */int webnet_session_read(struct webnet_session *session, char *buffer, int length){ int read_count; /* Read some data */ read_count = recvfrom(session->socket, buffer, length, 0, NULL, NULL); if (read_count <= 0) { session->session_phase = WEB_PHASE_CLOSE; return -1; } LOG_HEX("wb", 16, buffer, read_count); return read_count;}/* 有问题的LOG *//*D/HEX wb: 0000-000F: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0010-001F: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020-002F: 00 00 00 00 00 00 0D 0A 43 6F 6E 6E 65 63 74 69 ........Connecti 0030-003F: 6F 6E 3A 20 6B 65 65 70 2D 61 6C 69 76 65 0D 0A on: keep-alive.. 0040-004F: 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 User-Agent: Mozi 0050-005F: 6C 6C 61 2F 35 2E 30 20 28 57 69 6E 64 6F 77 73 lla/5.0 (Windows 0060-006F: 20 4E 54 20 31 30 2E 30 3B 20 57 69 6E 36 34 3B NT 10.0; Win64; 0070-007F: 20 78 36 34 29 20 41 70 70 6C 65 57 65 62 4B 69 x64) AppleWebKi 0080-008F: 74 2F 35 33 37 2E 33 36 20 28 4B 48 54 4D 4C 2C t/537.36 (KHTML, 0090-009F: 20 6C 69 6B 65 20 47 65 63 6B 6F 29 20 43 68 72 like Gecko) Chr 00A0-00AF: 6F 6D 65 2F 38 34 2E 30 2E 34 31 34 37 2E 31 30 ome/84.0.4147.10 00B0-00BF: 35 20 53 61 66 61 72 69 2F 35 33 37 2E 33 36 20 5 Safari/537.36 00C0-00CF: 45 64 67 2F 38 34 2E 30 2E 35 32 32 2E 35 32 0D Edg/84.0.522.52. 00D0-00DF: 0A 41 63 63 65 70 74 3A 20 74 65 78 74 2F 63 73 .Accept: text/cs 00E0-00EF: 73 2C 2A 2F 2A 3B 71 3D 30 2E 31 0D 0A 52 65 66 s,*/*;q=0.1..Ref 00F0-00FF: 65 72 65 72 3A 20 68 74 74 70 3A 2F 2F 31 39 32 erer: http://192 0100-010F: 2E 31 36 38 2E 31 2E 35 2F 73 74 61 74 75 73 5F .168.1.5/status_ 0110-011F: 63 6E 2E 68 74 6D 6C 0D 0A 41 63 63 65 70 74 2D cn.html..Accept- 0120-012F: 45 6E 63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 20 Encoding: gzip, 0130-013F: 64 65 66 6C 61 74 65 0D 0A 41 63 63 65 70 74 2D deflate..Accept- 0140-014F: 4C 61 6E 67 75 61 67 65 3A 20 7A 68 2D 43 4E 2C Language: zh-CN, 0150-015F: 7A 68 3B 71 3D 30 2E 39 2C 65 6E 3B 71 3D 30 2E zh;q=0.9,en;q=0. 0160-016F: 38 2C 65 6E 2D 47 42 3B 71 3D 30 2E 37 2C 65 6E 8,en-GB;q=0.7,en 0170-017F: 2D 55 53 3B 71 3D 30 2E 36 0D 0A 0D 0A -US;q=0.6....*/
从理论上分析，socket应用层收到了数据说明底层的数据包是正常的，后来通过软件包netutils的抓包工具也证实了tcp底层数据是正常的。为何在webnet上接收的包头被清零根本原因未找到，需要rtt官方以及其他坛友一块讨论一下
@几位讨论过此问题的坛友，如有打扰请见谅
@CrisJay @aozima @libing @huo @armink
问题找到了，以太网接收的地方申请内存的方式是参考cube工程，与rtt释放内存用的api对不起来
这个方法挺好，我试试看
模拟器上正常，感觉问题越来越玄了
用模拟器或许各个性能都强所以没复现，后来在MCU上做了一些这样的测试：
网页文件由原来的存在spi flash中改成qspi flash后基本都能加载正常了，这样只不过是提升读文件的速度，不会影响网络接收，问题的根本原因还是没找到