Комментарии 11
Сетевики и админы часто козыряют знанием наизусть модели OCI, даже на собеседованиях спрашивают. Но ни разу не видел применения этих знаний на практике.
Подскажите пожалуйста пример, когда в реальной жизни, работе, могут пригодится эти знания?
Когда у тебя в сети неизвестная проблема и ты открываешь Wireshark для диагностики
Во-первых, понимание модели OSI упрощает общение между сетевыми специалистами и теми, кто работает с сетевыми протоколами. Во-вторых знание модели помогает быстрее устранять проблемы, так как она позволяет легко определить, на каком уровне возникла неисправность, и как её устранить.
При разработке ПО и сетевого оборудования часто разные команды занимаются разными уровнями OSI. Например, разработчики аппаратного обеспечения обычно работают с уровнями 1-3, специалисты по маршрутизации — с уровнями 3-4, а разработчики приложений — с уровнями 5-7. Тестировщикам важно правильно определить, на каком уровне возникла проблема, и корректно передать информацию соответствующей команде разработчиков. Ведь, как известно, разработчики не любят баги и часто говорят, что у них "всё работает".
Специалистам, работающим с клиентами, также важно правильно объяснять им суть проблемы или особенности оборудования, поскольку сетевые устройства функционируют на разных уровнях OSI и выполняют различные задачи. Например, L2 и L3 коммутаторы оба называются коммутаторами, но они работают на разных уровнях модели OSI и выполняют разные функции. Если неверно трактовать свои знания о своем оборудовании, то знающий клиент откажется от сотрудничества.
А вот те, кто любят козырять знанием, вставляя в разговор цитаты из книг или бросаясь терминами, я обычно называю "сетевыми душнилами". Такие специалисты часто больше сосредоточены на демонстрации своих теоретических знаний, чем на реальном применении их на практике. Бывают и обратные случаи, когда практические знания превосходят теоретические. Настоящая ценность знаний, не только модели OSI, заключается в её практическом использовании, а не в умении блистать заумными фразами.
Можно уточнить?
Не совсем пойму, в какую сторону смотреть, что изучить?
Есть ПК, он в домене. Его сетевая карта (на материнской плате) в разъёме вставлен кабель) адрес пусть будет 192.168.1.12/24
В псие сетевую так делать вставлен кабель, но он от контроллера, что в этом же кабинете. Этот контроллер напрямую подключён без коммутаторов и другие моментов по езернет кабелю, 8p8c стандарт.
На ПК есть софт, который берёт данные с контроллера. В настройках ПО стоит айпи адрес такой же, как у второго сетевого адаптера. Адрес там типа АРИРА, который автоматически конфигурируется виндой.
Я не могу указать какой -то адрес из доменной сети указать в настройках ПО и поставить контроллер далеко от ПК, он должен быть напрямую подключён в ПК.
Вопрос, как и что нужно уточнить, чтобы через влан или другие технологии удалённо через коммутаторы пробросить ?
Например когда пользователь жалуется, что у него канал всего 10 Мб/с, хотя ты даёшь ему 100 Мб/с и отлично их промеряешь. Ты начинаешь анализировать проблему, видишь, что на канале большая задержка (неустранимая - концы канала на разных концах страны или канал через спутник) и тут ты начинаешь подозревать, что абонент использует TCP с фиксированным (или сильно ограниченным), что с учётом большой задержки приводит к тому, что TCP отсылает пакеты пока окно не закончится, а потом ничего не отправляет пока не начнет получать ответы о доставке пакетов.
По итогу советуешь абоненту проверить настройки TCP на своем старинном windows server 2008 (на удивление до сих пор встречается) и клиенте. По итогу скорость увеличивается в несколько раз.
Абонент стал немного довольнее (конечно, ты ведь частично сделал за него его работу, проведя описанный выше анализ), а ты понимаешь, что не зря когда разбирался во всех этих протоколах описанных в статье. Конечно какие-то вещи в подобных ситуациях сходу не вспомнишь, так как действительно не часто приходится пользоваться, но хотя бы будешь знать в какую сторону капать, чтобы не капали тебе на мозг.
И да, по работе замечал, что человек имеющий условно 50 часов теории и 100 часов практики, куда более полезен, чем тот кто имеет 300 часов практики не владея теорией.
Может немного сумбурно, но думаю суть ясна. И кстати ситуация примерно как описанная реально имела место быть на практике.
Очень понятно написано. Спасибо вам большое за труд, успехов !
В 99% подобных ситуаций это проблема не повторов TCP пакетов, а три другие проблемы:
Установления соединения. Например, css стиль или картинка лежит на другом сервере. А он не найден, или не работает. Браузер с этим ничего поделать не может, отобразить тоже.
Отсутствия ресурса. Сервер работает, но не может отдать требуемый ресурс. Потому что его не существует. Либо забыли положить на сервер, либо удалили, либо опечатка в запросе, либо сервер не смог обработать запрос, да мало ли причин для ошибок 4хх и 5хх.
Плохое соединение. TCP, конечно, запрашивает повтор потерянных пакетов, но если пропускная способность какого-либо участка канала от клиента до сервера низка, может получиться, что не смогли прийти ни основные ни повторные пакеты ни повторы повторов. Клиент не будет запрашивать повтор до бесконечности, а по таймауту закроет соединение. Что отобразится - зависит от того, что успели принять.
И бонусный 1%: вспомогательный ресурс изначально кривой, например ошибка в синтаксисе CSS или залита битая картинка.
TCP гарантирует доставку данных, но если соединение с сервером прерывается или теряется, загрузка может не завершиться. В этом случае браузер может получить часть данных или вовсе не получить их, что приведет к отображению страницы без стилей или с битой картинкой.
Иногда сервер может неправильно обработать запрос или не передать нужные данные (например, из-за высокой нагрузки или конфигурационных ошибок). Это может привести к тому, что браузер получит неполный или поврежденный файл.
Высокая задержка, потеря пакетов или другие сетевые проблемы могут привести к тому, что данные просто не успевают загрузиться в разумные сроки, и браузер может отобразить страницу в том виде, в котором она успела загрузиться на момент завершения соединения.
Сложно о простом. Транспортный уровень (L4) модели OSI