面试中必问之——TCP细节

也许你知道TCP的三次握手，四次挥手(学校里老师通常说的是三报文握手，四报文挥手。。。)的所有细节，你知道为什么是三次握手，为什么又是四次挥手。两次握手，三次挥手可不可以为什么？你知道为什么在主动断开方有Time_wait状态，被动断开方有Close_wait状态？
今天我们要谈的是上面没有出现的过的问题。更确切的说是更贴近实际应用生产环境的问题。

你知道当处于Time_wait状态的主机过多时会影响性能，但你知道为什么会导致这样的情况出现么？同样的道理，处于Close_wait状态的主机过多，又是什么原因导致的呢？

这就是本篇blog的重点所在。究其最本质的原因，写过网络server的应该知道如果我写的server或者client在调用socket()之后拿到了OS为我们分配的socket，然后进行了一系列其他的操作之后，最后应该close(socket)，但这个时候如果我们忘记了怎么办？

所以抛出第一个问题 写网络程序的时候忘记close()会发生什么事情？以及如何解决这个问题？

经过上面的分析，你可以知道忘记close可能是导致Close_wait状态过多的罪魁祸首。。接着最开始的问题来说，抛出第二个问题 处于Time_wait状态过多的原因是什么？如何解决这个问题？

大家熟悉TCP的话，知道Time_wait状态存在的意义，以及其所对应的时效性。一般都是2MSL(Maximum Segment Lifetime）,一般而言1MSL设置成1min，伯克利的unix上设置的是30s。建议性质的MSL就设置成1min即可。
这个时效的设置是有深刻意义的。

意义何在？

首先，最后一次挥手时的ACK如若不能正常到达对端，由于每次发送请求或应答报文都会开启一个timer，当超时时间到了，对端一定会重传FIN，如果我这段没有这个等待的时间就直接退出的话，会导致对端一直重传该FIN，并且当另一个服务启动时，恰好分配到了本次交互用的端口，那么该服务启动时将收到莫名其妙的数据，这是我们不想看到的。
其次，所有的网络协议没有100%可靠的，只能做到尽可能的可靠，网络拓扑结构的复杂以及网络的实时性变化，都将导致完全可靠的网络传输协议的创建困难重重。。所以对于复杂的网络环境，我们无法确保发送的数据是否到达对端，完全有可能在网络中滞留着，而对我们而言并不会有任何的反应。所以我们得确保已发送的数据要么到达对端，要么保证在传输的过程中当超过一定时间这个数据包将被沿途的路由器所丢弃掉。。这一点很重要！！！很重要！！！很重要！！！由此引入了MSL，最大报文生存时间，每个报文都是有其生命周期的，当没有在有效期内被接收时，它将被丢弃。

解决方案

上面只是说了Time_wait的意义何在，并没有说到当Time_wait状态的主机过多时如何解决？
一般来说，其一，对于不同的业务是需要进行相应的参数调整的，在测试过程中将有些参数调整至最佳。MSL的长短是可以进行调整的，通常可以先用top命令查看一下，是否处于Time_wait的主机过多，如果出现这样的情况，就适当减少MSL的时间。这是其一。
其二，需要对主动断开方的代码进行调试，debug找出为啥会一直处于Time_wait状态，

下面这篇博文可以参考着看一下，我只是在文字上面进行了说明，这篇博文里面带有图，可以参照着看。
计算机网络之TCP复习

代码测试后续补上。。。。。