資訊 - UPNP通用即插即用(UPnP NAT Traversal 常見問題)

[psac]

UPNP通用即插即用http://www.slime2.com.tw/forums/show...4%A1%A7Y%A5%CE

UPnP NAT Traversal 常見問題
問：什麼是 UpnP？
答：通用即插即用 (UPnP) 是一種用於 PC 機和智能設備（或儀器）的常見對等網絡 連接的體系結構，尤其是在家庭中。UPnP 以 Internet 標準和技術（例如 TCP/ IP、HTTP 和 XML）為基礎，使這樣的設備彼此可自動連接和協同工作，從而使網 絡（尤其是家庭網絡）對更多的人成為可能。

問：UPnP 對消費者意味著什麼？
答：簡單、更多選擇和更新穎的體驗。包含通用即插即用技術的網絡產品只需實 際連到網絡上，即可開始正常工作。實際上，UPnP 可以和任何網絡媒體技術（有 線或無線）協同使用。舉例來說，這包括：Category 5 以太網電纜、Wi-Fi 或 802.11B 無線網絡、IEEE 1394 ("Firewire")、電話線網絡或電源線網絡。當這些設備 與 PC 互連時，用戶即可充分利用各種具有創新性的服務和應用程序。

問：什麼是 UPnP 論壇？
答：「通用即插即用論壇」是一個開放式業界協會，成立於 1999 年 6 月，旨在幫 助定義 UPnP 標準以簡化家庭（長遠上講則是企業）智能設備的聯網。為實現上述 目標，該論壇正在制定和公佈 UPnP 設備控制協議及服務控制協議。截止到 2001 年 6 月初，已有 350 多家公司成為 UPnP 論壇的成員。UPnP 論壇受由 22 名成員 組成的 UPnP Steering Committee（UPnP 指導委員會）的管理。此外還設立了技術委 員會、市場推廣委員會及各種工作委員會（分別面向某種特定的設備），旨在努力 實現該機構的目標。有關論壇成員的列表及加入論壇的信息，請見論壇 Web 站 點。

問：UPnP 的技術要素是什麼？
答：UPnP 範圍廣泛，原因是它面向的是家庭網絡、臨近網絡及小型企業和商住樓 中的網絡。在網絡控制設備的管理下，它支持任何兩個設備之間的數據通 訊。UPnP 不依賴於特定的操作系統、編程語言或物理媒體。

UPnP 支持零配置網絡及自動查找功能，這樣以來，設備即可動態加入網絡，獲取 IP 地址，宣佈自己的名稱，根據需要提供功能，並瞭解其它設備的存在和功 能。DHCP 和 DNS 服務器為可選項。只要在網絡上可用，即可加以使用。此外， 設備還可自動平穩地脫離網絡，而不會遺留任何不必要的狀態。

UPnP 汲取了 Internet 的成功之處並繼承了它的組件，包括 IP、TCP、UDP、HTTP 及 XML。UPnP 中涉及了多供應商之間的協作，旨在建立標準的設備控制協議 (DCP)。與 Internet 類似，這些協議以公告式線協議為基礎，表示為 XML 形式，且 通過 HTTP 進行通訊。

問：什麼是 NAT？為什麼使用它？
答：「網絡地址轉換」是一種 Internet Engineering Task Force (IETF) 標準，用於允許 專用網絡（使用專用地址範圍，例如 10.0.x.x、192.168.x.x、172.x.x.x）上的多台 PC 機或設備共享單個、可全局路由的 IPv4 地址。經常使用 NAT 的一個主要原因就 是 IPv4（最新一代 Internet）地址的資源日漸緊缺。

在構成公用 Internet 與專用局域網之間屏障的網關設備中，可以使用 NAT。當專 用局域網的 IP 數據包經過網關時，NAT 將把專用 IP 地址和端口號轉換為公用 IP 地址和端口號，從而跟蹤這些轉換以保持各個會話不變。Microsoft? Windows? XP 和 Windows Me 操作系統中的「Internet 連接共享」及許多 Internet 網關設備都使用 NAT，尤其是在通過 DSL 或電纜調製解調器連接寬帶網的情況下。隨著越來越多 的家庭和小型企業將自己的 PC 機連接起來並共享 Internet 連接，NAT 的使用量正 急劇增加。

問：NAT 的問題在哪？
答：簡言之：NAT 會「瓦解」許多家庭或小型企業中日漸需要的最新型 PC 和家 庭網絡技術，例如多玩家遊戲、實時通訊及其它對等服務。如果在公用 Internet 上 使用專用地址或同時使用同一端口號，這些應用程序就會中止。應用程序必須使 用公共地址，且每個會話都須使用唯一的端口號。大型機構有專門的 IT 人員來確 保其公司應用程序在 NAT 上正常使用，但較小的機構和消費者卻不具備這樣奢侈 的條件。UPnP NAT Traversal 可以自動解決 NAT 給應用程序帶來的許多問題，使 之成為小型企業和消費者理想的解決方案。

問：誰提出的 NAT Traversal 解決方案？
答：NAT Traversal 解決方案是 UPnP IGD Working Committee 為制定 Internet 網關設 備 (IGD) 規範所從事工作的一部分。UPnP 的成員公司可以加入該委員會，也可以 只選擇跟蹤其工作進展。委員會的主席是 Intel 公司的 Prakash Iyer (prakash.iyer@intel.com)。許多公司，包括 Microsoft，都在為此而努力。

問：是否有其它途徑來解決 NAT Traversal 的問題？如果有，為什麼將 UPnP 視為最佳選 擇？
答：是的，確實有其它途徑來解決此問題，但目前還沒有其它機制來作為解決該 問題的業界標準，從而能對消費者自動實現，而對開發人員則普遍可行。其它方 案或者要求用戶進行人工干預，或者要求 Internet 網關設備製造商進行專門的開 發，並要求軟件開發人員處理 NAT Traversal 對特殊應用程序的需要。因此，只有 UPnP 能解決該重大問題。

用戶的工作： NAT Traversal 的手工干預法要求用戶使用瀏覽器（PC 機上一種基於圖 形用戶界面的工具）或 PC 上的命令行界面工具來更改家中 Internet 網關設備上的 某些設置。儘管有些熱衷技術的用戶不會有很大困難，但許多用戶卻感到困難重 重。此外，許多用戶甚至不知道 NAT Traversal 問題正對其 Internet 服務的使用造 成干擾。用戶可能想體驗一種多玩家遊戲或使用其它某些對等服務，卻發現由於 某種原因而無法連接。這會導致用戶採取疑難解答步驟、尋求電話支持、感到不 滿，甚至以後不打算使用新的服務或不打算嘗試新的技術感受。

開發人員的工作： 為避免要求用戶手動解決此 NAT Traversal 問題，有些 Internet 網 關設備製造商已編寫出應用層網關支持，並將其包含到設備中。該應用層網關軟 件的設計思路是特殊的應用程序。換言之，設備製造商將編寫和測試特殊的代 碼，自動使一個應用程序完成 NAT。如果該應用程序軟件進行了更新，則設備制 造商所編寫的應用層代碼將必須重新進行更新和測試。當只需要考慮幾個對等或 相關的應用程序時，這種一對一解決 NAT Traversal 問題的方式對於設備製造商而 言是可管理的，但它無法對數百或數千個應用程序伸展自如，這時不僅開發成本 高，並可能需要有關這些應用程序各自原理方面的知識。解決該問題較好的方法 就是讓設備製造商為設備添加能理解 UPnP 的軟件或固件，然後讓其它設備和軟 件能利用同一技術與 NAT 設備進行通訊。現在只有 UPnP 能夠完成這種職責。

問：UPnP NAT Traversal 解決方案的作用是什麼？
答：支持 UPnP 的 NAT Traversal 可確保下列情況的實現：

多玩家遊戲
對等連接
實時通訊
遠程協助（Windows XP 的功能之一）

對於 IHV 而言，該解決方案免去了編寫和維護應用層網關 (ALG) 數據庫以通過 NAT 的必要。它受 Windows XP 和 Direct Play（一種 Windows 編程資源）的支持， 因此為 DPlay 編寫的軟件應用程序將能自動對 NAT Traversal 使用 UPnP 解決方 案。

通過提供下列操作的方法，UPnP 論壇的 IGD 規範可進行自動 NAT Traversal：

瞭解公用 IP 地址
列舉現有的端口映射
添加和刪除端口映射
指定映射的租用期

問：哪些製造商在實施 UPnP NAT Traversal 解決方案？
答：目前，大多數大型網關（DSL/電纜路由器）製造商都宣佈計劃從 2001 年（不遲 於 7 月份）在提供的產品中實施 UPnP NAT Traversal 解決方案。其中包 括：Microsoft（WindowsXP 中）、Linksys、D-Link、Intel、Netgear and Buffalo Technology 及 Arescom。

其中的一些製造商已宣佈將為已擁有其設備的用戶提供固件或軟件升級，從而為 支持 UPnP 的 NAT Traversal 提供支持。

問：用戶怎樣才能知道哪些 Internet 網關設備支持 UPnP？
答：用戶可以查閱 Internet 網關設備製造商的 Web 站點，或者閱讀產品包裝上的標 簽，以確定是否提供該功能。後面幾個月內，有些零售商將會知道這個情況。在 未來的幾個月中，UPnP 論壇會提供一個 UPnP 徽標。製造商可以在自己的產品包 裝、營銷資料或產品上包含該徽標，以表明該產品滿足 UPnP 論壇的測試要求。

問：開發人員實施該方案時有哪些可用的資源？
答：資源有很多，範圍從白皮書到互操作性測試事件 (PlugFests)。有關技術性的文 章，請訪問 http://www.upnp.org/resources.htm。有關未來的重大事件， 請參閱 http://www.upnp.org/events.htm。Microsoft 在 MSDN Online 上提 供有關 Windows XP 的開發人員信息。

http://www.upnp.org/logo.asp

[psac]

UPNP與網路相關

最近越來越多的用戶反映找不到UPnP設定，在這裡感覺有必要說明下。

什麼是UPnP？
UPnP是一個提供連接阜中轉的設備支持，注意UPnP只是一種硬體設備功能支持，而不是一種硬體。所以以後請不要問UPnP如何安裝，哪裡可以買等等問題。

哪些網路需要UPnP？
一般而言只有局內網需要UPnP，但不是所有局內網都能用得上UPnP。

局內網的概念是什麼？什麼屬於局內網？
局內網就是通過防火牆和主機或者路由，而不直接連線到Internet的網路。
下列網路屬於局內網：LAN（區域網路），WAN（城域網），小區網，服務機構企業內部網，校園網，路由網路，主機帶子機的共享網路，有線網路，視訊網（就是常說的Cable），部分無線網路……

哪些網路可能會找到UPnP？
一般而言，只有家庭路由組裝網路，路由網路，LAN有可能找到UPnP，像外網就肯定沒有而且不需要。校園網，服務機構企業網，小區雖然有UPnP，但是絕對不會讓你使用，且不開啟該功能。有線網，WAN，Cable，無線網這種需要ISP支持UPnP才可以使用，所以能正常使用的可能也不大。

[psac]

UPnP功能使用、BT連接阜映射、局內網外網之完全解析

一、UPnP的概念：

以下是微軟官方網站對UPnP的解釋：

問：什麼是 UpnP？
答：通用即插即用 (UPnP) 是一種用於 PC 機和智能設備（或儀器）的一般對等網路連接的體系結構，尤其是在家庭中。UPnP 以 Internet 標準和技術（例如 TCP/IP、HTTP 和 XML）為基礎，使這樣的設備彼此可自動連接和協同工作，從而使網路（尤其是家庭網路）對更多的人成為可能。
問：UPnP 對消費者意味著什麼？
答：簡單、更多選項和更新穎的體驗。包含通用即插即用技術的網路產品只需實際連到網路上，即可開始正常工作。實際上，UPnP 可以和任何網路媒體技術（有線或無線）協同使用。舉例來說，這包括：Category 5 乙太網電纜、Wi-Fi 或 802.11B 無線網路、IEEE 1394 ("Firewire")、電話線網路或電源線網路。當這些設備與 PC 互連時，用戶即可充分利用各種具有創新性的服務和應用程式。
問：UPnP 的技術要素是什麼？
答：UPnP 範圍廣泛，原因是它面向的是家庭網路、臨近網路及小型企業和商住樓中的網路。在網路控制設備的管理下，它支持任何兩個設備之間的資料通訊。UPnP 不依賴於特定的操作系統、編程語言或物理媒體。
UPnP 支持零組態網路及自動搜尋功能，這樣以來，設備即可動態加入網路，獲取 IP 位址，宣佈自己的名稱，根據需要提供功能，並瞭解其它設備的存在和功能。DHCP 和 DNS 伺服器為可選項。只要在網路上可用，即可加以使用。此外，設備還可自動平穩地脫離網路，而不會遺留任何不必要的狀態。
UPnP 汲取了 Internet 的成功之處並繼承了它的元件，包括 IP、TCP、UDP、HTTP 及 XML。UPnP 中涉及了多供應商之間的協作，旨在建立標準的設備控制傳輸協定 (DCP)。與 Internet 類似，這些傳輸協定以公告式線傳輸協定為基礎，表示為 XML 形式，且通過 HTTP 進行通訊。
以下是BC官方網站對UPnP的解釋：

UPnP（Universal Plug and Play），通用即插即用，是一組傳輸協定的統稱，不能簡單理解為UPnP=「自動連接阜映射」。

在BitComet下載中，UPnP包含了2層意思：
1、對於一台局內網電腦，BitComet的UPnP功能可以使網路閘道或路由器的NAT模組做自動連接阜映射，將BitComet監聽的連接阜從網路閘道或路由器映射到局內網電腦上。
2、網路閘道或路由器的網路防火牆模組開始對Internet上其他電腦開放這個連接阜。
我倒是覺得微軟的解釋過於理論化，適合寫入牛津大詞典；而BC官方網站的解釋過於含蓄晦澀。其實對於一般的使用者來講，簡單的把UPnP理解為自動連接阜映射就可以了。它就是一種關於TCP/IP傳輸協定的，針對設備彼此間的通訊而制訂的新的Internet傳輸協定，目的就是希望未來所有聯入Internet中的設備能夠不受網路閘道阻礙的相互通信。
二、哪些用戶需要用UPnP功能？
1、只有在需要使用一些支持UPnP功能的P2P軟體的時候，如BT、電騾eMule、MSN等，我們才需要考慮UPnP這個東東。如果你根本就不用這些軟體，僅僅是上網瀏覽的話，下文就沒必要看了；
2、如果你需要使用這些P2P軟體，但你是外網用戶，那麼下文也可以不看了，因為你不需要做什麼UPnP就可以正常使用這些P2P軟體了；
至於如何判斷自己是局內網用戶還是外網用戶，可以參考下面3樓：
關於寬瀕用戶是局內網還是外網之完全解析- -

3、如果你是局內網用戶，但你已經手動為這些P2P軟體進行了連接阜映射，如在使用BC下載時，在「用戶列表」中已經看到「遠端」，或者是使用電騾eMule連接伺服器成功後，已經顯示為高ID，那麼下文也可以不看了。
但需要注意的是，手動做的連接阜映射只是針對某個P2P軟體起作用，如果再使用新的P2P軟體的話，仍然需要針對新的P2P軟體做相應的連接阜映射才可以；
如何手動進行連接阜映射的方法可參考下面1樓：
ADSL MODEM連接阜映射方法詳解- -
4、如果你是局內網用戶，需要使用這些P2P軟體，而且並未進行手動連接阜映射，比如在使用BC進行下載時,「用戶列表」中只有「本機」而沒有「遠端」，在使用電騾eMule的時候，顯示的也是低ID，那麼此時我們才需要考慮連接阜映射的問題！
這時我們可以有兩種選項：
1、進行手動連接阜映射，方法參見上面第3點的連接文章；
2、開啟UPnP功能，進行自動連接阜映射，也就是我們下面所講的內容；
小結：UPnP自動連接阜映射的目的：
以BC為例，手動連接阜映射和自動UPnP連接阜映射都是為了獲得遠端連接，因此凡是在「用戶列表」裡看見了「遠端」的用戶，都不需要進行連接阜映射或是UPnP！UPnP和連接阜映射只需要取其一，他們相當於達到目的的2種不同的方法而已。
因此如果你的系統或者硬體不支持UPnP功能，大可不必傷心，按照第3點的連接文章中的方法手動做連接阜映射就可以了，效果是一樣的；
三、實現UPnP必須滿足哪些條件：
必須同時滿足3個條件：
1、Modem必須支持UPnP功能：是否具備此功能可查閱說明書或者直接咨詢廠家。一般來講，Modem還必須同時支持路由功能，除非你配備了單獨的路由器；
2、操作系統的支持：文章開頭提到的那篇介紹UPnP的文章中，提到只有windows xp系統才支持UPnP功能，但微軟的官方網站聲稱從Windows Me開始就已經支持UPnP功能了。但Windows Me這個操作系統我也沒有用過，大家可以自行測試；
3、軟體必須支持UPnP功能：如BC、電騾eMule、MSN等軟體都支持UPnP功能；
注意：以上3個條件必須同時滿足，缺一不可，否則你只能考慮進行手動連接阜映射了；
到此為止，我們開啟UPnP的工作才真正結束。
以BC為例，成功增加UPnP功能後，在「全局日誌」中我們會看到類似下面的幾行：
Windows XP UPnP Status: Found WAN Connection Device[Linksys Inc.] [http://www.linksys.com/
]
Windows XP UPnP Status: WAN IP: 218.30.*.*
Windows XP UPnP Status: Port Mapping Existed!
此時我們用BC進行下載，如果用戶列表中有「遠端」，或者用電騾eMule連接伺服器後顯示為高ID，那麼就大功告成了！

[psac]

Q:
關於UPnP和NAT Traversal
原來用NAT技術實現端口映射功能非常好理解，如把外部IP的80映射到內部ip的xx.xx.xx.8機器上面這樣就實現了外部能訪問這台機器了。
現在了的UPnP技術聽說每台機器都能實現類似功能不知道是什麼原理實現了。
看了此文章還是瞭解比較少。
http://www.microsoft.com/china/windo...howitworks.asp
如內網有N台機器只要打開了這個UPnP功能，就能實現N台機器同時下載eMule實現highID功能嗎？不知道是怎麼樣實現的，如外部一個程式發送一條信息連接默認的4662端口，現在問題就來了，網關怎麼知道這個消息是發給哪台機器的eMule端口 的呢？因為同裡運行了那麼多台機器使用eMule在下載東東
UPNP便不是同一端口對應的

A:
比如 外部ip的一個隨機端口(如16124)會對應到內部ip的 4662端口
這樣網關就可以識別了

Q:
那外部的程式怎麼知道我是這個端口呢？我的程式連接到對方的時候告訴他的？
難道原來是這樣的？如我的程式啟動的時候，發送一條消息給B，然後告訴b我的監聽的端口是1111，然後防火牆把我這個1111端口放在了外部的端口2222上面監聽，然後所以發給2222的資料都發給了我1111，這種方式不就是普通的NAT嗎？沒有發 現什麼區別呀，普通的QQ聊天接收信息應該也是這樣實現的。

A:
支持UPnP的客戶端軟件知道怎麼端口對應這麼一回事
當然也就可以告訴會話雙方

看下列文字，假設你對NAT/NAPT的工作原理瞭解。

UPnP廣播設備信息，啟動了UPnP的客戶端接受到這樣的廣播，可以發現網關設備，比如FTPRush啟動之後搜索網關設備就是這麼一個過程。實際上，並非客戶端主動搜索，而是被動接受廣播來發現網關。

UPnP支持NAT穿越可以分成兩個部分來理解:
(1) 一般性質的NAT是針對報文IP/TCP頭的處理，應用層的內容本不在NAT的處理範圍。但是很多應用程式，由於和服務器通信的需要，把本地IP/PORT地址信息放在應用層內容中，也就是TCP/UDP負載中。如果NAT不分析應用層內容，就無法替換這些本地IP地址為網關WAN地址，也無法替換這些本地PORT信息為網關分配的PORT。

針對這個問題，最早用ALG(Application Layer Gateway)來支持，可以理解ALG為NAT中的針對特定應用的插件，專門用來轉換TCP/UDP負載中的IP/PORT信息為網關WAN側對應的IP/PORT.

支持UPnP的網絡程式，比如說一個SIP客戶端或者MSN Messenger，可以向網關發出request，請求網關WAN子設備信息，來獲取網關WAN IP，這樣就可以直接把WAN IP封裝在應用層資料中。

(2) 如果我們把LAN->Gateway->WAN成為正向通信，那麼可以把WAN->Gateway->LAN稱為反向通信。前者，LAN的客戶端首先發起連接到WAN側服務器。後者，WAN側的機器首先發起連接到LAN側機器。

上一種情況描述的實際上是正向通信時，NAT處理在特定應用中失效後，兩種輔助處理的情況。

反向通信的時候碰到的問題更加大，如果LAN側機器不主動告知Gateway，如何翻譯WAN來得連接請求，那麼Gateway會丟棄WAN側的連接請求。

有兩種方式可以處理，一種是手工配置，在網關設備上配置映射關係。比如LAN側有一個FTP server, 那麼在網關上配置一個LANIP/PORT21<->WANIP/PORT21，當有WAN側請求連接WANIP的PORT21時，gateway直接把請求轉到LAN IP/PORT21上。

還有一種方式應用自動通過UPnP通知網關配置，比如你啟動一個支持UPnP的FTP程式，就可以通知網關打開特定的映射。

上面FTP的例子實際上並非是這種UPnP應用的典型案例，21端口是知名端口，兩台開在LAN中的FTP Server會競爭這個端口





我不知道emule的highid是什麼意思，很少用emule. 不過我知道"古銅"其實想瞭解的是第二種穿越的實現方式。


我試著舉例說明:

LA<->G<->WB

LA: LAN PC A
WB: WAN Server B
G: NAT Gateway

如上通信場景, 通信分下列幾步：
(1) LA->WB
LA發起TCP連接到WB, G正常翻譯這個請求；

(2) LA->WB, LA->G
LA在報文中告知WB，自己打開了1234UDP端口，可以接受WB的連接.
LA發出UPnP通知G, 自己準備打開1234端口，等待WB連接，(是否一定是WB來連接，這個要看LA上應用程式和NAT的具體實現)。

(3) WB->LA
WB發起UDP連接請求到LA 1234端口，G可以正常翻譯

Q:

問一個問題，現在內網ftpsever普遍都用nat來實行端口映射吧，如果沒有網關設置權限，可否利用UPnP，ftpsever支持UPnP現在有沒有?


A:
有，雷電
http://www.raidenhttpd.com/jlbb/viewtopic.php?t=6100


Q:
謝謝，用這個在內網建ftp，外網能訪問嗎？（沒有網關設置權限）
我剛才試了試，好像不行。

A:
當然，只要你的路由支持upnp，而且XP安裝了upnp支持。
沒問題，我前一段時間就用著，還給作者報了一個bug.
Q:
雷電的話，好像僅支持pasv的時候用upnp申請端口用於資料連接吧
因為upnp無法指定申請到的外部端口，也就沒法拿來用於控制連接的
A:
都可以的。控制端口、資料端口都可以自動映射。我親自實踐過的。沒有問題



MS的UPnP 組網步驟中的「尋址」部分明確闡述——「必須要將友好主機（設備）名稱解析為 IP 地址」，同時在「事件處理中」表示「為支持多個控制點，可將所有事件消息都發往各個預定者」，按照這一邏輯，在端口映射唯一性無法獲得保障的情況下，應該會產生某種未知衝突，但也不排除具體單一設備在解析後拋棄大量「他」包而獲取少量「己」包的可能，這種 模式下，網絡資源絕對處於浪費狀態下。

換一種思維邏輯，單以帶寬來看。以512K ADSL為例，按照eMule的規則，主機直接獲得highID，帶寬也就是80-110K左右，LAN用戶作為lowID能達到40-50K就已經很不容易了。假如UPnP真的可以實現全LAN的highID（我沒測試），帶寬問題也是無法突破的瓶頸。如果不考慮所有的缺點和浪費，唯一好處也不過就是highID的良好連接性；但即使是這樣，在帶寬面前，效果還要要打很大折扣。


以上觀點，未經實際環境測試；如有不當，敬請指教！謝謝！ ：）



Q:
可以這樣理由，在不支持UPnP的網絡環境和應用程式環境中，工作方式是

主機發送包到網關，然後網關修改資料包的源地址為Wan的某個地址，收到返回的資料包後把資料包修改源地址後轉發給內網的主機。

UPnP
主機發送包到網關，然後告訴網關我監聽1111端口，然後網關自動映射到外部端口的2222，以後和內網的主機的通信都是發到外網的2222端口。

從如上看出，普通的NAT應該不支持端口自動端口映射之類的，只能使用一些簡單的Http瀏覽，有了UPnP後就是多了可以自動端口映射，所以在沒有開通UPnP的情況下面我們是不能收到外部發過來直接連接到內部的資料包的，目前在關閉UPnP的情況下面 QQ這類軟件能正常通信和監聽端口是由於NAT裡面加了特定的代碼來支持的。如果支持UPnP的情況下面使用QQ發文件再也不會出現在不同防火牆後面的提示了。這是我的理解，不知道正不正確。

還有一個問題，就是樓上說的如果WAN端口1111是映射到內網的機器A，可是機器A關機了，在關機的時候應該不會告訴網關，這個時候網關還是會把1111端口的資料發送到機器A的，這個端口自動失效是怎麼樣實現的呢？如果端口失效後，但是外部的機器還是 不知道你這個端口失效了，然後繼續發送包到這個端口來聯繫機器A，此裡內網的機器b上網了，然後又自動映射了端口1111，這樣外部的機器發送的資料發給了機器B，這不就有可能產生問題嗎？
__________________


A:
TCP映射的話不會有這個問題，因為握手就無法通過。UDP的話存在這個問題。
但是這個映射存在問題和NAT是一樣的，非UPnP的NAT也有同樣的問題。這個問題在早先的非UPnP的NAT網關中已經解決（映射生存期）。

在映射生存期間，另一個客戶端想要申請到同樣的端口是不可能的。


總結一下我的觀點，需要說明一下，我沒有研究過UPnP的詳細規範，只是抓包分析了一下其的流程。所以有不到之處，請指出，謝謝。

(1) NAT(NAPT)主要是針對內網主動發起連接，替換IP和TCP/UDP頭，來達到共享一個IP地址的目的;
(2) NAT對於非內網主動發起連接的情況
- 手工在NAT上配置靜態映射
- UPnP
(3) NAT對於需要替換非IP, TCP/UDP頭內的IP/PORT信息的情況
- ALG
- UPnP
- Other application specific method, like STUN for sip

UPnP並非為了使得第一個NAT的主要工作模式得到提高，比如用HTTP訪問網頁，根本就不需要UPnP來支持。

顯然UPnP是一個比較好的方式，應用程式的升級，新應用程式的使用不需要NAT代碼上的改變，不需要NAT上針對每一個應用都寫一個ALG或者實現一個特定的穿越方案。

古銅所說的，我不知道我的理解對不對。不過光從字面上來理解，我覺得有所偏差。
引用 古銅
首先感謝樓上的朋友的解答：
可以這樣理由，在不支持UPnP的網絡環境和應用程式環境中，工作方式是

主機發送包到網關，然後網關修改資料包的源地址為Wan的某個地址，收到返回的資料包後把資料包修改源地址後轉發給內網的主機。

UPnP
主機發送包到網關，然後告訴網關我監聽1111端口，然後網關自動映射到外部端口的2222，以後和內網的主機的通信都是發到外網的2222端口。

網關不會再次映射這個端口為2222，因為這個1111是LAN PC和WAN SVR協商出來的端口，NAT是不能夠更改的，(除非輔助以ALG做特定的處理，把LAN通知SVR連接的報文中的PORT改成2222, 要不然SVR是不知道2222這個端口的)。

由LAN PC提出自己需要映射到WAN上的那個TCP/UDP端口上。所以我第一個回帖裡面說到，兩個FTP server會有競爭關係, 假設同一個LAN下PC 1和PC2同時發起UPnP的請求給網關, 要求映射WAN IP/PORT 21, 那麼肯定碰撞, 但是如果FTP server 支持配置映射關係, 就可以避免碰撞. 在一般應用下，比如說PC1，PC2同時使用QQ來發送文件，兩個QQ用TCP連接告知各自的對端自己在一個隨即分配的UDP端口上等待連接來發送文件，這兩個隨即分配的端口碰撞幾率很低。NAT可以處理這種請求。

實際上，我們並不擔心，有計劃，有預知的開放WAN 端口來讓外部主機主動連接，而是不知道該怎麼處理無計劃，不能預知的情況。

FTP Server屬於有計劃，有預知，你能夠知道自己打算把LAN的FTP服務映射到外部的哪個斷口上。QQ文件傳輸屬於無計劃，沒有預知的，你不知道，QQ打算讓對端在哪個端口上接收請求。


從如上看出，普通的NAT應該不支持端口自動端口映射之類的，只能使用一些簡單的Http瀏覽，有了UPnP後就是多了可以自動端口映射，所以在沒有開通 UPnP的情況下面我們是不能收到外部發過來直接連接到內部的資料包的，目前在關閉UPnP的情況下面QQ這類軟件能正常通信和監聽端口是由於NAT裡面 加了特定的代碼來支持的。如果支持UPnP的情況下面使用QQ發文件再也不會出現在不同防火牆後面的提示了。這是我的理解，不知道正不正確。


其實我不知道「端口自動映射"這種提法是否好，因為NAT在正常情況下都是自動端口映射的。但是在原料不夠的情況下（外部主動連接LAN內部主機），NAT無法創建socket映射。這樣的情況下需要另外的方法來干預。這些方法有些是自動的有些是手動的。或許叫自動反向端口映射更加合適。

UPnP和ALG都可以實現自動反向端口映射，ALG需要NAT理解特定應用的特定報文格式，碰到加密報文，和報文格式保密的情況，這樣很難做。所以UPnP很好的發揮了作用。不過上面也說到了，這樣UPnP不能決定分配給應用的WAN端口，這樣會產生碰 撞，即使幾率不大。

"目前在關閉UPnP的情況下面QQ這類軟件能正常通信和監聽端口是由於NAT裡面 加了特定的代碼來支持的。如果支持UPnP的情況下面使用QQ發文件再也不會出現在不同防火牆後面的提示了。"
你說的後面這段文字太精闢了，其實說起來就是這麼簡單的一回事情。我總在想，我是不是把問題說的太複雜了。。。。



不對
qq的nat穿越能也僅能用於udp協議上，因為udp是無連接的協議，所以當nat被qq打了個洞以後，另一端的qq可以從服務器知道這個洞的位置（iport），從而鑽進來。
nat並沒有針對qq或者什麼別的東西做過特殊設計。（iptables裡面好像有一個ftp的模塊，是用來自動更改ftp服務器的port/pasv指令的，這種才是特殊設計）


目前在關閉UPnP的情況下面QQ這類軟件能正常通信和監聽端口是由於NAT裡面 加了特定的代碼來支持的。如果支持UPnP的情況下面使用QQ發文件再也不會出現在不同防火牆後面的提示了。"

上面這段話說，為了支持QQ的文件傳輸，語音聊天之類的功能，需要在NAT裡面加入支持代碼(ALG)。其實真正是怎麼樣穿越的，我也不知道，加入ALG僅僅是其中一個方法。我想notXX想要說的是QQ不是這麼實現的，因為用iptable就可以支持Q Q的文件傳輸功能，而iptable中沒有專門處理NAT的代碼。

在這個層面上，notXX說的是對的。MSN/QQ/Yahoo Messnger等等很多軟件為了繞過NAT，都開發了相應的方式來穿越NAT. 因為NAT網關設備不是輕易升級的，依賴網關上加入支持代碼來穿越是非常不明智的，想要做個功能升級，協議裡字段變變都要升級網關設備的軟件。

其實這段話說有問題也可以，說沒有問題也可以，但是僅僅為了說明UPnP所起的作用來說，是沒有任何問題的。我認為主要是討論UPnP的穿越，也就不用太多涉入其他的穿越方式了。

但是你所說的
"qq的nat穿越能也僅能用於udp協議上，因為udp是無連接的協議，所以當nat被qq打了個洞以後，另一端的qq可以從服務器知道這個洞的位置（iport），從而鑽進來。"

也許你寫的太簡單沒有描述清楚你的意思，但是從字面來看，是不太好理解。你是不是想說QQ是復用命令socket和資料socket的？

UPnP為我們奉上了一道怎樣的大餐
http://www.slime2.com.tw/forums/show...highlight=upnp