Стремительно растущие потребности в передаче больших объемов данных – знаковая тенденция нашего времени и мощный стимул для развития инфраструктуры информационных сетей. Одновременно с расширением географии коммуникаций растет и пропускная способность основных каналов связи: 10 – гигабитные сетевые каналы заменяются на 100 – гигабитные. И здесь вопрос эффективности использования резко возросшего потенциала пропускной способности канала сталкивается с ограничениями существующей технологии передачи данных TCP (Transmission Control Protocol), верхняя скоростная планка которой до недавнего времени ограничивалась рекордным значением 29 Гбит/с. Группа специалистов из Японии сумела разработать революционное дополнение к существующему протоколу, которое позволило повысить существующее значение почти втрое. Прошедшие в ноябре этого года успешные испытания технологии подтвердили возможность ее применения с использованием существующего стандартного абонентского оборудования.
Рубрика «tcp» - 7
73 Гбит-с — таков новый абсолютный рекорд скорости передачи данных по протоколу TCP
2015-12-17 в 6:20, admin, рубрики: LFTCP, tcp, Блог компании iCover.ru, периферия, протоколы проводной связи, Сетевое оборудование, системы передачи данных, Софт
Google успешно использует новый интернет-протокол QUIC в работе браузера Chrome
2015-04-18 в 21:19, admin, рубрики: chrome, Google, QUIC, tcp, метки: Chrome, QUIC 
На этой неделе программисты Google в своём блоге рассказали, что уже половина запросов от браузера Chrome к серверам интернет-гиганта проходит по новому интернет-протоколу QUIC, который компания начала разрабатывать в прошлом году. Протокол работает поверх UDP и содержит возможности шифрования, эквивалентные TLS и SSL.
Разработка протокола была начата в попытках ускорить работу интернет-соединений по сравнению с текущим протоколом TCP. Протокол UDP работает быстрее, поскольку он изначально проще устроен, и не рассчитан на коррекцию ошибок. Обычно его используют программы, которым необходимо работать в реальном времени (например, многопользовательские игры). В таких случаях нет смысла проверять прохождение всех пакетов и пересылать заново потерявшиеся.
Читать полностью »
IO Ninja – программируемый эмулятор терминала-сниффер (часть 2)
2015-04-09 в 1:34, admin, рубрики: broadcast, named pipes, pcap, serial, tcp, udp, Блог компании Tibbo, отладка, Сетевые технологии, системное администрирование, эмулятор терминала 
Данная статья является продолжением предыдущей, вводной статьи, в которой речь шла о мотивации и истории создания терминала/сниффера IO Ninja, и было немного рассказано про встроенные возможности нашего продукта. Продолжим рассказ о том, что доступно «из коробки», но с более практическим уклоном.
IO Ninja изначально задумывалась как утилита типа «всё-в-одном», и в комплект поставки входит большое количество встроеных плагинов для работы со всеразличными транспортами в разных режимах. Однако вместо сухого перечисления списка плагинов и их возможностей я решил продемонстрировать маленькую выборку задач из жизни, с которыми в нашей компании сталкивались на практике, и с которыми общеизвестные терминалы и мониторы справляются хуже, чем IO Ninja (а чаще не справляются вообще).
Читать полностью »
IO Ninja – программируемый эмулятор терминала-сниффер
2015-03-31 в 7:25, admin, рубрики: broadcast, named pipes, pcap, serial, tcp, udp, Блог компании Tibbo, информационная безопасность, отладка, Сетевые технологии, скриптовые языки, скрипты, эмулятор терминала, метки: логгер, сниффер, эмулятор терминала 
Приветствую вас, уважаемыее!
Сегодня я хотел начать рассказ об одном интересном продукте представляемой мной на хабре компании Tibbo. Продукт этот может оказаться полезен широкому кругу IT-профессионалов, включая системных администраторов, специалистов по информационной безопасности, и, наконец, простых разработчиков, которым нет-нет, да и приходится программировать общение с устройствами и другой низкоуровневый ввод/вывод.
Разговор пойдёт про программируемый терминал/сниффер IO Ninja (здесь и далее я буду опускать слово «эмулятор» и говорить просто «терминал»). Подозреваю, что само определение «терминал/сниффер» может выглядеть достаточно непривычно, если не сказать странно. Поэтому начнём с истории возникновения IO Ninja.
Читать полностью »
How to prepare TCP
2015-03-12 в 12:49, admin, рубрики: graph, rtt, tcp, throughput, wireshark, Блог компании Петер-Сервис, Сетевые технологии, сети для самых маленьких, системное администрирование 
Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Читать полностью »
Пишем свой tcp-мультиплеерный сервер
2015-03-10 в 13:59, admin, рубрики: .net, .net 4.5, C#, tcp, серверВ этой серии статей хочу рассказать о том, как создать tcp мультиплеерный сервер. Плюс к этому я хочу сделать его лучше, чем он ей сейчас, и научится лучше программировать — с помощью комментариев.
В этом посте мы изучим, как подключиться к серверу, в следующем я планирую разобраться с тем, как передавать цельные пакеты данных.
Первым делом надо создать решение и 2 проекта в нем. Два проекта — это, собственно, сам сервер, а так же тесты к нему. Первым делом сделаем тесты доверительной библиотекой для сервера для доступа к internal c помощью добавления в AssemblyInfo.cs строчк: [assembly: InternalsVisibleTo(«НАЗВАНИЕ ПРОЕКТА»)]. Так же добавим к проекту с тестами библиотеку NUnit (это лишь мое предпочтение). На этом первоначальные приготовления закончены.
Читать полностью »
Получаем IP-адреса HTTPS-клиентов с HAProxy (frontend) на Nginx (backend) в режимах HTTP и TCP-балансировки
2015-01-04 в 8:06, admin, рубрики: haproxy, HTTPS, nginx, proxy protocol, tcp, системное администрированиеДовольно часто требуется балансировать нагрузку между несколькими веб-серверами. При этом, как правило, необходимо, чтобы веб-приложения получали реальные IP-адреса клиентов, а не IP балансировщика.
В случае балансировки и терминации HTTP(S)-трафика на HAProxy (Layer 7 [1]) данная задача легко решается добавлением заголовка “X-Real-IP” и его обработкой на Nginx при помощи модуля ngx_http_realip_module [2]. При балансировке TCP-трафика от HTTPS-клиентов и передаче его на веб-сервера напрямую без модификации или терминации (Layer 4 [3]) добавить данный заголовок невозможно, поэтому требуется воспользоваться возможностями, предоставляемыми Proxy Protocol [4, 5, 6].
Рассмотрим оба варианта (балансировка L7 и L4) на примере выдержек из конфигурационных файлов haproxy 1.5.9 и nginx 1.6.2
О тонкостях «шифрованного трубопровода» в процессе разработки IMAP-клиента на Scala+Akka+Spray
2014-09-19 в 11:48, admin, рубрики: akka, imap, scala, tcp, Программирование, Сетевые технологии Совсем недавно я перешел с горячо любимого мной объектно-ориентированного C++ на новый для меня и еще не совсем понятный функциональный Scala. Причины перехода — совершенно отдельная история. Но одной из них было наличие достаточно хорошей, судя по отзывам, поддержки модели акторов — с помощью библиотеки Akka. Я давно мечтал опробовать на собственном опыте все описываемые преимущества этой технологии, а существующие реализации на C++ (CAF_C++ и Theron), которые я немного повертел в небольших тестах, оказались достаточно сырыми для моих нужд. Наиболее каноническое же (по моему мнению) решение модели акторов — Erlang, — я отмел, так как посчитал, что для его освоения мне понадобится слишком много времени, да и не факт, что я смогу найти необходимые мне сторонние библиотеки для этого далеко не универсального языка. Поэтому в результате выбор мой пал именно на Scala в связке с Akka, тем более что Scala я когда-то давно уже начинал изучать, но забросил за нецелесообразностью. Однако, как оказалось, на этот раз время для своего эксперимента я выбрал не самое удачное, в чем я убедился только спустя некоторое время.
Читать полностью »
LinkMeUp. Выпуск №17. Недостатки TCP и новые протоколы транспортного уровня
2014-07-25 в 8:13, admin, рубрики: CeBIT, linkmeup, RWTP, tcp, аспирантура, германия, подкасты, Сетевые технологии, системное администрирование, Учебный процесс в IT 17-й выпуск подкаста Linkmeup посвящён глубокотехнической теме.
В гостях у нас Дмитрий Качан — аспирант СибГУТИ. Дмитрий в данный момент занимается разработкой транспортных протоколов, работающих на уровне приложений.
Поэтому сегодня мы говорим о недостатках TCP, почему сейчас он уже не может выполнять свою роль протокола с гарантированной доставкой в некоторых случаях.
Вы узнаете какие сейчас есть подходы к решению этой проблемы.
Новости выпуска
- Правительство хочет, чтобы данные россиян хранились в нашей стране (link).
- HP сделал свой сетевой симулятор доступным широкой общественности (link).
- В MIT разработали технологию управления трафиком датацентра, которая многократно уменьшает задержки и очереди (link).
- Плавный переход к теме гостя. Big Data на службе футбола (link).
Скачать файл подкаста.
Под катом вы можете найти список некоторых коммерческих решений и протоколов для эффективной передачи информации с гарантированной доставкой, а также сами исследования Дмитрия.
Читать полностью »
Почему рост качества вызывает рост некачества, или должна ли работать основная функция
2014-06-24 в 17:47, admin, рубрики: tcp, udp, баги, видеонаблюдение, отладка, Работа с видео, сетевое программирование, Сетевые технологии, метки: tcp, tcp-ip, udp, баги, видеонаблюдение, отладка, сетевое программирование 
Глупо спорить с тем, что аналоговое видеонаблюдение уходит в прошлое: дешевые IP камеры дают картинку сопоставимого качества с дорогими аналоговыми. Помимо этого, IP камеры не ограничены сверху ничем, кроме производительности регистратора, тогда как аналоговые камеры требуют жесткого соответствия приёмной карты, согласования уровней сигнала передатчиков/усилителей/приемников и прочего шаманства.
Конструируя систему на базе IP камер в любой момент можно снять камеру и заменить на более качественную — если при этом сохранить IP адрес и логин-пароль, то, скорее всего, даже не придётся менять настройки приемника — просто в архив пойдёт более качественная картинка.
С другой стороны, это накладывает ограничения на регистратор — он должен быть готов работать с любым разрешением, любым битрейтом, любым кодеком и любым протоколом… Ну или по крайней мере, корректно работать с заявленным.
В мире софта есть два пути — есть linux-way: это набор небольших программ, каждая из которых делает одну функцию, но очень хорошо; и есть windows-way: это огромные кухонные комбайны, которые умеют делать всё, и немного больше. Главная проблема linux-way — это отсутствие интерфейса. Чтобы получить всю пользу придётся скурить маны (или хотя бы прочитать --help), и поэкспериментировать. А так же сообразить, что и с чем можно скомбинировать и как. Главная проблема windows-way — это потеря основной функции. Очень быстро при обрастании доп.функционалом теряются тесты ключевого функционала, и со временем начинаются проблемы даже с ним. А еще при этом начинается инерция мышления: «это главная функция, она оттестирована сильнее всего, там бага быть не может, пользователь делает что-то не то».
Читать полностью »