原文版權：Copyright (C) The Internet Society (2003).All Rights Reserved.
原文地址：
http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt譯文版權申明：請引用此文的作者或網站注明出處：
http://blog.csdn.net/hxhbluestar，以尊重譯者的勞動成果！
隨著IPv6時代的到來，我也一直懷疑，是不是還有必要再去學習NAT技術——因為網絡的資源不再如IPv4時代匱乏，而NAT技術正是為解決IP地址的緊缺而存在的，如此，NAT便沒有存在的必要了。
但是，隨著這篇文章的翻譯，我的懷疑慢慢變成慶幸，漸而又變為肯定，通過翻譯所學到的東西，不再僅僅是翻譯第一手資料帶來的成就感，更多的是通過翻譯，去領悟技術前輩們的智慧與經驗，也通過翻譯，養成自己從第一手資料獲得信息的習慣，從而將視野放得更寬，讓理解更為透徹——至少，很多東西都是要經過仔細斟酌才真正轉化為自己思想的一部分的。正是如此，我才堅定的要把這篇文章翻譯完，也如之前所提到的，如果時間允許的話，我會用C#來寫一些例子，讓大家更好的理解NAT技術，掌握NAT技術（主要涉及到即時通訊、文件對等傳輸和語音應用三個方面）。
這篇文章主要是介紹一下“代理”機制的起因以及給P2P應用帶來的不便，不需要任何基礎知識：）
1. Introduction
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 ****istrator. 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 ****istration purposes. Subsequent to this, the hosts establish direct connections with each other for fast and efficient propagation of updates during 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應用程序。