Технология 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 на стороне конечного пользователя практически не изменились.
ПК, участвовавшие в проекте (слева) и экспериментальный маршрутизатор
В ходе эксперимента, прошедшего 16-17 ноября этого года данные были переданы из Остина (в центральной части штата Техас) в Токио, отстоящих друг от друга на расстоянии 21 153 км с задержкой в 296 миллисекунд.
Маршрут рекордной передачи
Конфигурация аппаратного и программного обеспечения
Стоит отметить, что конфигурация систем оконечного оборудования, расположенного в точках приема-передачи была самой обычной. Данные в них обрабатывали процессоры Core i7-6770K, в качестве сетевого адаптера использовалась карта Mellanox Ко ConnectX®-4, а в качестве операционной системы — CentOS Linux 7.1. Пропускную способность специалисты замеряли при помощи пакета iperf3. Важно, что передающая система, как отмечают разработчики в своем пресс-релизе, использовала протокол LFTCP, принимающая — стандартный TCP.
Оборудование, использованное в эксперименте и схема роутинга
Подтверждение работоспособности принципов предложенной технологии на уровне конкретного результата имеет важнейшее практическое значение, поскольку позволяет значительно расширить пределы объемов и скоростей транслируемых данных, определив тем самым направление развития сети Интернет, как минимум, на несколько лет вперед. Очень важно, что новый протокол LFTCP доступен с открытым программным кодом.
Одно из направлений, где такие скорости и объемы передачи информации могут оказаться востребованы – наука. Так один из проектов Токийского университета, связанный с биологией по оценкам специалистов потребует для полноценной обработки полезной информации пропускной способности в 50 Гбит/с. И это всего лишь один из примеров процесса, требующего обработки колоссальных массивов данных и их трансляции на скоростях в десятки гигабит, где технология LFTCP уже вскоре может оказаться очень востребованной. И, судя по прогнозам специалистов Токийского университета, потребность в возможностях Long Fat pipe TCP будет расти пропорционально развитию набирающего обороты процесса интернационализации научных разработок.
Уважаемые читатели, мы всегда с удовольствием встречаем и ждем вас на страницах нашего блога. Мы готовы и дальше делиться с вами самыми свежими новостями, обзорными статьями и другими публикациями и постараемся сделать все возможное для того, чтобы проведенное с нами время было для вас полезным. И, конечно, не забывайте подписываться на наши рубрики.
Другие наши статьи и события
- Подборка новогодних подарков до 2016 рублей от iCover
- Спортивная гарнитура Jabra Sport Pace. В подарок за комментарий на GT
- Спорт-семейство: Jawbone UP3 и UP2 с позабытым товарищем UP24
- Один производитель – разные судьбы: внешние HDD LaCie P’9220 1 ТБ и Rugged Triple 2 ТБ
- Подарки от Harman Kardon к Новому году
- Выбери свой стиль
Комментарии (14)
AMDmi3
17.12.2015 13:02-1> заменяются на 100 – гигабитные. И здесь вопрос эффективности использования резко возросшего потенциала пропускной способности канала сталкивается с ограничениями существующей технологии передачи данных TCP
Вопрос эффективности использования канала на практике определяется количеством соединений, коих обычно десятки тысяч.
Deranged
17.12.2015 13:03+2Похоже на очередные трудности перевода.
TCP, который на самом деле, на секундочку, TCP/IP, именно на уровне TCP никаких привязок к временным задержкам не имеет, кроме всяких алгоритмов буферизации на стороне клиентов и сетевого оборудования, которое «склеивает» и «режет» пакеты по своему усмотрению.
В статье упомянуто некое «кодирование». TCP/IP оперирует понятиями фреймов и пакетов, которые уже представлены моделью как плоские массивы байт, без конкретной прикладной нагрузки, со своими заголовками и окончаниями пакетов. И никакого сжатия или кодирования прикладных данных сам протокол не декларирует.
А вот уже Ethernet и другие протоколы уровня «физики» могут оперировать кодированием данных при помощи уровней сигналов. Манчестерский код, NRZI и т.д. Но TCP/IP на это глубоко фиолетово.
Так что, содержимое статьи примерно можно перефразировать как: «японские ученые изобрели некую вундервафлю имеющую отношение к передаче данных по сети, и что-то там про TCP».
amarao
17.12.2015 17:53Вы используете слово «революционное» чтобы указать на то, что изменения в протокол не совместимы с предыдущими реализациями, или так, языком болтаете, не думая?
Насколько я понимаю, они всего лишь потюнили congestion control algorithm, и получившееся совершенно совместимо с другими реализациями tcp, то есть ни о каких революционных изменениях речь не идёт.VoiceDao
17.12.2015 18:31Вы используете слово «революционное» чтобы указать на то, что изменения в протокол не совместимы с предыдущими реализациями, или так, языком болтаете, не думая?
Абсолютно никакого повода для иронии здесь нет. Почти троекратное увеличение пропускной способности в сравнении с предыдущим показателем, сохранив при этом возможности использования стандартного протокола и оборудования, это по вашему не достижение?amarao
17.12.2015 18:58Достижение, но не совершающее революции. Ни в плохом (поломка совместимости), ни в хорошем смысле.
Если революцию — что поменяется, если на всех серверах в мире продеплоить это изменение? Почти ничего или ничего. В экстремально быстрых сетях одиночные потоки tcp станут быстрее. Сами сервера даже не станут быстрее, потому что у них упор производительности — на параллельных запросах.
Ну представьте себе, что сейчас кто-нибудь выкатит 12-парный оптический кабель, который в три раза быстрее 4-парного. Что поменяется? Ничего. Революция это? Нет.
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:
Нет, можно же просто слать и плевать на подтверждения или раздувать окно.
Вариантов масса, главное чтобы потерь не было.
А клиента они походу тюнили тоже, хотя бы буфера сокетов.TheDaemon
21.12.2015 09:35Так я и посчитал, что окно дальше не раздуешь, оно максимальное (8GBit). Получается, что слать надо больше чем окно. Впринципе ничего не мешает слать больше. Так как клиентов они не модифицировали (или я так понял перевод), то непонятно как при этом избегать потерь.
phprus
17.12.2015 18:52> Очень важно, что новый протокол LFTCP доступен с открытым программным кодом.
А кто-нибудь уже нашел, где этот открытый код доступен?
Если да, то опубликуйте, пожалуйста, ссылку, а то у меня найти пока не получается.
TheDaemon
18.12.2015 00:03А что за теоретическое ограничение скорости в ~30Гбит/с? Что мешает теоретикам увеличивать окно и MSS и уменьшать RTT?
TheDaemon
18.12.2015 00:20В моей теории скорость будет ограничиваться Макс.окно/Мин.RTT, т.е. 8GBit/что-то меньше микросекунд, т.е. минимум в Пета, а может и в Экса битах в секунду :) Или я что-то не так посчитал?
TheDaemon
18.12.2015 00:27О! Я, кажется, понял в чем фишка. У них RTT 0.3с, т.е. макс скорость 8Gbit/0.3=27Gbit. А они как-то обошли ограничение размера окна, т.к. с их RTT в кабеле окажется 22GBit, а максимальное окно в TCP 8Gbit (это с window scaling). Значит они потюнили Congestion Controller так, чтобы он слал подтверждение ДО того как получит данные?
kolu4iy
Что-то google про lftcp разговаривает со мной на японском… А где можно почитать принципиальные отличия от обычного TCP?
icover
К сожалению, столкнулся с аналогичной проблемой( Возможно чуть позже появиться больше данных хотя бы на английском, постараемся добавить в публикацию больше подробностей. Пока, увы, технической информации минимум.