關(guān)于tcp_tw_reuse。官方文檔上說tcp_tw_reuse 加上tcp_timestamps（又叫PAWS, for Protection Against Wrapped Sequence Numbers）可以保證協(xié)議的角度上的安全，但是你需要tcp_timestamps在兩邊都被打開（你可以讀一下tcp_twsk_unique的源碼?）。我個(gè)人估計(jì)還是有一些場景會有問題。

關(guān)于tcp_tw_recycle。如果是tcp_tw_recycle被打開了話，會假設(shè)對端開啟了tcp_timestamps，然后會去比較時(shí)間戳，如果時(shí)間戳變大了，就可以重用。但是，如果對端是一個(gè)NAT網(wǎng)絡(luò)的話（如：一個(gè)公司只用一個(gè)IP出公網(wǎng)）或是對端的IP被另一臺重用了，這個(gè)事就復(fù)雜了。建鏈接的SYN可能就被直接丟掉了（你可能會看到connection time out的錯(cuò)誤）（如果你想觀摩一下Linux的內(nèi)核代碼，請參看源碼?tcp_timewait_state_process）。

關(guān)于tcp_max_tw_buckets。這個(gè)是控制并發(fā)的TIME_WAIT的數(shù)量，默認(rèn)值是180000，如果超限，那么，系統(tǒng)會把多的給destory掉，然后在日志里打一個(gè)警告（如：time wait bucket table overflow），官網(wǎng)文檔說這個(gè)參數(shù)是用來對抗DDoS攻擊的。也說的默認(rèn)值180000并不小。這個(gè)還是需要根據(jù)實(shí)際情況考慮。

Again，使用tcp_tw_reuse和tcp_tw_recycle來解決TIME_WAIT的問題是非常非常危險(xiǎn)的，因?yàn)檫@兩個(gè)參數(shù)違反了TCP協(xié)議（RFC?1122）?

其實(shí)，TIME_WAIT表示的是你主動斷連接，所以，這就是所謂的“不作死不會死”。試想，如果讓對端斷連接，那么這個(gè)破問題就是對方的了，呵呵。另外，如果你的服務(wù)器是于HTTP服務(wù)器，那么設(shè)置一個(gè)HTTP的KeepAlive有多重要（瀏覽器會重用一個(gè)TCP連接來處理多個(gè)HTTP請求），然后讓客戶端去斷鏈接（你要小心，瀏覽器可能會非常貪婪，他們不到萬不得已不會主動斷連接）。

數(shù)據(jù)傳輸中的Sequence Number

下圖是我從Wireshark中截了個(gè)我在訪問coolshell.cn時(shí)的有數(shù)據(jù)傳輸?shù)膱D給你看一下，SeqNum是怎么變的。（使用Wireshark菜單中的Statistics ->Flow Graph… ）

?

你可以看到，SeqNum的增加是和傳輸?shù)淖止?jié)數(shù)相關(guān)的。上圖中，三次握手后，來了兩個(gè)Len:1440的包，而第二個(gè)包的SeqNum就成了1441。然后第一個(gè)ACK回的是1441，表示第一個(gè)1440收到了。

注意：如果你用Wireshark抓包程序看3次握手，你會發(fā)現(xiàn)SeqNum總是為0，不是這樣的，Wireshark為了顯示更友好，使用了Relative SeqNum——相對序號，你只要在右鍵菜單中的protocol preference 中取消掉就可以看到“Absolute SeqNum”了

TCP重傳機(jī)制

TCP要保證所有的數(shù)據(jù)包都可以到達(dá)，所以，必需要有重傳機(jī)制。

注意，接收端給發(fā)送端的Ack確認(rèn)只會確認(rèn)最后一個(gè)連續(xù)的包，比如，發(fā)送端發(fā)了1,2,3,4,5一共五份數(shù)據(jù)，接收端收到了1，2，于是回ack 3，然后收到了4（注意此時(shí)3沒收到），此時(shí)的TCP會怎么辦？我們要知道，因?yàn)檎缜懊嫠f的，SeqNum和Ack是以字節(jié)數(shù)為單位，所以ack的時(shí)候，不能跳著確認(rèn)，只能確認(rèn)最大的連續(xù)收到的包，不然，發(fā)送端就以為之前的都收到了。

超時(shí)重傳機(jī)制

一種是不回ack，死等3，當(dāng)發(fā)送方發(fā)現(xiàn)收不到3的ack超時(shí)后，會重傳3。一旦接收方收到3后，會ack 回 4——意味著3和4都收到了。

但是，這種方式會有比較嚴(yán)重的問題，那就是因?yàn)橐赖?，所以會導(dǎo)致4和5即便已經(jīng)收到了，而發(fā)送方也完全不知道發(fā)生了什么事，因?yàn)闆]有收到Ack，所以，發(fā)送方可能會悲觀地認(rèn)為也丟了，所以有可能也會導(dǎo)致4和5的重傳。

對此有兩種選擇：

一種是僅重傳timeout的包。也就是第3份數(shù)據(jù)。

另一種是重傳timeout后所有的數(shù)據(jù)，也就是第3，4，5這三份數(shù)據(jù)。

這兩種方式有好也有不好。第一種會節(jié)省帶寬，但是慢，第二種會快一點(diǎn)，但是會浪費(fèi)帶寬，也可能會有無用功。但總體來說都不好。因?yàn)槎荚诘萾imeout，timeout可能會很長（在下篇會說TCP是怎么動態(tài)地計(jì)算出timeout的）

快速重傳機(jī)制