Linux為什么卡住了
來自： http://www.epubit.com.cn/article/425
文：林沛滿
到今天為止，已經有5位讀者向我求助過這個問題了。癥狀請看圖1，他們通過SSH登錄Linux服務器時，輸完用戶名就卡住了，要等待10秒鐘才提示密碼輸入。這究竟是什么原因導致的呢？其實我也是Linux菜鳥，雖然嘗試過搜索“ssh hang”等關鍵詞，但是沒找到相關信息。
圖1
10秒鐘的時間并不算長，吃個薯片喝口咖啡就過去了。但是作為強迫癥患者，我還是容不得它的存在，因此便決定寫篇文章，向大家演示一下怎樣用Wireshark一步步解決這個問題。
首先是抓包，步驟如下。
1．在Linux服務器上啟動抓包。
2．從筆記本SSH到Linux服務器，輸入用戶名并回車。
3．等待10秒左右，直到登錄界面提示輸入密碼。
4．停止抓包。
這樣就可以得到一個涵蓋該現象的網絡包了。一般在實驗室中沒有干擾流量，不用過濾也可以分析，不過我們最好在做實驗時就養成過濾的習慣，以適應生產環境中抓到的包。因為我們是通過SSH協議登錄的，所以可以直接用“ssh”來過濾，如圖2所示。SSH包都是加密了的，因此我們看不出每個包代表了什么意思，不過這并不影響分析。從圖2中可以看到，21號包和25號包之間恰好就相隔10秒。
圖2
這兩個包之間所發生的事件，可能就是導致這個現象的原因。于是我再用“frame.number> 21 && frame.number< 25”過濾，結果如圖3所示。
圖3
從圖3中可以看到，Linux服務器當時正忙著向DNS服務器查詢10.32.200.23的PTR記錄（即反向解析），試圖獲得這個IP地址所對應的域名。該IP屬于我們測試所用的筆記本，但由于DNS服務器上沒有它的PTR記錄，所以兩次查詢都等了5秒鐘還沒結果，總共浪費了10秒鐘。
我們由此可以推出， 這臺Linux服務器在收到SSH訪問請求時，會先查詢該客戶端IP所對應的PTR記錄。假如經過5秒鐘還沒有收到回復，就再發一次查詢。如果第二次查詢還是等了5秒還沒回復，就徹底放棄查詢。 我們甚至可以進一步猜測，如果DNS查詢能成功，就不用白等那10秒鐘了。
為了驗證這個猜測，我在DNS服務器中添加了10.32.200.23的PTR記錄，如圖4所示，然后再次登錄。
圖4
這一次果然立即登錄進去了。從圖5的Wireshark截屏可見，DNS查詢是成功的，所以21號包和26號包之間幾乎是沒有時間停頓的。
圖5
明白了DNS查詢就是問題的起因，接下來就知道怎么進一步研究了。只要在Google搜索“ssh dns”，第一頁出來的鏈接都是關于這個問題的。隨便挑幾篇閱讀一下，就連我這樣的Linux初學者都能把這個問題研究透了。原來這個行為是定義在“/etc/ssh/sshd_config”文件中的，默認配置是這樣的：
[root@Linux_Server ~]# cat /etc/ssh/sshd_config |grep -i usednsUseDNS yes</pre>
改成下面這樣就可以解決了，不用去動DNS服務器上的配置：
[root@Linux_Server~]# cat /etc/ssh/sshd_config |grep -i usedns UseDNS no我經常說 技能比知識更重要 ，這就是例子之一。學會了使用Wireshark，其他知識也會跟著來的。
本文摘自《Wireshark網絡分析的藝術》，作者林沛滿。
《Wireshark網絡分析的藝術》挑選的網絡包來自真實場景，經典且接地氣。講解時采用了生活化的語言，力求通俗易懂，以使讀者在輕松閱讀的過程中，既可以學到實用的網絡知識，又能形成解決問題的思路。
與大多網絡圖書的課堂式體驗不同，閱讀《Wireshark網絡分析的藝術》的感覺更像在聽技術圈的朋友分享經驗，除了知識，還有心情和想法。本書的覆蓋范圍從日常使用的手機App，到企業級的數據中心；從對付運營商的網絡劫持，到開發自己的分析工具，不一而足。無論你是系統管理員、實施工程師、技術支持、網管、培訓教師，還是開發和測試人員，都適合閱讀本書。
</div>