Спасибо за ответ. Интересно, сталкивался ли кто-то с данной ситуацией.
Сами задачи в большинстве понятны (зависит от задачи), доработки обычно обходятся одной итерацией (иногда доработок нет). Обычно доработки возникают в задачах где нет понимания как лучше сделать.
Сергей, спасибо за ответ. Дело в том, что хочу увидеть хоть что-то, но вижу только то, что и было до вызова .append().
Я стал это делать после того, как передавал formData в $.ajax() в виде данных POST, но в результате запрос отправлялся без каких-либо данных. Какая я понял, что дело в том, что в formData пусто.
При попытке вызова formData.getAll() получаю «Uncaught TypeError: formData.getAll is not a function»
Вот состав formData — joxi.ru/p27LxQPtn9ZEA7 (видимо у меня какой-то не такой FormData).
Второе ваше замечание очень интересно и похоже на верный ответ :) Плюс, говорят, страницы слипаются. Это должно еще зависеть и от качества бумаги книги.
Если стопки по 4-5 книг вышиной, то это не проблема. Интересно как хранят в архивах ценные книги. Насколько я бегло смотрел — хранят горизонтально. Хотя я не уверен в этом правиле.
Если так хранят книги только из-за удобства доставания и убирания, тогда понятно. Но такой способом, по моему мнению, с точки зрения хранения книг плох. В больших библиотеках (в т.ч. домашних) часто книги не достаются.
Спасибо. Жирные каналы есть. К ДЦ подходят сотни гигабит. Вопрос в том, чем можно фильтровать этот трафик, чтобы резать паразитный. Понятно, что атак много и сейчас есть достаточно сложные виды атак, но пока страдаем от довольно простых.
Фильтровать никакой трафик нельзя потому, что это не наш трафик, а трафик в сторону клиента, который арендовал VDS. По этой же причине, кого-то блокировать нельзя для входящих пакетов, тем более я просто привел пример пакета, ip-src могут быть совершенно разные.
> Я пока не понял, к каким проблемам на физическом сервере приводит фильтрация трафика при помощи ebtables.
Проблема, что в том что на сервере могут быть сотни VDS, соответственно примерно столько же IP в мосте, проверять трафик на наличие ip-dst присвоен ли мак, это изврат. По поводу выключения и включения VDS, то их выключает панель управления и, впринцнипе, невозможно что-то встраивать в ее код, если только костылями, тем более сам пользователь может выключать и включать VDS-ки без панели, а из своей OS. Потому вариант писать скрипты по большому счету изврат и хотелось бы это делать в последнюю очередь, я надеюсь, что есть другое решение, которое полностью отключает трафик на выключенный IP, причем автоматически.
С мониторингом сервера все в порядке, просто пока зайдешь на сервер и закроешь проблемный IP уже лишний трафик насыпется на другие VDS, приводя к нагрузке всего сервера.
Какой тип флуда ответить невозможно, поскольку нет доступа к активному оборудованию и снять дамп возможно только на физическом сервере. Вопрос, вприцнипе, был задан для того чтобы узнать возможны ли варианты блокировки именно на сетевом оборудовании, но сетевые инженеры Дата-центра говорят, что установили настройку для влана и свичей в ДЦ "mac-address-table aging-time = 14400"
Виртуализация тоже, по большому счету не причем, используется стандартных мост в linux(bridge) с утилитой brctl.
Вот когда идет флуд, например, такой, как я показывал и отключает пользователь серевер, то ровно такие же пакеты видны на всех виртуальных серверах. В примере, имелось ввиду, что 109.XX.XX.XX - это IP, 53 это порт, но опять же значения это не имеет, флуд может быть разный, главное, что если IP недоступен, то трафик идет на все виртуальные интерфейсы. При этом, если с другого сервера во влане сделать arping, то информации о мак-адресе не будет. То есть на самом мосту уже нет этой информации и пакеты идут от активного оборудования провайдера.
Ситуацию спасает просьба о блокировке атакуемого IP на активном оборудовании, либо можно при помощи ebtables запретить форвардинг пакетов на атакуемый ip-адрес, тогда трафик будет идти просто на основной интерфейс физического сервера, не затрагивая виртуальные сервера. Оба варианта не являются выходом поскольку требуют постоянного присутствия как сетевых инженеров в ДЦ, так и приносят проблемы на физическом сервере, потому и хотелось бы узнать возможно ли в автоматическом режиме со стороны сетевого оборудования избегать таких проблем.
Сами задачи в большинстве понятны (зависит от задачи), доработки обычно обходятся одной итерацией (иногда доработок нет). Обычно доработки возникают в задачах где нет понимания как лучше сделать.