Pull to refresh

Comments 59

Ещё один школьник, который не чистит ботинки, и считает, что поэтому крем для обуви не нужен.
Неделя заразная что ли?

Автор, а вы не желаете рассмотреть на предмет ненужной информации пакеты протокола TCP/IP?
Я конечно понимаю, кризис и все такое… Но неужели вы действительно надеетесь много сэкономить на спичках?
Не выдвигалась идея что-либо менять в протоколе http.
Хотелось донести, что избыточной информации много, и не зря разработчики из Yahoo советуют минимизировать число запросов (совет номер 1).
Соверт номер 1 никак не связан с вашими наблюдениями. Там совсем другая идея. Если у вас скорость соединения 100Mbit (норма в наше время), а время доступа к сайту 50ms (у среднего сайта больше), то за время установления соединения вы можете передать 500 килобайт данных! Вот и всё: устанавливать соединение не дорого, а очень, очень, ОЧЕНЬ дорого — независимо от того, что вы потом по нему будете передавать и какая у вас будет избыточность.

Конечно браузер может посылать несколько запросов одновременно (4-8 обычно), но это не меняет общей картины: большинство страниц содержат больше элементов даже при всех ухищрениях…
Уточнение — браузер открывает 2 соединения, и передаёт ресурсы по ним последовательно (современные браузеры — 6 соединений).

Типичный сценарий: загружаем хабр (72 ресурса). Firefox тратит 50ms на открытие 6 соединений (паралллельно), и передаёт в среднем по 12 ресурсов по каждому.
Типичный сценарий: загружаем хабр (72 ресурса). Firefox тратит 50ms на открытие 6 соединений (паралллельно), и передаёт в среднем по 12 ресурсов по каждому.
На запрос ресурса при открытом соединении как раз и тратится 50ms. На само открытие соединения уходит больше времени (грубо говоря вдвое больше). Но это уже тонкости.
Accept-Language – есть смысл передавать для указания языка по умолчанию для многоязыковых сайтов. Практически это значение используется сайтами крайне редко, и даже такие гиганты как google используют геолокацию (geoIP) для определения языка отображения.

Здесь вы не правы, гугл использует Accept-Language
А так же есть много сайтов до сих пор использующих Russian Apache и реагирующих на Accept-Charset. А уж сколько сайтов реагируют на User-Agent…

В общем обычное замечание что если бы всё что до этого наработано выкинуть на помойку и начать заново — можно сделать лучше. Пока Закон Мура действует — делать это бессмысленно.
Суть в том, что все современные браузеры поддерживают все кодировки.
Хаос который творится с User-Agent, подробнее описан на хабре раньше.

Не призываю менять существующие наработки, вы меня неправильно поняли.
http является расширяемым протоколом с огромной поддержкой софта и железа — уходить от него было бы глупо.
На самом деле не совсем так. Периодически надо переосмысливать старые технологии, с учетом появившихся новых. Иногда окажется что действительно многое лучше выкинуть на помойку, заменив на что-то другое. Впрочем это уже не относится к теме поста.
Пока закон Мура в силе — смысла в этом нет. Единственный вариант: открытие новой «ниши» где новые технологии смогут развиться до уровня, позволяющего вытеснять старые. Фронтальная атака практически невозможна и бессмысленна.
Запрос HTTP/1.0 и того меньше:
GET / HTTP/1.0
Что — даже Host не нужен?

Странно, что вы по заголовкам ответа не прошлись. Предлагаю упростить до следующего:

GET / HTTP/1.1

HTTP/1.x 200 OK
на чём и закончить, погрузившись в нирвану и счастье от экономии трафика…
Конечно не нужен. HTTP 1.0 не поддерживает виртуальный хостинг т.е. на одном ip может размещаться только один сайт
Он поддерживает, только в нём эта фича опциональна.
А как в таком случае сервер различит к какому хосту идет обращение?
Тот, к которому было открыто подключение на 80й порт.
Видимо, в 1996 ещё не придумали VirtualHost и прокси.
Но топик-то этот написан не 13 лет назад, а сегодня. Можно считать, что для нормальной работы «сегодня» заголовок Host обязателен.
HTTP 1.0 с тех пор не изменился и все сервера что-нибудь да выдают если не указывать Host…
Да не, я понимаю, что будет выдан default host. Спрашивал я для того, чтобы уточнить — может чего забыл и есть еще какой то способ указать домен к которому идет обращение.

«Что-нибудь» — это явно не то, что нужно :))

Понятно, что протокол не менялся и по стандарту host не обязателен, но согласитесь, времена изменились и без него трудно было бы пользоваться интернетом :)
Да и без Accept-Encoding, Cookie и Connection: keep-alive сегодня тоже было бы сложновато.
Очень просто — к тому единственному, который он обслуживает. Когда HTTP протокол разрабатывали никто не думал о том, что имя домена будет чем-то важным, за что будут бороться. Считалось что есть машина, у неё есть имя, на ней лежат документы, к которым нужно иметь доступ — вот и всё. Зачем же ещё раз указавать машине как она называется — она что, дурная? Вот когда Internet начал коммерциализироваться и в дело вступили маркетологи — тогда и стала понятна проблема с таким подходом.

Заметим что в FTP эта «проблема» до сих пор не решена — и ничего, работают ftp-сервера как-то…
5.2 Request Header Fields


Request-Header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of request
header fields if all parties in the communication recognize them to
be request header fields. Unrecognized header fields are treated as
Entity-Header fields.

Протокол допускает любые заголовки, просто не регламентирует их и не требует понимания системами. Это я и имел ввиду: HTTP/1.0 не запрещает использовать заголовок Host, и он становится опциональным, если на обоих концах системы его поддерживают.
Что — даже Host не нужен? Не нужен и, более того, невозможен. Это расширение, разработанное Netscape'ом и, стоит признать, поддерживающееся практически всеми браузерами и серверами. Но в HTTP/1.0 его нет и указывать его на практике не обязательно.
Хабр идиот. Я не просил дописывать http в начале! gopher://gopher.floodgap.com/1/new
хе… Опера 9,63 не умеет работать с Сусликом… раньше вроде умела…
Он не видит никакой сетевой активности. А сам FF открывает хорошо.
Я тут подумал… А ведь XHTML тоже чрезвычайно избыточен! Закрывающие теги, например, в большинстве случаев не нужны, их можно смело выкинуть. Кавычки вокруг значений атрибутов — тоже лишний трафик! И кому сдался этот DTD, и без него все прекрасно работает!

Думаю, внедрив эти улучшения (для простоты назовем их HTTP 3 и XHTML 3), мы получим ускорение интернета чуть более чем в зиллион раз!
UFO just landed and posted this here
19 ресурсов с морды — ха!
Чтобы сделать запись в ярушечку грузится >300 документов. с лагами, заголовками и так далее
merlin@fathers ~/test $ curl -i habrahabr.ru/new/ > body+headers
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 83523 0 83523 0 0 137k 0 --:--:-- --:--:-- --:--:-- 206k
merlin@fathers ~/test $ curl -I habrahabr.ru/new/ > headers
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
merlin@fathers ~/test $ ls -l
итого 92
-rw-r--r-- 1 merlin family 83717 Фев 8 11:15 body+headers
-rw-r--r-- 1 merlin family 194 Фев 8 11:16 headers

Заголовки занимают примерно 0.2% от объёма страницы.

Автор, боритесь лучше с избыточностью в html (метаданные — 80%), tcp (метаданные в обе стороны — не менее 0.5%).
Вы загрузили один ресурс большого объёма (html страница).
Когда же вы загружаете страницу в браузере, запрашивается множество (обычно) мелких изображений.

html — избыточность прекрасно убирается засчёт сжатия страницы + gzip сжатие (Transfer-Encoding).
tcp — высокоэффективный бинарный протокол, бороться бесполезно.
Заметьте, я привожу реальные цифры, вы до сих пор — только какие-то домыслы.

Давайте будем деловыми людьми — подкрепите свои утверждения статистикой. Например, по той же странице хабра, которую скачивал я, но со всеми ресурсами.
Не путайте заголовки запроса с заголовками ответа.
Если открыть эти 74 ресурса в IE (~460 байт на запрос), получим 33Кб передаваемых данных. Из них полезная инфоррмации (сам url + необходимые заголовки) составляет до 30%. Получаем 70% избыточности.
Уход от ответа (=слив) засчитан.
Кстати говоря, про заголовки запроса.

Они-то идут по ИСХОДЯЩЕМУ для клиента (и входящему для сервера) каналу, которые практически всегда относительно мало загружены. Что толку от их оптимизации, если бутылочное горлышко и так не там?

Исправлять надо самое слабое звено цепи, и это в данном случае не исходящий наружу канал.
ага, а про соотношение 1 к 10 или 1 к 20 (исходящего канала к входящему для пользователя) забываем?
Какое такое соотношение?

У пользователя если ADSL — получается соотношение 1/8, ADSL2 — 1/24 (в пределе, в реальности ни разу не видел это число меньше 1/15, 1/10 — реальная цифра), ADSL2 Annex M — в пределе 1/10, в реальности — получается порядка 1/8-1/5.

Для других способов связи — скажем, набирающий популярность Ethernet — для пользователя соотношение 1/1.

Для сервера, который как правило стоит на площадке хостинга, это соотношение также 1/1.

если у вас есть данные по числе пользователей того или иного типа соединения — будет весьма любопытно посмотреть.

В реальности Ethernet ограничивают на уровне провайдера.
И Ethernet делают асимметричным? Никогда не слышал. Обычно наоборот.

У меня вот — ADSL, и мой канал сделали симметричным: хотя модем поднимает 2800kbps DS/900kbps US, на провайдере мне режут внешку до 800/800, согласно тарифу.

В нашем регионе, г. Воронеж + Воронежская область — подавляющаее большинство ADSL. Я знаю только про самого крупного провайдера — примерно 60000 абонентов ADSL, Ethernet/FTTx они только готовятся запустить. Все остальные — мельче, и у них тоже в общем преобладает ADSL.
Ну с полпроцента в TCP бороться как то несолидно :)
может, стоит помножить 0,2% на число ресурсов? 304-ответов может быть весьма много
Может. В любом случае, нужно измерять, а не домысливать, какой там получится трафик полезный, а какой — холостой.

Где измерения, покажите? Я не верю домыслам.
Мы про время загрузки или про объём данных говорим? Это разные вещи.

Там речь про время загрузки. На время загрузки влияет не только скорость канала и число элементов страницы, а также и задержка канала. Для ADSL ставится как правило алгоритмическая задержка на пакеты 20мс (чтобы соединение было стабильнее), и соответственно, он ВСЕГДА будет грузить страницы медленнее Ethernet, в котором такой задержки нет.

Кстати говоря, авторы той статьи — не очень хорошо разбираются в технологиях связи и их особенностях. Они совсем не учитывают эту особенность ADSL.
А для, скажем, спутника, та же самая задержка невообразимо больше (порядка секунд), и соответственно, даже если канал большой, страницы с большим количеством элементов будут грузиться медленнее — просто потому, что от запроса каждого элемента до получения ответа с элементом проходит больше времени. Про это в той статье — ни слова.

В любом случае, там про скорость загрузки, здесь — про трафик. Вы не находите, что это разные вещи?
спасибо за развернутый ответ и за выделение из одной проблемы двух. В любом случае мы идем к тому, что нам нужно
1. меньше данных
2. меньше соединений
факторов, которые на это влияют, очень много. В том числе есть и перекрестное влияние. В любом случае нам спор сейчас ведет в никуда — оба правы.
Да не про то. Я к тому, что на скорость получения ответа совершенно не влияет количество заголовков запроса, которое так стремится уменьшить автор.

Пока их меньше 1500 байт — они все уходят одним tcp-пакетом, соответственно, доходят до сервера за определённое время, независимо от объёма.
к сожалению, иногда из-за cookie заголовки сильно разрастаются. Но обычно именно из-за них
(автор) Да, действительно, не разбираюсь в особенностях технологий связи.
В свете того, что объём данных до 1500 байт передаётся одним пакетом, поставленный воспрос действительно не иеет смысла.
Accept-Language используют очень многие сайты. Геотаргетинг идет тогда, когда Accept-Language не указан.

Поставьте себе английскую мозиллу и проверьте.
Даешь постоянное соединение на 80й порт! Пусть братья-апачи обрабатывают запросы к ним без переустановления соединения.
Sign up to leave a comment.

Articles