Comments 14
Что-то google про lftcp разговаривает со мной на японском… А где можно почитать принципиальные отличия от обычного TCP?
> заменяются на 100 – гигабитные. И здесь вопрос эффективности использования резко возросшего потенциала пропускной способности канала сталкивается с ограничениями существующей технологии передачи данных TCP
Вопрос эффективности использования канала на практике определяется количеством соединений, коих обычно десятки тысяч.
Вопрос эффективности использования канала на практике определяется количеством соединений, коих обычно десятки тысяч.
Похоже на очередные трудности перевода.
TCP, который на самом деле, на секундочку, TCP/IP, именно на уровне TCP никаких привязок к временным задержкам не имеет, кроме всяких алгоритмов буферизации на стороне клиентов и сетевого оборудования, которое «склеивает» и «режет» пакеты по своему усмотрению.
В статье упомянуто некое «кодирование». TCP/IP оперирует понятиями фреймов и пакетов, которые уже представлены моделью как плоские массивы байт, без конкретной прикладной нагрузки, со своими заголовками и окончаниями пакетов. И никакого сжатия или кодирования прикладных данных сам протокол не декларирует.
А вот уже Ethernet и другие протоколы уровня «физики» могут оперировать кодированием данных при помощи уровней сигналов. Манчестерский код, NRZI и т.д. Но TCP/IP на это глубоко фиолетово.
Так что, содержимое статьи примерно можно перефразировать как: «японские ученые изобрели некую вундервафлю имеющую отношение к передаче данных по сети, и что-то там про TCP».
TCP, который на самом деле, на секундочку, TCP/IP, именно на уровне TCP никаких привязок к временным задержкам не имеет, кроме всяких алгоритмов буферизации на стороне клиентов и сетевого оборудования, которое «склеивает» и «режет» пакеты по своему усмотрению.
В статье упомянуто некое «кодирование». TCP/IP оперирует понятиями фреймов и пакетов, которые уже представлены моделью как плоские массивы байт, без конкретной прикладной нагрузки, со своими заголовками и окончаниями пакетов. И никакого сжатия или кодирования прикладных данных сам протокол не декларирует.
А вот уже Ethernet и другие протоколы уровня «физики» могут оперировать кодированием данных при помощи уровней сигналов. Манчестерский код, NRZI и т.д. Но TCP/IP на это глубоко фиолетово.
Так что, содержимое статьи примерно можно перефразировать как: «японские ученые изобрели некую вундервафлю имеющую отношение к передаче данных по сети, и что-то там про TCP».
Вы используете слово «революционное» чтобы указать на то, что изменения в протокол не совместимы с предыдущими реализациями, или так, языком болтаете, не думая?
Насколько я понимаю, они всего лишь потюнили congestion control algorithm, и получившееся совершенно совместимо с другими реализациями tcp, то есть ни о каких революционных изменениях речь не идёт.
Насколько я понимаю, они всего лишь потюнили congestion control algorithm, и получившееся совершенно совместимо с другими реализациями tcp, то есть ни о каких революционных изменениях речь не идёт.
Вы используете слово «революционное» чтобы указать на то, что изменения в протокол не совместимы с предыдущими реализациями, или так, языком болтаете, не думая?
Абсолютно никакого повода для иронии здесь нет. Почти троекратное увеличение пропускной способности в сравнении с предыдущим показателем, сохранив при этом возможности использования стандартного протокола и оборудования, это по вашему не достижение?
Абсолютно никакого повода для иронии здесь нет. Почти троекратное увеличение пропускной способности в сравнении с предыдущим показателем, сохранив при этом возможности использования стандартного протокола и оборудования, это по вашему не достижение?
Достижение, но не совершающее революции. Ни в плохом (поломка совместимости), ни в хорошем смысле.
Если революцию — что поменяется, если на всех серверах в мире продеплоить это изменение? Почти ничего или ничего. В экстремально быстрых сетях одиночные потоки tcp станут быстрее. Сами сервера даже не станут быстрее, потому что у них упор производительности — на параллельных запросах.
Ну представьте себе, что сейчас кто-нибудь выкатит 12-парный оптический кабель, который в три раза быстрее 4-парного. Что поменяется? Ничего. Революция это? Нет.
Если революцию — что поменяется, если на всех серверах в мире продеплоить это изменение? Почти ничего или ничего. В экстремально быстрых сетях одиночные потоки tcp станут быстрее. Сами сервера даже не станут быстрее, потому что у них упор производительности — на параллельных запросах.
Ну представьте себе, что сейчас кто-нибудь выкатит 12-парный оптический кабель, который в три раза быстрее 4-парного. Что поменяется? Ничего. Революция это? Нет.
UFO just landed and posted this here
> Очень важно, что новый протокол LFTCP доступен с открытым программным кодом.
А кто-нибудь уже нашел, где этот открытый код доступен?
Если да, то опубликуйте, пожалуйста, ссылку, а то у меня найти пока не получается.
А кто-нибудь уже нашел, где этот открытый код доступен?
Если да, то опубликуйте, пожалуйста, ссылку, а то у меня найти пока не получается.
А что за теоретическое ограничение скорости в ~30Гбит/с? Что мешает теоретикам увеличивать окно и MSS и уменьшать RTT?
В моей теории скорость будет ограничиваться Макс.окно/Мин.RTT, т.е. 8GBit/что-то меньше микросекунд, т.е. минимум в Пета, а может и в Экса битах в секунду :) Или я что-то не так посчитал?
О! Я, кажется, понял в чем фишка. У них RTT 0.3с, т.е. макс скорость 8Gbit/0.3=27Gbit. А они как-то обошли ограничение размера окна, т.к. с их RTT в кабеле окажется 22GBit, а максимальное окно в TCP 8Gbit (это с window scaling). Значит они потюнили Congestion Controller так, чтобы он слал подтверждение ДО того как получит данные?
А почему не используется протокол SCTP?
Sign up to leave a comment.
73 Гбит/с — таков новый абсолютный рекорд скорости передачи данных по протоколу TCP