近来产品销量不错，带来的是服务器疯狂告警：TIME_WAIT 连贯数量过多。TCP 的大抵协定我有理解，但其中的很多细节以及中间状态抓得并不深。因而打算翻译这篇 TIME_WAIT and its design implications for protocols and scalable client server，学习的同时思考一下怎么解决服务器上的告警问题。
以下为原文翻译：
在建设应用 TCP 进行通信的 client-server 零碎时，很容易因为一些小谬误重大影响零碎的扩展性。其中的一个谬误就是没有思考 TIME_WAIT 状态。在这篇文章中，我将解释 TIME_WAIT 状态存在的起因、它可能引发的问题、以及你围绕整个状态应该和不应该做的一些事件。
TIME_WAIT 是一个在 TCP 状态转换图中常常被误会的状态。它标记着一些 socket 可能进入或停留在了一个绝对长时间的状态中。如果你的服务器有大量的 socket 处在 TIME_WAIT 状态，那么就很有可能影响你持续创立新的 socket 连贯，从而影响你的服务器扩大能力。首先，对于 socket 如何以及为什么会进入 TIME_WAIT 状态就常常有一些误会。按理说这不应该，这个状态转换也并不神奇。从上面的 TCP 状态转换图能够看到，TCP 客户端通常最终都会进入 TIME_WAIT 状态。
只管图中显示 TIME_WAIT 是 client 的最终状态，但并不示意肯定是 client 才会进入 TIME_WAIT。在 TCP 连贯对中，无论是 client 还是 server，谁发动了“active close”，谁就会最终进入 TIME_WAIT 状态。那么问题来了，“active close”指的是什么呢？
在 TCP 连贯中，一端发动了“active close”示意由这一端在连贯中先调用了 Close()。在很多协定和 client/server 架构设计中，都是由 client 触发。但在 HTTP 和 FTP 服务器上，发动的通常是 server。导致 TCP 一端进入 TIME_WAIT 状态的理论过程如下图所示：
当初咱们晓得了 socket 是如何进入 TIME_WAIT 状态的。这有助于咱们了解为什么存在这个状态，以及为什么它可能暗藏着潜在问题。
TIME_WAIT 状态也常常被称为 2MSL wait 状态，这是因为 socket 在转变成 TIME_WAIT 状态当前，会停留 2 倍的 Maximum Segment Lifetime（MSL）工夫。MSL 指的是组成 TCP 协定的任何数据包在被抛弃前能够在网络中保留的最大工夫。这个工夫限度最终会绑定在传输 TCP 数据的 IP 报文里的 TTL 字段中。在不同实现中，MSL 会有不同的取值，而最通常的取值是 30s，1 分钟或 2 分钟。RFC 793 中将这个值定义为 2 分钟，Windows 零碎也把 2 分钟设定为默认值，不过能够通过 TcpTimedWaitDelay 这个注册设置进行调整。
TIME_WAIT 状态可能影响零碎扩展性的起因是，一旦一个 TCP 连贯中的 socket 被敞开了，它依然会停留在 TIME_WAIT 状态长达 4 分钟。如果有大量的连接不断被创立和敞开，那么 TIME_WAIT 状态的 socket 就会开始一直累加。你能够用 netstat 来察看处于 TIME_WAIT 状态的 socket。一台服务器同一时间可能建设的连贯数量是无限的，其中的一个限度就是服务器的本地端口数量。如果有太多连贯处于 TIME_WAIT 状态，那么你会发现很难再对外建设连贯，因为曾经没有足够的本地端口来反对新连贯。既然有这样的问题，那么为什么还会存在 TIME_WAIT 状态呢？
设计 TIME_WAIT 状态有两个起因。第一个就是避免连贯中提早达到的数据包被误认为是后续的新连贯报文。当一个连贯处于 2MSL wait 状态时，任何后续到达的报文都会被抛弃。
在上图中能够看到从终端 1 向终端 2 建设的两个连贯，在各个连贯中它们的地址和端口都是一样的。第一个连贯由终端 2 发动了“active close”。如果终端 2 不在 TIME_WAIT 状态停留足够长的工夫来抛弃前一次连贯中所有后续报文，那么后续到来的报文（带有正当的 sequence number）就有可能被认为是一个新的连贯。
请留神，其实这类提早报文触发的问题很难产生。首先它须要连贯中地址和端口都一样，这自身概率就很低，因为应用什么客户端端口是由操作系统从长期端口中抉择的，通常不同连贯会有不同端口。其次，提早报文携带的 sequence number 也很难凑巧在新连贯中被断定非法。总之，当这两种状况都产生时，TIME_WAIT 状态能够阻止新连贯中的数据被提早报文所影响。
TIME_WAIT 状态存在的另一个起因是保障 TCP 全双工连贯中断的可靠性。如果终端 2 发来的最初一个 ACK 包丢包了，那么终端 1 会重发最初一个 FIN 包。但如果此时终端 2 上连贯曾经进入了 CLOSED 状态，那么它只会回一个 RST，因为此时收到的 FIN 包并不在预期内。这就会导致终端 1 即便正确发送了所有报文，但最初依然收到了一个谬误回复。
可怜的是，不少操作系统对 TIME_WAIT 状态的实现看起来略显简略。只有那些真正符合条件的 socket 才须要被阻塞来取得 TIME_WAIT 状态提供的爱护。须要爱护的是那些可能通过 client 地址和端口，server 地址和端口准确匹配标识进去的连贯。但有些操作系统实现的限度更加严格，那些处于 TIME_WAIT 状态的连贯应用的本地端口号都不能被复用。如果有足够多的 socket 进入了 TIME_WAIT 状态，那么零碎就会因为短少可用的本地端口，而无奈创立新的出站连贯。
Windows 操作系统并不会这样做，它只会限度建设那些与 TIME_WAIT 状态下的已有连贯各属性完全一致的新出站连贯。
入站连贯很少受 TIME_WAIT 状态的影响，当一个连贯在 server 的“active close”操作下进入 TIME_WAIT 状态时，服务器监听的本地端口并不会在一个新的入站连贯中被阻止应用。在 Windows 操作系统中，server 正在监听的 TIME_WAIT 连贯的出名端口能够被用于组成新的连贯，而如果新连贯中的远端地址和端口恰好与将要复用的这个正处于 TIME_WAIT 状态的连贯统一，那么这条连贯只承受比 TIME_WAIT 连贯中最初一个 sequence number 更大 sequence number 报文。尽管 TIME_WAIT 对入站连贯影响比拟小，但一台服务器上的 TIME_WAIT 连接不断累积会对性能和资源造成影响，因为解决 TIME_WAIT 过期会须要一些操作，而且连贯在最终完结 TIME_WAIT 状态进而敞开前，会继续占用系统资源（只管占用的资源不多）。
既然 TIME_WAIT 状态会因为占用本地端口从而影响服务器创立出站连贯，而创立连贯时应用的本地端口是由操作系统从长期端口范畴中抉择的，那么为了改善这种状况，你能够做的第一件事就是确保你的长期端口范畴足够大。在 Windows 操作系统中，你能够调节 MaxUserPort 这个注册表配置。请留神在默认设置下 Windows 零碎可用的长期端口范畴大略在 4000 个左右，对很多 client/server 零碎来说都太小了。
只管能够缩小 socket 处于 TIME_WAIT 状态的工夫，但这项操作通常不会有什么帮忙。因为只有大量连贯建设，而后被 active close，才会进入 TIME_WAIT 状态并引发问题，调节 2MSL 等待时间通常只会容许在一段时间内创立和敞开更多的连贯，所以你须要继续调低 2MSL 工夫直到 TIME_WAIT 的爱护性能生效，此时就可能触发提早包在后续连贯中呈现，从而带来问题。当然这种问题只会在几种状况下呈现：你对同一个远端地址和端口建设连贯而且短时间内用尽了所有的本地端口，或者你须要应用一个固定的本地端口对远端同一个地址和端口建设连贯。
批改 2MSL 工夫通常是一个全局失效的配置，除了批改这个配置你还能够尝试批改 SO_REUSEADDR 同样在 socket 层面解决 TIME_WAIT。这个选项容许创立一个与已有 socket 的地址和端口都雷同的 socket，新的 socket 会劫持老的 socket。你能够通过容许 SO_REUSEADDR 来容许应用一个处在 TIME_WAIT 状态的端口被用来创立新 socket，但也须要承当拒绝服务攻打和数据包窃取的危险。在 Windows 平台中，另一个 socket 配置 SO_EXCLUSIVEADDRUSE 能够防止 SO_REUSEADDR 引起的一些问题。不过在我看来，与其扭转这些配置，不如从新设计零碎来齐全躲避 TIME_WAIT 问题。
之前图中的 TCP 状态转换都展现了有序的 TCP 连贯敞开。然而还有另一种敞开 TCP 连贯的办法，叫做 abort close，也就是发送一个 RST 包而不是 FIN 包。这通常能够通过设置 SO_LINER 这个 socket 配置为 0。这会导致连贯间接应用一个 RST 来敞开，抛弃期待传输的数据，而不是像失常状态一样传输期待数据并发 FIN 包完结连贯。须要留神的是一旦连贯被中断，会间接传输一个 RST 包，连贯中所有的数据都会被抛弃。通常状况下会产生一个 error 标识“connection has been reset by the peer”。而后对端会晓得连贯被中断，两边都不会进入 TIME_WAIT。
当然一个连贯在被 RST 终止后也会受到 TIME_WAIT 所爱护的提早报文的影响。不过触发的条件很严苛，简直不可能。如果要防止中断操作后受提早报文影响（比方是由中间设备，像是路由器触发了连贯敞开），就须要 TCP 两端都进入 TIME_WAIT 状态。不过这简直不会产生，TCP 两端目前都只是简略的敞开了连贯。
你有很多操作能够阻止 TIME_WAIT 状态引发问题。其中一些操作假如你有能力来扭转你的 client 和 server 之间的交互协定。对于大多数自行设计 server 端的场景都合乎这个条件。
对于一个从来不会被动对外建设连贯的服务器来说，除了维持处在 TIME_WAIT 状态下的连贯所须要的资源和性能以外，你不须要过分放心。
对于一个既接入连贯，又会对外创立连贯的服务器来说，黄金准则是保障连贯在对端敞开，最好的方法就是无论什么起因，从不发动“active close”。如果对端超时，应用 RST 中断连贯而不是敞开它。如果对端发送了谬误数据，同样回复 RST，等等。如果服务器从不被动发动“active close”，那么连贯就不会进入 TIME_WAIT，也就不会受到 TIME_WAIT 状态带来的问题影响。这种想法下，只管咱们能够很容易晓得谬误产生时该如何解决，但失常的连贯该如何敞开呢？现实的解决办法是在协定中协商由 client 端发动断开连接。当 server 认为该当断开连接时，从应用层发一个“连贯完结”的报文，告知 client 被动敞开连贯。如果在正当工夫内 client 没有敞开连贯，那么 server 端就终止连贯。
而在客户端，事件就更加简单。既然必然要有一端须要发动“active close”来终止 TCP 连贯，那么把 TIME_WAIT 状态管制在 client 端会有以下几个益处：首先，会受 TIME_WAIT 累积从而影响连贯的只会是一个客户端，其它客户端不会受影响。其次，客户端一直对同一个服务器疾速关上敞开 TCP 连贯是没有意义的，比解决 TIME_WAIT 问题更有意义的是维持更长时间的连贯。不要设计一个客户端每分钟都会向服务端建设新连贯的协定机制，该当应用一个长连贯设计，只在连贯断开时进行重连。如果两头的路由器回绝放弃连贯，你可能须要实现一个利用层面的心跳包，或者应用 TCP keep alive，或者承受路由器一直重置连贯：益处是不会有 TIME_WAIT 状态的 socket 累积。如果你在连贯中做的事就是短暂的，那么思考应用连接池设计来保障连贯关上，并复用连贯。最初，如果你就是要让客户端向同一个服务器一直疾速地关上敞开连贯，那么你可能须要设计一个应用层的敞开逻辑，实现敞开逻辑后间接终止连贯（abortive close）。你的客户端发送过一个“I’m done”，而后服务器回一个“goodbye”，而后客户端终止连贯。
TIME_WAIT 状态的存在是有情理的，而缩短 2MSL 工夫或者容许地址复用并不是很好的解决问题的方法。如果你能够设计你的协定来防止 TIME_WAIT，那你通常就能完全避免这个问题。
如果你想要理解 TIME_WAIT 实现上更多的信息，以及它是如何工作的，你能够查看这篇和这篇文章。