NAT, P2P и мультиплеер
Как приложение может быть спроектировано таким образом, чтобы два партнера могли напрямую общаться друг с другом (при условии, что оба знают IP-адреса друг друга), но без исходящих соединений? То есть никакие порты не будут открыты. Например, это делает Bitorrent, но многопользовательские игры (насколько я знаю) требуют переадресации портов.
4 ответа
Я не уверен, что вы подразумеваете под "Нет исходящих подключений", я собираюсь предположить, что вы, как и все остальные, не имели в виду "Входящие подключения" (они стоят за NAT/FW/ и т. Д.).
Наиболее распространенным из упомянутых до сих пор является UPNP, который в этом контексте является протоколом, который позволяет вам как компьютеру общаться со шлюзом и передавать мне этот порт, потому что я хочу, чтобы кто-то снаружи мог общаться со мной. UPNP также предназначен для других целей, но это обычное явление для домашних сетей (на самом деле это одно из многих определений).
Есть также более распространенные и немного более надежные способы, если вы не являетесь владельцем сети. Самый распространенный из них называется STUN, но, если я правильно помню, есть несколько вариантов. В основном вы используете сторонний сервер, который позволяет входящим соединениям пытаться координировать канал связи. По сути, вы отправляете UDP-пакет своему партнеру, который откроет вам NAT для ответа, но будет сброшен на NAT вашего партнера (поскольку правила пересылки еще не существует). Через соединение с посредником им затем говорят сделать то же самое, что теперь открывает их NAT и соответствует существующему правилу в вашем NAT. Теперь связь может продолжаться. Это вариант этого, который также разрешит соединение TCP/IP, посылая сообщения SYN и SYN-ACK с некоторой координацией.
Статьи в Википедии, на которые я ссылался, содержат ссылки на соответствующие RFC для этих протоколов о том, как именно они работают. По сути, это сводится к тому, что нет простого ответа, так как это очень сетевая проблема.
Вам нужна где-то "точка встречи" в сети: участники "встречаются" у какого-то "шлюза", а упомянутая "функция шлюза" заботится о переадресации.
По крайней мере, это один из способов сделать это: я не буду пытаться комментировать детали Bittorrent... Я уверен, что вы можете поискать ссылки в Google.
UPNP можно использовать для согласования с маршрутизатором, чтобы открыть и переслать порт для вашего приложения. Даже бит-торрент требует, чтобы хотя бы один из пиров имел открытый порт для подключения p2p. Тем не менее, нет необходимости, чтобы оба узла имели открытый порт, поскольку они оба взаимодействуют с одним и тем же сервером (трекером), который позволяет им согласовывать и определять, кто имеет открытый порт.
Альтернативой является эхо-сервер / сервер ретрансляции где-то в Интернете, которому доверяют оба пира и который ретранслирует весь трафик. "Проблема" с этим решением заключается в том, что эхо-сервер должен иметь большую пропускную способность для размещения всех подключенных одноранговых узлов, поскольку он передает весь трафик, а не устанавливает p2p-соединения.
Проверьте EchoWare: http://www.echogent.com/tech.htm
UPNP занимался этим в основном в последние годы, но необходимость открывать порты связана с тем, что приложение было закодировано для прослушивания ответа от определенного порта.
Порты ниже 1024 называются "зарегистрированными", потому что им был присвоен номер порта, потому что компания заплатила за это. Это не означает, что вы не можете использовать порт 53 для веб-сервера или SSH, просто большинство будет предполагать, когда увидит, что имеет дело с DNS. Порты выше 1024 не зарегистрированы, поэтому нет никакой связи - ваш веб-браузер, будь то Internet Explorer/Firefox/etc, использует незарегистрированный порт для отправки запроса веб-серверу (-ам) Stackru на порт 80. Вы можете использовать:
netstat -a
... на хостах Windows, чтобы увидеть, какие сетевые соединения в настоящее время установлены, включая соответствующий порт.