Комментарии

Вне зависимости от того, какие технологии шифрования и криптографические новинки будут использоваться в этом направлении, все сводится к решению одной из двух задач:

1) увеличению сложности внутренних операций хэширования;

2) увеличению длины hash-выхода данных с расчетом на то, что вычислительные мощности атакующих не смогут эффективно вычислять коллизию.

И, несмотря на появление в будущем квантовых компьютеров, специалисты уверены, что правильные инструменты (то же хэширование) способны выдержать испытания временем, ведь ни что не стоит на месте. Дело в том, что с увеличением вычислительных мощностей снижается математическая формализация структуры внутренних алгоритмических хэш-конструкций. А квантовые вычисления наиболее эффективны лишь в отношении к вещам, имеющим строгую математическую структуру.

так вы же в тексте нигде не сказали про «незнание хэша» для первого случая. Из того что я процетировал можно лишь сделать вывод об идентичности утверждений.

Да и кстати если вводите понятия «ключевые» и «безключевые» тоже можно было бы описать что это такое, а то из статьи непонятно. Как будто просто слова вставили.

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

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

мне кажется или это по сути одно и тоже? :)

В настоящее время практически ни одно приложение криптографии не обходится без использования хэширования.

Хэш-функции – это функции, предназначенные для «сжатия» произвольного сообщения или набора данных, записанных, как правило, в двоичном алфавите, в некоторую битовую комбинацию фиксированной длины, называемую сверткой. Хэш-функции имеют разнообразные применения при проведении статистических экспериментов, при тестировании логических устройств, при построении алгоритмов быстрого поиска и проверки целостности записей в базах данных. Основным требованием к хэш-функциям является равномерность распределения их значений при случайном выборе значений аргумента.

Криптографической хеш-функцией называется всякая хеш-функция, являющаяся криптостойкой, то есть удовлетворяющая ряду требований специфичных для криптографических приложений. В криптографии хэш-функции применяются для решения следующих задач:
— построения систем контроля целостности данных при их передаче или хранении,
— аутентификация источника данных.

Хэш-функцией называется всякая функция h:X -> Y, легко вычислимая и такая, что для любого сообщения M значение h(M) = H (свертка) имеет фиксированную битовую длину. X — множество всех сообщений, Y — множество двоичных векторов фиксированной длины.

Как правило хэш-функции строят на основе так называемых одношаговых сжимающих функций y = f(x1, x2) двух переменных, где x1, x2 и y — двоичные векторы длины m, n и n соответственно, причем n — длина свертки, а m — длина блока сообщения.

Для получения значения h(M) сообщение сначала разбивается на блоки длины m (при этом, если длина сообщения не кратна m то последний блок неким специальным образом дополняется до полного), а затем к полученным блокам M1, M2,.., MN применяют следующую последовательную процедуру вычисления свертки:

Ho = v,
Hi = f(Mi,Hi-1), i = 1,.., N,
h(M) = HN

Здесь v — некоторая константа, часто ее называют инициализирующим вектором. Она выбирается
из различных соображений и может представлять собой секретную константу или набор случайных данных (выборку даты и времени, например).

При таком подходе свойства хэш-функции полностью определяются свойствами одношаговой сжимающей функции.

Выделяют два важных вида криптографических хэш-функций — ключевые и бесключевые. Ключевые хэш-функции называют кодами аутентификации сообщений. Они дают возможность без дополнительных средств гарантировать как правильность источника данных, так и целостность данных в системах с доверяющими друг другу пользователями.

Бесключевые хэш-функции называются кодами обнаружения ошибок. Они дают возможность с помощью дополнительных средств (шифрования, например) гарантировать целостность данных. Эти хэш-функции могут применяться в системах как с доверяющими, так и не доверяющими друг другу пользователями.

О статистических свойствах и требованиях

Как я уже говорил основным требованием к хэш-функциям является равномерность распределения их значений при случайном выборе значений аргумента. Для криптографических хеш-функций также важно, чтобы при малейшем изменении аргумента значение функции сильно изменялось. Это называется лавинным эффектом.

К ключевым функциям хэширования предъявляются следующие требования:
— невозможность фабрикации,
— невозможность модификации.

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

К бесключевым функциям предъявляют требования:
— однонаправленность,
— устойчивость к коллизиям,
— устойчивость к нахождению второго прообраза.

Под однонаправленностью понимают высокую сложность нахождения сообщения по заданному значению свертки. Следует заметить что на данный момент нет используемых хэш-функций с доказанной однонаправленностью.

Под устойчивостью к коллизиям понимают сложность нахождения пары сообщений с одинаковыми значениями свертки. Обычно именно нахождение способа построения коллизий криптоаналитиками служит первым сигналом устаревания алгоритма и необходимости его скорой замены.

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

Это была теоретическая часть, которая пригодится нам в дальнейшем…

О популярных хэш-алгоритмах

Алгоритмы CRC16/32 — контрольная сумма (не криптографическое преобразование).

Алгоритмы MD2/4/5/6. Являются творением Рона Райвеста, одного из авторов алгоритма RSA.
Алгоритм MD5 имел некогда большую популярность, но первые предпосылки взлома появились еще в конце девяностых, и сейчас его популярность стремительно падает.
Алгоритм MD6 — очень интересный с конструктивной точки зрения алгоритм. Он выдвигался на конкурс SHA-3, но, к сожалению, авторы не успели довести его до кондиции, и в списке кандидатов, прошедших во второй раунд этот алгоритм отсутствует.

Алгоритмы линейки SHA Широко распространенные сейчас алгоритмы. Идет активный переход от SHA-1 к стандартам версии SHA-2. SHA-2 — собирательное название алгоритмов SHA224, SHA256, SHA384 и SHA512. SHA224 и SHA384 являются по сути аналогами SHA256 и SHA512 соответственно, только после расчета свертки часть информации в ней отбрасывается. Использовать их стоит лишь для обеспечения совместимости с оборудованием старых моделей.

Российский стандарт — ГОСТ 34.11-94.

Не стоит прибегать к черным методам продвижения, так как за этим могут последовать санкции поисковых систем.

Некачественный контент
— Переспам и переоптимизация ключевыми словами на странице.
— За спам в микроразметке для Google (спам ключевыми словами в структурированных данных).
— Неестественные тексты на странице — Баден-Баден от Яндекс.
— Повторяющийся контент или контент с низким уровнем уникальности — могут быть наложены санкции от Google (Google Panda).
— Заимствование чужого контента — Google DMCA-фильтр (Pirate).

Ссылочная масса

Не рекомендуется закупать некачественные ссылки на продвигаемый сайт. Необходимо отслеживать и избегать резкого роста ссылочной массы.

— Google Penguin — фильтр Google за некачественную ссылочную массу.
— Минусинск — фильтр Яндекс за SEO ссылки, АГС фильтр.

Накрутка поведенческих факторов

Поисковые системы негативно реагируют на попытку имитации действий реальных пользователей. Не надо так делать.

Сайты-аффилиаты

Аффилиаты — это сайты, которые принадлежат одной компании и продвигаются по одним и тем же запросам.
У них также могут совпадать: хостинг, тематика, адрес ли название фирмы, IP-адреса и т.д.
Необходимо разводить такие сайты по семантике.
Случай из практики: сайт официального дилера и сайт этого же дилера для бу авто. Был наложен такой фильтр, но его удалось снять.

Навязчивая реклама на сайте

Использование навязчивой рекламы также не рекомендуется поисковыми системами.

Взрослый контент

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

Обман и манипуляции

Дорвеи, клоакинг, скрытый текст — за все это могут последовать санкции поисковых систем.

Лично я не рекомендую продвигать сайт в органической выдаче с помощью накрутки поведенческих факторов. За этот способ продвижения можно получить бан на уровне хоста на срок от 8 месяцев, который снять будет проблематично и дорого. Для серьезного бизнеса с хорошо прокачанным брендовым именем — это будут большие убытки.

Накрутка поведенческих факторов — это имитация действий реальных пользователей на вашем сайте для воздействия на алгоритмы поисковых систем с целью улучшения позиций сайта в результатах выдачи.

Все пишут о том как нужно продвигать сайт и никто не пишет о том как не надо этого делать. Интересно было бы узнать с каким способом продвижения не стоит связываться?

Существует два основных фактора, определяющих специфику продвижения молодого сайта:

1. Сложно конкурировать в выдаче с сайтами-лидерами. Это логично, так как продвижение сайтов старше одного года всегда быстрее и проще. Однако это не значит, что у сайта, не достигшего возраста одного года, совсем нет шансов.

2. Отличные возможности избежать большого количества ошибок, изначально сделав все правильно.

Несмотря на то, что количество работы будет практически таким же, как и для других сайтов, нужно стремиться к тому, чтобы задачи были объемными, а темпы — оперативными.

Если эти условия будут соблюдены, тогда сайты будут ранжироваться значительно лучше. Однако если какие-то задачи второго приоритета (важные, но не блокирующие реализацию других задач), еще не реализованы на текущей версии сайта, всегда можно доделать их в будущем.
Фактор возраста

Практически всегда возраст сайта влияет на его продвижение. Только что созданная страница и старый сайт с нулевым уровнем оптимизации будут продвигаться совершенно по-разному.

Веб-страница, созданная давно, имеет приоритет за счет возраста, поэтому ее продвижение будет быстрее и эффективнее. Об этом нужно помнить, и при отложенном запуске сайта добавить на конкретный домен заглушку с текстом для индексации. В будущем можно разместить на этом домене уже новый сайт с набранной минимальной историей.
Планирование структуры нового сайта

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

Можно использовать структуры конкурентов, но дорабатывать их под собственные задачи и учитывать свои особенности.

Сбор семантического ядра

Сбор запросов для нового сайта — задача непростая, но эффективная. На его основе будут прописаны страницы, что важно для продвижения.

Для сайтов с большим количеством вложенных подразделов возможно, что не вся семантика будет собрана в одну итерацию. Их может быть несколько.

Особое внимание нужно уделить группировке ключевых слов на основе параметров:

— Коммерческий/информационный запрос. При разных интентах запросы будут несовместимы. Это видно на примерах разных страниц в Яндексе и Google:

Статьи с подборками фото в Google:

— Совместимость запросов на первой странице. Например, запросы «шкафы на кухне» и «шкаф на кухню» не всегда подходят для продвижения на одной странице, а запросы «бухгалтерская фирма» и «аутсорсинг бухгалтерии» на одной странице совместить можно.

— Наличие конкретных типов страниц в выдаче. По разным запросам могут быть определенные типы страниц в выдаче. Например, карточки доминируют в Google. Поэтому наличие хорошо оптимизированных страниц фильтров с ЧПУ-адресами будет некритично (хотя в будущем они обязательно нужны в Яндексе, в Google будут ранжироваться с переменным успехом).
— Собранную семантику нужно сразу загрузить на сервисы по мониторингу с любой доступной группировкой (сегменты, группы, теги, категории).

Также стоит добавить в мониторинг запросов основных конкурентов и следить за динамикой их видимости. Это даст понимание общего вектора продвижения сайта.

Кластеризация ключевых слов

После сбора ключевых слов и фраз необходимо провести их кластеризацию. Процесс сортировки связанных ключевых слов позволяет эффективнее организовать контент на сайте.

Могут возникнуть неочевидные нюансы, которые решаются индивидуально. Например, разные рекомендуемые страницы для продвижения в Яндексе и Google (в Яндексе ранжируются коммерческие страницы, а в Google — статьи). В этом случае рекомендуется принимать решение, исходя из специфики сайта и выдачи в каждой ПС.

Оптимизация контента

В этом случае контент — это не только текстовое описание страницы (с ключевыми словами, как в традициях SEO 2000-х годов, которые вызывали негатив у читателей), но и вывод товаров в оптимальном для SEO виде.

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

Оптимизация контента может включать дополнительные блоки, внедрить которые можно по итогам анализа конкурентов.

В большинстве случаев рекомендуется внедрение микроразметки. С ее помощью можно улучшить сканирование сайта поисковыми роботами и увеличить вероятность попадания в расширенный сниппет.

Подключение других каналов трафика

Как правило, рекламу на новом сайте запускают для сбора данных по ПФ. После того, как накопятся хотя бы минимальные объемы трафика (особенно на новые созданные страницы), результаты улучшатся.

Для сайтов услуг со средним и высоким уровнем конкуренции практика подключения других каналов трафика может быть постоянной. В то же время при работе с каталогами интернет-магазинов спустя время рекламу можно отключить в пользу органического продвижения.

Для коммерческих сайтов реклама особенно важна. От нее зависит количество продаж.

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

Техническая оптимизация нового сайта

Стандартные работы по технической оптимизации актуальны и для новых сайтов тоже.

Пропишите все файлы robots.txt, перейдите на протокол https, добавьте сайт в сервисы для веб-мастеров, сделайте полную валидацию кода и максимально ускорьте загрузку сайта.

Так как все больше страниц разрабатывают на JavaScript, важно проверить корректность вывода кода сайта. Подробнее о продвижении JS-сайтов.

Основное преимущество Node.js для нас — это возможность асинхронного выполнения кода. Это означает, что ваш сервер может обрабатывать множество запросов одновременно, не ожидая завершения каждого из них. Это приводит к более эффективному использованию ресурсов и быстрому отклику сервера.

Почему Node.js? Ответ прост — вместо традиционной модели параллелизма на основе потоков в Node.js используются принципы событийно-ориентированных систем – в сравнении с подходом «один поток на каждое соединение» код получается проще и быстрее. Node.js стал популярен благодаря обширному репозиторию NPM, внушительному сообществу разработчиков и возможности использовать JavaScript на клиенте, на сервере и для разработки инструментов.

Выбор Node.js в качестве платформы для серверной прослойки помимо множества плюсов повлек за собой и определенное количество головной боли для разработчиков.

Например, таким большим приложениям, как наше, даже при наличии хорошего покрытия тестами и документацией, каждое обновление дается нелегко: постоянное нахождение в процессе изменений вытекает не только из желания разработчиков порадовать себя или улучшить свой продукт, но и из реалий современного мира JavaScript-разработки.

Node.js мы используем в связке с биндингами C++ кода в JavaScript, отказаться от которых в силу сложившейся инфраструктуры мы не можем. При каждом обновлении Node.js мы сталкиваемся не только со стандартными сложностями обновления по гайдам миграции, но и с обновлением наших биндингов для поддержки очередной версии Node.js: libxml, libxslt и наших внутренних C++ библиотек.

Вообще, зависимость от биндингов привносит дополнительные накладные расходы по поддержке, поэтому их лучше избегать – например, наши внутренние биндинги стараемся переводить на отдельные HTTP-сервисы.

Отдельная история – асинхронность Node.js, которую еще нужно уметь «готовить». Например, в какой-то момент мы заметили, что время от времени работающий воркер падал из-за ошибки бизнес-логики и перезапускался, хотя весь код логики в Express и Koa обернут в отлов ошибок и должен перехватываться. То есть бизнес-логика, описанная в обработчиках роута, никак не должна останавливать весь процесс Node.js, но у нас это все равно происходило.

Анализ ситуации вскрыл любопытную особенность. При передаче в process.nextTick функции обратного вызова она запустится в текущем такте асинхронного цикла после выполнения остального кода текущего такта, включая код отлова ошибок. Если внутри такой функции возникал Exception, его было не отловить, потому что process.nextTick вовсе не «следующий такт», а конец текущего.

Еще есть нюансы с ES2015: весь наш клиентский код проходит через транспиляцию в Babel, что позволяет нам использовать любые новшества языка и не только стандарта ES2015. Но Node.js не имеет такой хорошей поддержки и ряд возможностей в нем отсутствуют, а прогонять серверный код через Babel — слишком большая головная боль при поддержке и сборке кода. Таким образом, при написании JavaScript-кода нам необходимо всегда держать в голове окружение, где этот код будет исполняться, а также по-разному настраивать правила линтера.

Приятной вишенкой на торте трудностей можно считать «усложнившийся» процесс выбора модулей для использования. Безусловно, есть признанные лидеры в той или иной сфере применения, но и среди них можно обоснованно искать более подходящие для каждого конкретного случая. Да, количество logic-ревью возросло, но тем и хорош Node.js и NPM, что у нас есть широкий выбор открытых модулей и возможность не подстраиваться под технологию, а использовать удобную для нас.

Посмотрите внимательнее на картинку к посту и вам все станет понятно, что вы все правильно понимаете
По поводу буфера веб-сервера, то он может попробовать сбросить используя cgi api, если я ничего не путаю

Написано, что flush() сбрасывает SAPI-буфер. Правильно ли я понимаю, что он также сбрасывает и Default Output Buffer?

Кроме того, в доках написано, что он пытается сбросить также буфер веб-сервера (как?).

Поток вывода в PHP содержит байты, обычно в виде текста, которые разработчику надо вывести на экран. Чаще всего для этого используется конструкция echo или printf(). Во-первых, нужно понимать, что любая функция, которая что-то выводит, будет использовать БВ из области PHP. Если говорить о расширениях для PHP, то можно получить доступ к функциям, пишущим в SAPI напрямую, в обход любого вышерасположенного БВ. API C задокументировано в lxr.php.net/xref/PHP_5_5/main/php_output.h, отсюда можно почерпнуть немало информации, например, о размере буфера по умолчанию.

Второй важный момент: слой БВ является не единственным слоем, в котором буферизуются выводимые данные.

И третье: в зависимости от SAPI, который вы используете (веб или cli), слой БВ может вести себя по-разному.

Ниже представлена схема, которая поможет понять всё вышесказанное:

Здесь мы видим, что для управления выводимыми данными в PHP используется три логических слоя буферизации. Два из них принадлежат тому самому «буферу вывода», а третий — SAPI. Когда поток вывода покидает область PHP, чтобы попасть на нижний уровень архитектуры, «по пути» могут возникнуть новые буферы: буфер терминала, буфер FastCGI, буфер веб-сервера, буфер операционной системы, буферы стеков TCP/IP. Не забывайте об этом. Хотя в рамках данной статьи мы будем говорить только о PHP, в стеке на пути данных к нижнему слою и пользователю встретится ещё немало программных средств.

Важное замечание относительно CLI SAPI: он отключает в PHP любой буфер вывода по умолчанию, присвоив в ini параметру output_buffering значение 0. Так что, пока вы в CLI не пропишете вручную функции ob_(), по умолчанию все выводимые данные будут напрямую попадать в слой SAPI. Более того, в CLI для параметра implicit_flush жёстко указано значение 1. Суть этого параметра разработчики вечно понимают неправильно, хотя код говорит совершенно недвусмысленно: когда implicit_flush имеет значение 1, буфер слоя SAPI сбрасывается при каждой записи. То есть каждый раз, когда вы записываете данные для вывода с помощью CLI SAPI, они немедленно отправляются на нижний уровень, где записываются в виде stdout, а потом сбрасываются.

Стандартный PHP-слой буферизации вывода

Если вы используете SAPI не так, как CLI, а например, PHP-FPM, то можете поэкспериментировать с тремя параметрами в ini, имеющими отношение к буферу:

— output_buffering
— implicit_flush
— output_handler

Обратите внимание, что использование с ними ini_set() не даст никакого эффекта, поскольку их значения считываются в момент запуска PHP, до того, как он может запустить какой-либо скрипт. Если использовать ini_set() с любым из этих параметров, то он меняет значение, однако оно уже нигде не будет использоваться. Слишком поздно — слой БВ уже запущен и активен. Изменить эти параметры можно, отредактировав php.ini или применив ключ –d к бинарнику PHP.

По умолчанию в php.ini, идущем в составе поставки PHP, output_buffering присвоено значение «4096» (байт). Если вы не используете php.ini (или запускаете PHP с ключом –n), то значением по умолчанию будет «0», то есть отключено. Если захардкодить значение «On», то будет назначен стандартный размер буфера вывода (16 КБ).

Как вы уже, наверное, догадались, использование буфера для вывода в веб-окружении благотворно влияет на производительность. Начальных 4 КБ вполне достаточно, ведь это означает, что вы можете записать до 4096 ASCII-символов, пока PHP не начнёт взаимодействовать с нижерасположенным слоем SAPI. В условиях веба отправка данных побайтно, напротив, производительность не улучшает. Гораздо лучше, если сервер отправляет весь контент скопом или большими частями. Чем реже уровни обмениваются данными, тем лучше с точки зрения производительности. Поэтому обязательно используйте буфер вывода. PHP отправит его содержимое в конце запроса и вам для этого ничего не придётся делать.

В предыдущей главе я упоминал об implicit_flush в контексте CLI. В случае с любым другим SAPI implicit_flush изначально отключён. Это хорошо, поскольку вряд ли вы будете приветствовать сброс SAPI сразу же после записи в него. Для протокола FastCGI сброс можно сравнить с завершением и отправкой пакета после каждой записи. Однако лучше сначала полностью заполнить буфер FastCGI, а уже потом слать пакеты. Если вам нужно вручную сбросить буфер SAPI, используйте для этого PHP-функцию flush(). Для сброса после каждой записи, как уже говорилось выше, можно использовать параметр implicit_flush в php.ini. Как вариант — однократный вызов PHP-функции ob_implicit_flush().

К содержимому буфера до его вывода можно применять callback output_handler. Вообще, благодаря расширениям PHP нам доступно немало callback-ов (пользователи тоже могут их писать, об этом я расскажу в следующей главе).

— ob_gzhandler: компрессия вывода с помощью ext/zlib
— mb_output_handler: перевод кодировки символов с помощью ext/mbstring
— ob_iconv_handler: перевод кодировки символов с помощью ext/iconv
— ob_tidyhandler: очистка вывода HTML с помощью ext/tidy
— ob_[inflate/deflate]_handler: компрессия вывода с помощью ext/http
— ob_etaghandler: автоматическая генерация заголовков ETag с помощью ext/http

Вы можете использовать только один callback, который получит содержимое буфера и сделает полезные преобразования для вывода, что не может не радовать. Для анализа данных, которые PHP отправляет веб-серверу, а тот отсылает пользователю, полезно использовать callback-и буфера вывода. Кстати, под «выводом» я подразумеваю как заголовок, так и тело. HTTP-заголовки тоже являются частью слоя буферизации вывода.

Тело и заголовки

Когда вы используете буфер вывода (неважно, пользовательский или один из стандартных), то можете отправлять HTTP-заголовки и содержимое как угодно. Любой протокол требует сначала отсылать заголовок, а уже потом тело, но за вас это сделает сам PHP, если вы используете слой БВ. Любая PHP-функция, работающая с заголовками (header(), setcookie(), session_start()), фактически использует внутреннюю функцию sapi_header_op(), которая просто заполняет буфер заголовков. Если после этого записать выводимые данные, например, с помощью printf(), то они запишутся в один из соответствующих буферов вывода. И во время отправки буфера PHP сначала

отсылает заголовки, а уже потом тело. Если вам не нравится такая забота со стороны PHP, то придётся вообще отключить слой БВ.

Пользовательские буферы вывода

Давайте разберём на примерах, как это работает, и что вы можете сделать. Имейте в виду, что если вы хотите использовать стандартный PHP-слой буферизации, то не сможете воспользоваться CLI, поскольку он отключается как слой.

Ниже приведён пример работы со стандартным PHP-слоем с помощью внутреннего веб-сервера SAPI:

/* запущено так: php -doutput_buffering=32 -dimplicit_flush=1 -S127.0.0.1:8080 -t/var/www */
 
echo str_repeat('a', 31);
sleep(3);
echo 'b';
sleep(3);
echo 'c';

Мы запустили PHP со стандартным буфером вывода на 32 байта, после чего сразу же записали в него 31 байт, пока не включилась задержка исполнения. Экран чёрный, пока ничего не отправлено. Затем действие sleep() заканчивается, и мы записываем ещё один байт, тем самым полностью заполняя буфер. После этого он сразу же сбрасывает себя в буфер слоя SAPI, а тот сбрасывает себя в вывод, поскольку implicit_flush имеет значение 1. На экране появляется строка aaaaaaaaaa{31 раз}b, после чего опять начинает действовать sleep(). По его завершении пустой 31-байтный буфер заполняется одним-единственным байтом, после чего PHP завершается и сбрасывает буфер. На экране появляется с.

Так выглядит работа стандартного PHP-буфера без вызова каких-либо ob-функций. Не забудьте, что это именно стандартный буфер, то есть он уже имеется в наличии (только нельзя использовать CLI).

Теперь с помощью ob_start() можно запускать пользовательские буферы, причем столько, сколько нужно, пока память не закончится. Каждый буфер будет помещаться за предыдущим и немедленно сбрасываться в следующий, что постепенно приведёт к переполнению.

ob_start(function($ctc) { static $a = 0; return $a++ . '- ' . $ctc . "\n";}, 10);
ob_start(function($ctc) { return ucfirst($ctc); }, 3);
 
echo "fo";
sleep(2);
echo 'o';
sleep(2);
echo "barbazz";
sleep(2);
echo "hello";
 
/* 0- FooBarbazz\n 1- Hello\n */

Устройство буферизации вывода

Как я уже говорил, начиная с версии 5.4 механизм буферизации вывода был полностью переписан. До этого код был очень неаккуратным, многие вещи сделать было непросто, часто возникали баги. Подробнее об этом можно почитать по ссылке. Новая кодовая база получилась гораздо чище, лучше организована, появились новые возможности. Правда, совместимость с версией 5.3 обеспечивается лишь отчасти.

Пожалуй, одним из самых приятных нововведений стало то, что расширения теперь могут объявлять свои callback-и буфера вывода, конфликтующие с callback-ами других расширений. Ранее было невозможно полностью управлять ситуациями, когда другие расширения тоже могли декларировать свои callback-и.

Вот небольшой пример на скорую руку, демонстрирующий, как можно зарегистрировать callback, преобразующий данные в верхний регистр:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "php.h"
#include "php_ini.h"
#include "main/php_output.h"
#include "php_myext.h"

static int myext_output_handler(void **nothing, php_output_context *output_context)
{
char *dup = NULL;
 
dup = estrndup(output_context->in.data, output_context->in.used);
php_strtoupper(dup, output_context->in.used);
 
output_context->out.data = dup;
output_context->out.used = output_context->in.used;
output_context->out.free = 1;
 
return SUCCESS;
}
 
PHP_RINIT_FUNCTION(myext)
{
php_output_handler *handler;
 
handler = php_output_handler_create_internal("myext handler", sizeof("myext handler") -1, myext_output_handler, /* PHP_OUTPUT_HANDLER_DEFAULT_SIZE */ 128, PHP_OUTPUT_HANDLER_STDFLAGS);
 
php_output_handler_start(handler);
 
return SUCCESS;
}
 
zend_module_entry myext_module_entry = {
STANDARD_MODULE_HEADER,
"myext",
NULL, /* Function entries */
NULL,
NULL, /* Module shutdown */
PHP_RINIT(myext), /* Request init */
NULL, /* Request shutdown */
NULL, /* Module information */
"0.1", /* Replace with version number for your extension */
STANDARD_MODULE_PROPERTIES
};
 
#ifdef COMPILE_DL_MYEXT
ZEND_GET_MODULE(myext)
#endif

Подводные камни

По большей части они задокументированы, некоторые из них вполне очевидны, а некоторые не слишком. К очевидным можно отнести, например, то, что не следует вызывать какие-либо функции буфера изнутри callback-а БВ, также как и записывать выводимые оттуда данные.

К неочевидным подводным камням можно отнести то, что некоторые функции PHP используют внутренний БВ для самих себя, заполняя его, а затем сбрасывая или возвращая. При этом следующий буфер ставится в стек. К подобным функциям относятся print_r(), highlight_file() и SoapServer::handle(). Не следует использовать их изнутри callback-а БВ – это может привести к непредсказуемым последствиям.

Заключение

Слой вывода можно сравнить со своеобразной сетью, которая улавливает любые возможные «утечки» вывода из PHP и сохраняет их в буфере заданного размера. Когда буфер заполняется, он сбрасывается (записывается) в нижний уровень, если таковой есть. Как минимум в самый нижний из имеющихся — в буфер SAPI. Пользователи могут управлять количеством буферов, их размером и операциями, которые могут быть разрешены в каждом слое буфера (очистка, сброс или удаление). Это очень гибкий инструмент, позволяющий, например, создателям библиотек и фреймворков полностью контролировать поток вывода, направляя его в глобальный буфер и обрабатывая там. При этом PHP сам регулирует порядок отправки заголовков и потока вывода.

По умолчанию имеется один буфер вывода, управляемый тремя настройками в ini-файле. Он устроен так, чтобы реже осуществлять операции записи и не слишком часто обращаться к слою SAPI, а значит и к сети. Это сделано для улучшения общей производительности. Также расширения PHP могут декларировать callback-и, запускаемые в каждом буфере — например, для компрессии данных, замены строк, управления HTTP-заголовками и многих других операций.

Буферизация вывода используется PHP для повышения производительности и выполнения нескольких трюков.

— Вы можете заставить PHP сохранять все выходные данные в буфер и выводить их все сразу, повышая производительность сети.
— В определенных ситуациях вы можете получить доступ к содержимому буфера, не отправляя его обратно в браузер.

Рассмотрим этот пример:

<?php
    ob_start( );
    phpinfo( );
    $output = ob_get_clean( );
?>

Приведенный выше пример преобразует выходные данные в переменную вместо отправки их в браузер. output_buffering по умолчанию отключен.

— Вы можете использовать буферизацию вывода в ситуациях, когда вы хотите изменить заголовки после отправки содержимого.

Рассмотрим этот пример:

<?php
    ob_start( );
    echo "Hello World";
    if ( $some_error )
    {
        header( "Location: error.php" );
        exit( 0 );
    }
?>

Спасибо за статью, а можно простыми словами — что такое буферизация вывода и зачем мне использовать ее в PHP?

Без буферизации вывода (по умолчанию) ваш HTML отправляется в браузер по частям по мере обработки PHP вашим скриптом. При буферизации вывода ваш HTML сохраняется в переменной и отправляется в браузер как единое целое в конце вашего скрипта.

Преимущества буферизации вывода для веб-разработчиков

— Включение только буферизации вывода уменьшает количество времени, необходимое для загрузки и рендеринга нашего HTML, потому что он не отправляется в браузер по частям, поскольку PHP обрабатывает HTML.
— Все необычные вещи, которые мы можем делать со строками PHP, теперь мы можем делать со всей нашей HTML-страницей как с одной переменной.
— Если вы когда-либо сталкивались с сообщением «Предупреждение: невозможно изменить информацию заголовка — заголовки уже отправлены (output)» при настройке файлов cookie, вы будете рады узнать, что буферизация вывода — это ваш ответ.

Я не большой знаток истории верстки, но всегда считал, что прорывной идеей это было на Западе. В России так верстали с самого начала, и никакого специального названия у этого не было. Просто у нас с самого начала был зоопарк разных разрешений, примерно от 640×480 до 1600×1200. Потом вариантов на десктопах стало поменьше, но стали появляться лэптопы, нетбуки, смартфоны… В общем число вариантов скорее росло. Не думаю, что вообще был сколько-нибудь продолжительный период, когда какое-то одно разрешение полностью доминировало.

Сам термин «резиновая верстка» появился вместе с концепцией фиксированной верстки из-за тлетворного влияния Запада :) В верстку хлынуло много новичков, которые тащили в рот всякую гадость читали первые попавшиеся руководства, разумеется западные, потому что они там вона какие умные, куда нам до них, какой смысл читать наши учебники. А во всех адекватных российских руководствах фиксированная верстка под конкретное разрешение всегда оценивалась однозначно как грубейшая ошибка.

Когда мобильного веба не было даже в самых смелых фантазиях, весь интернет был на десктопных компьютерах с небольшими экранами. Оптимизирован для разрешения 1024 на 768 и браузера Internet Explorer 5! — гордо писали тогда на сайтах. Но прошло время, экраны подросли и пришлось к этому как-то подстраиваться. Сначала это были просто резиновые таблицы: колонки по 25%, содержимое 50%, а в отдельной строке colspan=3 и распорка для минимальной ширины. Надеюсь, вы не поняли о чём я сечас говорил.

Резиновая вёрстка — это когда вы задаёте всему макету и отдельным его частям не фиксированную ширину, а эластичную — в процентах. За исключением минимальной и максимальной ширины. Высоту в вебе в принципе не принято задавать — обычно она подстраивается под содержимое. Фикс или резина? — спрашивали верстальщики 2000-х про макет и втайне надеялись на второе, поинтереснее. Сейчас сложно представить, но когда-то это было прорывной идеей, которая усложнила вёрстку, но сделала первый шаг в правильном пути.

Таблицы для раскладки ушли, а резиновая вёрстка осталась. Если у вас эластичные флоаты, флексы… да хоть гриды! — это всё равно резиновая вёрстка. Но если ширина внешнего контейнера зафиксирована — это уже фикс, сколько бы ни было резины внутри. Чуть более универсальный фикс, но всё равно. В общем, главное чтобы сайт двигался так или иначе вместе с окном, а не торчал кирпичом где-то в центре или с краю.

Когда расширился круг устройств с интернетом и появились первые мобильные браузеры — встала задача как-то подстраиваться под них. Простая резина здесь уже не справлялась — нужно было переписывать стили. Одной из первых, в 2006 году появилась техника адаптивной раскладки Марка ван ден Доббельстина. В статье на A List Apart Марк предложил добавлять классы при загрузке или ресайзе окна и на каждый диапазон вешать стили. До первой реализации медиавыражений в Safari оставалось два года.

Когда в начале десятых годов появилось для чего адаптировать и чем адаптировать — мобильные браузеры и медиавыражения — вышли книги, давшие названия подходам: «Адаптивный веб-дизайн» Аарона Густавсона и «Отзывчивый веб-дизайн» Итана Маркота. Подходы Аарона и Итана продолжали идеи Марка, но с более современными технологиями и несколько отличались направлением мысли.

«Адаптивный веб-дизайн» Аарона предлагал гибко адаптировать сайты к возможностям устройств и браузеров. Важной частью этой философии был ненавязчивый JavaScript с прогрессивным улучшением — и всё это поверх семантической разметки. Хотя Аарон писал не совсем об этом, сегодня принято считать, что главное в адаптивной вёрстке — привязка к конкретным разрешениям и устройствам. Стили переключаются от одного брейкпоинта к другому, то есть у вас есть фиксированные макеты для iPad и iPhone, а то, что между ними вас не волнует.

«Отзывчивый веб-дизайн» Итана ставил во главу три вещи: резиновый макет, гибкие картинки и медиавыражения. Все размеры и отступы Итан предлагал указывать в процентах с сумасшедшими дробями для точности. Отличительной чертой подхода стало плавное изменение сайта, с ориентацией не на конкретные устройства, а на содержимое. То есть ваш резиновый макет хорошо выглядит не только на iPhone и iPad, но и в любой точке между ними.

Чуть позже Итан сформулировал ещё один важный принцип в книге «Сначала мобильные». Если до тех пор отправной точкой для адаптации вёрстки служила десктопная версия, то он предложил перевернуть схему и начинать с мобильной версии, а потом её улучшать. Почему так? Потому, что усложнять простое проще, чем упрощать сложное. Вдуматесь! А ещё потому, что нет соблазна просто спрятать сложно адаптируемое и обделить мобильных пользователей.

Ну как, стало понятно? Вот адаптивная, вот отзывчивая… М-м, нет, не очень. Из-за путаницы между техникой адаптивной раскладки и философией адаптивного веб-дизайна, из-за того, что все эти подходы прекрасно сочетаются и уже не проследить чёткую границу между ними — из-за всего этого, я плюнул на терминологическую чистоту и стал называть всё это адаптивным дизайном или адаптивной вёрсткой. Это понятие всегда было достаточно широким, чтобы вместить все остальные способы.

Да и принцип дискретной адаптации от размеров устройств и без резины имел смысл лет 10 назад. При сегодняшнем разнообразии устройств полагаться на конкретные размеры и жёстко переключаться между ними — значит однажды очень больно промахнуться. Притом, никто вам не мешает при полностью резиновой вёрстке дописывать адаптацию под нужные разрешения.

Ну и как теперь верстать? Просто! Сначала делаете мобильный резиновый макет, который хорошо вписывается в небольшие устройства. А когда размеры экрана или окна начинают расти — начинаете использовать появившееся пространство для улучшения интерфейса. Появляется боковая колонка, вторая, растут размеры картинок и подгружаются новые разрешения и так далее. То есть медиавыражения меняют стили не когда вы дошли до экрана самого модного телефона, а когда это нужно для содержимого сайта и удобства пользователя. Мы именно так и учим делать на интенсиве по продвинутой вёрстке.

Чтобы сделать хороший адаптивный сайт, нужно понимать много нюансов: вьюпорт, медиавыражения, адаптивные картинки и другое.