Когда ищешь очки, тронь переносицу.
©Валентин Борисов
Основная телекоммуникационная интрига прошедшей недели вышла комом. В ее начале Россвязьнадзор сильно обнадежил любителей сенсаций выдачей лицензии на дальнюю связь малоизвестной компании "ЦентринфоКом". Сразу поползли слухи о аффилированности и зажимании "Голдена" с "МТТ"...
Вот пример -
На самом деле Мининформсвязи заинтересовано в том, чтобы выдать побольше лицензий компаниям наподобие "Центринфокома", которые в реальности не смогут предоставлять услуги дальней связи....
Но ГСН (назовем его так по старой памяти) начал обретать светский лоск - на людях не бить, а лишь обозначать удары. И через пару дней похожими лицензиями обзавелись фактически все желающие это сделать в данный исторический момент.
Понятно, что это только начало истории. Реально выполнить условия предоставления услуг междугородной и международной телефонной связи много сложнее (дороже). Тут обещает "быстро начать" только ММТ, остальные собираются потратить на подготовку пару лет.
А чиновникам остается непыльная задача последовательно пить нервы и деньги операторов разной степени альтернативности. И вытягивать все реально демонополизирующие Связьинвест изменения ближе к году эдак 2008...
Небольшая ссылка на программу Software Cellular Network, которую прислал Anatolij, неожиданно сыграла роль катализатора. Стало понятно, как будет проходить смена технологий в телефонии.
Ранее казалось, что IP-телефоны будут медленно и печально вытеснять "бытовые-классические", действуя с территорий офисов. Однако, процесс может пойти и другим путем.
Уже сейчас понятно, что мобильные телефоны успешно вытесняют фиксированную связь, грозя превратить многие километры медных каблей в полезные ископаемые. Один штришок - возможность дешевых звонков через VoIP с сотовых телефонов (через Bluetooth или Wi-Fi), и IP-телефоны оказываются у 80% людей.
По идее, не сложно будет добиться работы с потенциально более дешевого IP в любой точке, где есть широкополосный интернет - от офиса до интернет-кафе (а уж внутриквартирный WiFi - по мировым меркам дело настоящего, а не будущего). На этой благодатной ниве постараются продавцы бытовой техники, которым нет дела до прибылей телекомов. Технику отшлифуют, "потребность сформируют", да и с рекламой не поскупятся.
Впрочем, больше похоже, что ОПСОСы смогут побороть такой сценарий простыми низкими ценами. При фиксированной оплате сэкономить на переключении сложно, и "хитрые" варианты будут иметь весьма ограниченное применение. Но так или иначе, последним гвоздем в крышку гроба фиксированной телефонии вариант "разговора с мобилки через Wi-Fi"стать может... Лет эдак через 5-7.
Есть и второй путь с похожим итогом. Дешевые услуги сотовых операторов и распространение надежной сети 3(4,5)G. Тут "без работы", к сожалению, остается VoIP и вообще все кабельные средства передачи данных... Хотя верится в это с трудом - эфир все же не резиновый.
Кто считает, что оптическая "полевка" (П-294, описана в #221) - это советское изобретение? Ничуть не бывало - вот вполне "забугорный" cable type D02-048C-A3FB/900-MIL.
Описание не оставляет сомнений - самая подлинная "военка" -
It is Distribution Military Tactical 2-fiber cable with a 4.8mm diameter polyurethane outer jacket. This is 50/125 multimode cable, with a 900um buffer coating. The attenuation and bandwidth specifications are 3dB/km and 400MHz-km at 850nm and 1dB/km and 500MHz-km at 1300nm wavelength.
А вот еще несколько строчек с сайта компании-производителя:
Ну просто полный Excellent...
Немного ссылок.
Skype становится видеотелефоном. Напрашивалось давно... Вот что наконец позволит утилизировать толстые пучки оптики, проложенной по Европе и Штатам в период расцвета телекомов...
С 16 мая были введены новые тарифы Укртелекома. ADSL 128/64 Кбит/с, включено 256 Мбайт трафика - $10. Даже не знаю, дорого это или дешево по Украинским меркам.
В Москве запретили нелегальные антенны. Эта же новость кое-где прошла под заголовками типа "Лужков объявил войну черным провайдерам". Хотя сильно подозреваю, что при рассмотрении законопроекта про такую мелочь, как нелегальные домашние сети, даже не вспоминали...
Медиапортал ЮТК. Уже кое-что, но пока еще дороговато...
Интересная фотография, посвященная играм на рабочем месте (г. Усинск). И еще забавное - эротическая дверная ручка.
Письмо, посвященное последствиям blackout'а:
Краш-тест прошел круто... Больше никто не будет задавать небольшому провайдеру из Хабаровска вопрос "зачем ты отдал $5k в VSAT?". :-)
Полностью лежал Голден-Телеком, и все сервисы, которые через них работали. Похоже у них не только в Хабаровске, но и Москве не было ничего резервного, либо весь резерв распилили между важными коммерческими/московскими клиентами...
Прислал Денис
Обновление в разделах:
Узлы телевизионщиков...
Остатки бывшего кабельного, еще со времен кооперативов и перестройки. Ответвитель в баночке от кофе - это сильно.
Узел в лифтовой, одна из кабельных ТВ-компаний.
Узел - кусок от программы Электронная Россия. Все сделано прилично, аккуратно до зависти.
Прислал Владимир, гл. инженер ООО "ОктопусНет", г. Владивосток
Ящики должны быть большими...
Узел находится в пристройки для выхода на крышу 1,5*1,5 метра.
От крайней точки сети (которая и изображена на фото) протянуто два линка на SDSL-ных модемах до двух игровых клубов, расположенных в 500 и 400 метрах. Линки протянуты обычной полевкой.
В антивандальном ящике расположен свитч Компекс и два модема. Предыстория такова - монополист поменял свою тарифную политику, и если раньше клубам было все равно сколько и как они скачают друг у друга, то сейчас это стало относительно дорого.
В результате все закрыли свои ФТП, игровые сервера, подняли цены на внутригородской трафик. Решено было объединить два клуба в точке, принадлежащей нашей сети. В результате все только выиграли, на серверах принадлежащим нам и клубам стало больше игроков и все получили бесплатный доступ к ресурсам друг друга.
А этот ящик просто демонстрирует - больше пользователей не надо!
Прислал Бригинец Александр и Whistler
Введение.
OSI.
IP.
UDP.
TCP.
Окна.
Управление перегрузками.
Таймеры.
Заключение.
Однажды, начитавшись пресс-релизов ведущих производителей о методиках построения светлого телекоммуникационного будущего, я заметил, что, кроме увеличения скоростей передачи данных, большое внимание уделяется качеству обслуживания (QoS). Настройка которого, в свою очередь, подразумевает хорошее знание алгоритмов функционирования протоколов семейства IP. Поэтому, прежде чем касаться высоких материй (типа QoS), попробуем рассмотреть строение IP подробно и не пропустить детали.
OSI и инкапсуляция.
Сначала вспомним каноническую семиуровневую модель OSI, являющуюся основой понимания функционирования телекоммуникаций.
Уровень номер один (Layer 1) называется "физическим уровнем" и относится к аппаратному формированию и обработке потоков информации (уровни напряжений, кодирование, биты).
Уровень номер два (Layer 2), или "канальный уровень" оперирует фреймами (кадры данных). К нему относятся, например Ethernet, Frame Relay, PPP.
Третий уровень называется "сетевым". Он соединяет между собой сети при помощи дейтаграмм, осуществляя маршрутизацию. К этому уровню принадлежит IP протокол.
Четвертый уровень является "транспортным". Данный уровень поддерживает обмен пакетами между конечными участниками соединения. Примером являются UDP и TCP протоколы.
Остальные уровни: Layer 5 ("сеансовый"), Layer 6 ("уровень представлений") и Layer 7 ("уровень приложений") перечислены для ознакомления.
IP.
Протокол IP соответствует третьему уровню (Layer 3) OSI. Каждый пакет IP состоит из заголовка (идентификатор протокола верхнего уровня, IP адреса отправителя и получателя, прочие поля) и блока данных (верхнего уровня).
В свою очередь пакеты IP включают в себя пакеты UDP и TCP. Это называется инкапсуляцией. Пакет верхнего уровня (UDP или TCP) вместе с заголовком и данными входит в блок данных пакета нижнего уровня.
UDP.
Протокол User Datagram Protocol (UDP) соответствует четвертому уровню OSI (Layer 4). Заголовок пакета UDP очень прост и содержит небольшое число полей, главными из которых являются номера портов передатчика и приемника. Контроль передачи данных протоколом не поддерживается (это задача верхних уровней).
TCP.
Протокол TCP функционирует на четвертом уровне OSI (Layer 4). Так как он составляет 80-90 процентов современного сетевого трафика и достаточно сложен по конструкции, дальнейшее рассмотрение IP сконцентрируем именно на TCP.
Пакет TCP состоит из заголовка и блока данных. Структура заголовка состоит из множества полей.
Наиболее важными из них являются номера портов отправителя и получателя и флаги контроля передачи данных.
TCP – транспортный протокол, пересылающий данные в СЕГМЕНТАХ, но БАЙТ-ОРИЕНТИРОВАННЫЙ (Byte-stream), поэтому поток данных он воспринимает и контролирует ПОБАЙТНО с полным контролем прохождения. Подчеркнем, что TCP оперирует потоком байтов.
С целью контроля потока данных (в байтах внутри сегмента) байты нумеруются, причем в возрастающем порядке. С этой целью заголовок TCP содержит поле "номер последовательности" (Sequence Number - SN) – 32 битный номер первого текущего байта в сегменте. При этом пакет передаваемых данных TCP можно условно представить следующим образом.
В самом начале соединения, когда еще ничего не передавалось, SN называется "начальным номером последовательности" (Initial Sequence Number - ISN).
Кроме того, так как TCP надежный протокол транспортного уровня, вводится квитирование, то есть подтверждение приемной стороной получения данных – 32 битный номер СЛЕДУЮЩЕГО ожидаемого к приему байта в потоке на стороне приемника (Acknowledge Number - AN). Это число отражает факт успешного получения (AN-1) байт.
Рассмотрим известную схему установления соединения в TCP более подробно.
Передатчик (Sender) посылает в сторону приемника (Receiver) пакет с установленным флагом Synchronization (SYN), что означает начало установления синхронизации потока, то есть установление соединения передатчик => приемник. Кроме того, пакет содержит стартовый номер байтовой последовательности (Initial Sequence Number - ISNA), равный произвольно выбранному числу (алгоритм выбора ISN зависит от реализации протокола, в общем случае он псевдослучаен).
Приемник (Receiver) посылает передатчику (Sender) в ответ на его SYN пакет с флагом Acknowledge (ACK), что означает согласие на обмен. Дополнительно приемник сообщает номер следующего ожидаемого от передатчика байта в потоке данных, заполняя поле Acknowledge Number (ANB) (значением ISNA+1, что очевидно, так как пакет с ISNA уже получен).
Кроме того, не следует забывать, что TCP – дуплексный протокол. Поэтому приемник, в свою очередь, открывает соединение приемник => передатчик, устанавливая в том же пакете с ACK флаг SYN и указывая свой ISNB.
Передатчик, получив ACK от приемника, считает канал передатчик => приемник установленным и может дальше передавать сегменты с байтами, начиная их нумерацию с ISNA+1. Однако, он получил еще и SYN от приемника и отвечает на него пакетом с ACK и AN равным ISNB + 1.
Приемник, получив от передатчика подтверждение принятого им SYN в виде ACK пакета с ANA = ISNB + 1, считает канал приемник => передатчик установленным. В этот момент дуплексный канал связи приемник <=> передатчик налажен и дальше передаются только подтверждения приема очередной порции байт (пакеты только с ACK). Завершиться обмен может штатно (пакет с опцией FIN), когда данные закончатся, или принудительно (пакет с опцией RST).
Окна.
Число пакетов, которое отправитель посылает, не дожидаясь подтверждения (то есть ACK), называется окном (WINDOW SIZE или просто WINDOW). Технология называется "скользящее окно" (Sliding Window) и образно может трактоваться как перемещение (скольжение) окна передачи данных по потоку байтов.
Размер окна сообщается приемной стороной для передающей. Кроме того, размер окна может меняться в процессе передачи. Каждое подтверждение (ACK) содержит анонс окна, которое приемник может обработать. Если подтверждение (ACK) на порцию пакетов не получено, передатчик снижает размер окна и перепосылает пакеты.
Так как WINDOW = 1, передатчик посылает по одному пакету и ждет подтверждения.
А здесь мы видим, что WINDOW сначала равно 3, а затем приемник не смог обработать один пакет и изменил размер окна до 2.
Управление перегрузками. Congestion control.
Предотвращение перегрузок в рамках протокола TCP разбивается на две подзадачи.
Медленный старт. Slow Start.
Когда передатчик получает от приемника ACK, дополнительно приемник передает размер окна WINDOW, которое характеризует его (приемника) возможности по получению пакетов (размер буферов и прочее). WINDOW измеряется в сегментах.
Простая реализация TCP предполагает, что передатчик начнет передавать данные по технологии плавающего окна с числом передаваемых без подтверждения сегментов равным WINDOW.
Современные реализации TCP вводят еще один параметр – CONGESTION WINDOW. Именно он определяет число передаваемых без квитирования (подтверждения) сегментов.
В начале передачи данных CONGESTION WINDOW = 1 и передается один сегмент. После каждого успешного подтверждения CONGESTION WINDOW удваивается, а вместе с ним удваивается число передаваемых без подтверждения сегментов. Математически это означает экспоненциальный рост. Увеличение CONGESTION WINDOW происходит до WINDOW размера и останавливается.
Предотвращение перегрузок. Congestion Avoidance.
В случае каких-либо проблем (например, перегрузок) передатчик не получает очередное подтверждение и сбрасывает CONGESTION WINDOW до 1.
Кроме того, задействуется специальный параметр Slow Start Threshold Size (SSTHRESH), который по умолчанию равен 65636, но после детектирования проблемы принимает значение WINDOW/2 и в дальнейшем является верхней границей экспоненциального роста CONGESTION WINDOW (когда CONGESTION WINDOW удваивается), после которого CONGESTION WINDOW растет линейно (с коэффициентом 1/ CONGESTION WINDOW) снова до значения WINDOW.
В случае, если CONGESTION WINDOW так и не дойдет до WINDOW (проблемы в сети, подтверждение не пришло), то SSTHRESH еще уменьшится в два раза от своего предыдущего значения. И так далее.
Таймеры.
Но как TCP узнает о потере пакета? Это зависит от реализации протокола. Наиболее распространенная версия TCP под названием RENO считает, что пакет потерян при следующих условиях: не получен ACK или получено три дубликата ACK.
Таймер повторной передачи.
Для детектирования потери ACK используется специальный таймер - таймер повторной передачи (Retransmission Time Out - RTO). Данный таймер принимает некоторое стартовое значение (RTO) в момент посылки TCP пакета получателю и начинает свое декрементирование (последовательно уменьшаться на единицу с течением времени). В случае, если данный таймер окажется сброшенным в ноль до момента получения подтверждения (ACK), то переданный пакет считается потерянным и требуется повторная передача. Кроме того начинается процедура пересчета Congestion Avoidance (описано выше).
Так как маршруты пакетов могут быть разными, время их прохождения варьируется. Поэтому величина RTO не может быть фиксированной и должна вычисляться для каждого логического соединения.
Предварительно для каждого пакета TCP измеряется величина, называемая временем отклика (Round Trip Time - RTT) – интервал времени от момента посылки TCP пакета до момента получения подтверждения на него.
На основе RTT вычисляется значение величины сглаженной RTT (Smoothed RTT - SRTT) , что обеспечивает фильтрацию резких выбросов. А уже от SRTT вычисляется RTO. Таким образом, RTO является функцией от RTT, что позволяет учитывать временные особенности каждого соединения.
В случае, если и после повторной передачи пакета, опять не придет подтверждение за интервал RTO, то попытки передачи будут повторяться (ограниченное число раз, до 12). При этом параметр RTO будет экспоненциально увеличиваться (протокол предполагает ухудшение условий и на всякий случай повышает RTT).
И только после неудачи всех попыток происходит аварийное закрытие соединения.
Таймер возобновления передачи.
В ходе взаимодействия возможно следующее. Приемная сторона уведомляет передатчик о невозможности приема (установив размер окна в ноль), передатчик останавливает на некоторое время обмен, приемник через некоторое время желает возобновить прием пакетов и посылает пакет с НЕНУЛЕВЫМ ОКНОМ, но тот по какой-то причине теряется. Передатчик так и будет считать, что приемник не может принимать пакеты, а приемник не дождется от передатчика подтверждения на возобновление передачи. Возникает тупиковая ситуация.
С целью предотвращения подобного, для каждого соединения вводится таймер возобновления передачи (Persistent Timer -PT). Он взводится в момент получения пакета с нулевым размером окна. Если до момента обнуления таймера так и не придет разрешения на передачу, произойдет отправка одного "разведывательного" пакета.
Таймеры поддержки соединения.
Каждый участник TCP соединения с целью проверки соединения периодически отправляет партнеру тестовый пакет без данных и ждет его подтверждения. Значение этого периода определяется отдельным таймером Keep-Alive Timer и обычно равно 45 секундам. Если в течении определенного интервала времени, определяемого отдельным таймером (Idle Timer), не будет получено подтверждения, то соединение считается разорванным.
Заключение
Главной задачей данного материала являлось популярное изложение тонкостей протокола TCP, очень важных при решении задач обеспечения качества обслуживания в сети. Надеюсь, изложенное будет полезно как начинающим, так и специалистам в области сетевых технологий.
Автор статьи Эдуард Афонцев
![vk](https://vk.com/share.php?url=https://nag.ru/material/3490&title=Старая песня о главном. TCP/IP&description=Основная телекоммуникационная интрига прошедшей недели вышла комом. В ее начале Россвязьнадзор сильно обнадежил любителей сенсаций выдачей лицензии на дальнюю связь малоизвестной компании "ЦентринфоКом". Сразу поползли слухи о аффилированности и зажи&image=https://nag.ru/uploads/material/images/3490/social_cover.png)
