vk_logo twitter_logo facebook_logo googleplus_logo youtube_logo telegram_logo telegram_logo

#229 Старая песня о главном. TCP/IP

Дата публикации: 01.06.2005
Количество просмотров: 8617

Когда ищешь очки, тронь переносицу.
©Валентин Борисов

Разное.

Основная телекоммуникационная интрига прошедшей недели вышла комом. В ее начале Россвязьнадзор сильно обнадежил любителей сенсаций выдачей лицензии на дальнюю связь малоизвестной компании "ЦентринфоКом". Сразу поползли слухи о аффилированности и зажимании "Голдена" с "МТТ"...

Вот пример -
На самом деле Мининформсвязи заинтересовано в том, чтобы выдать побольше лицензий компаниям наподобие "Центринфокома", которые в реальности не смогут предоставлять услуги дальней связи....

Но ГСН (назовем его так по старой памяти) начал обретать светский лоск - на людях не бить, а лишь обозначать удары. И через пару дней похожими лицензиями обзавелись фактически все желающие это сделать в данный исторический момент.

Понятно, что это только начало истории. Реально выполнить условия предоставления услуг междугородной и международной телефонной связи много сложнее (дороже). Тут обещает "быстро начать" только ММТ, остальные собираются потратить на подготовку пару лет.

А чиновникам остается непыльная задача последовательно пить нервы и деньги операторов разной степени альтернативности. И вытягивать все реально демонополизирующие Связьинвест изменения ближе к году эдак 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.

OCC 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.

А вот еще несколько строчек с сайта компании-производителя:

 

  • Extremely strong, lightweight, rugged, survivable tight-buffer cable designed for military tactical field use and commercial applications;
  • Compact, round cable design for ease of transportation and deployment;
  • Designed for use in adverse environments where reduced size and weight are important;
  • Helically stranded cable core for flexibility, survival in difficult pulls, and superior mechanical protection for the optical fibers;
  • Can be used outdoors on the ground in all terrain, including severe environments;
  • Crush-resistant and resilient with a thick layer of Aramid strength members
  • Operating temperature range is -55°C to +85°C
  • Polyurethane jacketed for abrasion, cut and chemical resistance

Ну просто полный Excellent...

 


Немного ссылок.

Skype становится видеотелефоном. Напрашивалось давно... Вот что наконец позволит утилизировать толстые пучки оптики, проложенной по Европе и Штатам в период расцвета телекомов...

С 16 мая были введены новые тарифы Укртелекома. ADSL 128/64 Кбит/с, включено 256 Мбайт трафика - $10. Даже не знаю, дорого это или дешево по Украинским меркам.

В Москве запретили нелегальные антенны. Эта же новость кое-где прошла под заголовками типа "Лужков объявил войну черным провайдерам". Хотя сильно подозреваю, что при рассмотрении законопроекта про такую мелочь, как нелегальные домашние сети, даже не вспоминали...

Медиапортал ЮТК. Уже кое-что, но пока еще дороговато...

Интересная фотография, посвященная играм на рабочем месте (г. Усинск). И еще забавное - эротическая дверная ручка.

 


Письмо, посвященное последствиям blackout'а:

 

Краш-тест прошел круто... Больше никто не будет задавать небольшому провайдеру из Хабаровска вопрос "зачем ты отдал $5k в VSAT?". :-)
Полностью лежал Голден-Телеком, и все сервисы, которые через них работали. Похоже у них не только в Хабаровске, но и Москве не было ничего резервного, либо весь резерв распилили между важными коммерческими/московскими клиентами...
Прислал Денис

 


Обновление в разделах:

Фотографии о Связи.

Узлы телевизионщиков...

Остатки бывшего кабельного, еще со времен кооперативов и перестройки. Ответвитель в баночке от кофе - это сильно.

Фотки узлов телевизионщиков Фотки узлов телевизионщиков

Узел в лифтовой, одна из кабельных ТВ-компаний.

Фотки узлов телевизионщиков

Узел - кусок от программы Электронная Россия. Все сделано прилично, аккуратно до зависти.

Всем бы так работать Всем бы так работать

 

Прислал Владимир, гл. инженер ООО "ОктопусНет", г. Владивосток

 


Ящики должны быть большими...

Узел находится в пристройки для выхода на крышу 1,5*1,5 метра.

От крайней точки сети (которая и изображена на фото) протянуто два линка на SDSL-ных модемах до двух игровых клубов, расположенных в 500 и 400 метрах. Линки протянуты обычной полевкой.

ящик

В антивандальном ящике расположен свитч Компекс и два модема. Предыстория такова - монополист поменял свою тарифную политику, и если раньше клубам было все равно сколько и как они скачают друг у друга, то сейчас это стало относительно дорого.

В результате все закрыли свои ФТП, игровые сервера, подняли цены на внутригородской трафик. Решено было объединить два клуба в точке, принадлежащей нашей сети. В результате все только выиграли, на серверах принадлежащим нам и клубам стало больше игроков и все получили бесплатный доступ к ресурсам друг друга.

А этот ящик просто демонстрирует - больше пользователей не надо!

А больше клиентов нам и не надо

Прислал Бригинец Александр и Whistler

Старая песня о главном. TCP/IP.

Введение.
OSI.
IP.
UDP.
TCP.
Окна.
Управление перегрузками.
Таймеры.
Заключение.

Однажды, начитавшись пресс-релизов ведущих производителей о методиках построения светлого телекоммуникационного будущего, я заметил, что, кроме увеличения скоростей передачи данных, большое внимание уделяется качеству обслуживания (QoS). Настройка которого, в свою очередь, подразумевает хорошее знание алгоритмов функционирования протоколов семейства IP. Поэтому, прежде чем касаться высоких материй (типа QoS), попробуем рассмотреть строение IP подробно и не пропустить детали.

OSI и инкапсуляция.

Сначала вспомним каноническую семиуровневую модель OSI, являющуюся основой понимания функционирования телекоммуникаций.

Рисунок 1

Уровень номер один (Layer 1) называется "физическим уровнем" и относится к аппаратному формированию и обработке потоков информации (уровни напряжений, кодирование, биты).

Уровень номер два (Layer 2), или "канальный уровень" оперирует фреймами (кадры данных). К нему относятся, например Ethernet, Frame Relay, PPP.

Третий уровень называется "сетевым". Он соединяет между собой сети при помощи дейтаграмм, осуществляя маршрутизацию. К этому уровню принадлежит IP протокол.

Четвертый уровень является "транспортным". Данный уровень поддерживает обмен пакетами между конечными участниками соединения. Примером являются UDP и TCP протоколы.

Остальные уровни: Layer 5 ("сеансовый"), Layer 6 ("уровень представлений") и Layer 7 ("уровень приложений") перечислены для ознакомления.

IP.

Протокол IP соответствует третьему уровню (Layer 3) OSI. Каждый пакет IP состоит из заголовка (идентификатор протокола верхнего уровня, IP адреса отправителя и получателя, прочие поля) и блока данных (верхнего уровня).

Рисунок 2

В свою очередь пакеты IP включают в себя пакеты UDP и TCP. Это называется инкапсуляцией. Пакет верхнего уровня (UDP или TCP) вместе с заголовком и данными входит в блок данных пакета нижнего уровня.

Рисунок 3

UDP.

Протокол User Datagram Protocol (UDP) соответствует четвертому уровню OSI (Layer 4). Заголовок пакета UDP очень прост и содержит небольшое число полей, главными из которых являются номера портов передатчика и приемника. Контроль передачи данных протоколом не поддерживается (это задача верхних уровней).

Рисунок 4

TCP.

Протокол TCP функционирует на четвертом уровне OSI (Layer 4). Так как он составляет 80-90 процентов современного сетевого трафика и достаточно сложен по конструкции, дальнейшее рассмотрение IP сконцентрируем именно на TCP.

Пакет TCP состоит из заголовка и блока данных. Структура заголовка состоит из множества полей.

Рисунок 5

Наиболее важными из них являются номера портов отправителя и получателя и флаги контроля передачи данных.

TCP – транспортный протокол, пересылающий данные в СЕГМЕНТАХ, но БАЙТ-ОРИЕНТИРОВАННЫЙ (Byte-stream), поэтому поток данных он воспринимает и контролирует ПОБАЙТНО с полным контролем прохождения. Подчеркнем, что TCP оперирует потоком байтов.

Рисунок 6

С целью контроля потока данных (в байтах внутри сегмента) байты нумеруются, причем в возрастающем порядке. С этой целью заголовок TCP содержит поле "номер последовательности" (Sequence Number - SN) – 32 битный номер первого текущего байта в сегменте. При этом пакет передаваемых данных TCP можно условно представить следующим образом.

Рисунок 7

В самом начале соединения, когда еще ничего не передавалось, SN называется "начальным номером последовательности" (Initial Sequence Number - ISN).

Кроме того, так как TCP надежный протокол транспортного уровня, вводится квитирование, то есть подтверждение приемной стороной получения данных – 32 битный номер СЛЕДУЮЩЕГО ожидаемого к приему байта в потоке на стороне приемника (Acknowledge Number - AN). Это число отражает факт успешного получения (AN-1) байт.

Рассмотрим известную схему установления соединения в TCP более подробно.

Рисунок 8

Передатчик (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) на порцию пакетов не получено, передатчик снижает размер окна и перепосылает пакеты.

Рисунок 9

Так как WINDOW = 1, передатчик посылает по одному пакету и ждет подтверждения.

Рисунок 10

А здесь мы видим, что WINDOW сначала равно 3, а затем приемник не смог обработать один пакет и изменил размер окна до 2.

Управление перегрузками. Congestion control.

Предотвращение перегрузок в рамках протокола TCP разбивается на две подзадачи.

Рисунок 11

Медленный старт. Slow Start.

Когда передатчик получает от приемника ACK, дополнительно приемник передает размер окна WINDOW, которое характеризует его (приемника) возможности по получению пакетов (размер буферов и прочее). WINDOW измеряется в сегментах.

Простая реализация TCP предполагает, что передатчик начнет передавать данные по технологии плавающего окна с числом передаваемых без подтверждения сегментов равным WINDOW.

Современные реализации TCP вводят еще один параметр – CONGESTION WINDOW. Именно он определяет число передаваемых без квитирования (подтверждения) сегментов.

В начале передачи данных CONGESTION WINDOW = 1 и передается один сегмент. После каждого успешного подтверждения CONGESTION WINDOW удваивается, а вместе с ним удваивается число передаваемых без подтверждения сегментов. Математически это означает экспоненциальный рост. Увеличение CONGESTION WINDOW происходит до WINDOW размера и останавливается.

Рисунок 12

Предотвращение перегрузок. Congestion Avoidance.

В случае каких-либо проблем (например, перегрузок) передатчик не получает очередное подтверждение и сбрасывает CONGESTION WINDOW до 1.

Рисунок 13

Кроме того, задействуется специальный параметр Slow Start Threshold Size (SSTHRESH), который по умолчанию равен 65636, но после детектирования проблемы принимает значение WINDOW/2 и в дальнейшем является верхней границей экспоненциального роста CONGESTION WINDOW (когда CONGESTION WINDOW удваивается), после которого CONGESTION WINDOW растет линейно (с коэффициентом 1/ CONGESTION WINDOW) снова до значения WINDOW.

Рисунок 14

В случае, если CONGESTION WINDOW так и не дойдет до WINDOW (проблемы в сети, подтверждение не пришло), то SSTHRESH еще уменьшится в два раза от своего предыдущего значения. И так далее.

Рисунок 15

Таймеры.

Но как 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, очень важных при решении задач обеспечения качества обслуживания в сети. Надеюсь, изложенное будет полезно как начинающим, так и специалистам в области сетевых технологий.

Автор статьи Эдуард Афонцев

Анонс

 

  • Фактор времени (зарисовка на свободную тему);
  • Зацементированный RadioEthernet;
  • Когда в доме 4 провайдера;
  • В сети появились тарелочники...;
  • Зарисовки узлов разных провайдеров. Вечная тема (много фотографий гарантировано);
  • Традиционный пункт - ссылки на интересные места Сети. Присылайте письма - они очень нужны для обзоров. Обязательно сообщайте, нужна ли Ваша подпись, ссылка, или лучше обойтись без нее;
  • В "ужастиках" - Зацементированный RadioEthernet.
От редакции: если у вас есть чем поделиться с коллегами по отрасли, приглашаем к сотрудничеству
Ссылка на материал, для размещения на сторонних ресурсах
/articles/reviews/15457/staraya-pesnya-o-glavnom-tcp-ip.html

Обсудить на форуме

Оставлять комментарии могут только зарегистрированные пользователи

Зарегистрироваться