Golang 的 (*http.ResponseWriter) Write() 方法是否会阻塞直到数据传输给客户端完成？

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《Golang 的 (*http.ResponseWriter) Write() 方法是否会阻塞直到数据传输给客户端完成？》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

我问这个问题是因为我有一个非常奇怪的令人费解的经历，我即将讲述。

我正在检测 http api 服务器，以观察它在服务器和客户端之间存在延迟的情况下的行为。我的设置由一台服务器和十几个通过 10gbps 以太网结构连接的客户端组成。我测量了 5 个场景中处理某些 api 请求所需的时间。在每种情况下，我使用 tc-netem(8) 实用程序将服务器和客户端之间的延迟设置为以下值之一：无延迟（我称之为基线）、25 毫秒、50 毫秒、250 毫秒或 400 毫秒。

因为我使用直方图桶来量化服务时间，所以我观察到，无论在什么情况下，所有请求的处理时间都不到 50 毫秒，这显然没有任何意义，例如，在 400 毫秒的情况下，它应该至少在 400ms 左右（因为我只测量从请求到达服务器到 http write() 函数返回的持续时间）。请注意，响应对象的大小在 1kb 到 10kb 之间。

最初，我怀疑 *http.responswriter 的 write() 函数是异步的，并且在客户端收到数据之前立即返回。因此，我决定通过编写一个玩具 http 服务器来测试这个假设，该服务器为使用 dd(1) 和 /dev/urandom 生成的文件的内容提供服务，以便能够重新配置响应大小。这是服务器：

var response []byte

func httphandler(w http.responsewriter, r * http.request) {

    switch r.method {
        case "get":
            now: = time.now()
            w.write(response)
            elapsed: = time.since(now)
            mcs: = float64(elapsed / time.microsecond)
            s: = elapsed.seconds()
            log.printf("elapsed time in mcs: %v, sec:%v", mcs, s)
    }
}

func main() {
    response, _ = ioutil.readfile("bigfile")

    http.handlefunc("/hd", httphandler)
    http.listenandserve(":8089", nil)
}

然后我像这样启动服务器： dd if=/dev/urandom of=bigfile bs=$variable_size count=1 && ./server

从客户端，我发出 time curl -x get $server_ip:8089/hd --output /dev/null

我尝试使用 [1kb, 500mb] 范围内的许多 $variable_size 值，并在服务器和每个客户端之间使用 400 毫秒的模拟延迟。长话短说，我注意到 write() 方法会阻塞，直到响应大小足够大到可以直观地注意到（大约数十兆字节）时发送数据为止。但是，当响应大小较小时，与客户端报告的值相比，服务器不会报告精神上理智的服务时间。对于 10kb 文件，客户端报告 1.6 秒，而服务器报告 67 微秒（这根本没有意义，即使是我作为一个人，我也注意到客户端报告的延迟约为一秒） 。

为了更进一步，我试图找出服务器从哪个响应大小开始返回心理上可接受的时间。使用二分搜索算法进行多次试验后，我发现服务器对于大小小于 86501 字节的响应总是返回几微秒 [20us，600us]，对于 >= 86501 字节的请求返回预期（可接受的）时间（通常客户报告的时间的一半）。例如，对于 86501 字节的响应，客户端报告 4 秒，而服务器报告 365 微秒。对于86502字节，客户端报告4s，服务器报告1.6s。我使用不同的服务器多次重复这种经历，行为总是相同的。数字 86502 看起来很神奇！！

这段经历解释了我最初观察到的奇怪现象，因为所有 api 响应的大小都小于 10kb。然而，这为一个严肃的问题打开了大门。到底发生了什么以及如何解释这种行为？

我尝试寻找答案，但没有找到任何结果。我唯一能想到的是也许这与linux的套接字大小以及go是否以非阻塞方式进行系统调用有关。但是，据我所知，传输 http 响应的 tcp 数据包应该在发送者（服务器）返回之前全部由接收者（客户端）确认！打破这个假设（在本例中看起来是这样）可能会导致灾难！有人可以解释一下这种奇怪的行为吗？

技术细节：

Go version: 12
OS: Debian Buster
Arch: x86_64

解决方案

我推测这个问题事实上是以一种错误的方式表述的：你似乎在猜测 HTTP 是如何工作的，而不是查看整个堆栈。

首先要考虑的是 HTTP（1.0 和 1.1，这是很久以前的标准版本）没有指定任何一方确认数据接收的方式。
对于服务器收到客户端请求的事实存在隐式确认 - 服务器应该响应该请求，并且当它响应时，客户端可以合理地确定服务器实际上已收到该请求。
但在另一个方向上却没有这样的事情：服务器不希望客户端以某种方式“报告”（在 HTTP 级别）它已成功读取整个服务器的响应。

要考虑的第二件事是 HTTP 通过 TCP 连接（或 TLS，TLS 并没有真正的不同，因为它也使用 TCP）。

关于 TCP 的一个经常被遗忘的事实是，它没有消息帧，也就是说，TCP 执行不透明字节流的双向传输。 TCP 仅保证这些流中字节的总排序；它不会以任何方式保留任何偶尔的“批处理”，这可能是您通过典型编程接口使用 TCP 的方式自然产生的 - 通过调用某种“写入这组字节”函数。

关于 TCP 经常被遗忘的另一件事是，虽然它确实使用确认来跟踪接收方实际接收到的传出流的哪一部分，但这是一个未暴露给编程接口级别的协议细节（至少据我所知，TCP 的任何常见实现中都没有）。

这些功能意味着，如果想要使用 TCP 进行面向消息的数据交换，则需要在 TCP 之上的协议中实现对消息边界（所谓的“成帧”）和对单个消息接收的确认的支持。 HTTP 是一种高于 TCP 的协议，但虽然它实现了成帧，但除了如上所述的服务器响应客户端之外，它没有实现显式确认。

现在考虑一下，大多数（如果不是全部）TCP 实现在堆栈的各个部分都采用了缓冲。至少，程序提交的数据会被缓冲，从传入的 TCP 流中读取的数据也会被缓冲。

最后考虑一下，最常用的 TCP 实现通过使用允许提交任意长度的字节块的调用来将数据发送到活动 TCP 连接中。 考虑到上述缓冲，此类调用通常会阻塞，直到所有提交的数据都复制到发送缓冲区为止。 如果缓冲区中没有空间，则调用会阻塞，直到 TCP 堆栈设法将一定量的数据从该缓冲区传输到连接中，从而释放一些空间来接受来自客户端的更多数据。

以上所有内容对于 net/http.ResponseWriter.Write 与典型的当代 TCP/IP 堆栈交互意味着什么？

• 对 Write 的调用最终会尝试将指定的数据提交到 TCP/IP 堆栈中。
• 堆栈会尝试将该数据复制到相应 TCP 连接的发送缓冲区中 — 一直阻塞，直到所有数据都成功复制为止。
• 此后，您基本上失去了对该数据发生的情况的任何控制：它可能最终成功传递给接收者，也可能完全失败，或者其中一部分可能成功，而其余部分则不会。

这对您来说意味着，当 net/http.ResponseWriter.Write 阻塞时，它会阻塞您正在操作的 HTTP 连接底层的 TCP 套接字的发送缓冲区。

但请注意，如果 TCP/IP 堆栈检测到 HTTP 请求/响应交换底层的连接存在不可修复的问题 — 例如来自远程部分的带有 RST 标志的帧，这意味着连接已被意外断开 —这个问题也会使 Go 的 HTTP 堆栈冒泡，并且 Write 将返回非 nil 错误。 在这种情况下，您会知道客户端可能无法收到完整的响应。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。