кто съел четверть канала?
Анализировал сегодня загрузку сети, и пришел к неутешительным выводам относительно того, насколько сильно деградировали программисты в последние годы.
Прошли времена модемов на 14400, гордых владельцев "русских курьеров", сделанных собственными руками. Закончилась борьба за каждую сотню байт в секунду. Вроде бы сегодняшние технологии позволяют развернуться широко, ввести в массы видеоконференции, потоковое видео, голосовые чаты... Но по прежнему трафик стоит недешево, и в наших условиях каждый мегабайт остается ощутимым. Также по прежнему, в силе остается правило: "левый траффик — находка для хакера». Да и вообще, позволительная неоптимальность протоколов имеет свои пределы.
Рассмотрим проблему расхода трафика при использовании популярной ОС Windows.
Итак, начинаем с запуска компьютера. Обычная Windows 2000, без каких либо изменений и патчей, независимо от нашего желания при включении сетевого интерфейса посылает широковещательные запросы arp достаточно странного вида, например arp who-has 192.168.0.51 tell 192.168.0.51 (последнее — собственный IP-адрес клиента).
По идеологии Microsoft эти ARP-запросы предназначены для обнаружения конфликтов адресов в сети. На практике, например, при работе в среде hotspot c включенным arp spoofing (для возможности использования сети с компьютера с любыми сетевыми адресами TCP/IP), Windows 2000 выдает ошибку о конфликте, и данная "фича" не отключается. Также пролетают пакеты на broadcast сети (пример 10.30.30.249.137 > 10.30.30.255.137).
Замечательно, особенно если учесть, что отключены опции "Client for Microsoft Networks" и "File and Printer Sharing for Microsoft Networks". Трафик несущественный, около 1-2 Кбайт, но дает информацию хакеру о имени машины, ее MAC адресе, ОС, и т.п.
Следующий пациент — MSN.
Создаем две цепочки в iptables на порт 1863, и начинаем считать трафик. Логинимся. После процедуры логина смотрим, сколько это «заняло» траффика.
136 18717 ACCEPT tcp -- * * 0.0.0.0/0 10.30.30.249
tcp spt:1863
89 5171 ACCEPT tcp -- * * 10.30.30.249 0.0.0.0/0
tcp dpt:1863
Всего лишь 18 Кбайт передано, и 5 принято. Детальный разбор "пролетевших" данных:
T 10.30.30.249:1109 -> 207.46.104.20:1863 [AP]
VER 31 MSNP9 CVR0..
T 207.46.104.20:1863 -> 10.30.30.249:1109 [AP]
VER 31 MSNP9 CVR0..
Как я понимаю, это хендшейк и согласование протокола. Данные передаются текстом, видимо с расчетом на то, что компьютер умеет читать исключительно по английски и бинарные данные не приемлет абсолютно. Особенно умиляют пробелы между словами. Больше похоже не на протокол, а на литературное произведение.
Можно предположить, что это дань совместимости (для работы протокола через HTTP proxy) но, например, через HTTP CONNECT бинарные данные в HTTPS передаются прекрасно, а через HTTP POST/GET их вполне можно кодировать (например base64).
Подобный стиль следует и далее:
T 207.46.107.104:1863 -> 10.30.30.249:1110 [AP] MSG Hotmail Hotmail 460..MIME-Version: 1.0..Content-Type: text/x-msmsgsprofil$ ilEnabled: 0..MemberIdHigh: 196608..MemberIdLow: -2138660096..lang_preference$ ode: ..Gender: ..Kid: 0..Age: ..BDayPre: ..Birthday: ..Wallet: ..Flags: 1536.$ OM6p6pM4WbswwxOogFjBV00jDiKR3Q0yWohkUnMckCYLXZ!GVBV3FxafvBSL9azh0kEm5UQ$$..Cl$ T 207.46.107.104:1863 -> 10.30.30.249:1110 [AP] LST angelgirl121@hotmail.com angelgirl121@hotmail.com 3 0..
Возможно, исполнение данных, передаваемых TCP-протоколом, сделано для удобства его чтения спецслужбами, или производителями других продуктов, поддерживающих MSN (однако письма из Microsoft автору centericq говорят об обратном). Никто этого не знает.
Есть у этого протокола и печальные особенности. Для интереса я сделал маркировку пакетов по признаку, который позволяет определять пакеты, уведомляющие собеседников о том, что противоположная сторона набирает сообщение. За 60 секунд это составило около 231 килобайт. Это 30 Кбит/c.
897 231672 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 STRING match TypingUser
Тут же сделал общий "замер трафика", и получил суммарно 115 Кбит/с.
Фактически, ~25% полосы пропускания (а если разобрать другие моменты, думаю, цифра вырастет значительно) пропадает впустую из-за лени программистов. Вполне несложно не передавать десять раз одно и то же словосочетание, превратить некоторые словосочетания в цифровой код, и как-то кэшировать некоторые данные (не передавать, например, каждый раз ник собеседника, а присвоить, скажем, порядковый номер...).
Да и вообще, если бы Microsoft предоставил удобную информацию по возможности блокировать некоторые трафикоемкие фичи со стороны пользователя — было бы намного удобнее, и помогло бы развитию этого IM. Однако вероятность этого крайне мала...
/* Так что если я правильно понимаю смысл заметки, получается что около 25% от трафика идет по статье "Microsoft". Выходит немалая сумма. Впору не платить за эту ОС, а требовать доплаты за ее использование. :-) — прим. Павла Нагибина */
редакционное послесловие
Вы, наверное, заметили, что эта статья попала у нас в рубрику «мнение», а не в sysadmin или «технологии», что казалось бы более логичным. А получилось так потому, что автор, хоть и выдает на гора вполне достоверные, эксперементально проверенные сведения, несколько передергивает факты: выпячивает то, что ему «глаза мозолит», а кое о чем умалчивает — уж я не знаю, сознательно или нет :) Поскольку у нас тут все это под шапкой «мнение», позволю себе и я немного порассуждать на данную тему.
Насчет «пацианта» MSN. Во-первых, из статьи создается такое впечатление, что сервис MSN — неотъемлемая часть Windows-системы, и пользоваться им мы просто обязаны. Хотя многие предпочитают другие системы IM, и, прошу заметить, многие из них передают столько же (если не больше) служебной информации, и настолько же безобразно представленной. Кстати, в том числе поэтому мы запретили использование ICQ у нас в редакции.
Но давайте взглянем на мир шире. Освежив в памяти список и принципы работы стандартизованных Internet-протоколов, мы с ужасом выясняем, что из стандартного «супового набора» (HTTP, FTP, DNS, TELNET, SMTP, POP3, IRCP) только DNS и TELNET являеются истинно бинарными протоколами, остальные же — точно такие же «текстовые», как MSN!
Вот посмотрите на канал управления FTP: там не просто «литературные произведения», но натуральная «Война и Мир», причем все три тома :)
Вот вам первый попавшийся под руку пакет из FTP-сессии:
0x0000 00 C0 DF 02 1D 61 00 C0-26 11 44 C5 08 00 45 00 .Àß..a.À&.DÅ..E.
0x0010 00 64 46 05 40 00 80 06-53 DE C2 E2 79 5A C0 A8 .dF.@.€.SÞÂâyZÀ¨
0x0020 63 CB 00 15 13 4B 13 A0-FE F8 59 FD 32 C3 50 18 cË...K. þøYý2ÃP.
0x0030 FF BA E6 55 00 00 31 35-30 20 4F 70 65 6E 69 6E ÿºæU..150 Openin
0x0040 67 20 41 53 43 49 49 20-4E 4F 2D 50 52 49 4E 54 g ASCII NO-PRINT
0x0050 20 6D 6F 64 65 20 64 61-74 61 20 63 6F 6E 6E 65 mode data conne
0x0060 63 74 69 6F 6E 20 66 6F-72 20 6C 73 20 2D 6C 2E ction for ls -l.
0x0070 0D 0A ..
Да, клиент, конечно-же ориентируется не по англицкому тексту, а по цифровым кодам (десятичным, я прошу заметить!), но а) текст этот все равно передается и б) сервер получает и воспринимает комманды, представленные именно в виде английских словечек.
Итого, не нужно запускать могучий сетевой анализатор, чтобы прикинуть, что в контрольном канале FTP 50% (половина) данных — совершенно непотребная бурда.
Исходя из логики автора, из этого всего вытекает, что RFC писали (и поныне пишут) напрочь деградировавшие программисты, а утверждали все это в качестве стандартов вообще полные идиоты во главе с Джоном Постелом (светлая ему память). Кстати, насчет «старых добрых времен» — работа над FTP велась с 1971 по 1985 год.
Можно долго развивать тему насчет оправданности использования «текстовых» протоколов, но это как бы совершенно отдельная тема, уходящая корнями в ARPANET, в проблемы интероперабельности и отладки.
Намного проще обвинить Microsoft в непрофессионализме, мелком пакостничестве, вымогательстве, а еще массонстве, сатанизме и распространении детской порнографии ;))
Denis Fedorishenko, впервые опубликовано на NAG.RU.
Редакционное послесловие Alice D. Saemon.
Прошли времена модемов на 14400, гордых владельцев "русских курьеров", сделанных собственными руками. Закончилась борьба за каждую сотню байт в секунду. Вроде бы сегодняшние технологии позволяют развернуться широко, ввести в массы видеоконференции, потоковое видео, голосовые чаты... Но по прежнему трафик стоит недешево, и в наших условиях каждый мегабайт остается ощутимым. Также по прежнему, в силе остается правило: "левый траффик — находка для хакера». Да и вообще, позволительная неоптимальность протоколов имеет свои пределы.
Рассмотрим проблему расхода трафика при использовании популярной ОС Windows.
Итак, начинаем с запуска компьютера. Обычная Windows 2000, без каких либо изменений и патчей, независимо от нашего желания при включении сетевого интерфейса посылает широковещательные запросы arp достаточно странного вида, например arp who-has 192.168.0.51 tell 192.168.0.51 (последнее — собственный IP-адрес клиента).
По идеологии Microsoft эти ARP-запросы предназначены для обнаружения конфликтов адресов в сети. На практике, например, при работе в среде hotspot c включенным arp spoofing (для возможности использования сети с компьютера с любыми сетевыми адресами TCP/IP), Windows 2000 выдает ошибку о конфликте, и данная "фича" не отключается. Также пролетают пакеты на broadcast сети (пример 10.30.30.249.137 > 10.30.30.255.137).
Замечательно, особенно если учесть, что отключены опции "Client for Microsoft Networks" и "File and Printer Sharing for Microsoft Networks". Трафик несущественный, около 1-2 Кбайт, но дает информацию хакеру о имени машины, ее MAC адресе, ОС, и т.п.
Следующий пациент — MSN.
Создаем две цепочки в iptables на порт 1863, и начинаем считать трафик. Логинимся. После процедуры логина смотрим, сколько это «заняло» траффика.
136 18717 ACCEPT tcp -- * * 0.0.0.0/0 10.30.30.249
tcp spt:1863
89 5171 ACCEPT tcp -- * * 10.30.30.249 0.0.0.0/0
tcp dpt:1863
Всего лишь 18 Кбайт передано, и 5 принято. Детальный разбор "пролетевших" данных:
T 10.30.30.249:1109 -> 207.46.104.20:1863 [AP]
VER 31 MSNP9 CVR0..
T 207.46.104.20:1863 -> 10.30.30.249:1109 [AP]
VER 31 MSNP9 CVR0..
Как я понимаю, это хендшейк и согласование протокола. Данные передаются текстом, видимо с расчетом на то, что компьютер умеет читать исключительно по английски и бинарные данные не приемлет абсолютно. Особенно умиляют пробелы между словами. Больше похоже не на протокол, а на литературное произведение.
Можно предположить, что это дань совместимости (для работы протокола через HTTP proxy) но, например, через HTTP CONNECT бинарные данные в HTTPS передаются прекрасно, а через HTTP POST/GET их вполне можно кодировать (например base64).
Подобный стиль следует и далее:
T 207.46.107.104:1863 -> 10.30.30.249:1110 [AP] MSG Hotmail Hotmail 460..MIME-Version: 1.0..Content-Type: text/x-msmsgsprofil$ ilEnabled: 0..MemberIdHigh: 196608..MemberIdLow: -2138660096..lang_preference$ ode: ..Gender: ..Kid: 0..Age: ..BDayPre: ..Birthday: ..Wallet: ..Flags: 1536.$ OM6p6pM4WbswwxOogFjBV00jDiKR3Q0yWohkUnMckCYLXZ!GVBV3FxafvBSL9azh0kEm5UQ$$..Cl$ T 207.46.107.104:1863 -> 10.30.30.249:1110 [AP] LST angelgirl121@hotmail.com angelgirl121@hotmail.com 3 0..
Возможно, исполнение данных, передаваемых TCP-протоколом, сделано для удобства его чтения спецслужбами, или производителями других продуктов, поддерживающих MSN (однако письма из Microsoft автору centericq говорят об обратном). Никто этого не знает.
Есть у этого протокола и печальные особенности. Для интереса я сделал маркировку пакетов по признаку, который позволяет определять пакеты, уведомляющие собеседников о том, что противоположная сторона набирает сообщение. За 60 секунд это составило около 231 килобайт. Это 30 Кбит/c.
897 231672 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 STRING match TypingUser
Тут же сделал общий "замер трафика", и получил суммарно 115 Кбит/с.
Фактически, ~25% полосы пропускания (а если разобрать другие моменты, думаю, цифра вырастет значительно) пропадает впустую из-за лени программистов. Вполне несложно не передавать десять раз одно и то же словосочетание, превратить некоторые словосочетания в цифровой код, и как-то кэшировать некоторые данные (не передавать, например, каждый раз ник собеседника, а присвоить, скажем, порядковый номер...).
Да и вообще, если бы Microsoft предоставил удобную информацию по возможности блокировать некоторые трафикоемкие фичи со стороны пользователя — было бы намного удобнее, и помогло бы развитию этого IM. Однако вероятность этого крайне мала...
/* Так что если я правильно понимаю смысл заметки, получается что около 25% от трафика идет по статье "Microsoft". Выходит немалая сумма. Впору не платить за эту ОС, а требовать доплаты за ее использование. :-) — прим. Павла Нагибина */
редакционное послесловие
Вы, наверное, заметили, что эта статья попала у нас в рубрику «мнение», а не в sysadmin или «технологии», что казалось бы более логичным. А получилось так потому, что автор, хоть и выдает на гора вполне достоверные, эксперементально проверенные сведения, несколько передергивает факты: выпячивает то, что ему «глаза мозолит», а кое о чем умалчивает — уж я не знаю, сознательно или нет :) Поскольку у нас тут все это под шапкой «мнение», позволю себе и я немного порассуждать на данную тему.
Насчет «пацианта» MSN. Во-первых, из статьи создается такое впечатление, что сервис MSN — неотъемлемая часть Windows-системы, и пользоваться им мы просто обязаны. Хотя многие предпочитают другие системы IM, и, прошу заметить, многие из них передают столько же (если не больше) служебной информации, и настолько же безобразно представленной. Кстати, в том числе поэтому мы запретили использование ICQ у нас в редакции.
Но давайте взглянем на мир шире. Освежив в памяти список и принципы работы стандартизованных Internet-протоколов, мы с ужасом выясняем, что из стандартного «супового набора» (HTTP, FTP, DNS, TELNET, SMTP, POP3, IRCP) только DNS и TELNET являеются истинно бинарными протоколами, остальные же — точно такие же «текстовые», как MSN!
Вот посмотрите на канал управления FTP: там не просто «литературные произведения», но натуральная «Война и Мир», причем все три тома :)
Вот вам первый попавшийся под руку пакет из FTP-сессии:
0x0000 00 C0 DF 02 1D 61 00 C0-26 11 44 C5 08 00 45 00 .Àß..a.À&.DÅ..E.
0x0010 00 64 46 05 40 00 80 06-53 DE C2 E2 79 5A C0 A8 .dF.@.€.SÞÂâyZÀ¨
0x0020 63 CB 00 15 13 4B 13 A0-FE F8 59 FD 32 C3 50 18 cË...K. þøYý2ÃP.
0x0030 FF BA E6 55 00 00 31 35-30 20 4F 70 65 6E 69 6E ÿºæU..150 Openin
0x0040 67 20 41 53 43 49 49 20-4E 4F 2D 50 52 49 4E 54 g ASCII NO-PRINT
0x0050 20 6D 6F 64 65 20 64 61-74 61 20 63 6F 6E 6E 65 mode data conne
0x0060 63 74 69 6F 6E 20 66 6F-72 20 6C 73 20 2D 6C 2E ction for ls -l.
0x0070 0D 0A ..
Да, клиент, конечно-же ориентируется не по англицкому тексту, а по цифровым кодам (десятичным, я прошу заметить!), но а) текст этот все равно передается и б) сервер получает и воспринимает комманды, представленные именно в виде английских словечек.
Итого, не нужно запускать могучий сетевой анализатор, чтобы прикинуть, что в контрольном канале FTP 50% (половина) данных — совершенно непотребная бурда.
Исходя из логики автора, из этого всего вытекает, что RFC писали (и поныне пишут) напрочь деградировавшие программисты, а утверждали все это в качестве стандартов вообще полные идиоты во главе с Джоном Постелом (светлая ему память). Кстати, насчет «старых добрых времен» — работа над FTP велась с 1971 по 1985 год.
Можно долго развивать тему насчет оправданности использования «текстовых» протоколов, но это как бы совершенно отдельная тема, уходящая корнями в ARPANET, в проблемы интероперабельности и отладки.
Намного проще обвинить Microsoft в непрофессионализме, мелком пакостничестве, вымогательстве, а еще массонстве, сатанизме и распространении детской порнографии ;))
Denis Fedorishenko, впервые опубликовано на NAG.RU.
Редакционное послесловие Alice D. Saemon.
Сетевые решения. Статья была опубликована в номере 12 за 2003 год в рубрике технологии
