Почему nat требуется, когда прокси достаточно? [закрыто]

Моя машина подключена по локальной сети. Для подключения к интернету трафик идет через прокси-сервер. Насколько я понимаю, прокси- сервер отправляет запрос от имени отправителя исходного запроса. Поэтому, когда сервер отвечает, он отправляет ответ прокси, думая, что это клиент. Затем прокси пересылает ответ на мою машину.
Возьмите случай трансляции сетевых адресов . Ваш запрос проходит через роутер nat. Затем маршрутизатор nat предоставляет вам публичный IP-адрес и сохраняет это отображение в своей таблице. Ответ (с сервера) отправляется на этот назначенный публичный адрес. Какой маршрутизатор nat разрешает ваш локальный IP-адрес из таблицы и пересылает ответ на ваш компьютер.
Мой вопрос, почему nat требуется, когда сам прокси-сервер может опосредовать трафик и предоставить вам доступ к Интернету?

MadHatter написал превосходное непрофессиональное объяснение различий между прокси и NAT.

Для получения более подробной технической информации я предлагаю вам ознакомиться с моделью OSI и моделью TCP / IP. Nat работает на более поздней 3 модели OSI (сетевой уровень, в данном случае IP), а прокси обычно работают на 7-м уровне (прикладной уровень, HTTP или все, что вы используете).

NAT и прокси тоже пытаются решить несколько разные проблемы. NAT скрывает несколько частных IP-адресов за меньшим количеством общедоступных IP-адресов, чтобы уменьшить нехватку IP-адресов, в то время как прокси-серверы создают «точку пересечения» сети по соображениям безопасности, аудита или производительности.

Мне кажется, что вы здесь хорошо поняли основы, и короткий ответ таков: если вы используете прокси с публичным адресом, вам не нужен NAT - для протоколов, опосредованных прокси. ,

Однако на небесах и на земле больше протоколов, чем вы мечтали в вашей философии ; не все из них являются проксимальными, и прокси-серверы не существуют даже для всех, поэтому NAT является для них удобным резервным вариантом.

Изменить : прокси-сервер является вычислительным устройством, которое работает на уровне приложения. HTTP-прокси получает HTTP-запросы для удаленного сайта, и, как вы указали, он сам отправляется на этот сайт, делает запрос и передает ответ запрашивающему клиенту. Но для этого он должен понимать HTTP на детальном уровне.

Точно так же вы можете написать прокси-сервер FTP, но он должен понимать детали команд MKD, DELE, LIST и т.п., таких как протокол FTP, чтобы правильно проксировать запросы клиента. Любой прокси-сервер, который хочет работать прозрачно, обычно должен хорошо понимать внутреннюю часть протокола, чтобы прокси-протокол этого протокола.

SOCKS является в некоторой степени исключением из этого правила, но это потому, что протокол SOCKS создает более общий интерфейс для проксирования, требующий, чтобы каждый клиент был SOCKSified, и, следовательно, способен делать правильные запросы прокси-сервера SOCKS, чтобы установить вид прокси, который требует каждый, который не совсем прозрачен.