Jaderné noviny – 14. 3. 2013: Přednosti SO_REUSEPORT pro síťové servery

2. 4. 2013 | Luboš Doležel | Jaderné noviny | 3608×

Aktuální verze jádra: 3.9-rc2. Citáty týdne: Ben Bell, Linus Torvalds a tým Pax. Overlayfs v 3.10. Volba SO_REUSEPORT u socketů.

Obsah

• Aktuální verze jádra: 3.9-rc2
• Citáty týdne: Ben Bell, Linus Torvalds a tým Pax
• Overlayfs v 3.10
• Volba SO_REUSEPORT u socketů

Aktuální verze jádra: 3.9-rc2

Aktuální vývojová verze jádra je 3.9-rc2 vydaná 10. března. Mno, bylo to docela v poklidu. Jasně, Dave Jones si pohrával s Trinity a bylo kvůli tomu nějaké to vzrůšo, ale Al je zpátky a už se snad virtuálně řítí na bílém koni, aby nás zachránil. Ale jinak to na tuto fázi -rc bylo dobré.

Stabilní aktualizace: během uplynulého týdne žádné nevyšly. V době psaní tohoto textu se revidovaly verze 3.8.3, 3.4.36 a 3.0.69; jejich vydání lze očekávat po 14. březnu.

Citáty týdne: Ben Bell, Linus Torvalds a tým Pax

Ještě důležitější je to, jestli má archivní jádro lepší zvuk než nějaké čerstvé. Trochu jsem to testoval a výsledky jsou jednoznačné, i když by neměly překvapit kohokoliv, kdo se aspoň trochu vyzná v nahrávání:

1. Starší jádra mají příjemnější zvuk než ta novější.
2. Jádra ručně kompilovaná na stroji, kde běží, nezní tak sterilně jako ta distribuční, která navíc mají mrzkou odezvu a špatné stereo.
3. Jen pro pořádek dodám, že gcc4 je naprostá katastrofa pro kvalitu zvuku. Nedělám si srandu, jestli chcete rozumný zvuk a používáte gcc4, tak už můžete rovnou nahrávat pomocí plechovky místo mikrofonu.

-- Ben Bell

Ale tohle je určitě další ze situací typu "Jsme naprosto v koncích. Pomoz nám, Al-biwane Ke-Vire, jsi mou jedinou nadějí."

Ale? Prosím, nenuť mě nosit ty zlaté bikiny.

-- Linus Torvalds

Každý linuxový vývojář se smysluplnými příspěvky v oblasti bezpečnosti Linuxu bude plně sponzorován týmem Pax. Tým LKSC zaměstnal strategicky rozmístěné vyhazovače s baseballkami, kteří budou zlepšovat budoucí debaty na LKML a bezpečnost linuxového jádra.

-- tým Pax

Overlayfs v 3.10

Systém souborů „overlayfs“ je jednou z implementací konceptu union filesystem, kde je dva nebo více systémů souborů kombinováno do jediného, virtuálního stromu. Na LWN se poprvé o overlayfs psalo v roce 2010; od té doby se těšilo pokračujícímu vývoji a dostalo se do jader od řady distribucí. Zatím se ale ještě nedostalo do hlavní řady.

Vývojář Miklos Szeredi nedávno požádal, jestli by připojený patch s implementací overlayfs nemohl být zařazen do vývojového cyklu verze 3.10. Už o to žádal dříve, ale tentokrát Linus odpověděl:

Ano, myslím si, že bychom do toho měli jít. Používá se to, je to docela malé a ostatní alternativy jsou horší. Pojďme naplánovat, jak to zapracujeme.

Na Linusovu žádost Al Viro souhlasil, že opět patche zreviduje, i když poznamenal, že s nimi dříve zrovna spokojený nebyl. Pokud se ale nevynoří něco závažného a neopravitelného, pak se overlayfs asi konečně dostane do jádra.

Volba SO_REUSEPORT u socketů

Jednou z funkcí začleněných do verze 3.9 byla podpora příznaku SO_REUSEPORT v TCP a UDP; tato podpora byla implementována sérií patchů od Toma Herberta. Tento nový příznak umožňuje, aby vícero soketů na stejném hostiteli naslouchalo na stejném portu; cílem je zlepšit výkon vícevláknových síťových aplikací na špičkových systémech s mnoha výpočetními jádry.

Základní koncept SO_REUSEPORT je jednoduchý. Vícero serverů (procesů nebo vláken) může použít bind na ten samý port, pokud každý z nich následujícím způsobem nastaví příznak:

int sfd = socket(domain, socktype, 0);

int optval = 1;
setsockopt(sfd, SOL_SOCKET, SO_REUSEPORT, &optval, sizeof(optval));

bind(sfd, (struct sockaddr *) &addr, addrlen);

Takže pokud první server tuto volbu nastaví před voláním bind, pak libovolný počet dalších serverů může použít ten samý port, pokud tuto volbu také nastaví. Důvodem pro požadavek na přítomnost příznaku u prvního serveru je to, aby nebylo možné krást porty – aby zlomyslná aplikace nemohla používat port pro odchycení (některých) příchozích spojení či datagramů. A aby nežádnoucí procesy nemohly udělat to samé v případě portů, kde první server SO_REUSEPORT použil, všechny následující servery musejí mít to samé efektivní UID jako první server.

SO_REUSEPORT se může používat u TCP i UDP socketů. U TCP socketů je možné, aby vícero naslouchacích socketů – obvykle v různých vláknech – poslouchalo na stejném portu. Každé vlákno pak může přijímat příchozí spojení pomocí volání accept(). Toto je alternativou ke tradičnímu přístupu, kde vícevlákenné servery přijímají příchozí spojení na jediném socketu.

Prvním z tradičních přístupů je mít jediné naslouchací vlákno, které přijímá všechna příchozí spojení a předává je ostatním vláknům pro zpracování. Problém je v tom, že ve extrémních případech může naslouchací vlákno představovat úzké hrdlo. V počátečních debatách o SO_REUSEPORT Tom uvedl, že pracuje s aplikacemi, které přijímají 40 000 spojení za sekundu. Vzhledem k tomuto číslu nepřekvapí, že pracuje pro Google.

Dalším z tradičních přístupů je to, že všechna vlákna (nebo procesy) používají volání accept() na jediném naslouchacím socketu v jednoduché smyčce:

while (1) {
	new_fd = accept(...);
	process_connection(new_fd);
}

Problémem při použití této techniky, jak Tom upozornil, je to, že když se více vláken sejde při volání accept(), probuzení nejsou spravedlivá, takže při vysoké zátěži mohou být příchozí spojení distribuována mezi vlákny značně nevyváženě. V Google zaznamenali trojnásobný rozdíl mezi vlákny, která obdržela nejvíce spojení a nejméně spojení; takové nevyvážení může vést k nedostatečnému využití jader procesoru. SO_REUSEPORT se liší v tom, že rozdává připojení mezi vlákny (nebo procesy) volajícími accept() rovnoměrně.

Stejně jako v případě TCP SO_REUSEPORT umožňuje, aby více UDP socketů poslouchalo na stejném portu. Tato schopnost se může hodit například u DNS serveru, který pracuje přes UDP. Díky SO_REUSEPORT může každé vlákno volat recv() na svém vlastním socketu, aby přijímalo datagramy. Tradičním přístupem je, že všechna vlákna volají recv() na jediném sdíleném socketu. Stejně jako v případě TCP toto může vést k nevyváženosti vytížení různých vláken. SO_REUSEPORT se liší v tom, že datagramy distribuuje rovnoměrně.

Tom poznamenal, že SO_REUSEADDR již umožňuje, aby více UDP socketů naslouchalo a přijímalo na stejném UDP portu. Rozdíl je v tom, že SO_REUSEADDR nebrání krádežím portů a nerozdává datagramy rovnoměrně.

Na Tomových patchích se najdou další zajímavosti. První z nich je jedna zajímavá stránka této implementace. Příchozí spojení a datagramy jsou socketům dodávány pomocí hashe založeného na čtveřici identifikátorů – těmi jsou IP adresa a port druhé strany a místní IP adresa a port. To znamená, že když klient použije ten samý socket pro odeslání série datagramů na serverový port, pak tyto datagramy všechny skončí u stejného naslouchacího socketu (dokud bude existovat). Toto zjednodušuje implementaci stavové komunikace mezi klientem a serverem.

Další zajímavostí je to, že současná implementace SO_REUSEPORT je postižena jistým defektem. Pokud se změní počet socketů naslouchajících na portu kvůli spouštění nových nebo ukončení existujících, je tu riziko toho, že příchozí spojení budou při uskutečňování třícestného handshaku přerušena. Problém je v tom, že příchozí požadavky na spojení jsou při příjmu prvního paketu SYN spojeny s konkrétním socketem. Pokud se počet naslouchajících socketů změní, pak se může přihodit, že logika v SO_REUSEADDR nenasměruje poslední ACK při handshaku na správný socket. V takovém případě bude spojení resetováno a na serveru zůstane osiřelá struktura s požadavkem. Na řešení problému se stále pracuje; může si to vyžádat implementaci tabulky požadavků o připojení, která by byla sdílena mezi vícero naslouchacími porty.

Volba SO_REUSEPORT je nestandardní, ale vyskytuje se v podobné formě na řadě jiných UNIXových systémů (hlavně na BSD, odkud pochází). Vypadá to jako užitečná alternativa při snaze vymačkat maximum ze síťových aplikací na vícejádrových systémech, proto půjde o zajímavou novinku pro některé vývojáře aplikací.

       

Komentáře

[Gilhad]

nanesměruje - nenasměruje

[Hue]

První citát napsal Ben Bell a ten od Torvaldse úplně chybí...

[Hue]

Tak ne, špatně přečteno, jen ten citát od Bena nemá u sebe jméno

[Luboš Doležel (Doli)]

Opraveno.

[mikro]

virtualne, virtualne... :)

[Luboš Doležel (Doli)]

Tenhle význam virtually samozřejmě znám, přesto mi přijde, že se v tomto kontextu myslelo to "virtuálně". Jinak mi tam to slovo prostě nesedí.

[Luboš Doležel (Doli)]

Jinak se Petr Krčmář v tom zápisku plete, což potvrzuje výkladový slovník. Virtually má skutečně i význam příslovce "virtuálně", kdežto virtual jen přídavného jména "virtuální".

[little.owl]

Ano, Krcmar to ma asi blbe.

Nicmene i u vas se ztracim.

Vyznamy jsou fakticky stejne, rozdil je jen, ze jedno je adverb (virtually) a druhe adjective (virtual) se vsim co to prinasi.

Nejcastejsi vyznam - almost, very nearly [the thing described]:

He virtually admitted that ...

The company has a virtual monopoly on ...

Computer Science:

... running Windows virtually on OS X ...

... virtual reality technology ...

Jde jen o kontext, necitim v tom jinak az tak rozdil ...

[little.owl]

Tak jsem se kouknul na puvodni mail a preklad neni skutecne optimalni, mikro ma pravdu.

Ja bych to spise prevypravel misto

... Al je zpátky a už se snad virtuálně řítí na bílém koni, aby nás zachránil.

treba takto:

... Al je zpátky a doufejme že se už téměř řítí na bílém koni, aby nás zachránil.

[Luboš Doležel (Doli)]

Tenhle vyznam ceskeho "temer" to nema. Je to blizsi slovu "practically" nez "almost".

[little.owl]

U prekladu se snazim prevypravet puvodni text v jinem jazyce, tak aby co nejvice vystihoval puvodni text, zejmena u metaforickych textu, v podstate uz neslovickarim, nema to smysl. Takze pokud by zalezelo jen na me, tak bych napsal neco jako:

... Al je zpátky a doufejme že už se obrazne řítí na bílém koni, aby nás zachránil.

a to by mi vyznamove sedelo nejvice; pokud nechapete 'temer' metaforicky, muzete mit pocit, ze je to spatne, protoze "virtually" je v tomto vyznamu spise protejsek 'literally'.

U vaseho puvodniho prekladu udelalo vice skody, ze jste vypustil "hopefully" a cokoliv z [temer | skoro | obrazne] by bylo lepsi nez "virtualne", nebot alespon mne to v tomto kontextu v cestine zni nejasne.

[Luboš Doležel (Doli)]

Místo hopefully tam je "snad" a virtuálně mi tam dává smysl, když se bavíme o někom, kdo se přiřítí jedině po síti...

[smazáno]

Imho to dava smysl v obou vyznamech, a ktery Linus myslel se muzete hadat donekonecna

[little.owl]

Místo hopefully tam je "snad"

To "hopefully" je tam hodne silne a vlastne to bylo prvni co me trklo, "snad" mi v danem kontextu nestaci, ale tyhle veci jsou o pocitech.

když se bavíme o někom, kdo se přiřítí jedině po síti...

To uz je hodne velke domysleni pribehu nad ramec toho co bylo receno. Co kdyz ma dotycny stado [bilych] koni?

V tomto uziti je "virtually" spise nez vyznamove slovo vyrazovy prostredek jak vyjadrit ze neco je metaforicky temer/skoro jako neco v tom jak to pusoby (effect), ale ne ve skutecnosti (fact); uvnitr schovaneho "almost/nearly" se u "virtually" zbavit temer nelze.

Snad (a nemyslim "doufejme" ) to bude takto viditelne v nasledujicich vetach:

There is virtually no air in the room.

He was there, staying back and listening to the conversation, virtually invisible.

V jinem jazyku pak staci najit vyrazovy prostredek ci slovo, ktere vyjadri totez aniz byste se s primym prekladem slova "virtually" vubec trapil.

[smazáno]

Snad (a nemyslim "doufejme" ) to bude takto viditelne v nasledujicich vetach:

There is virtually no air in the room.

He was there, staying back and listening to the conversation, virtually invisible.

Hele, on tohle Lubos chape. Tyhle vety jsou dost jednoznacne, ale co takhle treba "virtually driving a car". Kdyz si to das do google, tak na tebe vypadnout vety jako "I don't see any point in arcade racers, what's the point of virtually driving a car around a track ...."

Ale naprosto chapu, ze kdyz zijes v Anglii, tak ten vyznam, ktery by se dal do cestine prelozit jako "vlastne/temer", je pro tebe asi tak 100x silnejsi .

PS: Lubose se tady zastavam i presto ze mu obcast napisu drsny komentar pod preklady XKCD

[little.owl]

Tyhle vety jsou dost jednoznacne,

Ja jsem je umyslne tvoril tak aby byly a zaroven ilustrovaly co mam na mysli, nechtel jsem to zbytecne zamlzovat, coz by jiste slo.

ale co takhle treba "virtually driving a car".

Zalezi na kontextu. Pokud se nebavime o nejakych simulacich - jako i v pripade zminenych arcade racers, bude tu "virtually" nejspis v mineni "practically", coz je ve vetsine pripadu synonymum a jen je tam slaby nadech smerem k "really"; u simulaci to bude spise zminene "in effect even if not in fact".

Ale naprosto chapu, ze kdyz zijes v Anglii, tak ten vyznam, ktery by se dal do cestine prelozit jako "vlastne/temer", je pro tebe asi tak 100x silnejsi .

Clovek se casem v souvislosti mezi reci a konkretnim konanim nauci vice rozlisovat detaily a niance; vydeseny/zmateny/nejisty vyraz posluchace rekne vice nez slovnik.

PS: Lubose se tady zastavam i presto ze mu obcast napisu drsny komentar pod preklady XKCD

Preklady ma dobre, i kdyz taky kolem toho "virtually" v prekladu zbytecne tancuje. Ja naopak normalne do takovych veci vlastne vubec nerypu, ale to zduvodneni nahore me postrcilo.

[pavlix]

+1