tcp 協(xié)議 是互聯(lián)網(wǎng)中最常用的協(xié)議 ， 開(kāi)發(fā)人員基本上天天和它打交道，對(duì)它進(jìn)行深入了解。 可以幫助我們排查定位bug和進(jìn)行程序優(yōu)化。下面我將就TCP幾個(gè)點(diǎn)做深入的探討
一、TCP連接階段
一、TCP 三次握手
1、兩次握手行不行？
客戶端：收到 ack 后 分配連接資源。 發(fā)送數(shù)據(jù)
服務(wù)器 : 收到 syn 后立即 分配連接資源
缺陷：
當(dāng)ack 丟失后， 服務(wù)器認(rèn)為連接建立了，等待客戶端發(fā)送數(shù)據(jù)。 但是客戶端并沒(méi)有建立連接。服務(wù)器一直在等待數(shù)據(jù)，耗費(fèi)資源。
PS: 網(wǎng)上有說(shuō)法是什么TCP全雙工需要互相確認(rèn)，個(gè)人覺(jué)得和這個(gè)沒(méi)有任何關(guān)系的。
2、三次握手
客戶端：收到ACK， 立即分配資源
服務(wù)器：收到ACK， 立即分配資源
缺陷: 同樣問(wèn)題, 最后一個(gè)ACK，服務(wù)器沒(méi)有收到， 這是 客戶端分配了資源， 但是服務(wù)器沒(méi)有分配資源。 客戶端并不知道，繼續(xù)發(fā)送數(shù)據(jù)。服務(wù)器會(huì)返回 RST 信號(hào)。 因此問(wèn)題影響不大。
3、四次、五次、六次...握手?
既然三次握手也不是100%可靠， 那四次，五次，六次。。。呢? 其實(shí)都一樣，不管多少次都有丟包問(wèn)題。
二、連接狀態(tài)變化
1、正常連接
2、半連接
client 只發(fā)送一個(gè) SYN， server 分配一個(gè)tcb， 放入syn隊(duì)列中。 這時(shí)候連接叫半連接狀態(tài)；如果server 收不到 client 的ACK， 會(huì)不停重試 發(fā)送 ACK-SYN 給client 。重試間隔 為 2 的 N 次方 疊加（2^0 , 2^1, 2^2 ....）；直至超時(shí)才釋放syn隊(duì)列中的這個(gè) TCB;
在半連接狀態(tài)下， 一方面會(huì)占用隊(duì)列配額資源，另一方面占用內(nèi)存資源。我們應(yīng)該讓半連接狀態(tài)存在時(shí)間盡可能的小
3、異常狀況
當(dāng)client 向一個(gè)未打開(kāi)的端口發(fā)起連接請(qǐng)求時(shí)，會(huì)收到一個(gè)RST回復(fù)包
三、backlog 隊(duì)列
1、tcp接收端有兩個(gè)隊(duì)列：一個(gè)是 syn 隊(duì)列 ， 另一個(gè)是 accept 隊(duì)列
- syn 隊(duì)列 : 收到 客戶端syn 的時(shí)候， 在syn隊(duì)列分配一個(gè) TCB，也叫半連接隊(duì)列
-
accept 隊(duì)列 : 當(dāng)收到客戶端 ack 時(shí)候，把 TCB 從syn隊(duì)列移到 accept中來(lái)， 也叫全連接隊(duì)列
tcp_queue.png
2、隊(duì)列大小如何設(shè)置？
- 設(shè)置syn 隊(duì)列大小
/proc/sys/net/ipv4/tcp_max_syn_backlog
- 設(shè)置 accept 隊(duì)列大小
int listen(int sockfd, int backlog);
/proc/sys/net/core/somaxconn
當(dāng)listen 的 backlog 和 somaxconn 都設(shè)置了得時(shí)候， 取兩者min值
3、當(dāng)前連接隊(duì)列大小查看
#ss -a
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
tcp LISTEN 1 0 *:8888 *:*
Recv-Q 是accept 隊(duì)列當(dāng)前個(gè)數(shù)， Send-Q 設(shè)置最大值
4、SYN隊(duì)列滿的情況
- 若設(shè)置 net.ipv4.tcp_syncookies = 0 ，則直接丟棄當(dāng)前 SYN 包；
- 若設(shè)置 net.ipv4.tcp_syncookies = 1 ，發(fā)送ACK+SYN；
5、ACCEPT隊(duì)列滿的情況
- 若設(shè)置 tcp_abort_on_overflow = 1 ，則 TCP 協(xié)議?；貜?fù) RST 包，并直接從 SYN queue 中刪除該連接信息；
- 若設(shè)置 tcp_abort_on_overflow = 0 ，則 TCP 協(xié)議棧將該連接標(biāo)記為 acked ，但仍保留在 SYN queue 中，并啟動(dòng) timer 以便重發(fā) SYN-ACK 包；當(dāng) SYN-ACK 的重傳次數(shù)超過(guò) net.ipv4.tcp_synack_retries 設(shè)置的值時(shí)，再將該連接從 SYN queue 中刪除；
6、SYN flooding
這種SYN洪水攻擊是一種常見(jiàn)攻擊方式，就是利用半連接隊(duì)列特性，占滿syn 隊(duì)列的 資源，導(dǎo)致 client無(wú)法連接上。
解決方案:
- 縮短SYN隊(duì)列超時(shí)時(shí)間 : 設(shè)置系統(tǒng)配置 net.ipv4.tcp_synack_retries， 減少 重發(fā) syn-ack 次數(shù)
- Syn Cache技術(shù) : 這種技術(shù)是在收到SYN數(shù)據(jù)報(bào)文時(shí)不急于去分配TCB，而是先回應(yīng)一個(gè)SYN ACK報(bào)文，并在一個(gè)專用HASH表（Cache）中保存這種半開(kāi)連接信息，直到收到正確的回應(yīng)ACK報(bào)文再分配TCB到accept隊(duì)列。在linux系統(tǒng)中這種Cache每個(gè)半開(kāi)連接只需使用160字節(jié)，遠(yuǎn)小于TCB所需的736個(gè)字節(jié)。
- Syn Cookie技術(shù)： 相對(duì)于 Syn Cache技術(shù)， 這里不分配任何資源，只是巧妙的用算法計(jì)算一個(gè)Sequence Number 放在 SYN 請(qǐng)求中。 為了能正確匹配識(shí)別 client 回應(yīng)的 ACK 中 Sequence Number。 完全靠算法 來(lái) 完成。 如果開(kāi)啟了 SYN cookies 選項(xiàng)，在半連接隊(duì)列滿時(shí)，SYN cookies 并不丟棄 SYN 請(qǐng)求，而是將源目的 IP、源目的端口號(hào)、接收到的客戶端初始序列號(hào)以及其他一些安全數(shù)值等信息進(jìn)行 hash 運(yùn)算，并加密后得到服務(wù)器端的初始序列號(hào)，稱之為 cookie 。服務(wù)器端在發(fā)送初始序列號(hào)為 cookie 的 SYN+ACK 包后，會(huì)將分配的連接請(qǐng)求塊釋放。如果接收到客戶端的 ACK 包，服務(wù)器端將客戶端的 ACK 序列號(hào)減 1 得到的值，與上述要素 hash 運(yùn)算得到的值比較，如果相等，直接完成三次握手，構(gòu)建新的連接。SYN cookies 機(jī)制的核心就是避免攻擊造成的大量構(gòu)造無(wú)用的連接請(qǐng)求塊，導(dǎo)致內(nèi)存耗盡，而無(wú)法處理正常的連接請(qǐng)求。（echo 1 > /proc/sys/net/ipv4/tcp_syncookies）
7、哪些是內(nèi)核自動(dòng)完成的動(dòng)作，哪些是應(yīng)用層觸發(fā)
- client 調(diào)用 connect 函數(shù) , 三次握手在內(nèi)核協(xié)議棧自動(dòng)完成，connect 函數(shù)立即返回，不管server端是否是調(diào)用了 accept函數(shù)沒(méi)有。
- server調(diào)用 accept函數(shù)， 才從 accept隊(duì)列移除 TCB資源 ，返回socket 句柄句柄 給應(yīng)用程序。
- 如果server端的synt隊(duì)列未滿 ，client端調(diào)用connect 函數(shù)，不管server是否調(diào)用accept與否，都會(huì)立即返回； 如果隊(duì)列滿，client則一直重復(fù)發(fā)送SYN( 間隔 2的冪遞增)到直至超時(shí)返回。
二、TCP關(guān)閉階段
一、TCP 四次 揮手
1、正常關(guān)閉流程
2、三次揮手行不行
為什么不像握手那樣合并成三次揮手? 因?yàn)楹蛣傞_(kāi)始連接情況，連接是大家都從0開(kāi)始， 關(guān)閉時(shí)有歷史包袱的。server(被動(dòng)關(guān)閉方) 收到 client(主動(dòng)關(guān)閉方) 的關(guān)閉請(qǐng)求FIN包。 這時(shí)候可能還有未發(fā)送完的數(shù)據(jù)，不能丟棄。 所以需要分開(kāi)。事實(shí)可能是這樣
當(dāng)然，在沒(méi)有待發(fā)數(shù)據(jù)，并且允許 Delay ACK 情況下， FIN-ACK合并還是非常常見(jiàn)的事情，這是三次揮手是可以的。
3、二次揮手行不行
同上
4、半關(guān)閉(CLOSE_WAIT)
CLOSE_WAIT 是被動(dòng)關(guān)閉方才有的狀態(tài)。
被動(dòng)關(guān)閉方 [收到 FIN 包 發(fā)送 ACK 應(yīng)答] 到 [發(fā)送FIN， 收到ACK ] 期間的狀態(tài)為 CLOSE_WAIT， 這個(gè)狀態(tài)仍然能發(fā)送數(shù)據(jù)。 我們叫做半關(guān)閉, 下面用個(gè)例子來(lái)分析:
這個(gè)是我實(shí)際生產(chǎn)環(huán)境碰到的一個(gè)問(wèn)題，長(zhǎng)連接會(huì)話場(chǎng)景，server端收到client的rpc call 請(qǐng)求1，處理發(fā)現(xiàn)請(qǐng)求包有問(wèn)題，就強(qiáng)制關(guān)閉結(jié)束這次會(huì)話， 但是 因?yàn)閏lient 發(fā)送 第二次請(qǐng)求之前，并沒(méi)有去調(diào)用recv，所以并不知道 這個(gè)連接被server關(guān)閉， 繼續(xù)發(fā)送 請(qǐng)求2 ， 此時(shí)是半連接，能夠成功發(fā)送到對(duì)端機(jī)器，但是recv結(jié)果后，遇到連接已經(jīng)關(guān)閉錯(cuò)誤。
CLOSE_WAIT 和 后面提到的 TIME_WAIT 一樣，都是存在潛在危害，CLOSE_WAIT 狀態(tài)下 文件句柄資源沒(méi)有釋放。要知道系統(tǒng) 句柄資源也是有限的。要盡快釋放close掉。
5、同時(shí)關(guān)閉
如果 client 和 server 恰好同時(shí)發(fā)起關(guān)閉連接。這種情況下，兩邊都是主動(dòng)連接，都會(huì)進(jìn)入 TIME_WAIT狀態(tài)
4、TIME_WAIT 狀態(tài)
TIME_WAIT 狀態(tài) 是主動(dòng)關(guān)閉方才有的狀態(tài)：這種狀態(tài)下有個(gè)讓開(kāi)發(fā)人員都很苦惱的普遍性問(wèn)題，端口耗盡, 我們知道，端口數(shù)據(jù)類型是 unsigned short。 最大值是 65535. 所以 一臺(tái)機(jī) 上 最多分配 65535個(gè)端口（不考慮accept的tcp資源情況下，也可以看成一臺(tái)機(jī)器最多只能分配這么鏈接數(shù)）。
然而，TIME_WAIT* 持續(xù)保持時(shí)間是 2*MSL（ Maximum segment lifetime）。 默認(rèn)是 2分鐘。（ 通過(guò)這個(gè)可以修改 /proc/sys/net/ipv4/tcp_fin_timeout）。想想在并發(fā)高的機(jī)器上 2分鐘 很容易發(fā)起超過(guò) 6w多個(gè)短鏈接請(qǐng)求。 這時(shí)候就出現(xiàn)端口不夠用，connect 錯(cuò)誤“Cannot assign requested address” 。TIME_WAIT的如此設(shè)計(jì)是為了解決2個(gè)問(wèn)題：
以下兩種討論的兩種情況都是 假設(shè) 前后兩次連接都是相同四元組( 源ip，源端口，目的ip，目的端口)，都是屬于 "在不相關(guān)的連接中接受延遲的段"現(xiàn)象
1、被動(dòng)關(guān)閉方在LAST_ACK狀態(tài)(已經(jīng)發(fā)送FIN)，等待主動(dòng)關(guān)閉方的ACK應(yīng)答，但是 ACK丟掉， 主動(dòng)方并不知道，以為成功關(guān)閉。因?yàn)闆](méi)有TIME_WAIT等待時(shí)間，可以立即創(chuàng)建新的連接， 新的連接發(fā)送SYN到前面那個(gè)未關(guān)閉的被動(dòng)方，被動(dòng)方認(rèn)為是收到錯(cuò)誤指令，會(huì)發(fā)送RST。導(dǎo)致創(chuàng)建連接失敗。
2、主動(dòng)關(guān)閉方斷開(kāi)連接，如果沒(méi)有TIME_WAIT等待時(shí)間，可以馬上建立一個(gè)新的連接，但是前一個(gè)已經(jīng)斷開(kāi)連接的，延遲到達(dá)的數(shù)據(jù)包。 被新建的連接接收，如果剛好seq 和 ack字段 都正確, seq在滑動(dòng)窗口范圍內(nèi)(只能說(shuō)機(jī)率非常小，但是還是有可能會(huì)發(fā)生)，會(huì)被當(dāng)成正確數(shù)據(jù)包接收，導(dǎo)致數(shù)據(jù)串包。 如果不在window范圍內(nèi)，則沒(méi)有影響( 發(fā)送一個(gè)確認(rèn)報(bào)文（ack 字段為期望ack的序列號(hào)，seq為當(dāng)前發(fā)送序列號(hào)），狀態(tài)變保持原樣)
4、解決TIME_WAIT 問(wèn)題
TIME_WAIT 問(wèn)題比較比較常見(jiàn)，特別是CGI機(jī)器，并發(fā)量高，大量連接后段服務(wù)的tcp短連接。因此也衍生出了多種手段解決。雖然每種方法解決不是那么完美，但是帶來(lái)的好處一般多于壞處。還是在日常工作中會(huì)使用。
1、改短TIME_WAIT 等待時(shí)間
net/ipv4/tcp_fin_timeout
這個(gè)是第一個(gè)想到的解決辦法，既然等待時(shí)間太長(zhǎng)，就改成時(shí)間短，快速回收端口。但是實(shí)際情況往往不樂(lè)觀，對(duì)于并發(fā)的機(jī)器，你改多短才能保證回收速度呢，有時(shí)候幾秒鐘就幾萬(wàn)個(gè)連接。太短的話，就會(huì)有前面兩種問(wèn)題小概率發(fā)生。
2、禁止Socket lingering
struct linger stLinger;
stLinger.l_onoff = 1;
stLinger.l_linger = 0;
setsockopt(fdC, SOL_SOCKET, SO_LINGER, ( void *)&stLinger, sizeof(stLinger));
這種情況下關(guān)閉連接，會(huì)直接拋棄緩沖區(qū)中待發(fā)送的數(shù)據(jù)，會(huì)發(fā)送一個(gè)RST給對(duì)端，相當(dāng)于直接拋棄TIME_WAIT， 進(jìn)入CLOSE狀態(tài)。同樣因?yàn)槿∠?TIME_WAIT 狀態(tài)，會(huì)有前面兩種問(wèn)題小概率發(fā)生。
3、tcp_tw_reuse
net.ipv4.tcp_tw_reuse選項(xiàng)是 從 TIME_WAIT 狀態(tài)的隊(duì)列中，選取條件：１、remote 的 ip 和端口相同， 2、選取一個(gè)時(shí)間戳小于當(dāng)前時(shí)間戳； 用來(lái)解決端口不足的尷尬。
net/ipv4/tcp_ipv4.c
int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp)
{
/* ……省略…… */
if (tcptw->tw_ts_recent_stamp &&
(!twp || (sock_net(sk)->ipv4.sysctl_tcp_tw_reuse &&
get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {
/* ……省略…… */
return 1;
}
return 0;
}
net/ipv4/inet_hashtables.c
static int __inet_check_established(struct inet_timewait_death_row *death_row,
struct sock *sk, __u16 lport,
struct inet_timewait_sock **twp)
{
/* ……省略…… */
sk_nulls_for_each(sk2, node, &head->chain) {
if (sk2->sk_hash != hash)
continue;
if (likely(INET_MATCH(sk2, net, acookie,
saddr, daddr, ports, dif))) {
if (sk2->sk_state == TCP_TIME_WAIT) {
tw = inet_twsk(sk2);
if (twsk_unique(sk, sk2, twp))
break;
}
goto not_unique;
}
}
/* ……省略…… */
}
現(xiàn)在端口可以復(fù)用了，看看如何面對(duì)前面TIME_WAIT 那兩種問(wèn)題。 我們仔細(xì)回顧用一下前面兩種問(wèn)題。都是在新建連接中收到老連接的包導(dǎo)致的問(wèn)題， 那么如果我能在新連接中識(shí)別出此包為非法包，是不是就可以丟掉這些無(wú)用包，解決問(wèn)題呢。
需要實(shí)現(xiàn)這些功能，需要擴(kuò)展一下tcp 包頭。 增加 時(shí)間戳字段。 發(fā)送者 在每次發(fā)送的時(shí)候。 在tcp包頭里面帶上發(fā)送時(shí)候的時(shí)間戳。 當(dāng)接收者接收的時(shí)候，在ACK應(yīng)答中除了TCP包頭中帶自己此時(shí)發(fā)送的時(shí)間戳，并且把收到的時(shí)間戳附加在后面。也就是說(shuō)ACK包中有兩個(gè)時(shí)間戳字段。結(jié)構(gòu)如下:
那我們接下來(lái)一個(gè)個(gè)分析tcp_tw_reuse是如何解決TIME_WAIT的兩個(gè)問(wèn)題的
tcp_tw_reuse 使用有三個(gè)條件：
1、必須開(kāi)啟 timestamp，通過(guò) net.ipv4.tcp_timestamp 參數(shù)設(shè)置, linux 2.6 后缺省是打開(kāi)的；
2、必須客戶端和server同時(shí)支持 timestamp. 在連接握手階段協(xié)商：當(dāng)一方不開(kāi)啟時(shí)，兩方都將停用timestamps。比如client端發(fā)送的SYN包中帶有timestamp選項(xiàng)，但server端并沒(méi)有開(kāi)啟該選項(xiàng)。則回復(fù)的SYN-ACK將不帶timestamp選項(xiàng)，同時(shí)client后續(xù)回復(fù)的ACK也不會(huì)帶有timestamp選項(xiàng)。當(dāng)然，如果client發(fā)送的SYN包中就不帶timestamp，雙向都將停用timestamp。
3、 tcp_tw_reuse 只對(duì)outgoing connections 有效。也就是發(fā)起連接方 client 有效。 server端產(chǎn)生新的連接是不會(huì)復(fù)用 TIME_WAIT 資源
- LAST_ACK收到 SYN問(wèn)題: LAST_ACK 狀態(tài) socket 苦苦等待 主動(dòng)關(guān)閉方的ACK應(yīng)答，但是卻收到了SYN。注意：敲黑板，劃重點(diǎn)了。此時(shí)檢查有timestamp字段的話，不會(huì)立即發(fā)送RST包，而是比較timestamp字段時(shí)間戳非常新，明顯不是自己這個(gè)連接建立時(shí)候SYN延遲包。這時(shí)候恢復(fù) FIN + ACK， 對(duì)方收到 回復(fù)一個(gè)RST結(jié)束上個(gè)連接。 繼續(xù)發(fā)SYN建立新的連接 。這樣就解決料老的連接無(wú)法關(guān)閉，新的連接無(wú)法建立的問(wèn)題。
- 收到上一個(gè)連接數(shù)據(jù)串包問(wèn)題，也是檢查這個(gè)數(shù)據(jù)包的TCP頭里面的timestamp，比較發(fā)現(xiàn)遠(yuǎn)遠(yuǎn)小于上一次TCP包的timestamp ，于是丟棄這個(gè)包即可。
4、tcp_tw_recycle
tcp_tw_recycle自 Linux內(nèi)核4.12版以來(lái)，已被棄用， 大家可以放心的不用了
tcp_tw_recycle 也是借助 timestamp機(jī)制。顧名思義， tcp_tw_reuse 是復(fù)用 端口，并不會(huì)減少 TIME-WAIT 數(shù)量。你去查詢機(jī)器上TIME-WAIT 數(shù)量，還是 幾千幾萬(wàn)個(gè)，這點(diǎn)對(duì)有強(qiáng)迫癥的同學(xué)感覺(jué)很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT資源。會(huì)減少 機(jī)器上 TIME-WAIT 數(shù)量。
tcp_tw_recycle 工作原理是。
動(dòng)態(tài)縮小TIME-WAIT 時(shí)間, 不再是 2*MSL時(shí)間回收來(lái)回收TIME-WAIT資源，而是根據(jù) RTO（Retransmission TimeOut）即重傳超時(shí)時(shí)間， 這個(gè)時(shí)間根據(jù)一套特定算法來(lái)動(dòng)態(tài)計(jì)算，當(dāng)TIME-WAIT 停留時(shí)間大于 RTO。系統(tǒng)釋放資源。 這招可以減少TIME-WAIT 數(shù)量
為了解決TIME-WAIT 收到不相關(guān)連接數(shù)據(jù)包的問(wèn)題， 內(nèi)核會(huì)紀(jì)錄 TIME-WAIT 狀態(tài)下 最后一次 收到包的時(shí)間戳，和ip地址等信息。(注意是IP地址沒(méi)有端口信息哦)。如果收到連接SYN包（注意只在連接時(shí)候檢測(cè)哦），先檢查remote IP 有沒(méi)有 相關(guān)的 TIME-WAIT狀態(tài)，如果有則比較時(shí)間戳，如果時(shí)間戳比最后一次收到時(shí)間戳還要小，則這個(gè)包被認(rèn)為是延遲包，丟棄掉。
存在問(wèn)題： 一般情況下我們不建議使用tcp_tw_recycle ， 因?yàn)樗? 存在 NAT 網(wǎng)關(guān)的時(shí)候。 會(huì)出問(wèn)題。NAT是地址共享， 而 tcp_tw_recycle 機(jī)制下恰恰又是根據(jù)ip紀(jì)錄時(shí)間戳信息的。在 NAT下，多臺(tái)機(jī)器上client。 對(duì)于server 可能是同一個(gè)IP。由于客戶端的時(shí)間戳可能不一致。會(huì)導(dǎo)致連接不上問(wèn)題。
NAT網(wǎng)絡(luò)在國(guó)內(nèi)使用非常普遍，家庭網(wǎng)絡(luò)基本上NAT網(wǎng)絡(luò)， N個(gè)設(shè)備共享一個(gè)IP地址。 公司辦公網(wǎng)基本上也是如此。
