Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 24
Классная статья, спасибо.
Статья хорошая, правда как по мне - слишком много теории и мало практики.
Было бы интересно почитать про реальные примеры использования HTTP 1.1 и чанков в AJAX.
Кстати, в переводе есть один ляп:
"Если бы он знал, ему бы не нужно было передавать данные в первом месте."
In the first place - это не "в первом месте", а "в первую очередь" :)
Было бы интересно почитать про реальные примеры использования HTTP 1.1 и чанков в AJAX.
Кстати, в переводе есть один ляп:
"Если бы он знал, ему бы не нужно было передавать данные в первом месте."
In the first place - это не "в первом месте", а "в первую очередь" :)
Даже не так. Это значит, "вообще не нужно было бы передавать", то есть "in the first place" - отсылка к вышеописанному порядку.
Согласен.
Просто поначалу фраза "ему не нужно было передавать данные в первую очередь" мне показалась достаточно понятной, но похоже я сам инглиша перечитал :)
Просто поначалу фраза "ему не нужно было передавать данные в первую очередь" мне показалась достаточно понятной, но похоже я сам инглиша перечитал :)
Я вообще написал поправку, потому что знал, что обычно значит "in the first place", а потом поврубался в тот параграф - и ничего не понял, ни так, ни этак :) Видимо, придется читать оригинал вместо перевода.
авторы пытаются указать на какое-то противоречие, но оно никак из текста не следует. Я постарался внести ясность своим комментарием, возможно, безуспешно
Все, прочитал оригинал - дошло.
Суть в том, что автор четко разделяет потоковую передачу и передачу одним куском. Отсюда - два способа завершить передачу для потока.
Дык вот, если говорить только об этом абзаце :)
Статья оказалась довольно полезной :) Если бы не заморочился с переводом, прочитал бы её этак через месяц...
Суть в том, что автор четко разделяет потоковую передачу и передачу одним куском. Отсюда - два способа завершить передачу для потока.
Дык вот, если говорить только об этом абзаце :)
Использование заголовка Content-Length позволяет просто и надежно узнать, где конец данных. К несчастью, это не позволяет посылать данные кусок за куском разного размера. Сервер, посылающий данные потоком не может в начале потока знать, сколько кусков осталось или какого размера каждый из них. Если бы он знал, ему вообще не нужно было бы слать данные потоком.
Статья оказалась довольно полезной :) Если бы не заморочился с переводом, прочитал бы её этак через месяц...
а причем тут чанки?
тема http chunked-encoding не раскрыта :)
тема http chunked-encoding не раскрыта :)
«Три способа закончить» &mdash ;-)
Да. Про сами-то чанки, как-то скупо. А остальное вобщем-то все и так знают. Но вообщем статья хороша самим обзором проблемы.
вроде чаще переводят "дырявые абстракции". Не дословно, но по русски.
>Я так понимаю, что без заголовка Content-Length клиент никогда не узнает, смог ли он получить
>все сообщение от сервера или только его часть (например, из-за неожиданного разрыва соединения),
>что может существенно отразиться на целостности передаваемых данных.
Кстати, столкнулся практически с обратной байдой, когда пытался прикрутить гзипование данных и заодно Content-Length в CakePHP. Если был включен дебаг, то IE не понимал скачивание файлов - потому что некоторые доп. данные слались в дополнение к указанной в заголовке длине (FF при этом благополучно скачивал файл). Пришлось делать вилку: если включен дебаг, то заголовок не шлём.
>все сообщение от сервера или только его часть (например, из-за неожиданного разрыва соединения),
>что может существенно отразиться на целостности передаваемых данных.
Кстати, столкнулся практически с обратной байдой, когда пытался прикрутить гзипование данных и заодно Content-Length в CakePHP. Если был включен дебаг, то IE не понимал скачивание файлов - потому что некоторые доп. данные слались в дополнение к указанной в заголовке длине (FF при этом благополучно скачивал файл). Пришлось делать вилку: если включен дебаг, то заголовок не шлём.
благодарю, отличная статья.
Админу на заметку:
Не используйте Keep-Alive на нагруженных серверах, которые работают под Апачем (если ваш апач специально не обучен). Т.к. демон Апача кушает очень много памяти и максимум тянет 255 открытых соединений. Т.е. если keep-alive открыли 255 человек, то больше к вашему серверу никто подключиться не сможет, пока не освободиться новый поток.
- Что же делать?
- Ставить NGINX с поддержкой keep-alive, который будет проксировать запросы от пользователей к апачу (не забудьте в nginx настроить передачу реального IP пользователя в http-заголовках для Apache, а то у вас все пользователе будут на апаче с IP вашего сервера).
Т.е. на FRONTEND'e у вас стоит NGINX а на BACKEND'e Apache.
Таким образом, вся арава пользователей висит на резиновом NGINX'е, который в нашем случае спокойно тянет 1500 соединений keep-alive. А апач там вообще после этого использует максимум 5-8 потоков чтобы сделать генерацию страницы и отдать ее nginx'y.
Ведь пользователи разные бывают и по выделинки и по диалапу страницу открывают. Даже с отключенным keep-alive у нас Apache забивали (скрипты идеально отточены, не в них проблема).
Вобщем, к чему я все это дело пишу.
В результате мы на одной машине поставили nginx:80 и apache:8080 После чего мы смогли поддерживать более 255 подключений и СЭКОНОМИЛИ ПОРЯДКА 500MB ОЗУ, которые жрал апач на поддержку соединений с пользователями.
В итоге производительность сервера возрасла, после установки NGINX'а.
PS Спасибо ва Игорь Сысоев за такую хорошую вещь!
Не используйте Keep-Alive на нагруженных серверах, которые работают под Апачем (если ваш апач специально не обучен). Т.к. демон Апача кушает очень много памяти и максимум тянет 255 открытых соединений. Т.е. если keep-alive открыли 255 человек, то больше к вашему серверу никто подключиться не сможет, пока не освободиться новый поток.
- Что же делать?
- Ставить NGINX с поддержкой keep-alive, который будет проксировать запросы от пользователей к апачу (не забудьте в nginx настроить передачу реального IP пользователя в http-заголовках для Apache, а то у вас все пользователе будут на апаче с IP вашего сервера).
Т.е. на FRONTEND'e у вас стоит NGINX а на BACKEND'e Apache.
Таким образом, вся арава пользователей висит на резиновом NGINX'е, который в нашем случае спокойно тянет 1500 соединений keep-alive. А апач там вообще после этого использует максимум 5-8 потоков чтобы сделать генерацию страницы и отдать ее nginx'y.
Ведь пользователи разные бывают и по выделинки и по диалапу страницу открывают. Даже с отключенным keep-alive у нас Apache забивали (скрипты идеально отточены, не в них проблема).
Вобщем, к чему я все это дело пишу.
В результате мы на одной машине поставили nginx:80 и apache:8080 После чего мы смогли поддерживать более 255 подключений и СЭКОНОМИЛИ ПОРЯДКА 500MB ОЗУ, которые жрал апач на поддержку соединений с пользователями.
В итоге производительность сервера возрасла, после установки NGINX'а.
PS Спасибо ва Игорь Сысоев за такую хорошую вещь!
Как-то сумбурно. Сначала много теории, потом неплохое описание HTTP 1.0 (разве что момент с "собиранием" сервером сокетов невнятно написан). Потом переход к HTTP 1.1 и полнейшая каша - вмете свалены TCP, HTTP и AJAX плюс картинка состояний TCP посреди текста о чанках (таки по-русски будет - блоках). Я на эту картинку долго смотрел и пытался там эти самые чанки найти и только потом понял, что это вообще из другой оперы. В общем - хреново получилось.
что-то у меня дежа-вю годичной давности: сам когда-то так же писал. Для начала стоит сделать десятка два переводов, в общей сложности страниц на 100, а потом, может быть, пересмотреть занятую позицию.
@сумбурно: да, это перевод, а не авторская статья. А найти качественный текст на английском, который было бы приятно переводить, — задача весьма нетривиальная, а если хочется по определенной тематике — так и вообще невозможная.
@чанки: сам Сысоев активно употребляет именно этот термин. Боюсь, что для русского человека так уже привычнее... К тому же, наиболее близким и семантическим будет перевод "куски" или "кусочки"
@сумбурно: да, это перевод, а не авторская статья. А найти качественный текст на английском, который было бы приятно переводить, — задача весьма нетривиальная, а если хочется по определенной тематике — так и вообще невозможная.
@чанки: сам Сысоев активно употребляет именно этот термин. Боюсь, что для русского человека так уже привычнее... К тому же, наиболее близким и семантическим будет перевод "куски" или "кусочки"
Аааа... Ну, если стилистика оригинала соблюдена, то конечно да :)
P.S. Кстати, смысл Вашего комментария от меня тоже неуловимо ускользает :)
P.P.S. Перевожу по мере необходимости в значительных количествах. Но, если перевожу не худжественную литературу, то сильно работаю над стилистикой. Более того, если перевод претендует на сколько-либо серьёзное отношение (а уж тем более, если это официальный документ), то никакие "кусочки" не допустимы. Или в документации вы тоже "кусочки" или "чанки" использовать будете? А во-вторых, это вопрос технической грамотности.
P.S. Кстати, смысл Вашего комментария от меня тоже неуловимо ускользает :)
P.P.S. Перевожу по мере необходимости в значительных количествах. Но, если перевожу не худжественную литературу, то сильно работаю над стилистикой. Более того, если перевод претендует на сколько-либо серьёзное отношение (а уж тем более, если это официальный документ), то никакие "кусочки" не допустимы. Или в документации вы тоже "кусочки" или "чанки" использовать будете? А во-вторых, это вопрос технической грамотности.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучаем потоки, чанки и ищем конец