Ondřej Caletka: Multipath TCP
Ondřej Caletka začal svou přednášku obecným výkladem o protokolu TCP, který je nejpoužívanějším protokolem na internetu. Jeho úlohou je nad nespolehlivou paketovou IP sítí vytvářet spolehlivý proudový přenos. Dnešní zařízení mají ovšem velmi často několik různých možností připojení, ale nedokáží je využít najednou. Můj notebook se teď třeba může připojit po kabelu, WiFi i přes mobilní síť.
Tento problém právě řeší multipath TCP.
Jde vlastně o vylepšení TCP protokolu o podporu vícenásobného spojení za pomocí různých rozhraní a různých zdrojových IP adres. Dovoluje například zálohovat hlavní linku pomocí několika vedlejších, či využít více nezávislých cest k navýšení výkonu připojení. Poměrně často se někdo naivně ptá, jak může spojit 20Mbit a 40Mbit linku do jedné 60Mbit. Takové spojení za normálních možností není možné, ale s multipath to možné je.
V principu jde o to, že dvě zařízení spolu přes internet naváží několik různých spojení v kombinaci všech dostupných rozhraní. Pomocí dodatečných hlaviček v TCP si odsignalizují, jaké IP adresy mají v současné době dostupné a na všechny se vzájemně spojí.
Pak je možné otestovat kvalitu spojení a využít to opravdu nejlepší. Funguje to zároveň s IPv4 i IPv6 konektivitami, takže je pak skutečně zvolen nejlepší způsob připojení.
Pokud právě používané spojení z nějakého důvodu vypadne, automaticky se najde další nejlepší a komunikace pokračuje. Nedojde přitom k přerušení datového toku, takže z uživatelského hlediska ani nepoznáte, že se data přesměrovala přes jiné spojení.
Překážku v použití multipath TCP představují různé middleboxy, které jsou instalovány na mnoha sítích. Jde například o NAT, ALG, transparentní proxy a další zařízení, která ovlivňují spojení. Odhaduji, že asi 60 % kódu multipath TCP řeší obcházení těchto middleboxů.
Některé překážky ovšem překonat nelze, takže na některých sítích pak nic jiného než standardní TCP fungovat nebude.
Pro funkci multipath TCP není potřeba nijak upravovat síť samotnou, protože protokol je zpětně kompatibilní s TCP. Je ovšem potřeba implementovat podporu na obou komunikujících zařízeních. Pokud druhá strana multipath nepodporuje, nezareaguje na doplňkové hlavičky a komunikace pak probíhá standardně jedním TCP kanálem.
Implementace je k dispozici pro Linux a FreeBSD, zatím však neexistuje řešení pro Windows či OS X. Četl jsem o tom, že nový iOS 7 používá multipath pro komunikaci s hlasovou službou SIRI. Pro ostatní komunikaci se ale ani tam nepoužívá.
Výhodou MPTCP je, že z hlediska uživatele i aplikací se chová stejně, jako obyčejné TCP. Vyměněná TCP vrstva se ale stará o to, že když jedno spojení vypadne, je automaticky nahrazeno jiným. Používám multipath asi měsíc a nesetkal jsem se s žádnými problémy.
Naopak nevýhodou je vyšší počet spojení, což neudělá radost poskytovatelům obsahu, pro které znamená vyšší zátěž. Stejně tak nebudou nadšeni poskytovatelé připojení, kteří se snaží odlehčit svým Carrier-Grade NATům. Z praktického hlediska je také nepříjemný ‚měkký handover‘. Pokud jedno spojení vypadne, musí existovat alespoň jedno další, na kterém se stroje dohodnou o dalším postupu. Pokud žádné spojení neexistuje, TCP sezení se rozpadne, protože není jak změnu odsignalizovat.
Tím je limitovaná i implementace plné mobility. Pokud například na mobilu náhle změníme WiFi síť a zároveň v tu chvíli nemáme dostupná GSM data, naše navázaná TCP spojení se rozpadnou i přes MPTCP.
Pavel Tišnovský: IDE v Linuxu
Pavel Tišnovský se zabýval vývojovými prostředími, která existují pro Linux. Ukázal, že jich existuje celá řada. Hodně vývojářů tvrdí, že nemůžou pro Linux vyvíjet, protože pro něj neexistuje Visual Studio.
Pokud jim už vysvětlíte, že mohou použít jinou variantu, často ji odmítnou pro špatnou kvalitu. Podle Tišnovského jde ale o předsudek. Říká se, že v Linuxu nejsou pořádná vývojová prostředí. Já si myslím, že to není pravda, proto jsem se rozhodl udělat tuto přednášku.
Pavel Tišnovský pak svou přednášku pojal jako přehled různých vývojových prostředí, která rozdělil do několika kategorií: odlehčená univerzální IDE, IDE specializovaná na jeden jazyk, těžkotonážní IDE a nakonec neortodoxní prostředí. Uvedl příklad několika různých variant v každé skupině.
Řekl přitom, že většina moderních IDE má řadu společných vlastností. My programátoři už jsme docela rozmlsaní, takže už nám nestačí jen editor, ale požadujeme integraci mnoha dalších funkcí, které nám ulehčí život.
Jde samozřejmě o samotný programátorský editor, ale také o správce projektů, rozhraní pro překlad a debugger. Tyto nástroje má v různé podobě každé IDE.
Postupně byla představena prostředí: Anjuta, která vznikla už v roce 1999 a podporuje jazyky C, C++, Python, Vala, Java a JavaScript. Dále následoval Qt Creator, který je zaměřený na vývoj aplikací využívajících knihovnu Qt. Má velmi dobrý editor, který umí emulovat chování Vim s většinou jeho vlastností.
Výhodou Qt Creatoru je také velmi bohatá dokumentace.
Dalším vývojovým prostředím bylo prostředí Geany, o němž Pavel Tišnovský řekl, že je velmi nenáročné na systémové zdroje. Poměrně často ho používám na starším notebooku s 512 MB RAM a je to jediné vývojové prostředí, které tam pracuje bez problémů.
Dále bylo popsáno prostředí Code::Blocks. Už z názvu vyplývá, že tohle prostředí bylo původně vytvořeno pro vývoj v C++, ale dnes už tomu tak není.
Code::Blocks je napsáno v knihovně wxWidgets, je multiplatformní a má podporu pro mnoho různých překladačů.
Mezi IDE zaměřené na jeden programovací jazyky byl zařazen Gambas, který je inspirován Visual Basicem. Autor byl fascinován množstvím chyb ve Visual Basicu, proto se rozhodl jeho chyby zduplikovat ve vlastním prostředí.
Velkou výhodou je pokročilý interaktivní grafický návrhář formulářů, inspirovaný právě Visual Basicem. Neprogramuje se v něm ovšem v Basicu, ale jde o plnohodnotný strukturovaný programovací jazyk.
Dalším IDE pro jeden jazyk je Lazarus. Tvůrci projektu Lazarus se snažili napodobit dříve oblíbené prostředí Delphi, ale doplnit do něj podporu databází a další vylepšení.
Lazarus má rozhraní pro GTK+, Qt, Win32, Cocoa a Carbon. Editor rozhraní obsahuje řadu komponent, které se dají jednoduše přetáhnout do okna nové aplikace a použít. Na rozdíl od Delphi umožňuje Lazarus umisťovat i prvky do oken relativně, takže se aplikace umí přizpůsobovat různým rozlišením a displejům.
Dalším představovaným prostředím bylo IDLE, které je určeno pro vývoj v Pythonu. IDLE je součástí základní instalace Pythonu ve Windows.
Podle Pavla Tišnovského se ale toto IDE používá na školách, protože je poměrně jednoduché a nedá se na něm nic pokazit. Nevýhodou je velmi jednoduchý programátorský editor, takže pokud jste zvyklí na jiné prostředí, tady vám toho bude hodně chybět.
Celá nápověda k prostředí je tvořena jediným souborem. Je to hodně minimalistické prostředí.
Dále byl zmíněn Eric, což je rozhraní pro vývoj v Pythonu a Ruby. Eric je vytvořený v Pythonu, což je dobře, protože jeho vývojáři Pythonu rozumí a tak ví, co uživatele takového editoru potřebují.
Pro Eric je dnes dostupná celá řada zásuvných modulů, které rozšiřují možnosti prostředí například o analýzu kódu či diagramy jednotlivých funkcí.
Jako „těžkotonážní prostředí“ byl nakonec představen Eclipse. Důležité je, že Eclipse není prostředí pro vývoj v Javě, jak se často uvádí. Je to spíš univerzální platforma pro tvorbu IDE.
Zajímavé je, že podporuje více pracovních ploch a podporuje různé pohledy na projekty. Vývojářské prostředí je pak možné rozšiřovat pomocí různých modulů pro různé jazyky. Například JDT pro Javu, Pydev pro Python či Counterclockwise pro Clojure.
Nakonec byla zmíněna některé neortodoxní prostředí jako IPython, Vim s různými moduly a Emacs nakonfigurovaný jako vývojové prostředí. Už jsem viděl i programátory, kteří si s pomocí mnoha modulů nakonfigurovali Gedit jako vývojové prostředí.
Nástrojů pro vývoj tedy existuje nepřeberné množství.
Jiří Ráž: Open-source antispamová ochrana
Jiří Ráž ze sdružení Cesnet popisoval rozsáhlé zkušenosti se stavbou antispamového řešení postaveného na Linuxu. Spam je samozřejmě dnes možné filtrovat u externí firmy, která vše zajistí za vás. Tím ovšem dáte z ruky veškerou poštu a kontakty na uživatele. Obvykle také ztratíte možnost jakékoliv konfigurace a celá antispamová ochrana je pro vás jen blackboxem.
Základní ochranu představuje už samotná konfigurace vstupu na přijímacím mail serveru. Přijímat bychom měli pouze korektní e-mailové adresy z existujících domén. Jinak se nám na serveru bude hromadit pošta a nedoručenky není kam posílat.
Asi nejpoužívanějším open-source antispamovým řešením je Spamassassin od Apache Foundation. Provádí rozličné testy a uděluje zprávě kladné či záporné body. Podle výsledku pak zprávu ohodnotí. Jde o poměrně spolehlivé řešení, které je ale náročné na výkon serveru.
V případě velkého zatížení tak dochází ke zpoždění pošty.
Výhoda je, že mu můžeme vytvářet vlastní pravidla a tvořit jak whitelisty, tak blacklisty. Můžeme třeba určit, že maily od naší firemní tiskárny nejsou nikdy spam a naopak určit, které sítě nám nikdy nepošlou regulérní poštu.
Spamassassin je navíc schopen spolupracovat s ClamAV a kontrolovat poštu na viry.
Poměrně dobrou metodou boje proti spamu je greylisting. Ten umí sám o sobě výrazně snížit počet spamu, který nám dorazí na server. Odhaduji, že jde určitě o padesát procent.
Využívá se toho, že spammery nezajímá, zda byla zpráva doručena. Jejich cílem je obeslat co nejvíce uživatelů v co nejkratším čase. Na první pokus je zpráva odmítnuta a server si pokus poznamená. Jakmile je pokus zopakován, mail už projde.
Umístěním greylistingu před Spamassassina snížíme výrazně zátěž serveru, protože greylisting je podstatně méně náročný než plná kontrola obsahu mailu. Doporučován byl nástroj SQLgrey.
Další zajímavou technikou je nolisting, který obdobně jako greylisting využívá lenosti spammerů. Spočívá ve vytvoření MX záznamu s nejnižší prioritou na adresu, kde nic neběží.
Lepší variantou je konfigurace Postfixu, který poštu pouze odmítá. V obou případech by se měl legitimní server pokusit o doručení na jiný MX server. Otázka je, jak je to účinné, protože dnes už neplatí, že se spammeři zaměřují na MX servery s nejnižší prioritou.
Dále je možné používat různé blacklisty a whitelisty, což jsou seznamy spamujících IP adres. Pro zjišťování informací z nich se využívá jednoduchého DNS dotazu. Je ale poměrně riskantní odmítat poštu na základě jednoho blacklistu. Dostat se na seznam hříšníků je totiž velmi jednoduché.
Problém je například v různých bezdrátových sítích, kde se střídají uživatelé. Jeden z nich může ze zavirovaného počítače rozesílat spam a IP adresa se velmi rychle dostane na blacklist. Lepší je proto kombinovat informace z několika zdrojů.
K tomu se velmi dobře hodí Postfwd, který umožňuje vytvářet filtrovací pravidla a poštu prověřovat ještě před tím, než zpráva vstoupí do našeho mailového systému. Můžeme filtrovat podle IP adresy, odesílatele, příjemce a pozdravu. Můžeme tak například testovat správnost reverzních záznamů, výskyt adres na různých blacklistech a podobně. Používáme asi šest blacklistů, takže máme větší šanci, že neodmítneme poštu, která by měla projít.
Výhodou tohoto řešení je, že dokáže výrazně snížit zatížení mail serveru.
Pro Postfwd můžeme také vytvářet vlastní seznamy škodících adres. Pomocí Fail2ban můžeme sledovat IP adresy strojů, které se například snaží doručovat adresy na neexistující schránky. Tím vytvoříme seznam adres, které se nám snaží škodit a předáme je Postfwd, který se s nimi odmítne bavit.
Fail2ban navíc umí sám po nějakém čase adresy odblokovat.
Jiří Ráž přidal praktické zkušenosti z provozu mail serveru v síti Cesnet. Po nasazení všech zmíněných technik klesl počet spamů doručených do uživatelských schránek z několika tisíc zhruba na desítku. Greylisting trochu pomohl, ale ne zásadně. Až po nasazení Postfwd došlo k významnému poklesu spamu.
