res2001

PHP будет медленнее, конечно же, но на сколько критично оценить трудно. Т.к. в этой задаче основные задержки будут приходится на системный ввод/вывод, а не на работу самой программы.
Если хорошо знаете PHP, то реализуйте сначала на нем, оцените производительность и решите надо ли переписывать на плюсах.

1. Маршрутизаторов может быть много. Например, сеть большого предприятия, где используется несколько подсетей + доступ в интернет. На какой именно маршрутизатор должен отправлять пакет хост, предназначенный не для своей сети?
2. Маршрутизаторы добавляются в систему то же через таблицу маршрутизации. Для шлюза по умолчанию в таблице маршрутизации добавляется маршрут для сети 0.0.0.0 (т.е. все адреса).

Кстати, комп с виндой, даже не с серверной виндой, вполне может выступать в качестве маршрутизатора, т.к. винда умеет в маршрутизацию.

При биндинге можно указать вместо адреса константу INADDR_ANY (0.0.0.0) - т.е. все доступные адреса, тогда программа будет слушать указанный порт на всех адресах, доступных ОС.
Адрес 127.0.0.1 (или любой из подсети 127.0.0.0/8) назначают, обычно тогда, когда сервис должен работать только в рамках локальной машины. Например у вас есть обратный прокси на nginx и пара сайтов на apache. Прокси будет слушать внешний адрес на 443 порту, а сайты вполне могут слушать 127.0.0.1 и принимать подключения только от прокси.

По умолчанию роутеры настроены так, что их нельзя админить с WAN порта. Но это можно изменить настройками.
Но не советую этого делать, т.к. ... Когда ты последний раз обновлял роутер? Как часто это делаешь? Роутеры то же ломают.
Можно поднять на роутере ВПН и админить роутер через ВПН.

Согласен с ответом chupasaurus
Но даже если не принимать во внимание broadcast адрес, то если в сети нет свободных адресов - это говорит о том, что нельзя легко добавить дополнительные узлы в сеть. А это плохо в большинстве случаев. На практике в рабочих (и домашних) сетях никогда такого не встречал. Нормально, когда 10-20% адресов свободны (в домашних условиях и малых сетях свободны обычно 95% адресов). Если количество свободных адресов <5%, то стоит задуматься о разделении сети или увеличении маски.

Вы с другом находитесь в одном городе?
Если да, то, по идее, вы находитесь в одной провайдерской сети. Задержки должны быть минимальными при доступе друг к другу.

Сделайте traceroute (tracert/mtr) с обоих компов друг к другу, сравните вывод, посмотрите через какие адреса проходит трафик в обоих случаях. Где происходят самые большие задержки. В нормальном состоянии трафик должен идти через одни и те же промежуточные хосты и даже может не выходить за пределы провайдерской сети. Если набор промежуточных хостов сильно различается, то возможно провайдер криво маршрутизирует трафик и он в одном из случае идет по какому-то не оптимальному маршруту. Если на одном из узлов с одной стороны задержки приемлемые, а с другой высокие - явно что-то не то с этим узлом.
Можно звонить в поддержку и попытаться объяснить ситуацию, давя на проведенное вами исследование. Как минимум пожаловаться на неадекватные задержки внутри провайдерской сети.

Для большей достоверности traceroute стоит запустить несколько раз, получить несколько показаний тестов и усреднить их.

Как только ты дашь доступ из интернета к этому приложению по советам выше, приложение сразу же начнут ломать.
Если приложение изначально не создавалось для работы в интернете, то скорее всего рано или поздно в нем найдут баг и сломают. А дальше может быть что угодно: внедрение шифровальщика/вымогатора, использование твоего компа в бот сети и т.п. не приятные вещи.

Поэтому для приложений, предназначенных для использования в относительно безопасной локальной сети, стоит использовать ВПН, а не прямой доступ из интернета.

Надо "разлогиниться" и залогинится пользователем 2.

Взаимодействие между уровнями - это детали реализации.
Тот же TCP/IP можно реализовать очень по разному с разными интерфейсами для прикладного приложения.
Наиболее распространенное сейчас сетевое API это Berkeley Sockets (или просто сокеты). Сокеты реализуют в т.ч. и взаимодействие по TCP/IP. Есть и другие сетевые API, например TLI, но я никогда в реальности не встречал его использования.
Сетевое API - это то с помощью чего прикладной программист использует сеть. Внутри тех же сокетов есть свои интерфейсы для передачи между сетевыми уровнями.

Если хотите прокачать скилы в администрировании фаервола, то ставьте ту же голую Ubuntu или FreeBSD и тренируйтесь.
Если такой цели нет, то берите готовый продукт, с GUI. Вполне подойдут все тут предложенные (и железные и софтовые) и еще пачка других может найтись.
Если в конторе есть развернутая виртуальная инфраструктура, то корп.фаервол можно реализовать на ВМ, это достаточно удобно, плюс все плюшки от виртуализации.
На мой взгляд софтовый вариант более гибок, т.к. кроме функций фаервола он может быть и корпоративным ВПН сервером, и внешним почтовым сервером и прокси. Совмещать функции или нет на одном железе - это уже другой вопрос. Любые готовые решения не в состоянии предоставляют "полной" гибкости, конечно.

Кто вам сказал, что больше 0xFFFF TCP соединений нельзя принять? Видимо вы сделали этот не правильный вывод исходя из того, что номер порта - двухбайтовое целое? Но в случае принимающей стороны будет использоваться один и тот же порт (который открыт для прослушивания) для всех принятых соединений.

ко мне делают запросы каждый комп. с интернетом во всем мире одновременно

Хочу напомнить, что, например, Ethernet - последовательный канал. В один момент времени по нему может передаваться только один пакет данных, все остальные либо встанут в очередь где-то на промежуточном маршрутизаторе, либо будут отброшены, когда очередь переполнится. То же самое касается и оптических линий и прочего. Так что из всего мира только первый счастливчик прорвется, остальные будут курить в сторонке пока ваш комп принимает первый пакет.

Сам по себе UDP, как писали предыдущие отвечающие, не предполагает подтверждения получения пакета, поэтому он и работает быстрее - меньше накладных расходов. Видимо из-за этого и кем-то считается, что он не подвержен DDoS. Но! Многие приложения, работающие через UDP строят поверх UDP свой собственный протокол, который может гарантировать доставку даже поверх UDP. Например OpenVPN. В этом случае DDoS вполне сработает.
Вообще DDoS атака направлена на то, что принимающий сервис не сможет обработать корректный запрос. Это может произойти по нескольким причинам:
1. принимающий сервис умер из-за большого количества запросов или настолько загружен, что начал пропускать запросы.
2. канал связи забит левым трафиком и нормальные запросы не могут прорваться. При этом сам сервис может чувствовать себя прекрасно - трафик в канале может быть произвольный, не обязательно направленный именно на этот сервис.
Оба варианта - успех DDoS атаки. При этом второму варианту пофигу какой протокол использует сервис и есть ли у него гарантия доставки. Важно то, что сервис не получит корректного трафика, что то же будет успехом DDoS.

Проще всего использовать роутер, который умеет использовать одновременно 2 внешних линии. Чаще всего в простых роутерах с поддержкой резервирования канала одна линий рабочая, вторая резервная, т.е. не используется. Вам же нужно использовать одновременно обе линии, так что роутер нужен соответствующий. Конкретную модель не подскажу.

Подобный маршрутизатор можно собрать и самому, если очень хочется. Собирал такое в свое время на FreeBSD с использованием принципов policy based routing в тамошнем фаерволе ipfw и множественных таблиц маршрутизации. По моему, аналогичную штуку можно реализовать и на Linux, но тут я не в курсе. Дело это не легкое, требует серьезного погружения в тему и знаний работы IP протокола, принципов маршрутизации, используемого фаервола.
Видимо нечто подобное реализовано по ссылке в ответе ValdikSS
На винде сделать это из коробки нельзя. Возможно есть какое-то стороннее ПО для этого.

Если смотреть только на Ethernet, то он представляет плоскую сеть, где все узлы равноправны и могут обмениваться трафиком друг с другом на прямую без всякой маршрутизации. Ethernet ничего не знает о других сетях. Для него есть только одна сеть.
Поэтому для взаимодействия между разными сетями нужен более высокоуровневый протокол, который позволяет отличить адреса "своей" сети, от "чужих" адресов (обеспечивает маршрутизацию между сетями). Это IP. Датаграммы IP вкладываются в поле данных Ethernet.
Над IP есть TCP и UDP. TCP гарантирует доставку пакетов, UDP - не гарантирует. Общее между ними то, что оба протокола позволяют идентифицировать конечные приложения на хосте получателя и отправителя по номерам портов. Сам по себе IP не позволяет этого делать, для него конечной точкой является хост в сети, средств идентификации приложений внутри хоста в IP нет. TCP и UDP пакеты вкладываются в поле данных IP пакета.
Ну и далее поверх TCP и UDP куча прикладных протоколов, которые решают какие-то специфические задачи. Эти прикладные протоколы точно так же вкладываются в поле данных протоколов TCP или UDP.

И нет никакой конвертации и преобразования, просто пакет вышележащего протокола является данными для пакета нижележащего протокола (инкапсуляция). Про инкапсуляцию смотри аналогию CityCat4 о картошке.

Все зависит от того какой кабель. В роутере обычно разъемы Ethernet (8 или 4 жильный кабель с разъемом RJ45) и в них можно сунуть только Ethernet (ни оптику, ни телефонную линию, и т.д.).
Если в квартиру заходит что-то отличное от Ethernet, то требуется устройство, которое будет преобразовывать один тип сигнала в другой (например оптику в Ethernet, или DSL в ethernet), отсюда появляются дополнительные устройства на входе в роутер. Эти дополнительные устройства не всегда называются модемами, для оптики, например, устройство имеет более общее название медиа конвертер (преобразователь интерфейсов). Модем это то же медиа конвертер.
Бывают модели роутеров, которые имеют внешний порт не Ethernet (оптика, DSL). Такие роутеры, как правило, используются именно там где входящая линия именно этого типа. Тогда, конечно, дополнительное устройство не требуется.
Так же часто на входе уже имеется Ethernet, тогда такой кабель можно напрямую втыкать в роутер, без посредников.

Вай-фай он разный. Есть несколько стандартов, отличающихся скоростью.
Когда устройство подключается к вай-фай оно определяет по какому из стандартов будет работать. Определяется это в т.ч. в зависимости от внешних факторов, например от уровня сигнала, от количества помех и т.п.
Если у вас много вай-фай точек в округе, то все они засирают одно и то же эфирное пространство и мешают друг другу, что снижает скорость передачи данных. Так что далеко не факт, что в ваших условиях ваше оборудование сможет выдать максимально возможные для него скорости.
Обычно для обхода этой проблемы применяют двухдиапазонные роутеры (ну и клиентские устройства само собой), которые могут работать еще и на частоте 5 Ггц. Такие устройства стоят дороже, а потому встречаются реже и соответственно меньше помех создают друг другу на частоте 5 ГГц. Но, опять же, далеко не факт, что в ваших условиях это как-то вам поможет.