V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
httpbin - 协议调试工具
httpstatuses - 协议状态码查询
httpie - cURL-like tool for humans
Fiddler
vevlins
V2EX  ›  HTTP

golang 等语言中的 http stream 实现原理是什么?

  •  
  •   vevlins · 2019-10-07 18:24:32 +08:00 · 5010 次点击
    这是一个创建于 1875 天前的主题,其中的信息可能已经有所发展或是发生改变。

    好奇的不是 stream 本身的实现原理。在 golang 中 http 返回体的 body 是一个 io.Reader 类型,这里是如何实现的?在 http1.1 的前提下讨论:

    1. 这里是整个返回体都返回完才开始接收数据的吗?

      1.1 如果是,缓冲区是在哪里?全部数据在网卡上还是内存里?

    2. 如果是 http 请求未完全返回就接收了数据,是如何实现的?

      2.1 基于 transfer-encoding:chunked ?

      2.2 基于 http 包底层的 tcp 包拆包?

    还望不吝赐教

    10 条回复    2019-10-08 21:43:15 +08:00
    Reficul
        1
    Reficul  
       2019-10-07 18:34:17 +08:00 via Android   ❤️ 1
    1.在内存里,部分已经发送出去了。2.不能判断长度就是 chunked,否则会有 content length。也是因为这个,body 开始返回就不能修改 header 了。TCP 就是一个流,没看懂拆包啥意思。
    gamexg
        2
    gamexg  
       2019-10-07 18:54:34 +08:00   ❤️ 1
    简化版本的 http 协议,

    请求方法送 :

    GET / HTTP/1.1
    HOST:www.abc.com


    服务器回复:

    HTTP/1.1 200 OK
    Content-Length: 123

    html 内容



    http 底层是 tcp 协议,go 的 net.TcpConn 本身提供了 io.Reader 接口实现。
    如上面的例子,Content-Length 表明了 body 的长度,那么 body 直接用 io.LimitReader 包装下 net.TcpConn 即可。

    如果是 transfer-encoding,那么麻烦点,需要从每段头部读取到本段长度,然后返回每段的内容。
    vevlins
        3
    vevlins  
    OP
       2019-10-07 18:55:21 +08:00
    @Reficul 可能表述的不太清楚,我主要的疑惑是假如一个请求的返回体是 100M,把 resp.body read 到一个 10 位的 byte[]中,在开始读 10bytes 之前 100M 的返回体是否都已经返回回来了?如果存在内存里,那这种 io stream 的意义不就不大了吗?如果不是的话,从技术方案来讲,要么在 http/1.1 的限制下用 chunked,要么在 tcp/ip 层拿 http 拆分的更小的包。 感谢!
    gamexg
        4
    gamexg  
       2019-10-07 18:55:42 +08:00
    另外如上面最简单的例子,
    go client 只用读取到 http 响应头,然后剩下的交给 io.LimitReader 就行。
    vevlins
        5
    vevlins  
    OP
       2019-10-07 18:59:06 +08:00
    @gamexg “go 的 net.TcpConn 本身提供了 io.Reader 接口实现”,如果不声明 chunked 方式,假如整个返回体 1w 个字节,这里的实现是等待 1w 个字节都拿到然后封装成 io stream 的方式提供给程序员吗? 感谢!
    gamexg
        6
    gamexg  
       2019-10-07 19:08:07 +08:00   ❤️ 1
    @vevlins #5 不是,如不使用 chunked,1w 直字节,那么 body 最简单可以这样实现:

    return io.LimitReader(conn,10000)


    另附下 io.LimitedReader 源码:

    ```

    // A LimitedReader reads from R but limits the amount of
    // data returned to just N bytes. Each call to Read
    // updates N to reflect the new amount remaining.
    // Read returns EOF when N <= 0 or when the underlying R returns EOF.
    type LimitedReader struct {
    R Reader // underlying reader
    N int64 // max bytes remaining
    }

    func (l *LimitedReader) Read(p []byte) (n int, err error) {
    if l.N <= 0 {
    return 0, EOF
    }
    if int64(len(p)) > l.N {
    p = p[0:l.N]
    }
    n, err = l.R.Read(p)
    l.N -= int64(n)
    return
    }

    ```


    不过我不确定 http 底层实现,印象是有个缓冲区用来实现 ReadLine。
    不过 body 部分为了方便理解可以当作这个缓冲区不存在,直接从操作系统 tcp 缓冲区读取到的 body 数据。
    操作系统的 tcp 缓冲区尺寸是有限的,超过的部分会因为 tcp 滑动窗口,还在服务器 tcp 缓冲区,甚至部分还在 nginx 内存。
    vevlins
        7
    vevlins  
    OP
       2019-10-07 19:12:21 +08:00
    @gamexg 感谢🙏
    vevlins
        8
    vevlins  
    OP
       2019-10-08 20:12:22 +08:00
    @gamexg 您好,关于这个问题我还有两个疑问,不知可否解答。就 net.Conn 而言 1.假如从 io.Reader 读取的速度比较快,会阻塞直到读满字节还是爆 EOF ? 2.同一个 url 有时读取到的部分字节为 00000...,是否是 net.Conn 存在的问题?
    vevlins
        9
    vevlins  
    OP
       2019-10-08 20:14:06 +08:00
    @gamexg 比如之前提到过 tcp 缓冲区有限,如果设置为一次读取超过缓冲区大小数量的字节,能够正常执行吗
    gamexg
        10
    gamexg  
       2019-10-08 21:43:15 +08:00   ❤️ 1
    @vevlins #8

    1. 系统 tcp 缓冲区只要有数据(不限长度),Read 就会立刻返回。如果没有数据,那么 Read 会阻塞至超时或连接关闭。

    2.不知道具体情况,不清楚原因。猜测未处理只读取到部分内容的情况?

    3.可以正常执行,read 会先返回部分操作系统系统 tcp 缓存区存在的数据。


    Read 这个函数用来读取数据。传入的是一个 buf,这个函数有两个情况会返回:

    1.读取到数据,数据并不需要填满 buf,即使 buf 为 10*1024 尺寸,但是操作系统 tcp 缓冲区只有 1 byte 也会立刻返回。
    2.读取出错。例如:超时、连接关闭等等情况。

    Read 函数返回 (int,error),int 为读取到的数据长度,当出现错误时 error 返回错误原因。

    所以问题 2 应该是未处理返回的 int,应该是读取的数据未填满 buf,000 为未使用 buf 的默认值。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1386 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 17:14 · PVG 01:14 · LAX 09:14 · JFK 12:14
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.