News Google QUIC soll Websites beschleunigen

fethomm

Commander
Registriert
Okt. 2012
Beiträge
2.597
Das maßgeblich von Google entwickelte SPDY-Protokoll wurde kürzlich zum Transportprotokoll für den kommenden Standard HTTP 2.0 bestimmt. Bei Google arbeitet man aber bereits erneut an einer Verbesserung der Geschwindigkeit von Netzwerkverbindungen. Das Zauberwort heißt dieses Mal „Quick UDP Internet Connections“ (QUIC).

Zur News: Google QUIC soll Websites beschleunigen
 
Ich denke er spielt eher auf UDP an :rolleyes:

Find ich toll. Fand UDP schon immer deutlich sympatischer als TCP.

Hier eine visuelle Approximation von UDP
gopymlH.gif
 
Zuletzt bearbeitet:
OT: @1668mib
Damit könnte man auch den Schwachsinn "RIP in Peace" erklären
1. Akronym ausdenken: Rest In Peace
2. Akronym in der Bezeichnung verwenden: Rest In Peace in Peace
Ganz einfach, rekursives Akronym.

Und sonst, finde es gut, dass Google auch dahin Forschung betreibt. Wenn das ganze dann alias HTTP als allgemeiner Standard genutzt wird hilft das allen.
 
Imho hat UDP aber nichts im normalen Internet zu suchen. Sicherheit geht vor, und die ist bei UDP nicht gewährleistet. Für Streams ne gute Sache, aber auch nur dafür.
 
@wazzup: Meinst du Sicherheit oder nicht eigentlich Zuverlässigkeit? oO

@Vivster: Ok, aber selbst das ist ja nicht unbedingt jetzt so dramatisch neu.. man denke nur mal an AJAX, wo XML drin steckt...
und in PHP steckt auch PHP drin, nur ist es zufälligerweise rekursiv..
 
@Vivster:
so eine geniale bildliche darstellung von UDP habe ich noch nicht gesehen. Epic.
 
Vivster schrieb:

Das tolle an Forwärtsfehlerkorrektur: es ist egal, wenn einige Pakete fehlen. Bei einer 3/4 FEC kann z.B. jedes 4. Paket fehlen und es muss trotzdem nicht neu gesendet werden. Das dürfte vor allem im mobilen Bereich interessant sein, wo Neuübertragungen und Handshakes besonders langwierig sind. Dafür verringert sich die Nettobandbreite auf 75%. Wenn du also kleine Datenmengen mit niedriger Latenz und hoher Zuverlässig senden musst ist das die bessere Wahl. Für große Datenmengen ohne hohe Latenzanforderungen bleibt TCP mit selektiver Neuübertragung.
 
Zuletzt bearbeitet:
Niedrige Latenz? Ich weiß nicht... Wenn das 1. Paket erst geschickt werden kann, wenn das 4. Paket auch "feststeht", dann sehe ich da nicht viel von niedriger Latenz ;-)

Auf einem verhältnismäßig unzuverlässigen Transportweg mag es natürlich sinnvoller sein.
 
Das kommt ganz darauf an wie hoch deine RTT ist und wie Häufig du Pakete verlierst. Wenn Paketverlust relativ wahrscheinlich ist und deine RTT jenseits von 100ms liegt, also etwa die Situation wie bei UMTS, dann verringert sich der Jitter deutlich und damit auch im Mittel die Latenz.
 
Die Frage, die bleibt ist: Wenn die Leitung so unzuverlässig ist, dann können auch mal mehr Pakete verloren gehen, und mal weniger.. die Statistik, dass im Mittel jedes vierte verloren geht, bringt mir wenig, wenn einmal 2 von 4 und einmal 4 von 4 ankommen...
 
Zurück
Oben