HTTP/3 προ των πυλών, εμπνευσμένο από Google

[ZAFIRIOSNT]

δλδ με αυτό δεν θα ανταλλάζουμε κλειδάκια? ρε, δεν καλό....

[defacer]

Αν δεν έχετε δουλέψει επαγγελματικά με το HTTP κατ' ελάχιστο, πλιζ μη προσπαθείτε να βγάλετε συμπέρασμα. Πολλά μίλια άουτ. Το μόνο πράγμα που διάβασα από σχόλια και που ισχύει είναι πως "προ των πυλών" σημαίνει στην πραγματικότητα "σε μερικά χρόνια βλέπουμε αν έχει προχωρήσει καθόλου η εξάπλωση".

Ένα μόνο σχόλιο, όταν λένε "πάνω στο UDP", εννοούν "πάνω στο UDP με επιπλέον custom protocol που προσφέρει error correction και άλλες απαραίτητες εγγυήσεις, απλά όχι με τον ίδιο ακριβώς τρόπο όπως στο TCP".

Πώς να το πω, είναι στατιστικά πιθανότερο συμπέρασμα πως κάποιος εδώ δεν καταλαβαίνει τι διαβάζει ακριβώς, παρά ότι αυτοί που είναι η δουλειά τους να κάνουν αυτό το πράγμα δεν ξέρουν τι πάνε να κάνουν.

Επεξ/σία 16 Νοεμβρίου 2018 από defacer

[Επισκέπτης]

Δυστυχώς, το άρθρο μιλάει μόνο για το επιθυμητό αποτέλεσμα του πρωτοκόλου, χωρίς να παρέχει καθόλου πληροφορίες για το πως θα υλοποιηθεί (πέρα από το θα στηρίζεται στο UDP και ένα ασαφές διάγραμμα που δεν φανερώνει τα custom features που αναφέρει ο όπως πάντα εύστοχος defacer),  ούτε τα πιθανά trade-offs που θα το καθιστούν αποτελεσματικό για συγκεκριμένα σενάρια χρήσης (ή κάθε σεναριο;).

Η αλήθεια είναι ότι το TCP σχεδιάστηκε να καλύψει ανάγκες άλλων καιρών, οπότε, μάλλον κάτι χρήσιμο θα σκέφτηκαν εκεί στη Google. 

Αναρωτιέμαι αν θα είναι backwards compatible και αν θα επιτρέπει progressive deployment.

[defacer]

Το TCP είναι γαμώ τα πρωτόκολλα. Εννοώ από την άποψη του πόσο πετυχημένος ήταν ο σχεδιασμός του: τόσο που χρησιμοποιείται για "τα πάντα", και 40-50 χρόνια μετά την εισαγωγή του υπάρχουν ακόμα κάποια bits εκεί μέσα "δεσμευμένα για μελλοντική χρήση", που δε χρησιμοποιήθηκαν ποτέ γιατί δεν υπήρξε ανάγκη, ο καλός ο μύλος όλα τα αλέθει.

Τα προβλήματα του TCP γενικά είναι πως α) τα κάνει όλα, αλλά δε σου αφήνει επιλογή για όλα αυτά που κάνει, β) δημιουργήθηκε στοχεύοντας μια εποχή που τα πράγματα ήταν αλλιώς, και κάποιες αποφάσεις που πάρθηκαν τότε δεν είναι καλές σήμερα.

Εύκολο παράδειγμα: πολλά πάρε-δώσε client-server για να γίνει η δουλειά στην αρχή. Όταν έγινε το TCP, το latency ήταν περίπου το ίδιο που είναι και τώρα, αλλά το bandwidth ήταν 100000 φορές μικρότερο. Όταν λοιπόν καθόμαστε και περιμένουμε πχ 200 msec το round trip, σήμερα πονάει γιατί σε αυτό το χρόνο αν στέλναμε δεδομένα με 10mbit θα είχαμε ήδη μεταφέρει 500KB δεδομένα. Χωρίς διαφημίσεις, αυτό μπορεί να είναι όλη η σελίδα.

[Thecomedian!]

Λογικά θα αυξήσουν το μέγεθος του  header του UDP ώστε να προσθέσουν sequencing,FCS (Frame Check Sequence),CRC(Cyclic Redundancy Check) ανάλογο με το header του πακέτου TCP.Θεωρώ ότι μόνο έτσι θα μπορέσει να υπάρχει ο ελάχιστος έλεγχος στην αξιόπιστη παράδοση των πακέτων που απαιτείται για μεταφορά data sensitive πακέτων HTTP.Εκτός και  αν τα παραλείψουν όλα αυτά και γίνεται έλεγχος πακέτων στα παραπάνω layers με extra κώδικα.Αλλά απλώς μαντεύουμε τώρα!!

[Ather]

Σε κάποιες περιπτώσεις μπορεί να υπάρχουν καθυστερήσεις. Πρακτικά στην καθημερινότητα όχι, όπως το καταλαβαίνω.

[defacer]

Το UDP παραμένει ως έχει, πάνω από αυτό θα στήσουν πρωτόκολλο. Όπως και σε πολλές άλλες περιπτώσεις, πχ https://en.wikipedia.org/wiki/Real-time_Transport_Protocol.

Όσο για το πώς θα είναι, αυτό είναι εύκολο γιατί υπάρχει ήδη: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/

Γενικά υπάρχουν ήδη καλές γενικές περιγραφές του τι κάνει διαφορετικά. Πχ, προκειμένου να γλυτώσουμε ένα ή και περισσότερα round trips για την αποκατάσταση συνεδρίας (πριν δηλαδή καν αρχίσουμε να κάνουμε τη δουλειά για την οποία ενδιαφερόμαστε εξαρχής), η αποκατάσταση συνεδρίας γίνεται ταυτόχρονα με τον καθορισμό κρυπτογραφικών παραμέτρων (αφού εδώ το έχουμε δεδομένο ότι θέλουμε ασφαλές πρωτόκολλο και τι είδους, που σε άλλες εφαρμογές δεν είναι έτσι).

Το βασικότερο ίσως πράγμα που κάνει είναι ότι παρέχει εσωτερικά μηχανισμό για το διαχωρισμό του καναλιού επικοινωνίας που θα δημιουργηθεί σε αυτόνομα υπο-κανάλια. Αυτό συμβαίνει επειδή εδώ ξέρουμε από πριν ότι θα χρειαστούν πολλές λογικά αυτόνομες συναλλαγές (πχ φορτώνω σελίδα και βλέπω 3 CSS αρχεία, 5 JavaScript και 10 εικόνες, αυτά είναι ήδη 18 HTTP requests που πρέπει να γίνουν, πολλαπλάσια του 18 round trips για τις συνδέσεις, κλπ). Στην περίπτωση με τα υποκανάλια, πληρώνουμε ένα μικρό τίμημα σε όγκο δεδομένων (πολύ μικρό και χεστήκαμε κιόλας γιατί από bandwidth σήμερα άλλο τίποτα) για να κερδίσουμε πάρα πολύ σε μη-αναμονή για round trips που δεν έγιναν (γιατί στο latency ότι κι αν κάνεις στο τέλος πάντα τρως πόρτα από την ταχύτητα του φωτός, οπότε δε βελτιώνεται ρεαλιστικά, οπότε όταν χτυπάνε εκεί πονάει).

[KaraD]

 

Spoiler

Διάβασα τα σχόλια ψάχνοντας κάποιον να γράφει για τα bolt κάτω απο τον τίτλο. 

HTTP (Hyper Transfer Protocol)

που λείπει το Text. 

Μόνο και μόνο από αυτό δεν ξέρω τι εντύπωση να δημιουργήσω για τον αρθρογράφο και τη σχέση του με τα πρωτοκολλα. 

Επί της ουσίας η χρήση του udp μειώνει δραστικότατα το overhead στο δίκτυο και θα έχει ως αποτέλεσμα να είναι όλες οι εφαρμογές πολύ κοντά σε real time. 

Πάω στοίχημα ότι κάπου θα υπάρχει ένα White paper που θα εξηγεί το πρωτοκολλο (για αυτούς που έχουν όρεξη να διαβάσουν) 

[defacer]

3 minutes ago, KaraD said:

Επί της ουσίας η χρήση του udp μειώνει δραστικότατα το overhead στο δίκτυο και θα έχει ως αποτέλεσμα να είναι όλες οι εφαρμογές πολύ κοντά σε real time. 

Overhead όταν λέμε συνήθως εννοούμε σε όγκο δεδομένων. Σε αυτό τον τομέα δε μειώνει ιδιαίτερα τίποτα, η διαφορά είναι 16 bytes ανά frame, με ένα λογικό payload γύρω στα 1300 bytes αυτό είναι 1.2% σε τελικά νούμερα καλύτερο efficiency. Δηλαδή ας πούμε χοντρικά από το 98% πάει στο 99%, not that important. Άσε που με τα του QUIC από πάνω το overhead τελικά είμαι σίγουρος πως θα είναι μεγαλύτερο χωρίς καν να κοιτάξω.

Το QUIC πάντως ενσωματώνει εκούσια διαχείριση ροής δεδομένων (κάτι που ως τώρα γίνεται με τη στάνταρ μέθοδο του TCP, η οποία δε βολεύει σε αρκετές περιπτώσεις ανάμεσα στις οποίες και αυτή εδώ), οπότε σίγουρα είναι στόχος το να παρουσιάζει καλύτερη perceived απόκριση. Το λένε και φαρδιά πλατιά στην εισαγωγή.

4 minutes ago, KaraD said:

Πάω στοίχημα ότι κάπου θα υπάρχει ένα White paper που θα εξηγεί το πρωτοκολλο (για αυτούς που έχουν όρεξη να διαβάσουν) 

Έδωσα το λινκ παραπάνω.

[Επισκέπτης]

Σε πρώτη φάση η χρήση του UDP για HTTP ακυρώνει QoS μοντέλα διαχείρισης best effort κίνησης αλλά και μηχανισμούς πχ congestion avoidance. 

Σε firewalling επίπεδο επίσης η χρήση του UDP για HTTP μόνο βολική δεν την λες....

-- https://www.fastvue.co/fastvue/blog/googles-quic-protocols-security-and-reporting-implications/

 

Σίγουρα TCP και UDP ξεκίνησαν με άλλα δεδομένα για να καλύψουν ανάγκες που σήμερα αλλά και αύριο γίνονται πιο σύνθετες και νέες ιδέες θα μπουν στο παιχνίδι.

Βέβαια η Google τα ίδια έλεγε και πριν λίγα χρόνια για το ίδιο πρόβλημα με το SPDY....

Επεξ/σία 17 Νοεμβρίου 2018 από Επισκέπτης

[KaraD]

7 ώρες πριν, defacer είπε

Το QUIC πάντως ενσωματώνει εκούσια διαχείριση ροής δεδομένων (κάτι που ως τώρα γίνεται με τη στάνταρ μέθοδο του TCP, η οποία δε βολεύει σε αρκετές περιπτώσεις ανάμεσα στις οποίες και αυτή εδώ), οπότε σίγουρα είναι στόχος το να παρουσιάζει καλύτερη perceived απόκριση. Το λένε και φαρδιά πλατιά στην εισαγωγή.

Έριξα μια ματιά στο λινκ που έδωσες. 

Από όσο είδα είναι δουλειά που ακόμα τρέχει με κάποια σημεία που χρήζουν αποφάσεων (βλ. TBD parts in document). 

Αυτό που είδα και έχει ενδιαφέρον κατά τη γνώμη μου ειναι το παρακάτω 

Spoiler

QUIC connection is a single conversation between two QUIC
 endpoints. QUIC’s connection establishment combines version
 negotiation with the cryptographic and transport handshakes to reduce
 connection establishment latency, as described in Section 7.

Επίσης ενδιαφέρον παρουσιάζει το section 17 με τα διάφορα ήδη πακέτων. 

Αυτό που είπα νωρίτερα για το overhead βασιζόταν στον αριθμό των πακέτων που χρειάζονται για την αποστολή ιδίων δεδομένων (πχ ενός αρχείου), αλλά αν κατάλαβα καλά το πρωτόκολλο είναι κάπως υβριδικής μορφής παρά καθαρά udp. 

Σε 1 paper(Taking a Long Look at QUIC
An Approach for Rigorous Evaluation of Rapidly Evolving Transport Protocols) που μου έβγαλε ο γουγλης γίνεται και μια ενδιαφέρουσα σύγκριση με το TCP και αναφέρονται κάποια πλεονεκτήματα του κάθε transport. 

Από όσο διάβασα η Google ήδη το χρησιμοποιει οπότε δεδομένης της υποστήριξης από τεχνολογικό κολοσσό το πρωτόκολλο ίσως να μη χρειαστεί να περάσει το κλασικό δρόμο academia - >prototype tests - > small scale infrastructure deployment μεχρι να βγει στην αγορά και να το δούμε σε ευρεία χρήση αρκετά συντομότερα από το αναμενόμενο. 

[defacer]

1 hour ago, KaraD said:

Από όσο διάβασα η Google ήδη το χρησιμοποιει οπότε δεδομένης της υποστήριξης από τεχνολογικό κολοσσό το πρωτόκολλο ίσως να μη χρειαστεί να περάσει το κλασικό δρόμο academia - >prototype tests - > small scale infrastructure deployment μεχρι να βγει στην αγορά και να το δούμε σε ευρεία χρήση αρκετά συντομότερα από το αναμενόμενο.

Το αρχικό άρθρο το διάβασες; 😛

[Επισκέπτης]

Μια ωραία παρουσίαση υπάρχει και σε: cloudflare:

-- https://blog.cloudflare.com/the-road-to-quic/

Ουσιαστικά το SPDY (Google) που έγινε HTTP/2 , ήταν η αρχική προσέγγιση της Google (gQUIC=HTTP/2 over UDP), ενώ η προσέγγιση της ομάδας του IETF είναι το iQUIC. Μέχρι να υιοθετηθεί (σε large scale) το HTTP/2 ....και να πάμε παρακάτω... έχει (πάρα μα πάρα...) πολύ δρόμο.

[mader]

Η γνώμη μου:  αερολογίες της γουγλας που απέχουν πολυ απο την πραγματικότητα...

εαν κατάλαβα καλα, θα παρει το UDP, θα το τροποποιήσει και θα εχει ΘΕΩΡΗΤΙΚΆ ενα πιο αποδοτικό πρωτόκολλο επικοινωνίας σε σχεση με το TCP.

Δεν ζουμε ομως σε ενα τέλειο κοσμο και ετσι δεν θα ειναι τοσο απλο για παρα πολους λογους.

 

Για να μην λεμε πολλα,

σκεψου να ξεκινήσεις να μιλάς απροειδοποίητα στον κολλητό σου, μεσα σε ενα νυχτερινό κεντρο με πολυ φασαρία, λεγοντας του κατι σημαντικό.

το πιο πιθανο ειναι να ακούσει ολόκληρη την προταση η γκόμενα διπλα που θα εχει στήσει αυτί εδω κ ωρα, παρα ο κολλητος σου που ισως να ακουσει μονο τα τελευταια λογια και φυσικα να σου ζητησει να επαναλαβεις απο την αρχη (UDP) και οχι μονο τα λογια που δεν ακουσε (TCP)

 

οποτε στην πραξη, το QUIC θα ειναι αποδοτικό σε ενα μικρο αριθμο συστημάτων (π.χ. intranets) και πανω - κατω το ιδιο με το TCP για WWW

Επεξ/σία 17 Νοεμβρίου 2018 από mader

[defacer]

1 ώρα πριν, mader είπε

Η γνώμη μου:  αερολογίες της γουγλας που απέχουν πολυ απο την πραγματικότητα...

 

Θα ρωτούσα με ποια λογική πρόκειται να υιοθετήσει η IETF αερολογίες, αλλά μετά θα τρέχουμε να ψάχνουμε τι είναι IETF.