![\"Eine](\"https:\/\/www.lukaswojcik.com\/blog\/wp-content\/uploads\/diagrams\/umschaltaugenblick-de.png\")
Warum jede Verbindung stirbt<\/h2>\n
Eine TCP-Verbindung wird \u00fcber vier Werte bezeichnet: beide Adressen und beide Ports. Verkehr, der \u00fcber WAN1 hinausgeht, tr\u00e4gt die \u00f6ffentliche Adresse von WAN1, und der Server auf der anderen Seite hat diese Adresse in seiner H\u00e4lfte der Verbindung stehen.<\/p>\n
Nach der Umschaltung geht derselbe Verkehr \u00fcber WAN2 hinaus und kommt mit einer anderen Absenderadresse an. F\u00fcr den Server ist das nicht dieselbe Verbindung – es sind Pakete, die zu nichts geh\u00f6ren, und die bekommen ein R\u00fccksetzen oder werden verworfen. Der Router kann nicht helfen: Der \u00dcbersetzungszustand, der die innere Verbindung auf die Adresse von WAN1 abbildete, geh\u00f6rt zu einer Schnittstelle, die unten ist.<\/p>\n
Deshalb ist der zu vermeidende Ausdruck bei Ger\u00e4ten dieser Klasse nahtlose Ausfallsicherung<\/em>. Nahtlos ist die Verf\u00fcgbarkeit eines Weges. Sitzungen werden nicht dar\u00fcber getragen, und daran \u00e4ndert keine Zeiteinstellung etwas.<\/p>\n Der sichtbare Teil ist die Rechnung der Gesundheitspr\u00fcfung – das Intervall mal der Zahl geduldeter Fehlversuche. Der unsichtbare Teil kommt davor: Die Leitung kann fast ein ganzes Intervall lang tot sein, bevor die erste Pr\u00fcfung es \u00fcberhaupt bemerkt, denn die eben noch gelungene Pr\u00fcfung lief einen Moment vor dem Ausfall.<\/p>\n Die letzte Zeile entscheidet dar\u00fcber, was ein Mensch erlebt. Der Router ist nach f\u00fcnfzehn Sekunden zur\u00fcck; ein Download, der noch nicht gemerkt hat, dass seine Verbindung tot ist, sitzt erheblich l\u00e4nger in einer \u00dcbertragungswiederholung, und ein Browserreiter sieht die ganze Zeit eingefroren aus.<\/p>\n Die QUIC-Zeile ist die echte Ausnahme und lohnt sich zu kennen, weil sie still zum Regelfall wird: Eine Verbindungskennung, die nicht an der Adresse h\u00e4ngt, ist genau die Eigenschaft, die einen Wegwechsel \u00fcberstehbar macht – und beide Seiten m\u00fcssen sie unterst\u00fctzen.<\/p>\n Die VPN-Zeile weist auf die eine Anordnung hin, die in der Praxis hilft. Ein Tunnel, der sich selbst neu aufbaut, macht aus einer Umschaltung eine Neuverbindung, und alles innerhalb des Tunnels sieht eine kurze Pause statt einer toten Verbindung – denn innerhalb des Tunnels haben sich die Adressen nie ge\u00e4ndert.<\/p>\n Der Wechsel zur\u00fcck auf die Hauptleitung ist eine zweite Umschaltung, mit einer zweiten Runde toter Sitzungen. Das ist der Grund, warum die beiden Zeiten nicht symmetrisch sein sollten: schnell umschalten begrenzt den Ausfall, langsam zur\u00fcckschalten vermeidet, den Preis zweimal f\u00fcr eine Leitung zu zahlen, die noch nicht stabil ist.<\/p>\n Eine flatternde Leitung mit gleichen Zeiten ist der schlimmste Fall des ganzen Themas. Jedes Flattern kostet zwei Runden zerrissener Sitzungen, und eine Leitung, die alle paar Minuten flattert, ist sp\u00fcrbar schlechter als eine, die schlicht weg ist – denn eine weggefallene schaltet einmal um und bleibt dann liegen.<\/p>\n Am Router wenig, und das geh\u00f6rt klar gesagt, statt an Einstellungen zu drehen in der Hoffnung, eine davon sei der Trick. Drei Dinge helfen.<\/p>\n Verschiedene Pr\u00fcfziele auf den beiden Anschl\u00fcssen, damit eine St\u00f6rung des Ziels nicht als Ausfall beider Leitungen missverstanden wird. Eine R\u00fcckschaltzeit, die ein Mehrfaches der Umschaltzeit betr\u00e4gt, damit Flattern eine Umschaltung kostet statt zehn. Und f\u00fcr alles, was wirklich nicht abrei\u00dfen darf, ein Tunnel, der den Wegwechsel \u00fcbersteht und die Sitzungen in sich tr\u00e4gt.<\/p>\n Dar\u00fcber hinaus besteht die ehrliche Haltung darin, mit der Unterbrechung zu planen statt sie zu bestreiten: zu wissen, dass die Gespr\u00e4che abrei\u00dfen, dass die Sicherung von vorn beginnt und dass die f\u00fcnfzehn Sekunden in der Einstellung die kleinere H\u00e4lfte dessen sind, was der Ausfall tats\u00e4chlich kostet.<\/p>\nWie lange die Umschaltung tats\u00e4chlich dauert<\/h2>\n
schlimmster Fall = Intervall × (Fehlversuche + 1)\nüblich = Intervall × (Fehlversuche + 0,5)\n\nIntervall 5 s, 3 Fehlversuche\n bester Fall 15 s\n üblich 17,5 s\n schlimmster 20 s\n\ndazu die Zeit, die Anwendungen brauchen, um den Verlust zu bemerken -\nbei einer TCP-Zeitüberschreitung weit mehr als alles Obige<\/code><\/pre>\nWas \u00fcbersteht und was nicht<\/h2>\n
\n\n
\n \nVerkehr<\/th>\n \u00dcbersteht es?<\/th>\n Warum<\/th>\n<\/tr>\n<\/thead>\n \n SSH, Datenbankverbindungen<\/td>\n nein<\/td>\n langlebiges TCP, an das Adresspaar gebunden<\/td>\n<\/tr>\n \n Downloads \u00fcber HTTP\/1.1 und HTTP\/2<\/td>\n nein<\/td>\n TCP; beginnt ohne Bereichsanfragen von vorn<\/td>\n<\/tr>\n \n HTTP\/3 (QUIC)<\/td>\n oft<\/td>\n eine Verbindungskennung bezeichnet die Sitzung, nicht die Adresse<\/td>\n<\/tr>\n \n Ein laufendes Gespr\u00e4ch<\/td>\n nein<\/td>\n der Medienstrom ist an die alte \u00f6ffentliche Adresse gerichtet<\/td>\n<\/tr>\n \n DNS-Abfragen<\/td>\n ja<\/td>\n einzelne Pakete, die ohnehin wiederholt werden<\/td>\n<\/tr>\n \n Ein VPN-Tunnel<\/td>\n kurz weg<\/td>\n bemerkt es und baut sich neu auf, samt der Sitzungen darin<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Die R\u00fcckschaltung kostet dasselbe noch einmal<\/h2>\n
Was sich dagegen tun l\u00e4sst<\/h2>\n