webnet导致的页面被挂起的根本原因探讨

发布于 2020-08-03 10:24:16 浏览：1988 订阅该版

论坛有多个帖子在讨论使用webnet后浏览器加载资源的时候被挂起（网页加载不完整）
![image.png](/uploads/20200803/c1224613a39236590c28459d15a06ec1.png)

----------
帖子列表如下，一般大家认为是页面资源较多，浏览器会通过多个socket链路来加载资源，由于设备资源有限就会导致页面被挂起。
[WebNet是否不适合比较复杂的网页开发](https://club.rt-thread.org/ask/question/10723.html)
[webnet网页被挂起](https://club.rt-thread.org/ask/question/12035.html)
[webnet使用浏览器刷新异常问题](https://club.rt-thread.org/ask/question/422132.html)

-------------
理论上来讲页面内容被加载后socket和内存都会释放，资源不足的话大家排队加载就行了，不应该出现永久的阻塞。通过不断的调试，页面被挂起的原因终于找到了，在webnet的接收函数`webnet_session_read()`中增加dump信息发现凡是被挂起的资源其HTTP GET请求的头部的若干字节会被清零，从而导致webnet无法解析HTTP包头最终链接被挂起。

```c
/* 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对不起来**