73 Гбит/с — таков новый абсолютный рекорд скорости передачи данных по протоколу TCP

    Приветствуем вас на страницах блога 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

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

    iCover.ru
    0,00
    iCover.ru — магазин инноваций
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      0
      Что-то google про lftcp разговаривает со мной на японском… А где можно почитать принципиальные отличия от обычного TCP?
        +4
        К сожалению, столкнулся с аналогичной проблемой( Возможно чуть позже появиться больше данных хотя бы на английском, постараемся добавить в публикацию больше подробностей. Пока, увы, технической информации минимум.
        –1
        > заменяются на 100 – гигабитные. И здесь вопрос эффективности использования резко возросшего потенциала пропускной способности канала сталкивается с ограничениями существующей технологии передачи данных TCP

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

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

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

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

                Ну представьте себе, что сейчас кто-нибудь выкатит 12-парный оптический кабель, который в три раза быстрее 4-парного. Что поменяется? Ничего. Революция это? Нет.
                • НЛО прилетело и опубликовало эту надпись здесь
                    0
                    Так я и посчитал, что окно дальше не раздуешь, оно максимальное (8GBit). Получается, что слать надо больше чем окно. Впринципе ничего не мешает слать больше. Так как клиентов они не модифицировали (или я так понял перевод), то непонятно как при этом избегать потерь.
                0
                > Очень важно, что новый протокол LFTCP доступен с открытым программным кодом.
                А кто-нибудь уже нашел, где этот открытый код доступен?
                Если да, то опубликуйте, пожалуйста, ссылку, а то у меня найти пока не получается.
                  0
                  А что за теоретическое ограничение скорости в ~30Гбит/с? Что мешает теоретикам увеличивать окно и MSS и уменьшать RTT?
                    0
                    В моей теории скорость будет ограничиваться Макс.окно/Мин.RTT, т.е. 8GBit/что-то меньше микросекунд, т.е. минимум в Пета, а может и в Экса битах в секунду :) Или я что-то не так посчитал?
                      0
                      О! Я, кажется, понял в чем фишка. У них RTT 0.3с, т.е. макс скорость 8Gbit/0.3=27Gbit. А они как-то обошли ограничение размера окна, т.к. с их RTT в кабеле окажется 22GBit, а максимальное окно в TCP 8Gbit (это с window scaling). Значит они потюнили Congestion Controller так, чтобы он слал подтверждение ДО того как получит данные?
                    0
                    А почему не используется протокол SCTP?

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое