< 返回版块

JeremyWuuuuu 发表于 2019-08-14 14:24

Tags:MIO;TCP

小弟最近在学习 MIO, 对于 MIO 有一些小小的疑问.

问题描述

假设在当前有一个 HTTP 请求进入, 当用户应用被 MIO 通知为可以读的时候, 用户开始处理数据. 在这个情况下有一个背景条件就是, 用户通过 TCP 连接传过来的东西是远远大于这个 TCP 连接的接收的缓冲区大小的 (RECEIVEING BUFFER), 此时当用户处理这个 HTTP 请求的时候, 从 TCP 的缓冲区里读出来的数据并不是完整的 (由于缓冲区大小远远小于用户上传的数据).

疑问:

当该情况发生的时候, 应当如何处理, 程序如何能在当前程序处理完之前来保存当前的上下文并继续等待数据传入之后处理.

自己的想法:

因为 HTTP 请求头中会带有 Content-Length 这个头, 我可以通过这个头来知道当前的请求体是否已经被发送完成, 但此时如果同一个 client 有另一个请求 (与当前不相干) 进入 (假设当前复用这个 TCP 链接), 应当如何处理.

评论区

写评论
Ryan-Git 2019-08-15 15:50

streaming 和 multiplex/pipeline 又是两回事了。具体看协议吧。

对以下内容的回复:

作者 JeremyWuuuuu 2019-08-14 18:35

所以我在这里考虑到的是, 2.0 以上的 streaming 是如何来实现的? 比如请求是分片段来传输的, 大概也是会有具体的编号什么的吧.. 还得看规范= =. 对以下内容的回复:

Ryan-Git 2019-08-14 16:02

少回答一个问题。关于如何识别消息。http 是按行分割的文本协议,header 和 body 之间空一行,所以一直读,读到一个空行了就可以 parse header。body 的长度答主自己想到了,看 header 里的 content-length,按 lenght 读一个 body。后面就是下一个请求了。

当然这是最简单的情况,还有 chunk 之类的分割 body 的类型,具体看 rfc 吧。

Ryan-Git 2019-08-14 15:56

看起来题主是想用 tcp 实现 http 协议,现在主流的 http 1.1 是不支持 pipeline 的,也就是说在同一个连接上上一个请求没发完的话是不会发下一个请求的,不存在这个问题。

1 共 4 条评论, 1 页