为什么在net/http中不直接关闭连接而是将连接放入一个新列表中？

偷偷努力，悄无声息地变强，然后惊艳所有人！哈哈，小伙伴们又来学习啦~今天我将给大家介绍《为什么在net/http中不直接关闭连接而是将连接放入一个新列表中？》，这篇文章主要会讲到等等知识点，不知道大家对其都有多少了解，下面我们就一起来看一吧！当然，非常希望大家能多多评论，给出合理的建议，我们一起学习，一起进步！

最近看了golang的源码，发现一个地方不太明白。

if t.MaxIdleConns != 0 && t.idleLRU.len() > t.MaxIdleConns { 
    oldest := t.idleLRU.removeOldest() 
    oldest.close(errTooManyIdle) 
    t.removeIdleConnLocked(oldest) 
 }

代码在这里：https://github.com/golang/go/blob/96c8cc7fea94dca8c9e23d9653157e960f2ff472/src/net/http/transport.go#l984-l988

问题： 当idleconn的长度> t.maxidleconns时，为什么不直接关闭conn，而是将conn放入新的列表中。同时，删除列表中最旧的 conn。据我了解，关闭冗余连接很简单，而且结果是正确的。

正确答案

我推测原因是服务器（远程）无论如何都没有义务保持空闲连接打开，即使它决定这样做，也没有义务只要客户要求，就保持开放。
另一个可能的问题是，空闲的 TCP 会话可以被中间网络节点主动终止（例如，NAT 设备通常必须为它们路由的每个 TCP 会话维护某种状态，因此它们“有兴趣”摆脱它们认为需要的会话。死了）； TCP keepalive 可能会有所帮助，但应该启用它们（情况并非总是如此），并且它们的“ping”应该足够频繁，以便中间节点认为此类会话处于活动状态，但情况又并非总是如此。 p>

这些问题很容易导致会话空闲一段时间后被服务器或中间网络节点关闭。 除此之外，基本上 net/http 没有简单的方法来知道特定的空闲连接是否确实已关闭并且在自上一次 HTTP 会话执行以来的时间范围内变得不可用，直到 net/http 拉动该连接用于进行另一次会话。

如果您进一步阅读代码，您会发现 net/http 尝试使用空闲连接，如果发现它已失效，它将选择下一个连接，并重复该操作，直到一个连接有效，否则将被迫建立新连接。

因此，更新的连接更有可能准备好为另一个 HTTP 会话提供服务。

添加另一条推理，与上面介绍的有些相关：服务器可能对同时活动连接的数量有限制 - 总数，或每个（源）主机，或两者 - 并且在生产设置中通常有。按照这种逻辑，如果与它的连接成功，则可能意味着客户端认为某些旧连接处于活动状态（尽管处于空闲状态），但服务器已关闭该连接，因此它能够在保持其配置范围内创建新连接活动连接数的限制。当然，这样的逻辑只是一种猜测，但并非毫无根据。

终于介绍完啦！小伙伴们，这篇关于《为什么在net/http中不直接关闭连接而是将连接放入一个新列表中？》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布Golang相关知识，快来关注吧！