網路協議棧異常

Ⅰ 網路癱瘓一般都是由於哪些原因造成的

家庭網路故障（network failure）是指由於硬體的問題、軟體的漏洞、病毒的侵入等引起網路無法提供正常服務或降低服務質量的狀態。硬體一般都是由架構網路的設備，包括網卡、網線、路由、交換機、數據機等設備引起的的網路故障 。對於這種故障，我們一般可以通過PING命令,和tracert命令等查看的出來。軟體一般TCP/IP協議如果出現故障的話，網路肯定是會出現問題了。還有可能就是對用戶管理出現了問題。有時候防火牆的設置也會影響網路。

排除方法：

首先排查物理層故障：檢查路由器、貓等網路設備的電源是否正常（看一下電源指示燈）；檢查網線是否連接正確（按照說明書連接）；檢查網線是否完好無損並能夠正常工作（可以將被測試網線的兩端插入路由器的兩個LAN口，檢查兩個LAN口的指示燈是否亮起）；檢查電腦上無線網卡或者有線網卡是否被禁用（進入控制面板，在地址欄中輸入「網路連接」後，查看網卡是否被禁用，如若被禁用則啟用即可）。

然後檢查TCP/IP協議棧是否工作正常：按住WIN鍵+R鍵，彈出運行窗口，並輸入「cmd」，然後回車：回車後跳出一個黑框框，這裡面輸入「ping 127.0.0.1」，然後回車：如果返回的信息是「來自127.0.0.1的回復：位元組=XX 時間<XXms TTL=XX」，那說明TCP/IP協議棧運行正常。否則就是TCP/IP協議棧除了問題，需要重新安裝TCP/IP協議咯！

最後檢查路由器配置是否正確：打開路由器配置界面：打開IE瀏覽器，在地址欄中輸入前面所查詢到的「網關地址」：默認的用戶名密碼都是admin，不同的路由器廠商不同，詳見路由器背面或者產品說明書。在DHCP設置中，開啟DHCP服務，地址池可以從192.168.X.100開始，結束IP根據你的需求來。一般默認即可：保存完畢以後，點擊系統工具-->重啟路由器-->重啟即可。

Ⅱ UDP怎麼會返回Connection refused錯誤

有時候，寫UDP socket程序的
時候，在調用sendto或者recvfrom的時候，會發現有Connection
refused錯誤返回，錯誤碼是ECONNREFUSED。對於懂得socket介面但是不很很懂網路的人，可能這根本就不是個問題，他會根據錯誤碼知
道遠端沒有這個服務埠，正如socket api的man手冊中描述的那樣：
ECONNREFUSED
A remote host refused to allow the network connection (typically because it is not running the requested service).
有
時候無知真的是一種幸福！但是如果你十分精通TCP/IP棧，那麼就想不通了，UDP既然無連接，怎麼知道遠端的情況呢？UDP不正如協議標准描述的那
樣，發出去就不管了嗎？對於接收，沒有數據就一直等，如果設置了NOWAIT，則直接返回EAGAIN，表示稍後再試。不管怎麼說，也不會有
ECONNREFUSED這么詳細的信息返回才對啊。

既然UDP不會從對端返回任何錯誤信息，那麼一定有別的什麼返回了，總不能憑空猜測啊。這就涉及到了網路協議設計中的數據平面和控制平面了，對於控制平面
的消息，可以是帶內傳輸，也可以是帶外傳輸。對於TCP而言，無疑是帶內傳輸的，因為它本身就是有連接的協議，協議本身會處理任何的錯誤和異常，然而對於
UDP而言，因為其設計目的就是保持簡單性，故不再附帶有任何帶內的控制消息邏輯，互聯網上為了彌補這一類協議的控制邏輯的缺失，ICMP協議才顯得尤為
重要！實際上，ICMP，根據名稱就可以看出它是一種專門的控制協議，控制和指示IP層發生的事件。

ECONNREFUSED正是ICMP返回的！然而並不是所有的UDP
socket都可以享用ICMP帶來的錯誤提示，畢竟帶外控制消息和協議本身的關聯太鬆散了。UDP
socket必須顯式的connect對端才可以。現在問題又來了，既然UDP根本就是一個無連接的協議，connect的意義何在呢？這其實是
socket介面設計的范疇，和協議本身沒有任何關系，當一個UDP
socket去connect一個遠端時，並沒有發送任何的數據包，其效果僅僅是在本地建立了一個五元組映射，對應到一個對端，該映射的作用正是為了和
UDP帶外的ICMP控制通道捆綁在一起，使得UDP socket的介面含義更加豐滿。

我們知道，ICMP錯誤信息返回時，ICMP的包內容就是出錯的那個原始數據包，根據這個原始數據包可以找出一個五元組，根據該五元組就可以對應到一個本
地的connect過的UDP
socket，進而把錯誤消息傳輸給該socket，應用程序在調用socket介面函數的時候，就可以得到該錯誤消息。如果一個UDP
socket沒有調用過connect，那麼即使有ICMP數據包返回，由於socket保持了UDP的完整語義，協議棧也就不保存關於該socket和
對端關聯的任何信息，因此也就無法找到一個特定的五元組將錯誤碼傳給它。
以下是一個測試程序：
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>
#include <netinet/in.h>
#include <stdio.h>
#include <arpa/inet.h>
#include <unistd.h>
void test( int sd, struct sockaddr *addr, socklen_t len)
{
char buf[4];
connect(sd, (struct sockaddr *)addr, len);
sendto(sd, buf, 4, 0, (struct sockaddr *)addr, len);
perror("write");
sendto(sd, buf, 4, 0, (struct sockaddr *)addr, len);
perror("write");
recvfrom(sd, buf, 4, 0, (struct sockaddr *)addr, len);
perror("read");
}
int main(int argc, char **argv)
{
int sd;
struct sockaddr_in addr;
if(argc != 2) {
exit(1);
}
bzero(&addr, sizeof(addr));
addr.sin_family = AF_INET;
addr.sin_port = htons(12345);
inet_pton(AF_INET, argv[1], &addr.sin_addr);
sd = socket(AF_INET, SOCK_DGRAM, 0);
test(sd, (struct sockaddr *)&addr, sizeof(addr));
return 0;
}

編譯為UDPclient，執行./UDPclient 192.168.1.20，注意，這個地址一定要是個IP可達的地址，才好測試。按照上面的理論，結果應該是：第一個sendto成功，然後192.168.1.20返回了：
ICMP 192.168.1.20 udp port 12345 unreachable, length 40
接下來第二個sendto返回：
write: Connection refused
由於第二次沒有發送任何數據包到達192.168.1.20，所以也不能企望它返回ICMP錯誤信息，因此接下來的recvfrom調用會阻塞。
最後的一個問題時，你不能太指望這個Connection refused以及一切帶外返回的錯誤信息，因為你不能保證一定能收到遠端發送的ICMP包，如果中間的某個節點或者本機禁掉了ICMP，socket api調用就無法捕獲這些錯誤。

Ⅲ 網路協議錯誤怎麼解決

網路協議錯誤可以通過修改電腦的網路協議ip地址解決，步驟如下。

1，打開windows7系統，在桌面右下角點擊「網路」。

Ⅳ 請教ZigBee協議棧的問題

在ZigBee Pro里，則新增加了一對多路由(Multicast Routing)、多對一路由及源節點路由。一對多路由與一對一路由(Unicast Routing)相同，路由節點會發出路由要求，差別在於當收到封包的節點，會檢查群組身分表(Group ID Table, GIDT)，GIDT由當地(Local)端設定，如果是屬於相同的群組身分(Group ID)的話，就會迴路由響應，在迴路由響應後，建立的路由表條目(Route Table Entry)就可以使用。因此如果發送一對多的封包(圖6)，會先檢查GIDT，如果不是屬於同一個群組，就會檢查路由表，把封包往下一個節點(Next Hop)傳送，如果檢查到是屬於自己群組封包時，會將自己的狀態改成會員模式(Member Mode)，然後再將封包以廣播(Broadcast)方式，確保同一個群組的節點都能夠接收到這筆數據。當然，為了避免這個廣播的封包在網路上一直重復的傳送，當節點的狀態為會員模式時，會檢查廣播傳送表(Broadcast Transmission Table)，以確保不再重復傳送同樣的封包。

就應用而言，很多情境會把數據集中收集，多數的節點都會把數據往同一個節點送，因此，整個網路拓撲就如樹狀一樣。由於ZigBee Pro放棄樹狀路由的功能，此時為建立樹狀的路由路徑，如果每個節點都做一對一路由，才能建立往源節點(Originator/Source)的路徑，這樣會花較多的時間，較沒有效率，所以必須提出一個新的路由方式，即所謂的多對一路由(圖7)。由源節點發送多對一路由的路由要求，當接收到這個封包的節點，就會直接建立一條往源節點路由的路徑，所以所有節點很快就會建好路由條目。

反向基本上還是得透過一對一路由的方式，建立起源節點對於其它節點的路由路徑。不過在ZigBee Pro增加源節點路由的方式，就是當路由路徑有變化時，節點會先發出一個路由紀錄命令(Route Record Command)，這個命令中會記錄這條路徑上經過的節點，因此當源節點接收該命令後，會把這條路徑記錄在源節點路由表(Source Route Table)，只要源節點須把數據傳送到其它節點時，會先到源節點路由表找尋路由路徑，以加快時間，並且減少建立路由路徑或路徑修復的次數。

更詳細的解釋看參考資料里的吧，講的很清楚

Ⅳ 網路協議棧是什麼

協議棧（英語：Protocol stack），又稱協議堆疊，是計算機網路協議套件的一個具體的軟體實現。協議套件中的一個協議通常是只為一個目的而設計的，這樣可以使得設計更容易。因為每個協議模塊通常都要和其他兩個通信，它們通常可以想像成是協議棧中的層。最低級的協議總是描述與硬體的物理交互。每個高級的層次增加更多的特性。用戶應用程序只是處理最上層的協議。

Ⅵ bios中網路協議棧開啟會怎麼樣

Network
stack：網路協議棧。開啟/關閉UEFI網路協議棧。開啟Network
stack後可以設置下面2個選項。
Ipv4
PXE
Support：開啟/關閉Ipv4（互聯網協議第4版）
PXE支持。
Ipv6
PXE
Support：開啟/關閉Ipv6（互聯網協議第6版）
PXE支持。

Ⅶ Qt網路編程 伺服器異常斷開，不能檢查到網路狀態變化

自己做心跳保活。因為異常斷開不屬於qt的處理范圍，而tcp協議棧又不存在自動處理異常斷線的功能，tcp連接在不正常關閉情況下通常都會被協議棧保持存活一段時間（具體和操作系統協議棧實現和設置有關）。qt無法獲得tcp協議棧的狀態消息，也就不會做出任何反應。所謂心跳機制請參照以下網址內容：

http://ke..com/view/4372209.htm

Ⅷ 協議棧是什麼意思

協議棧（Protocol Stack）是指網路中各層協議的總和，其形象的反映了一個網路中文件傳輸的過程：由上層協議到底層協議，再由底層協議到上層協議。使用最廣泛的是英特網協議棧，由上到下的協議分別是：應用層（HTTP，FTP，TFTP，TELNET，DNS，EMAIL等），運輸層（TCP，UDP），網路層（IP），鏈路層（WI-FI，乙太網，令牌環，FDDI，MAC等），物理層。

Ⅸ 手機wifi模塊異常是怎麼回事

• wifi模塊出現異常了，一般這種情況可以把手機進行恢復設置看看。

• 手機的問題，先嘗試使用其它wifi軟體連網，再不行的就去手機店維修。
  
  
  

Ⅹ 如何測試TCP/IP協議棧來修復網路連接故障

在我們修復Windows網路連接時，要確保本地TCP/IP棧沒有問題。本文將一步步地指導您進行本地主機連接DNS伺服器和默認網關伺服器的能力測試，並介紹如何測試主機名解析。

在「檢查IP配置」中，我闡述了如何確定哪個IP地址是我們的系統使用的主地址。接下來，我們會驗證IP地址配置是正常工作的，以及本地TCP/IP堆棧沒有問題。

首先，我們需要執行的測試是PING本地主機地址。有幾種不同的方法可以實現這個步驟。其中一個是輸入下面的命令：

PING LOCALHOST

當我們輸入這個命令時，Windows將PING地址127.0.0.1。不管我們的機器的地址是什麼，Windows總會使用127.0.0.1作為本地主機地址。因此，對於上面所列出來的命令，另外一個替代的命令是：

Ping 127.0.0.1

輸入這個命令時，我們應該可以查看到一個成功的PING，如同使用其它的PING命令一樣。我們可以看到圖A所顯示的例子。

PING本地主機地址對診斷遠程主機連接問題沒有什麼作用。然而，它卻可以允許我們確認我們的本地TCP/IP
棧運行是否正確。當我們PING本地主機地址時接收到目的主機無法到達的錯誤信息時，這往往意味著TCP/IP的配置是不正確的，或者本地TCP/IP棧
的某個部分出錯了。

依據我的個人經驗，我們通常可以通過刪除計算機的TCP/IP協議來處理這個問題，然後重新設置。

PING默認網關

在本系列的前面的部分文章中，我提到有幾種不同的TCP/IP配置部分需要文檔化，它們是故障修復過程所必需的。其中有默認網關的IP地址和主DNS伺服器的信息。

假設我們嘗試連接的是遠程網路或者在企業網路的不同分片上的主機，那麼我們下一步需要嘗試的是PING默認網關。我們可以簡單地通過在PING命令
後添加默認網關的IP地址來完成。比如，如圖B，請注意我的TCP/IP配置列出了我的默認網關地址是147.100.100.100。然後，我會直接
PING這個地址。這就驗證了本地機器可以連接到默認網關。同時，它也告訴我們本地網路的連接工作正常，至少在IP地址層上是正常的。

PING DNS伺服器

目前，我們已經確定在本地計算機和默認網關之間的IP層連接是正常的。然而，這並不保證主機名被解析到正確的IP地址。在這一系列的文章的第一部分
「使用PING命令來修復網路連接故障」中，我已經探討了如何使用目的主機的正式域名和PING命令來驗證DNS伺服器是否正常工作。還有幾種其它的方法
我們可以用來簡單地測試DNS名字解析。

其中一個是，我們可以PING DNS伺服器的IP地址，如圖C所示。這並不保證名字解析是正確工作的，但是它肯定可以驗證本地機器能夠連接到DNS伺服器上。

另外一個方法是使用Nslookup命令來驗證域名解析是正確工作的。我們只需簡單地輸入Nslookup，後面加上遠程主機的正式域名。Nslookup命令就應該能夠將域名解析到一個IP地址，如圖D所示。

如果我們不經常使用Nslookup，那麼一開始上面的圖象可能會有點誤導我們。首先，這個屏幕似乎在報告一個錯誤。如果我們更仔細點觀察，我們可
以看到返回的信息的第一部分是來自於本地DNS伺服器。這是因為所引用的IP地址是與DNS伺服器的IP地址相匹配的。然而，返回的信息的後面部分為我們
提供的是我們所要查詢的主機的IP地址。只要列出了這個IP地址，那麼DNS查詢就是成功的。

如果域名解析過程失敗了，那麼就可以肯定存在一個DNS問題。實際問題可能是許多不同的DNS伺服器問題中的其中一個。比如，轉發的DNS伺服器地
址可能是不正確的，或者DNS伺服器可能並不訪問網際網路，這些都是連接更高級DNS伺服器所必須的。類似的，DNS伺服器的DNS服務可能已經中斷。典型
地，由於許多客戶往往都依賴於一個DNS伺服器，因此這些類型的問題將會影響到其它客戶。

如果DNS域名解析成功了，那麼，重要的是我們要驗證域名解析過程中返回的IP地址。我們可以通過對比返回的IP地址和遠程主機正在使用的實際的IP地址來進行驗證。這些IP地址必須是相匹配的，但是，其中可能會有不匹配的情況，它將造成連接失敗。

當出現IP地址不匹配時，可能是客戶端感染了惡意軟體或者是DNS中毒了。DNS中毒指的是DNS緩存中被寫入無效的或者不正確的IP地址。

當出現這樣一個問題時，我會建議客戶端機器的進行惡意軟體掃描。同時對間諜軟體和病毒進行掃描是很重要的，因為它們都會引起這種問題。一旦清除了惡意軟體的問題，那麼可以嘗試清空DNS緩存。我們可以輸入下面的命令來清空DNS緩存：

IPCONFIG /FLUSHDNS

我們可以看看這個例子，如圖E所示：

其中需要記住的重要一點是， DNS緩存包含不準確IP地址，並不總是意味著發生了DNS中毒。因為有時主機被指派了新的IP地址後，DNS緩存需要一段時間才會得到修改後的IP地址。

總結

在本文中，我已經闡述了如何驗證本地TCP/IP協議棧是否正確工作。接下來，我還繼續闡述了如何測試本地主機與DNS伺服器和默認網關伺服器交互
的能力，以及如何測試主機域名解析。在本系列接下來的內容中，我將探討可以使用PING命令來檢測的幾個常見問題，同時我還將開始探討路由問題。