Приветствуем вас на страницах блога iCover! Стремительно растущие потребности в передаче больших объемов данных – знаковая тенденция нашего времени и мощный стимул для развития инфраструктуры информационных сетей. Одновременно с расширением географии коммуникаций растет и пропускная способность основных каналов связи: 10 – гигабитные сетевые каналы заменяются на 100 – гигабитные. И здесь вопрос эффективности использования резко возросшего потенциала пропускной способности канала сталкивается с ограничениями существующей технологии передачи данных TCP (Transmission Control Protocol), верхняя скоростная планка которой до недавнего времени ограничивалась рекордным значением 29 Гбит/с. Группа специалистов из Японии сумела разработать дополнение к существующему протоколу, которое позволило повысить существующее значение почти втрое. Прошедшие в ноябре этого года успешные испытания технологии подтвердили возможность ее применения с использованием существующего стандартного абонентского оборудования.

image

Технология TCP – одного из основных протоколов на основе которого работала и продолжает работать глобальная сеть Интернет была разработана еще в 1974 году. Популярность технологии TCP специалисты объяснили технической возможностью гарантированной доставки данных с уведомлением отправителя об их получении, чего не могла обеспечить передача по протоколу UDP. Продемонстрировав достаточно высокий “запас прочности”, протокол TCP прекрасно справлялся со своими базовыми задачами на скоростях, исчисляемых в килобитах, несколько позже – в мегабитах и десятках мегабит. Вполне удовлетворительные результаты протокол продемонстрировал и при пересечении отметки пропускной способности в 100 и 1000 Мбит/с.

Сегодня, когда передовые провайдеры уже осуществляют переход на скорости с 10 на 100 Гбит/с возможностей протокола TCP, изначально не рассчитанного на такие показатели пропускной способности уже оказывается недостаточно. Рекордное значение скорости передачи данных по протоколу TCP/IP, зафиксированное до последнего момента при избыточности кодирования не более 50% составляло 29 Гбит/с (97,7% от теоретически обоснованной). Ясно, что в сетях, способных ежесекундно транслировать до 100 Гбит такие показатели выглядят достаточно скромно.

Группа исследователей Токийского университета сумела разрешить существующее противоречие, предложив своеобразную модификацию протокола TCP, названную ими LFTCP (Long Fat pipe TCP). Использование новой технологии позволило передать данные по существующим 100 – гигабитным каналам сети TransPAC американской компании Pacific Wave со скоростью 73 Гбит/с, использовав таким образом пропускную способность сети почти на ?. При этом “дух и буква” самого протокола TCP на стороне конечного пользователя практически не изменились.

image

ПК, участвовавшие в проекте (слева) и экспериментальный маршрутизатор

В ходе эксперимента, прошедшего 16-17 ноября этого года данные были переданы из Остина (в центральной части штата Техас) в Токио, отстоящих друг от друга на расстоянии 21 153 км с задержкой в 296 миллисекунд.

image

Маршрут рекордной передачи

image

Конфигурация аппаратного и программного обеспечения

Стоит отметить, что конфигурация систем оконечного оборудования, расположенного в точках приема-передачи была самой обычной. Данные в них обрабатывали процессоры Core i7-6770K, в качестве сетевого адаптера использовалась карта Mellanox Ко ConnectX®-4, а в качестве операционной системы — CentOS Linux 7.1. Пропускную способность специалисты замеряли при помощи пакета iperf3. Важно, что передающая система, как отмечают разработчики в своем пресс-релизе, использовала протокол LFTCP, принимающая — стандартный TCP.

image

Оборудование, использованное в эксперименте и схема роутинга

Подтверждение работоспособности принципов предложенной технологии на уровне конкретного результата имеет важнейшее практическое значение, поскольку позволяет значительно расширить пределы объемов и скоростей транслируемых данных, определив тем самым направление развития сети Интернет, как минимум, на несколько лет вперед. Очень важно, что новый протокол LFTCP доступен с открытым программным кодом.

Одно из направлений, где такие скорости и объемы передачи информации могут оказаться востребованы – наука. Так один из проектов Токийского университета, связанный с биологией по оценкам специалистов потребует для полноценной обработки полезной информации пропускной способности в 50 Гбит/с. И это всего лишь один из примеров процесса, требующего обработки колоссальных массивов данных и их трансляции на скоростях в десятки гигабит, где технология LFTCP уже вскоре может оказаться очень востребованной. И, судя по прогнозам специалистов Токийского университета, потребность в возможностях Long Fat pipe TCP будет расти пропорционально развитию набирающего обороты процесса интернационализации научных разработок.



Уважаемые читатели, мы всегда с удовольствием встречаем и ждем вас на страницах нашего блога. Мы готовы и дальше делиться с вами самыми свежими новостями, обзорными статьями и другими публикациями и постараемся сделать все возможное для того, чтобы проведенное с нами время было для вас полезным. И, конечно, не забывайте подписываться на наши рубрики.

Специальная подборка Новогодних подарков от iCover

Другие наши статьи и события

Комментарии (14)


  1. kolu4iy
    17.12.2015 09:49

    Что-то google про lftcp разговаривает со мной на японском… А где можно почитать принципиальные отличия от обычного TCP?


    1. icover
      17.12.2015 10:10
      +4

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


  1. AMDmi3
    17.12.2015 13:02
    -1

    > заменяются на 100 – гигабитные. И здесь вопрос эффективности использования резко возросшего потенциала пропускной способности канала сталкивается с ограничениями существующей технологии передачи данных TCP

    Вопрос эффективности использования канала на практике определяется количеством соединений, коих обычно десятки тысяч.


  1. Deranged
    17.12.2015 13:03
    +2

    Похоже на очередные трудности перевода.
    TCP, который на самом деле, на секундочку, TCP/IP, именно на уровне TCP никаких привязок к временным задержкам не имеет, кроме всяких алгоритмов буферизации на стороне клиентов и сетевого оборудования, которое «склеивает» и «режет» пакеты по своему усмотрению.
    В статье упомянуто некое «кодирование». TCP/IP оперирует понятиями фреймов и пакетов, которые уже представлены моделью как плоские массивы байт, без конкретной прикладной нагрузки, со своими заголовками и окончаниями пакетов. И никакого сжатия или кодирования прикладных данных сам протокол не декларирует.
    А вот уже Ethernet и другие протоколы уровня «физики» могут оперировать кодированием данных при помощи уровней сигналов. Манчестерский код, NRZI и т.д. Но TCP/IP на это глубоко фиолетово.
    Так что, содержимое статьи примерно можно перефразировать как: «японские ученые изобрели некую вундервафлю имеющую отношение к передаче данных по сети, и что-то там про TCP».


  1. amarao
    17.12.2015 17:53

    Вы используете слово «революционное» чтобы указать на то, что изменения в протокол не совместимы с предыдущими реализациями, или так, языком болтаете, не думая?

    Насколько я понимаю, они всего лишь потюнили congestion control algorithm, и получившееся совершенно совместимо с другими реализациями tcp, то есть ни о каких революционных изменениях речь не идёт.


    1. VoiceDao
      17.12.2015 18:31

      Вы используете слово «революционное» чтобы указать на то, что изменения в протокол не совместимы с предыдущими реализациями, или так, языком болтаете, не думая?

      Абсолютно никакого повода для иронии здесь нет. Почти троекратное увеличение пропускной способности в сравнении с предыдущим показателем, сохранив при этом возможности использования стандартного протокола и оборудования, это по вашему не достижение?


      1. amarao
        17.12.2015 18:58

        Достижение, но не совершающее революции. Ни в плохом (поломка совместимости), ни в хорошем смысле.

        Если революцию — что поменяется, если на всех серверах в мире продеплоить это изменение? Почти ничего или ничего. В экстремально быстрых сетях одиночные потоки tcp станут быстрее. Сами сервера даже не станут быстрее, потому что у них упор производительности — на параллельных запросах.

        Ну представьте себе, что сейчас кто-нибудь выкатит 12-парный оптический кабель, который в три раза быстрее 4-парного. Что поменяется? Ничего. Революция это? Нет.


      1. Ivan_83
        21.12.2015 02:13

        Нет там ничего суперского.
        Ребята запили свой модуль ядра congestion control для TCP.
        Дальше они немного покумекали и сделали чтобы он не слишком заваливал канал и всё это не сваливалось в ретрансмиты.

        Это по силам любому школьнику.
        Вон hybla в линухе — менее 200 строк с комментами и всей обвязкой: http://lxr.free-electrons.com/source/net/ipv4/tcp_hybla.c
        а реально алгоритма там строк 100 и даже меньше.

        2 TheDaemon:
        Нет, можно же просто слать и плевать на подтверждения или раздувать окно.
        Вариантов масса, главное чтобы потерь не было.
        А клиента они походу тюнили тоже, хотя бы буфера сокетов.


        1. TheDaemon
          21.12.2015 09:35

          Так я и посчитал, что окно дальше не раздуешь, оно максимальное (8GBit). Получается, что слать надо больше чем окно. Впринципе ничего не мешает слать больше. Так как клиентов они не модифицировали (или я так понял перевод), то непонятно как при этом избегать потерь.


  1. phprus
    17.12.2015 18:52

    > Очень важно, что новый протокол LFTCP доступен с открытым программным кодом.
    А кто-нибудь уже нашел, где этот открытый код доступен?
    Если да, то опубликуйте, пожалуйста, ссылку, а то у меня найти пока не получается.


  1. TheDaemon
    18.12.2015 00:03

    А что за теоретическое ограничение скорости в ~30Гбит/с? Что мешает теоретикам увеличивать окно и MSS и уменьшать RTT?


    1. TheDaemon
      18.12.2015 00:20

      В моей теории скорость будет ограничиваться Макс.окно/Мин.RTT, т.е. 8GBit/что-то меньше микросекунд, т.е. минимум в Пета, а может и в Экса битах в секунду :) Или я что-то не так посчитал?


      1. TheDaemon
        18.12.2015 00:27

        О! Я, кажется, понял в чем фишка. У них RTT 0.3с, т.е. макс скорость 8Gbit/0.3=27Gbit. А они как-то обошли ограничение размера окна, т.к. с их RTT в кабеле окажется 22GBit, а максимальное окно в TCP 8Gbit (это с window scaling). Значит они потюнили Congestion Controller так, чтобы он слал подтверждение ДО того как получит данные?


  1. milast
    18.12.2015 06:32

    А почему не используется протокол SCTP?