windows下：Spin即使没有任何请求正在处理，server依然会等ExitWaitTimeout秒后退出

[xiaotushaoxia]

Describe the Question

windows下：Spin即使没有任何请求正在处理，server依然会等ExitWaitTimeout秒后退出

Reproducible Code

h := server.Default(server.WithHostPorts(":5653"))
h.Spin()

开启后直接ctrl+c，程序依然会等待。

看了下问题应该出在
github.com\cloudwego\hertz\pkg\network\standard\transport.go 112行。因为ubuntu下使用netpoll.transport，和standard.standard的Shutdown实现不一样，所以只在windows下存在问题。

参考net.http的shutdown实现，net.http.Server会记录所有客户端，Shutdown后有在ctx.Done前尝试去关闭全部客户端，如果客户端已经退出了，Shutdown就直接返回。hertz.Server似乎没有记下全部客户端，所以Shutdown硬等到ctx.Done， 这个实现应该是有瑕疵的

Hertz version:
v0.6.6

[github-actions]

This issue has been marked as invalid question, please give more information by following the issue template. The issue will be closed in 1 days if no further activity occurs.

[li-jin-gou]

hi @xiaotushaoxia 改下 issue 模版吧，否则可可能会被自动close。

[welkeyever]

@xiaotushaoxia 赞，这个 diff 是标准网络库和 netpoll 实现上没有完全对齐。我记录一个 TODO，有兴趣的话也非常欢迎 PR 哈~

[xiaotushaoxia]

嗯。我的想法是参考net.http实现。net.http中的conn会记录状态 New Idle Active， server（hzrtz中的Transporter） shutdown的时候在ctx.Done前一次次关闭全部Idle的conn，直到全部连接关闭。
所以需要做的事

1. 因为conn的状态要更新，所以handler方法中要更新conn的状态
2. 因为要关闭关闭idle的conn，所以Transporter需要记录全部的conn

2的主要问题是要记录全部conn需要加锁，不知道会不会有性能影响（不过可能是杞人忧天，不要提前优化....)
1难受的点在conn的状态维护要离开Transporter，在http协议处理那边（pkg.protocol.server下的Server.Serve）。而Serve的参数network.Conn又没有设置状态的方法，修改network.Conn又感觉不妥。
@welkeyever

[li-jin-gou]

个人感觉如果有性能损失的话&不如不完善 win 的体验😞，原因是服务实际部署大概率还是在 linux 上部署，win 更多是开发调试👀

[xiaotushaoxia]

嗯。本来就是为了高性能做的这个，我翻了下issues，看到也有提到hertz因为性能舍弃一些边缘功能的评论。
然后是一开始我的评论提到netpoll.transport没这个问题。其实netpoll.transport的shutdown应该有差不多的问题，它shutdown后可能程序直接就退出了，不会等当前的连接完成。
权衡下看要不要处理这个问题吧
@li-jin-gou @welkeyever

[welkeyever]

netpoll的shutdown其实是符合预期的：进入graceful阶段会将正在进行中的响应置为短连接，若所有长链接都被正常关闭后则提前退出，否则等待到用户配置的最大退出时间。
标准网络库如果要对齐的话可以按照这个行为来对齐。

直接在graceful进入的时刻批量关闭所有idle状态的链接，这个行为我不认为比上述行为更优：它并不会额外降低连接关闭时刻的并发问题。并且仅是在idle连接退出时间上的一点区别。

[zhouguanglong1]

这个问题，在macOS m2-arm64上面也会出现。现象是，如果hertz启动后没有任何请求，关闭和重启都是瞬间完成。如果有过一个请求，点击关闭和重启，就需要等待5s。

[welkeyever]

@zhouguanglong1 这个是符合预期的，大概率是因为你的链接没有关闭（浏览器默认都是长链接），这个可以本地使用telnet模拟，关闭链接的话直接ctrl-C就可以。