Радищев Дмитрий

Пробило меня сегодня на ликбез. По модемам, протоколам модуляции, коррекции, компрессии, текущему состоянию дел и перспективам развития... Куулер в свое время, помнится, "сисадминские байки" любил рассказывать, где объяснял благодарным слушателям чем icmp отличается от tcp/ip и тому подобные вещи, почему бы мне не заняться аналогичным делом - рассказать, как именно шипит и жужжит та белая коробочка с лампочками, и почему оно так часто теряет CARRIER.
          Проблема передачи информации между компьютерами появилась вскоре после появления собственно компьютеров. "Материальные носители" - магнитные ленты, дискетки - великая вещь (и до сих пор - если мне нужно перенести три гига информации из пункта А в удаленный на пять километров пункт Б - я скорее всего воспользуюсь жестким диском, а не модемом или еще каким сетевым средством), но сеть - тоже хорошо. И появились сети - локальные для начала, на расстоянии вытянутого провода. Что было уже хорошо, но... хочется-то, конечно, большего - отдать мелкий файлик приятелю Васе с другого конца города, а то и получить что-то из другого города. Ну, а поскольку наиболее повсеместно протянутая из тогдашних паутин проводов называлась "телефонная сеть", появились коробочки, позволявшие передавать информацию по ней. Появились, развиваются (до сих пор, как ни странно), и, несмотря на бурный рост разнообразных xDSL, умирать пока не собираются.
          Телефонный канал, как вы, наверно, догадываетесь, изначально для передачи цифры предназначен не был, а предназначен был для передачи голоса, то есть - звука. Если быть точным - то звука в полосе частот от (приблизительно) 300 до 3400 Гц (на цифровых - до 4000 Гц, на тех, что собраны из контактов, релюх и кусков провода - как получится), что, конечно, далеко от Hi-Fi звучания, но достаточную разборчивость речи обеспечивает. Чтобы "засунуть" внутрь цифру - нужно превратить цифру в звук (промодулировать), а на другом конце демодулировать - проанализировав дошедший туда звук понять, что же там хотели сказать. Ну, раз модуляция - поговорим о модуляции. "Шумоподобные" технологии распространения не получили (и сложновато технически, и толку мало - спектр получается широковат), поэтому модуляция осуществляется классическим образом: берется несущая (синусоида определенной частоты), и изменяется (то есть, собственно, модулируется) по какому-нибудь параметру. По амплитуде (амплитудная модуляция), частоте (частотная) или фазе (фазовая). От этого и начнем плясать.
          Пропуская совсем уж малоизвестные протоколы модуляции, начнем с v21. Модуляция "дискретно-частотная" (FSK, frequency shift keying), то есть - каждый бит передается своей частотой. Поскольку (вечная проблема) в телефонной розетке всего два провода (как результат - мы слышим в наушнике сами себя, так называемое "ближнее эхо" или "местный эффект"), чтобы отличить передачу удаленной стороны от своей собственной - используется четыре частоты: две "туда" и две "обратно". Скорость протокола v21 была 300 бит/с или 300 бод (baud). То есть, сдвиг частоты происходил 300 раз в секунду, и за один "раз" передавался ровно один бит.
          При "простых" видах модуляции, когда у сигнала просто переворачивается фаза или меняется частота, скорость жестко ограничена только частотной полосой. Действительно, даже если мы на своем конце попытаемся "перевернуть" фазу, скажем, 5000 раз в секунду - на другой конец придет "каша", полученная после обрезания полосы сигнала. Реально, поскольку спектр при модуляции обязательно "размазывается" дополнительно, да и "туда-обратно" разделять как-то надо - практический предел находится где-то в районе 1000-2000 бод.
          В следующем по хронологии виде модуляции - v22 - ситуация выглядела следующим образом. На низшей (для v22) модуляционной скорости (а это целых 600 бит/с) ничего принципиально не изменилось. Модуляция, правда, используется "дискретная фазо-разностная" (DPSK, differential phase shift keying), то есть бит кодируется "переворотом" фазы несущей на 180 градусов, в остальном все на месте - частотное разделение каналов, один бит за один "элемент модуляции". На высшей же для v22 скорости - 1200 бит/с - все становится куда веселей и лучше. Ну и, собственно, с v22 начали появляться те идеи, развитие которых постепенно привело к скоростям вроде 33600. Итак.
          Итак. Разделение каналов - частотное. Модуляция - DPSK. Но - и очень простое "но" - за один "раз" передается теперь не один бит, а два бита. Поскольку фаза теперь может не только "переворачиваться" на 180, но и "поворачиваться" на 90 и 270 градусов. То есть, фаза нарезана не просто на "плюс" и "минус", а на четыре положения. Что и позволило передавать данные в два раза быстрее - при бодовой скорости 600 бод иметь 1200 бит/с канальную, "битовую", скорость.
         Есть одно общее заблуждение, настолько распространенное, что почти ставшее "истиной". Заблуждение состоит в том, что "бод" (baud) есть "наукообразный термин" для выражения "бит в секунду", бит/с, и что если на модеме написано "33600" - то это "модем на 33600 бод". На самом деле это не так. За, так сказать, "один акт модуляции" (сдвиг фазы/амплитуды/частоты/чего-там-еще) можно передать более одного бита информации (достаточно "нарезать" эти сдвиги на мелкие дольки). Частота этих самых "актов модуляции" однозначно ограничена частотной полосой канала (слишком частая модуляция будет "размазана" за счет ограниченной полосы), скорость же передачи данных ограничена не только полосой, но и соотношением сигнал/шум, определяющим, насколько мелко можно нарезать единицу модуляции,не боясь, что разница потонет в шумах.
          Скорость, с которой происходят скачки амплитуды/фазы называется "бодовой" скоростью, и не превышает 2400 бод. Скорость же передачи данных (битовая, или "канальная" скорость)... ну, вы в курсе. :-) Поэтому модем с надписью 33600 - это отнюдь не модем на "33600 бод", а вовсе даже модем на 2400 бод, но - на 33600 бит в секунду.
          Дальше - проще. Синусоида заданной частоты (несущая частота известна и постоянна) характеризуется двумя параметрами - амплитудой и фазой. Амплитуда может меняться от 0 до 1, фаза - от 0 до 2*Пи. Разделяем каждый интервал на сколько нужно делений, а "акт модуляции" сводим к изменению фазы несущей на сколько-нужно и заданию амплитуды какой-нужно. На том конце - детектируем, анализируя амплитуду и сдвиг фазы каждого дошедшего кусочка синусоиды. Пример? Нарезаем фазу на четыре кусочка, амплитуду - на четыре уровня (итого 2+2=4 бита на бод), и получаем v22bis. Бодовая скорость 600 бод, битовая - 2400 бит/с. И это только начало :-)
         кстати, v22bis до сих пор актуальности не потерял. Скорость, конечно, мала для "браузинга интернета" (впрочем... работал же я в интернете на 2400 несколько лет назад), но достаточна для почты, а простота протокола определяет его неприхотливость - там, где современный модем на v34bis не может завершить своё "бжумм-бжумм-шшшшш" из-за шумов или искажений, v22bis зачастую живет без проблем.
          Крастота, правда? Давайте теперь нарежем амплитуду на, э... 16 уровней, и фазу на 16 уровней - получим сразу 4+4=8 бит за бод и 600*8=4800 бит/с скорость! А вот и опаньки. При малых амплитудах шумы будут сильно мешать определению точной фазы отсчета, и как следствие - нарезку по фазе придется уменьшить, со всеми вытекающими. Поэтому... поэтому придется немного заняться теорией.
          Наш кусочек синусоиды, как мы уже договорились, характеризуется амплитудой и фазой. Удобным представлением для этого является комплексное число в виде A*exp(i*Ф), где A - амплитуда, Ф - фаза, соответственно. Шумы воздействуют не на амплитуду и фазу "по отдельности", а на это число целиком, поэтому и нарезку делать надо не по "фазе и амплитуде", а по действительной и мнимой части нашего комплексного числа. А если попроще... на листке бумаги рисуются оси координат, вокруг центра рисуется окружность единичного радиуса (максимальное значение амплитуды). Точка внутри окружности соответствует сигналу с амплитудой, равной расстоянию от начала координат, фаза - углу между отрезком от точки до нуля и осью абсцисс. Впрочем, чего это я вам основы комплексной арифметики рассказываю - сами должны знать :-)
          А дальше - так. На плоскости рисуется сеточка (прямоугольная) из точек. Точки, выходящие за пределы окружности отсекаются как "запрещенные", полученная совокупность точек нарекается умным научным термином "сигнальное созвездие", и за, так сказать, один акт модуляции передается одна из точек сигнального созвездия. Voila - мы имеем так называемую "квадратурную" (QAM - quadrature-amplitude modulation) модуляцию, практически идеально использующую шумовые характеристики звукового канала (наверно, оптимальней была бы структура не "квадратиков" а "сот", впрочем - возможно, так уже и сделано, тут я уже не в курсе).
         ...на самом деле все чуть сложней - например, перед передачей битового потока он прогоняется через специальный алгоритм, обеспечивающий "в среднем постоянный" уровень аналогового сигнала на выходе (QAM-кодер может "запутаться" в точках, соответсвующих малой амплитуде, удаленный же модем может распознать это как снижение уровня и подкрутить усиление. Куда при этом уползут точки созвездия, и что получится в результате, оставляю в качестве упражнения читателю.
          Следующий шаг - введение эхогашения. Если мы имеем полосу в 3кГц в среднем шириной, и хотим передавать информацию в обе стороны - придется либо делить полосу на две половинки: "туда" и "обратно", либо... либо пытаться устранить собственное эхо, то есть, попытаться "вычесть" из входа приемника сигнал собственного передатчика, орущего ему же "в ухо". Это осложняется тем, что идеальных линий (с чисто активным сопротивлением 600 Ом) не бывает, как, впрочем, и идеальных модемов, и потому чисто аналоговые методы "вычитания" помогают не сильно. В результате вычитание собственного сигнала делается в DSP, и "настройка эхогашения" становится обязательным этапом установки соединения.
          А теперь, вооруженные сокровенным знанием про QAM и эхогашение, примемся за v32. Прислушавшись к процедуре "начального установления связи" можно услышать:
          - прерывистый писк в начале. Модемы на v22* пищали непрерывно, писк этот остался "для совместимости" (чтобы модем на v22* смог соединиться с более современным, пусть даже на v22), но периодически происходит "переворот" фазы сигнала (ухом слышится как "разрыв" в писке), как сигнал "я умею v32!".
          - "пикхшшшшшшшшшш" первого модема: короткий "пип" как сигнал "я тебя слышу, счас будем соединяться", затем второй модем молчит, первый выдает в линию тестовую последовательность и подстраивает параметры эхогасителя до достижения нужного уровня подавления собственного сигнала. Второй модем тем временем, зная параметры тестового сигнала, оценивает качество линии.
          - "пишшшшшшшшшшш" - первый модем настроился и замолк, шипит и настраивается второй - первый слушает. Обычно это шипение несколько отличается по громкости и/или тональности - все-таки один шипит "здесь", а другой - "оттуда", с того конца линии.
          - "ШШхк...." - и тишина. Сигнальные цепи подстроены, модемы договорились о параметрах модуляции (в соответствии с качеством линии), зашипели друг на друга (поэтому шипение стало громче) и выключили динамик - началась работа по передаче данных.
         
          Уфф. Протоколы коррекции и компрессии оставим на потом, а сейчас еще чуть-чуть о v32. С достоинствами понятно - первый протокол с нормальной QAM (тем самым использующий почти на пределе шумовые характеристики линии), первый протокол с эхогашением... по мелочи - если в процессе соединения модем обнаруживает, что качество связи упало - идет запрос на снижение скорости (fallback), при этом (понятно) надежность возрастает, хотя скорость и падает. Недостатки... есть, конечно. Главных - два: одинаковая скорость в обе стороны (если модем 1 слышит модем 2 "на двоечку", а модем 2 слышит модем 1 "идеально" - связь будет "на двоечку", потому что... потому что так вот), и отсутствие штатного fallforward (повышения скорости) - если по линии прошел шумок и скорость упала - обратно она уже не вырастет, разве что через процедуру "повторной установки связи" - ретрейн (которого вполне может и не быть - зачем модемам ретрейниться на хорошей линии).
         Как правильно перевести слово "ретрейн" (retrain) на наш, русский, язык я, например, до сих пор толком не знаю. "Перетренировка" не совсем подходит - кого там "тренируют"? Ближе всего (если не отрываться от словаря и не изобратать нового смысла старых слов) - "повторное обучение", что, впрочем, тоже не совсем точно.
          По сути "ретрейн" (можно я его переведу так?) - повторная установка связи, очень похожая на начальную установку связи (пип-пшшшшшшш-пШШШШШШШ) за исключением того, что собственно протокол уже известен, и настраиваются только параметры протокола. Производится ретрейн при "неустранимых сбоях" в "гладкой" работе протокола модуляции. Такие "неустранимые сбои" как правило возникают в результате резкого ухудшения качества (или изменения параметров) линии, как правило - всплесков шума, при которых модемы "не слышат" друг друга и не могут штатным образом снизить скорость. "Неустранимость" - понятие весьма субъективное и зависит от авторов прошивки к модему. Процедура эта довольно неприятна, поскольку занимает значительное время (несколько секунд - а если линия у вас трещит часто, а модем просит ретрейн на каждый треск, то заметную часть времени данные просто не передаются), да и сам по себе чувствителен к шумам и трескам.
          Соответственно, устойчивость и скорость работы модема на шумных линиях во многом зависит от его "политики" по отношению к ретрейнам - тот, что просит ретрейн на каждый чих жить толком не будет. Например, "сбой синхронизации TCM" (о TCM - позже) можно устранить ретрейном, а можно - запросом renegotiation на скорость, равную текущей. Те, кто знает про этот трюк - на шумных линиях работают, кто не в курсе - ретрейнится. Впрочем, я отвлекся. Вернемся к v32 :-)
          Скорости v32 - 4800, 7200 и 9600 bit/s, довольно скоро появился протокол v32bis (собственно, чистого v32 я ни разу и не видел - только v32bis да v32t), в котором появились скорости 12000 и 14400 бит/с, затем, сначала как "фирменное расширение", а потом и как стандарт - v32terbo, со скоростями 16800 и 19200, вплоть до так и оставшегося нестандартным 21600 (V32terbo Enсhanced) в модемах Russian Courier 21600 (переделка USR Sportser 14400 выпуска первой половины 90-х). . Как видно - шаг изменения скорости равен 2400 бит/с, и эта традиция, в общем-то сохранилась. Новые скорости добавлялись простым и понятным способом - увеличением количества точек в сигнальном созвездии.
          Однако дальше опять случился затык. А может, просто инженерная мысль не сидела на месте и мешала дальше тупо наращивать плотность точек. :-) В-общем, выяснилось, что требования к шумам для больших скоростей получаются уж больно строгие, и ошибки при передаче идут уж слишком часто для того, чтобы успешно исправляться вышележащим протоколом коррекции-компрессии. Вот бы иметь возможность исправлять "на лету" хотя бы полпроцента "битых" бит, примерно как на компакт-дисках... да и недостатки v32* (которые частично пыталась исправить, например, приснопамятная USR, придумав v32 with ASL (Adaptive Speed Leveling) - возможность "несимметричной" передачи и динамического изменения скорости в обе стороны).
          Результатом стал протокол v34 (и его расширение - v34bis). За который, по моему глубокому мнению, создателям надо поставить памятник при жизни, предварительно оторвав у создателей все выступающие части, чтобы неповадно было :-)
          Итак, v34*. Непревзойденный до сих пор шедевр в области запихивания максимального количества информации в минимальной толщины звуковой канал с искажениями, потерями и шумами. По порядку:
          - уже знакомая нам QAM.
          - уже знакомое нам эхогашение.
          - широкий выбор всего подряд с каждой стороны: в отличие от v32, где (даже с ASL) частота несущей и бодовая скорость выбиралась совместно, здесь все параметры передачи (то есть абсолютно все) определяются принимающей стороной, и могут независимо изменяться. Почему принимающей - понятно: ей это шипение потом слушать :-)
          - разнообразие (по сравнению с v32) несущих и бодовых скоростей (читай: полос спектра), позволяющее выбрать "живую" рабочую полосу даже в клинических случаях "заваленных насмерть верхов" или "гудения на низах".
          - precoding, shaping, и тому подобная "предкоррекция" - внесение передающей стороной "предыскажений", компенсирующих искажения канала передачи (неравномерность АЧХ, нелинейность).
          - этап "замера" характеристик линии при установлении соединения.
          - штатная процедура rate renegotiation (изменения скорости) при изменении характеристик линии - на слух (при включенном динамике) слышится как короткое "попискивание" в процессе собственно связи.
          - и главное - так называемая TCM, Trellis Coded Modulation.
         На TCM я просто обязан остановиться подробнее. Как я уже говорил, чем плотнее расположены точки в сигнальном созвездии (и чем больше бит мы передаем в боде), тем выше требования к шумам и искажениям в линии. Практически это означает, что повышая скорость передачи данных мы повышаем (причем довольно резко) вероятность ошибки, сбоя при передаче. Пока количество сбоев исчисляется единицами бит на несколько единиц-десятков килобайт - с такими сбоями справляются протоколы коррекции/компрессии, работающие по принципу "обнаружение ошибки - запрос повтора". Такие алгоритмы обязательно присутствуют в современных модемах, и хороши тем, что исправляют ошибку вне зависимости от ее происхождения - раз не сошлась контрольная сумма - кадр отправляется в помойку и запрашивается новый кадр. Недостаток же... при попытках получить действительно предельные скорости, когда сбойные биты начинают пролетать слишком часто (бит на килобайт или чаще) бОльшая часть кадров (их нельзя делать слишком маленькими - растут накладные расходы: заголовок, контрольная сумма, синхронизация) отправляется "в корзину", и модем в основном занят перезапросами битых кадров, а не основной работой. При ошибках же порядка бита на сотню бит, когда, казалось бы, еще можно работать и работать (всего-то 1% сбоев, фи) классические протоколы коррекции-компрессии умирают вообще - 99.9% пакетов приходят битыми, 99% запросов на повтор не проходят по той же причине. И вот тут-то и спасает TCM :-)
          Идея треллис-кодирования в следующем. В поток "символов" ("символом" называется то, что передается за один бод - как правило это несколько бит) вводится дополнительная избыточность. Точнее, некоторые последовательности символов (которым, как мы помним, соответствует некая последовательность точек в сигнальном пространстве) объявлены "запрещенными". При этом множество "запрещенных" последовательностей подобрано так, что для каждой из них существует единственная "наиболее близкая" последовательность (мы-то знаем, что как правило ошибка заключается в том, что точка сигнального созвездия ошибочно детектируется как одна из ближайших к ней точек). Получив "запрещенную" последовательность, декодер по специальному алгоритму определяет наиболее вероятную неискженную последовательность, разворачивает ее в поток бит, и уже его отдает вышележащему протоколу коррекции/компрессии. Фокус в том, что приблизительно зная характер ошибок, и введя небольшую избыточность, получается с некоторой вероятностью восстановить неискаженный сигнал, и при этом вероятность восстановления оказывается достаточно большой, чтобы с неправильно восстановленными последовательностями (ясно, что декодер "придумает" что-то для любой входной последовательности, но для нетипичной ошибки при этом сбой все-таки почти гарантирован) успешно справлялся более высокоуровневый протокол коррекции/компрессии. Уфф.
          На самом деле все еще веселее, и используется не "множество последовательностей символов" а "пространство состояний кодера" (что похоже, но не совсем то), но я надеюсь, это упрощение только улучшило понимание общей идеи треллис-кодирования :-)
          А на слух v34 (скорость до 28800), а равно и v34bis (33600, шаг везде 2400) несильно отличается от v32. Начальное пи-и'и-и'и-и'и-и (как v32), короткое бжумм-БЖУММ (модемы убедились, что оба поддерживают v34 и обменялись "зондирующими сигналами" для промера характеристик линии), дальше - привычное "пшшшшшшшш-ПШШШШШШШШ-ШШкх..." - настройка эхогашения обоими сторонами, "вход" в соединение, гасим динамик - вперед!
          ...а теперь немного об отрывании выступающих частей. Протокол v34, как я уже говорил, самый вылизанный из используемых сейчас для передачи данных по "каналам ТЧ", и только парочка мелочей...
          Зондирующий сигнал (бжумм-БЖУММ в самом начале соединения) передается на уровне +6дБ к номинальному. С какого перепуга разработчики это сделали - неясно, а как результат - на некоторых каналах сигнал этот перегружает канал, что заставляет уменьшать уровень, что (очевидно) приводит к ухудшению соотношения сигнал/шум и ухудшению связи. Впрочем, сейчас вроде как-то извернулись, и сигнал привели к разумному уровню.
          Есть в стандарте v34 такая фича. Power Drop называется. Если удаленный модем слышит достаточно сильный (по его мнению), но искаженный сигнал, и он (удаленный модем) считает, что искажения вызваны перегрузкой звукового канала, он может запросить "сброс мощности" - попросить "не орать, я и так неплохо слышу". А вот обратной процедуры предусмореть как-то не догадались. Как классический результат - некоторые модемы motorolla на линиях с большими искажениями. "Сигнал искажен, сбрось мощность - Ок, сбросил - все равно искажен, сбрось еще - ладно, сбросил - ой, что-то я тебя не слышу... тууу-тууу-тууу...). Нечасто, но бывает.
          TCM и прочие прелести превращаются в этакую палку о двух концах под названием "задержки" - и если для выкачивания mp3 это абсолютно несущественно, то для, например, игр, это может стать смертельным. Поэтому любителям Quake и прочего, советую сразу запретить в модеме v34.
          В остальном же - некий шедевр мироздания. Так и застывший, увы, в точке 33600 (на "аналоговых" АТС мешает шум, на "цифровых" же - мешает то, что QAM совершенно не приспособлен для борьбы с характерными "цифровыми" искажениями сигнала).
          ...поскольку 56к протоколы в большинстве своем куда менее интересны. Поскольку в мире наметился массовый переход на цифровые телефонные сети, качество же обычной, "аналоговой" аппаратуры улучшаться не собирается, а протокол v34 отлично борется с "аналоговыми" искажениями сигнала, но беспомощен против "ступенек" дискретизации - v34 с его QAM+TCM так и остался на 33600, а создатели 56к модемов пошли другим путем.
         Искажения бывают разные. Белые, желтые, красные... ой, я не про то :-) Изначально, когда модемные протоколы только-только разрабатывались, телефония была аналоговой, искажения были в виде неровностей АЧХ и ФЧХ (амплитудно- и фазо-частотной характеристик), а шум был "подкрашенный белый" (в достаточной мере случайный с гладким спектром), потому и модуляция разрабатывалась в расчете на такие вот "мягкие агалоговые" искажения. Успехи были достигнуты большие, но... Но на цифровых АТС это не слишком помогло. Сигнал на них дискретизуется, передается в виде 8-битных отсчетов, ~8000 отсчетов в секунду, и плавный входной сигнал превращается в "ступенчатый" на выходе. "Классических" искажений (амплитудных, фазовых) практически нет, но зато появляется "шум дискретизации" - разность между переданным и принятым сигналом, имеющая вид мелкой "пилы" (треугольных "пичков", следующих с частотой дискретизации), хитрым образом зависящей от входного сигнала. Вообще-то в этой "пиле" тоже содержится информация(!), но v34, как и другие QAM-based протоколы про это не в курсе, и для них это - шум. Причем шум резко "окрашенный", да еще и зависящий от входного сигнала, что отнюдь не способствует. Поэтому, собственно, v34* при реальных 64кбит, бегающих "там, между станциями", наружу может вытащить 33600, не больше.
          Первыми, пожалуй, выдвинули свое решение USR - заслуженно полузабытый протокол x2. Идея проста. По телефонной сети один фиг идет цифровой поток до 64кбит/с. От АТС до клиента идет неплохой такой медный провод, в котором полоса отнюдь не ограничена тремя килогерцами, да и перегрузок он не боится. Давайте поставим прямо на АТС железяку, которая будет связана с модемом клиента прямым медным проводом, один конец железяки воткнем непосредственно в цифровой канал АТС, а другой - соответственно, отдадим клиенту. Цифровой канал дает до 64кбит, а качество аналогового (провод) позволяет забыть про TCM и прочие тонкости, а просто забабахать сигнал с полосой килогерц этак восемь, да помощнее, и обойтись обычным QAM. Ну, а если клиент звонит обычным телефоном - то "модем" простаивает, а работает стандартная аппаратура телефонной станции.
          Достоинства - этот протокол действительно использует "цифровой" канал до последнего бита в секунду :-) Недостатки... X2-server (та железка, что ставится на АТС) надо ставить на АТС клиента. То есть, если в городе десять АТС - либо провайдер разоряется на десять стоек (и разговаривает с руководством десяти АТС на тему установки абонентского оборудования, что само по себе геморройно), либо - некоторые клиенты останутся без x2. Плюс к этому - неравномерность распределения клиентов по АТС, неравномерность нагрузки... в-общем, оно круто, но дороговато получается. Поэтому x2 кое-где еще есть, но уже мало.
          К слову, поскольку идея-то хороша сама по себе, цикл реинкарнации уже идет вовсю. Правда, уже не в виде классического "модема", а в виде разнообразных xDSL (по сути - short-range модемов) с перекачкой данных непосредственно по каналам телефонной сети.
          Дальше - больше. Помним старую шутку: "если я переименую zip в wav, запишу на магнитофон а потом оцифрую обратно - разве не получится тот же самый zip?". Ну, в каждой шутке, как известно, есть доля шутки :-) Протоколы k56flex и сегодняшний фактический стандарт - v90 - работают именно так. Точнее, в "исходящую" сторону (от клиента к серверу) используется все та же QAM+TCM, а вот во "входящую" - информация передается непосредственно перепадами уровней, этими самыми "ступеньками" дискретизации, которые так мешают жить v34. :-) Естественно, поскольку искажения в "медном проводе" таки есть, скорость редко достигает теоретического предела (в х2, напомню, все лучше - "проводной" канал как правило не является узким местом), и реально наблюдается что-то от 40 до 50 кбит, остальное уходит в избыточность кодирования. Начальное установление соединения на v90 не спутаешь ни с чем - после бжж-пшшш идет очень характерный "вечерний звон" - БОММмммм... БОМММмммм... - калибровка АЦП принимающего модема под параметры линии и замеры переходных искажений. Модуляция же в протоколе, можно сказать никакая - используется только цифровая избыточность для компенсации неидеальности линии. По каналу же - "ентот зип переименован в вав и записан на магнитофон" :-)
          Достоинства. Главное - простота серверной части. На АТС клиента изменять не надо ничего абсолютно - там и так уже все есть. На сервере (который теперь может быть один на город, а не по штуке на каждой АТС) "модема" в его классическом понимании, собственно, и нет - провод с "цифрой" из АТС непосредственно входит в коробочку "модема", минуя ненужную теперь аналоговую часть. Модемная стойка, кстати, прикидывается для окружающего мира "ма-аленькой АТСкой", а наличие внутри 30 номеров вовсе не означает наличия там 30 экземпляров модема - достаточно производительный процессор может "обсчитывать" несколько соединений одновременно.
          Недостатки... Скорость редко достигает предельной. Поскольку искажения есть всегда. Протокол несимметричный - "вверх" идет обычное v34bis с потолком в 33600. Если позвонить с модема на v90 на другой такой же - получится v34bis, поскольку "серверная" часть требует прямого подключения к "цифре" на АТС. Если по пути от АТС до абонента есть хоть что-то отличное от прямого медного провода (скажем, офисная АТС или радиоудлиннитель) - v90 умирает, поскольку так нужные ему "ступеньки" расплываются уже запредельно. В остальном же - простой как валенок и довольно надежный протокол.           Собственно, я был уверен, что на этом прогресс классического модемостроения остановится - нельзя быть святее Папы Римского, и нельзя превзойти v90 по скорости при приемлемой цене (существенно дороже - легко, пример - x2). Тем не менее... см. в самом низу статьи. А пока - протоколы коррекции/компрессии, и немного об экзотике :-)           Итак, как там битики заворачиваются в "пшшшшшшш" я надеюсь уже всем понятно. Понятно также, что единичные "сбои" - ошибочно принятые данные - есть вещь неизбежная при работе с предельной скоростью. Поэтому с самого начала модемостроения использовались и используются протоколы коррекции ошибок. Работающие по более-менее одинакововму принципу: поток данных нарезается на "кадры", каждый кадр обвешивается заголовком, контрольной суммой и синхропоследовательностью, на приемной же стороне - выделяется кадр (по синхропоследовательности), проверяется контрольная сумма, и, при ошибке, выдается запрос на повторную посылку сбойного кадра. При этом алгоритму глубоко наплевать на характер и природу ошибки - кадр с одним-единственным сбойным битом, и кадр, в котором нет ни одного правильного бита (все проинвертированы:-)) будет одинаково объявлен "сбойным" и перезапрошен. В этом смысле упомянутое выше треллис-кодирование хорошо работает в паре с "классическими" алгоритмами коррекции: одиночные ошибки исправляются TCM, множественные же ошибки на выходе TCM с заметной вероятностью дают "кашу", малопохожую на исходный сигнал, но - это уже некритично, все равно "убит" будет один, максимум два кадра.
          А алгоритмов не так уж много. Самый ранний протокл коррекции из примененных в модемах - MNP2 (Microcom Network Protocol, где был и был ли MNP1 - история умалчивает). Байт-ориентированный, синхронный (каждый байт обрамляется стартовым/стоповым битом), и, что любопытно, "прозрачный" для аппаратной части модема. То есть, к модему, не имеющему встроенной коррекции, можно "довесить" внешнюю реализацию mnp2, работающую через стандартный RS-232, не затрагивая собственно внутренности модема. Проблему с программами, которые хотят сами работать с модемом, и, зачастую, не в курсе, что им бы надо бы работать не с модемом, а с "драйвером mnp2" я оставлю в стороне - в каких-то случаях она решалась легко, в каких-то не решалась вообще.
          MNP3, как дальнейшее развитие протоколов коррекции, отказался от старт-стоповых битов внутри кадра (уменьшив накладные расходы на их передачу и ускорившись в результате почти на 20%), принципиальных же изменений (не считая более сложного "входа в протокол" и невозможности внешней, "программной", реализации) нет. MNP4, точнее то, что так называют, есть просто улучшенная реализация того же самого протокола.
          С появлением MNP5 жить стало однозначно веселей. Появилась хоть какая-то компрессия (передающая сторона "на лету" сжимала данные, принимающая же их разжимала обратно), с единственным мелкием недостатком - если данные сжимались плохо (архив я передаю, например - всяко RAR лучше пожмет чем пластиковая коробочка с лампочками), то в результате сжатия их объем увеличивался. :-) Не так уж чтобы сильно, но достаточно для того, чтобы выключать MNP5 в модеме если предполагался обмен архивами. Впрочем, встретить сейчас модем, поддерживающий только MNP - довольно сложно. С появлением...
          ...с появлением v42bis. Как в свое время v34 собрал в себя все лучшее из существоваших тогда протоколов модуляции, и так и остался на вершине, так и в v42 (а затем в v42bis) внесли все лучшее, что тогда было, и еще чуть-чуть. В подробности, наверно, углубляться не буду (вряд ли вам будет сильно интерено читать подробности про "улучшение фрейминга" с целью более быстрого обнаружения битых кадров или наличие SREJ - selective reject - выборочного перезапроса кадра "из середины потока"), для полноты замечу, что v42bis отличается от v42 наличием компрессии, предельная компрессия (как обычно - "в природе не встречающаяся") - до 4 раз, при невозможности сжатия данные передаются "как есть", без увеличения объема). Собственно, про компрессию я, можно сказать, закончил.
         Пару слов о winmodem'ах. Идея сделать "бюджетный" модем, где все что можно вынесено в компьютер, далеко не нова. Та же "навесная" MNP2 коррекция была первой ласточкой такого подхода. Проблемы тогда были те же - программа пользователя должна была работать не с модемом, а с другой программой. Поскольку во времена господства MNP2 был DOS, а под дос более-менее стандартом был FOSSIL (FIDO-Opus-Seadog Serial Interface Layer), драйвера MNP2 имели интерфейс fossil, а уж дальше - если прикладная программа умела пользоваться fossil - нет проблем, если нет - ну, значит нет. MNP с более крупными номерами как-то не были затронуты "софтмодемностью" (во многом потому, что MNP больше MNP2 нельзя навесить к любому модему, а разработка модема с "закладками" для навесных протоколов компрессии оказалась задачкой малоперспективной).
          А первые "классические" винмодемы назывались RPI (Rockwell Protocol Interface, по имени фирмы-разработчика Rockwell). Точнее, это были не совсем "классические" винмодемы - сегодняшний винмодем без драйвера есть мертвый кусок кремния, в то время как RPI-модем без драйвера - это обычный v32/v34 модем без коррекции. Общение драйвера с модемом происходило через стандартный RS-232 с помощью специальных команд. Соответственно, в модеме были нужные возможности, вроде перехода в синхронный режим по команде драйвера, и достаточного размера буфера для передачи v42-кадра "одним куском". Прикладные программы под windows (ну не под дос же) работали через библиотечку с символическим названием v42.dll. :-) Честно говоря, не знаю, насколько далеко тогда заходила эмуляция "модема" этой dll'кой, но думаю, что проблемы были те же: программа должна была быть в курсе, иначе коррекции/компрессии не было. Сейчас, как мы знаем, если эта вин-глюкала (а количество глюков, связанных с винмодемами, просто огромно по сравнению с нормальными, пусть и внутренними, модемам) более-менее согласилась увидеться и работать со своими драйверами (это не значит, что через неделю виндовый plug-n-play не обраружит у вас на мыши среднюю кнопку и не перераспределит ресурсы так, что винмодем окажется конфликтующим за прерывание с контроллером жестких дисков), то запущенные "терминалки", пытающиеся работать с RS-232, втихую заворачиваются "куда надо", создавая впечатление, что модем - вот он, живой такой, веселый. В-общем, не берите винмодемы. Не ищите приключений на свою пятую точку. И не забывайте, что там, где экономят доллары на DSP - те же доллары экономят и на аналоговой части, поэтому аналоговая часть винмодемов обычно реализована хуже.
                    На закуску - об экзотических примерах протоколов.
            - v32terbo - изначально был "фирменной экзотикой" (как следствие - "кривые" попытки повторить   - v32t Российскими апгрейдерами спортсеров), затем стал стандартным. Скорость - до 19200 (против 14400 v32bis), достигнута тупым расширением сигнальных таблиц.
            - ZYX. Кто автор вы уже, наверно, догадались, ;-) по сути - та же "терба" (v32t), но со своими сигнальными таблицами. Совместима сама с собой, с появлением v34 стала неактуальна, как впрочем и v32t.
            - ZyCELL - "сотовая" разновидность ZYX. Отличается, по сути, бОльшими таймаутами и бОльшим упорством при ретрейнах. Если обычному модему хорошенько "пошуметь" в линию 3-5 секунд, а лучше - подомкнуть ее отверточкой - связь обычно разрывается, ZyCELL продолжает пытаться.
            - HST. От High Speed Transfer (или Technology? По yandex.ru на high speed transfer - 515 документов, на high speed technology - 648 документов, так что как правильно - я уже не уверен). Разработка незабвенной USR, предназначен для связи в плохих условиях (шумы, искажения). Прост, как все крутое :) Поскольку много геморроя доставляет современным протоколам эхогашение (собственный крик), а в условиях плохой связи (особенно нелинейных искажений и большого "дальнего" эха) качественно погасить эхо весьма непросто, HST сделан резко несимметричным. В одну сторону у него до 16800 бит/с (в широкой полосе), в противоположную - до 450 бит/с в узенькой полосе(и этот канал наполовину забит служебной информацией v42). Разделение каналов - только частотное, внутри - обычный QAM. Протокол очень устойчив, почти идеален для однонаправленной передачи данных (долго-долго качаем файл, потом можем долго-долго закачивать файл туда), предусмотрен "переворот канала" (при забитии передающих буферов одной из сторон). К сожалению, для классического сегодняшнего применения - интернет - непригоден, поскольку даже поток запросов-подтверждений tcp/ip слишком толст для тонкого "обратного" канала, и попытка работать в интернете с HST есть наблюдение за непрерывным переворотом канала туда-сюда (что резко замедляет, да и не менее резко снижает надежность, поскольку переворот канала делается через ретрейн). Так что HST остался в прошлом - вместе с протоколами вроде zmodem.
            - PEP. Разработка фирмы telebit, реализован в ставшем историей модеме telebit trailblazer. Грандиозная вещь, так разобраться, хотя и требовала слишком больших вычислительных мощностей. Идея вот в чем.
          Звуковые каналы бывают хреновые. Бывают даже очень хреновые - спутниковые, например, где и АЧХ страшненькая, и фаза плавает вовсю, и помехи всех видов - от узкополосных до "щелчков". Большинство протоколов используют доступную полосу единым "куском", оценивая сигнал/шум и затухания во всем куске сразу. В результате, при сильной неравномерности АЧХ и/или шума либо неэффективно используется широкая полоса (в центре полосы все может быть классно, но по краям, допустим, сильное затухание и шум), либо используется узкая полоса (а края... а зачем нам края?). Я уж не говорю про то, что v32/v34 надеются поиметь полосу хотя бы килогерца два - два с половиной, и если посреди диапазона торчит помеха (или, скажем, имеется узкий "завал" частот) - жить они уже не будут.
          В PEP (Paketized Ensemble Protocol, сами переведете если надо:)) все сделано веселее. Вся полоса разделена на несколько сотен(!) узеньких (единицы герц) подполос, и в каждой такой полосе, на своей несущей, с использованием самой обычной QAM, со скоростью от 2 до 6 бит/с, независимо передаются данные. Поверх этого, естественно, висит алгоритм, раскладывающий битики по каналам, и обеспечивающий их обратное складывание на другой стороне (задача нетривиальная с учетом разной скорости в каналах и тем фактом, что любой канал в любой момент может "усохнуть"). Поскольку полоса каждого канальчика - несколько герц, "плоская" АЧХ и линейная ФЧХ, равно как и "плоские" шумы для каждого отдельно взятого канальчика практически обеспечены, тем самым половина проблем обычных модемов снимается автоматически. Каналы, попавшие в "неудачные" места спектра (края диапазона, завал частот, узкополосная помеха) работают на пониженной скорости или не работают вообще. В процессе связи скорость может изменяться, а каналы, которым стало совсем плохо, выбрасываются вообще. Не помню, была ли реализована обратная процедура - возможно что и нет. :-) Короткие же "щелчки", хотя и бьют по всему диапазону сразу, тоже редко приводят к потере бит, ввиду медленной скорости в каждом из канальчиков.
          Модемы с PEP в свое время были круты до неимоверности, поскольку жили и давали приемлемую скорость на совершенно диких каналах (легенды говорят, что PEP умел качать даже при обрыве кабеля - впрочем, на то они и легенды), но - видимо, как и с iridium'ом - спрос умноженный на цену не смог перекрыть стоимость, и PEP больше не делают. Скорость... PEP - до 19200, turbo-PEP - до 23000. Н-неплохо, особенно если учесть, что v32 тогда только-только появлялся.
          Кстати, дело telebit живет и побеждает - наша отечественная разработка PComm работает именно по такому принципу. Кремний-то нынче подешевел, а плохие линии не всегда можно заменить на хорошие...

Ну, и на сладкое. Честно говоря, после k56flex и v90 я был твердо уверен, что ничего нового в мире "классических pstn-модемов" (pstn - public switching telephone network, "обычная телефонная сеть" то бишь, в отличие от isdn, например) не появится: как полоса аналоговых линий, так и пропускная способность цифровых вычерпаны почти до дна, драться за проценты никто не будет, а если нужна большая скорость - pstn-модем уже не спасет, нужен шортрэнж или какое-то еще более другое решение.
          Ан нет, инженерная мысль на месте не стоит. Не так давно ITU (International Telecommunication Union) утвердил тройку новых протоколов. v92, v44 и v59. Первый довольно интересен: "исходящая" скорость поднимается с 33600 до 48000 (могу только догадываться как - скорее всего отказом от QAM в исходящем канале и переходом на тот же PCM. Поскольку при этом решается задача "попасть в точку" аналоговым сигналом, что существенно сложней чем "померить амплитуду ступеньки", 56к никто не обещает - 48к добиться бы), уменьшается время установки соединения (о-о-о! это да. v90, фактичеки, устанавливает v34, а потом, поверх этого, пытаются поднять v90. Время на соединение, соответственно, нужно большое), и, самое любопытное - "V.92 появилась возможность временной остановки соединения для ответа на другой входящий звонок, тоесть теперь вы не пропустите важный телефонный звонок во время Internet-сеанса". Опять-таки, как оно сделано можно только догадываться. Если "с переделкой" оборудования АТС - то можно считать, что этого нет и не будет. Если без... я пока вижу один метод - ловить "биип-биип" call waiting на фоне "шипения" цифры, и реагировать на ситуацию (посылать на удаленный модем сигнал "ты там повиси пока я тут побазарю", переключаться на другой разговор (flash?), подзывать абонента к телефону/компьютеру). Но - это тоже не фонтан, поскольку call waiting и модемы - вещи чуждые друг другу, и дружить нормально для них проблемно.
          v44 - замена v42bis. "На 25% лучше". Ну, собственно, давно пора - v42bis уж столько лет исполнилось, модуляционных протоколов сколько поменялось, а этот трудяга все пашет. Непонятно только, почему всего 25% и как эта цифра измерялась.
          С v59 у меня лично непонятки. Привожу ту единственную строку, что у меня есть, разбирайтесь сами что бы это могло значить :-) "V.59 - протокол для обнаружения проблем в модемах и модемных соединениях". Протокол - для обнаружения проблем - в модемах и соединениях. То есть, данные по нему качать как бы и не требуется, похоже. Ну, ладно...           ...А вот теперь я с 99.9% уверенностью говорю, что дальнейшее развитие "модемов" прекратилось окончательно. Все, новых скоростей и протоколов больше не будет - ресурсы среды передачи вычерпаны полностью, дальше - short-range и xDSL.          

(c)2000 Радищев Дмитрий, при перепечатке ссылка на http://dibr.nnov.ru обязательна
          Выражаю благодарность Петру Ильницкому за помощь в подготовке статьи.

Пишите! mailto:dibr@kis.ru