故障現(xiàn)象

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

故障排查

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

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

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

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

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

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

故障解決

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

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

最后，在客戶端測試，故障問題解決。

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

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

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