Версионирование .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, и становится страшно, там добавили совместимости из-за которой много всего развалилось, несмотря на обещанную совместимость.

Подлые порты

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

Собственно, список:

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

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

Какой тип 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 можно настроить как нравится.

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...

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

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

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

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

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

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

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

1. Думайте заранее о том, как вы будете оптимизировать
2. Если необходимо, делайте простую оптимизацию, которую можно улучшить в будущем

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

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

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

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

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

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

Вообще, на работе всё было весьма и весьма неплохо. У нас собралась отличная команда, которая может делать любые безумные вещи, и пусть другие команды нам завидуют!

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

В свободное от работы время приобщаюсь к Github'у и Nuget'у. В феврале сделал небольшую, но очень быструю библиотеку для копирования объектов: DeepCloner, потом разошёлся и сделал одну из самых быстрых (или самую быструю) библиотеку для вычисления CRC32: Crc32.NET. Вообще, началось с того, что мне понадобилась реализация CRC32C, а т.к. автор что-то медленно правил свою (версию для плюсов он уже обновил, а вот .NET никак не может, хотя спустя полгода таки принял мой pull request). Ну и в общем, раз я взялся за CRC32C, то надо было поглядеть на обычный CRC32. На нюгете и гитхабе проекты оказались неушстрыми и полузаброшенными. Пришлось сделать свой.
Ну и в конце-концов, я допилил свой архиватор до рабочего состояния, называется он красиво: Blazer. В прицнипе, нужно его повылизывать и попилить, но в целом там уже достаточно клёвых фич, типа сжатия с шаблоном. Ну и большинство фич сосредоточено в библиотеке, а не в консольном экзешнике.

Ну и ещё научился находить плавающие баги в коде, сидя в гостинице в Москве с ноутбуком. Хотя фактически несколько часов искал их с помощью головы. Оригинальные впечатления.

В общем, желаю всем читающим меня отличного Нового Года, покорения новых профессиональных вершин, а также чистого, гладкого и красивого кода.

Краткий анализ .NET Core/Standard/Framework

Тут в очередной раз разбирался с тем, что в Microsoft нагородили с .NET, пока окончательно не понял, но в целом, чтобы не пересказывать основные статьи про всё это дело, просто сообщу, то что я понял:

• Есть .NET Core, это специальный кроссплатформенный фреймворк
• Есть .NET Framework, это классический .NET, работающий под винду
• Есть .NET Standard, это набор API, который гарантированно будет работать в .NET Core и .NET Framework (ну и всяких ксамаринах)
• Код, изначально написанный на .NET Framework, не будет работать под .NET Core
• Если есть желание писать под .NET Standard, чтобы работало под большим .NET Framework, то лучше не делать так. Ибо работать будет, но плохо.
• Потому что вся магия в том, что API похожее, но разное. 
• Другими словами, версия под .NET Framework будет использовать очень похожий, но отдельный набор API. Если он весь скрыт внутри. то ничего страшного, никто не увидит. Если же вылезает наружу, могут быть неприятные последствия.
• Ещё раз уточню, что если написано, что Standard 1.2=Framework 4.5.1, то это не значит, что код, написанный под 4.5.1 будет работать на уровне 1.2. Это просто значит, что если написать код, под 1.2, то его с помощью бубна можно заставить работать на 4.5.1. При этом набор API в 1.2 особо нигде не расписан, например, там нет криптографии. Странно, но вот так.
• Судя по всему, самая популярная версия .NET Standard — 1.3, что в ней такого особого, пока не разобрался

Т.е. в целом ситуация складывается странная. Если хочется разрабатывать универсальные вещи, то лучше тупо не думать, а разрабатывать под .NET Core, забив на .NET Framework полностью. Потому что поставить .NET Core не сложно, а существущий код под .NET Framework всё равно придётся переделывать, так что, смысла во взрослом фреймворке на мой взгляд немного.

PS: Возможно, после дальнейшего знакомства со всем этим делом, моё мнение изменится, тогда обновлю пост. Но пока есть ощущение ужасной неразберихи и путаницы в API, чего стоит только набор версий фреймворка 4.5, 4.5.1, 4.6, 4.6.1, 4.6.2 — надо долго гуглить, чтобы найти отличия, но при этом для каждого из них, есть своя версия .NET Standard, но, поскольку, скоро будет .NET Standard 2.0, использовать .NET Standard 1.5 и 1.6, не рекомендуется из-за проблем с совместимостью. Ещё раз, стандартная версия фреймворка, сделанная для совместимости, будет несовместима сама с собой. А нам с этим жить...