會話超時導致的故障

故障現象

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

故障排查

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

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

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

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

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

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

故障解決

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

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

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

經驗總結

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

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