HTTP协议下，当返回数据较大时，reponse发送延迟极大且并行请求会一起堵塞很久

[mizuse-emiya]

Describe the bug (描述bug)
HTTP协议的server下，如果请求返回的数据较大时，数据返回延迟过高（不是rpc方法延迟，方法内无阻塞，延迟经测试很低）。返回数据100mb时，并行50个请求需要等到很久后（45s）同时发出的请求才会陆续收到回报，显著慢于只打一个请求（1.3s）, 单个请求返回1GB时耗时10s显著慢于网卡的吞吐

To Reproduce (复现方法)
http协议的server返回内容如下，value为大小为100MB或1GB的字符串

std::string value(1024*1024*100, 'a'); 
cntl->http_response().set_status_code(200);
cntl->http_response().set_content_type("text/plain");
cntl->response_attachment().append(value.c_str(), value.length());

打http请求

Expected behavior (期望行为)
当并发50个http请求，返回value为100MB时，50个请求在发出请求45秒后统一陆续返回。如果只有一个请求，返回value 100MB只需要1.3s。

一次请求，如果返回value为1GB，leave method耗时要10多s（不考虑rpc方法内的时间），请求端很久收到返回，延迟过高。
Versions (各种版本)
OS: ubuntu20
Compiler: gcc13
brpc: 1.11.0
protobuf: 3.21.12

Additional context/screenshots (更多上下文/截图)

[chenBright]

试试持续下载看有没有改善？

[mizuse-emiya]

试试持续下载看有没有改善？

抱歉，我们使用的是http直接请求，没有用brpc的client，然后主要问题在于返回1g的数据花了10多秒，根据日志显示应该是请求3秒内rpc方法已经处理完了，也就是返回数据写入socket到返回花了10秒时间，这和我们的网卡带宽和brpc的性能测试貌似不太对得上

[chenBright]

可以抓包看看server发包情况吧

[mizuse-emiya]

[mizuse-emiya]

你好，已经抓包分析，测试是返回一次http请求返回1GB数据， 看起来server在接受请求后0.7秒开始发包返回数据
1GB均匀得发送了10s才将数据发送完毕，这和我们网卡的吞吐有点对不上，测试服务器上当时没有其他大量数据往返的网络请求。

[chenBright]

会不会是网络问题或者client收数据慢了呢？

1. 有没有发生丢包、重传、拥塞控制？
2. 分析一下抓包数据，client的接受窗口有没有变化？
3. 看一下bvar内置服务rpc_keepwrite_second、rpc_waitepollout_count、rpc_waitepollout_second这三个指标。

[mizuse-emiya]

会不会是网络问题或者client收数据慢了呢？

1. 有没有发生丢包、重传、拥塞控制？
2. 分析一下抓包数据，client的接受窗口有没有变化？
3. 看一下bvar内置服务rpc_keepwrite_second、rpc_waitepollout_count、rpc_waitepollout_second这三个指标。

1.丢包和重传发生次数较少，但触发了过拥塞控制，接受窗口有变化，如图

但是平时的发送速率依然不高，貌似不是bottleneck
2.请求时rpc_keepwrite_second只在瞬时超过4s，另两个指标如图，但是不太理解什么意思

[chenBright]

rpc_waitepollout_count表示server写socket写到EAGAIN的次数，看起来server不是瓶颈。

[mizuse-emiya]

rpc_waitepollout_count表示server写socket写到EAGAIN的次数，看起来server不是瓶颈。

client的窗口看着还好没有真正限制到发包过，网卡本身发包慢？

[chenBright]

有可能

[Huixxi]

rpc_waitepollout_count表示server写socket写到EAGAIN的次数，看起来server不是瓶颈。

client的窗口看着还好没有真正限制到发包过，网卡本身发包慢？

这个现在定位了么