Здравствуйте, Mamut, Вы писали:
M>Search Engine Optimization
Это следовало бы назвать SEF — Search Engine Fooling. Идиотичное по самой своей природе занятие, которое рано или поздно неизбежно отомрёт. (Не знаю как, но бесконечно жить и здравствовать оно просто не имеет права.)
Здравствуйте, Игoрь, Вы писали:
И>Не согласен, можно даже сказать — категорически не согласен. Во-первых, текстовый протокол избавляет тебя от некоторых платформенных различий, вроде little/big endian, тех же выравниваний.
Угу, чтобы избавиться от особенностей какой-то одной платформы сделаем его неперевариваемым для всех. У нас это называют "ни себе ни людям".
И>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему.
Давайте тогда не останавливаться на половине пути и сделаем текстовыми еще и исполняемые файлы вместе с базами данных. Вообще отлаживать просто будет.
И>Возможно я вымирающий вид, но я до сих пор использую telnet клиент для тестов и отладки, очень удобно (в случае текстового протокола).
Для тестов и отладки можно (и нужно) написать отладочный инструмент. А эти отладочные "удобства" в мир выпускать не нужно. Вы исполняемые файлы, собранные в "target: debug", тоже распространяете?
И>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто кна ура, а можно и автогенераторами воспользоваться.
Какие проблемы есть лично у меня я уже написал, а вы поскипали.
И>В общем, мой опыт говорит о том, что по-умолчанию нужно использовать текстовый формат, и только в случае крайней необходимости — бинарный.
Прошу считать мой случай крайней необходимостью.
Здравствуйте, Mamut, Вы писали:
M>Думаю, Михаил (misha_irpen) за такие запросы туда-сюда просто порэжет на куски, да
Не обязательно
Я бы предложил так: при подключении, еще до запроса, сервер сразу компактно говорит клиенту что ему нужно (FTP/SMTP, вон, тоже сразу клиента привествуют и не рассыпаются). А клиент уже формирует свой запрос исходя из этих данных. Причем я бы еще сделал так, что если клиент положил в заголовок больше чем его просили, совсем отказывать в обслуживании этого запроса, ибо нефиг.
Здравствуйте, misha_irpen, Вы писали:
S>>Во-вторых, HTTP устроен так, что "не надо платить за то, чего не используешь". Если модные сервисы от него не нужны, то накладные расходы на заголовки HTTP близки к нулю. _>Небольшая мысль вслух того, кто чувствует эти нулевые накладные расходы ежемесячно.
_>Сервер линеечек (картинки такие для женских форумов, показывают временную шкалу в виде симпотичного изображения): обрабатывает запрос GET и в ответ отдает небольшой GIF. Никаких модных сервисов, все просто как три копейки. Входящий трафик в месяц -- более ста гигов. Еще раз: СТО ГИГАБАЙТ ЗАГОЛОВКОВ HTTP! А если бы заголовки были бинарными, то этот объем можно было бы сократить в разы, если не на порядок. Вот такие накладные расходы на заголовки HTTP, близкие к нулю...
Вы бы вместо прикладной гигантомании указали количество запросов и объёмы исходящего трафика. А то я могу и на бинарке сотни терабайт накопать:)) И ещё расскажите, какую долю эти картинки составляют от общего объёма страницы.
_>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей. Это то же самое, что использовать в программе исключительно строковые переменные. Только неопытным новичкам такое простительно (еще PHP-шникам с JS-никами, но у них и выбора-то нет), а тут нате вам, парсите текст, переводите числа в строки а строки в числа вместо того чтобы просто взять и считать несколько байт в соответствующий контейнер. Зачем? Неужели до сих пор кто-то думает что пользователь сам будет вводить текст запроса? Может он еще и TCP-фрейм должен руками вбить?
Затем, что автоматически получается гибкость, расширяемость, простота диагностики, а таки да — и ручной ввод запроса, где это надо (для отладки). А Вы расскажите, сколько будет стоить альтернатива, обеспечивающая все основные возможности HTTP. Только не фиксированной структурой, а хотя бы чем-то вроде ASN.1 BER. Сколько места она сожрёт и насколько сложно будет разбирать это всё в случае проблем.
Здравствуйте, Shabi, Вы писали:
S>Здравствуйте, misha_irpen, Вы писали:
_>>Я вообще не понимаю этого тяготения к текстовым данным. Хоть убей.
S>...эти все подлянки из юниксов вестимо...задолбало такое наследие
Вот не надо с больной головы на здоровую переваливать.
Юниксоеды отлично знают, где нельзя текст применять. А также знают, чем хорошо его применять там, где можно.
Здравствуйте, netch80, Вы писали:
N>Вы бы вместо прикладной гигантомании указали количество запросов и объёмы исходящего трафика.
Тут уже писал: http://rsdn.ru/forum/message/2904051.1.aspx
N>И ещё расскажите, какую долю эти картинки составляют от общего объёма страницы.
Страницы как таковой нет, 99.999% запросов к серверу идут из <img src=..., расположенных на левых сайтах.
N>Затем, что автоматически получается гибкость, расширяемость, простота диагностики,
размер, необходимость парсинга.
N>а таки да — и ручной ввод запроса, где это надо (для отладки). А Вы расскажите, сколько будет стоить альтернатива, обеспечивающая все основные возможности HTTP. Только не фиксированной структурой, а хотя бы чем-то вроде ASN.1 BER. Сколько места она сожрёт и насколько сложно будет разбирать это всё в случае проблем.
Я не готов просто взять и немедленно предложить бинарную альтернативу, я просто указал на живой пример поблемы, связанной с текстовой рулезностью HTTP.
T>Кстаааааати, исполняемые файлы говорите... Хм, пойду оформлю патент... А, блин, это ж называется распространением в исходниках.
Нееееее!
Я предложил сделать текстовыми именно исполняемые файлы. Или другими словами повсеместно перейти на скрипты (и даже процессоры заставить испольнять эти скрипты непосредственно).
Здравствуйте, misha_irpen, Вы писали:
_>Здравствуйте, Игoрь, Вы писали:
_>Угу, чтобы избавиться от особенностей какой-то одной платформы сделаем его неперевариваемым для всех. У нас это называют "ни себе ни людям".
Бред. Вот как раз в случае бинарного протокола и будет: "ни себе ни людям". Ты вообще представляешь себе, что такое переносимый и расширяемый бинарный протокол прикладного уровня? Хоть с одним из них разбирался и работал? Тебе в любом случае придется делать маршалинг/анмаршалинг параметров, только в случае с текстом это будет гораздо проще и сделать можно в любой среде, а вот с бинарными данными — облом-с. Единственное преимущество бинарных протоколов — скорость. Которая нивелируется современными техническими средствами.
И>>Во-вторых, серьезно упрощает отладку, когда достачно взглянуть на сессию, чтобы идентифицировать проблему. _>Давайте тогда не останавливаться на половине пути и сделаем текстовыми еще и исполняемые файлы вместе с базами данных. Вообще отлаживать просто будет. _>Для тестов и отладки можно (и нужно) написать отладочный инструмент. А эти отладочные "удобства" в мир выпускать не нужно. Вы исполняемые файлы, собранные в "target: debug", тоже распространяете?
Блин, да причем здесь бинарные и исполняемые файлы? К исполняемым файлам совсем другие требования, и не надо их сюда приплетать.
Кроме отладки есть еще поддержка, мониторинг и пр. Для текстового протокола я могу написать простой тестовый скрипт (или простенький клиент) практически на любом языке под любой платформой, админ может сделать тоже самое, в случае же бинарного протокола перспективы не радужные.
И>>С парсингом текста вообще никаких проблем не вижу, если протокол грамотно спроектирован — пишутся легко и просто кна ура, а можно и автогенераторами воспользоваться. _>Какие проблемы есть лично у меня я уже написал, а вы поскипали.
И какие, 100 месячных гиг? не смеши.
Здравствуйте, Игoрь, Вы писали:
_>>Угу, чтобы избавиться от особенностей какой-то одной платформы сделаем его неперевариваемым для всех. У нас это называют "ни себе ни людям". И>Бред.
Ну бред так бред. Чего с бредящим споришь-то? Я свою точку зрения высказал, а доказывать свое здравомыслие не собирался ни секунды.
Здравствуйте, misha_irpen, Вы писали:
_>Здравствуйте, netch80, Вы писали:
N>>Вы бы вместо прикладной гигантомании указали количество запросов и объёмы исходящего трафика. _>Тут уже писал: http://rsdn.ru/forum/message/2904051.1.aspx
5%. В общем, не цифра. А извращённые хостеры... ну да, бывают. Им же надо стероиды применять, чтобы крутыми казаться.
N>>И ещё расскажите, какую долю эти картинки составляют от общего объёма страницы. _>Страницы как таковой нет, 99.999% запросов к серверу идут из <img src=..., расположенных на левых сайтах.
Эти img src на каких-то таки страницах. Но я понял.:)
N>>Затем, что автоматически получается гибкость, расширяемость, простота диагностики, _>размер, необходимость парсинга.
Обратите внимание, что раньше 5-го уровня OSI текст не применяют. Вот там действительно критично. А на верхних, как Вы заметили — 5%. Редко где больше. Зато читается.
А вот про необходимость парсинга — см. ниже.
N>>а таки да — и ручной ввод запроса, где это надо (для отладки). А Вы расскажите, сколько будет стоить альтернатива, обеспечивающая все основные возможности HTTP. Только не фиксированной структурой, а хотя бы чем-то вроде ASN.1 BER. Сколько места она сожрёт и насколько сложно будет разбирать это всё в случае проблем. _>Я не готов просто взять и немедленно предложить бинарную альтернативу, я просто указал на живой пример поблемы, связанной с текстовой рулезностью HTTP.
Ну вот именно, что предложить альтернативу Вы не можете, зато проехаться тяжёлым танком — сколько угодно. Думаете, остальные не знают, что текст надо парсить и что это проблема? Мне SIP с этими заморочками уже снится. Но когда я пытаюсь нарисовать, как бы выглядел протокол, который в этом плане сильно легче — получаются совсем уже нецензурные монстры. В лучшем случае это тот же BER.
Здравствуйте, misha_irpen, Вы писали:
T>>Кстаааааати, исполняемые файлы говорите... Хм, пойду оформлю патент... ;) А, блин, это ж называется распространением в исходниках. :-\ _>Нееееее! :) _>Я предложил сделать текстовыми именно исполняемые файлы. Или другими словами повсеместно перейти на скрипты (и даже процессоры заставить испольнять эти скрипты непосредственно).
В какой-то мере это происходит. Например, с явой или дотнетом и JIT. Но для "нативного" приложения — смысла нет именно потому, что в 99% систем файл мапится в память и должен быть по возможности временно отмаплен (когда VM чистит память). С тем, что парсится, так не получится. Не думаю, что Вы этого не знаете. Но — продолжаете ёрничать.:(
говорится о 100 гигабайтах заголоков ХТТП. Какую долю они составляют от общего трафика _>Более 5% (еще примерно столько же заголовочного мусора уходит в каждом ответе, в итоге имеем около 10% оверхеда). Однако дело в том что хостинг-провайдеры ой как не любят входящий трафик! Лютой ненавистью ненавидят просто. И их можно понять, ведь входящий трафик это прямые обытки, в отличии от исходящего.
То есть, главное — это входящий. Предположим что бинарный формат представления будет занимать где-то в 5 раз меньше места. Тогда выигрыш от его использования будет экономия 4% входящего трафика. Так ли это критично?
То есть понятно, лишнее — да, но вроде это не составляет кардинальной разницы даже в данном случае...?
говорится о 100 гигабайтах заголоков ХТТП. Какую долю они составляют от общего трафика _>>Более 5% (еще примерно столько же заголовочного мусора уходит в каждом ответе, в итоге имеем около 10% оверхеда). Однако дело в том что хостинг-провайдеры ой как не любят входящий трафик! Лютой ненавистью ненавидят просто. И их можно понять, ведь входящий трафик это прямые убытки, в отличии от исходящего. F>То есть, главное — это входящий. Предположим что бинарный формат представления будет занимать где-то в 5 раз меньше места. Тогда выигрыш от его использования будет экономия 4% входящего трафика. Так ли это критично?
Что-то я не уловил мысль. Входящий трафик на 100% состоит из HTTP-заголовкаов, а это значит что уменьшение их объема в пять раз, во столько же раз уменьшит эту составляющую (именно она является основной проблемой при поиске подходящего хостера).
F>То есть понятно, лишнее — да, но вроде это не составляет кардинальной разницы даже в данном случае...?
Средний рамер отдаваемого файла -- 15 килобайт, тут заголовок не так критичен, но тут и страфиком проблем меньше.
Здравствуйте, misha_irpen, Вы писали:
F>>То есть, главное — это входящий. Предположим что бинарный формат представления будет занимать где-то в 5 раз меньше места. Тогда выигрыш от его использования будет экономия 4% входящего трафика. Так ли это критично? _>Что-то я не уловил мысль. Входящий трафик на 100% состоит из HTTP-заголовкаов, а это значит что уменьшение их объема в пять раз, во столько же раз уменьшит эту составляющую (именно она является основной проблемой при поиске подходящего хостера).
Странная у Вас арифметика, какая-то сферическая в вакууме.
Если считать обычный GET состоящим из 450 байт (это я скормил своему браузеру URL на картинку и померял его) — на один запрос будет израсходовано:
1. TCP SYN — 46 байт
2. TCP ACK — 38 байт
3. GET — 40+450 байт
4. ACK на ответы сервера — ну раз картинки маленькие, посчитаем 5 ACK'ов по 38 байт
5. ACK на FIN сервера — 38 байт (считая, что сервер закрыл соединение первым)
Это я всё взял из реального tcpdump'а.
Если считать трафик по IP, то служебного содержания — 328 байт. (328+90)/(328+450) == 0.537..., то есть все безумные усилия по 5-кратному сокращению HTTP заголовка запроса дадут менее чем двукратное (46%) сокращение входящего трафика. Если трафик считается по Ethernet, то ещё хуже (ко всем размерам прибавить 14 и размер меньший чем 64 заменить на 64) — будет всего 35% сокращения.
А теперь попробуем вычислить, что сделать с протоколом, чтобы он все эти интересные подробности типа
во всех их видах сжал в 5 раз. Я не представляю себе, как это сделать.:)) Ну максимум полтора раза, и то — с натяжкой.
А полуторакратное сокращение GET'а даст 20% экономии входящего трафика. Стоит ли это той борьбы? Может, лучше просто пользоваться менее жлобским хостером?
Текстовые конфигурационные файлы, при всех их недостатках, обладают одним несомненным достоинством: на них можно посмотреть глазками и поправить обычным текстовым редактором. Их можно сравнивать diff'ом и хранить историю изменений в source control system. По ним можно сказать grep. В общем, с ними можно проделывать все те штуки, которые можно проделывать с обычным текстом.
Точно так же текстовые протоколы, при всех их несостатках, обладают одним существенным достоинством: на них можно посмотреть глазками, и понять, что происходит. Можно поговорить с сервером телнетом (вручную) и получить осмысленную реакцию.
Не надо считать юниксоидов полными идиотами. В конце концов, многие вещи пришли именно оттуда, а это что-нибудь да значит.
Здравствуйте, netch80, Вы писали:
N>Если считать обычный GET состоящим из 450 байт (это я скормил своему браузеру URL на картинку и померял его) — на один запрос будет израсходовано:
Вот из этих 450 байт и набегает 100-130 ГБ в месяц.
N>Ну максимум полтора раза, и то — с натяжкой.
А данному сервису все эти мегаинтересные подробности, простите, нафиг не упали. Если бы протокол был еще и адаптивным, то вероятно это решило бы проблему.
N>А полуторакратное сокращение GET'а даст 20% экономии входящего трафика. Стоит ли это той борьбы? Может, лучше просто пользоваться менее жлобским хостером?
Тут все в деньги упирается, сервису нужно не менее 2.5 ТБ суммарного трафика в месяц, а при нежлобском хостере это вываливается в сумму, которая выше дохода от рекламы. Вот такая сферическая арифметика...
Здравствуйте, Pzz, Вы писали:
Pzz>Не надо считать юниксоидов полными идиотами. В конце концов, многие вещи пришли именно оттуда, а это что-нибудь да значит.
Идиотами? Да вы что! Лично мне некоторые юниксоидные вещи очень нужны и в виндах (например меня сильно "расстраивает", когда программа не понимает параметров командной строки). Но все перечисленные вами удобства хороши на этапе отладки, а в реальной эксплуатации от них немало проблем добавляется.
Здравствуйте, misha_irpen, Вы писали:
N>>Ну максимум полтора раза, и то — с натяжкой. _>А данному сервису все эти мегаинтересные подробности, простите, нафиг не упали. Если бы протокол был еще и адаптивным, то вероятно это решило бы проблему.
И как? Особенно без лишнего round-trip'а.
А, блин, это ж называется распространением в исходниках. 
