Portál AbcLinuxu, 16. května 2024 15:50
Aktuální verze jádra: 3.1-rc6. Citáty týdne: Luis Rodriguez, Alan Cox. Vývoj jádra bez kernel.org. LPC: zrychlujeme síť: Proporcionální omezení rychlosti; Rychlé otevření TCP spojení; Stručně: síťové fronty v uživatelském prostoru.
Aktuální vývojová verze jádra je 3.1-rc6 vydaná 14. září. Věci jdou kvůli nefunkčnosti kernel.org nadále pomalu, takže nedochází k mnoha změnám. Nic, co by vystupovalo z řady. Pusťte se do toho a dejte nám vědět, jestli narazíte na nějaké zbývající regrese. Repozitář je samozřejmě nadále umístěn na Githubu.
Stabilní vydání: během uplynulého týdne nebyly vydány žádné stabilní aktualizace.
Ve zkratce – soubory spatch mohou být použity na cílovém adresáři pro generování patchů. spdiff umí přečíst patch a podle něj vygenerovat spatch. Toto pro svět backportování znamená to, že pokud backportujete jednu evoluční změnu v linuxovém jádře na jednom ovladači, tak můžete backportovat tu samou změnu u *všech* ovladačů. Toto je ohromný krok kupředu, co se práce potřebné pro backportování týče.
-- Luis Rodriguez zjednodušuje backportování
Nejsem si jist, že právo kolem odvozených děl je tak jednoznačné, ale zase 'poskytněte krátkou stručnou definici odvozených děl' se zdá být právní obdobou Goldbachovy hypotézy.
-- Alan Cox
Bezpečnostní problémy na kernel.org vyvolaly obavy o zdrojový kód jádra a další software, který je tam hostován. Zatím nebylo prokázáno, že by kernel.org bylo použito k šíření závadného softwaru. Ale celý průlom má i druhou stránku: kernel.org je „mimo provoz z důvodů údržby“ a není známo, kdy se vrátí. Takže i když nebyl šířen žádný škodlivý software, následkem je to, že průlom kernel.org představuje DoS útok značného rozsahu.
Linus vydal dvě 3.1-rc verze z dočasného umístění na Githubu, nicméně tam není k nalezení mnoho práce. Mimo jiné ztráta repozitářů hostovaných na kernel.org znamená to, že relativně není mnoho věcí, které by mohl přetahovat. Stephen Rothwell mezitím pokračuje v přetahování stromů, ke kterým se dostane, aby vytvořil linux-next. Je schopen hlásit problémy s integrací a sestavováním, ale nemůže dát strom tam, odkud by jej mohli přetahovat ostatní. Navíc si teď užívám klidu. Od té doby, co je kernel.org mimo provoz, nevyšly žádné stabilní aktualizace stromu.
Prozatím se objevují alternativní stromy, jak vývojáři nacházejí jiná místa, kde hostovat svou práci. Pokud bude ještě nějakou dobu výpadek kernel.org pokračovat, můžeme očekávat, že se takových stromů vynoří ještě mnohem víc – ačkoliv někteří vývojáři vytváření alternativních repozitářů odmítají. Většina náhradních stromů je označena jako dočasné, bude ale zajímavé, kolik z nich se přesune zpět na kernel.org, jakmile tato epizoda dospěje ke konci. Někteří vývojáři se mohou rozhodnout, že jim více vyhovuje, když je strom jinde. Takže možná máme distribuovaný systém pro správu zdrojového kódu, ale ukázalo se, že jaderná komunita pracuje s centralizovaným hostingem a distribuovanou infrastrukturou.
Ztráta kernel.org zpomalila věci dostatečně na to, aby bylo jasné, že celý proces má v sobě jedno kritické místo, které nesmí selhat. Jestli stojí za námahu toto napravovat, není úplně jasné, nedošlo k žádné ztrátě kódu a kdyby kernel.org mělo odejít navždy, celý proces by se mohl rychle vrátit do normálu na jiných systémech. Nicméně zatím byly věci narušeny do takové míry, jak se to málo jiným událostem povedlo. Stojí za to zamyslet se, co by se stalo, kdyby k narušení došlo v průběhu začleňovacího okna.
Téměř všechny služby nabízené Googlem jsou poskytovány přes Internet, takže je logické, že tato společnost má zájem na zlepšování fungování sítě. Síťařská část Linux Plumbers Conference 2011 obsahovala přednášky od tří vývojářů Google, přičemž každý z nich měl návrh na zásadní změnu implementace. Suma sumárum se zdá, že v tom, jak funguje síťování, je hodně prostoru pro vylepšení.
Okénko [congestion window] je u odesilatele v TCP jeho představou o tom, kolik dat může být na cestě k příjemci, než se začne linka přetěžovat. Zahozené pakety jsou často známkou toho, že je okénko příliš velké, takže implementace TCP obvykle okénko značně zmenší, jakmile ke ztrátě dojde. Jenže zmenšení okénka zase omezí výkon; pokud byla ztráta paketu jen náhoda, celé zpomalení je pak naprosto zbytečné. RFC 3517 popisuje algoritmus, pomocí kterého je rychlost spojení po ztrátě paketu rychle obnovena, ale Nandita Dukkipati říká, že by to šlo udělat lépe.
Podle Nandity u velké části síťových spojení se servery Googlu dojde k nějaké ztrátě; dokončení těchto spojení pak trvá 7-10krát déle. RFC 3517 je součástí tohoto problému. Algoritmus reaguje na ztrátu paketu okamžitým zmenšením okénka na polovinu, což znamená, že odesílající strana musí, pokud bylo v době ztráty okénko plné, počkat na ACK u poloviny paketů, které byly právě přenášeny, než začne odesílat další data. To způsobí, že se odesílající strana na delší dobu odmlčí. V jednoduchých případech to funguje dostatečně dobře (ztráta jednoho paketu v dlouhotrvajícím přenosu), ale když jde o krátké přenosy nebo rozsáhlejší ztráty paketů, je tu tendence, že se to ucpe.
Linux aktuálně nedodržuje RFC 3517 striktně; namísto toho používá vylepšení nazvané „půlení rychlosti“ [rate halving]. S tímto algoritmem není okénko zmenšeno na polovinu okamžitě. Jakmile se spojení dostane do fáze obnovy po ztrátě, každý přijatý ACK (který typicky potvrdí přijetí dvou paketů na druhé straně) způsobí zmenšení okénka o jediný paket. V průběhu jedné sady paketů, které zrovna byly přenášeny, bude okénko zmenšeno na polovinu, ale odesílající strana bude v průběhu tohoto omezování odesílat dále (pomaleji). Výsledkem je plynulejší běh a snížená latence.
Ale půlení rychlosti lze dále zlepšovat. ACKy, na kterých závisí, jsou samy o sobě možným předmětem ztráty; rozsáhlejší ztráta může způsobit významné omezení velikosti okénka a pomalou obnovu. Tento algoritmus ani nezahajuje proces zvětšování na nejvyšší funkční hodnotu, dokud není proces obnovy dokončen. Takže může chvíli trvat, než se rychlost obnoví.
Algoritmus proporcionálního omezení rychlosti má odlišný přístup. Prvním krokem je odhadnout, kolik dat ještě teče po drátech, což je následováno výpočtem toho, kolik by podle aktuálně používaného algoritmu měla být velikost okénka. Pokud je objem dat na cestě menší než cílová velikost okénka, systém rovnou zahájí algoritmus pomalého startu TCP [TCP slow start], aby uvedl velikost okénka do původního stavu. Takže pokud během spojení dojde k nárazovým ztrátám, systém začne pracovat na obnově velikosti okénka okamžitě namísto toho, aby se plazil s malým okénkem delší dobu.
Pokud je objem dat na cestě alespoň tak velký jako nové okénko, je použit algoritmus podobný půlení rychlosti. Skutečné omezení rychlosti je spočítáno relativně vůči novému okénku namísto toho, aby šlo o přímočaré půlení. U velkých i malých ztrát má důraz na používání odhadů dat v trubkách namísto počítání ACK prý za následek plynulejší obnovu a systém se tak vyhne zbytečným omezením velikosti okénka.
O kolik je to lepší? Nandita říká, že Google na některých ze svých systémů provedl experimenty; výsledkem bylo snížení průměrné latence o 3 – 10 %. Vypršení časového limitu při obnově poklesla o 5 %. Tento kód je nyní nasazován na více serverech Googlu; taktéž byl přijat k zařazení v průběhu vývojového cyklu verze 3.2. Více informací můžete najít v tomto návrhu RFC.
Otevření TCP spojení vyžaduje třípaketový handshake; SYN paket odeslaný klientem, SYN-ACK odpověď od serveru a konečné ACK od klienta. Než je handshake dokončen, není možné přenášet žádná data, takže handshake nevyhnutelně vede k latenci při vytváření každého spojení. Yuchung Cheng se ale ptá, co by se stalo, kdybychom data odesílali přímo v paketech handshaku? Pro jednoduché operace – kupříkladu požadavek HTTP GET následovaný obsahem stránky – by odeslání relevantních dat spolu s handshakem omezilo latenci. Výsledkem tohoto je návrh „rychlého otevírání TCP spojení“ [TCP fast open].
RFC 793 popisující TCP umožňuje, aby v handshake paketech byla odesílána data, a to s podmínkou, že data nebudou předána aplikaci, dokud nebude handshake dokončen. Mohli bychom zvažovat vynechání této podmínky, abychom urychlili proces přenosu dat přes TCP spojení, ale jsou tu jistá rizika, se kterými je nutné se vypořádat. Zjevným problémem je usnadnění SYN flood útoků, které jsou špatné samy o sobě, i když se dotknou jen jádra; pokud by každý přijatý SYN paket měl zabrat i prostředky aplikace, možnosti DoSu by byly značně horší.
Yuchung popsal přístup k rychlému otevření, který by většinu problémů obešel. Prvním krokem je vytvoření tajné hodnoty pro každý server, která je hashována spolu s informacemi od každého klienta s cílem vytvoření cookie specifické pro daného klienta. Tato cookie je odeslána klientovi jako speciální atribut k obvyklému paketu SYN-ACK; klient si to může ponechat pro rychlá otevření spojení v budoucnu. Požadavek získat nejprve cookie je překážkou za účelem zamezit útokům SYN flood, ale trochu věci komplikuje. Tajná hodnota serveru je navíc docela často měněna a pokud server zjistí příliš mnoho nových spojení, rychlé otevírání bude znemožněno, dokud se věci neuklidní.
Je tu jeden problém, a to, že kolem 5 % systémů zahodí SYN pakety obsahující neznámé atributy nebo data. S tímto se nedá moc udělat; rychlé otevření TCP spojení prostě nebude fungovat. Klient si proto musí pamatovat případy, kde SYN pakety pro rychlé otevření neprošly a v budoucnu použít obyčejný postup.
K rychlému otevření by nedocházelo ve výchozím stavu; aplikace na obou stranách by o to musely explicitně požádat. Na klientské straně je pro rychlé otevření použito systémové volání sendto() s novým příznakem MSG_FAST_OPEN, funguje to jako kombinace connect() a sendmsg(). Na serverové straně umožní rychlé otevírání volání setsockopt() s volbou TCP_FAST_OPEN. Tak či tak se aplikace nemusejí cookies pro rychlé otevření a podobnými věcmi zabývat.
Při testech Googlu rychlé otevírání TCP spojení zlepšilo časy načítání stránek o 4 až 40 %. Tato technika funguje nejlépe v situacích, kdy je latence mezi stranami spojení vysoká, samozřejmě čím je vyšší, tím účinnější je ji odstranit. Patch implementující tuto funkčnost bude brzy zaslán k zařazení.
Zatímco předchozí dvě přednášky se týkaly zvyšování účinnosti přenosu dat přes síť, Willem de Bruijn se zabývá zpracováním síťových operací na lokálním systému. Především pracuje s high-end hardwarem: vysokorychlostní linky, spousty procesorů a především malé síťové adaptéry, které jsou schopné rozpoznat určité přenosy a nasměrovat pakety do front specifických pro jednotlivá spojení. Než se jádro vůbec dostane k nějakým rozvahám nad daným paketem, už je zařazen na správné místo, čekaje na aplikaci, než si požádá o data.
Samotné zpracování paketů se odehraje v kontextu přijímajícího procesu dle potřeby. Takže se vše odehraje ve správném kontextu na správném CPU; mezizpracování na úrovni softwarového IRQ je vynecháno. Willem popsal nové rozhraní, pomocí kterého by aplikace přijímala pakety přímo od jádra přes sdílený paměťový segment.
Jinými slovy, přednáška popisovala variantu konceptu síťových kanálů, kde je zpracovávání paketů přesunuto co nejblíže aplikaci. Je zde řada detailů, se kterými je nutné se vyrovnat, včetně obvyklých překážek celé myšlenky kanálů: zpracovávání firewallem atp. Navrhované používání souboru v sysfs pro přenos paketů do uživatelského rozhraní také pravděpodobně neprojde revizí. Ale tato práce se může nakonec dostat do stavu, kdy je obecně užitečná; ti, které to zajímá, mohou najít patche na stránce unetq.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.