The Will Will Web | 魔鬼般的細節:127.20.11.12 與 172.20.11.12 的慘痛教訓

The Will Will Web

記載著 Will 在網路世界的學習心得與技術分享

魔鬼般的細節:127.20.11.12 與 172.20.11.12 的慘痛教訓

你知道寫程式、玩 IT 最需要的是什麼嗎?是 “視力”!原來卡住我們好幾個星期的問題是因為有人將主機的 hosts 設定錯誤導致程式發生異常,而這個錯誤之前在做程式驗證時還檢驗不出來,有趣的地方請繼續看下去。

我們的專案利用 MSMQ 實做了一個訊息傳遞機制,假設我們有四台 Web 伺服器,如果 Web1 接到新訊息就會傳遞到 Web2, Web3, Web4 三台,如果 Web2 接收到訊息就會傳遞到 Web1, Web3, Web4 三台,依此類推。

由於客戶的環境並無 Active Directory 或自行��置的內部 DNS,我們為了讓訊息透過主機名稱而非透過 IP 連線,所以在各台主機設定 hosts 檔案 ( 不知道 hosts 的人可參考: 手動設定網址對應 IP 的方式 ),設定的內容如下圖示 ( 這是錯誤的設定,不知道是哪位天兵設定的 ):

 

設定完後很自然的透過 ping web2 的方式測試,結果是通的。然後測試 MSMQ 進行訊息傳遞,訊息也成功送出,所以上線後就認為應該沒問題了。

然後我們的程式透過 MSMQ 送一段時間後訊息就會停止傳送,我今天就是去客戶端查詢這個問題。首先,固執的我堅持認為 MSMQ 沒那麼弱,畢竟是在業界使用數十年的技術了,不可能在 MSMQ 的訊息無故不送出,且還不引發任何錯誤,但是訊息就是一直待在「傳出佇列」裡一動也不動的待著。

訊息放到「傳出佇列」後也沒有任何想傳遞的跡象,連嘗試送一次也沒有:

最後眼尖的我在開啟 hosts 檔查看 IP 對應表後才知道原來是 IP 打錯了!!!

但是,為什麼一個錯誤的 IP 卻 Ping 的到呢??

我們可以看一下 localhost - Wikipedia, the free encyclopedia 的說明,在 Internet Engineering Task Force (IETF) 定義的標準中是將整個 127.0.0.0/8 ( Class A ) 的位址都用做為 loopback 用途,所以所有 127.xxx.xxx.xxx 開頭的 IP 位址全部都會導向到「本機」,所以當然 Ping 的到。

最後,我將 127.20.11.xx 修改成 172.20.11.xx 就把問題解決了,一行程式都不用改!很瞎的問題,不過花了我們好多時間才解決。

我沒辦法要求開發人員能懂這麼多 IT / 網管 的東西,只希望你們 眼力 好一點,不要再打錯了,尤其是很愛 Copy & Paste 的人,更應該小心行事。

相關連結