MCP

пятница, 29 декабря 2017 г.

Итоги моего 2017 года

Решил в этом году повторить пост относительно прошлого, ибо оказалось даже для меня полезным и интересным посмотреть, что было в прошлом и сравнить, что стало (хотя уже было) в этом. Так что, нашёл время (единственный свободный день под конец года оказался, хотя сейчас пытаюсь восстановить угробленные виндой данные с диска в 3Тб), и решил написать, что же произошло технического в этом году.

Получилось так, что я почти забросил этот блог. ибо хочется писать про интересное, а это интересное надо долго и упорно изучать, чтобы пост не получился глупым и ошибочным. А в итоге получается, что занимаюсь или банальщиной, или не сильно углубляюсь, или лезу в такие дебри, что объяснить их не представляется возможным. А вот так, чтобы что-то интересное... На новый год принято давать себе обещания, типа бросить пить, заняться спортом, вести блог... Так вот не буду, ибо не знаю ещё, чем буду заниматься в следующем году...

А в этом активно и вплотную занялся .NET Core под Linux, фактически все новые проекты теперь там и живут, и живут весьма неплохо. На работе кроме всякой мелочи был сделан очень крутой проект. Он. конечно выглядит просто и банально, но внутри там очень всё круто, микросервисно, распредёлённо и кешированно. При этом, пока не замучали новыми фичами, он умудрялся жить на мелких виртуалках, используя по максимуму всё, что они предоставляли. Но в конце-концов, один проект превратился в два, с общей и своей частью, я сдался и развёл проект на 3 сервера и разрешил жрать память (хотя слишком разрешил 16 Гигов, съеденных из-за баги доставили много радости в поиске бага).

В остальном, год был похож на прошлый. Был хакатон, но участвовал я один, в итоге "почётное" третьё место. И ещё не внедрено. Продолжаю пилить на гитхабе свой клонятор, Crc32 (теперь ещё быстрее), и архиватор, который уже помаленьку использую в бою и вижу, что у него есть очень интересные фичи. Также нарисовал свой аналог IPSec под названием AutoTunnel, получилось интересно, но надо бы чуть допилить, ибо склейка фрагментированных UDP пакетов со стороны Windows — это боль.

С нетехнической стороны — год отметился путешествиями: Баку, Минск, Кострома, Мюнхен, Тбилиси, Амстердам, Прага... Посетил кучу мест, получил много впечатлений и не собираюсь останавливаться на достигнутом!

К сожалению, со всей этой беготнёй, забыл про новогоднее настроение, но у меня есть ещё 2 дня его найти, буду упорно стараться. Ну а вам его тоже желаю, надеюсь, что оно у вас уже есть и вы готовитесь к самому весёлому празднику, Новому Году.

С Наступающим!



понедельник, 27 ноября 2017 г.

Ненавистный .NET

Последнее время совсем не пишу в блог, как-то нет подходящих тем, могу только сообщить, что такой ненависти к Microsoft я давно не испытывал. Попытка поработать с .NET Core 2.0 сразу же привела к идиотским ошибкам, типа 2 entry point у приложения. При этом второй генерируется самостоятельно (!), другими словами, у Microsoft новые отличнейшие идеи, как всё должно работать по их мнению, вместо того, чтобы просто сделать рабочий продукт.

Если кончится мат и появятся слова, постараюсь написать что-то более членораздельное. Но, блин, у Microsoft был отличнейший .NET, приложения на котором просто работали... Теперь не так, они могут падать по совершенно различным причинам, а Dll Hell уже перешёл все границы. Ну, как, как можно так портить жизнь разработчикам за их же деньги...

понедельник, 2 октября 2017 г.

Версионирование .NET Core

Когда-то писал про .NET Core и обещал написать больше, но было лениво, так что руки не дошли.

Сейчас просто для понимания бреда, который творится с версионированием краткое описание разных версий. Это может быть полезно, т.к. вышел .NET Core 2.0 и .NET Standard 2.0, и версии слились в экстазе. Но на самом деле они разные, и скоро разъедутся и будут опять портить всем жизнь. Итак, временно забудем про существование 2.0, и вспомним, что есть:


  • Вы собрались писать под .NET Core, соответственно выбираете, какую версию хотите, вы можете выбрать версию 1.0 (на момент написания 1.0.7) или 1.1 (на момент написания 1.1.4), при этом, особой разницы в этом нет. 
  • На самом деле, вы можете выбрать рантайм или сдк Логично, что для разработки нужен SDK, для версии рантайма 1.0.7, сдк имеет версию 1.1.4 (т.е. рантайм разрабатывается и старый и новый одновременно, сдк только новый)
  • После этого, вы можете решить, что использовать, .NET Standard или .NET Core. Для библиотек лучше использовать Standard, у него версии: 1.0,1.1,1.2,1.3,1.4,1.5,1.6, для запускаемых файлов лучше Core, у него версии 1.0 и 1.1
  • Впрочем, вы можете писать библиотеки на Core, а экзешники на Standard, в этом не очень много смысла, но в целом он есть
  • Версии Standard для удобства используют стандартную библиотеку NETStandard.Library, она бывает версий 1.6.0 и 1.6.1
  • В этой библиотеке есть стандартные библиотеки, которые любят называться как большие и иметь версию 4.3.0 (большие имеют версию 4.0.0). Впрочем, иногда бывают и 4.2.0 и 4.1.0, и всякие разные
Т.е. приложение мод .NET Core 1.0 может запускаться в рантайме 1.1.4, иметь зависимость на библиотеку .NET Standard 1.3, которая использует библиотеку NETStandard.Library 1.6.1 и это всё будет замечательно работать! Главное надо понять, что это просто разные версии разных библиотек. 

Сейчас вышел .NET Standard 2.0, и всё стало совсем просто: приложение под .NET Core 2.0 запускается в рантайме 2.0, имеет зависимость на библиотеку .NET Standard 2.0, которая использует библиотеку NETStandard.Library 2.0.0. К сожалению, скоро все эти версии опять разъедутся в разные стороны, и опять будет путаница. Но. надеюсь, вы теперь будете во все оружии.

PS: Сейчас слушаю про version hell в .NET Core 2.0, и становится страшно, там добавили совместимости из-за которой много всего развалилось, несмотря на обещанную совместимость.


суббота, 3 июня 2017 г.

Подлые порты

Я тут настроил логгирование входящих запросов из интернета на мой комп, конечно же, меня периодически (раз в час) сканируют. Решил просто поделиться списком портов, которые интересуют "хакеров".  Зачем? Просто для информации, на какие порты обращать внимание, и на какие порты не стоит вешать ваши сервисы, если они настолько популярны, что их ломают, то и ваши сервисы могут попасть под раздачу или флуд.

Собственно, список:
7
9
13
21
22
23
25
26
37
53
79
80
81
88
106
110
111
113
119
143
144
179
199
389
427
443
444
465
513
514
515
543
544
548
554
587
631
646
873
990
993
995
1025
1026
1027
1028
1029
1110
1433
1720
1723
1755
1900
2000
2001
2049
2121
2717
3000
3128
3306
3389
3986
4899
5000
5009
5051
5060
5101
5190
5357
5432
5631
5666
5800
5900
6000
6001
6646
7070
8000
8008
8009
8080
8081
8443
8888
9100
9999
10000
32768
49152
49153
49154
49155
49156
49157

Это только за сегодняшнее утро, но я не ставил себе целью собрать весь список. Некоторые порты ожидаемые, некоторые красивые, а некоторые очень удивительные, даже интересно, что в них такого особенного.

вторник, 23 мая 2017 г.

Какой тип VPN лучше

Тут разбираюсь с тем, что лучше в качестве протокола VPN подобрать, с учётом того, что с обоих концов стоят похожие железки, соответственно друг с другом их можно подружить любой комбинацией. Соответственно много читал про типы VPN, и решил поделиться тем, что выяснил (не перепечатывая один и тот же текст из вики).

PPTP

Классический протокол, работает везде. На всём что шевелится. Очень быстрый (с ним только IPSec может соперничать при определённых условиях). Но есть один недостаток — дырявый. Стандартный MSCHAPv2 позволяет выяснить пароль, если перехватить сессию. Но, судя по всему, проблема только в случае MITM. Т.е., если не считаете, что ваш трафик перехватывают, то жить вроде бы можно. Есть ещё протоколы вида EAP, но с их поддержкой всё достаточно грустно.
Второй недостаток — использование в качестве транспорта протокола GRE (тоже самое что TCP, UDP или ICMP, только GRE). Иногда режется.
В общем, по общему мнению, использовать небезопасно, но быстр

IPSec

Не совсем VPN, а нечто очень клёвое и могучее, которое может шифровать или один порт между двумя компьютерами, или связывать целые подсети безопасным образом. Очень хорошо поддерживается аппартное шифрование, и сам весь шифрованный, может хоть по сертификатам, хоть по PSK ходить, работает в винде на низком уровне, в общем, чудо а не протокол. Есть только пара жирных минусов: первоначальная настройка может быть весьма муторной (с перебиранием галочек, и чтением логов), неосторожное действие может зарубить железяку (будет считать, что трафик к ней должен идти через IPSec, который не настроен), ну и настройка этого через NAT — могучий квест, для настоящих джедаев.
В общем, по жизни рекомендую связывать удалённые компьютеры с фиксированными IP в безопасную псевдо-локальную сеть. Тут он волшебен. Остальное — на любителя.
Ходит через UDP, EH и ESP протоколы, что очень хорошо для транспорта, но мутновато для фаривола. с NAT'ом добавляется UDP 4500, и куча мути.

L2TP/IPSec

Немного дурацкое название связано с тем, что сам туннель нешифрованный, соответственно поднимается туннель поверх IPSec, что приводит по мнению многих к двойной инкапсуляции и приличному оверхеду. Но т.к. IPSec сам по себе хорош, не так уж и плохо. Живьём попробовать не удалось, уж очень большой квест по настройке. Предпочитаю голый IPSec. В общем, как вы понимаете, мне не очень нравится этот туннель, но если вам кто-то его настроили он работает, то будет весьма безопасный туннель.
Ходит через UDP 1701, EH и ESP протоколы, EH не обязателен.

SSTP

Как программисту, мне очень нравится этот туннель. Ибо это тупой SSL-стрим (по умолчанию на 443-ем порту), в который всё заворачивается. Т.е. с криптографией всё нормально TLS1.2, все плюшки. Проверка сертификатов сервера, возможно клиента. Работает дубово и стабильно. Но один маленький нюанс: хорошо работает только на винде начиная с Висты и более или менее на Микротиках. Под линухом кое-как, под андроидом из коробки ничего нет, ну и в целом не очень распространён.
Тем не менее, если есть возможность его использовать со стороны системы — будет работать. 
Утверждается, что протокол закрытый, поэтому могут быть дыры, но снаружи это чистый SSL-стрим (не отличить от обычного обращения к сайту, кроме объёма данных), так что все правила безопасности соответствуют https.
Ещё один недостаток, кроме ограниченной поддержки — TCP канал для тоннеля. В чём проблема? В плохой сети. Ибо TCP-пакеты могут теряться и запрашиваться повторно. Тут получается ситуация TCP over TCP, что при потере пакетов верхнего уровня приводит к куче проблем нижнего. Т.е. два уровня начинают заниматься попытками перепосылки пакетов, что сильно проваливает скорость. Однако, при хорошей сети — всё отлично.

OpenVPN

Последний вариант, о котором я хочу рассказать, но не самый плохой. Это отдельный OpenSource клиент подо всё что шевелится, который позволяет сделать всё что угодно. Хоть примешаться к существующему SSL-трафику на 443-ем порту сервера. В общем, есть всё. Куча алгоритмов, куча вариантов. Минусов только два: нужно ставить отдельно и слегка мутновато настраивать. Если справитесь, то всё будет хорошо, хотя пользователям придётся писать развёрнутую инструкцию.
Ну и по-возможности, следует настроить его на использование UDP, а не TCP, чтобы не было проблем, аналогичных SSTP. По скорости примерно соответствует SSTP.

Скорость

Всё очень depends, зависит от тонкой настройки, аппаратной поддержки и прочего. Но мои тесты показали, что в целом скорость распределяется следующим образом
  • PPTP — самый быстрый. Очень и очень быстрый
  • L2TP/IPsec — чуть медленнее (протоколы серьёзныее)
  • SSTP — сильно медленнее
  • OpenVPN — примерно соответствует SSTP, но чуть медленнее (проверял только TCP вариант, думаю UDP будет гораздо быстрее)

Итоги

На самом деле, выбор весьма сложен. Старые протколы или сложные или дырявые, но поддерживаются везде и максимально быстро. Новые стараются сделать удобнее, но с поддержкой грустнее. Я пока не выбрал, что лучше, но думаю про SSTP, когда всё хорошо и PPTP, когда плохо с качеством и скоростью, но очень надо. При хорошей подготовке, возможно лучшим будет всё-таки IPSec, ну а хитрый OpenVPN можно настроить как нравится.

среда, 8 марта 2017 г.

Visual Studio 2017 и очередная упоротость от Microsoft

Данный пост навеян статьёй о выходе VS2017, в которой есть такая шикарнейшая фраза:

We’re now encouraging Visual Studio 2015 users to migrate to MSBuild and csproj from project.json. As I stated above, we will not be supporting any of the new .NET Core tools in Visual Studio 2015. We also won’t be updating the Visual Studio 2015 project.json-based tools.
И вот эта фраза меня убило, хотя новости ходили давно, но тут они всё-таки сделали всё "в самом лучшем виде". И я не могу не высказаться по этому поводу.

Дело в том, что я не очень люблю новые технологии в плане использования в продакшене (в пет проджектах — в самый раз!). Дело в том, что их интерфейсы и функционал постоянно меняется, авторы ищут правильные идеи и каждая версия как маленький взрыв.

В результате, часть времени в проекте уходит на миграцию на новую версию, часть на обучение разработчиков как сегодня правильно писать и часть на исправление незамеченных регрессов. В общем, это хорошо так перекликается с одним из моих ранних постов про велосипеды. Я, собственно, до сих пор предпочитаю использовать .NET 4.0: он работает начиная с XP и VS2010, он не мёртвый (апдейты выходят и для него, и свежие .NET улучшают его код, ибо в реальности одно и тоже), да и в новых не так уж и много полезных фич, чтобы переходить на него. Кроме того, никаких проблем с версионированием, которые поехали дальше: 4.5, 4.5.1, 4.5.2, 4.6, 4.6.1, 4.6.2 — без гугла различия и не вспомнишь.

Но тут решили делать всё по-новому и перешли на .NET4.6 и .NET Core, всё-таки у Core есть хорошие плюшки в виде нативной компиляции и гарантированной работы под Linux, да и разрабатывается она давно.

Про сам .NET Core писать не буду, ибо мелочь уже написана, на на ещё один пост не набирается, но вот что понравилось безоговорочно, это файлы project.json, которые очень похожи на package.json, но для Core. Собственно, наконец-то у Microsoft получился вменяемый формат проекта, который можно редактировать ручками не в плане хотфиксов, а прямо-таки изменять поведение проекта. Ну и работать с проектом не только в студии, но хоть в саблайме.

И тут приходит Microsoft и говорит, извините, факир был пьян, мы возвращаем всё назад. При этом новые фичи будут работать только в новой студии, а старые поддерживать мы больше не будем. Т.е. фактически кинули всех владельцев 2015-ой студии, которые работали с проектами на Core. При этом Microsoft всю жизнь тащила обратную совместимость, ибо так правильно и ынтырпрайзно.  Но, судя по всему, в команде .NET царит атмосфера вида: как хочется и как им удобнее. В результате, мало того, что ты летишь в самолёте, у которого по ходу дела меняют крылья на другие, ещё и забирают двигатели с фразой — они отстой, в новых всё лучше, покупайте наших слонов!

Собственно, теперь кроме обновления студий всем связанным участникам необходимо опять переделывать весь тулинг (тестирование, билды, пекеджи), опять изучать косяки всех инструментов, мигрировать проекты. Вот задолбало конкретно. Я хочу писать код, а не бороться с очередными новшествами и изучать очередные инструменты, которые не сделают мою жизнь лучше.

Эээх... как же хорошо было в .NET4.0...

пятница, 24 февраля 2017 г.

Немного про оптимизацию

Есть такая программистская мудрость, что преждевременная оптимизация — это зло, народ верит в эту в целом правильную мысль и пишет код со статусом — когда будет надо, тогда и прооптимизируем.

Идея это логичная, ибо зачем тратить время на оптимизацию того, что ещё три раза перепишется, но есть один нюанс который забывают во всей этой истории, а именно: если вы собираетесь когда-то в будущем, оптимизировать код, то он должен иметь возможность оптимизации. В переводе на русский, когда пишете код, думайте — будет он работать всю жизнь в таком виде, или у него будут проблемы под нагрузкой и с ними что-то надо делать. И если считаете, что надо что-то делать, сразу думайте о том, как это надо будет делать. Заранее. Возможно даже стоит сразу потратить время на некоторую оптимизацию, улучшив её потом, но получить результат сразу и понимание того, можно ли двигаться дальше.

На мой взгляд, основное действие, которое требуется для возможности оптимизации — локализация кода в одном месте и уменьшение точек входа. Меньше точек входа — меньше поверхность оптимизации и всё становится проще.

Давайте приведу пример. Есть у нас список пользователей в системе, и нужен классический CRUD с аццким уклоном в R, ибо пользователи достаются на каждый запрос а меняются всё-таки пореже. Логичный способ улучшить производительность — кеширование. Но чтобы удобно всё кешировалось, работа с пользователями должа быть сосредоточена в каком-нибудь UserManager. И тут сразу вылезает проблема классических приложений, которые, доставая данные, джойнят данные с пользователями (автор, ответственный, владелец). Это просто и удобно, но очень сильно рушит идею кеширования — в нём теряется множество смысла, ибо всё равно идёт запрос в базу.

Т.е. в случае необходимости кешировать пользователей мы сталкиваемся с проблемой: низкая эффективность кеширования без переписывания всего кода (убирание джойнов и прочей работы с пользователями). Но при этом, если мы изначально не включаем кеширование — то приложение будет доставать пачку пользователей на каждый чих и работать не будет в принципе. Такая вот дилемма.

Что с этим делать? Я уже расписал:

  1. Думайте заранее о том, как вы будете оптимизировать
  2. Если необходимо, делайте простую оптимизацию, которую можно улучшить в будущем
Т.е. в нашем случае с пользователями, мы можем держать вытаскивать их из базы и держать в памяти. На каждое изменение пользователя — сбрасывать кеш. В дальнейшем, можем подключить более эффективную инвалидацию, LRU, уменьшить объём данных в памяти, и идти за редко нужными ними в базу. Это потом. Но сейчас у нас мы оставили одну точку входа (мы знаем, что берём пользователей достаточно быстро), и имеем возможность улучшить кеш.

Тоже самое актуально и для оптимизации скорости работы алгоритмов по CPU, IO и прочему: уменьшите количество точек входа, и подумайте, что можно будет сделать, если всё будет плохо до того, как реализуете задачу целиком.

Данный пост был навеян идеями по оптимизации одного из проектов, которые весьма сложные и трудозатратные, просто потому, что в своё время отложили эту задачу со статусом: решим проблему, когда будет актуально. В результате, довели ситуацию до весьма плачевных последствий.