A. NAT打洞 必須要有一個公網的IP嗎
隨著IPv6時代的到來，我也一直懷疑，是不是還有必要再去學習NAT技術——因為網路的資源不再如IPv4時代匱乏，而NAT技術正是為解決IP地址的緊缺而存在的，如此，NAT便沒有存在的必要了。
但是，隨著這篇文章的翻譯，我的懷疑慢慢變成慶幸，漸而又變為肯定，通過翻譯所學到的東西，不再僅僅是翻譯第一手資料帶來的成就感，更多的是通過翻譯，去領悟技術前輩們的智慧與經驗，也通過翻譯，養成自己從第一手資料獲得信息的習慣，從而將視野放得更寬，讓理解更為透徹——至少，很多東西都是要經過仔細斟酌才真正轉化為自己思想的一部分的。正是如此，我才堅定的要把這篇文章翻譯完，也如之前所提到的，如果時間允許的話，我會用C#來寫一些例子，讓大家更好的理解NAT技術，掌握NAT技術（主要涉及到即時通訊、文件對等傳輸和語音應用三個方面）。
這篇文章主要是介紹一下「代理」機制的起因以及給P2P應用帶來的不便，不需要任何基礎知識：）
1. Introction
1、簡介
關鍵詞：
middleboxe(s) —— 我翻譯成「代理」，也許有更好的翻譯
host —— 我翻譯成「主機」，希望大家不要理解成伺服器了，主機就是一台普通的終端機
Present-day Internet has seen ubiquitous deployment of "middleboxes" such as network address translators(NAT), driven primarily by the ongoing depletion of the IPv4 address space. The asymmetric addressing and connectivity regimes established by these middleboxes, however, have created unique problems for peer-to-peer (P2P) applications and protocols, such as teleconferencing and multiplayer on-line gaming. These issues are likely to persist even into the IPv6 world, where NAT is often used as an IPv4 compatibility mechanism [NAT-PT], and firewalls will still be commonplace even after NAT is no longer required.
在當今的Internet中，普遍存在使用「代理」設備來進行網路地址轉換（NAT），導致這種現象的原因是 IPV4 地址空間的資源耗盡危機。雖然不對稱 asymmetric 的地址分配和連通性制度已經在代理中被定義，但是卻給端對端應用程序和協議制定造成了一些特殊的問題。像電話會議和多媒體網路游戲。這些問題即使在IPV6世界中還是會存在，因為NAT作為IPV4的一種兼容性機制經常被使用[NAT-PT]，並且防火牆將仍然將普遍存在，即使不再需要NAT技術。
Currently deployed middleboxes are designed primarily around the client/server paradigm, in which relatively anonymous client machines actively initiate connections to well-connected servers having stable IP addresses and DNS names.
Most middleboxes implement an asymmetric communication model in which hosts on the private internal network can initiate outgoing connections to hosts on the public network, but external hosts cannot initiate connections to internal hosts except as specifically configured by the middlebox's administrator. In the common case of NAPT, a client on the internal network does not have a unique IP address on the public Internet, but instead must share a single public IP address, managed by the NAPT, with other hosts on the same private network.The anonymity and inaccessibility of the internal hosts behind a middlebox is not a problem for client software such as web browsers, which only need to initiate outgoing connections. This inaccessibility is sometimes seen as a privacy benefit.
當前使用的「代理」技術主要是為 客戶端/服務端 C/S 結構設計的，為了實現那些需要連接但是又沒有固定IP地址的客戶端能夠連接到一台配置好的擁有固定IP和DNS域名的伺服器。
大多數的「代理」使用一種 asymmetric 通信模型，即 私網（區域網） 的主機能發起一個「外出」連接去連接公網上的主機。 但是公網上的主機卻無法發送信息給私網上的主機（除非對「代理」進行特殊的配置），NAPT（網路地址埠轉換）的普通情況是，一個私網客戶端不需要一個公網的固定的IP地址，但是必須要共享一個由NAPT控制的公網的固定IP地址（當然這個NAPT是處於同一個私網內部的）。這樣的話，這些匿名的並且看起來難以觸及的藏在NAT之後的內網主機對於像 Web瀏覽器 這種軟體來說就不是一個問題,因為內網的主機只需要發起向外部的連接就可以了。這樣一來，無法觸及也還是有他的優點的——那就是具有保密性。
In the peer-to-peer paradigm, however, Internet hosts that would normally be considered "clients" need to establish communication sessions directly with each other. The initiator and the responder might lie behind different middleboxes with neither endpoint having any permanent IP address or other form of public network presence. A common on-line gaming architecture, for example, is for the participating application hosts to contact a well-known server for initialization and administration purposes. Subsequent to this, the hosts establish direct connections with each other for fast and efficient propagation of updates ring game play.
Similarly, a file sharing application might contact a well-known server for resource discovery or searching, but establish direct connections with peer hosts for data transfer. Middleboxes create problems for peer-to-peer connections because hosts behind a middlebox normally have no permanently usable public ports on the Internet to which incoming TCP or UDP connections from other peers can be directed.
RFC 3235 [NAT-APPL] briefly addresses this issue, but does not offer any general solutions.
然而，在P2P的應用中，Internet上的「客戶機」之間是需要建立一個通信會話直連的。邀請者和響應者也許會處於不同的NAT之後，也許他們都沒有固定IP或者即使有也不是公網的IP地址。舉例來說，在一個普通的網路游戲體系結構中，都是通過客戶端向一個具有公網固定IP的伺服器發起申請進行初始化並通過驗證的。同時，客戶端之間也要建立直連，才使網路間傳輸的速度加快，保證數據即時更新（不然搶不到裝備啊，呵呵）。
同樣的，一個文件共享應用程序也必須通過到一個伺服器上去查找它想要的資源，然後再到擁有這個數據的主機上去下載（BT網站，走了一個中介），「代理」造成了很多P2P直連的問題，因為藏在「代理」之後的的主機通常沒有固定的埠來使其他的客戶端發起的TCP或UDP連接能夠最終到達。
RFC 3235[NAT-APPL] 簡要的提到了這個問題，但是沒有給出任何的解決方案。
In this document we address the P2P/middlebox problem in two ways. First, we summarize known methods by which P2P applications can work around the presence of middleboxes. Second, we provide a set of application design guidelines based on these practices to make P2P applications operate more robustly over currently-deployed middleboxes. Further, we provide design guidelines for future middleboxes to allow them to support P2P applications more effectively. Our focus is to enable immediate and wide deployment of P2P applications requiring to traverse middleboxes.
在這篇文章中，我們用兩種方式討論 P2P/代理 的問題。首先，概要的講敘已有的P2P應用程序能夠在現有的代理機制中的工作原理。然後，我們提供一組應用程序設計指南，基於已有的實踐，在現有的配置好的代理上，來使得P2P應用程序操作更加有條理。最後，我們提供了設計指南，為以後的代理機制能夠更方便支持P2P應用程序。討論的焦點是如何 直接的、廣泛的 配置那些需要經過「代理」的P2P應用程序。
Peer-to-Peer (P2P) communication across middleboxes（術語篇）
2. Terminology
2. 術語
In this section we first summarize some middlebox terms. We focus hereon the two kinds of middleboxes that commonly cause problems for P2P applications.
在這一章節中，首先概要的介紹一下「代理」技術的一些術語。然後集中討論兩種造成P2P應用問題的代理機制。
Firewall
A firewall restricts communication between a private internal network and the public Internet, typically by dropping packets that are deemed unauthorized. A firewall examines but does not modify the IP address and TCP/UDP port information in packets crossing the boundary.
防火牆
防火牆限制了私網與公網的通信，它主要是將（防火牆）認為未經授權的的包丟棄，防火牆只是檢驗包的數據，並不修改數據包中的IP地址和TCP/UDP埠信息。
Network Address Translator (NAT)
A network address translator not only examines but also modifies the header information in packets flowing across the boundary, allowing many hosts behind the NAT to share the use of a smaller number of public IP addresses (often one). Network address translators in turn have two main varieties:
網路地址轉換（NAT）
當有數據包通過時，網路地址轉換器不僅檢查包的信息，還要將包頭中的IP地址和埠信息進行修改。以使得處於NAT之後的機器共享幾個僅有的公網IP地址（通常是一個）。網路地址轉換器主要有兩種類型：
Basic NAT
A Basic NAT maps an internal host's private IP address to a public IP address without changing the TCP/UDP port numbers in packets crossing the boundary. Basic NAT is generally only useful when the NAT has a pool of public IP addresses from which to make address bindings on behalf of internal hosts.
基礎NAT
基礎NAT 將私網主機的私有IP地址轉換成公網IP地址，但並不將TCP/UDP埠信息進行轉換。基礎NAT一般用在當NAT擁有很多公網IP地址的時候，它將公網IP地址與內部主機進行綁定，使得外部可以用公網IP地址訪問內部主機。（譯者註：實際上是只將IP轉換，192.168.0.23
B. 有沒有C# TCP 穿透，NAT打洞，實現客戶端與外網伺服器端的連接的代碼 有的話可不可以我私聊給
伺服器都已經在外網了，還有打什麼洞，穿什麼透，客戶端直接連就行了
C. C#UDP穿越NAT，UDP打洞，UDP Hole Punching源代碼，該怎麼處理
首先要有一個沒有nat的公網伺服器,
每個用戶使用一個埠與伺服器通訊回 ,伺服器在收到用戶連入答請求後把用戶的標識符跟用戶的埠號匹配保存起來
當另一個用戶請求該用戶時把該用戶對應的埠號返回 然後用戶之間互相用指定埠號聯系 就是打洞了
伺服器要維系連接要定時發心跳包
D. 使用nat打洞，筆記本電腦連有線時，打洞成功，連接無線cmcc或者手機流量開的熱點時打洞失敗，為什麼
連接上了CMCC或者wifi，手機開的熱點是用手機的數據流量。
手機沒有辦法可以中繼wifi網路的信號，手機開啟熱點信號，必須連接手機的數據流量才能作為熱點使用。
E. 關於JAVA實現NAT打洞技術缺乏公網伺服器的問題。
NAT 一般ip好確定，找個查看ip地址的網站，像 ip138 之類的，就可以看到外網ip，但是埠可能每次訪問都會變化的。
F. 沒有公網IP還能實現nat打洞嗎 如果有能說說方法嗎謝謝
能的 搜一下p2p udp 穿透
G. NAT打洞是什麼
就是NAT的埠映射問題。
H. java tcp nat 打洞
既然知道原理了就按照原理寫唄，tcp打洞關鍵要能地址復用
I. NAT 公網打洞 想要別人訪問我私網的埠
很難實現啊，學校應該都有防火牆的，你能登陸那個防火牆去允許B來訪問你的版機器嗎？權就是在防火牆創建個策略，B來訪問你的機器在加埠號（不同的訪問對應不同的埠號，如ftp用21、遠程連接用3389等）。就舉個在你機器上建立FTP的伺服器讓B來訪問。個人比較喜歡serv-u的軟體，安裝好，如果你電腦是私有地址的話直接映射出去，然後給別人賬號密碼就行了。前提是在防火牆允許的情況下
J. pc服務端和Android客戶端之間通信怎麼實現NAT打洞
我們做的是用代碼實現的，通過HTTP協議，或者TCP協議也是可以的