Dima TBasil A. Sidorovпропущено...
HTTP это транспортный протокол. Что, собственно и закодировано в его аббревиатуре.
Уровень приложения - обработчики методов HTTP-запросов.
Хорошо. На порту 80 не обязан висеть web-сервер. Пусть даже он там висит, возьмем порт 12345, где висит самопальный сервис с собственным протоколом обмена, где никак не упомянуто к кому обращение... В общем я к тому что reverse proxy это один из костылей IPv4, он работает, его используют, но это фундаментальное нарушение модели OSI, где заявлено независимость уровней друг от друга. Вобщем грязный хак.

детский сад какой-то, господи.
необходимость reverse proxy это никакие не хаки, и не IPv4 костыли.

он нужен просто потому что

а) OpenSSL страшно дыряв, и его нужно изолировать от бекэнда. Бекэнд вообще ничего не должен знать про SSL
б) балансировать нагрузку как-то надо, выставлять в интернет целую кучу IP адресов напрямую - это клиника, кто между ними переключение будет делать при перегрузке?
в) отказоустойчивость обеспечивать тоже надо - кто еще, как не reverse прокци будет делать HA переключение, при помирании одной из нод бекэнда?
г) проблема медленных каналов у клиентов (3g, edge, v.42bis, гг) - зачем бекэнду (апач, с кучей памяти под PHP и т.п.) сидеть тратить время, ждать, пока клиент там выгребет свою порцию данных? бекэнд отдал фронтэнду ответ и пошел другого клиента обрабатывать, а прокси-фронтэнд с минимальными ресурсами (ему даже стек не нужен под каждый коннект) уже озаботится как
доставить ответ клиенту
д) gzip - тоже не дело бекэнда, как и поддержка этих ващих SPDY, HTTP 2.0 - весь этот треш даром не нужен на бекэнде (апаче)

дальше продолжать лениво

эти же правила останутся в силе и для IPv6, ничего не изменится.

при чем тут вообще IPv4?