FULI

我再研究下

你可以尝试下我最新的提交，自己编译下

这个问题大概是这样的： 1. Ctrl+C中断后，留在streambuf中的待发送数据，还在排队发送中，对端也还在持续echo 2. 因此第二次再次链接的时候，表现在卡住了，因为上一个链接的数据包，还堆积在发送队列中（因为这次改了closeWait等待30秒才发起关闭，主要是处理有一些链接会 HALF_CLOSE的问题），导致了SMUX的streamSYN并没有及时发送处理，卡在开启链接。

你可以尝试如下：（在最新的版本下，只改kcptun中的std/copy.go） 1. 修改closeWait的时间，改为0，1 2. 启动参数中，增大smuxbuffer的大小。防止堆积

因此，我接下来要做的尝试如下： 区分server端的copy和client端的copy。 client端的copy是需要立即关闭的，不等待。

https://github.com/xtaci/kcptun/commit/142ac6b48f218b17c80cbb7c1477eceb2bca97da

怎么说呢，这个问题可以环节，但因为是复用在一条链路上，因此一定存在 对头阻塞问题，就是Ctrl+C下中断不了已经堆积在kcp发送队列的数据。 https://zh.wikipedia.org/wiki/%E9%98%9F%E5%A4%B4%E9%98%BB%E5%A1%9E

对的，就是这个问题，ctrl+c后，服务端在kcp 队列中的，cancel不掉，那么你可以降低per streambuffer，来缓解这个问题。

主要是有些奇葩的服务器，会用TCP HALF CLOSE，只关闭发送，不关闭接收，这种情况下，还得预留一个时间来收(30s) 。当然，对于你们的特定应用，你是可以关闭closeWait的，或者这个作为参数，写入启动config。我考虑下。

3ec90cd66d42521db3232c347b89f488c5d94276 @Frank-pv 参数化了