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

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

В самом простом понимании апстрим и даунстрим — это направление потока информации.

Поскольку все мы читаем эту статью, будучи подключенными к интернету, давайте рассмотрим пример апстрима и даунстрима применительно к интернет-провайдерам (ISP). Здесь провайдера в первую очередь интересует трафик. Upstream-трафик — это данные, поступающие от пользователя через другого интернет-провайдера. Например, если у вас есть сайт, предлагающий подписку на рассылку, информация, которую я отправляю для оформления подписки, является upstream-данными.

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

Подведем итог: то, что нужно или хочется мне (ваша рассылка), находится в апстриме. То, что вы предоставляете мне (приветственное письмо и сама рассылка), поступает ко мне по даунстриму.

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

В мире Linux понятия апстрима и даунстрима имеют два основных контекста. Один связан с ядром, а другой — с приложениями. Есть и другие, но я надеюсь донести суть именно на этих двух примерах.

Upstream и downstream в контексте ядра LinuxgGBkjrlBKnxDNHuH80Z2ZFjBG6TZoY3ngP4HcEM2.webp

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

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

В версию ядра, создаваемую дистрибутивом, будут добавлены патчи, а также активированы определенные функции и опции. Эта конфигурация определяется создателем дистрибутива. Именно поэтому существует несколько разновидностей Linux: например, Debian и Red Hat. Создатель дистрибутива решает, какие опции предложить своей пользовательской базе, и компилирует ядро соответствующим образом.

Как только эта работа завершена, всё подготавливается к релизу в репозитории, откуда мы можем забрать копию. Эта копия поступает к нам по даунстриму.

Аналогично, если дистрибьютор обнаруживает баг в ядре, исправляет его и затем отправляет патч разработчикам ядра, чтобы те могли пропатчить ядро для всех, кто находится в даунстриме. Это называется контрибьютом в апстрим (или вкладом в апстрим), поскольку здесь поток направлен вверх, к первоисточнику.

Upstream и downstream в контексте приложений

Опять же, технически Linux — это ядро, а всё остальное является дополнительным ПО. Создатели дистрибутива также добавляют в свой проект дополнительное программное обеспечение. В этом случае существует несколько апстримов. Дистрибутив может содержать любое количество приложений, таких как X, KDE, Gnome и так далее.

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

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

Если вы опубликуете информацию о проблеме на каком-нибудь общем форуме по Linux и упомянете, что используете Mint, вы наверняка получите ответ вроде: «Эту проблему лучше решать на форуме Mint».

Используя предыдущий пример с багом в nano, вполне возможно, что программисты Mint внесли изменения в nano, чтобы он лучше работал в их дистрибути именно в их дистрибутиве. Если они действительно совершили ошибку, они захотели бы узнать об этом и, допустив ее, именно они должны ее исправить.

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

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

Автоматический поток в даунстрим

Было время, когда пользователям приходилось самостоятельно получать обновления. Пользователь скачивал обновленный исходный код и компилировали новый исполняемый файл. С течением времени были созданы такие утилиты, как apt, позвольшие пользователям подтягивать обновленные бинарные файлы (исполняемые файлы) из репозиториев. Программа apt создана для Debian, но у других дистрибутивов есть свои аналогичные программы для этого.

Программы вроде apt берут на себя всю работу с апстримом и даунстримом. Если вы запустите apt с опцией обновления следующим образом:

 sudo apt upgrade 

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

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

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

Заключение

Я только что вспомнил один эпизод из прошлого, раз уж упомянул Red Hat. В 1994 или 1995 году они опубликовали вакансию, и одним из крутых бонусов на рабочем месте там значилось: «сколько угодно бесплатных арахисовых M&Ms и сколько угодно бесплатной Dr. Pepper». Я ни капли не сомневался, что справлюсь с работой, и откликнулся исключительно ради этих двух бонусов. Правда, звонка я так и не дождался.

Ну да ладно. Вернемся к сути…

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

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

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