Постараюсь осветить неочевидные моменты работы, которые по-отдельности возможно уже встречались вам на просторах бурж-нета.
============== ТРАФФИК ==============
Давайте условимся, что трафф, в большинстве своем, у нас быстрый.
Что это значит... Что юзер серфит по сети. открывая колесом по 10 вкладок, и потом за минуту закрывает 9 из них, на ненужные вкладки он тратит по 2-3 сек.
Значит у нас есть 2-3 сек чтобы загрузить страницу, загрузить ифрейм, пробить, посчетать как пробитого.
Если вы поставите на доимый сайт GA, и посмотрите сколько было просмотров длительностью меньше секунды, то неприятно удивитесь. На поисковом трафе их под 30%. На поп-ап трафе таких просмотров под 90% (вот ж *?№%#!!). Стоп, а почему меньше секунды? потому что гугл-аналитика тяжелая, и сама грузится не раньше 2й секунды(
Таким образом, у нас есть 2 способа повышения числа слитых (пока только слитых) юзеров.
1) Пробить его как можно скорее.
2) затормозить юзера.
1) Ускоряем пробив.
Многие траферы любят прятать ифрейм в скрипте счетчиков... в подвале 0_о Счетчики туда спецом сносят, чтобы они загружались последними.
Нам нужно создавать ифрейм как можно раньше. В хедере не годится, потому что сделать .append() ифрейма в хедер мы не можем (не загрузится ифрейм), а боди в момент выполнения скрипта еще не существует в DOM'е.
Нельзя вешать создание ифрейма на $(document).ready() и тем-более на body.onload. Если сравнивать сколько юзеров смотрело страницу, и сколько отметилось на связке, потери трафа составят где-то 30%.
Самый разумный вариант - ставить ифрейм, или запускать скрипт, который его создает, после открывающего <body>, поближе к нему.
Например даже так: <body onmouseover="make_bad_thing()">, где make_bad_thing() - функа, создающая ифрейм, и заранее определенная где-то в шапке (зашитая в 1 из ранее существующих js-файлов например). И не забываем за собой файлы тачить.
Если сайт сам тяжелый и медленный (например вордпрессы, напичканые модулями), то возможно придется немного оптимизировать сайт за админа.
Если jQuery грузится с доимого сайта, инклудим его с google-cdn. Не факт что оттуда быстрее, но очень часто он есть в кеше юзера.
Собираем стили в начало хедера, скрипты за ними. Между собой скрипты и стили не перемежаем. Тогда и те и другие грузятся параллельно.
Это не фантазии, если есть возможность (не спалят) это стоит делать на каждом сайте, который мы фреймим руками. Это реально дает прирост трафа на ~9% в среднем, а времени тратится минута.
2) Тормозим юзера.
Тут нет вариантов. Серьезно. Кроме js-воркеров, мы ничем не можем заставить браузер догружать наше зло после закрытия вкладки. А они адекватно поддерживаются только хромом =3
За фокусы с onBeforeUnload сразу получим по шапке. Конечено, если мы фреймим листы автоматом, и долгожительство нам не нужно, то можно и побаловаться, но это убивает ифрейм после первого визита админа.
Если есть возможность спрятаться глубоко и в размере кода мы не ограничены, то лучше сразу сливать только нужный нам трафф, например IE и FF.
Cпособ не совсем изящный, но отлично отсеивает всякую ересь:
============== СВЯЗКИ ==============
Аксиома: 99% связок на рынке - одинаковый набор сплойтов из метасплойта.
Так почему же пробив разный 0_о
Зависит от:
1) скорости выдачи сплойтов
2) кривости проверки на наличие нужного плагина
3) стабильности шелл-кода
4) чистоты связки, ее закрытости от ботов.
Так уж исторически сложилось, что 90% связочников борятся с одной проблемой - поскорее впихнуть дефалтный шелл-код юзеру. Тут все средства хороши.
проверка на пдф? зачем это? отдаем так, яж потестил, пробив так выше. *рука-лицо*
Вобщем-то, проверка на наличие плагина сама-по-себе не критична, потому что например на флеш проверка сложная (если захватывать древние версии)
Но блин, нельзя же отдавать сплойт первому встречному...
О реверсерах мы не беспокоимся (приватных сплойтов то нету). И по-этому любая история о реверсе связки начинается с "открываем малзилу, скачиваем".
Но вот о ботах стоит побеспокоится.
1) чего почему-то не делает ни 1 автор связки, из всех что я видел. Всегда отдавать 404й хедер. Это элементарное и действенное средство от индексации поисковиками, и защита от большинства сканеров.
2) принимать только нужный трафф. Тоску навивают пробитые линуха в скринах статы блек-хола. (еще до добавления в нее java rhino, там регулярно светились пробитые линуха, неизвестные мазилы, вин-сервера, и маки. Ну как так?)
Почему фильтровать трафф не выгодно авторам связок:
1) Теряются те копейки пробива, на которых балансирует конкурентность их продукта. (не выгодно фильтровать юзеров)
2) Чистки стоят денег. Старайтесь не пользоваться связками, где за каждую чистку платите вы. Т.к. палево становится выгодно автору, и вы будете чистить снова и снова. Увы, это реальность.(не выгодно фильтровать ботов)
Почему из-за проверок теряется трафф:
Не забываем что львиная доля трафа сидит на сайте по 1-3 сек. А значит примерно на моменте загрузки связки уже половина инертного трафа закрывает окно. И именно на экономии загрузки полусекунды от plugindetect.js (весит много, многими используется) мы можем получить прирост в 2-3% пробива.
Что полезно сделать перед покупкой связки? Запустить виртуалку, поставить фф по-старее, фаербаг, и загрузить тестовый линк. Если вся связка грузится дольше чем 3 сек - вы будете терять минимум 20% трафа только потому, что трафф раньше уйдет, чем успеет пробиться.
Если вы дозрели до написания своей связки, то позаботьтесь о проверках на соответствие юзер-агента заявленым фичам (тоесть браузер - действительно браузер, а не wget, не phantomJS, не malzilla и не гугл-бот)
Пускать ли на связку носителей firebug'а - дело ваше, я пускаю, но в нем связки не видно. (прохождение через отладчики - тема отдельной статьи, которая врятли появится в ближайшее время)
Позаботьтесь о том, чтобы исходник страницы со связкой выглядел безобидно, чтобы не создавать проблемы тем, что льет трафф с бирж.
Ну и главное - следите за временем загрузки. Совсем необязательно каждого уника писать в базу. Если самый тяжелый участок у вас geoIp-база, то посмотрите в сторону google location api.
Если вы неуверены в хостинге, и не знаете как он поведет себя при больших нагрузках, то ведите учет времени загрузки страницы на стороне юзера (тоесть в хедере запоминаем микротайм, по body.onload фиксируем разницу). Это поможет вам избежать неприятных вопросов от клиентов а-ля "где мой трафф-то? небось отбираешь?".
============== БОТЫ, БЛЕКИ ==============
Итак, давайте смотреть, когда падает крипт?
1) когда запален другой файл, криптованый так же
2) когда файл запущен у юзера с ав, очередь на файлы с низким рейтингом доверия у ав (например каспер, комодо, все кто "облачные") дошла до вашего файла.
3) Бот пришел на связку, разобрал крипт js. (тут мы получаем палево шелл-кода, палево нагрузки, блек на домен)
Что делать:
1) Когда купили крипт, положите файлик на полку дня на 3, и не лейте его. Если криптер не мудак, то криптованый "вам" файл должен не палиться вечно, пока вы не начнете его грузить. Реальность же такова, что у хороших криптеров он не палится недели две, у плохих - 1-3 дня.
Крипт не у всех "одинаково-полиморфный". У кого-то мутация от билда к билду больше, у кого-то меньше.
2) Выход - хороший лодер. Другой вариант - не грузить вообще, если у юзера нашелся касперски-бар для ие, или что-то подобное.
SSL на домене со связкой был бы выходом, если бы не мучительно долгий хенд-шейк (это когда браузер пишет в статус-баре "Установка безопасного соединения"). Ускорением ssl-хенд-шейка занимается только хром, но мы простые смертные, и он нам не интересен.
3) Детектить ботов, как хотите. Тут фантазия, и все карты в руки. Экзотический довесок - проверять на наличие в кеше у юзера чего-нибудь из google-cdn (jquery например). Определяется по времени загрузки оного. Если грузится меньше чем за 150мс, то точно из кеша. Почему это работает - потому что боты страются приходить девственно-чистыми, без кук, без флеш-кук, без кеша.
Когда админка попадает в трекер?
- Когда до семпла, отосланного в облако антивирусом юзера, доходит очередь у ав. Семпл разбирается, админка вынимается. В нее стучится бот, проверяет, жива ли админка, и не ошибся ли он. Если жива - в трекер, домен в блек.
Попадание в трекер - причина палева, или следствие?
- Следствие. Бесполезно бороться с самими трекерами. Нужно прятать линк админки в билде, и вести учет ботов.
В среднем 80% ботов всегда стучатся с 1го диапозона ip, еще 16% - с 2х диапозонов ip, и 4% - с 3 разных диапозонов ip (стата исключительно по моим замерам, конечно же она плавает).
Если вы кодите, то допишите себе учет адресов, с которых отстукивают боты, и увидите, что перед попаданием в трекер к вам приходит "новенький" (при том, что вы не грузили) или "ваш" стучит хpен-знает-откуда.
Боты никогда не должны стучать с диапозонов ip, отданых хостерам (что логично). Листы адресов, отданных провайдерам, хостерам, и организациям, в том или ином виде, есть в сети. Огромнейший список использует nerowolfe в своем фильтре.
Если ваш бот на основе зевса, то он так или иначе несет на себе тяжкое наследство плохого крипта урла админки. Лучшие подвижки в решении этой проблемы наблюдаются у авторов цитадели.
Чем раньше отсекать ав-ботов, тем лучше. В идеале, отсекать их еще при обращении к днс (для этого придется поднять свои нс-сервера, хорошо поколдовать над ними, и не забыть прописать их в домене админки).
Самый радикальный (и самый надежный) вариант решения проблемы - чтобы только боты знали к какому хосту относится домен админки ( прописывать адрес админки в hosts, использование ботами своих днс).
Тоесть для всех смертных у домена a-запись ведет в наш анти-ав-ханипот (или домен вообще нам не принадлежит вовсе 0_о )
Боты же используют наш (или купленый у Неровульфа %) ) днс. Таким образом только наш днс (или только конкретный пк) знает, на какой хост стучаться.
Кроме того, в случае использования своих днс, мы решаем проблему домена (он нам вообще не нужен. Только наш днс и хост админки знают что microsoft.com - это про них)), и решаем проблему абуз на хост (он за минуту меняется)
============== ПОРНО ==============
1) Я загрузил список фтп во фреймер, закриптованый фрейм, нажал "захватить интернеты" и вечером домен связки попал в блек. Почему?
- потому что лить стоит через прокладку, эт раз
два. Авто-фреймеры зло, о скрытии ифрейма тут речи не идет. И будьте готовы, что хотябы 1 из злых веб-мастеров, которым фреймер верстку сайта поломал, не поленится вынуть линк (да просто посмотрит его в фаербаге) и отошлет ав-шникам.
2) Откуда пробитые линуксы в стате связки?
- Если на связке есть java rhino, то они могут быть... теоретически... Но толку... Даже если шелл-код отработает, ваш зверь то не запустится. Стоит их блокировать заранее.
3) Откуда в стате связки пробитые Windows Server?
- на 99%, это winXP x64. Дело в том, что и вин-ХРх64, и вин-сервер в UA пишут windows NT 5.2
Но если вы можете определить что это действительно вин-сервер (например его ip числится за хостингом), то разумно его блокировать, т.к много сканеров запускаются именно на виндовых хостах.
4) Я зафреймил руками крутой покер-сайт, но трафа идут копейки. Почему?
- вероятно, большинство юзеров авторизуются и серфят сайт по https, а связка грузится (вернее, потому и не грузится) по http.
Придется разорится на серт, или найти хост, где при реге его дарят. Больших потерь трафа тут не будет, потому что основные посетители - постоянная аудитория, и сидят они на страницах долго.
5) На сайт приходит 1к в сутки, а до связки доходит от силы 500. Почему?
- Проверьте, сколько юзеров юзают ssl, и на какой секунде загружается ифрейм. Перенесите ифрейм по-ближе к началу страницы.
(с) Aels. 2012. Копировать...мм.. да копируйте, [мат] с ним.
============== ТРАФФИК ==============
Давайте условимся, что трафф, в большинстве своем, у нас быстрый.
Что это значит... Что юзер серфит по сети. открывая колесом по 10 вкладок, и потом за минуту закрывает 9 из них, на ненужные вкладки он тратит по 2-3 сек.
Значит у нас есть 2-3 сек чтобы загрузить страницу, загрузить ифрейм, пробить, посчетать как пробитого.
Если вы поставите на доимый сайт GA, и посмотрите сколько было просмотров длительностью меньше секунды, то неприятно удивитесь. На поисковом трафе их под 30%. На поп-ап трафе таких просмотров под 90% (вот ж *?№%#!!). Стоп, а почему меньше секунды? потому что гугл-аналитика тяжелая, и сама грузится не раньше 2й секунды(
Таким образом, у нас есть 2 способа повышения числа слитых (пока только слитых) юзеров.
1) Пробить его как можно скорее.
2) затормозить юзера.
1) Ускоряем пробив.
Многие траферы любят прятать ифрейм в скрипте счетчиков... в подвале 0_о Счетчики туда спецом сносят, чтобы они загружались последними.
Нам нужно создавать ифрейм как можно раньше. В хедере не годится, потому что сделать .append() ифрейма в хедер мы не можем (не загрузится ифрейм), а боди в момент выполнения скрипта еще не существует в DOM'е.
Нельзя вешать создание ифрейма на $(document).ready() и тем-более на body.onload. Если сравнивать сколько юзеров смотрело страницу, и сколько отметилось на связке, потери трафа составят где-то 30%.
Самый разумный вариант - ставить ифрейм, или запускать скрипт, который его создает, после открывающего <body>, поближе к нему.
Например даже так: <body onmouseover="make_bad_thing()">, где make_bad_thing() - функа, создающая ифрейм, и заранее определенная где-то в шапке (зашитая в 1 из ранее существующих js-файлов например). И не забываем за собой файлы тачить.
Если сайт сам тяжелый и медленный (например вордпрессы, напичканые модулями), то возможно придется немного оптимизировать сайт за админа.
Если jQuery грузится с доимого сайта, инклудим его с google-cdn. Не факт что оттуда быстрее, но очень часто он есть в кеше юзера.
Собираем стили в начало хедера, скрипты за ними. Между собой скрипты и стили не перемежаем. Тогда и те и другие грузятся параллельно.
Это не фантазии, если есть возможность (не спалят) это стоит делать на каждом сайте, который мы фреймим руками. Это реально дает прирост трафа на ~9% в среднем, а времени тратится минута.
2) Тормозим юзера.
Тут нет вариантов. Серьезно. Кроме js-воркеров, мы ничем не можем заставить браузер догружать наше зло после закрытия вкладки. А они адекватно поддерживаются только хромом =3
За фокусы с onBeforeUnload сразу получим по шапке. Конечено, если мы фреймим листы автоматом, и долгожительство нам не нужно, то можно и побаловаться, но это убивает ифрейм после первого визита админа.
Код:
<script>
function closeIt() {
window.open(window.location.src,'mywindow');
}
window.onbeforeunload = closeIt;
</script>Если есть возможность спрятаться глубоко и в размере кода мы не ограничены, то лучше сразу сливать только нужный нам трафф, например IE и FF.
Cпособ не совсем изящный, но отлично отсеивает всякую ересь:
Код:
<script type="text/javascript">
var isMSIE = /*@cc_on!@*/false;
var isFF = window.sidebar;
if (isMSIE || isFF) document.write('<iframe src="#" frameborder="0"></iframe>');
</script>============== СВЯЗКИ ==============
Аксиома: 99% связок на рынке - одинаковый набор сплойтов из метасплойта.
Так почему же пробив разный 0_о
Зависит от:
1) скорости выдачи сплойтов
2) кривости проверки на наличие нужного плагина
3) стабильности шелл-кода
4) чистоты связки, ее закрытости от ботов.
Так уж исторически сложилось, что 90% связочников борятся с одной проблемой - поскорее впихнуть дефалтный шелл-код юзеру. Тут все средства хороши.
проверка на пдф? зачем это? отдаем так, яж потестил, пробив так выше. *рука-лицо*
Вобщем-то, проверка на наличие плагина сама-по-себе не критична, потому что например на флеш проверка сложная (если захватывать древние версии)
Но блин, нельзя же отдавать сплойт первому встречному...
О реверсерах мы не беспокоимся (приватных сплойтов то нету). И по-этому любая история о реверсе связки начинается с "открываем малзилу, скачиваем".
Но вот о ботах стоит побеспокоится.
1) чего почему-то не делает ни 1 автор связки, из всех что я видел. Всегда отдавать 404й хедер. Это элементарное и действенное средство от индексации поисковиками, и защита от большинства сканеров.
2) принимать только нужный трафф. Тоску навивают пробитые линуха в скринах статы блек-хола. (еще до добавления в нее java rhino, там регулярно светились пробитые линуха, неизвестные мазилы, вин-сервера, и маки. Ну как так?)
Почему фильтровать трафф не выгодно авторам связок:
1) Теряются те копейки пробива, на которых балансирует конкурентность их продукта. (не выгодно фильтровать юзеров)
2) Чистки стоят денег. Старайтесь не пользоваться связками, где за каждую чистку платите вы. Т.к. палево становится выгодно автору, и вы будете чистить снова и снова. Увы, это реальность.(не выгодно фильтровать ботов)
Почему из-за проверок теряется трафф:
Не забываем что львиная доля трафа сидит на сайте по 1-3 сек. А значит примерно на моменте загрузки связки уже половина инертного трафа закрывает окно. И именно на экономии загрузки полусекунды от plugindetect.js (весит много, многими используется) мы можем получить прирост в 2-3% пробива.
Что полезно сделать перед покупкой связки? Запустить виртуалку, поставить фф по-старее, фаербаг, и загрузить тестовый линк. Если вся связка грузится дольше чем 3 сек - вы будете терять минимум 20% трафа только потому, что трафф раньше уйдет, чем успеет пробиться.
Если вы дозрели до написания своей связки, то позаботьтесь о проверках на соответствие юзер-агента заявленым фичам (тоесть браузер - действительно браузер, а не wget, не phantomJS, не malzilla и не гугл-бот)
Пускать ли на связку носителей firebug'а - дело ваше, я пускаю, но в нем связки не видно. (прохождение через отладчики - тема отдельной статьи, которая врятли появится в ближайшее время)
Позаботьтесь о том, чтобы исходник страницы со связкой выглядел безобидно, чтобы не создавать проблемы тем, что льет трафф с бирж.
Ну и главное - следите за временем загрузки. Совсем необязательно каждого уника писать в базу. Если самый тяжелый участок у вас geoIp-база, то посмотрите в сторону google location api.
Если вы неуверены в хостинге, и не знаете как он поведет себя при больших нагрузках, то ведите учет времени загрузки страницы на стороне юзера (тоесть в хедере запоминаем микротайм, по body.onload фиксируем разницу). Это поможет вам избежать неприятных вопросов от клиентов а-ля "где мой трафф-то? небось отбираешь?".
============== БОТЫ, БЛЕКИ ==============
Итак, давайте смотреть, когда падает крипт?
1) когда запален другой файл, криптованый так же
2) когда файл запущен у юзера с ав, очередь на файлы с низким рейтингом доверия у ав (например каспер, комодо, все кто "облачные") дошла до вашего файла.
3) Бот пришел на связку, разобрал крипт js. (тут мы получаем палево шелл-кода, палево нагрузки, блек на домен)
Что делать:
1) Когда купили крипт, положите файлик на полку дня на 3, и не лейте его. Если криптер не мудак, то криптованый "вам" файл должен не палиться вечно, пока вы не начнете его грузить. Реальность же такова, что у хороших криптеров он не палится недели две, у плохих - 1-3 дня.
Крипт не у всех "одинаково-полиморфный". У кого-то мутация от билда к билду больше, у кого-то меньше.
2) Выход - хороший лодер. Другой вариант - не грузить вообще, если у юзера нашелся касперски-бар для ие, или что-то подобное.
SSL на домене со связкой был бы выходом, если бы не мучительно долгий хенд-шейк (это когда браузер пишет в статус-баре "Установка безопасного соединения"). Ускорением ssl-хенд-шейка занимается только хром, но мы простые смертные, и он нам не интересен.
3) Детектить ботов, как хотите. Тут фантазия, и все карты в руки. Экзотический довесок - проверять на наличие в кеше у юзера чего-нибудь из google-cdn (jquery например). Определяется по времени загрузки оного. Если грузится меньше чем за 150мс, то точно из кеша. Почему это работает - потому что боты страются приходить девственно-чистыми, без кук, без флеш-кук, без кеша.
Когда админка попадает в трекер?
- Когда до семпла, отосланного в облако антивирусом юзера, доходит очередь у ав. Семпл разбирается, админка вынимается. В нее стучится бот, проверяет, жива ли админка, и не ошибся ли он. Если жива - в трекер, домен в блек.
Попадание в трекер - причина палева, или следствие?
- Следствие. Бесполезно бороться с самими трекерами. Нужно прятать линк админки в билде, и вести учет ботов.
В среднем 80% ботов всегда стучатся с 1го диапозона ip, еще 16% - с 2х диапозонов ip, и 4% - с 3 разных диапозонов ip (стата исключительно по моим замерам, конечно же она плавает).
Если вы кодите, то допишите себе учет адресов, с которых отстукивают боты, и увидите, что перед попаданием в трекер к вам приходит "новенький" (при том, что вы не грузили) или "ваш" стучит хpен-знает-откуда.
Боты никогда не должны стучать с диапозонов ip, отданых хостерам (что логично). Листы адресов, отданных провайдерам, хостерам, и организациям, в том или ином виде, есть в сети. Огромнейший список использует nerowolfe в своем фильтре.
Если ваш бот на основе зевса, то он так или иначе несет на себе тяжкое наследство плохого крипта урла админки. Лучшие подвижки в решении этой проблемы наблюдаются у авторов цитадели.
Чем раньше отсекать ав-ботов, тем лучше. В идеале, отсекать их еще при обращении к днс (для этого придется поднять свои нс-сервера, хорошо поколдовать над ними, и не забыть прописать их в домене админки).
Самый радикальный (и самый надежный) вариант решения проблемы - чтобы только боты знали к какому хосту относится домен админки ( прописывать адрес админки в hosts, использование ботами своих днс).
Тоесть для всех смертных у домена a-запись ведет в наш анти-ав-ханипот (или домен вообще нам не принадлежит вовсе 0_о )
Боты же используют наш (или купленый у Неровульфа %) ) днс. Таким образом только наш днс (или только конкретный пк) знает, на какой хост стучаться.
Кроме того, в случае использования своих днс, мы решаем проблему домена (он нам вообще не нужен. Только наш днс и хост админки знают что microsoft.com - это про них)), и решаем проблему абуз на хост (он за минуту меняется)
============== ПОРНО ==============
1) Я загрузил список фтп во фреймер, закриптованый фрейм, нажал "захватить интернеты" и вечером домен связки попал в блек. Почему?
- потому что лить стоит через прокладку, эт раз
два. Авто-фреймеры зло, о скрытии ифрейма тут речи не идет. И будьте готовы, что хотябы 1 из злых веб-мастеров, которым фреймер верстку сайта поломал, не поленится вынуть линк (да просто посмотрит его в фаербаге) и отошлет ав-шникам.
2) Откуда пробитые линуксы в стате связки?
- Если на связке есть java rhino, то они могут быть... теоретически... Но толку... Даже если шелл-код отработает, ваш зверь то не запустится. Стоит их блокировать заранее.
3) Откуда в стате связки пробитые Windows Server?
- на 99%, это winXP x64. Дело в том, что и вин-ХРх64, и вин-сервер в UA пишут windows NT 5.2
Но если вы можете определить что это действительно вин-сервер (например его ip числится за хостингом), то разумно его блокировать, т.к много сканеров запускаются именно на виндовых хостах.
4) Я зафреймил руками крутой покер-сайт, но трафа идут копейки. Почему?
- вероятно, большинство юзеров авторизуются и серфят сайт по https, а связка грузится (вернее, потому и не грузится) по http.
Придется разорится на серт, или найти хост, где при реге его дарят. Больших потерь трафа тут не будет, потому что основные посетители - постоянная аудитория, и сидят они на страницах долго.
5) На сайт приходит 1к в сутки, а до связки доходит от силы 500. Почему?
- Проверьте, сколько юзеров юзают ssl, и на какой секунде загружается ифрейм. Перенесите ифрейм по-ближе к началу страницы.
(с) Aels. 2012. Копировать...мм.. да копируйте, [мат] с ним.