Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Билет 10

.docx
Скачиваний:
13
Добавлен:
28.06.2021
Размер:
268.37 Кб
Скачать

Билет 10.1

Что такое DTE и DCE? Каковы функции модема и кодера/декодера?

DTE (Data Termilal Equipment) – оборудование, являющееся источником данных, генерируемых в сеть. Компьютер, роутер.

DCE (Data Circuit Equipment) - оборудование линии связи для передачи преобразования и усиления сигнала, сгенерированного DTE (модемы, коммутаторы, хабы и конверторы).

DCE – интерфейс между DTE и средой передачи. По факту это модем. DTE – оконечное оборудования, по факту компьютер\сервер\принтер итд. Специальные протоколы для передачи от DTE к DCE: RS-232.

Слово "модем" (modem) происходит от сочетания "модулятор/демодулятор" и используется для обозначения широкого спектра устройств передачи цифровой информации при помощи аналоговых сигналов путем их модуляции - изменения во времени одной или нескольких характеристик аналогового cигнала: частоты, амплитуды и фазы. При этом модулируемый аналоговый сигнал называется несущим (carrier) и обычно представляет собой сигнал постоянной частоты и амплитуды (несущая частота).

Модем выполняет функцию оконечного оборудования линии связи. (DCE) Дополнительные функции:

Факс-модем — позволяет компьютеру, к которому он присоединён, передавать и принимать факсимильные изображения на другой факс-модем или обычный факс-аппарат.

Голосовой модем — с функцией оцифровки сигнала с телефонной линии и воспроизведения произвольного звука в линию. Часть голосовых модемов имеет встроенный микрофон. Такой модем позволяет осуществить:

• передачу голосовых сообщений в режиме реального времени на другой удалённый голосовой модем, приём сообщений от него и воспроизведение их через внутренний динамик;

использование в режиме автоответчика и для организации голосовой почты.

Кодек (кодер-декодер) – компонент модема, который осуществляет двустороннее преобразование аналогового сигнала, поступающего из линии, в поток цифровых данных.

Билет 10.2

Протокол TCP, UDP. Формат пакета и алгоритм работы.

TCP(Transmission Control Protocol. Он обеспечивает надежную транспортировку между прикладными процессами путем установления логического соединения), UDP(User Datagram Protocol, дейтаграммный протокол без установки соединения и подтверждений. Не имеет дополнительных опций и используется для посылки срочных сообщений; В отличие от TCP он не устанавливает соединение. Он расширяет функции IP до номеров портов. Он использует те же номера портов, что и TCP. Быстрее работает, чем TCP. Используется в DNS, SNMP, VoIP)

Передача информации идет следующим образом:

  • Запускаем процесс с портом n. У него есть свой IP адрес. Говорим Source port и sorce IP address, указываем destination port (предположим 80-й), IP адрес сервера, на котором мы хотим этот процесс запустить.

  • До запуска этого процесса, любая ОС, которая поддерживает TCP будет выполнять специальный процесс «трехстороннее рукопожатие TCP»

Есть рабочая станция, которая хочет начать передачи. Сервер пока не знает ни SEQ, ни ACK, он просто ожидает. Рабочая станция тоже не знает какой порт ей придет. А для номера с которого она собирается начать будет работать специальный генератор случайных чисел, который даст случайный адрес (например 730). Flag SYN.

Такое сообщение получит сервер, оно означает, что мы хотим начать, синхронизироваться. После того как сервер получит это сообщение он скажет, что далее для пересылки ACK = 731 (меняет местами ACK + 1, т. к. получаем со следующего байта). SEQ тоже делает случайным (в примере 400). И то, и другое некие случайные числа. А также предаёт флаг SYN, что означает, что он готов к синхронизации.

Принимающая станция устанавливает ACK 401-м. А SEQ – 731-м. Это означает, что мы поняли. И дальше в пакете некое подтверждение.

Сервер понимает, что мы переслали все данные и ACK остается 731, SEQ – 401. Это означает, что мы передали всю информацию. В случае успеха всегда SEQ +1, А если что-то не так, то устанавливаем специальный timeout, при получении которого мы понимаем, что если мы в течении него не установим соединение, то будет disconnect.

Для SEQ числа случайны, согласно RFC 793. Выбирается, обычно, при начальной загрузки станции. Это будет делать драйвер TCP, который, например, может использовать время запуска системы и увеличивать счетчик на 4 микросекунды. Это так по default'у. Хотя в ОС могут сделать и по своему. SEQ мы будем увеличивать на единичку, а старые соединения будут сбрасываться с флагом RESET (если за timeout соединиться не удалось). Если соединение установилась, то начинается передача данных TCP.

Есть рабочая станция, есть некий сервер. На рабочей станции есть ACK = 401. SEQ = 731. У сервера есть ACK 731, SEQ = 401 (этого мы добились при синхронизации). Далее станция отправляет, предположим 20 байт и ACK = 401, SEQ = 731. Сервер сделает следующее: установит ACK 751 (731+20 байт), SEQ 401 – следующий байт с которого мы ожидаем прием. Передаст соответствующий ACK 751, SEQ = 401 и 0 байт, т. к. ничего никуда не передаем, а просто шлем некое подтверждение, что все приняли. На станции устанавливаем ACK =401, SEQ = 751 и передаем следующие 50 байт (например). На сервере мы переустанавливаем ACK = 801 (751+50) и SEQ=401 и отправляем эти данные станции + 0 байт. После получения данного сообщения станции станция переустанавливает себе ACK =401 и SEQ = 801.

Подтверждения являются аккумулятивными, это означает, что мы не подтверждаем каждый байт, а мы подтверждаем какую-то порцию. Они накапливаются. Номер подтверждения – всегда номер последующего байта, прием которого ожидается. Подтверждение на дубликаты тоже получаем, т.к. мы не можем узнать по каким причинам был отправлен дубликат. Если мы будем их отбрасывать – мы потеряем сегменты TCP. И это одна из причин, по которым мы будем работать медленно. Потеря пакетов – признак неправильно работающей ОС. Количество ошибок TCP/IP должно быть строго равным 0. Это в ethernet коллизии бывают, а в TCP/IP потерь пакетов быть недолжно. Как только передаем некие ACK’и, SEQ’и и т.д. запускается специальные таймеры, которые имеют timeout, превышение timeout вызывает повторную передачу. Это одна из причин, по которой идут дублирующие пакеты. Значение timeout очень сильно влияет на производительность системы. Он должен быть связан с временем «двойного пробега». (сегмент должен придти туда и вернуться обратно. Если timeout большой – длительное ожидание при ошибке. При маленьком – бесконечные повторные передачи. Поэтому в современных ОС используются специальные алгоритмы, для вычисления адаптивного timeout`а. Адаптивный timeout использует специальные методы задержки. Например если у нас сильно загружена система, то мы должны ждать. (см. медленный старт TCP». Адаптивный алгоритм KARN – алгоритм, который используется практически во всех современных ОС.

UNIX – Алгоритмы старые

Windows – Новые алгоритмы.

Размер окна тоже варьируется, окно не меняется, пока свободное место не составляет 20-40%. Поэтому сначала делают большое окно (например пытаются передать 80 байт), потом понимают, что передать невозможно, сокращают это окно, и до тех пор пока 20, 40% не остается его размер не трогают. Такое динамическое окно позволяет управлять потоками данных используя специальные алгоритмы.

65535 байт – максимальный размер окна. Начальный размер окна согласовывается на стадии установки соединения, а дальше размер окна меняется.

UDP

Идея проста:

  • Посылаем первый пакет, на unknown port UDP, должны получить destination unreachable, от любой ОС. Любой пакет отправляется с TTL – time to live

  • Отправляем следующий пакет в котором уменьшен TTL, для того, чтобы он остановился на предыдущем роутере, он выкинет этот пакет с сообщением time exited и, соответственно даст свои координаты. Application TTL увеличит на единичку, чтобы попытаться пробиться к следующему роутеру, от которого в совою очередь получаем time exited. Таким способом и трассируется весь маршрут.

Однако если хост действительно не использует этот порт, то мы дальше не пройдем. Это надо учитывать.

Роутеры и host'ы должны поддерживать UDP и ICMP. Если они не поддерживаются, или поддерживаются некорректно, то никакого хорошего результата мы тоже не получим.

Ну и наконец мы можем получить, что действительно нет маршрута до нужного host’а.

И мы должны потребовать, чтобы все ОС правильно работали с ICMP и могли работать с сообщением time exited.

В любой ОС есть конфигурация параметров TCP, например если это VRP Huawei, то мы в этой конфигурации будем указывать, например, размер MTU (размер того сегмента, который мы будем отправлять). По умолчанию 1500 байт. В этом случает требуется фрагментация пакетов TCP. Дальше будет целая конфигурация атрибутов TCP, например, SYN timer – если пакеты не получены, пока таймер истечет, то TCP соединение прекратить (сообщение с флагом RESET). Диапазон таких значений в ОС от 2-600 секунд. FIN таймер - если не получен FIN пакет до истечении таймера, то соединение будет прекращено. На FIN обычно очень большой диапазон 600 – 700 секунд. Размеры буферов для передачи и приема сокетов влияют на установку соединения и указывается в ОС. Это настройки ОС на работу TCP. Есть специальные настройки, связанные с настройкой производительности.

настройки ОС на работу TCP. Есть специальные настройки, связанные с настройкой производительности.

Соседние файлы в предмете Распределенные операционные системы