През 2010 г. компанията имаше 50 сървъра и прост мрежов модел: бекенд, фронтенд и защитна стена. Броят на сървърите нарасна, моделът стана по-сложен: етапи, изолирани VLAN с ACL, след това VPN с VRF, VLAN с ACL на L2, VRF с ACL на L3. Главата се върти? По-късно ще бъде по-забавно.
Когато имаше 16 000 сървъра, стана невъзможно да се работи без сълзи с толкова много разнородни сегменти. Така че измислихме друго решение. Взехме стека на Netfilter, добавихме Consul към него като източник на данни и получихме бърза разпределена защитна стена. Те замениха ACL на рутери и ги използваха като външна и вътрешна защитна стена. За динамично управление на инструмента разработихме системата BEFW, която се използва навсякъде: от управление на достъпа на потребителите до продуктовата мрежа до изолиране на мрежови сегменти един от друг.
Той ще ви каже как работи всичко и защо трябва да разгледате по-отблизо тази система. Иван Агарков () е ръководител на групата за инфраструктурна сигурност на отдела за поддръжка в центъра за развитие на компанията в Минск. Иван е фен на SELinux, обича Perl и пише код. Като ръководител на групата за информационна сигурност, той редовно работи с регистрационни файлове, архивиране и R&D, за да защити Wargaming от хакери и да осигури работата на всички сървъри за игри в компанията.
Историческа справка
Преди да ви кажа как го направихме, ще ви кажа как стигнахме до това на първо място и защо беше необходимо. За да направите това, нека се върнем 9 години назад: 2010, World of Tanks току-що се появи. Wargaming имаше приблизително 50 сървъра.
Диаграма на растежа на фирмения сървър.
Имахме мрежов модел. За онова време беше оптимално.
Мрежов модел през 2010 г.
Има лоши момчета от предния край, които искат да ни разбият, но има защитна стена. Няма защитна стена на бекенда, но има 50 сървъра, знаем ги всичките. Всичко работи добре.
За 4 години сървърният флот нарасна 100 пъти, до 5000. Появиха се първите изолирани мрежи - сценични: те не можеха да преминат към производство и там често се изпълняваха неща, които можеха да бъдат опасни.
Мрежов модел през 2014 г.
По инерция използвахме едни и същи хардуерни части и цялата работа беше извършена върху изолирани VLAN: ACL се записват във VLAN, които позволяват или отказват някакъв вид връзка.
През 2016 г. броят на сървърите достигна 8000. Wargaming погълна други студия и се появиха допълнителни партньорски мрежи. Те изглеждат наши, но не съвсем: VLAN често не работи за партньори, трябва да използвате VPN с VRF, изолацията става по-сложна. Изолационната смес ACL нарасна.
Мрежов модел през 2016 г.
До началото на 2018 г. паркът от машини нарасна до 16 000. Имаше 6 сегмента, а останалите не ги броихме, включително затворените, в които се съхраняваха финансови данни. Появиха се контейнерни мрежи (Kubernetes), DevOps, облачни мрежи, свързани чрез VPN, например от IVS. Имаше много правила - беше болезнено.
Мрежов модел и методи за изолация през 2018 г.
За изолация използвахме: VLAN с ACL на L2, VRF с ACL на L3, VPN и много други. Твърде много.
Проблеми
Всеки живее с ACL и VLAN. Какво не е наред? На този въпрос ще отговори Харолд, прикривайки болката.
Имаше много проблеми, но имаше пет големи.
- Геометрично увеличение на цената за нови правила. Добавянето на всяко ново правило отнемаше повече време от предишното, защото беше необходимо първо да се види дали вече има такова правило.
- Няма защитна стена вътре в сегментите. Сегментите бяха някак отделени един от друг и вече нямаше достатъчно ресурси вътре.
- Правилата се прилагаха дълго време. Операторите могат да напишат едно локално правило на ръка за час. Глобалният отне няколко дни.
- Трудности с правилата за одит. По-точно не беше възможно. Първите правила са написани още през 2010 г. и повечето от авторите им вече не работят за компанията.
- Ниско ниво на контрол на инфраструктурата. Това е основният проблем - ние не знаехме много добре какво става у нас.
Ето как изглеждаше един мрежов инженер през 2018 г., когато чу: „Имам нужда от още ACL.“
Решения
В началото на 2018 г. беше решено да се направи нещо по въпроса.
Цената на интеграциите непрекъснато расте. Отправната точка беше, че големите центрове за данни спряха да поддържат изолирани VLAN и ACL, защото паметта на устройствата изчерпа.
Решение: премахнахме човешкия фактор и автоматизирахме максимално предоставянето на достъп.
Прилагането на новите правила отнема много време. Решение: ускорете прилагането на правилата, направете го разпределено и паралелно. Това изисква разпределена система, така че правилата да се доставят сами, без rsync или SFTP до хиляди системи.
Няма защитна стена вътре в сегментите. Защитна стена в рамките на сегменти започна да идва при нас, когато различни услуги се появиха в една и съща мрежа. Решение: използвайте защитна стена на ниво хост - базирани на хост защитни стени. Почти навсякъде, където имаме Linux и навсякъде, където имаме iptables, това не е проблем.
Трудности с правилата за одит. Решение: Съхранявайте всички правила на едно място за преглед и управление, за да можем да одитираме всичко.
Ниско ниво на контрол върху инфраструктурата. Решение: направете опис на всички услуги и достъпите между тях.
Това е по-скоро административен процес, отколкото технически. Понякога имаме 200-300 нови издания на седмица, особено по време на промоции и празници. Освен това, това е само за един екип от нашите DevOps. С толкова много версии е невъзможно да се види какви портове, IP адреси и интеграции са необходими. Затова имахме нужда от специално обучени сервизни мениджъри, които да попитат екипите: „Какво изобщо има и защо го повдигнахте?“
След всичко, което стартирахме, мрежовият инженер през 2019 г. започна да изглежда така.
консул
Решихме, че ще поставим всичко, което намерим с помощта на сервизни мениджъри, в Consul и оттам ще напишем правилата за iptables.
Как решихме да направим това?
- Ние ще съберем всички услуги, мрежи и потребители.
- Нека създадем iptables правила въз основа на тях.
- Ние автоматизираме управлението.
- ....
- ПЕЧАЛБА.
Consul не е отдалечен API, той може да работи на всеки възел и да пише в iptables. Остава само да измислите автоматични контроли, които ще изчистят ненужните неща и повечето проблеми ще бъдат решени! Ще уредим останалото, докато вървим.
Защо консул?
Доказал се е добре. През 2014-15 г. го използвахме като бекенд за Vault, в който съхраняваме пароли.
Не губи данни. По време на употреба Consul не е загубил данни при нито един инцидент. Това е огромен плюс за система за управление на защитна стена.
P2P връзките ускоряват разпространението на промяната. С P2P всички промени идват бързо, няма нужда да чакате с часове.
Удобен REST API. Обмислихме и Apache ZooKeeper, но той няма REST API, така че ще трябва да инсталирате патерици.
Работи както като Key Vault (KV), така и като директория (Service Discovery). Можете да съхранявате услуги, каталози и центрове за данни наведнъж. Това е удобно не само за нас, но и за съседните екипи, защото когато изграждаме глобална услуга, мислим мащабно.
Написано на Go, което е част от стека на Wargaming. Обичаме този език, имаме много Go разработчици.
Мощна ACL система. В Consul можете да използвате ACL, за да контролирате кой какво пише. Гарантираме, че правилата на защитната стена няма да се припокриват с нищо друго и няма да имаме проблеми с това.
Но Consul има и своите недостатъци.
- Не се мащабира в рамките на център за данни, освен ако нямате бизнес версия. Може да се мащабира само чрез федерация.
- Много зависи от качеството на мрежата и натоварването на сървъра. Consul няма да работи правилно като сървър на натоварен сървър, ако има забавяния в мрежата, например неравномерна скорост. Това се дължи на P2P връзките и моделите за разпространение на актуализации.
- Трудност при наблюдение на наличността. В статут на консул може да каже, че всичко е наред, но той почина отдавна.
Решихме повечето от тези проблеми, докато използвахме Consul, поради което го избрахме. Компанията има планове за алтернативен бекенд, но ние се научихме да се справяме с проблемите и в момента живеем с Consul.
Как работи Consul
Ще инсталираме от три до пет сървъра в условен център за данни. Един или два сървъра няма да работят: те няма да могат да организират кворум и да решат кой е прав и кой крив, когато данните не съвпадат. Повече от пет няма смисъл, производителността ще падне.
Клиентите се свързват към сървърите в произволен ред: същите агенти, само с флаг server = false.
След това клиентите получават списък с P2P връзки и изграждат връзки помежду си.
На глобално ниво ние свързваме няколко центъра за данни. Те също така свързват P2P и комуникират.
Когато искаме да извлечем данни от друг център за данни, заявката преминава от сървър на сървър. Тази схема се нарича Клепански протокол. Протоколът Serf, подобно на Consul, е разработен от HashiCorp.
Някои важни факти за Consul
Consul има документация, описваща как работи. Ще дам само избрани факти, които си струва да знаете.
Консулските сървъри избират господар измежду избирателите. Consul избира master от списъка със сървъри за всеки център за данни и всички заявки отиват само към него, независимо от броя на сървърите. Главното замразяване не води до преизбиране. Ако главният не е избран, заявките не се обслужват от никого.
Искахте ли хоризонтално мащабиране? Съжалявам, не.
Заявката към друг център за данни преминава от главния към главния, независимо от кой сървър е дошла. Избраният мастер получава 100% от натоварването, с изключение на натоварването при препращащи заявки. Всички сървъри в центъра за данни имат актуално копие на данните, но само един отговаря.
Единственият начин за мащабиране е да активирате остарял режим на клиента.
В остарял режим можете да отговорите без кворум. Това е режим, в който се отказваме от последователност на данните, но четем малко по-бързо от обикновено и всеки сървър отговаря. Естествено, запис само през мастера.
Consul не копира данни между центрове за данни. Когато се сглоби федерация, всеки сървър ще има само свои собствени данни. За други винаги се обръща към някой друг.
Атомичността на операциите не е гарантирана извън транзакция. Не забравяйте, че не сте единственият, който може да промени нещата. Ако искате да е различно, извършете транзакция със заключване.
Операциите по блокиране не гарантират заключване. Заявката преминава от главен към главен, а не директно, така че няма гаранция, че блокирането ще работи, когато блокирате, например, в друг център за данни.
ACL също не гарантира достъп (в много случаи). ACL може да не работи, защото се съхранява в един обединен център за данни - в ACL център за данни (основен DC). Ако DC не ви отговори, ACL няма да работи.
Един замразен майстор ще накара цялата федерация да замръзне. Например има 10 центъра за данни във федерация и един има лоша мрежа и един главен се проваля. Всеки, който общува с него, ще се забие в кръг: има заявка, няма отговор на нея, нишката замръзва. Няма как да знаем кога ще стане това, просто след час-два ще падне цялата федерация. Нищо не можеш да направиш по въпроса.
Статусът, кворумът и изборите се обработват в отделна тема. Преизбиране няма да има, статусът няма да показва нищо. Мислите си, че имате жив Консул, питате и нищо не се случва - няма отговор. В същото време статусът показва, че всичко е наред.
Сблъскахме се с този проблем и трябваше да изградим отново определени части от центровете за данни, за да го избегнем.
Бизнес версията на Consul Enterprise няма някои от горните недостатъци. Има много полезни функции: избор на избиратели, разпределение, мащабиране. Има само едно „но“ - системата за лицензиране на разпределена система е много скъпа.
Животът хакерство: rm -rf /var/lib/consul - лек за всички болести на агента. Ако нещо не работи за вас, просто изтрийте данните си и изтеглете данните от копие. Най-вероятно Consul ще работи.
BEFW
Сега нека поговорим за това, което добавихме към Consul.
е акроним за BАСКEndFгнявWвсичко. Трябваше да наименувам продукта по някакъв начин, когато създадох хранилището, за да поставя първите тестови ангажименти в него. Това име остава.
Шаблони за правила
Правилата са написани в синтаксиса на iptables.
- -N BEFW
- -P ВХОДЕН КАП
- -A ВХОД -m състояние—състояние СВЪРЗАНО, УСТАНОВЕНО -j ПРИЕМАНЕ
- -A ВХОД -i lo -j ПРИЕМАНЕ
- -A ВХОД -j BEFW
Всичко влиза във веригата BEFW, с изключение на ESTABLISHED, RELATED и локален хост. Шаблонът може да бъде всякакъв, това е само пример.
С какво е полезен BEFW?
Услуги
Имаме услуга, тя винаги има порт, възел, на който работи. От нашия възел можем локално да попитаме агента и да разберем, че имаме някакъв вид услуга. Можете също да поставите тагове.
Всяка услуга, която работи и е регистрирана в Consul, се превръща в правило за iptables. Имаме SSH - отворен порт 22. Bash скриптът е прост: curl и iptables, нищо друго не е необходимо.
Клиентите
Как да отворим достъп не за всички, а избирателно? Добавете IP списъци към KV хранилище по име на услуга.
Например искаме всеки в десетата мрежа да има достъп до услугата SSH_TCP_22. Добавяне на едно малко TTL поле? и сега имаме временни разрешения, например за един ден.
Достъпи
Ние свързваме услуги и клиенти: имаме услуга, KV съхранение е готово за всеки. Сега даваме достъп не на всички, а избирателно.
Групи
Ако пишем хиляди IP за достъп всеки път, ще се уморим. Да измислим групировки - отделно подмножество в KV. Нека го наречем псевдоним (или групи) и да съхраняваме групи там според същия принцип.
Нека се свържем: сега можем да отворим SSH не специално за P2P, а за цяла група или няколко групи. По същия начин има TTL - можете да добавите към група и да премахнете от групата временно.
интеграция
Нашият проблем е човешкият фактор и автоматизацията. Досега сме го решавали по този начин.
Работим с Puppet и им прехвърляме всичко, което е свързано със системата (код на приложението). Puppetdb (обикновен PostgreSQL) съхранява списък с услуги, които се изпълняват там, те могат да бъдат намерени по тип ресурс. Там можете да разберете кой къде кандидатства. Ние също имаме система за заявка за изтегляне и заявка за сливане за това.
Написахме befw-sync, просто решение, което помага за прехвърлянето на данни. Първо, бисквитките за синхронизиране са достъпни от puppetdb. Там е конфигуриран HTTP API: изискваме какви услуги имаме, какво трябва да се направи. След това отправят молба до консула.
Има ли интеграция? Да: те написаха правилата и позволиха приемането на заявки за изтегляне. Имате ли нужда от определен порт или да добавите хост към някаква група? Заявка за изтегляне, преглед - без повече „Намерете 200 други ACL и се опитайте да направите нещо по въпроса.“
Оптимизация
Pinging localhost с празна верига от правила отнема 0,075 ms.
Нека добавим 10 000 iptables адреса към тази верига. В резултат на това ping ще се увеличи 5 пъти: iptables е напълно линеен, обработката на всеки адрес отнема известно време.
За защитна стена, където мигрираме хиляди ACL, имаме много правила и това въвежда латентност. Това е лошо за протоколите за игри.
Но ако сложим 10 000 адреса в ipset Пингът дори ще намалее.
Въпросът е, че „O“ (сложността на алгоритъма) за ipset винаги е равно на 1, без значение колко правила има. Вярно, има ограничение - не може да има повече от 65535 правила.Засега живеем с това: можете да ги комбинирате, да ги разширявате, да правите два ipseta в един.
Хранение
Логично продължение на процеса на итерация е съхраняването на информация за клиентите на услугата в ipset.
Сега имаме същия SSH и не пишем 100 IP наведнъж, а задаваме името на ipset, с който трябва да комуникираме, и следното правило DROP. Може да се преобразува в едно правило „Който не е тук, ПУСТИ“, но е по-ясно.
Сега имаме правила и комплекти. Основната задача е да направите набор преди да напишете правилото, защото в противен случай iptables няма да напише правилото.
Обща схема
Под формата на диаграма всичко, което казах, изглежда така.
Ние се ангажираме с Puppet, всичко се изпраща на хоста, услугите тук, ipset там и всеки, който не е регистриран там, не се допуска.
Разрешаване и отказ
За да спасим бързо света или бързо да деактивираме някого, в началото на всички вериги направихме два ipseta: rules_allow и rules_deny. Как работи?
Например, някой създава натоварване на нашата мрежа с ботове. Преди това трябваше да намерите неговия IP от регистрационните файлове, да го занесете на мрежовите инженери, за да могат да намерят източника на трафика и да го забранят. Сега изглежда различно.
Изпращаме го на Consul, изчакваме 2,5 секунди и готово. Тъй като Consul разпространява бързо чрез P2P, той работи навсякъде, във всяка част на света.
Веднъж някак напълно спрях WOT поради грешка със защитната стена. rules_allow - това е нашата застраховка срещу подобни случаи. Ако сме сгрешили някъде със защитната стена, нещо е блокирано някъде, винаги можем да изпратим условно 0.0/0бързо да вземе всичко. По-късно ще поправим всичко на ръка.
Други комплекти
Можете да добавите всякакви други комплекти в пространството $IPSETS$.
За какво? Понякога някой има нужда от ipset, например, за да емулира изключване на някаква част от клъстера. Всеки може да донесе всякакви комплекти, да ги назове и те ще бъдат взети от Консул. В същото време комплектите могат или да участват в правилата на iptables, или да действат като екип NOOP: Съгласуваността ще се поддържа от демона.
Потребители
Преди това беше така: потребителят се свързваше с мрежата и получаваше параметри през домейна. Преди появата на защитните стени от ново поколение Cisco не знаеше как да разбере къде е потребителят и къде е IP адресът. Следователно достъпът беше предоставен само чрез името на хоста на машината.
какво направихме Закъсахме в момента, в който получихме адреса. Обикновено това е dot1x, Wi-Fi или VPN - всичко минава през RADIUS. За всеки потребител създаваме група по потребителско име и поставяме IP в нея с TTL, който е равен на неговия dhcp.lease - веднага щом изтече, правилото ще изчезне.
Сега можем да отворим достъп до услуги, като други групи, чрез потребителско име. Премахнахме болката от имената на хостове, когато се променят, и премахнахме тежестта от мрежовите инженери, защото те вече не се нуждаят от Cisco. Сега инженерите сами регистрират достъп на своите сървъри.
Изолация
В същото време започнахме да демонтираме изолацията. Сервизните мениджъри направиха инвентаризация и ние анализирахме всички наши мрежи. Нека ги разделим на същите групи и на необходимите сървъри групите бяха добавени, например, за отказ. Сега същата сценична изолация завършва в rules_deny на продукцията, но не и в самата продукция.
Схемата работи бързо и просто: премахваме всички ACL от сървърите, разтоварваме хардуера и намаляваме броя на изолираните VLAN.
Контрол на целостта
Преди това имахме специален тригер, който отчиташе, когато някой промени правило на защитната стена ръчно. Пишех огромен линтер за проверка на правилата на защитната стена, беше трудно. Целостта вече се контролира от BEFW. Той ревностно гарантира, че правилата, които създава, не се променят. Ако някой промени правилата на защитната стена, това ще промени всичко обратно. „Настроих бързо прокси, за да мога да работя от вкъщи“ – няма повече такива опции.
BEFW контролира ipset от услугите и списъка в befw.conf, правилата на услугите във веригата BEFW. Но не следи други вериги и правила и други ipsets.
Защита срещу сблъсък
BEFW винаги съхранява последното известно добро състояние директно в двоичната структура state.bin. Ако нещо се обърка, винаги се връща обратно към този state.bin.
Това е застраховка срещу нестабилна работа на Consul, когато не е изпратил данни или някой е направил грешка и е използвал правила, които не могат да бъдат приложени. За да гарантира, че няма да останем без защитна стена, BEFW ще се върне към най-новото състояние, ако възникне грешка на който и да е етап.
В критични ситуации това е гаранция, че ще останем с работеща защитна стена. Отваряме всички сиви мрежи с надеждата, че администраторът ще дойде и ще го оправи. Някой ден ще сложа това в конфигурациите, но сега имаме само три сиви мрежи: 10/8, 172/12 и 192.168/16. В рамките на нашия консул това е важна функция, която ни помага да се развиваме по-нататък.
Демо: по време на доклада Иван демонстрира демо режима на BEFW. По-лесно е да гледате демонстрацията . Наличен демо изходен код .
Клопките
Ще ви разкажа за грешките, които срещнахме.
ipset add set 0.0.0.0/0. Какво се случва, ако добавите 0.0.0.0/0 към ipset? Ще бъдат ли добавени всички IP адреси? Ще има ли достъп до интернет?
Не, ще получим грешка, която ни струва два часа престой. Освен това бъгът не работи от 2016 г., той се намира в RedHat Bugzilla под номер #1297092 и го открихме случайно - от доклад на разработчик.
Сега това е строго правило в BEFW 0.0.0.0/0 се превръща в два адреса: 0.0.0.0/1 и 128.0.0.0/1.
набор за възстановяване на ipset < файл. Какво прави ipset, когато му кажете restore? Мислите ли, че работи по същия начин като iptables? Ще възстанови ли данни?
Нищо подобно - прави сливане и старите адреси не отиват никъде, не блокирате достъпа.
Открихме грешка при тестване на изолацията. Сега има доста сложна система - вместо restore се провежда create temp, тогава restore flush temp и restore temp. В края на размяната: за атомарност, защото ако го направите първи flush и в този момент пристига някакъв пакет, той ще бъде изхвърлен и нещо ще се обърка. Така че има малко черна магия.
консул kv get -datacenter=друго. Както казах, смятаме, че искаме някакви данни, но или ще получим данни, или грешка. Можем да направим това чрез Consul локално, но в този случай и двете ще замръзнат.
Локалният клиент Consul е обвивка на HTTP API. Но той просто виси и не реагира само на Ctrl+C, или Ctrl+Z, или нещо друго kill -9 в следващата конзола. Срещнахме това, когато изграждахме голям клъстер. Но все още нямаме решение; подготвяме се да коригираме тази грешка в Consul.
Лидерът на консула не отговаря. Нашият капитан в центъра за данни не отговаря, ние си мислим: „Може би алгоритъмът за повторен избор ще работи сега?“
Не, няма да работи и мониторингът няма да покаже нищо: консулът ще каже, че има индекс на ангажираност, лидер е намерен, всичко е наред.
Как да се справим с това? service consul restart в cron на всеки час. Ако имате 50 сървъра, няма нищо страшно. Когато станат 16 000, ще разберете как става.
Заключение
В резултат на това получихме следните предимства:
- 100% покритие на всички Linux машини.
- Speed.
- Автоматизация.
- Ние освободихме хардуерните и мрежовите инженери от робство.
- Появиха се възможности за интеграция, които са почти неограничени: дори с Kubernetes, дори с Ansible, дори с Python.
Против: Консул, с който сега трябва да живеем, и много високата цена на грешката. Като пример, веднъж в 6:XNUMX (най-гледаното време в Русия) редактирах нещо в списъците с мрежи. Ние просто правехме изолация в BEFW по това време. Сбърках някъде, май посочих грешната маска, но всичко падна за две секунди. Мониторингът светва, притичва дежурният по поддръжката: „Имаме всичко!“ Шефът на ведомството побеля, когато обясни на бизнеса защо се е случило така.
Цената на грешката е толкова висока, че измислихме собствена сложна процедура за предотвратяване. Ако внедрите това на голям производствен обект, не е необходимо да давате главен токен над Consul на всички. Това ще свърши зле.
Cost. Написах код за 400 часа сам. Моят екип от 4 души отделя 10 часа месечно за поддръжка на всички. В сравнение с цената на всяка защитна стена от ново поколение, тя е безплатна.
Планове. Дългосрочният план е да се намери алтернативен транспорт, който да замени или допълни Консул. Може би ще е Кафка или нещо подобно. Но през следващите години ще живеем на Консул.
Непосредствени планове: интеграция с Fail2ban, с мониторинг, с nftables, евентуално с други дистрибуции, метрики, разширен мониторинг, оптимизация. Поддръжката на Kubernetes също е някъде в плановете, защото сега имаме няколко клъстера и желание.
Още от плановете:
- търсене на аномалии в трафика;
- управление на мрежови карти;
- Поддръжка на Kubernetes;
- асемблиране на пакети за всички системи;
- Web-UI.
Ние непрекъснато работим върху разширяването на конфигурацията, увеличаването на показателите и оптимизацията.
Присъединете се към проекта. Проектът се оказа готин, но за съжаление все още е проект за един човек. Ела и се опитайте да направите нещо: ангажирайте се, тествайте, предложете нещо, дайте своята оценка.
Междувременно се подготвяме за , който ще се проведе на 6 и 7 април в Санкт Петербург, и каним разработчици на системи с високо натоварване . Опитните оратори вече знаят какво да правят, но за тези, които започват да говорят, препоръчваме поне . Участието в конференцията като лектор има редица предимства. Можете да прочетете кои например в края .
Източник: www.habr.com