![\"O\u015b](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/umschaltaugenblick-pl.png\")
Dlaczego ginie ka\u017cde po\u0142\u0105czenie<\/h2>\n
Po\u0142\u0105czenie TCP oznacza si\u0119 czterema warto\u015bciami: obydwoma adresami i obydwoma portami. Ruch wychodz\u0105cy przez WAN1 niesie publiczny adres WAN1, a serwer po drugiej stronie ma ten adres w swojej po\u0142owie po\u0142\u0105czenia.<\/p>\n
Po prze\u0142\u0105czeniu ten sam ruch wychodzi przez WAN2 i przybywa z innym adresem \u017ar\u00f3d\u0142owym. Dla serwera to nie jest to samo po\u0142\u0105czenie – to pakiety nienale\u017c\u0105ce do niczego, kt\u00f3re dostaj\u0105 zresetowanie albo zostaj\u0105 odrzucone. Router nie mo\u017ce pom\u00f3c: stan translacji odwzorowuj\u0105cy po\u0142\u0105czenie wewn\u0119trzne na adres WAN1 nale\u017cy do interfejsu, kt\u00f3ry jest wy\u0142\u0105czony.<\/p>\n
Dlatego wyra\u017ceniem, kt\u00f3rego przy sprz\u0119cie tej klasy nale\u017cy unika\u0107, jest bezszwowe prze\u0142\u0105czanie<\/em>. Bezszwowa jest dost\u0119pno\u015b\u0107 drogi. Sesje nie s\u0105 po niej przenoszone i nie zmienia tego \u017cadne ustawienie czasu.<\/p>\n Cz\u0119\u015bci\u0105 widoczn\u0105 jest rachunek sprawdzania – interwa\u0142 razy liczba tolerowanych niepowodze\u0144. Cz\u0119\u015b\u0107 niewidoczna przychodzi przed tym: \u0142\u0105cze mo\u017ce by\u0107 martwe przez niemal ca\u0142y interwa\u0142, zanim pierwsze sprawdzenie w og\u00f3le to zauwa\u017cy, bo sprawdzenie, kt\u00f3re przed chwil\u0105 si\u0119 powiod\u0142o, przebieg\u0142o moment przed awari\u0105.<\/p>\n Ostatni wiersz rozstrzyga o tym, czego do\u015bwiadcza cz\u0142owiek. Router wraca po pi\u0119tnastu sekundach; pobieranie, kt\u00f3re jeszcze nie zauwa\u017cy\u0142o, \u017ce jego po\u0142\u0105czenie jest martwe, siedzi w powt\u00f3rzeniu transmisji znacznie d\u0142u\u017cej, a karta przegl\u0105darki przez ca\u0142y ten czas wygl\u0105da na zamro\u017con\u0105.<\/p>\n Wiersz o QUIC jest prawdziwym wyj\u0105tkiem i warto go zna\u0107, bo po cichu staje si\u0119 regu\u0142\u0105: identyfikator po\u0142\u0105czenia niezale\u017cny od adresu to dok\u0142adnie ta w\u0142asno\u015b\u0107, kt\u00f3ra czyni zmian\u0119 drogi mo\u017cliw\u0105 do przetrwania – a obie strony musz\u0105 j\u0105 obs\u0142ugiwa\u0107.<\/p>\n Wiersz o VPN wskazuje jedyny uk\u0142ad, kt\u00f3ry w praktyce pomaga. Tunel odbudowuj\u0105cy si\u0119 samodzielnie zamienia jedno prze\u0142\u0105czenie w jedno ponowne po\u0142\u0105czenie, a wszystko wewn\u0105trz tunelu widzi kr\u00f3tk\u0105 przerw\u0119 zamiast martwego po\u0142\u0105czenia – bo wewn\u0105trz tunelu adresy nigdy si\u0119 nie zmieni\u0142y.<\/p>\n Przej\u015bcie z powrotem na \u0142\u0105cze g\u0142\u00f3wne jest drugim prze\u0142\u0105czeniem, z drug\u0105 rund\u0105 martwych sesji. To pow\u00f3d, dla kt\u00f3rego oba czasy nie powinny by\u0107 symetryczne: szybko prze\u0142\u0105czy\u0107 ogranicza awari\u0119, wolno wr\u00f3ci\u0107 pozwala unikn\u0105\u0107 p\u0142acenia ceny dwukrotnie za \u0142\u0105cze, kt\u00f3re nie jest jeszcze stabilne.<\/p>\n Trzepocz\u0105ce \u0142\u0105cze z r\u00f3wnymi czasami to najgorszy przypadek ca\u0142ego tematu. Ka\u017cde trzepni\u0119cie kosztuje dwie rundy zerwanych sesji, a \u0142\u0105cze trzepocz\u0105ce co kilka minut jest odczuwalnie gorsze ni\u017c takie, kt\u00f3rego po prostu nie ma – bo to, kt\u00f3rego nie ma, prze\u0142\u0105cza raz i potem zostaje.<\/p>\n Na routerze niewiele, i to nale\u017cy powiedzie\u0107 wprost, zamiast kr\u0119ci\u0107 ustawieniami w nadziei, \u017ce kt\u00f3re\u015b z nich jest sztuczk\u0105. Pomagaj\u0105 trzy rzeczy.<\/p>\n R\u00f3\u017cne cele sprawdzania na obu \u0142\u0105czach, \u017ceby awaria celu nie zosta\u0142a wzi\u0119ta za awari\u0119 obu linii. Czas powrotu b\u0119d\u0105cy wielokrotno\u015bci\u0105 czasu prze\u0142\u0105czenia, \u017ceby trzepotanie kosztowa\u0142o jedno prze\u0142\u0105czenie zamiast dziesi\u0119ciu. I dla wszystkiego, co naprawd\u0119 nie mo\u017ce si\u0119 zerwa\u0107, tunel przetrwaj\u0105cy zmian\u0119 drogi i nios\u0105cy sesje w sobie.<\/p>\n Poza tym uczciw\u0105 postaw\u0105 jest planowanie z przerw\u0105, a nie zaprzeczanie jej: wiedzie\u0107, \u017ce rozmowy si\u0119 urw\u0105, \u017ce kopia zacznie od nowa i \u017ce pi\u0119tna\u015bcie sekund z ustawie\u0144 jest mniejsz\u0105 po\u0142ow\u0105 tego, co awaria faktycznie kosztuje.<\/p>\nIle prze\u0142\u0105czenie naprawd\u0119 trwa<\/h2>\n
najgorszy przypadek = interwał × (niepowodzenia + 1)\ntypowo = interwał × (niepowodzenia + 0,5)\n\ninterwał 5 s, 3 niepowodzenia\n najlepiej 15 s\n typowo 17,5 s\n najgorzej 20 s\n\ndo tego czas, którego aplikacje potrzebują, by zauważyć stratę -\nprzy przekroczeniu czasu TCP znacznie więcej niż wszystko powyżej<\/code><\/pre>\nCo przetrwa, a co nie<\/h2>\n
\n\n
\n \nRuch<\/th>\n Przetrwa?<\/th>\n Dlaczego<\/th>\n<\/tr>\n<\/thead>\n \n SSH, po\u0142\u0105czenia z baz\u0105<\/td>\n nie<\/td>\n d\u0142ugowieczne TCP, zwi\u0105zane z par\u0105 adres\u00f3w<\/td>\n<\/tr>\n \n Pobierania po HTTP\/1.1 i HTTP\/2<\/td>\n nie<\/td>\n TCP; bez \u017c\u0105da\u0144 zakresu zaczyna od pocz\u0105tku<\/td>\n<\/tr>\n \n HTTP\/3 (QUIC)<\/td>\n cz\u0119sto<\/td>\n identyfikator po\u0142\u0105czenia oznacza sesj\u0119, a nie adres<\/td>\n<\/tr>\n \n Trwaj\u0105ca rozmowa<\/td>\n nie<\/td>\n strumie\u0144 medi\u00f3w kierowany jest na stary adres publiczny<\/td>\n<\/tr>\n \n Zapytania DNS<\/td>\n tak<\/td>\n pojedyncze pakiety, i tak powtarzane<\/td>\n<\/tr>\n \n Tunel VPN<\/td>\n na chwil\u0119 znika<\/td>\n zauwa\u017ca i buduje si\u0119 od nowa, wraz z sesjami w \u015brodku<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Powr\u00f3t kosztuje to samo jeszcze raz<\/h2>\n
Co da si\u0119 z tym zrobi\u0107<\/h2>\n