expertenaustausch > comm.* > comm.protocols.tcp-ip

Autist (28.01.2020, 11:41)
So isses !
Juergen Ilse (28.01.2020, 12:25)
Autist <autist69> wrote:
> So isses !


Warum sollte man so einen Unsinn tun und etablierte Protokolle dadurch
inkompatibel modifizieren?

Tschuess,
Juergen Ilse (juergen)
Autist (28.01.2020, 12:28)
>> So isses !

> Warum sollte man so einen Unsinn tun und etablierte Protokolle dadurch
> inkompatibel modifizieren?


Weil QUIC effizienter ist.
Kay Martinen (28.01.2020, 12:52)
Am 28.01.20 um 11:28 schrieb Autist:
>>> So isses !

>> Warum sollte man so einen Unsinn tun und etablierte Protokolle dadurch
>> inkompatibel modifizieren?

> Weil QUIC effizienter ist.


bLötzinn!

Lt. ist das
ein Versuch http(s) schneller zu machen indem man statt TCP dann UDP
einsetzt, was aber immer noch auf dem IP-Protokoll aufsetzen müßte. Und
damit dessen Beschränkungen unterliegt.

Da denke ich mir: Man könnte den gleichen oder besseren Tempogewinn
erzielen wenn man nur auf ein paar andere Dinge verzichten würde. Z.b.
tonnenweise scripte in Seiten die wieder andere scripte und bilder von
anderen seiten nachladen - alles nur um die Seitenbesucher zu tracken,
ihnen werbung, malware oder spionagetools unter zu jubeln. U.s.w. u.s.f.

DAS sind dinge die die Welt nicht braucht! Dann braucht man auch kein
Schnelleres Protokoll für das Deppen-Netz! Dann IST es schneller!

Außerdem bin ich sicher das der mögliche Tempogewinn dieses
"Schnelleren" Protokolls gleich wieder aufgefressen wird dadurch das
irgend ein Honk auf die Idee kommt "Hey, wenn es jetzt schneller geht,
dann können wir noch mehr Werbung pro Sekunde ausliefern"

Und den "Mehr Privatsphäre"-Ansatz (durch Header-verschlüsselung,
Metadaten-minimierung) darin wird mit an Sicherheit grenzender
Wahrscheinlichkeit irgendwann irgend jemand auch wieder ausgehebelt
bekommen.

Fazit: Besser gleich sein lassen und den richtigen Weg gehen (Verbot von
Excessivem Site-overload). Ein neues Protokoll; noch dazu von Google;
braucht kein Mensch. Punkt!

Kay
Marc Haber (28.01.2020, 14:21)
Autist <autist69> wrote:
>So isses !


Abgesehen davon, dass Du ein Troll bist, ist ein Mischbetrieb
selbstverständlich möglich.

Der Impact wird also nur positiv sein.

Grüße
Marc
Autist (28.01.2020, 14:35)
> Lt. ist das
> ein Versuch http(s) schneller zu machen indem man statt TCP dann UDP
> einsetzt, was aber immer noch auf dem IP-Protokoll aufsetzen müßte. Und
> damit dessen Beschränkungen unterliegt.


Man hat
1. Verschlüsselungs-Aushandelung im Handshake.
2. Datenaustausch ggf. im Handshake.
3. Multiplexing.
4. Bessere Fluss- und Stau-Kontrolle.
Das bietet alles TCP nicht.
Kay Martinen (28.01.2020, 14:38)
Am 28.01.20 um 13:21 schrieb Marc Haber:
> Autist <autist69> wrote:
>> So isses !

> Abgesehen davon, dass Du ein Troll bist, ist ein Mischbetrieb
> selbstverständlich möglich.
> Der Impact wird also nur positiv sein.


Brauchst du ssh@quic? Zum schneller auf die Ausgabe warten. :-)

TCP durch UDP-Spezial zu ersetzen ist ja nicht allgemein Sinnvoll. Oder
wie meintest du Mischbetrieb?

Kay
Autist (28.01.2020, 14:38)
> Abgesehen davon, dass Du ein Troll bist, ist ein Mischbetrieb
> selbstverständlich möglich.


Logisch, aber es ist vorstellbar, dass QUIC auch mal in den Kernel
wandert und nach und nach TCP größtenteils ersetzt. Bzgl. HTTP wird
es schon recht bald so sein, dass fast nur noch HTTP/3 und somit
QUIC gesprochen wird. TCP wird dann irgendwann zum Legacy-Protokoll
das man für Dinge verwendet wo dieses Finetuning nicht not tut.
Juergen Ilse (28.01.2020, 15:26)
Hallo,

Autist <autist69> wrote:
>> Lt. ist das
>> ein Versuch http(s) schneller zu machen indem man statt TCP dann UDP
>> einsetzt, was aber immer noch auf dem IP-Protokoll aufsetzen müßte. Und
>> damit dessen Beschränkungen unterliegt.


IP ist nicht nur "WWW", aber das begreifen anscheinend manche Idioten nicht.

> Man hat
> 1. Verschlüsselungs-Aushandelung im Handshake.
> 2. Datenaustausch ggf. im Handshake.
> 3. Multiplexing.
> 4. Bessere Fluss- und Stau-Kontrolle.


Ob es wirklich "bessere Fluss- und staukontrolle" ist, haengt vom konkreten
Anwendungsfall ab. Fuer typischen Webserver-Verkehr mag das moeglicherweise
sogar zutreffen, aber das ist bei weitem nicht die einzige Anwendung fuer TCP.
Multiplexing benoetigt man fuer viele Anwendungen von TCP nicht. Und nicht
zu vergessen: QUIC ist noch nicht einmal fertig spezifiziert, es hat kaum
Draft erreicht und ist vopn Standard noch weit entfernt, noch nicht einmal
"BCP" ist mit QUIC bisher erreicht, und last but not least: viele Browser
unterstuetzen es noch nicht, und ob Webserver-Betreiber die Nutzer solcher
Browser wirklich als Kunden ausschliessen wollen?

> Das bietet alles TCP nicht.


Dafuer ist TCP das bei weitem simpler zu implementierende Prtokoll, und z.B.
im embedded Bereich wird man aus unter anderem disem Grund wohl in sehr wei-
ten Teilen niemals auf QUIC wechseln ...

Mit anderen Worten: die reisserische Ueberschrift zeugt von halbverstandenem
Viertelwissen bei der Person, die hier grossspurig eine solche Ueberschrift
geschrieben hat (zumindest meiner Ansicht nach).

Tschuess,
Juergen Ilse (juergen)
Juergen Ilse (28.01.2020, 15:28)
Hallo,

Kay Martinen <kay> wrote:
> Am 28.01.20 um 13:21 schrieb Marc Haber:
> Brauchst du ssh@quic? Zum schneller auf die Ausgabe warten. :-)
> TCP durch UDP-Spezial zu ersetzen ist ja nicht allgemein Sinnvoll. Oder
> wie meintest du Mischbetrieb?


Ich denke, er meinte "bei Webservern" (und in anderen Bereichen wird QUIC
wohl TCP auch kaum verdraengen).

Tschuess,
Juergen Ilse (juergen@usenet-verwalötung.de)
Juergen Ilse (28.01.2020, 15:38)
Hallo,

Autist <autist69> wrote:
>> Abgesehen davon, dass Du ein Troll bist, ist ein Mischbetrieb
>> selbstverständlich möglich.

> Logisch, aber es ist vorstellbar, dass QUIC auch mal in den Kernel
> wandert


Wozu? Und vor allem: in *welchen* Kernel? Linux? FreeBSD? Windows? Solaris?
NetBSD? OpenBSD? QNX? L4? ...

> und nach und nach TCP größtenteils ersetzt.


Es gibt noch immer genuegend Anwendungsfaelle, wo QUIC gegenueber TCP nur
hoehere Komplexitaet, ggfs. mehr Angreifbarkeit und keinerlei Vorteile bietet.
Warum sollte man z.B. den Austausch von Routing-Informationen ueber BGP per
QUIC statt per TCP machen wollen?

> Bzgl. HTTP wird es schon recht bald so sein, dass fast nur noch HTTP/3


Dann wird "sehr bald" wohl noch mindestens 20 Jahre dauern. Bisher sind
meines Wissens nach noch keine "HTTP3 only" Webseiten im Netz zu finden.
Eher wird IPv6 IPv4 komplett ersetzt haben, ehe QUIC im Bereich der Web-
serverkommunikation TCP komplett ersetzt haben koennte ... Und ich bin
mir nicht sicher, ob ich das sterben von IPv4 noch erleben werde ...
Wieviele FTP-Server gibt es noch, obwohl FTP eigentlich schon seit mehr
als 25 Jahren "legacy" ist und gegenueber neueren Protokollen zum File-
transfer nur Nachteile bietet? Warum ist noch immer FTP in jeder NAT-
Implementierung als Sonderfall beruecksichtigt?

Tschuess,
Juergen Ilse (juergen)
Autist (28.01.2020, 15:40)
>>> Lt. ist das
>>> ein Versuch http(s) schneller zu machen indem man statt TCP dann UDP
>>> einsetzt, was aber immer noch auf dem IP-Protokoll aufsetzen müßte. Und
>>> damit dessen Beschränkungen unterliegt.


> IP ist nicht nur "WWW", aber das begreifen anscheinend manche Idioten nicht.


Doch, das begreife ich. Aber WWW ist wohl das einzige wo die Optimierun-
gen von QUICK wirklich was bringen. Und bzgl. des Anteils des Internet
-Traffics kommt nach HTTP erstmal lange Zeit gar nichts.

>> Man hat
>> 1. Verschlüsselungs-Aushandelung im Handshake.
>> 2. Datenaustausch ggf. im Handshake.
>> 3. Multiplexing.
>> 4. Bessere Fluss- und Stau-Kontrolle.


> Ob es wirklich "bessere Fluss- und staukontrolle" ist, haengt vom konkreten
> Anwendungsfall ab. Fuer typischen Webserver-Verkehr mag das moeglicherweise
> sogar zutreffen, aber das ist bei weitem nicht die einzige Anwendung fuer TCP.
> Multiplexing benoetigt man fuer viele Anwendungen von TCP nicht. Und nicht
> zu vergessen: QUIC ist noch nicht einmal fertig spezifiziert, es hat kaum
> Draft erreicht und ist vopn Standard noch weit entfernt, noch nicht einmal
> "BCP" ist mit QUIC bisher erreicht, und last but not least: viele Browser
> unterstuetzen es noch nicht, und ob Webserver-Betreiber die Nutzer solcher
> Browser wirklich als Kunden ausschliessen wollen?


Am Draft wird sich kaum noch was ändern, denn es gibt schon unzählige
Implementationen.

> Dafuer ist TCP das bei weitem simpler zu implementierende Prtokoll, und z.B.
> im embedded Bereich wird man aus unter anderem disem Grund wohl in sehr wei-
> ten Teilen niemals auf QUIC wechseln ...


Logisch, da tun die Features von QUIC auch nicht not.
Autist (28.01.2020, 15:43)
>>> Abgesehen davon, dass Du ein Troll bist, ist ein Mischbetrieb
>>> selbstverständlich möglich.

>> Logisch, aber es ist vorstellbar, dass QUIC auch mal in den Kernel
>> wandert


> Wozu? Und vor allem: in *welchen* Kernel? Linux? FreeBSD? Windows? Solaris?
> NetBSD? OpenBSD? QNX? L4? ...


Naja, wenn es in Linux und Windows drin ist können die anderen wohl
nicht umhin, da mitzumachen.

> Es gibt noch immer genuegend Anwendungsfaelle, wo QUIC gegenueber TCP nur
> hoehere Komplexitaet, ggfs. mehr Angreifbarkeit und keinerlei Vorteile bietet.
> Warum sollte man z.B. den Austausch von Routing-Informationen ueber BGP per
> QUIC statt per TCP machen wollen?


Logisch ist das da nicht nötig.

> Dann wird "sehr bald" wohl noch mindestens 20 Jahre dauern. Bisher sind
> meines Wissens nach noch keine "HTTP3 only" Webseiten im Netz zu finden.


Das wird recht schnell gehen, denn in den Browsern kommt es durch die
Updates und die Webserver werden auch von Zeit zu Zeit ge-updatet wer-
den. Da gibt's kaum was anzupassen, weswegen das sicher um Größenord-
nungen schneller ausgerollt wird als IPv6.
Juergen Ilse (28.01.2020, 16:00)
Hallo,

Autist <autist69> wrote:
>> Dann wird "sehr bald" wohl noch mindestens 20 Jahre dauern. Bisher sind
>> meines Wissens nach noch keine "HTTP3 only" Webseiten im Netz zu finden.

> Das wird recht schnell gehen, denn in den Browsern kommt es durch die
> Updates und die Webserver werden auch von Zeit zu Zeit ge-updatet wer-
> den. Da gibt's kaum was anzupassen, weswegen das sicher um Größenord-
> nungen schneller ausgerollt wird als IPv6.


Deine "Tunnelblick" ausschliesslich auf die Sicht aus Richtung Anwender ist
graesslich un in *dieser* Gruppe voellig unangebracht. Es gibt diverse Web-
serverimplementierungen und nicht alle heissen "apache" und nciht alle haben
QUIC bereits implementiert. Darueberhinaus gibt es noch Loadbalancer,
Firewalls, ... und auch die sollten damit umgehen koennen, und deren Lebens-
dauer im Unternehmenseinsatz liegt teilweise bei mehr als einem Jahrzehnt ...

Tschuess,
Juergen Ilse (juergen)
Autist (28.01.2020, 16:04)
> Deine "Tunnelblick" ausschliesslich auf die Sicht aus Richtung Anwender ist
> graesslich un in *dieser* Gruppe voellig unangebracht. Es gibt diverse Web-
> serverimplementierungen und nicht alle heissen "apache" und nciht alle haben
> QUIC bereits implementiert.


Ich habe auch von der Server-Seite gepsrochen, und da lässt sich QUIC
recht einfach und transparent nachrüsten. Wenn Du heute einen Chromium
-basierten Browser mit Google-Diensten benutzt, dann benutzt Du mit
hoher Wahrscheinlichkeit HTTP/3 / QUIC.

Ähnliche Themen