FBScanner и Firebird 3.0
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
FBScanner и Firebird 3.0
ЕМНИП, в FB 3.0 то ли обещают то ли уже сделали шифрование сетевого траффика. А FBScanner готов к такому повороту событий?
Re: FBScanner и Firebird 3.0
Уже сделалиDimitry Sibiryakov писал(а):в FB 3.0 то ли обещают то ли уже сделали шифрование сетевого траффика
Re: FBScanner и Firebird 3.0
И да и нет.
ДА - потомучто делаю свой плагин и перехватом траффика не будет смысла заниматься, плагин входит в поставку FBScanner-a.
а нет - потомучто если траффик зашифрован - расшифровать его будет как минимум сложно.
Впрочем, в IB2009 тоже обещано было шифрование траффика.
Но то ли оно включается опционально, и по-умолчанию выключено, то ли еще чего...
FBScanner-у не потребовалось никаких доработок после IB7.0. Все работает по-прежнему и в IB XE.
Разве что авторизация проходит в два раундтрипа.
Перехват и расшифровка TCP-траффика это от бедности. Неужто я стал бы делать такой хак, если бы был штатный механизм трейса в 2005г.
Я даже создавал тему на gmane "хочется серверного API".
ДА - потомучто делаю свой плагин и перехватом траффика не будет смысла заниматься, плагин входит в поставку FBScanner-a.
а нет - потомучто если траффик зашифрован - расшифровать его будет как минимум сложно.
Впрочем, в IB2009 тоже обещано было шифрование траффика.
Но то ли оно включается опционально, и по-умолчанию выключено, то ли еще чего...
FBScanner-у не потребовалось никаких доработок после IB7.0. Все работает по-прежнему и в IB XE.
Разве что авторизация проходит в два раундтрипа.
Перехват и расшифровка TCP-траффика это от бедности. Неужто я стал бы делать такой хак, если бы был штатный механизм трейса в 2005г.
Я даже создавал тему на gmane "хочется серверного API".
Re: FBScanner и Firebird 3.0
разумеется, в IB с версии 2009 шифрование трафика (OTW) включается только явно, и идет оно через SSL. И без этого шифровать трафик можно было чем угодно, в т.ч. zebedee.Но то ли оно включается опционально, и по-умолчанию выключено, то ли еще чего...
http://www.ibase.ru/devinfo/zebedee.htm
а про OTW в InterBase - тут: http://interbase.blogspot.ru/2012/05/interbase.html
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: FBScanner и Firebird 3.0
Может, стоит закинуть в трекер пожелание, чтобы пакет шифровался не полностью, оставив открытой часть, нужную для работы прокси: операцию и установку доп.соединения для эвентов?..
Re: FBScanner и Firebird 3.0
ты все думаешь, как его приспособить к балансировке нагрузки?
... Так уж устроен протокол, что одной только операции будет мало:
Вариант 1.
Как минимум, надо чтобы передавалась длина пакета. Сейчас смещение к началу следующего логического пакета, (в начале которого стоит код операции) надо довольно долго и мучительно вычислять. Особенно op_fetch.
При том, что содержимое самого fetch пакета совершенно неинтересно, и не нужно FBScanner-у. Но раз уже такое вычисление происходит, FBScanner подсчитывает кол-во прошедших строк. Которое нужно только для "красоты". Я уж молчу о том, что после того как FBScanner стал производить полную расшифровку протокола, нагрузка на CPU увеличилась на порядок.
(полная расшифровка появилась в версии FBScanner 2.5, без этого невозможно было понять, что происходит в 11ом протоколе FB2.1 и старше)
Но даже если так, то знание операции мало: стейтментов (или тр-ций) может быть несколько. Какому именно сейчас делается prepare - важно знать.
Вариант 2.
Интересно, а как сейчас происходит шифрация протокола? Полностью пакуется логический пакет?
Если да - то зачем? По сути, шифровать протокол нет никакого смысла.
Достаточно шифровать данные:
а) данные внутри fetch (каждый столбец - отдельно)
б) внутри передачи параметров (алгоритм тот же самый, как с fetch)
в) блобы
г) под вопросом - текст SQL запроса.
Если пойти по этому варианту, доработки в FBScanner будут ненужны
))
Пакеты не изменятся, а сами данные по барабану, в общем-то... правда, логирование всеравно накроется.
... Так уж устроен протокол, что одной только операции будет мало:
Вариант 1.
Как минимум, надо чтобы передавалась длина пакета. Сейчас смещение к началу следующего логического пакета, (в начале которого стоит код операции) надо довольно долго и мучительно вычислять. Особенно op_fetch.
При том, что содержимое самого fetch пакета совершенно неинтересно, и не нужно FBScanner-у. Но раз уже такое вычисление происходит, FBScanner подсчитывает кол-во прошедших строк. Которое нужно только для "красоты". Я уж молчу о том, что после того как FBScanner стал производить полную расшифровку протокола, нагрузка на CPU увеличилась на порядок.
(полная расшифровка появилась в версии FBScanner 2.5, без этого невозможно было понять, что происходит в 11ом протоколе FB2.1 и старше)
Но даже если так, то знание операции мало: стейтментов (или тр-ций) может быть несколько. Какому именно сейчас делается prepare - важно знать.
Вариант 2.
Интересно, а как сейчас происходит шифрация протокола? Полностью пакуется логический пакет?
Если да - то зачем? По сути, шифровать протокол нет никакого смысла.
Достаточно шифровать данные:
а) данные внутри fetch (каждый столбец - отдельно)
б) внутри передачи параметров (алгоритм тот же самый, как с fetch)
в) блобы
г) под вопросом - текст SQL запроса.
Если пойти по этому варианту, доработки в FBScanner будут ненужны
))Пакеты не изменятся, а сами данные по барабану, в общем-то... правда, логирование всеравно накроется.
-
Dimitry Sibiryakov
- Заслуженный разработчик
- Сообщения: 1436
- Зарегистрирован: 15 сен 2005, 09:05
Re: FBScanner и Firebird 3.0
Скорее прицениваюсь: стоит ли сваять свой или дешевле будет закинуть тикет к Firebird, как говорил ДЕ... У них там внутре тоже уже есть готовый редиректор, так что научить его раскидывать коннекты на несколько хостов в зависимости от количества неотвеченных пакетов не должно быть слишком тяжко...