故障現(xiàn)象

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

故障排查

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

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

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

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

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

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

故障解決

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

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

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

經驗總結

通過這次故障問題，有了新的心得體會。有時候，網絡故障問題其實隱藏得比較深，很難發(fā)現(xiàn)。比如，這次故障問題，如果只是使用簡單的Ping命令來排查故障，是很難發(fā)現(xiàn)的。只有深入到網絡傳輸底層，對傳輸數據進行抓包分析，才能及早發(fā)現(xiàn)故障癥結。

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