- Очистите кэш вашего браузера
- Запустите анализатор пакетов Wireshark
- Введите в адресную строку браузера следующий URL: http://gaia.cs.umass.edu/wireshark-labs/HTTP-ethereal-lab-file3.html
- Остановите захват пакетов Wireshark
- Найдите и запомните номер сообщения (крайний левый столбец), которое соответствует запросу HTTP GET, отправленному на адрес gaia.cs.umass.edu, а также номер сообщения, соответствующего началу ответного HTTP-сообщения, отправленного на ваш компьютер с gaia.cs.umass.edu
- Оставьте только пакеты, которые расположены ниже IP. Чтобы это сделать, выберите Analyze => Enabled Protocols и сбросьте флажок IP Protocol
- Выберите кадр Ethernet, в котором содержится сообщение HTTP GET (на основе номера сообщения из п. 5). Раскройте раздел Ethernet II.
- Каков 48-разрядный Ethernet-адрес вашего компьютера?
- Какому устройству соответствует значение Ethernet-адреса?
Перейдите на сообщение, которое соответствует ответному HTTP-сообщению (отклику).
- Каково значение исходного Ethernet-адреса? Какое устройство имеет такой Ethernet-адрес?
- Каков адрес назначения в этом Ethernet-кадре? Это Ethernet-адрес вашего компьютера?
- Очистите ARP-кэш. Для этого запустите команду:
arp –d *. Утилита arp находится для Windows C:\windows\system32, для Unix /sbin/arp или /usr/etc/arp - Повторите шаги 1-7 из предыдущего задания.
- Найдите два ARP сообщения (запрос и ответ). У запроса в поле Destination должно быть Broadcast.
- Каковы шестнадцатеричные значения исходного и конечного адресов в Ethernet-кадре,
содержащем сообщение с broadcast ARP-запросом?
- Содержится ли в ARP-сообщении IP-адрес отправителя?
- Где в ARP-запросе находится сама «вопросная часть» – Ethernet-адрес той машины, чей
соответствующий IP-адрес мы запрашиваем?
- Где в сообщении с ARP-откликом хранится Ethernet-адрес, который мы запрашивали на
основе соответствующего IP-адреса?
Продолжите работу с REST сервисом, созданным вами ранее в самом первом домашнем задании.
Поддержите возможность регистрации пользователя в вашем сервисе. При этом не используйте уже готовые фреймворки и решения. Предложите свою «наивную» реализацию.
В этом задании достаточно все данные хранить в памяти, т.о. базу данных использовать НЕ обязательно. Также вы можете при желании выгружать данные локально на диск (например, сериализовать в файл).
Пользователь регистрируется, его данные сохраняются на стороне сервиса.
Новые операции, которые должен поддерживать сервис:
- Зарегистрировать нового пользователя по адресу его почты и паролю
(email выступает в качестве логина пользователя).
POST /user/sign-up- Схема запроса:
{ "email": "string", "password": "string" }
- Авторизовать пользователя по логину и паролю. Сервис высылает обратно на сторону
клиента токен доступа (можно использовать случайно сгенерированную строку)
POST /user/sign-in- Схема запроса:
{ "email": "string", "password": "string" } - Схема ответа:
{ "token": "string" }
Теперь во все операции с сервисом клиент может передавать полученный токен. Если токен передан, то сервер понимает, кто это и разрешает доступ к расширенному функционалу.
- Добавить новый продукт
POST /product?token=<token>- Если токен был передан, то созданный продукт будет ассоциирован с данным пользователем
- Иначе продукт будет публичным
- Получить/Обновить/Удалить продукт
GET/PUT/DELETE /product/{product_id}?token=<token>- Если токен был передан, то пользователь помимо публичных продуктов имеет доступ к своим собственным
- Иначе пользователь имеет доступ только к публичным продуктам
- Получить список всех продуктов
GET /products?token=<token>- Аналогично операции получения одного продукта — авторизованный пользователь получает расширенный список продуктов
Продемонстрируйте работоспособность вашего решения с помощью программы Postman: запустите операции с токеном и без него и приложите скрин.
todo
Если пользователь использовал сервис без токена и посмотрел хотя бы один товар (по product_id или
список всех товаров), то ему на почту отправляется приветственный текст (например, "Рады видеть вас в
нашем сервисе вновь!").
Откуда сервису известен email пользователя? Сервис при регистрации пользователя запоминает IP-адрес и привязывает его к учетке пользователя.
Будем считать, что, когда пользователь пользуется сервисом без регистрации (не предоставляет токен доступа), но его IP-адрес есть среди списка зарегистрированных пользователей, определяется email.
Приветственный email отправляется не сразу, а по истечении заданного времени (можно использовать таймер). Каждый раз, когда пользователь вызывает какой-либо метод, таймер сбрасывается.
Таким образом пользователь получит лишь один email после того, как закончит работать с сервисом: пройдет определенное время и сработает таймер (один раз).
todo
Вам предлагается вывести формулу эффективности протокола множественного доступа, схожего с
протоколом CSMA/CD. В этом протоколе время дискретное и все адаптеры работают синхронно.
Однако в отличие от дискретного варианта ALOHA длительность кванта времени много меньше
времени передачи одного кадра. Пусть длительность кванта равна
- Если в течение данного кванта ни один из узлов не владеет каналом, все узлы состязаются
за канал, то есть в момент начала данного кванта каждый узел передает кадр с
вероятностью р. Если передачу начинает ровно один узел, этот узел захватывает канал на
последующие
$k - 1$ квантов и передает кадр целиком. - Если какой-либо узел владеет каналом, все остальные узлы воздерживаются от передачи до тех пор, пока данный узел не закончит передачу кадра. Как только узел заканчивает передачу кадра, все узлы начинают борьбу за канал.
Обратите внимание, что канал попеременно находится в одном из двух состояний: в
«продуктивном состоянии», длящемся ровно
- Определите эффективность этого протокола для фиксированных значений
$N$ и$p$ . - Для фиксированного значения
$N$ определите значение$p$ , при котором эффективность является максимальной. - Используя значение
$p$ (являющееся функцией$N$ ), полученное в предыдущем упражнении, определите эффективность при значении$N$ , стремящемся к бесконечности. - Покажите, что эффективность приближается к
$1$ при увеличении размера пакета.
todo
Исследуем применение небольших пакетов в приложениях для IP-телефонии. Один из
недостатков, связанных с небольшим размером пакетов, заключается в следующем: значительная
часть полосы передачи данных в канале тратится на пересылку лишних байт. Поэтому
предположим, что пакет состоит из
- Рассмотрим непосредственную отправку исходного голосового материала в цифровой форме.
Предположим, что звук закодирован с постоянным битрейтом
$128$ кбит/с. Также будем исходить из того, то каждый пакет заполняется целиком, и лишь после этого источник отсылает пакет в сеть. Время, требуемое на наполнение пакета, называется задержкой пакетирования. В контексте$L$ определите задержку пакетирования в миллисекундах. - Задержка пакетирования, превышающая
$20$ мс, может провоцировать заметное и неприятное эфирное эхо. Определите задержку пакетизации для$L = 1500$ байт (что примерно соответствует максимальному размеру Ethernet-пакета) и для$L = 50$ (примерно соответствует размеру ATM-пакета). - Вычислите задержку, возникающую при продвижении пакетов с промежуточным хранением
для одного коммутатора при скорости передачи в канале
$R = 622$ Мбит/с, для значений$L = 1500$ байт и$50$ байт. - Опишите преимущества, связанные с использованием пакетов небольшого размера.
todo