Linux服務(wù)器丟包故障的解決思路及引申的TCP/IP協(xié)議棧理論
我們使用Linux作為服務(wù)器操作系統(tǒng)時(shí)，為了達(dá)到高并發(fā)處理能力，充分利用機(jī)器性能，經(jīng)常會(huì)進(jìn)行一些內(nèi)核參數(shù)的調(diào)整優(yōu)化，但不合理的調(diào)整常常也會(huì)引起意想不到的其他問(wèn)題，本文就一次Linux服務(wù)器丟包故障的處理過(guò)程，結(jié)合Linux內(nèi)核參數(shù)說(shuō)明和TCP/IP協(xié)議棧相關(guān)的理論，介紹一些常見(jiàn)的丟包故障定位方法和解決思路。
問(wèn)題現(xiàn)象
本次故障的反饋現(xiàn)象是：從辦公網(wǎng)訪問(wèn)公網(wǎng)服務(wù)器不穩(wěn)定，服務(wù)器某些端口訪問(wèn)經(jīng)常超時(shí)，但Ping測(cè)試顯示客戶端與服務(wù)器的鏈路始終是穩(wěn)定低延遲的。
通過(guò)在服務(wù)器端抓包，發(fā)現(xiàn)還有幾個(gè)特點(diǎn)：
- 從辦公網(wǎng)訪問(wèn)服務(wù)器有多個(gè)客戶端，是同一個(gè)出口IP，有少部分是始終能夠穩(wěn)定連接的，另一部分間歇訪問(wèn)超時(shí)或延遲很高
- 同一時(shí)刻的訪問(wèn)，無(wú)論哪個(gè)客戶端的數(shù)據(jù)包先到達(dá)，服務(wù)端會(huì)及時(shí)處理部分客戶端的SYN請(qǐng)求，對(duì)另一部分客戶端的SYN包“視而不見(jiàn)”，如tcpdump數(shù)據(jù)所示，源端口為56909的SYN請(qǐng)求沒(méi)有得到響應(yīng)，同一時(shí)間源端口為50212的另一客戶端SYN請(qǐng)求馬上得到響應(yīng)。
Shell
| 1 2 3 4 5 6 7 8 9 10 11 |
$ sudo tcpdump -i eth0 port 22 and "tcp[tcpflags] & (tcp-syn) != 0" 18:56:37.404603 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321481 ecr 0,nop,wscale 7], length 0 18:56:38.404582 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198321731 ecr 0,nop,wscale 7], length 0 18:56:40.407289 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198322232 ecr 0,nop,wscale 7], length 0 18:56:44.416108 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198323234 ecr 0,nop,wscale 7], length 0 18:56:45.100033 IP CLIENT.50212 > SERVER.22: Flags [S], seq 4207350463, win 65535, options [mss 1366,nop,wscale 5,nop,nop,TS val 821068631 ecr 0,sackOK,eol], length 0 18:56:45.100110 IP SERVER.22 > CLIENT.50212: Flags [S.], seq 1281140899, ack 4207350464, win 27960, options [mss 1410,sackOK,TS val 1709997543 ecr 821068631,nop,wscale 7], length 0 18:56:52.439086 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198325240 ecr 0,nop,wscale 7], length 0 18:57:08.472825 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198329248 ecr 0,nop,wscale 7], length 0 18:57:40.535621 IP CLIENT.56909 > SERVER.22: Flags [S], seq 1190606850, win 29200, options [mss 1448,sackOK,TS val 198337264 ecr 0,nop,wscale 7], length 0 18:57:40.535698 IP SERVER.22 > CLIENT.56909: Flags [S.], seq 3621462255, ack 1190606851, win 27960, options [mss 1410,sackOK,TS val 1710011402ecr 198337264,nop,wscale 7], length 0 |
排查過(guò)程
服務(wù)器能正常接收到數(shù)據(jù)包，問(wèn)題可以限定在兩種可能：部分客戶端發(fā)出的數(shù)據(jù)包本身異常；服務(wù)器處理部分客戶端的數(shù)據(jù)包時(shí)觸發(fā)了某種機(jī)制丟棄了數(shù)據(jù)包。因?yàn)槌鰡?wèn)題的客戶端能夠正常訪問(wèn)公網(wǎng)上其他服務(wù)，后者的可能性更大。
有哪些情況會(huì)導(dǎo)致Linux服務(wù)器丟棄數(shù)據(jù)包？
防火墻攔截
服務(wù)器端口無(wú)法連接，通常就是查看防火墻配置了，雖然這里已經(jīng)確認(rèn)同一個(gè)出口IP的客戶端有的能夠正常訪問(wèn)，但也不排除配置了DROP特定端口范圍的可能性。
如何確認(rèn)
查看iptables filter表，確認(rèn)是否有相應(yīng)規(guī)則會(huì)導(dǎo)致此丟包行為：
Shell
| 1 |
$ sudo iptables-save -t filter |
這里容易排除防火墻攔截的可能性。
連接跟蹤表溢出
除了防火墻本身配置DROP規(guī)則外，與防火墻有關(guān)的還有連接跟蹤表nf_conntrack，Linux為每個(gè)經(jīng)過(guò)內(nèi)核網(wǎng)絡(luò)棧的數(shù)據(jù)包，生成一個(gè)新的連接記錄項(xiàng)，當(dāng)服務(wù)器處理的連接過(guò)多時(shí)，連接跟蹤表被打滿，服務(wù)器會(huì)丟棄新建連接的數(shù)據(jù)包。
如何確認(rèn)
通過(guò)dmesg可以確認(rèn)是否有該情況發(fā)生：
Shell
| 1 |
$ dmesg |grep nf_conntrack |
如果輸出值中有“nf_conntrack: table full, dropping packet”，說(shuō)明服務(wù)器nf_conntrack表已經(jīng)被打滿。
通過(guò)/proc文件系統(tǒng)查看nf_conntrack表實(shí)時(shí)狀態(tài)：
Shell
| 1 2 3 4 5 6 |
# 查看nf_conntrack表最大連接數(shù) $ cat /proc/sys/net/netfilter/nf_conntrack_max 65536 # 查看nf_conntrack表當(dāng)前連接數(shù) $ cat /proc/sys/net/netfilter/nf_conntrack_count 7611 |
當(dāng)前連接數(shù)遠(yuǎn)沒(méi)有達(dá)到跟蹤表最大值，排除這個(gè)因素。
如何解決
如果確認(rèn)服務(wù)器因連接跟蹤表溢出而開(kāi)始丟包，首先需要查看具體連接判斷是否正遭受DOS攻擊，如果是正常的業(yè)務(wù)流量造成，可以考慮調(diào)整nf_conntrack的參數(shù)：
nf_conntrack_max決定連接跟蹤表的大小，默認(rèn)值是65535，可以根據(jù)系統(tǒng)內(nèi)存大小計(jì)算一個(gè)合理值：CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32)，如32G內(nèi)存可以設(shè)置1048576；
nf_conntrack_buckets決定存儲(chǔ)conntrack條目的哈希表大小，默認(rèn)值是nf_conntrack_max的1/4，延續(xù)這種計(jì)算方式：BUCKETS = CONNTRACK_MAX/4，如32G內(nèi)存可以設(shè)置262144；
nf_conntrack_tcp_timeout_established決定ESTABLISHED狀態(tài)連接的超時(shí)時(shí)間，默認(rèn)值是5天，可以縮短到1小時(shí)，即3600。
Shell
| 1 2 3 |
$ sysctl -w net.netfilter.nf_conntrack_max=1048576 $ sysctl -w net.netfilter.nf_conntrack_buckets=262144 $ sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=3600 |
Ring Buffer溢出
排除了防火墻的因素，我們從底向上來(lái)看Linux接收數(shù)據(jù)包的處理過(guò)程，首先是網(wǎng)卡驅(qū)動(dòng)層。
如下圖所示，物理介質(zhì)上的數(shù)據(jù)幀到達(dá)后首先由NIC（網(wǎng)絡(luò)適配器）讀取，寫(xiě)入設(shè)備內(nèi)部緩沖區(qū)Ring Buffer中，再由中斷處理程序觸發(fā)Softirq從中消費(fèi)，Ring Buffer的大小因網(wǎng)卡設(shè)備而異。當(dāng)網(wǎng)絡(luò)數(shù)據(jù)包到達(dá)（生產(chǎn)）的速率快于內(nèi)核處理（消費(fèi)）的速率時(shí)，Ring Buffer很快會(huì)被填滿，新來(lái)的數(shù)據(jù)包將被丟棄。
如何確認(rèn)
通過(guò)ethtool或/proc/net/dev可以查看因Ring Buffer滿而丟棄的包統(tǒng)計(jì)，在統(tǒng)計(jì)項(xiàng)中以fifo標(biāo)識(shí)：
Shell
| 1 2 3 4 5 6 7 |
$ ethtool -S eth0|grep rx_fifo rx_fifo_errors: 0 $ cat /proc/net/dev Inter-|?? Receive????????????????????????????????????????????????|??Transmit face |bytes????packets errs drop fifo frame compressed multicast|bytes????packets errs drop fifo colls carrier compressed ??eth0: 17253386680731 42839525880????0????0????0???? 0??????????0 244182022 14879545018057 41657801805????0????0????0???? 0?????? 0???????? 0 |
可以看到服務(wù)器的接收方向的fifo丟包數(shù)并沒(méi)有增加，這里自然也排除這個(gè)原因。
如何解決
如果發(fā)現(xiàn)服務(wù)器上某個(gè)網(wǎng)卡的fifo數(shù)持續(xù)增大，可以去確認(rèn)CPU中斷是否分配均勻，也可以嘗試增加Ring Buffer的大小，通過(guò)ethtool可以查看網(wǎng)卡設(shè)備Ring Buffer最大值，修改Ring Buffer當(dāng)前設(shè)置：
Shell
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# 查看eth0網(wǎng)卡Ring Buffer最大值和當(dāng)前設(shè)置 $ ethtool -g eth0 Ring parameters for eth0: Pre-set maximums: RX:???? 4096?? RX Mini:????0 RX Jumbo:?? 0 TX:???? 4096?? Current hardware settings: RX:???? 1024?? RX Mini:????0 RX Jumbo:?? 0 TX:???? 1024?? # 修改網(wǎng)卡eth0接收與發(fā)送硬件緩存區(qū)大小 $ ethtool -G eth0 rx 4096 tx 4096 Pre-set maximums: RX:???? 4096?? RX Mini:????0 RX Jumbo:?? 0 TX:???? 4096?? Current hardware settings: RX:???? 4096?? RX Mini:????0 RX Jumbo:?? 0 TX:???? 4096 |
netdev_max_backlog溢出
netdev_max_backlog是內(nèi)核從NIC收到包后，交由協(xié)議棧（如IP、TCP）處理之前的緩沖隊(duì)列。每個(gè)CPU核都有一個(gè)backlog隊(duì)列，與Ring Buffer同理，當(dāng)接收包的速率大于內(nèi)核協(xié)議棧處理的速率時(shí)，CPU的backlog隊(duì)列不斷增長(zhǎng)，當(dāng)達(dá)到設(shè)定的netdev_max_backlog值時(shí)，數(shù)據(jù)包將被丟棄。
如何確認(rèn)
通過(guò)查看/proc/net/softnet_stat可以確定是否發(fā)生了netdev backlog隊(duì)列溢出：
Shell
| 1 2 3 4 5 |
$ cat /proc/net/softnet_stat 01a7b464 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01d4d71f 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0349e798 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 017e0826 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 |
其中：
每一行代表每個(gè)CPU核的狀態(tài)統(tǒng)計(jì)，從CPU0依次往下；
每一列代表一個(gè)CPU核的各項(xiàng)統(tǒng)計(jì)：第一列代表中斷處理程序收到的包總數(shù)；第二列即代表由于netdev_max_backlog隊(duì)列溢出而被丟棄的包總數(shù)。
從上面的輸出可以看出，這臺(tái)服務(wù)器統(tǒng)計(jì)中，并沒(méi)有因?yàn)閚etdev_max_backlog導(dǎo)致的丟包。
如何解決
netdev_max_backlog的默認(rèn)值是1000，在高速鏈路上，可能會(huì)出現(xiàn)上述第二列統(tǒng)計(jì)不為0的情況，可以通過(guò)修改內(nèi)核參數(shù)net.core.netdev_max_backlog來(lái)解決：
Shell
| 1 |
$ sysctl -w net.core.netdev_max_backlog=2000 |
反向路由過(guò)濾
反向路由過(guò)濾機(jī)制是Linux通過(guò)反向路由查詢，檢查收到的數(shù)據(jù)包源IP是否可路由（Loose mode）、是否最佳路由（Strict mode），如果沒(méi)有通過(guò)驗(yàn)證，則丟棄數(shù)據(jù)包，設(shè)計(jì)的目的是防范IP地址欺騙攻擊。rp_filter提供了三種模式供配置：
- 0 - 不驗(yàn)證
- 1 - RFC3704定義的嚴(yán)格模式：對(duì)每個(gè)收到的數(shù)據(jù)包，查詢反向路由，如果數(shù)據(jù)包入口和反向路由出口不一致，則不通過(guò)
- 2 - RFC3704定義的松散模式：對(duì)每個(gè)收到的數(shù)據(jù)包，查詢反向路由，如果任何接口都不可達(dá)，則不通過(guò)
如何確認(rèn)
查看當(dāng)前rp_filter策略配置：
Shell
| 1 2 |
$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter 0 |
如果這里設(shè)置為1，就需要查看主機(jī)的網(wǎng)絡(luò)環(huán)境和路由策略是否可能會(huì)導(dǎo)致客戶端的入包無(wú)法通過(guò)反向路由驗(yàn)證了。
從原理來(lái)看這個(gè)機(jī)制工作在網(wǎng)絡(luò)層，因此，如果客戶端能夠Ping通服務(wù)器，就能夠排除這個(gè)因素了。
如何解決
根據(jù)實(shí)際網(wǎng)絡(luò)環(huán)境將rp_filter設(shè)置為0或2：
Shell
| 1 2 3 4 5 |
$ sysctl -w net.ipv4.conf.all.rp_filter=2 或 $ sysctl -w net.ipv4.conf.eth0.rp_filter=2 |
半連接隊(duì)列溢出
半連接隊(duì)列指的是TCP傳輸中服務(wù)器收到SYN包但還未完成三次握手的連接隊(duì)列，隊(duì)列大小由內(nèi)核參數(shù)tcp_max_syn_backlog定義。
當(dāng)服務(wù)器保持的半連接數(shù)量達(dá)到tcp_max_syn_backlog后，內(nèi)核將會(huì)丟棄新來(lái)的SYN包。
如何確認(rèn)
通過(guò)dmesg可以確認(rèn)是否有該情況發(fā)生：
Shell
| 1 |
$ dmesg | grep "TCP: drop open request from" |
半連接隊(duì)列的連接數(shù)量可以通過(guò)netstat統(tǒng)計(jì)SYN_RECV狀態(tài)的連接得知
Shell
| 1 2 |
$ netstat -ant|grep SYN_RECV|wc -l 0 |
大多數(shù)情況下這個(gè)值應(yīng)該是0或很小，因?yàn)榘脒B接狀態(tài)從第一次握手完成時(shí)進(jìn)入，第三次握手完成后退出，正常的網(wǎng)絡(luò)環(huán)境中這個(gè)過(guò)程發(fā)生很快，如果這個(gè)值較大，服務(wù)器極有可能受到了SYN Flood攻擊。
如何解決
tcp_max_syn_backlog的默認(rèn)值是256，通常推薦內(nèi)存大于128MB的服務(wù)器可以將該值調(diào)高至1024，內(nèi)存小于32MB的服務(wù)器調(diào)低到128，同樣，該參數(shù)通過(guò)sysctl修改：
Shell
| 1 |
$ sysctl -w net.ipv4.tcp_max_syn_backlog=1024 |
另外，上述行為受到內(nèi)核參數(shù)tcp_syncookies的影響，若啟用syncookie機(jī)制，當(dāng)半連接隊(duì)列溢出時(shí)，并不會(huì)直接丟棄SYN包，而是回復(fù)帶有syncookie的SYC+ACK包，設(shè)計(jì)的目的是防范SYN Flood造成正常請(qǐng)求服務(wù)不可用。
Shell
| 1 2 |
$ sysctl -w net.ipv4.tcp_syncookies=1 net.ipv4.tcp_syncookies = 1 |
PAWS
PAWS全名Protect Againest Wrapped Sequence numbers，目的是解決在高帶寬下，TCP序列號(hào)在一次會(huì)話中可能被重復(fù)使用而帶來(lái)的問(wèn)題。
如上圖所示，客戶端發(fā)送的序列號(hào)為A的數(shù)據(jù)包A1因某些原因在網(wǎng)絡(luò)中“迷路”，在一定時(shí)間沒(méi)有到達(dá)服務(wù)端，客戶端超時(shí)重傳序列號(hào)為A的數(shù)據(jù)包A2，接下來(lái)假設(shè)帶寬足夠，傳輸用盡序列號(hào)空間，重新使用A，此時(shí)服務(wù)端等待的是序列號(hào)為A的數(shù)據(jù)包A3，而恰巧此時(shí)前面“迷路”的A1到達(dá)服務(wù)端，如果服務(wù)端僅靠序列號(hào)A就判斷數(shù)據(jù)包合法，就會(huì)將錯(cuò)誤的數(shù)據(jù)傳遞到用戶態(tài)程序，造成程序異常。
PAWS要解決的就是上述問(wèn)題，它依賴于timestamp機(jī)制，理論依據(jù)是：在一條正常的TCP流中，按序接收到的所有TCP數(shù)據(jù)包中的timestamp都應(yīng)該是單調(diào)非遞減的，這樣就能判斷那些timestamp小于當(dāng)前TCP流已處理的最大timestamp值的報(bào)文是延遲到達(dá)的重復(fù)報(bào)文，可以予以丟棄。在上文的例子中，服務(wù)器已經(jīng)處理數(shù)據(jù)包Z，而后到來(lái)的A1包的timestamp必然小于Z包的timestamp，因此服務(wù)端會(huì)丟棄遲到的A1包，等待正確的報(bào)文到來(lái)。
PAWS機(jī)制的實(shí)現(xiàn)關(guān)鍵是內(nèi)核保存了Per-Connection的最近接收時(shí)間戳，如果加以改進(jìn)，就可以用來(lái)優(yōu)化服務(wù)器TIME_WAIT狀態(tài)的快速回收。
TIME_WAIT狀態(tài)是TCP四次揮手中主動(dòng)關(guān)閉連接的一方需要進(jìn)入的最后一個(gè)狀態(tài)，并且通常需要在該狀態(tài)保持2*MSL（報(bào)文最大生存時(shí)間），它存在的意義有兩個(gè)：
1.可靠地實(shí)現(xiàn)TCP全雙工連接的關(guān)閉：關(guān)閉連接的四次揮手過(guò)程中，最終的ACK由主動(dòng)關(guān)閉連接的一方（稱為A）發(fā)出，如果這個(gè)ACK丟失，對(duì)端（稱為B）將重發(fā)FIN，如果A不維持連接的TIME_WAIT狀態(tài)，而是直接進(jìn)入CLOSED，則無(wú)法重傳ACK，B端的連接因此不能及時(shí)可靠釋放。
2.等待“迷路”的重復(fù)數(shù)據(jù)包在網(wǎng)絡(luò)中因生存時(shí)間到期消失：通信雙方A與B，A的數(shù)據(jù)包因“迷路”沒(méi)有及時(shí)到達(dá)B，A會(huì)重發(fā)數(shù)據(jù)包，當(dāng)A與B完成傳輸并斷開(kāi)連接后，如果A不維持TIME_WAIT狀態(tài)2*MSL時(shí)間，便有可能與B再次建立相同源端口和目的端口的“新連接”，而前一次連接中“迷路”的報(bào)文有可能在這時(shí)到達(dá)，并被B接收處理，造成異常，維持2*MSL的目的就是等待前一次連接的數(shù)據(jù)包在網(wǎng)絡(luò)中消失。
TIME_WAIT狀態(tài)的連接需要占用服務(wù)器內(nèi)存資源維持，Linux內(nèi)核提供了一個(gè)參數(shù)來(lái)控制TIME_WAIT狀態(tài)的快速回收：tcp_tw_recycle，它的理論依據(jù)是：
在PAWS的理論基礎(chǔ)上，如果內(nèi)核保存Per-Host的最近接收時(shí)間戳，接收數(shù)據(jù)包時(shí)進(jìn)行時(shí)間戳比對(duì)，就能避免TIME_WAIT意圖解決的第二個(gè)問(wèn)題：前一個(gè)連接的數(shù)據(jù)包在新連接中被當(dāng)做有效數(shù)據(jù)包處理的情況。這樣就沒(méi)有必要維持TIME_WAIT狀態(tài)2*MSL的時(shí)間來(lái)等待數(shù)據(jù)包消失，僅需要等待足夠的RTO（超時(shí)重傳），解決ACK丟失需要重傳的情況，來(lái)達(dá)到快速回收TIME_WAIT狀態(tài)連接的目的。
但上述理論在多個(gè)客戶端使用NAT訪問(wèn)服務(wù)器時(shí)會(huì)產(chǎn)生新的問(wèn)題：同一個(gè)NAT背后的多個(gè)客戶端時(shí)間戳是很難保持一致的（timestamp機(jī)制使用的是系統(tǒng)啟動(dòng)相對(duì)時(shí)間），對(duì)于服務(wù)器來(lái)說(shuō)，兩臺(tái)客戶端主機(jī)各自建立的TCP連接表現(xiàn)為同一個(gè)對(duì)端IP的兩個(gè)連接，按照Per-Host記錄的最近接收時(shí)間戳?xí)聻閮膳_(tái)客戶端主機(jī)中時(shí)間戳較大的那個(gè)，而時(shí)間戳相對(duì)較小的客戶端發(fā)出的所有數(shù)據(jù)包對(duì)服務(wù)器來(lái)說(shuō)都是這臺(tái)主機(jī)已過(guò)期的重復(fù)數(shù)據(jù)，因此會(huì)直接丟棄。
如何確認(rèn)
通過(guò)netstat可以得到因PAWS機(jī)制timestamp驗(yàn)證被丟棄的數(shù)據(jù)包統(tǒng)計(jì)：
Shell
| 1 2 3 |
$ netstat -s |grep -e "passive connections rejected because of time stamp" -e "packets rejects in established connections because of timestamp” 387158 passive connections rejected because of time stamp 825313 packets rejects in established connections because of timestamp |
通過(guò)sysctl查看是否啟用了tcp_tw_recycle及tcp_timestamp:
Shell
| 1 2 3 4 |
$ sysctl net.ipv4.tcp_tw_recycle net.ipv4.tcp_tw_recycle = 1 $ sysctl net.ipv4.tcp_timestamps net.ipv4.tcp_timestamps = 1 |
這次問(wèn)題正是因?yàn)榉?wù)器同時(shí)開(kāi)啟了tcp_tw_recycle和timestamps，而客戶端正是使用NAT來(lái)訪問(wèn)服務(wù)器，造成啟動(dòng)時(shí)間相對(duì)較短的客戶端得不到服務(wù)器的正常響應(yīng)。
如何解決
如果服務(wù)器作為服務(wù)端提供服務(wù)，且明確客戶端會(huì)通過(guò)NAT網(wǎng)絡(luò)訪問(wèn)，或服務(wù)器之前有7層轉(zhuǎn)發(fā)設(shè)備會(huì)替換客戶端源IP時(shí)，是不應(yīng)該開(kāi)啟tcp_tw_recycle的，而timestamps除了支持tcp_tw_recycle外還被其他機(jī)制依賴，推薦繼續(xù)開(kāi)啟：
Shell
| 1 2 |
$ sysctl -w net.ipv4.tcp_tw_recycle=0 $ sysctl -w net.ipv4.tcp_timestamps=1 |
結(jié)論
Linux提供了豐富的內(nèi)核參數(shù)供使用者調(diào)整，調(diào)整得當(dāng)可以大幅提高服務(wù)器的處理能力，但如果調(diào)整不當(dāng)，就會(huì)引進(jìn)莫名其妙的各種問(wèn)題，比如這次開(kāi)啟tcp_tw_recycle導(dǎo)致丟包，實(shí)際也是為了減少TIME_WAIT連接數(shù)量而進(jìn)行參數(shù)調(diào)優(yōu)的結(jié)果。我們?cè)谧鱿到y(tǒng)優(yōu)化時(shí)，時(shí)刻要保持辯證和空杯的心態(tài)，不盲目吸收他人的果，而多去追求因，只有知其所以然，才能結(jié)合實(shí)際業(yè)務(wù)特點(diǎn)，得出最合理的優(yōu)化配置。文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-508298.html
Linux服務(wù)器丟包故障的解決思路及引申的TCP/IP協(xié)議棧理論 | SDNLAB | 專注網(wǎng)絡(luò)創(chuàng)新技術(shù)
https://www.sdnlab.com/17530.html文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-508298.html
到了這里，關(guān)于Linux服務(wù)器丟包故障的解決思路及引申的TCP/IP協(xié)議棧理論的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
