Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.

Итак, тема многолога: Протокол HTTP и его немерянная крутизна.

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

Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня.
Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.

Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.

Миф номер 1: Протокол HTTP обладает избыточностью, из-за того что он текстовый.

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

Обычно те, кто делает подобные м.1. заявления, подразумевают "вот если бы я реализовал свой протокол, то ух я бы сделал его супероптимальным".
Вот это — тоже миф. Дело в том, что в HTTP уже встроены возможности по оптимизации, до которых обычно у "творцов протоколов" никогда не доходят руки. Например, кэширование, частичная передача контента (т.н. докачка), и компрессия данных. В итоге, с учетом этого, зачастую реальное приложение, построенное поверх http, потребляет меньше трафика, чем "TCP/IP" аналог.

Миф номер 2: Так ведь клиент там будет тяжеловесный. Вот то ли дело сокет.

Я, если честно, не мерил, сколько ресурсов отжирает WinInet. Но ничего в нем ракетного нет. Если есть острое недоверие к стандартной реализации клиента, велком — никто не запрещает открыть сокет на порт 80, послать стандартный реквест, и получить нужный респонс. В некоторых особо торжественных случаях это и есть самый кошерный способ — естественно, если нет нужды поддерживать редиректы, компрессию, кэширование, куки, и прочие вещи, традиционно встроенные в http-клиента.

Если под "тяжеловесным клиентом" понимается веб-браузер, то надо понимать, что во-первых, он нужен только для человека. Программному клиенту браузер не нужен. А альтернативный клиент, который будет внутри себя обрабатывать HTTP, будет ненамного эффективнее, чем браузер (и уж точно менее распространен).

Миф номер 3: Ага! Клиент-то может и маленький, а сервер? Он же тормозит!

Ну, вообще-то, смотря какой сервер, и что понимается под "тормозит". Обычно, stateless HTTP сервер рвет аналогичный по функционалу сервер с удержанием соединения как тузик грелку. Потому, что HTTP клиент работает в "импульсном" режиме: сбегал к серверу (за 40 миллисекунд), и тупит локально, до следующего запроса. Редкий пользователь кликает ссылку ежесекундно.
(Если ваше приложение не укладывается в эту схему — упс, надо подумать над альтернативой, HTTP скорее будет неидеален)
Если удерживать соединение в таком "импульсном" приложении, то пользователь держит занятыми на пару десятичных порядков больше ресурсов, чем нужно.

Ну а если то, что вам нужно отдавать на клиента, лежит в готовом виде в файловой системе, то опередить современный HTTP сервер вряд ли удастся. Потому что редкий хардкорный программист рискнет писать свой драйвер режима ядра — а именно это делает, к примеру, IIS 6 и новее.

Миф номер 4: Ну и ладно. Мне всё равно недостаточно чистого HTTP, а значит придется строить свой протокол.

Не совсем. Большинство из того, чего вам не хватает, в HTTP либо предусмотрено (см. RFC 2616), либо предусмотрен способ расширять протокол. Таким образом, сохраняются все преимущества готовой реализации, но при этом необязательно ограничиваться ею. Ваш контент лучше сжимать не gzip, а каким-нибудь fluxe? Ок, пусть клиент передает его в Accept-Encoding, а сервер научится передавать в нем. Если к вам придет старая версия клиента, вам не надо думать, как это понять и передать ей контент в несжатом виде.
Вам не нравится digest authentication? Отлично, придумайте свой протокол и включите его в negotiation.

Напоследок порекомендую для ознакомления книжку O'Reilly "RESTful Web Services" для осознания того, как правильно строить свои протоколы на базе HTTP.