> To ve světě protokolu TCP znamená, že dojde k přerušení příslušného TCP sezení. To nijak zásadně nevadí u valné většiny webových aplikací.
Naopak já mám zkušenost že když Firefoxu přestanou téct pakety z cíle na který má otevřené keep-alive spojení, tak čeká a čeká a čeká a nejde s tím nic moc dělat (pomůže změnit nastavení proxy tam a zpět a možná smazat cache). Možná by pomohlo poslat mu RST. Nejspíš podvržený, když ten původní NAT zhebnul.
U "Active-StandBy CGN" je aktivní jen 1 CGN, takže tam žádná škálovatelnost/distribuce zátěže není.
Pokud zařízení zvládá dostatečně rychle synchronizovat tabulku NAT tak, aby se dalo provozovat v režimu Active-Active, tak je obecně pro synchronizaci možné využít multicast a padne naopak to omezení na 2 CGN...
Shrunuto: ten řádek o škálovatelnosti ve shrunující tabulce je zavádějící.
U velkých instalaci "pokud stihne synchronizovat" není zrovna vhodný výraz. A zvlášť u velkých instalaci bez zchromnuti velké části spojení to nemusíš stihnout. Ta synchronizace není zas až takový akademický konstrukt. Tak to funguje vevnitř v zařízeních s redundantnimi komponenty. Tam se to dá stíhat neboť architektura umožňuje paralelní přístupy do paměti modulu a navíc na backplane jsou jiné prodlevy a jiné šířky pasma:) Nicmene i velké skatule se umí zblaznit...
Když jsem si tak četl článek, tak jsem začal nabývat pocitu, ze přestávám po první třetině rozumět textu. Spousta slov a málo informací.
Autor je evidentně technický velmi fundovaný, ale k podávání informací by měl přistupovat spíše popularizační formou a nikoli na informace rozpliznout jak v nějaké práci z vysoké školy.
Článek má precijen mít jinou formu. Zvlášť když na něj není evidentně tolik mista.
Ale berte mne s rezervou. Občas musím instruovat mladší kolegy ze v businessu neplatí - více to rozepiste pane kolego.
ČLÁNKY DO MAILU