Procházel jsem online příručku Apache httpd a narazil jsem na směrnici, která to umožňuje. Našli jsme popis v manuálové stránce pro tcp :
TCP_DEFER_ACCEPT (since Linux 2.4)
Allow a listener to be awakened only when data arrives on the
socket. Takes an integer value (seconds), this can bound the
maximum number of attempts TCP will make to complete the
connection. This option should not be used in code intended
to be portable.
Pak jsem našel tento článek, ale stále mi není jasné, pro jaký druh zátěže by to bylo užitečné. Předpokládám, že pokud httpd má možnost speciálně pro toto, musí mít určitou relevanci pro webové servery. Vycházím také z toho, že je to možnost a nejen jak httpd připojení k síti, že existují případy použití, kdy to chcete, a jiné, kde nechcete.
I po přečtení článku mi není jasné, jaká by byla výhoda čekání na dokončení třícestného podání ruky. Zdá se být výhodné zajistit, aby nebylo nutné zaměňovat relevantní httpd například tím, že tak učiníte v době, kdy handshake stále probíhá, namísto potenciálního způsobení zpoždění po vytvoření spojení.
U článku by se mi také zdálo, že bez ohledu na TCP_DEFER_ACCEPT stavu zásuvky, stále budete potřebovat čtyři pakety (v každém případě handshake a pak data). Nevím, jak dokážou snížit počet na tři, ani jak to poskytuje smysluplné vylepšení.
Moje otázka tedy v zásadě zní:Je to jen stará zastaralá možnost nebo existuje skutečný případ použití této možnosti?
Přijatá odpověď:
(abych shrnul své komentáře k OP)
Třícestný handshake, na který odkazují, je součástí navázání TCP spojení, dotyčná možnost se toho konkrétně netýká. Všimněte si také, že výměna dat není součástí třícestného handshake, pouze vytváří TCP spojení v otevřeném/ustaveném stavu.
Pokud jde o existenci této možnosti, nejedná se o tradiční chování soketu, normálně se vlákno obslužného programu soketu probudí, když je spojení přijato (což je stále po dokončení třícestného handshake) a pro některé protokoly začíná činnost zde ( např. SMTP server odešle uvítací řádek 220), ale pro HTTP je první zprávou v konverzaci webový prohlížeč, který odešle svůj řádek GET/POST/atd., a dokud se tak nestane, HTTP server nemá o připojení žádný zájem (kromě načasování). to out), takže probuzení procesu HTTP po dokončení přijetí soketu je plýtvání činností, protože proces okamžitě znovu usne a čeká na potřebná data.
I když jistě existuje argument, že probuzení nečinných procesů je může připravit k dalšímu zpracování (konkrétně si pamatuji, že jsem probudil přihlašovací terminály na velmi starých počítačích a nechal je zapojit z výměny), ale můžete také namítnout, že jakýkoli počítač, který má swap out zmíněný proces již klade požadavky na své zdroje a vytváření dalších zbytečných požadavků může celkově snížit výkon systému – i když se zdánlivý výkon vašeho jednotlivého vlákna zlepší (což také nemusí, extrémně vytížený stroj by měl úzká hrdla na IO disku, která by zpomalte ostatní věci, pokud jste se přehodili, a pokud je to tak zaneprázdněné, okamžitý spánek to může okamžitě vyměnit). Zdá se, že jde o hazard a nakonec se „chamtivý“ hazard nemusí nutně vyplatit na vytíženém stroji a určitě způsobuje zbytečnou práci navíc na stroji, který již měl proces zaměněný – váš přístup je optimalizován pro stroj s velká paměťová sada procesů, které jsou většinou nečinné, a výměna jedné nečinnosti za jinou není žádný velký problém, nicméně počítač s velkou sadou paměti aktivních procesů bude trpět extra IO a každý počítač, který nemá omezenou paměť, trpí, jakýkoli počítač vázaný na CPU na tom bude hůř.
Související:Linux – Proč rsync na Linuxu nezachovává všechna časová razítka (čas vytvoření)?Moje obecná rada ohledně této úrovně ladění výkonu by byla nedělat programatická rozhodnutí o tom, co je nejlepší, ale umožnit správci systému a operačnímu systému spolupracovat při řešení problémů správy zdrojů – to je jejich práce a oni lépe se hodí k pochopení pracovní zátěže celého systému i mimo něj. Poskytněte možnosti a možnosti konfigurace.
Abychom konkrétně odpověděli na otázku, tato možnost je výhodná ve všech konfiguracích, ne na úrovni, kterou byste si pravděpodobně všimli, s výjimkou extrémního zatížení HTTP provozem, ale teoreticky je to „správný“ způsob, jak to udělat. Je to možnost, protože ne všechny varianty Unixu (dokonce ani všechny Linux) tuto schopnost mají, a proto může být pro přenositelnost konfigurována tak, aby nebyla zahrnuta.