在我們修復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命令來檢測的幾個常見問題，同時我還將開始探討路由問題。
『貳』 Thread協議棧基礎
Thread協議棧是可靠，經濟高效，低功耗，無線D2D（設備到設備）通信的開放標准。它是專為連接家庭應用而設計的，其中需要基於IP的網路，並且可以在協議棧中使用各種應用層。
這些是Thread協議棧和網路的一般特性：
圖1顯示了Thread協議棧的概述。
該標准基於在2.4GHz頻帶中以250kbps運行的IEEE 802.15.4 [IEEE802154] PHY（物理層）和MAC（媒體訪問控制層）。該規范的IEEE 802.15.4-2006版本用於Thread協議棧。
802.15.4 MAC層用於基本的消息處理和擁塞控制。該MAC層包括設備用於監聽干凈信道的CSMA（Carrier Sense Multiple Access，載波偵聽多路訪問）機制，以及用於處理重試和確認消息的鏈路層以用於相鄰設備之間的可靠通信。基於由軟體協議棧的較高層建立和配置的密鑰，被MAC層用於對消息的加密和完整性保護。網路層建立在這些基礎機制上，以在網路中提供可靠的端對端通信。
在由運行Thread協議棧的設備組成的系統中，這些設備都不代表單點故障。雖然系統中有許多設備執行特殊功能，但是Thread協議棧的設計使得它們可以被替換，而不會影響Thread網路中正在進行的通信。例如，一個常眠的子設備需要一個父設備進行通信，因此這個父設備代表它的通信失敗單點。但是，如果常眠設備的父設備不可用，常眠設備可以並將會選擇另一個父設備，因此該轉換不應該對用戶可見。
雖然系統設計用於沒有單點故障，但在某些拓撲結構下，將存在沒有備份功能的單個設備。例如，在具有單個網關的系統中，如果網關斷電，則無法切換到另一個網關。
路由器或邊界路由器可以為Thread網路中的某些功能承擔Leader角色。這個Leader需要在網路內作出決定。例如，Leader分配路由器地址並允許新的路由器請求。Leader角色是被選舉的，如果Leader失敗，會由另一個路由器或邊界路由器承擔Leader角色。正是這種自主操作確保沒有單點故障。
邊界路由器是一種特定類型的路由器，提供從802.15.4網路到其他物理層（例如，Wi-Fi和乙太網）上的相鄰網路的連接。邊界路由器為802.15.4網路中的設備提供服務，包括用於離網操作（off-network operations）的路由服務。Thread網路中可能有一個或多個邊界路由器。
路由器為網路設備提供路由服務。路由器還為嘗試加入網路的設備提供加入和安全服務。路由器是設計為不休眠的。路由器可以降級其功能並成為REED（Router-eligible End Devices，符合路由器的終端設備）。
REED有能力成為路由器，但是由於網路拓撲或條件，這些設備不作為路由器工作。這些設備通常不轉發消息或為Thread網路中的其他設備提供加入或安全服務。如果需要，Thread網路管理REED成為路由器，且無需用戶交互。
常眠終端設備是主機設備。他們只通過他們的父路由器進行通信，不能轉發其他設備的消息。
Thread協議棧中的設備支持[RFC 4291]中指定的IPv6定址架構。設備配置1個或多個ULA（Unique Local Address，唯一本地地址）或GUA（Global Unicast Address，全局單播地址）地址。
啟動網路的設備選擇一個/64前綴，然後在整個Thread網路中使用。該前綴是本地分配的全局ID（Locally Assigned Global ID），通常稱為ULA前綴[RFC 4193]，可以稱為網格本地ULA前綴（mesh local ULA prefix）。Thread網路還可以具有一個或多個邊界路由器，每個邊界路由器可以具有或可以不具有可以用於生成附加GUA的前綴。Thread網路中的設備使用其擴展MAC地址（Extended MAC address）來導出其[RFC 4944]第6節中定義的介面標識符（interface identifier），並且基於此，通過已知的本地前綴FE80 :: 0/64配置鏈路本地IPv6地址，如[RFC 4862]和[RFC 4944]所述。
設備還支持適當的多播地址（multicast addresses）。這包括鏈路本地所有節點組播（link-local all node multicast），鏈路本地全路由器組播（link-local all-router multicast）和區域本地組播（realm-local multicast）。
加入Thread網路的每個設備都將分配一個16位短地址，如[IEEE 802.15.4]中所規定。對於路由器，該地址使用地址欄位中的較高位分配，低位設置為0，表示路由器地址。然後，對於子設備使用其父設備的高位和適當的低位來為其地址分配一個16位的短地址。這允許Thread網路中的任何其他設備通過使用其地址欄位的高位來了解子設備的路由位置。
圖2說明了Thread短地址。
所有設備使用[RFC 4944]和[RFC 6282]中定義的6LoWPAN。
在Thread網路中使用頭部壓縮（Header compression），設備傳輸消息盡可能多地壓縮IPv6報頭，以最小化發送的數據包的大小。
支持網格包頭（mesh header），用於更有效地壓縮網格內的消息，以及針對如「路由和網路連接」部分中所述的鏈路層轉發（link layer forwarding）。網格標頭（mesh header）還允許消息的端到端分段（end-to-end fragmentation），而不是[RFC 4944]中指定的逐跳分段（hop by hop fragmentation）。Thread協議棧使用路由選擇配置（route-over configuration）。
這些設備不支持[RFC 6775]中規定的鄰居發現（neighbor discovery），因為DHCPv6用於向路由器分配地址。終端設備和REED由他們的路由器父節點分配短地址。然後，該短地址用於配置用於網路內通信的網格（Mesh）本地ULA。
有關6LoWPAN使用和配置的更多詳細信息，請參見「6LoWPAN的Thread用法（Thread Usage of 6LoWPAN）」白皮書。Thread規范的第3章詳細說明了使用的具體6LoWPAN配置。
設備支持ICMPv6（Internet Control Message Protocol version 6，Internet控制消息協議版本6）協議[RFC 4443]和ICMPv6錯誤消息，以及回顯請求（echo request）和回顯回復消息（echo reply messages）。
Thread協議棧支持在[RFC 768]中定義的UDP（用戶數據報協議），用於設備之間的消息傳遞。
Thread協議棧支持Thread網路中所有路由器之間的全網格連接（full mesh connectivity）。
實際拓撲基於Thread網路中路由器的數量。如果只有一個路由器或邊界路由器，則形成具有單個路由器的基本星形拓撲。如果有多個路由器，則自動形成網格（Mesh）拓撲。圖3說明了Thread網路的基本拓撲結構和設備類型。
網格網路（Mesh Networks）通過允許射頻轉發其他射頻的消息，使射頻系統更可靠。例如，如果節點不能直接向另一個節點發送消息，則網格網路（Mesh Networks）通過一個或多個中間節點轉發消息。如「路由和網路連接」一節中所討論的，Thread網路的性質使得所有路由器節點彼此之間保持路由和連接，因此網格不斷維護和連接。Thread網路中通常有最多32個活動路由器的限制。但是，64個路由器地址用於允許回收路由器地址。
在網格網路（Mesh Networks）中，常眠終端設備或REED不會為其他設備路由。這些設備將消息發送到作為路由器的父設備。該父路由器處理其子設備的路由操作。
Thread網路通常最多有32個活動路由器，它們使用基於設備路由表的消息的下一跳路由（next-hop routing）。設備路由表由協議棧維護，以確保所有路由器都具有Thread網路中任何其他路由器的連接和最新路徑。使用RIP（Routing Information Protocol，路由信息協議）演算法（來自[RFC 1058]和[RFC 2080]的演算法，但不採用其特定的消息格式）。所有路由器與其他路由器使用MLE（Mesh Link Establishment），以壓縮格式交換其到Thread網路中的其他路由器的路由成本（cost of routing）。
注意：從IP的角度來看，Thread網路支持路由器和主機。主機是常眠終端設備或REED。
MLE消息（請參閱「Thread規范」第4章「消息鏈路建立（Message Link Establishment）」 中針對Thread進行的擴展[draft-kelsey-intarea-mesh-link-establishment-06]) 用於建立和配置安全射頻鏈路，檢測鄰近設備，以及維護Thread網路中設備之間的路由成本。使用單跳鏈路本地單播（single-hop link local unicasts）和路由器之間多播（multicasts between Routers）來傳輸MLE消息。
隨著拓撲和物理環境的變化，MLE消息用於識別，配置和保護鄰近設備的鏈路。MLE還用於分發跨Thread網路共享的配置值，如通道（channel）和PAN（Personal Area Network，個人區域網路）ID。這些消息可以由MPL（Multicast Protocol for Low power and Lossy Networks，低功耗和有損網路的多播協議）指定的簡單洪泛轉發（forwarded with simple flooding）。（有關詳細信息，請參閱[draft-ietf-roll-trickle-mcast-09]）。
在建立兩個設備之間的路由成本時，MLE消息還確保考慮了非對稱鏈路成本（asymmetric link costs）。802.15.4網路中的非對稱鏈路成本（asymmetric link costs）很常見。為了確保雙向通信是可靠的，考慮雙向鏈路的成本是很重要的。
按需路由發現（On-demand route discovery）通常用於低功耗802.15.4網路。然而，由於路由發現請求洪泛網路（route discovery requests flooding the network），按需路由發現（on-demand route discovery）在網路開銷和帶寬方面是昂貴的。
在Thread網路中，所有路由器定期交換包含到所有鄰居路由器鏈路成本信息（link cost information to all neighbor Routers）的單跳MLE廣告包（single-hop MLE advertisement packets），以及到Thread網路中所有其他路由器的路徑開銷（path costs to all other Routers）。通過這些定期的本地更新，所有路由器都具有Thread網路中任何其他路由器的最新路徑開銷信息，因此不需要按需路由發現。如果路由不再可用，路由器可以在到達目的地的下一個最合適的路由上進行選擇。這種自愈路由機制允許路由器快速檢測其他路由器是否已經脫離Thread網路，並計算最佳路徑以維護與Thread網路中所有其他設備的連接。
每個方向的鏈路質量（link quality in each direction）基於來自該鄰近設備的傳入消息的鏈路成本（link cost on incoming messages from that neighboring device）。此傳入鏈路成本（incoming link cost）映射到從0到3的鏈路質量（link quality）。值為0表示未知成本。鏈路成本（link cost is a measure of RSSI）是接收到的消息高於接收等級的RSSI（接收信號強度指示）的度量。
表1總結了鏈路質量和鏈路成本。
圖4示出了Thread網路上的各種鏈路成本的示例。
Thread網路中任何其他節點的路徑開銷就是到達該節點的鏈路成本的最小值。路由器監控這些成本，即使網路的射頻鏈路質量或拓撲變化，並通過使用周期性MLE廣告消息在Thread網路傳播新的成本。路由成本基於兩個設備之間的雙向鏈路質量。
為了說明一個簡化的例子，想像一下預先委託的網路（pre-commissioned network），其中共享安全材料，所有的設備同時啟動。每個路由器將周期性地發送初始填充的到單跳鄰居成本的廣告。在內部，每個路由器將存儲未在廣告中發送的下一跳信息（next hop information）。
前幾個廣告的路徑成本等於鏈路成本，因為已知的唯一路由器是立即鄰居，如圖5所示。
但是，隨著路由器開始收聽來自鄰居的廣告，其中包含兩跳或更多跳的其他路由器的成本，它們的表填充了多跳路徑成本，然後傳播得更遠，直到最終在所有路由器之間存在如圖6和圖7所示的連接信息網路。
當路由器從鄰居接收到新的MLE廣告時，它或者已經具有該設備的鄰居表項，或者添加一個。MLE廣告包含來自鄰居的進入成本（incoming cost from the neighbor），因此在路由器的鄰居表中更新（updated in the Router』s neighbor table）。MLE廣告還包含其他路由器的更新的路由信息（updated routing information for other Routers），並且該信息在設備路由表中更新（updated in the device routing table）。
通過查看子設備的地址的高位來確定父路由器地址（Parent Router address），可以實現到子設備的路由。一旦設備知道父路由器，它就具有該設備的路徑開銷信息和下一跳路由信息（path cost information and next-hop routing information）。
活動路由器的數量僅限於可以包含在單個802.15.4數據包中的路由和成本信息的數量。此限制目前為32個路由器，但提供了64個活動路由器地址以允許老化掉路由器地址（aging out of Router addresses）。
設備使用IP路由轉發數據包（IP routing to forward packets）。設備路由表（device routing table）填充有路由器的網格本地ULA地址的壓縮形式和適當的下一跳（compressed form of a mesh local ULA address for Routers and the appropriate next hop）。
距離向量路由（Distance vector routing）用於獲取到Thread網路上路由器地址的路由（get routes to Router addresses）。當在Thread網路上進行路由時，該16位地址的高6位定義了目標路由器的路由器地址。如果目的地址的低位為0，則路由器為最終目的地址。否則，目的路由器負責根據16位目的地址的較低位轉發到最終目的地。
對於超出Thread網路的路由，邊界路由器通知Leader其所服務的特定前綴（particular prefix(es) it serves），並且該信息作為MLE數據包中的Thread網路數據分發（distributed as Thread Network data within the MLE packets）。Thread網路數據包括：前綴數據（prefix data），它是前綴本身，6LoWPAN上下文（6LoWPAN context），邊界路由器（Border Routers）和該前綴的DHCPv6伺服器（DHCPv6 server for that prefix）。如果設備要使用該前綴配置IPv6地址，則使用SLAAC（Stateless Address Autoconfiguration，無狀態地址自動配置）或聯系相應的DHCP（Dynamic Host Configuration Protocol，動態主機配置協議）伺服器。Thread網路數據還包括路由伺服器列表（a list of routing servers），它們是默認的邊界路由器的路由器地址。
Leader被指定做出決策，選擇REED成為路由器或允許路由器降級為REED。Leader也分配和管理路由器地址。然而，此路由Leader中包含的所有信息都存在於其他路由器中，並且如果路由Leader變得無法訪問，則另一個路由器將自主被選擇並作為Leader接管，而無需用戶干預。
雖然在Thread協議棧中使用UDP消息傳遞，但仍然需要可靠的消息傳遞。這是使用一系列輕量級機制完成的，如下所示：
加入設備（joining device）必須經歷各個階段才能參與Thread網路：
所有加入都是Thread網路中用戶啟動的。一旦加入，設備就可以完全參與Thread網路，並可以與Thread網路內外的其他設備和服務交換應用層信息。
加入設備（joining device）必須發現Thread網路，並與路由器建立聯系（establish contact with a Router）以進行調試（commissioning）。加入設備掃描所有信道（scans all channels），在每個信道上發出信標請求（issues a beacon request），並等待信標響應（waits for beacon responses）。信標包含一個有效載荷，包括網路SSID（Service Set Identifier，服務集標識符）和允許加入信標的許可證（a permit joining beacon），指示Thread網路是否正在接受新的成員。一旦設備發現Thread網路，它將使用MLE消息來建立一個相鄰的路由器（establish a neighboring Router），通過它可以執行調試（perform commissioning）。
如果設備已經獲得了調試信息（obtained commissioning information），因為它已經有足夠的信息直接附加到Thread網路，則不需要發現。
Thread提供兩種調試方法：
注意：僅在通過信標有效載荷中的許可證加入標志（joining solely via the permit joining flag in the beacon payload）的典型802.15.4加入方法不在Thread網路中使用。這種方法最常用於沒有用戶界面或到設備的帶外頻道的按鈕類型加入（push button type joining）。在有多個網路可用的情況下，該方法可能存在設備轉向（device steering）問題，並且也可能存在安全問題。
具有調試信息（commissioning information）的加入設備（joining device）與父路由器聯系，然後通過父路由器交換MLE鏈路配置消息（exchanging MLE link configuration messages）附加到Thread網路。設備作為終端設備（end device）或REED附加到Thread網路，並由父路由器分配16位短地址，如圖8所示。
一旦REED已經附加到Thread網路，它可能會發出一個地址請求（issue an address request）成為一個路由器，然後由Leader分配一個路由器地址。
一旦設備連接到Thread網路，就需要有各種各樣的信息來保持其在網路中的參與。MLE提供服務以在整個網路中分發網路數據，並在鄰居之間交換鏈路成本（link costs）和安全幀計數器（security frame counters）。
MLE消息分發或交換以下信息：
注意 ：MLE消息是被加密的，除非是在發現時，加入設備獲得所需的安全資料過程中。
DHCPv6 [RFC 3315]是一種基於UDP的客戶端 - 伺服器協議，用於管理網路中設備的配置。DHCPv6使用UDP從DHCP伺服器請求數據。
邊界路由器上的DHCPv6服務用於配置：
所有設備都支持ICMPv6錯誤消息，以及回顯請求（ echo request）和回顯回應消息（ echo reply messages）。
設備上的應用層可以訪問一組設備管理和診斷信息，這些信息可以在本地使用或收集並發送到其他管理設備。
Thread協議棧從802.15.4 MAC層使用的信息包括：
Thread協議棧從網路層使用的信息包括：
由於各種原因，在現場操作的設備可能會意外重置或故障重置。已重置的設備需要重新啟動網路操作，無需用戶干預。為此，需要將一組信息存儲在非易失性存儲中。這包括：
『叄』 協議棧是什麼意思
協議棧（Protocol Stack）是指網路中各層協議的總和，其形象的反映了一個網路中文件傳輸的過程：由上層協議到底層協議，再由底層協議到上層協議。使用最廣泛的是英特網協議棧，由上到下的協議分別是：應用層（HTTP，FTP，TFTP，TELNET，DNS，EMAIL等），運輸層（TCP，UDP），網路層（IP），鏈路層（WI-FI，乙太網，令牌環，FDDI，MAC等），物理層。
『肆』 《計算機網路》解釋以下名詞：協議棧、客戶、伺服器、客戶-伺服器方式。
協議棧怎麼說呢就是指分層結構中定義硬體、軟體在不同的級別如何協調工作的一組協議。
如TCP/IP協議棧中包括網路層的IP協議，傳輸層的TCP、UDP協議，應用層的HTTP、FTP協議等等等等。
==============
客戶的定義就多了,對於各行各業都沒有固定的意思,我摘抄了三種:
1、客戶指的是購買或者使用本站的產品或者服務的群體
2、指咨詢項目交付成果的使用者，同時也是該項目的定購人和支付人。
3、客戶指的是產品和服務的受益者。
==============
伺服器的接司就多啦:自己慢慢看:http://www.oaprinter.com/club/dispbbs.asp?boardid=63&id=16828
==============
客戶-伺服器(C/S)方式這個就更簡單啦:請看這個地方:http://www.c111.net/htm/bbs/index.php?mods=topicdisplay&forumid=2&postid=37&p=1