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

2019-10-07 18:24:32 +08:00
 vevlins

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

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

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

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

    2.1 基于 transfer-encoding:chunked ?

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

还望不吝赐教

5039 次点击
所在节点    HTTP
10 条回复
Reficul
2019-10-07 18:34:17 +08:00
1.在内存里,部分已经发送出去了。2.不能判断长度就是 chunked,否则会有 content length。也是因为这个,body 开始返回就不能修改 header 了。TCP 就是一个流,没看懂拆包啥意思。
gamexg
2019-10-07 18:54:34 +08:00
简化版本的 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
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
2019-10-07 18:55:42 +08:00
另外如上面最简单的例子,
go client 只用读取到 http 响应头,然后剩下的交给 io.LimitReader 就行。
vevlins
2019-10-07 18:59:06 +08:00
@gamexg “go 的 net.TcpConn 本身提供了 io.Reader 接口实现”,如果不声明 chunked 方式,假如整个返回体 1w 个字节,这里的实现是等待 1w 个字节都拿到然后封装成 io stream 的方式提供给程序员吗? 感谢!
gamexg
2019-10-07 19:08:07 +08:00
@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
2019-10-07 19:12:21 +08:00
@gamexg 感谢🙏
vevlins
2019-10-08 20:12:22 +08:00
@gamexg 您好,关于这个问题我还有两个疑问,不知可否解答。就 net.Conn 而言 1.假如从 io.Reader 读取的速度比较快,会阻塞直到读满字节还是爆 EOF ? 2.同一个 url 有时读取到的部分字节为 00000...,是否是 net.Conn 存在的问题?
vevlins
2019-10-08 20:14:06 +08:00
@gamexg 比如之前提到过 tcp 缓冲区有限,如果设置为一次读取超过缓冲区大小数量的字节,能够正常执行吗
gamexg
2019-10-08 21:43:15 +08:00
@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 的默认值。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/606768

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX