網絡異常 檢查【此篇文章推薦大家看】

無論是否能訪問外網，一個路由器上的目標機器，只要是在同一個網段，都是可以互相ping通的。

從原理上分析，協議上，Socket連接使用的是TCP/UDP協議基於IP，Ping使用的是ICMP協議基於 IP。這就決定了兩者只是共用IP層。

只要網絡是通的，就可以機器間互相共享文件。如果是局域網上，任何單臺目標機器ping路由，ping本機都沒有問題也可以上網，則說明局域網是通的。（參考網絡編程經典《TCP/IP詳解》）

備註：

1、兩臺目標機器不在同一個網段是不能ping通的。若要能ping通，則需要路由器去路由轉發，如將內網IP映射到一個公網IP或公網域名上（可以使用花生殼內網版客戶端）。

2、目標機器要能基於tcp/udp連接，必須要能互相ping通，但能ping通不一定就能connect上，可能訪問的端口不對，建議更換成正確的端口（如讓客戶端訪問服務端的內網端口映射到的外網端口）。

能順利ping通外網網址，說明你的計算機與外網網站是互通的。
之所以socket TCP連接失敗或者UDP無響應，原因可以從以下三個環節中查找：
1）本機（你的計算機）
防火牆是否屏蔽掉你使用的端口？
2）公司外網路由（或網關）
路由（網關）是否開放了你所指定的協議（TCP或UDP）以及端口？
3）外網網站
外網網站是否允許使用你所指定的協議（TCP或UDP）以及端口？

上述三個環節，只要有一個出問題，都會導致Socket連接失敗，或UDP無響應！

3、服務端和客戶端都運行在本地機器上，多個本地客戶端只能第一個客戶端去連接服務端纔有效，即服務端只接收第一個本地客戶端的連接請求，後續第二個，第三個等本地客戶端的連接請求是不會再被接收的，會是個無響應的連接請求。而且這種服務端和客戶端都運行在本地機器上的情形，是不走網卡的。

 

 

 

下面是別處文章的內容：點擊打開鏈接

利用libevent進行網絡異常檢查（客戶端能及時檢測到自身的網絡異常）

《網絡編程釋疑之：TCP半開連接的處理》這篇文章主要講述了網絡異常的出現、以及如何在服務端解決存在的網絡異常。同時，客戶端能否及時檢測到自身的網絡異常（比如網絡禁用，網線斷開......）也同樣影響着客戶端的正常邏輯，下面我就通過自己的實驗和實踐來給大家說明下。

場景是這樣的，客戶端和服務端建立起一個長連接，並且通過一個心跳來維持上線狀態、同時也爲了解決上面所說的TCP半開連接問題。客戶端在自身出現網絡異常的情況下下線，但是一旦自身網絡恢復要自動恢復此前的正常邏輯。這種情況在現實場景中有很多，比如底層協議爲TCP的即時聊天軟件在自身網絡異常的情況下掉線，一旦網絡恢復就自動上線，還有其他很多的基於TCP自動重連應用。這樣，要求我們能及時快速的響應到網絡異常並開始新的自動重連動作。

當然，我們可以從操作系統的層次去迅速響應到網絡異常（比如網絡禁用，網線斷開...)，但是我目前還沒找到特別好的方案，望有過實踐的朋友可以指導一二。我便退一步選用了在網絡應用層進行這種網絡異常的檢查，在這個過程中選用了libevent網絡庫的

void bufferevent_setcb (struct bufferevent *bufev, bufferevent_data_cb readcb, bufferevent_data_cb writecb, bufferevent_event_cb eventcb, void *cbarg)

方法，利用eventcb回調來響應網絡關閉或異常事件。之所以寫這篇文章，就是因爲在這過程中發現了一些不同的網絡異常行爲導致的處理不同，甚至在不同的操作系統下也有不同。

Windows系統

禁用網絡會立馬響應eventcb回調，對應的事件是BEV_EVENT_ERROR。

而斷開網線不會立馬響應eventcb回調，而是在下一次利用此socket進行數據操作時響應eventcb回調，對應的事件爲BEV_EVENT_EOF。

Linux系統（CentOS）

禁用網絡和斷開網線都不會響應eventcb回調，需要自己去處理關閉socket描述符並清理響應libevent的資源。

Android系統

奇怪的是同是linux內核，但是在禁用網絡和wifi斷開情況下的處理卻和windows系統類似。

---

另外分享給大家一篇文章《網絡異常檢查》