會(huì)話超時(shí)導(dǎo)致的故障

故障現(xiàn)象

最近，筆者在日常網(wǎng)絡(luò)維護(hù)中，有用戶反映業(yè)務(wù)軟件在執(zhí)行某操作時(shí)，經(jīng)常出現(xiàn)“發(fā)送請(qǐng)求失敗”的提示。按常規(guī)，首先在客戶端使用Ping命令簡(jiǎn)單測(cè)試網(wǎng)絡(luò)狀況，通過(guò)長(zhǎng)時(shí)間Ping測(cè)試，沒(méi)有發(fā)現(xiàn)有丟包情況，而且時(shí)延也基本穩(wěn)定在3ms左右，說(shuō)明網(wǎng)絡(luò)狀況良好。但是，用戶反映故障問(wèn)題一直存在，影響日常工作。

故障排查

根據(jù)用戶反映的故障現(xiàn)象，故障可能來(lái)源于業(yè)務(wù)軟件本身或者網(wǎng)絡(luò)問(wèn)題。由于先前Ping測(cè)試沒(méi)有發(fā)現(xiàn)網(wǎng)絡(luò)異常，應(yīng)該是業(yè)務(wù)軟件本身的問(wèn)題。在業(yè)務(wù)軟件上執(zhí)行其他操作，并沒(méi)有發(fā)現(xiàn)異常問(wèn)題。聯(lián)系業(yè)務(wù)軟件廠家，也證實(shí)軟件方面不存在問(wèn)題。經(jīng)過(guò)仔細(xì)分析，用戶執(zhí)行操作后，業(yè)務(wù)軟件會(huì)發(fā)出數(shù)據(jù)庫(kù)操作請(qǐng)求，主要是大量數(shù)據(jù)插入操作。執(zhí)行完畢后，返回結(jié)果到客戶端。是數(shù)據(jù)庫(kù)執(zhí)行存在問(wèn)題還是數(shù)據(jù)返回時(shí)有問(wèn)題呢？為了找到問(wèn)題所在，我通過(guò)遠(yuǎn)程操作，在服務(wù)器端的軟件上執(zhí)行相同操作，發(fā)現(xiàn)執(zhí)行后，雖然執(zhí)行返回結(jié)果的時(shí)間比其他操作的時(shí)間慢了點(diǎn)，但是數(shù)據(jù)都能正常返回，沒(méi)有出現(xiàn)錯(cuò)誤提示。通過(guò)以上測(cè)試，可以斷定問(wèn)題出在網(wǎng)絡(luò)傳輸上。

在找準(zhǔn)故障來(lái)源后，為了更深入查找網(wǎng)絡(luò)問(wèn)題，使用Wireshark抓包軟件對(duì)網(wǎng)絡(luò)數(shù)據(jù)流仔細(xì)分析。當(dāng)用戶執(zhí)行操作后，首先通過(guò)TCP的三次握手建立連接，然后客戶端發(fā)出數(shù)據(jù)庫(kù)查詢請(qǐng)求，服務(wù)器傳來(lái)一個(gè)響應(yīng)包，接下來(lái)，看到大量的超時(shí)重發(fā)請(qǐng)求?？梢钥闯觯捎趫?zhí)行超時(shí)太長(zhǎng)，客戶端沒(méi)有收到返回?cái)?shù)據(jù)，業(yè)務(wù)軟件提示報(bào)錯(cuò)。遠(yuǎn)程到數(shù)據(jù)庫(kù)服務(wù)器，發(fā)現(xiàn)數(shù)據(jù)庫(kù)操作已經(jīng)執(zhí)行完畢，更加斷定故障問(wèn)題是由于超時(shí)傳輸導(dǎo)致的。

通過(guò)咨詢軟件廠家和網(wǎng)上查詢，發(fā)現(xiàn)可以通過(guò)修改注冊(cè)表來(lái)修改客戶端的會(huì)話等待時(shí)間，具體操作是這樣的。新建一個(gè)記事本文件，在里面編輯：

編輯好后，把文件名改成ReceiveTimeout.reg，并雙擊執(zhí)行。注冊(cè)表修改好后，繼續(xù)操作業(yè)務(wù)軟件，發(fā)現(xiàn)故障依舊存在，用抓包軟件來(lái)看還是存在大量的超時(shí)重傳請(qǐng)求。這讓筆者感到很詫異，難道還有其他問(wèn)題存在？

分析了當(dāng)前的網(wǎng)絡(luò)結(jié)構(gòu)。客戶端首先通過(guò)華為S2326接入，然后上聯(lián)華為SRG1200網(wǎng)關(guān)設(shè)備。問(wèn)題會(huì)不會(huì)出在SRG1200網(wǎng)關(guān)上？有可能當(dāng)用戶端發(fā)出請(qǐng)求后，由于遠(yuǎn)程數(shù)據(jù)庫(kù)執(zhí)行需要較長(zhǎng)一段時(shí)間，數(shù)據(jù)返回時(shí)間較長(zhǎng)，SRG1200會(huì)將數(shù)據(jù)丟棄，客戶端沒(méi)有能收到返回的數(shù)據(jù)，導(dǎo)致故障。為了驗(yàn)證想法，帶上筆記本，模擬客戶端的網(wǎng)絡(luò)配置，直接接入SRG1200設(shè)備。發(fā)現(xiàn)問(wèn)題依然存在，更加證實(shí)了原來(lái)的推想。

由于以前沒(méi)有遇到這方面的故障問(wèn)題，于是咨詢了華為設(shè)備廠商。在描述故障現(xiàn)象和當(dāng)前網(wǎng)絡(luò)結(jié)構(gòu)后，按照華為工程師的分析，這種故障可能由于SRG1200上面針對(duì)不同的網(wǎng)絡(luò)傳輸協(xié)議都有相應(yīng)的會(huì)話存活時(shí)間，當(dāng)用戶數(shù)據(jù)通過(guò)SRG1200時(shí)，會(huì)在該設(shè)備的會(huì)話表上添加用戶的會(huì)話條目，如果會(huì)話存活時(shí)間到期，會(huì)話條目會(huì)被自動(dòng)刪除。結(jié)合當(dāng)前故障，用戶發(fā)出請(qǐng)求后，由于數(shù)據(jù)庫(kù)操作執(zhí)行需要較長(zhǎng)一段時(shí)間，而當(dāng)數(shù)據(jù)庫(kù)執(zhí)行完畢后返回?cái)?shù)據(jù)時(shí)，原來(lái)用戶的會(huì)話條目早已因?yàn)槌瑫r(shí)而被刪除。此時(shí)，從服務(wù)器端返回的結(jié)果數(shù)據(jù)到達(dá)SRG1200時(shí)，因?yàn)闆](méi)有發(fā)現(xiàn)對(duì)應(yīng)的會(huì)話條目而被直接丟棄。這就是問(wèn)題的所在。

故障解決

找到問(wèn)題癥結(jié)后，故障就可以迎刃而解。在SRG1200上，使用dis firewall session aging-time查詢當(dāng)前設(shè)備支持協(xié)議的會(huì)話時(shí)間，我們可以看到該設(shè)備支持57種不同協(xié)議的會(huì)話。Timeout時(shí)間以秒為單位?？梢园l(fā)現(xiàn)各種協(xié)議會(huì)話存活時(shí)間長(zhǎng)短不一，比如ICMP協(xié)議的默認(rèn)會(huì)話存活時(shí)間為20s，Telnet協(xié)議的默認(rèn)會(huì)話存活時(shí)間為600s。

根據(jù)用戶執(zhí)行的操作，我們調(diào)整HTTP協(xié)議和TCP協(xié)議的會(huì)話時(shí)間應(yīng)該就可以，根據(jù)實(shí)際數(shù)據(jù)庫(kù)執(zhí)行所需時(shí)間，我設(shè)置這兩種協(xié)議的會(huì)話存活時(shí)間為1200s（即20分鐘）。具體這樣設(shè)置，在全局配置模式下，使用“firewall session aging-time service-set http 1200”，“firewall session aging-time service-set tcp 1200”。執(zhí)行完后保存配置。

最后，在客戶端測(cè)試，故障問(wèn)題解決。

經(jīng)驗(yàn)總結(jié)

通過(guò)這次故障問(wèn)題，有了新的心得體會(huì)。有時(shí)候，網(wǎng)絡(luò)故障問(wèn)題其實(shí)隱藏得比較深，很難發(fā)現(xiàn)。比如，這次故障問(wèn)題，如果只是使用簡(jiǎn)單的Ping命令來(lái)排查故障，是很難發(fā)現(xiàn)的。只有深入到網(wǎng)絡(luò)傳輸?shù)讓?，?duì)傳輸數(shù)據(jù)進(jìn)行抓包分析，才能及早發(fā)現(xiàn)故障癥結(jié)。

另外，我們?cè)谠O(shè)置會(huì)話存活時(shí)間方面，也不適宜將會(huì)話時(shí)間設(shè)置太長(zhǎng)，因?yàn)闀?huì)話表的總條目是有最大限制數(shù)的，如果某協(xié)議會(huì)話存活時(shí)間太長(zhǎng)，在大量用戶并發(fā)時(shí)，可能影響其他協(xié)議會(huì)話，造成設(shè)備系統(tǒng)資源緊張。