最近同事遇到一個(gè)問題，使用python開發(fā)的工具在執(zhí)行的時(shí)候無法和MySQL建立連接，其最直接的現(xiàn)象就是滿篇的TIME_WAIT，最后通過調(diào)整tcp_timestamps參數(shù)問題得以解決，再次記錄一下這次解決的經(jīng)驗(yàn)總結(jié)。

ps：不過先汗顏一個(gè)，對(duì)基礎(chǔ)的tcp知識(shí)太不敏感了，需要回爐重新學(xué)習(xí)啊。

一、看下TIME_WAIT產(chǎn)生的原因

大家都知道建立連接是著名的三次握手機(jī)制。

那么如何關(guān)閉連接呢？ 其實(shí)也是著名的四次握手機(jī)制。

TIME_WAIT就產(chǎn)生在四次握手的的主動(dòng)關(guān)閉方，而server端會(huì)進(jìn)入close狀態(tài)。

那么TIME_WAIT什么時(shí)候會(huì)消失呢？linux會(huì)在2MSL時(shí)間內(nèi)消失。（MSL是最大分段生存期，默認(rèn)為2分鐘）

二、無法建立連接的原因

　　由于同事的腳本的用途是進(jìn)行采集數(shù)據(jù)后的寫入操作，為了加快速度故使用python的map功能并發(fā)寫入數(shù)據(jù)庫(kù)，當(dāng)在腳本執(zhí)行的服務(wù)器上報(bào)錯(cuò)后，發(fā)現(xiàn)滿篇都是TIME_WAIT的現(xiàn)象。

　　經(jīng)過我們內(nèi)部討論，初步認(rèn)為是由于TIME_WAT沒有快速回收導(dǎo)致Linux的可用端口被沾滿導(dǎo)致無發(fā)建立連接，和MySQL的設(shè)置沒有關(guān)系。

　　查看目前Linux可用端口范圍：

[me]sysctl -a|grep ip_local_port_range net.ipv4.ip_local_port_range = 32768    61000

　　查看當(dāng)前占用的端口直接用netstat就可以了：

netstat -nat|grep -i time_wait|wc -l

三、如何解決？

對(duì)于TCP鏈接的優(yōu)化大家都知道的三個(gè)參數(shù)：tcp_tw_reuse、tcp_tw_recycle、tcp_timestamp

1、我們先看看這3個(gè)參數(shù)的定義和作用。

tcp_tw_reuse：用來使用time-wait狀態(tài)的sockets重用

Allow to reuse TIME-WAIT sockets for new connections when it issafe from PRotocol viewpoint. Default value is 0.It should not be changed without advice/request of technical experts.

tcp_tw_recycle：用來加速對(duì)time-wait

Enable fast recycling TIME-WAIT sockets. Default value is 0.It should not be changed without advice/request of technical experts.

tcp_timestamp:在TCP的包頭添加時(shí)間戳

Enable timestamps as defined in RFC1323

2、調(diào)整記錄

我們先查看服務(wù)器的狀態(tài)，發(fā)現(xiàn)reuse和recycle的參數(shù)都是1，但是time_wait并沒有被很快的回收，也沒有被快速的重用。

[root ~]# cat /proc/sys/net/ipv4/tcp_tw_reuse 1[root ~]# cat /proc/sys/net/ipv4/tcp_tw_recycle 1

后來發(fā)現(xiàn)是由于tcp_timestamp這個(gè)參數(shù)設(shè)置為0的原因

[root ~] cat /proc/sys/net/ipv4/tcp_timestamps 0

將這個(gè)參數(shù)置為1之后，time_wati的狀態(tài)立刻下降了很多，腳本也可以正常執(zhí)行了。看來tcp_timestamp非常關(guān)鍵。

3、探尋原因

但是，究竟是tcp_tw_reuse起作用了？ 還是tcp_tw_recycle起作用了？我們還是不知道，只能從現(xiàn)象得知問題解決了。

我們將tcp_tw_recycle的值設(shè)定為0之后，再次測(cè)試，再次出現(xiàn)了大量的time_wait現(xiàn)象。

為了證明tcp_tw_recycle真正起作用了，我們?cè)俅螌cp_tw_reuse參數(shù)設(shè)置為1，這時(shí)候也再次出現(xiàn)了大量的time_wait的現(xiàn)象。

看來，最終我們的結(jié)論是同時(shí)開啟tcp_tw_recycle，tcp_tw_reuse和tcp_timestamp才能真正做到快速回收和服用time-wait狀態(tài)的socket。

從stackoverflow上看到的一個(gè)答案比較靠譜。點(diǎn)這里

但是同時(shí)也發(fā)現(xiàn)，網(wǎng)上有很多信息顯示，如果同時(shí)開啟tcp_tw_recycle和tcp_timestamp會(huì)出現(xiàn)問題。主要是由于TCP的一種行為

RFC 1323　　TCP Extensions for High Performance　　Jacobson, Braden, & Borman

An additional mechanism could be added to the TCP, a per-hostcache of the last timestamp received from any connection.This value could then be used in the PAWS mechanism to rejectold duplicate segments from earlier incarnations of theconnection, if the timestamp clock can be guaranteed to haveticked at least once since the old connection was open.  Thiswould require that the TIME-WAIT delay plus the RTT togethermust be at least one tick of the sender's timestamp clock.Such an extension is not part of the proposal of this RFC.

三、結(jié)論

1、開啟tcp_timestamp是開啟tcp_tw_recycle，tcp_tw_reuse和tcp_timestamp的前提條件。

2、但是在nat模式下，不用將tcp_tw_recycle和tcp_timestamp同時(shí)開啟，這會(huì)造成tcp超時(shí)引發(fā)故障。

附錄：

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

http://lxr.free-electrons.com/source/net/ipv4/tcp_minisocks.c#L92

http://www.ietf.org/rfc/rfc1323.txt