Comments 31
Вот это вот что вообще было? Вы серйозно считаете, что человек, выдающий все эти детали, будет вам нужнее другого? А отдельный жанр - это скопированные вопросы от собеседования к собеседованию. В общем, здесь плохо почти все.
Наверное, это была попытка объяснить всю сложность современной сети в рамках одной статьи.
Написано гладко, но тому, кто всё это знает, видно, что осталось за кадром, а тому, кто всё это не знал, мне кажется, столько одним глотком не проглотить.
Да. Всю полноту сетей не уместить в формат статьи. Тут освещены только основные аспекты. Исчерпывающий материал есть в книгах по сетям, которые в объеме начинаются от 1000-1500 страниц ;)
Исчерпывающий материал
К сожалению, его там нету.
Например, я не знаю ни одной книжки, которая учит сетевому программированию не в парадигме 80-х - 90-х, когда компьютеры в сети были соединены в основном проводами, конфигурация была в основном статическая, и если, к примеру, какой-то роутер в пути отправлялся в перезагрузку, то связь временно пропадала и потом восстанавливалась в той же конфигурации, а современным сетям, в которых большая часть участников - это мобильные устройства, сидящие на временном соединении, и стабильность хоть каких-либо аспектов конфигурации никто не обещал (даже вплоть до того, что DNS может возвращать всё время разные адреса для одного и того же имени).
Да, ты прав и это очень интересный тезис. Хоть литература существующая по сетям фундаментальна, но как ты сказал отражает парадигму тех лет. Эта тема явно требует продолжения с оглядкой на текущие реалии и технологии)
Спасибо за замечание!
Ну почему же. Очень даже полезная литература прошлых лет. И программирование надо уметь, если архитектор стать хочешь. И сети телефонной и спутниковой связи. Поэтому очень даже пригодится, если хочешь в архитектуру сетей.
Вообще сети разрабатывали программисты со связистами. Так что — есть один универсальный ответ:
читать стандарты, все правки, получить фундаментальное образование, и конечно перечитать те самые книги из прошлого века.
Все описано в стандартах, все ответы там
Да ну все эти книги, «бла-бла-бла». Шучу.
Пара тройка курсов Cisco, и ты архитектор;)
Картинки не информативны - нет перевода на русский язык.
Не похоже на что-то полезное. В тексте россыпь аббревиатур и сугубо технических нюансов, плюс сам текст явно "выковырян" из нейронки. Это пример того, что (и как!) писать вообще не надо. Имхо, я не заставляю)
У меня на собеседованиях вопрос "Что происходит, когда в браузере набрали URL и нажали Enter" один из любимых, и задаю его когда кандидат плавает, чтобы понять, что человек вообще понимает в происходящем вокруг. Сразу же поясняю кандидату, что отвечать можно вообще всё что угодно. Это как вариант "на поговорить". Если человек сразу рассказывает всё что надо подробно, тогда такой вопрос не задаётся.
Фактически протоколы Интернета соответствуют уровням OSI примерно так
Поэтому на собеседованиях нужно отвечать, что "модель OSI - устарела".
Понимание этого процесса важно для инженеров
Сисадмины и инженеры (сетевые) и так это все знают отлично. Разработчикам эти знание вообще не нужны, если только в соло что-то сложное не писать, а если и нужны, то курс Сети для самых маленьких - самое оно. Для соответствующих хабов уровень "Сложное" выглядит как-то не соответствующе.
а зачем надо знать про ОСИ если я если соприкасаюсь с сеткой то это сокет, а сокет это системный вызов, что еще мне надо знать прошу прощения ?) типо как вызвать системный вызов )
Да, при работе с сокетами может и не нужно постоянно думать про оси, но он даст понимание, допустим, почему socket.send() не все отправил, или почему socket.recv() висит 30 секунд 👐🏻
Потому, что когда программа начинает работать не как в книжке написано, надо как-то с этим уметь разбираться.
ОСИ может и не шибко поможет, а вот понимание, чего там в сетевом стеке под капотом творится, может и помочь.
У вас фундаментальная ошибка во фразе
Основные характеристики TCP: ..., гарантия доставки данных
Не знаю, кто это придумал, но TCP никогда не гарантировала доставку данных, так как это принципиально невозможно. И даже нет планов что-то изменить в этом плане.
Советую почитать книгу "Addison Wesley : UNIX Network Programming", где в частности сказано (жирным выделено мной):
Note that TCP does not guarantee that the data will be received by the other endpoint,
as this is impossible. It delivers data to the other endpoint if possible, and notifies the
user (by giving up on retransmissions and breaking the connection) if it is not possible.
Therefore, TCP cannot be described as a 100% reliable protocol; it provides reliable
delivery of data or reliable notification of failure.
Другими словами, TCP всего лишь предоставляет механизм сигнализации, что пакет доставлен, и клиент может повторно попытать отправить пакет, если не получен сигнал о доставке (то есть даже может быть ситуация, что пакет доставлен, но сигнал потерян). Это не гарантия того, что данные будут доставлены.
Спасибо за замечание, но!
TCP реализует надёжную доставку данных в том смысле, что он либо доставляет данные в правильном порядке без дубликатов, либо сообщает об ошибке, если это невозможно. То есть это «надежность на уровне попытки и уведомления», а не физическая гарантия принятия.
И в профильной литературе под "гарантией доставки" - это и имеется в виду
p.s: но я так же не могу отрицать проблемы переводов, интерпритаций и так далее
Либо есть сигнал и мы доставку гарарнтиуоем, либо закрываем сессию указывая ошибку и предлагая ее повторить.
Это не проблемы перевода — это так условились разработчики стандарта, что мы гарантируем доставку данных, такими-то методами, на соснове таких то правил, и уже если повторные ну никак не доходят, то условились отпускать сессию (закрывать соединение) с описанием ошибки (чтобы разобраться в каком слое сбой — это может быть физический даун или шторм в сети, петля, хакеры, «что угодно»), и предлогая пользователю повторить попытку с указанием ошибки. То есть нет смысла бесконечно повторять утерянные пакеты, так как раньше ресурсы компов и сетей пели романсы, а сейчас их не хватает на весь этот 4К контент и ИИ революцию.
Так условились умные дяди и это работает и методологически не протеворечит здравому смыслу.
То есть гарантия есть, но если нижестоящие слои не обеспечивают связь, то от куда тебе вообще работать будет))))). Бабка свет вырубила на чердаке, а они от TCP гарантию требуют))))))
Чао
Говоря о негарантированности доставки пакета TCP в книге автор явно исходил из парадигмы протоколов X.25, где таковая доставка гарантируется. Насколько я помню теорию, пакет X.25 в буфере промежуточного узла сети передачи данных не будет удалён до момента получения сообщения о доставке до следующего узла, и соответственно передача пакета будет повторяться.
MTU и фрагментация
И ни слова о jumbo frame (
А можно ж ведь еще сказать, что если в гигабитную сеть воткнуто хоть одно 100-мегабитное устройство, то бродкасты-мультикасты будут передаваться на скорости 100 мегабит, а не на гигабите.
Причем передача юникастного пакета касается только двух дырок в свитче: передающей и приёмной. И остальным устройствам не мешает. А вот бродкасты-мультикасты передаются во все дырки одновременно.
Умничать так умничать! :)
Спасибо за статью, отличный, чоткий разбор по уровням модели OSI. Готовая шпаргалка. Здорово
Возможно слегка не по теме, но хотелось бы узнать. Кто-то знаком с книгой "unix разработка сетевых приложений". Если да, то интересно как настроить файлы, прилагающиеся к 3 изданию (в частности файлы директории libgai)?
Спасибо за внимание
Рука не поднимается минус поставить, но для кого эта статья? Девопсы и сетевые инженеры и так всё это знают. Для любителей и кто вкатывается в тему это не подъёмный материал. Кто серьёзно настроен, будет читать литературу, а не статьи на Хабре.
Компьютерные сети «под капотом»: детальный разбор по уровням OSI и TCP/IP