Вряд ли кто-то из нас задумывается, какие испытания преодолевает обычное сообщение, прежде чем добраться из одного уголка света в другой. Набрали пару строк в мессенджере, отправили фотографию — и лишь миг спустя на другом конце города или даже континента кто-то улыбается нашему пакету байтов. Всё работает, как по волшебству. Но это только на поверхности.
На самом деле, за таким простым действием скрывается удивительный конвейер из правил, инструкций и невидимых согласований. Каждый компьютер, облако, маршрутизатор — как маленький бюрократ, строго следит за своими обязанностями, чтобы ни один бит не потерялся по пути.
Но так было не всегда. Ещё несколько десятилетий назад попытка связать разные компьютеры напоминала знакомство людей, говорящих на совершенно не похожих диалектах. Одни предпочитали громко кричать из окна, другие — писать письма мелом на доске. Нужно было не только придумать общий язык, но и договориться: кто что должен делать, на каком этапе, кто передаёт, кто проверяет, а кто отвечает за упаковку и доставку.
Меня зовут Иннокентий Солнцев, вы слушаете подкаст «До нас дошло». В этом выпуске мы разберёмся, зачем интернету понадобились строгие инструкции, и что на самом деле руководит движением каждого байта в этом многоуровневом балете. Откройте настройки сети, посмотрите на привычный значок Wi-Fi — сегодня расскажем, по каким ступенькам проходит каждый ваш байт по пути к цели.
Когда мы сегодня отправляем письмо по электронной почте или сохраняем файл в облако, мы редко задумываемся, как именно проходит процесс обмена данными между нашим устройством и остальным миром. Между тем, эта простота стала результатом десятилетий согласований, стандартов и технологических компромиссов.
В первых компьютерных сетях — это середина 60-х годов прошлого века, у нас про них был отдельный выпуск подкаста — каждая система представляла собой замкнутый, автономный мир: производитель сам определял не только способ передачи данных, но и все правила общения между машинами. Связать между собой такие изолированные «острова» разных производителей становилось всё сложнее. Например, у IBM, Digital Equipment или Siemens были собственные протоколы, зачастую намеренно несовместимые с конкурентами: ведь рынок был молодым, и борьба шла не только за технологии, но и за контроль над будущими закупками заказчиков - если конкуренты не поддерживают вашу технологию, то уже купившему ваш продукт и таким образом подсевшему на вашу иглу заказчику уйти к этим конкурентам будет невероятно сложно.
По мере роста вычислительных ресурсов и появления межуниверситетских, ведомственных и корпоративных сетей стало очевидно: каждая новая интеграция превращается в инженерный кошмар. Для каждого «моста» между системами приходилось писать сложный переводчик, а иногда — почти с нуля проектировать обмен данными, силами самого клиента.
К 1970-м годам мир оказался буквально покрыт разрозненными сетями: у каждой крупной компании или исследовательского центра мелькали свои взгляды на то, как организовать передачу данных и что считать «правильной» связью. Например, мини-компьютеры DEC соединялись протоколами DECnet, мейнфреймы IBM — по SNA, в Европе набирал обороты свой стек X.25. Каждая такая система использовала собственный формат сообщений, уникальные методы адресации и конкретные технические решения, зачастую осознанно «отгораживаясь» от внешнего мира.
Это неоднородное пространство технологических «островов» работало, пока устройства оставались в пределах собственной экосистемы. Но стоило появиться задаче соединить, например, университетский кластер из Англии с вычислительным центром во Франции, или интегрировать оборудование разных производителей на одном промышленном объекте — возникали серьёзные проблемы.

Одним из самых заметных примеров сетевого «Вавилона» стала ARPANET — первая масштабная экспериментальная сеть в США, связавшая университеты и военные лаборатории. Каждая из её подсетей могла использовать свой протокол, а для объединения приходилось разрабатывать временные решения — шлюзы и конвертеры. Инженерам приходилось буквально вручную согласовывать правила: как оформить заголовок, какие коды ошибок использовать, кто отвечает за восстановление соединения при сбое.
Вот несколько типичных сцен для 1970-х:
— Например, крупные банки сталкивались с парадоксом: вроде бы и техника в обоих филиалах одинаковая, а отправить платёжный документ напрямую — уже сложная задача. Каналы передачи и используемые программы различались настолько, что процесс обмена превращался в постоянный поиск обходных решений и временных «костылей».
— В больших научных проектах к общей вычислительной сети постоянно подключались новые институты. Каждый раз это означало написание специфических, если можно так выразиться, «переводчиков» между разными системами: протоколы у всех разные, и работало это очень нестабильно.
— А военные инженеры (в условиях рыночной экономики, разумеется) с досадой обнаруживали, что новая партия радаров или датчиков требует не просто иной разъём, но едва ли не целую переписанную с нуля систему обмена данными. И так каждый год: новые устройства — новые проблемы для интеграции.
Так возникла идея: создать некую универсальную систему, набор соглашений, по которым любые устройства смогут передавать данные друг другу вне зависимости от конструкции, страны происхождения или задач. Эти «правила дорожного движения» для компьютерных сетей должны были описывать не столько сами методы передачи, сколько общие принципы взаимодействия — чтобы даже очень разные устройства смогли обменяться сообщениями, лишь производя «перевод» между своими внутренними форматами согласно установленным правилам.
В середине 1970-х годов под влиянием банковских ассоциаций, телекоммуникационных монополий и международных академических сообществ начались крупные попытки формализовать язык сетевого взаимодействия. В это время появляются как первые прототипы стандартизированных протоколов, так и концепции многоуровневых моделей архитектуры сетей: идёт активная дискуссия между инженерами, государственными агентствами и университетами, — как вообще должны быть устроены коммуникации на уровне мира, а не частного завода или лаборатории.
Крупнейшим заказчиком были государства, публичный сектор и военные, в первую очередь американские и европейские, чьё оборудование требовало интеграции поставщиков со всего мира. Многие университеты поддерживали разработку стандартных этапов и соглашений, чтобы заполнять «белые пятна» в экспериментальных сетях.
Именно это давление со стороны крупных клиентов, государственных структур и производителей привело к формированию целых рабочих групп. В США этим занимались, например, в комитетах ANSI и Национальном бюро стандартов (NBS); в Европе и остальном мире — в рамках Международной организации по стандартизации (ISO) и Международного консультативного комитета по телеграфу и телефонной связи (CCITT, впоследствии ITU-T). В СССР, хотя проблема конкуренции между вендорами и не стояла так остро,тем не менее аналогичные работы по стандартизации парадигм обмена данными велись под эгидой ГОСТ и профильных научно-технических институтов, с участием Министерства связи и ведущих вычислительных центров, и советские специалисты были активными участниками рабочих групп и ISO, и МСЭ.

Тогда на международных семинарах и в технических отчётах всё чаще всплывали слова: «уровень», «слой», «модульность». Что это значило для инженеров? В самом простом понимании уровень — это отдельный этап в сложной задаче передачи передачи данных. Каждый уровень отвечает только за свой участок работы: скажем, один занимается тем, как вообще перевести сигналы по проводам, другой — как собрать эти сигналы в пакеты, а третий — за то, чтобы переданные данные пришли к нужному получателю без потерь.
Разделить задачу передачи данных на такие уровни — значит добиться простоты и гибкости: если придумали новый способ передачи информации по кабелю, не надо менять всю систему обмена, достаточно обновить только уровень, «ответственный» работу с кабелем, а все остальные уровни гарантированно останутся такими же, и их переделывать не нужно.
Сначала говорили просто о «верхнем» и «нижнем» уровнях, ведь не всегда было понятно, где провести границы между задачами. Со временем схемы стали сложнее: в одних вариантах выделяли пять этапов, в других доходили до семи и даже больше. Так и зарождалось то, что потом стало называться многоуровневой архитектурой сети.
Первые шаги к официальной «слоистой» архитектуре сделали в середине 1970-х годов. Одной из первых стала трёхуровневая модель, предложенная в США на основе опыта ARPANET: выделяли уровень сетевой среды, уровень «промежуточной» обработки (транспорт) и уровень приложений. Это была очень простая схема — по сути, весь обмен делился на передачу через «железо», обработку данных в пути и то, что делал пользователь.

Однако практика быстро показала: такой схемы не хватает, чтобы описать все варианты реальной работы сетей, особенно когда речь шла о сложных задачах вроде установления соединения, согласования формата данных или обеспечения безопасности.
В 1977–1978 годах рабочие группы ISO и CCITT начали работу над более универсальной многоуровневой моделью. К началу 1980-х появляется уже более признанная, формализованная структура — семиуровневая модель, положенная потом в основу стандарта OSI. Но до неё ещё оставалась целая череда экспериментов: где-то делили на пять слоёв, где-то на шесть, а где-то предлагали схемы с «половинками» и дополнительными подуровнями.
Именно семиуровневая модель OSI оказалась первой, которую приняли как базовую для обсуждения и стандартизации на международном уровне. Она предложила разделить задачу передачи данных на следующие семь уровней:
- физический: как организовать передачу аналогового сигнала в среде передачи
- канальный: как этот аналоговый сигнал превратить в какие-то осмысленные цифровые данные
- сетевой: как организовать передачу данных между любыми узлами, в том числе и не имеющих общего канала связи, через цепочку транзитных узлов
- транспортный: как два узла, имеющих связь друг с другом, могут обособить потоки данных разных приложений, чтобы они не смешивались между собой
- сеансовый: как установить поток данных для приложения, когда оно нужно, как управлять им в процессе, и как завершить поток, который больше не нужен
- уровень представления описывает синтаксис передаваемых данных
- и уровень приложения, грубо говоря, делает все остальное
https://www.youtube.com/watch?v=S770Fb2Jsxk (??)
Если вы загрустили от обилия технической информации - не переживайте, жесть закончилась, дальше все буду рассказывать как для гуманитариев. Смысл модели был в том, чтобы есть слона по частям, и разбить большую задачу передачи данных на множество маленьких примитивных задачек, а эти маленькие задачки объединить обратно в кучки по следующим принципам:
Кучки должны быть пронумерованы: первая, вторая, третья, и так далее
Если мы меняем способ решения какой-то одной задачи из кучки, это может повлиять на задачи в этой кучке и соседней с ней, но не дальше. Например, если мы меняем что-то в кучке номер два, может потребоваться доработка в кучках номер один и три, но пятая кучка обязана остаться нетронутой.

Идея за моделью OSI стоит очень красивая и логичная, по сути она предписывает не творить дичь, а стараться проектировать системы таким образом, чтобы внесение изменения в них было максимально простым. Заметьте, она описывает не интернет, а любые системы, в которых возможно взаимодействие между разными сущностями. Современная телефония, взаимодействие между блоками автомобиля, и даже между разными секциями одного чипа следуют этой модели, потому что она оказалась логична, проста, и позволяет вносить предсказуемые изменения во взаимодействие между системами, экономя силы, нервы и деньги участникам процесса. Модель оказалась настолько удачной, что часто мы ей следуем совершенно бессознательно, потому что “а разве можно как-то иначе”? Многие страны официально признали ее за стандартный способ построения систем взаимодействия (например, в России это ГОСТ Р ИСО 7498).

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

Первое утверждение родилось из того факта, что в комитете ISO придумали не только саму модель для произвольного взаимодействия, но и конкретный набор протоколов для построения компьютерных сетей, в котором каждый протокол отвечает за один уровень. Сама исходная модель ничего про протоколы не говорит, она оперирует задачами, а вот задумка комитета состояла в том, чтобы сделать именно протоколы, которые полностью закрывают какой-то один из шести уровней (оставив седьмой уровень конкретному приложению). Какая от этого была бы польза - решительно непонятно, потому что, как показала практика, нет никакой проблемы в том, что один протокол закрывает задачи нескольких уровней, причем не обязательно полностью. Короче говоря, вот этот набор протоколов в комитете согласовывали очень долго, почти десять лет, очень мучительно, потому что каждый вендор пытался пропихнуть в этот набор то, что было у него, и чего не было у конкурентов, и с абсолютно непонятной выгодой от его использования.
Когда этот набор протоколов наконец согласовали, оказалось, что он действительно никому не нужен. НО: этот набор протоколов, хотя и называется очень похоже, и его название тоже включает в себя ISO OSI, не является частью самой модели, и не умаляет ее достоинств.
Второе утверждение, будто бы эта модель устарела, обычно упоминается в сочетании с моделью TCP/IP, в том ключе что сегодня мы не используем протоколы OSI, но повсеместно используем стек протоколов TCP/IP, и это как бы развивает предыдущее утверждение. И действительно, если не знать деталей, то может показаться логичным, что были протоколы OSI и TCP/IP, OSI мы не используем, а TCP/IP используем, следовательно OSI пора отправиться в помойку, а TCP/IP - это актуально и современно. В реальности все интереснее, потому что на самом деле дела обстоят с точностью до наоборот.
Стек протоколов TCP/IP впервые был описан в середине 70-х, и за 10 лет, пока бюрократы из ISO корпели над идеальной моделью, он завоевал бешеную популярность. В отличие от «эталонного» стека протоколов OSI, который проектировали долго и коллективно, стек TCP/IP появился снизу — как практическое решение конкретных, срочных задач по объединению разнородных сетей для ARPANET и других исследовательских проектов США. Его принимали не потому, что он был идеален с инженерной точки зрения или соответствовал некой строгой теории, а потому что он работал, распространялся бесплатно и быстро адаптировался под нужды очень разных участников: университетов, лабораторий, крупных компаний. В этом стеке было три протокола: нижележащий канальный протокол, каждая сеть могла использовать свой, но были и рекомендованные варианты, поверх него работал протокол межсетевого интерконнекта (IP), поверх него транспортный протокол (TCP или UDP), и внутри него передавало данные непосредственно приложение.
Решающее значение имело то, что TCP/IP быстро стал универсальной «прививкой» для самых разных сетей — протоколы внедряли по факту, а не по указу сверху. К началу 80-х годов он постепенно вытеснил множество фирменных и отраслевых решений, а с развитием интернета — стал негласной основой глобальной связи.
При этом, вопреки мифу, модель TCP/IP изначально вообще не претендовала на универсальность и не предлагала единственного «правильного» способа построения систем обмена данных — она была, прежде всего, про интернет: удобно, быстро, практически; и стандартизована лишь постфактум. Этот подход никогда не претендовал на то, чтобы быть эталонным, и “моделью” его стали называть уже в 90-х, как отражение того факта, что в интернете IP победил всех конкурентов. В этой модели четырьмя уровнями стали именно три протокола (канальный, сетевой и транспортный) и приложение как четвертый, высший уровень. В самом простом сценарии это очень здорово совпадало с тем, что при передаче последовательно шли заголовки трех протоколов, а затем данные приложения.
При этом откровенно говоря, в современных сетях мы часто используем протоколы из стека IP совершенно не так, как это предлагали делать отцы-основатели, к четырем служебным протоколам (канальному, сетевому и транспортному) повсеместно добавляются различные туннельные, всякие слои шифрования, ВПНы и прочая ерунда, о которой даже подумать не могли в 74 году, поэтому из двух моделей устарела сегодня именно модель TCP/IP.
OSI, напротив, будучи моделью необычайно общей, прекрасно дружит с любыми новомодными штуками. Главное - не забывать, что по кучкам (или уровням) она раскладывает не протоколы, а задачи, а к порядку передачи заголовков по сети она отношения не миеет и никогда не имела.
Возьмём самый классический и до сих пор основной протокол — TCP (Transmission Control Protocol). В теории, по модели OSI, у нас отдельно есть транспортный уровень (доставка данных между программами на разных компьютерах), отдельно — сессионный (управление началом, поддержанием и завершением общения), отдельно — представление (например, преобразование форматов или шифрование). Но на практике TCP решает задачи сразу нескольких уровней. Когда вы открываете браузер и он подключается к сайту, TCP сам устанавливает соединение между вашим компьютером и сервером. Это называется «трёхэтапное рукопожатие» — специальный процесс, гарантирующий каждому участнику, что другая сторона действительно готова общаться. Формально, это задача сеансового уровня, но она включена в TCP. Если вы отправили длинное сообщение — TCP разобьёт его на части, пронумерует их и отправит по очереди. Даже если части получателю пришли в разном порядке, он их соберет правильно. Такая «сборка-разборка» должна относиться к уровню представления — но снова, делает всё TCP. Если нужно между двумя узлами передавать несколько потоков данных (например, скачивать одновременно два файла, чтобы их содержимое не перемешивалось между собой) - это задача транспортного уровня, но TCP решает и ее. В модели OSI он решает задачи сразу нескольких уровней, и это прекрасно работает. Современные протоколы идут ещё дальше и делают всё возможное, чтобы ваша музыка, картинка или чат не зависели от деталей сетевой магистрали — даже если это приходится решать пачкой функций из разных уровней в рамках одного протокола.
Следом стоит поговорить о том, почему архитектурное мышление оказалось таким живучим — не только в истории, но и в повседневной инженерной практике. Семь уровней OSI или четыре уровня TCP/IP для многих сегодня — примеры «классических методичек», неких скучных схем из учебников, которые нужно зазубрить, а иначе ты не настоящий сетевик. На деле же сила уровневого подхода — не в количестве ступеней, а в самом принципе разделения ответственности.
Этот принцип — ключ к надёжности: если вы меняете что-то в одном уровне, будь то провод связи или формат прикладного сообщения, ни инфраструктура всей сети, ни сами приложения не разваливаются. Заменили медный кабель на оптоволокно? Это изменение, изменит только самый нижний уровень — а данные по-прежнему летят так, как нужно верхним слоям. Решили поменять способ шифрования или добавить компрессию файлов? Вы знаете, что это задачи слоя представления, поэтому возможно, что под это придется адаптировать другие задачи слоя представления, но сетевая архитектура и приложения этого даже не должны заметить. В рамках системы, построенной по уровневым принципам, что добавление шифрования вызывает необходимость заменить провод на другой, который такое шифрование поддерживает.
Именно такой подход позволил сетям эволюционировать — ведь никто заранее не знал, какое оборудование, протоколы передачи или даже какие типы данных понадобятся через десять-двадцать лет. Уровневая архитектура работала как страховка: если меняется что-то важное в одном месте, нет нужды переписывать всё остальное. В этом — главная причина, почему идея модели OSI выжила, «пережила» большинство собственных протоколов, и скорее всего будет оставаться актуальной еще очень долго.
В результате современный интернет во многом работает вопреки ожиданиям проектировщиков 1970-х, но по фундаментальным принципам, которые они заложили. Каждый новый протокол — для безопасности ли, скорости или удобства — опирается на разумный анализ: стоит ли создавать уровень заново, вынести часть функций наружу или встроить прямо «внутрь» ради сокращения задержек и экономии ресурсов?
Модели остаются живы потому, что дают общий язык и способ договориться, но сам интернет напоминает не застывшую машину, а скорее гибкую транспортную систему, которая беспрестанно меняется по ходу движения.
В следующий раз, отправляя сообщение или открывая ссылку в браузере, вспомните: за вашей командой скрывается целая архитектура, где на каждом уровне кто-то берёт ответственность за то, чтобы ваши данные дошли без потерь и задержек. Интернет действительно строится по слоям — не всегда по строгому стандарту, но обязательно по разуму, изобретательности и опыту поколений инженеров. А если вдруг что-то не сработало — не переживайте: через пару секунд, минут или новых стандартов оно до вас обязательно дойдёт.

Этот выпуск для вас подготовил ведущий Иннокентий Солнцев и звукорежиссер Алексей Попов