Технологии компьютерных сетей весна 2018 — различия между версиями
м |
(Задание 2) |
||
(не показаны 3 промежуточные версии этого же участника) | |||
Строка 16: | Строка 16: | ||
Порядок выполнения: | Порядок выполнения: | ||
− | # Сделать форк [https://github.com/h31/ | + | # Сделать форк [https://github.com/h31/NetworksLab2018AU репозитория] на GitHub. |
# Для каждого задания сделать отдельную ветку (branch) в своём репозитории. | # Для каждого задания сделать отдельную ветку (branch) в своём репозитории. | ||
# Работать над кодом, сохраняя файлы в соответствующей заданию директории. | # Работать над кодом, сохраняя файлы в соответствующей заданию директории. | ||
Строка 42: | Строка 42: | ||
* Сервер не знает о длине получаемых сообщений. | * Сервер не знает о длине получаемых сообщений. | ||
− | Язык программирования - | + | Язык программирования - С или C++. Для сборки кода используйте утилиту CMake. Для организации работы с несколькими клиентами используйте потоки. Не забывайте использовать примитивы синхронизации для блокировки общих между несколькими клиентами ресурсов. |
Результатом выполнения задания должно быть 4 программы, клиент и сервер под Windows и Linux/BSD/macOS, и описание вашего прикладного протокола. Протокол можно описать либо с помощью текста, либо с помощью изображений (таблицы, схемы и т.д.). Примеры описания протоколов - в слайдах лекций. Описание должно быть в такой степени подробным, чтобы по нему можно было написать альтернативную совместимую реализацию клиента/сервера. | Результатом выполнения задания должно быть 4 программы, клиент и сервер под Windows и Linux/BSD/macOS, и описание вашего прикладного протокола. Протокол можно описать либо с помощью текста, либо с помощью изображений (таблицы, схемы и т.д.). Примеры описания протоколов - в слайдах лекций. Описание должно быть в такой степени подробным, чтобы по нему можно было написать альтернативную совместимую реализацию клиента/сервера. | ||
Строка 49: | Строка 49: | ||
Крайний срок выполнения: '''18 марта''' в 23:59. К этому времени необходимо выполнить задание, выложить его на GitHub и сделать Pull Request. Замечания преподавателя '''можно''' исправлять после дедлайна, но учтите, что в таком случае вы будете отнимать у себя время на выполнение следующих заданий. | Крайний срок выполнения: '''18 марта''' в 23:59. К этому времени необходимо выполнить задание, выложить его на GitHub и сделать Pull Request. Замечания преподавателя '''можно''' исправлять после дедлайна, но учтите, что в таком случае вы будете отнимать у себя время на выполнение следующих заданий. | ||
+ | |||
+ | === Задание 2. Простейший UDP-клиент/сервер === | ||
+ | |||
+ | Необходимо реализовать клиент и сервер протокола DNS. | ||
+ | |||
+ | Отличия относительно предыдущего задания: | ||
+ | * ОС - одна, какая именно - на ваш выбор. | ||
+ | * Не нужно описывать протокол. | ||
+ | |||
+ | Подразумевается, что протокол будет реализован на минимальном рабочем уровне. Рассчитывайте на следующие ограничения: | ||
+ | * Поддержка только записей типа A. | ||
+ | * Сервер может указывать любой адрес в ответе. Это может быть хэш доменного имени, адрес из файла (например, /etc/hosts), случайная величина с seed равным длине доменного имени в запросе или что-то другое на ваш выбор. Единственное пожелание - чтобы возвращаемый адрес был функцией от доменного имени в запросе и указанного файла на локальном компьютере и не зависел бы от других величин (для обеспечения идемпотентности запроса). Также возможна реализация сервера, который бы с помощью вызовов getaddrinfo/gethostbyname запрашивал адреса из реальной DNS-сети. | ||
+ | * В ответе не нужно указывать ни авторитативные сервера, ни дополнительные записи. Только непосредственно ответы. | ||
+ | |||
+ | Для экономии времени можно в качестве шаблона запроса/ответа использовать захваченный сниффером пакет. В Wireshark для этого есть функция Export as C Arrays. | ||
+ | |||
+ | Для проверки разработанного DNS-сервера используйте консольные утилиты host, dig или nslookup, явно указав им обращаться к серверу на том же компьютере. Для проверки DNS-клиента используйте любой существующий DNS-сервер, например, Google Public DNS (8.8.8.8). | ||
+ | |||
+ | [https://tools.ietf.org/html/rfc1035 RFC на протокол DNS]. Кроме того, есть множество упрощенных описаний протокола DNS. | ||
+ | |||
+ | === План выполнения работ === | ||
Текущий план: | Текущий план: | ||
Строка 76: | Строка 97: | ||
** IGMP. | ** IGMP. | ||
** Снифферы. Wireshark, tcpdump. Задание правил. | ** Снифферы. Wireshark, tcpdump. Задание правил. | ||
− | ** Network Namespaces | + | ** Network Namespaces. |
− | ** InfiniBand | + | ** InfiniBand. |
* Особенности использования существующих протоколов | * Особенности использования существующих протоколов | ||
** Протокол TCP. Алгоритмы контроля перегрузок. | ** Протокол TCP. Алгоритмы контроля перегрузок. |
Текущая версия на 10:19, 20 марта 2018
Содержание
Лекции
Преподаватель: Ицыксон Владимир Михайлович (vlad@ftk.spbstu.ru, itsykson@gmail.com)
Практика
Преподаватель: Алексюк Артем Олегович (aleksyuk@kspt.icc.spbstu.ru, artyom.aleksyuk@gmail.com)
Telegram-группа для взаимодействия в ходе курса. Участвовать не обязательно, но очень желательно. В группе будут выкладываться объявления по курсу, кроме того, преподаватель будет по мере возможности отвечать там на вопросы. Основные объявления будут дублироваться в SeWiki.
Задания
Порядок выполнения:
- Сделать форк репозитория на GitHub.
- Для каждого задания сделать отдельную ветку (branch) в своём репозитории.
- Работать над кодом, сохраняя файлы в соответствующей заданию директории.
- В тот момент, когда вы будете готовы показать свой код (для проверки или консультации), сделать Pull Request в мою ветку master.
- Исправить замечания преподавателя.
- Дождаться статуса Approved у вашего Pull Request-а.
Задание 1. Простейший TCP-клиент/сервер (мессенджер Elegram)
Необходимо разработать простейшую систему обмена мгновенными сообщениями (чат, мессенджер). Чат-сервер должен принимать сообщения от клиентов и рассылать полученные сообщения всем подключенным клиентам. У каждого клиента должен быть собственный никнейм, задаваемый пользователем. При получении сообщения от другого клиента, на экран должно выводиться время получения сообщения, никнейм пользователя-отправителя и текст сообщения. Пример вывода: <4:20> [Peter] Hello!
Клиент должен иметь консольный интерфейс. Параметры работы клиент принимает через аргументы командной строки в следующем порядке: адрес сервера, порт, никнейм. Функции, которые не требуются от сервера и клиента:
- Регистрация клиентов, авторизация, аутентификация.
- Более чем один канал общения.
- Хранение истории переписки.
- Обработка временных зон.
- Работа с языками, отличными от английского.
Чтобы принимаемые (входящие) сообщения не мешали пользователю вводить свой текст, предлагается включать отдельный режим отправки сообщения, например, при нажатии клавиши m. В этом режиме пользователь вводит своё сообщение, новые сообщения от других пользователей временно не отображаются, после отправки сообщения (по Enter) режим автоматически отключается.
Предполагается, что клиент и сервер будут созданы на основе шаблона, находящегося в директории tcp_template репозитория. Шаблон заведомо неполный, в нем необходимо устранить следующие проблемы:
- В коде сервера отсутствуют вызовы для корректного закрытия сокетов.
- Сервер завершается после обработки первого же запроса.
- Сервер способен работать одновременно только с одним клиентом.
- Сервер не знает о длине получаемых сообщений.
Язык программирования - С или C++. Для сборки кода используйте утилиту CMake. Для организации работы с несколькими клиентами используйте потоки. Не забывайте использовать примитивы синхронизации для блокировки общих между несколькими клиентами ресурсов.
Результатом выполнения задания должно быть 4 программы, клиент и сервер под Windows и Linux/BSD/macOS, и описание вашего прикладного протокола. Протокол можно описать либо с помощью текста, либо с помощью изображений (таблицы, схемы и т.д.). Примеры описания протоколов - в слайдах лекций. Описание должно быть в такой степени подробным, чтобы по нему можно было написать альтернативную совместимую реализацию клиента/сервера.
Бесплатная виртуальная машина с триальной версией Windows. Для сборки программного кода использовать либо Visual Studio (подойдет Community или Express редакция), либо один из дистрибутивов MinGW. Лично у меня успешно заработал TDM-GCC.
Крайний срок выполнения: 18 марта в 23:59. К этому времени необходимо выполнить задание, выложить его на GitHub и сделать Pull Request. Замечания преподавателя можно исправлять после дедлайна, но учтите, что в таком случае вы будете отнимать у себя время на выполнение следующих заданий.
Задание 2. Простейший UDP-клиент/сервер
Необходимо реализовать клиент и сервер протокола DNS.
Отличия относительно предыдущего задания:
- ОС - одна, какая именно - на ваш выбор.
- Не нужно описывать протокол.
Подразумевается, что протокол будет реализован на минимальном рабочем уровне. Рассчитывайте на следующие ограничения:
- Поддержка только записей типа A.
- Сервер может указывать любой адрес в ответе. Это может быть хэш доменного имени, адрес из файла (например, /etc/hosts), случайная величина с seed равным длине доменного имени в запросе или что-то другое на ваш выбор. Единственное пожелание - чтобы возвращаемый адрес был функцией от доменного имени в запросе и указанного файла на локальном компьютере и не зависел бы от других величин (для обеспечения идемпотентности запроса). Также возможна реализация сервера, который бы с помощью вызовов getaddrinfo/gethostbyname запрашивал адреса из реальной DNS-сети.
- В ответе не нужно указывать ни авторитативные сервера, ни дополнительные записи. Только непосредственно ответы.
Для экономии времени можно в качестве шаблона запроса/ответа использовать захваченный сниффером пакет. В Wireshark для этого есть функция Export as C Arrays.
Для проверки разработанного DNS-сервера используйте консольные утилиты host, dig или nslookup, явно указав им обращаться к серверу на том же компьютере. Для проверки DNS-клиента используйте любой существующий DNS-сервер, например, Google Public DNS (8.8.8.8).
RFC на протокол DNS. Кроме того, есть множество упрощенных описаний протокола DNS.
План выполнения работ
Текущий план:
- До 18 марта - первое задание (2,5 недели).
- До 28 марта - второе задание (1,5 недели).
- До 25 апреля - первая часть третьего задания (4 недели).
- До 23 мая - вторая часть третьего задания (4 недели).
Темы для обсуждения на практических занятиях
- Администрирование сетевых сервисов
- HTTP-сервер. Nginx, Apache httpd, особенности, администрирование. HTTP/2, TLS в HTTP-сервере.
- FastCGI, реверсивные прокси.
- Файлообменные серверы. FTP, NFS, SFTP, SMB-сервер. Rsync.
- VPN-сервер. IPsec, OpenVPN, Wireguard. Сравнение, администрирование. Site-to-site. Туннели.
- SSH-сервер и всё, что он умеет делать. Авторизация по ключам, ssh-agent, проброс портов, VPN и т.д.
- Почтовый сервер. SMTP, IMAP-сервер.
- DNS, DHCP-сервер.
- Администрирование компьютерных сетей
- IPv6. Настройка, особенности.
- Настройка сети в GNU/Linux. Старые и новые утилиты. ifconfig, netstat, ip, ss.
- Утилита tc. Шейпинг трафика, имитация особенностей различных каналов связи.
- Отладка компьютерных сетей. mtr, traceroute, ping, iperf3.
- VLAN, коммутация пакетов.
- NAT, прокси.
- QoS.
- AS, looking glass, IX, маршрутизация в Интернете.
- IGMP.
- Снифферы. Wireshark, tcpdump. Задание правил.
- Network Namespaces.
- InfiniBand.
- Особенности использования существующих протоколов
- Протокол TCP. Алгоритмы контроля перегрузок.
- Задержки в сети. Round trip time т.п.
- MTU, MSS, фрагментация, туннели.
- Сериализация данных.