Здравствуйте, mrTwister, Вы писали:
Pzz>>Я тут подумал, и у меня в голове нарисовался след. учебный план.
T>Про маршрутизацию не хватает: OSPF, BGP
Боюсь, столько не впихнуть.
Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей) в разговоре об различии между MAC и IP адресами, но мне кажется, сильно дальше этого идти не обязательно.
Здравствуйте, Pzz, Вы писали:
Pzz>Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей) в разговоре об различии между MAC и IP адресами, но мне кажется, сильно дальше этого идти не обязательно.
Не знаю, не уверен. Весь интернет работает на BGP. Это максимально фундаментальная технология, которая буквально находится в основе всего современного IT. И при этом про нее почти никто ничего не знает.
Здравствуйте, mrTwister, Вы писали:
Pzz>>Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей) в разговоре об различии между MAC и IP адресами, но мне кажется, сильно дальше этого идти не обязательно.
T>Не знаю, не уверен. Весь интернет работает на BGP. Это максимально фундаментальная технология, которая буквально находится в основе всего современного IT. И при этом про нее почти никто ничего не знает.
Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
Я тоже, должен признаться, мало чего знаю про BGP...
LVV>Но практика вызывает у меня вопросы. LVV>Непонятно, с чего начинать и чем заканчивать. LVV>Ну, писание клиента и сервера — это понятно. LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
но сервера же не только для веб-страниц бывают. игрушки и всякие телеграммы имеют вполне себе самописные сервера.
J>>Модель osi . 90% программистов очень далеки от ее понимания.
Pzz>Она слишком академичная. Стек TCP/IP плохо на неё ложится.
Это смотря как его подать Когда я учился в институте, у нас был преподаватель фанат OSI.
Каждая лекцию / зачет он обязательно ее вспоминал и дотошно спрашивал у каждого студента . Сейчас ,по прошествии лет, благодаря этому
у меня не возникает никаких проблем с настройкой новой сетевой железки .
Если студент в последствии попадет в авиацию, море и прочие конторы, где много пропитанных протоколов , хорошее знание osi тоже лишнем не будет
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Janus, Вы писали:
Pzz>>Она слишком академичная. Стек TCP/IP плохо на неё ложится.
J>Это смотря как его подать Когда я учился в институте, у нас был преподаватель фанат OSI. J>Каждая лекцию / зачет он обязательно ее вспоминал и дотошно спрашивал у каждого студента . Сейчас ,по прошествии лет, благодаря этому J>у меня не возникает никаких проблем с настройкой новой сетевой железки .
На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
J>Если студент в последствии попадет в авиацию, море и прочие конторы, где много пропитанных протоколов , хорошее знание osi тоже лишнем не будет
Ну, наверное умение работать в авиации, это отдельный навык. Требующий, например, умения выживать при сильно формализованном процессе.
Здравствуйте, Pzz, Вы писали:
Pzz>На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
Любой впн находится в квантовой суперпозиции, являясь одновременно и транспортом и пэйлоадом, независимо от хендшейка и мнения наблюдателя.
Здравствуйте, Stanislaw K, Вы писали:
Pzz>>На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
SK>Любой впн находится в квантовой суперпозиции, являясь одновременно и транспортом и пэйлоадом, независимо от хендшейка и мнения наблюдателя.
Тут важно, чтобы от него не отваливался какой-нибудь кусок под воздействием недоброго взгляда наблюдателя.
Здравствуйте, Pzz, Вы писали:
Pzz>Я имел ввиду затронуть маршрутизацию по префиксам (и прочие там классы сетей)
"Классы сетей" уже несколько десятилетий как не используются Classless Inter-Domain Routing появился в 1993 году. Такие архаичные термины не стоит и упоминать т.к. это тупиковая ветвь эволюции.
По хорошему должен быть отдельный предмет, где 7 уровней модели OSI и соответсвующие протоколы рассмастриваются. Сетевое программирование это уже обычно прикладные протоколы и API OS — те самые сокеты.
Если начинать с низов, то как минимум надо показать и объяснить что такое tcpdump, traceroute, ip a & co, wireshark. Looking glass сервисы и AS. DHCP и прочее DNS с HTTP это уже самая верхушка сетевого айсберга.
Здравствуйте, Pzz, Вы писали:
Pzz>Она слишком академичная. Стек TCP/IP плохо на неё ложится.
Прекрасно ложится, просто не для каждого уровня есть отдельный протокол.
Здравствуйте, Marty, Вы писали:
LVV>>Но про программирование в винде аж 5 глав подряд написано.
M>Ну, в винде есть дополнительная пачка функций WSA*, может про них? А так, API беркли сокетов точно такое же, только, как уже сказал, ioctl по другому называется, и нет poll (когда я активно с сетью возился, его не особо было и линупсах и прочих бздях). Сейчас, наверное, уже подвезли.
poll'а нет, зато есть overlapped и I/O completion ports
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, Stanislav V. Zudin, Вы писали:
M>>Ну, в винде есть дополнительная пачка функций WSA*, может про них? А так, API беркли сокетов точно такое же, только, как уже сказал, ioctl по другому называется, и нет poll (когда я активно с сетью возился, его не особо было и линупсах и прочих бздях). Сейчас, наверное, уже подвезли.
SVZ>poll'а нет, зато есть overlapped и I/O completion ports
Pzz>На каком уровне OSI находится IP-level VPN, который использует HTTPS для авторизации, а потом уходит в WebSocket, используя его в качестве транспорта для пакетов?
Это вопрос из серии как рассматривает самолет летчик и пассажир .
Есть еще L2TPv3 на каком уровне OSI он находится ?
J>>Если студент в последствии попадет в авиацию, море и прочие конторы, где много пропитанных протоколов , хорошее знание osi тоже лишнем не будет
Pzz>Ну, наверное умение работать в авиации, это отдельный навык. Требующий, например, умения выживать при сильно формализованном процессе.
дело не формализации. Любое сетевое взаимодействие можно описать моделью osi . Обсуждая с коллегами проприетарную сеть (протокол) вы поймете друг друга
... Хорошо уметь читать между строк. Это иногда
приносит большую пользу
Здравствуйте, Pzz, Вы писали:
SK>>Любой впн находится в квантовой суперпозиции, являясь одновременно и транспортом и пэйлоадом, независимо от хендшейка и мнения наблюдателя.
Pzz>Тут важно, чтобы от него не отваливался какой-нибудь кусок под воздействием недоброго взгляда наблюдателя.
Здравствуйте, Pzz, Вы писали:
Pzz>Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
Может быть, не знаю. Но для меня странно, что доставка пакетов из точки А в точку Б на другом конце света объясняется магией и это всем ок
Pzz>Я тоже, должен признаться, мало чего знаю про BGP...
Да я сам не так давно в эту тему начал погружаться и был в шоке от своей некомпетентности. Я понял, что вообще не понимал, как работает интернет и очень мне бы хотелось, чтобы про BGP мне рассказали еще в университете. Благо его придумали 36 лет назад, это не какая-то новомодная технология
Здравствуйте, LaptevVV, Вы писали:
LVV>В общем, основной вопрос: чего давать в лабах.
А у вас то кейс какой? Системный или прикладной? Есть у студентов курс типа "сети" или это первое знакомство?
Если прикладной, то нужно смотреть адресацию, http api udp tcp dns, таймауты-обрывы. Минимально протоколы, фокус на различные задачи — передача файлов, чат, восстановление после обрыва, итд.
Здесь можно писать хоть на чем, абы работало.
Если системный — то это протоколы, сокеты и подобные вещи. Тут нужно чтото низкоуровневое, вещи типа nodejs не сгодятся.
Если курса по сетям не было, то нужно дать какую то картину мира tcp/ip osi/iso адресация порты итд, что бы могли это попробовать при помощи утилит — ping, tracert, ifconfig, route, netstat итд.
Тут я бы потратил 2 лабы чисто на докер и похожие вещи, что бы люди могли соорудить сеть и попробовать на ней разные инструменты. Если с докером тупик, то нужно чтото другое, мб ssh, telnet
Уже после этого приступать к тем самым сокетам.
Вы можете давать студентам какие то заготовки хоть на Go, что бы они дорабатывали под конкретную лабу. В этом случае вы можете увеличить объем задания, т.к. студенты будут стартовать "с трамплина"
Здравствуйте, mrTwister, Вы писали:
Pzz>>Может это не такое уж и обязательное знание, если о нём почти никто ничего не знает?
T>Может быть, не знаю. Но для меня странно, что доставка пакетов из точки А в точку Б на другом конце света объясняется магией и это всем ок
Ну почему магией? Маршрутом...
Pzz>>Я тоже, должен признаться, мало чего знаю про BGP...
T>Да я сам не так давно в эту тему начал погружаться и был в шоке от своей некомпетентности. Я понял, что вообще не понимал, как работает интернет и очень мне бы хотелось, чтобы про BGP мне рассказали еще в университете. Благо его придумали 36 лет назад, это не какая-то новомодная технология
А что в Интернете придумали не несколько десятков лет назад?
Здравствуйте, LaptevVV, Вы писали: LVV>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
Типа, зачем программировать, когда всё уже сделано до нас? Ну не программируйте, ПТУ по настройке nginx на соседней улице.
LVV>1. С++. Стандартной библиотеки нет.
База — это сокеты на С.
LVV>Но у меня 100500 книжек по программированию на основе сокетов.
Если про UNIX речь, классика — книги Стивенсона.
Но впрочем, и в винде API сокетов — перепев из юниксового API.
LVV>В точ числе и Ntnlink-сокеты.
Это всё внутрилинуксовая хрень, для программирования сетей не нужно.
LVV>Ну, тоже лучше питона, но менее приятно, чем Go
да, нафиг этот JS выкинуть из головы
LVV>В общем, основной вопрос: чего давать в лабах.
1) Пишем UDP клиент-сервер. Размыкаем кабель. Видим, что сообщение пропущено, и сетевому стеку пофиг.
Пишем TCP клиент-сервер. Размыкаем кабель. Видим, что сообщение НЕ пропущено, потому что сетевому стеку НЕ пофиг.
2) Первый вариант сервера — однопоточный, с мультиплексированием I/O.
Второй вариант сервера — многопоточный, работа с каждым клиентом в отдельном потоке.
3) Пишем сервер для ооочень большого количества клиентов (epoll), нагружаем.
Здравствуйте, student__, Вы писали:
__>Здравствуйте, LaptevVV, Вы писали: LVV>>Но студенты зададут вопрос: а зачем nginx, IIS и проие всякие апачи, если сервер надо писать самим7
__>Типа, зачем программировать, когда всё уже сделано до нас? Ну не программируйте, ПТУ по настройке nginx на соседней улице.
То есть учиться программировать сокеты нужно из любви к искусству?
Потому что в голове преподавателя нарисован такой образ сетевого программиста?
Изучение чего угодно действительно начинается с предпосылок для применения и с границ применимости.
Формируется навык: выбирать подходящие средства для реализации сетевого взаимодействия.
(2LaptevVV) Студентам я бы изложил так.
Программирование на сокетах нужно:
* Для реализации кастомных протоколов, которые нужны:
* * Когда оверхед слишком большой:
* * * по доле служебных полей в трафике (никакой HTTP в 64 бита CAN не влезет);
* * * по тяжести разбора (реализация DHCP и TFTP в PXE);
* * * по риску багов в реализации (регулярно находят CVE в реализациях HTTP/2).
* * Когда схема работы отличается от "запроса-ответа": однонаправленная передача (телеметрия) или multicast (service discovery).
* Для реализации стандартных протоколов, которая может потребоваться:
* * Если её нет под нужную платформу или под какие-то требования (Pzz уже выступал).
* * Чтобы эффективно читать данные без промежуточных структур (сотни тысяч сообщений Netflow/sFlow в секунду).
* Для передачи дескриптора между процессами в *nix (SCM_RIGHTS), которое нужно:
* * Чтобы разделить управляющий процесс и воркеров (как в том же Nginx);
* * ЧТобы обновлять или перезапускать программу без разрыва существующих соединений (как nginx -s reload).
* Для оптимизации производительности с помощью ОС-специфичных средств (recvmmsg/sendmmsg, SO_ATTACH_FILTER, управление буфером).
Границы применимости:
* Сокетов может не быть в микроконтроллере без ОС. (Более экзотический случай: когда мы уже работаем в обход ядра.)
* Обычные (не AF_PACKET) сокеты не предназначены для обработки транзитного трафика на неопределенные адреса, т. е. в задачах файерволов и т. п.
* Производительность сокетов принципиально ограничена копированием между ядром и userspace, системными вызовами и производительностью ядра. (А как тогда? DPDK, eBPF.)
Аналогично есть причины изучать протоколы, диагностику сети и сокетов.
Какие из причин релевантны для студентов в рамках дисциплины — зависит от специальности и учебной программы.
Например, нашему "Управлению в технических системах" упомянутый в теме BGP напрочь не нужен, а "Вычислительным машинам, системам и сетям" — обязателен (хотя это уже не сетевое программирование).
__>1) Пишем UDP клиент-сервер. Размыкаем кабель. Видим, что сообщение пропущено, и сетевому стеку пофиг. __>Пишем TCP клиент-сервер. Размыкаем кабель. Видим, что сообщение НЕ пропущено, потому что сетевому стеку НЕ пофиг.
Видим, что send/sendto отрабатывает одинаково успешно, данные одинаково не приходят.
Тут-то и начинается настоящая лаба с инспекцией системы и трафика
Правда, всё еще непонятно, зачем для этого уметь программировать сокеты.
