Когда кому-то или чему-то становится плохо, то требуется нечто большее, чем просто констатация данного факта.
Читать полностью »
Рубрика «tcp» - 7
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 — это потеря основной функции. Очень быстро при обрастании доп.функционалом теряются тесты ключевого функционала, и со временем начинаются проблемы даже с ним. А еще при этом начинается инерция мышления: «это главная функция, она оттестирована сильнее всего, там бага быть не может, пользователь делает что-то не то».
Читать полностью »
Как делается оптимизация трафика
2014-03-06 в 6:06, admin, рубрики: tcp, Блог компании КРОК, инфраструктура, ит-инфраструктура, Сетевые технологии, метки: tcp, инфраструктура 
«КПД» стандартного WAN – всего около 10%
Если заглянуть в практически любой канал связи между филиалом компании и дата-центром, то можно увидеть достаточно неоптимальную картину:
- Во-первых, передается очень много (до 60–70% канала) избыточной информации, которая так или иначе уже запрашивалась.
- Во-вторых, канал загружен «болтливыми» приложениями, рассчитанными на работу в локальной сети, — они обмениваются короткими сообщениями, что негативно сказывается на их производительности в канале связи.
- В-третьих, сам протокол TCP изначально создавался для локальных сетей и отлично подходит для малых задержек RTT и при отсутствии потерь пакетов в сети. В реальных каналах при потерях пакетов скорость сильно деградирует и медленно восстанавливается за счет больших RTT.
Я работаю руководителем инженерной команды департамента телекоммуникаций КРОК и регулярно оптимизирую каналы связи дата-центров как наших, так и энергетических компаний, банков и других организаций. Ниже расскажу основы и приведу наиболее интересное, на мой взгляд, решение. Читать полностью »
Кроссплатформенный сервер с неблокирующими сокетами. Часть 4
2014-02-20 в 9:53, admin, рубрики: c++, SSL, tcp, неблокируемые сокеты, ненормальное программирование, Программирование, С++, сервер, метки: SSL, tcp, неблокируемые сокеты, С++, сервер Эта статья продолжает мои предыдущие:
Простейший кросcплатформенный сервер с поддержкой ssl
Кроссплатформенный https сервер с неблокирующими сокетами
Кроссплатформенный https сервер с неблокирующими сокетами. Часть 2
Кроссплатформенный https сервер с неблокирующими сокетами. Часть 3
В своих статьях я поэтапно расписываю процесс создания однопоточного кроссплатформенного сервера на неблокирующих сокетах.
Во всех предыдущих статьях, сервер принимал и отправлял сообщения только по ssl протоколу. В этой статье я опишу добавление в сервер поддержки обычного нешифрованного tcp протокола и научу сервер отправлять в браузер графический файл.
Но сначала немного пройдусь по комментариям к предыдущим статьям.
Читать полностью »
Ускоряем Nginx за 5 минут
2013-10-29 в 21:48, admin, рубрики: high performance, highload, nginx, optimization, tcp, высокая производительность, Серверная оптимизация, метки: high performance, highload, nginx, optimization, tcp 
Попытайтесь повторить это сами
Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Мне удалось довести этот показатель до 904,000 запросов в секунду. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.
Минутка банальности.
yum -y install nginx
На всякий пожарный, создадим бэкап исходного конфига.
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf
А теперь можно и похимичить!
Читать полностью »
Новый вид DDoS-атаки: найден баг протокола ТСР в Windows
2013-10-18 в 18:53, admin, рубрики: ddos, ddos-атака, IT-стандарты, manet, tcp, windows, Сетевые технологии, метки: ddos, ddos-атака, manet, tcp, tcp-ipУважаемые хабро-читатели, прежде чем перейти к сути хочу сразу сказать, что автор не является каким бы то ни было хакером или зловредным программером, исследующим со свечкой каждый темный угол драйвера или чего-либо другого программного, поэтому если об этой уязвимости уже известно, то не судите строго, а лучше посоветуйте патч.
Итак, в процессе отладки стека протоколов для сетей MANET, где тестировалось модифицированное ТСР-соединение радиосети с компьютером через Ethernet-шлюз, было случайно выявлено, что путем некорректного закрытия соединения клиентом на стороне сервера возможно удерживание ресурсов сокета бесконечно долго!
Началось всё с этого:
На скрин-шоте представлено ТСР-соединение между клиентом 192.168.0.108 (Ethernet шлюз) и сервером 192.168.0.187 (OS Windows Vista).
Как видно, при неправильном указании номера последовательности в пакете FIN ACK клиента, Windows сервер не закрыл сокет и не освободил ресурсы. Попытка соединиться еще раз с того же порта клиента (source port 40400) на порт сервера (destination port 31000) оказалась неуспешной. Сервер упорно требовал ACK в ответ на новый SYN от клиента.
Сначала, я решил что это просто какой-то баг на стороне стека MANET (помимо, конечно же, неправильного seqno в FIN ACK), но проанализировав поток по номерам sequence / acknowledgement и повторив этот же эксперимент для других портов оказалось, что таки да, Windows…
Пример другого порта сервера (30000):
Потом, перегрузив комп и повторили все еще раз. На этот раз соединение закрывал клиент, а сервер слушал порт 32000.
Результат тот же.
Читать полностью »