Ответьте, положа руку на сердце — вы представляете все последствия исправления бага? Вы представляете все последствия того или иного технического решения некоторой задачи?
Инженер — не робот. Инженер это человек, обладающий способностью/умением высококачественного творения, в котором учитывается множество различных деталей. Ещё раз повторюсь — инженер это тот же учёный-творец, только поле зачастую сужено определённой специальностью и предполагается мощная само-ответственность.
Точка-точка-запятая… На западе программист именно изучает computer science. Также логично вспомнить, что очень многое приходится «творить». В общем инженер — это учёный-творец. Как-то вот так.
На одном маршруте разные автобусы могут начинать движение с разных конечных остановок. Они потом и конечные, что на концах «линии» движения. Проблемой можно назвать только всяческие кольцевые маршруты (которые не имеют явно выраженной одной или обоих конечных).
Всё остальное субъективизм и тоже имеет право на существование ;)
я и написал — за редким видом. Большинство атак идёт с ботнетов, благо купить такие услуги, судя по слухам, не представляет сложности. Атаки же с помощью дедиков достаточно кропотливая работа — их ведь ещё надо бы собрать и их услуги реже продают.
так ясно-понятно, что пакеты в MTU не упирались — иначе бы поток резко больше был (900 000 * 1400 * 9 ~ 10.7 Гбит/сек).
Я и пытаюсь объяснить — суть ддоса не в перегрузке канала байтами (за редким видом атак), а в перегрузке сервера левыми запросами, которые в канал очень редко упираются.
Ну и особенность http позволяет проводить более изощрённые атаки, ибо коннекты живут некоторое время.
Да неважно это вообще. Это всё — теоретические измышления. В статье цитата: «Например, 30 марта система, отвечающая за распределение входящей нагрузки по серверам LiveJournal, обрабатывала более миллиона одновременных соединений при средней норме 50 тысяч соединений. ЖЖ пришлось обслуживать в десятки раз больше запросов, чем обычно, и “отдавать» по 2 Гбит трафика в секунду вместо обычных 400 Мбит»
Что у нас тут есть? Есть следующее «более миллиона одновременных соединений» — да легко, если соединения забирающие картинки — не закрылись, а новых навалилась куча. Другой вопрос — как они смогли столько соединений разрулить, но для этого существуют различные high-load механизмы. Скорее всего никак не разрулили — из-за мощного потока соединений сервер просто перегружался. В общем он пытался, но съедал на этом всю мощность и отвечал медленно.
Теперь по поводу счёта — счёт в данном случае бесполезен. Скорее всего сервер успевал обрабатывать только handshake. И соединения висели более чем по секунде. Пока сервер не получал хоть немного времени, чтобы обработать старые.
Далее MTU — максимальный размер пакета мало того, что не фиксированная величина (пакет имеет полное право быть меньше, либо равен MTU), так ещё и не подлежащая к использованию в данном контексте. Объясняю: поставьте на удалённой машине веб-сервер, ограничте к нему канал до 1Мбита/секунду и начните качать файл 20 Мбайта. Скачается файл за ~(20*9/1) = 180 секунд (3 минуты). Угадайте, соединение длилось 1 секунду и заново начиналось, или всё прошло в рамках одного соединения? Таким образом соединение длилось 3 минуты. Если с таким же каналом вы ткнётесь качать 10 таких файлов с сервера — каждый файл будет качаться медленнее, но соединения будет держаться. В конечном итоге ограничением является количество одновременных соединений, которое принимает сервер. Вот ровно по такой простой причине нет необходимости считать абстрактные цифры. Потому что просчитывается совсем другая ситуация, а не описанная.
PS сие была последняя попытка донести данную мысль, за сим прощаюсь.
Человек интересно, конечно, считает, но пакеты всегда разные. В виду неоднородности сети (пакеты проходят через множество узлов, у которых MTU может значимо различаться) нельзя твёрдо говорить, что MTU = 1500 байт, скорее оно было в районе 1200-1400. Но даже если принять MTU == 1500, то даже в этом случае расчёт в принципе неправильные:
пакет формируется по принципу — заполняем сколько можем, остальное в следующем пакете. пустые данные в пакете не передаются. Таким образом handshake в среднем требует около 300 байт (3 пакета). Далее (не знаю точно протокол http, скорее всего передаётся в 3ем пакете handshake`а) идёт запрос. В запросе передаются различные параметры, урл и ряд заголовков, характеризующих ПО запрашивающее (какие технологии поддерживаются etc). Далее сервер обрабатывая запрос может запросить куки. После получения всех необходимых данных клиенту отдаётся страничка. И тут начинается узкое место — пока данные клиенту не отданы (например картинка 20Мб) соединение не сбрасывается. Если канал перегружен — скорость конкретного соединения проседает, но разорваться оно может только по таймауту молчания (за каждые несколько принятых пакетов клиент отсылает отчёты). Соединения могут висеть больше минуты. Так что по сути — вопрос лишь в том, сколько реальных соединений может выдержать распределяющий сервер LJ (интересно, кстати, сколько их).
Суть — с помощью DDoS`а можно реально перегрузить принимающий сервер и он будет еле отвечать клиентам. И проблема будет не в канале.
Давайте уточним: аппарат принадлежит клиенту или оператору? Если первое, то на каком основании они могут оставлять следящее руткит-приложение не предупреждая клиента? Сколько помню США себя всегда позиционировали как аццких защитников частной собственности…
Простите, это я что-то путаю или не eBay вовсе не обязательно «новый операторский телефон»? Ну и, если я покупаю, то аппарат мой и без моего ведома они уже не имеют права пихать свои логгеры. В общем — если аппарат к сети не подключён и является собственностью клиента — никакого права без спецсоглашения (которое может идти отдельным пунктом в договоре) собирать какую-либо информацию о клиенте они не имеют права.
Не активированный и не активированный в сети оператора выглядят для меня разными фразами, хотя это больше вопрос к автору поста. В общем внимательно надо бы изучить проблемку, ведь одно дело, если телефон «арендуется» клиентом, другое — чистая продажа.
Я один дочитал до строки «За телефоном можно следить, даже если он никогда не был активирован в сети оператора»? Если понимать фразу буквально — то следить может не только «свой», но и «чужой» оператор… В общем интересные коллизии получаются ;)
Глупый вопрос — вы готовитесь сдавать OCJCP (или как он там правильно пишется) экзамен? Насколько я помню почти всё это может быть проверено вопросами. Ну и прочитать (хотя бы разик) умные книжки по Java — никогда не помешает.
Впрочем, я вряд ли сильно ошибусь, если скажу, что причины и свойства гравитационных сил весьма слабо изучены? Если у вас есть какая-нибудь информация по ним — с радостью почитаю :)
Инженер — не робот. Инженер это человек, обладающий способностью/умением высококачественного творения, в котором учитывается множество различных деталей. Ещё раз повторюсь — инженер это тот же учёный-творец, только поле зачастую сужено определённой специальностью и предполагается мощная само-ответственность.
Всё остальное субъективизм и тоже имеет право на существование ;)
Я и пытаюсь объяснить — суть ддоса не в перегрузке канала байтами (за редким видом атак), а в перегрузке сервера левыми запросами, которые в канал очень редко упираются.
Ну и особенность http позволяет проводить более изощрённые атаки, ибо коннекты живут некоторое время.
Что у нас тут есть? Есть следующее «более миллиона одновременных соединений» — да легко, если соединения забирающие картинки — не закрылись, а новых навалилась куча. Другой вопрос — как они смогли столько соединений разрулить, но для этого существуют различные high-load механизмы. Скорее всего никак не разрулили — из-за мощного потока соединений сервер просто перегружался. В общем он пытался, но съедал на этом всю мощность и отвечал медленно.
Теперь по поводу счёта — счёт в данном случае бесполезен. Скорее всего сервер успевал обрабатывать только handshake. И соединения висели более чем по секунде. Пока сервер не получал хоть немного времени, чтобы обработать старые.
Далее MTU — максимальный размер пакета мало того, что не фиксированная величина (пакет имеет полное право быть меньше, либо равен MTU), так ещё и не подлежащая к использованию в данном контексте. Объясняю: поставьте на удалённой машине веб-сервер, ограничте к нему канал до 1Мбита/секунду и начните качать файл 20 Мбайта. Скачается файл за ~(20*9/1) = 180 секунд (3 минуты). Угадайте, соединение длилось 1 секунду и заново начиналось, или всё прошло в рамках одного соединения? Таким образом соединение длилось 3 минуты. Если с таким же каналом вы ткнётесь качать 10 таких файлов с сервера — каждый файл будет качаться медленнее, но соединения будет держаться. В конечном итоге ограничением является количество одновременных соединений, которое принимает сервер. Вот ровно по такой простой причине нет необходимости считать абстрактные цифры. Потому что просчитывается совсем другая ситуация, а не описанная.
PS сие была последняя попытка донести данную мысль, за сим прощаюсь.
пакет формируется по принципу — заполняем сколько можем, остальное в следующем пакете. пустые данные в пакете не передаются. Таким образом handshake в среднем требует около 300 байт (3 пакета). Далее (не знаю точно протокол http, скорее всего передаётся в 3ем пакете handshake`а) идёт запрос. В запросе передаются различные параметры, урл и ряд заголовков, характеризующих ПО запрашивающее (какие технологии поддерживаются etc). Далее сервер обрабатывая запрос может запросить куки. После получения всех необходимых данных клиенту отдаётся страничка. И тут начинается узкое место — пока данные клиенту не отданы (например картинка 20Мб) соединение не сбрасывается. Если канал перегружен — скорость конкретного соединения проседает, но разорваться оно может только по таймауту молчания (за каждые несколько принятых пакетов клиент отсылает отчёты). Соединения могут висеть больше минуты. Так что по сути — вопрос лишь в том, сколько реальных соединений может выдержать распределяющий сервер LJ (интересно, кстати, сколько их).
Суть — с помощью DDoS`а можно реально перегрузить принимающий сервер и он будет еле отвечать клиентам. И проблема будет не в канале.
Впрочем, я вряд ли сильно ошибусь, если скажу, что причины и свойства гравитационных сил весьма слабо изучены? Если у вас есть какая-нибудь информация по ним — с радостью почитаю :)