Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.
Итак, тема многолога: Протокол 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.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Сюда же надо добавить лёгкую интергацию в существующую инфраструктуру: NAT, прокси, куча библиотек и модулей. Всё это не надо писать заново, а можно тупо воспользоваться.
_pk_sly wrote:
> S>HTTP > > Сюда же надо добавить лёгкую интергацию в существующую инфраструктуру: > NAT, прокси, куча библиотек и модулей. Всё это не надо писать заново, а > можно тупо воспользоваться.
Ещё элементарно добавляется s к концу... https то бишь.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
S>Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.
S>Итак, тема многолога: Протокол HTTP и его немерянная крутизна.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
Не то, что бы я возражал, но просто для полноты картины: какие еще протоколы, кроме POP3/SMTP/FTP еще рассматривались как конкуренты HTTP и таки проиграли HTTP?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
> Ну а если то, что вам нужно отдавать на клиента, лежит в готовом виде в > файловой системе, то опередить современный HTTP сервер вряд ли > удастся. Потому что редкий хардкорный программист рискнет писать свой > драйвер режима ядра — а именно это делает, к примеру, IIS 6 и новее.
А при чем здесь "лежит в готовом виде в файловой системе"? Для того,
чтобы отсылать готовое файло, есть функция TransmitFile. А IIS'овский
http.sys, если верить MS, занимается слудующим:
• Routing HTTP requests to the correct request queue.
• Caching of responses in kernel mode.
• Performing all text-based logging for the WWW service.
• Implementing Quality of Service (QoS) functionality, which includes
connection limits, connection timeouts, queue-length limits, and bandwidth
throttling
Т.е., непосредственно к оптимизации передачи относится, насколько я понимаю,
"Caching of responses in kernel mode". Причем сделано это, очевидно, в
первую голову для кэширования динамического контента — статический и так FS
закэширует.
Posted via RSDN NNTP Server 2.1 beta
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Sinclair, Вы писали:
S>Есть несколько применений, для которых HTTP неоптимален. В частности, двусторонний стриминг медиа будет на нем работать не слишком хорошо, хотя односторнний работает только в путь.
А как насчёт двухстороннего общения (но не стриминг медиа). Например jabber с его XMPP, который постоянно держит TCP/IP соединение. Или общение а-ля COMET однозначно лучше?
Здравствуйте, Sinclair, Вы писали:
S>Раз уж тут пошла такая пьянка, как выносить в корневые темы свои ничем не подкрепленные мнения, я тоже отмечусь. А потом буду на этот пост ссылаться.
S>Итак, тема многолога: Протокол HTTP и его немерянная крутизна.
Здравствуйте, Sinclair, Вы писали:
S>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно. Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут. Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов. Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
Здравствуйте, Pzz, Вы писали:
Pzz>Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно. Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут. Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов. Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
А какой протокол позволяет послать одновременно несколько запросов через одно соединение?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Pzz, Вы писали:
HB>>А какой протокол позволяет послать одновременно несколько запросов через одно соединение?
Pzz>Самодельный.
А, все понял. Не совсем "несколько запросов одновременно"; просто возможность послать следующий запрос, не дожидаясь ответа на предыдущие, так?
What a piece of work is a man! how noble in reason! how infinite in faculty! in form and moving how express and admirable! in action how like an angel! in apprehension how like a god! the beauty of the world! the paragon of animals!
Здравствуйте, Curufinwe, Вы писали:
C>Зачем же сразу велосипеды? C>Можно XMPP например использовать.
Здесь, по-моему, надо соотносить свои потребности с имеющимися возможностями, и не впадать в крайности. С одной стороны, глупо изобретать самодельный HTTP. С другой стороны, не менее глупо пытаться загнать в рамки существующего протокола то, что в эти рамки не лезет. Конкретный выбор протокола очень зависит от задачи. Но обсуждать достоинства/недостатки существующих протоколов тем не менее осмысленно.
Здравствуйте, Pzz, Вы писали:
C>>Зачем же сразу велосипеды? C>>Можно XMPP например использовать.
Pzz>Здесь, по-моему, надо соотносить свои потребности с имеющимися возможностями, и не впадать в крайности. С одной стороны, глупо изобретать самодельный HTTP. С другой стороны, не менее глупо пытаться загнать в рамки существующего протокола то, что в эти рамки не лезет. Конкретный выбор протокола очень зависит от задачи. Но обсуждать достоинства/недостатки существующих протоколов тем не менее осмысленно.
Конечно зависит от задачи. Голову ведь никто ещё не отменял . Просто зачастую, если хорошо поискать, можно найти готовый протокол с существующей реализацией, который подходит на 99%
Здравствуйте, Pzz, Вы писали:
Pzz>Его самый существенный недостаток заключается в том, что HTTP использует отдельный TCP connection на каждый запрос, а TCP разгонается медленно.
HTTP/1.1 поддерживает keep-alive
Pzz>Про то, что соединение можно не рвать, я в курсе, но по-моему, в не-www-ных применениях как правило все его рвут.
ну значит сами себе злобные буратины.
Pzz>Но даже если не рвать, то HTTP не позволяет послать одновременно несколько запросов.
Еще как позволяет.
Схема такая:
Посылаешь первый запрос с заголовком connection: keep-alive
Если сервер ответил утвердительно то ты можешь послать все остальные запросы не дожидаясь ответа от сервера.
А потом получить ответы на них в томже порядке в котором послал.
Pzz>Поэтому HTTP работает медленно, если использовать его для коротких запросов с небольшим количеством возвращаемых данных.
Если keep-alive не использовать.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, eao197, Вы писали:
E>Не то, что бы я возражал, но просто для полноты картины: какие еще протоколы, кроме POP3/SMTP/FTP еще рассматривались как конкуренты HTTP и таки проиграли HTTP?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, Sinclair, Вы писали:
S>>Так вот, я открою страшную тайну: HTTP — это один из лучших на сегодняшний день сетевых протоколов прикладного уровня. S>>Архитектуры находящихся примерно на том же уровне протоколов POP3 и SMTP рядом не валялись. Про FTP я вообще молчу.
E>Не то, что бы я возражал, но просто для полноты картины: какие еще протоколы, кроме POP3/SMTP/FTP еще рассматривались как конкуренты HTTP и таки проиграли HTTP?
1. "Самописанные", т.е. нестандартизованные протоколы
2. Бинарные RMI/Corba
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sergey, Вы писали:
S>Т.е., непосредственно к оптимизации передачи относится, насколько я понимаю, S>"Caching of responses in kernel mode". Причем сделано это, очевидно, в S>первую голову для кэширования динамического контента — статический и так FS S>закэширует.
Нет. На всякий случай напомню, что FS кэширует дисковые страницы. А в httpResponse уезжают вовсе не они. Например, response может быть пожат gzip-ом.
Фишка в том, что статический контент отдается без перехода в user mode. Три драйвера договариваются между собой в режиме ядра.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
