Για περισσότερα από 20 χρόνια βλέπουμε ιστοσελίδες χρησιμοποιώντας το πρωτόκολλο HTTP. Οι περισσότεροι χρήστες δεν σκέφτονται καν τι είναι και πώς λειτουργεί. Άλλοι γνωρίζουν ότι κάπου κάτω από το HTTP υπάρχει TLS, και κάτω από αυτό είναι το TCP, κάτω από το οποίο είναι η IP, και ούτω καθεξής. Και άλλοι -αιρετικοί- πιστεύουν ότι το TCP ανήκει στο παρελθόν· θέλουν κάτι πιο γρήγορο, πιο αξιόπιστο και ασφαλές. Αλλά στις προσπάθειές τους να εφεύρουν ένα νέο ιδανικό πρωτόκολλο, επέστρεψαν στην τεχνολογία των 80s και προσπαθούν να χτίσουν τον γενναίο νέο κόσμο τους πάνω σε αυτήν.
Λίγο ιστορικό: HTTP/1.1
Το 1997, το πρωτόκολλο ανταλλαγής πληροφοριών κειμένου HTTP έκδοση 1.1 απέκτησε το δικό του RFC. Εκείνη την εποχή, το πρωτόκολλο είχε χρησιμοποιηθεί από προγράμματα περιήγησης για αρκετά χρόνια και το νέο πρότυπο διήρκεσε άλλα δεκαπέντε. Το πρωτόκολλο λειτουργούσε μόνο βάσει της αρχής αίτησης-απόκρισης και προοριζόταν κυρίως για τη μετάδοση πληροφοριών κειμένου.
Το HTTP σχεδιάστηκε για να τρέχει πάνω από το πρωτόκολλο TCP, διασφαλίζοντας ότι τα πακέτα παραδίδονται αξιόπιστα στον προορισμό τους. Το TCP λειτουργεί με τη δημιουργία και τη διατήρηση μιας αξιόπιστης σύνδεσης μεταξύ των τελικών σημείων και τη διάσπαση της κυκλοφορίας σε τμήματα. Τα τμήματα έχουν τον δικό τους σειριακό αριθμό και το άθροισμα ελέγχου. Εάν ξαφνικά ένα από τα τμήματα δεν φτάσει ή φτάσει με εσφαλμένο άθροισμα ελέγχου, τότε η μετάδοση θα σταματήσει μέχρι να αποκατασταθεί το χαμένο τμήμα.
Στο HTTP/1.0, η σύνδεση TCP έκλεινε μετά από κάθε αίτημα. Αυτό ήταν εξαιρετικά σπάταλο, γιατί... Η δημιουργία μιας σύνδεσης TCP (3-Way-Handshake) είναι μια αργή διαδικασία. Το HTTP/1.1 εισήγαγε τον μηχανισμό keep-alive, ο οποίος σας επιτρέπει να επαναχρησιμοποιήσετε μία σύνδεση για πολλαπλά αιτήματα. Ωστόσο, καθώς μπορεί εύκολα να γίνει εμπόδιο, διάφορες υλοποιήσεις του HTTP/1.1 επιτρέπουν το άνοιγμα πολλαπλών συνδέσεων TCP στον ίδιο κεντρικό υπολογιστή. Για παράδειγμα, το Chrome και οι πρόσφατες εκδόσεις του Firefox επιτρέπουν έως και έξι συνδέσεις.
Η κρυπτογράφηση έπρεπε επίσης να αφεθεί σε άλλα πρωτόκολλα και γι' αυτό χρησιμοποιήθηκε το πρωτόκολλο TLS μέσω TCP, το οποίο προστάτευε αξιόπιστα τα δεδομένα, αλλά αύξησε περαιτέρω τον χρόνο που απαιτείται για τη δημιουργία μιας σύνδεσης. Ως αποτέλεσμα, η διαδικασία χειραψίας άρχισε να μοιάζει με αυτό:
Εικονογράφηση Cloudflare
Έτσι, το HTTP/1.1 είχε μια σειρά από προβλήματα:
- Αργή ρύθμιση σύνδεσης.
- Τα δεδομένα μεταδίδονται σε μορφή κειμένου, πράγμα που σημαίνει ότι η μετάδοση εικόνων, βίντεο και άλλων πληροφοριών μη κειμένου είναι αναποτελεσματική.
- Μία σύνδεση TCP χρησιμοποιείται για ένα αίτημα, πράγμα που σημαίνει ότι άλλα αιτήματα πρέπει είτε να βρουν άλλη σύνδεση είτε να περιμένουν μέχρι να την απελευθερώσει το τρέχον αίτημα.
- Υποστηρίζεται μόνο το μοντέλο έλξης. Δεν υπάρχει τίποτα στο πρότυπο σχετικά με το server-push.
- Οι επικεφαλίδες μεταδίδονται σε κείμενο.
Εάν το server-push υλοποιηθεί τουλάχιστον χρησιμοποιώντας το πρωτόκολλο WebSocket, τότε τα υπόλοιπα προβλήματα έπρεπε να αντιμετωπιστούν πιο ριζικά.
Λίγος εκσυγχρονισμός: HTTP/2
Το 2012, η Google άρχισε να εργάζεται πάνω στο πρωτόκολλο SPDY (προφέρεται "ταχύτατο"). Το πρωτόκολλο σχεδιάστηκε για να λύνει τα κύρια προβλήματα του HTTP/1.1 και ταυτόχρονα υποτίθεται ότι διατηρεί τη συμβατότητα προς τα πίσω. Το 2015, η ομάδα εργασίας IETF εισήγαγε την προδιαγραφή HTTP/2 με βάση το πρωτόκολλο SPDY. Εδώ είναι οι διαφορές στο HTTP/2:
- Δυαδική σειριοποίηση.
- Πολυπλεξία πολλαπλών αιτημάτων HTTP σε μία μόνο σύνδεση TCP.
- Διακομιστής-σπρώξτε έξω από το κουτί (χωρίς WebSocket).
Το πρωτόκολλο ήταν ένα μεγάλο βήμα μπροστά. Αυτός έντονα και δεν απαιτεί τη δημιουργία πολλαπλών συνδέσεων TCP: όλα τα αιτήματα σε έναν κεντρικό υπολογιστή πολυπλέκονται σε ένα. Δηλαδή, σε μια σύνδεση υπάρχουν πολλά λεγόμενα streams, καθένα από τα οποία έχει το δικό του ID. Το μπόνους είναι ένα boxed server-push.
Ωστόσο, η πολυπλεξία οδηγεί σε ένα άλλο βασικό πρόβλημα. Φανταστείτε ότι εκτελούμε ασύγχρονα 5 αιτήματα σε έναν διακομιστή. Όταν χρησιμοποιείτε το HTTP/2, όλα αυτά τα αιτήματα θα εκτελούνται εντός της ίδιας σύνδεσης TCP, πράγμα που σημαίνει ότι εάν ένα από τα τμήματα οποιουδήποτε αιτήματος χαθεί ή ληφθεί λανθασμένα, η μετάδοση όλων των αιτημάτων και των απαντήσεων θα σταματήσει έως ότου ολοκληρωθεί το χαμένο τμήμα. ανακαινισμένο. Προφανώς, όσο χειρότερη είναι η ποιότητα της σύνδεσης, τόσο πιο αργά λειτουργεί το HTTP/2. , σε συνθήκες όπου τα χαμένα πακέτα αντιπροσωπεύουν το 2% όλων των πακέτων, το HTTP/1.1 στο πρόγραμμα περιήγησης αποδίδει καλύτερα από το HTTP/2 λόγω του γεγονότος ότι ανοίγει 6 συνδέσεις αντί για μία.
Αυτό το πρόβλημα ονομάζεται «μπλοκάρισμα της γραμμής» και, δυστυχώς, δεν είναι δυνατή η επίλυσή του όταν χρησιμοποιείτε το TCP.
Εικονογράφηση Daniel Steinberg
Ως αποτέλεσμα, οι προγραμματιστές του προτύπου HTTP/2 έκαναν εξαιρετική δουλειά και έκαναν σχεδόν ό,τι μπορούσε να γίνει στο επίπεδο εφαρμογής του μοντέλου OSI. Ήρθε η ώρα να κατεβείτε στο επίπεδο μεταφοράς και να εφεύρετε ένα νέο πρωτόκολλο μεταφοράς.
Χρειαζόμαστε ένα νέο πρωτόκολλο: UDP vs TCP
Πολύ γρήγορα έγινε σαφές ότι η εφαρμογή ενός εντελώς νέου πρωτοκόλλου επιπέδου μεταφοράς είναι ένα αδύνατο έργο στη σημερινή πραγματικότητα. Γεγονός είναι ότι το υλικό ή τα μεσαία κουτιά (δρομολογητές, τείχη προστασίας, διακομιστές NAT...) γνωρίζουν για το επίπεδο μεταφοράς και η εκμάθησή τους σε κάτι νέο είναι μια εξαιρετικά δύσκολη εργασία. Επιπλέον, η υποστήριξη για πρωτόκολλα μεταφοράς είναι ενσωματωμένη στον πυρήνα των λειτουργικών συστημάτων και οι πυρήνες δεν είναι επίσης πολύ πρόθυμοι να αλλάξουν.
Και εδώ θα μπορούσε κανείς να σηκώσει τα χέρια του και να πει «Εμείς, φυσικά, θα εφεύρουμε ένα νέο HTTP/3 με προτίμηση και εταίρες, αλλά θα χρειαστούν 10-15 χρόνια για να εφαρμοστεί (μετά από αυτό το διάστημα το μεγαλύτερο μέρος του υλικού θα είναι αντικαταστάθηκε), αλλά υπάρχει ακόμα ένα όχι. Η προφανής επιλογή είναι να χρησιμοποιήσετε το πρωτόκολλο UDP. Ναι, ναι, το ίδιο πρωτόκολλο που χρησιμοποιούσαμε για να πετάξουμε αρχεία μέσω LAN στα τέλη της δεκαετίας του 'XNUMX και στις αρχές της δεκαετίας του XNUMX. Σχεδόν όλο το σημερινό υλικό μπορεί να λειτουργήσει με αυτό.
Ποια είναι τα πλεονεκτήματα του UDP έναντι του TCP; Πρώτα απ 'όλα, δεν έχουμε μια περίοδο λειτουργίας επιπέδου μεταφοράς για την οποία γνωρίζει το υλικό. Αυτό μας επιτρέπει να προσδιορίζουμε μόνοι μας τη συνεδρία στα τελικά σημεία και να επιλύουμε τις διενέξεις εκεί. Δηλαδή, δεν περιοριζόμαστε σε μία ή περισσότερες συνεδρίες (όπως στο TCP), αλλά μπορούμε να δημιουργήσουμε όσες από αυτές χρειαζόμαστε. Δεύτερον, η μετάδοση δεδομένων μέσω UDP είναι ταχύτερη από ότι μέσω TCP. Έτσι, θεωρητικά, μπορούμε να ξεπεράσουμε το τρέχον ανώτατο όριο ταχύτητας που επιτυγχάνεται στο HTTP/2.
Ωστόσο, το UDP δεν εγγυάται αξιόπιστη μετάδοση δεδομένων. Στην πραγματικότητα, απλώς στέλνουμε πακέτα, ελπίζοντας ότι η άλλη άκρη θα τα λάβει. Δεν έχουν λάβει? Λοιπόν, καμία τύχη... Αυτό ήταν αρκετό για τη μετάδοση βίντεο για ενήλικες, αλλά για πιο σοβαρά πράγματα χρειάζεστε αξιοπιστία, πράγμα που σημαίνει ότι πρέπει να τυλίξετε κάτι άλλο πάνω από το UDP.
Όπως και με το HTTP/2, οι εργασίες για τη δημιουργία ενός νέου πρωτοκόλλου ξεκίνησαν στη Google το 2012, δηλαδή περίπου την ίδια στιγμή που ξεκίνησαν οι εργασίες για το SPDY. Το 2013, ο Jim Roskind παρουσίασε στο ευρύ κοινό , και ήδη το 2015 εισήχθη το Internet Draft για τυποποίηση στο IETF. Ήδη εκείνη την εποχή, το πρωτόκολλο που αναπτύχθηκε από τον Roskind στην Google ήταν πολύ διαφορετικό από το πρότυπο, έτσι η έκδοση της Google άρχισε να ονομάζεται gQUIC.
Τι είναι το QUIC
Πρώτον, όπως ήδη αναφέρθηκε, αυτό είναι ένα περιτύλιγμα πάνω από το UDP. Μια σύνδεση QUIC ανεβαίνει πάνω από το UDP, στην οποία, κατ' αναλογία με το HTTP/2, μπορούν να υπάρχουν πολλές ροές. Αυτές οι ροές υπάρχουν μόνο στα τελικά σημεία και εξυπηρετούνται ανεξάρτητα. Εάν συμβεί απώλεια πακέτου σε μια ροή, δεν θα επηρεάσει άλλες.
Εικονογράφηση Daniel Steinberg
Δεύτερον, η κρυπτογράφηση δεν εφαρμόζεται πλέον σε ξεχωριστό επίπεδο, αλλά περιλαμβάνεται στο πρωτόκολλο. Αυτό σας επιτρέπει να δημιουργήσετε μια σύνδεση και να ανταλλάξετε δημόσια κλειδιά με μία μόνο χειραψία, και σας επιτρέπει επίσης να χρησιμοποιήσετε τον έξυπνο μηχανισμό χειραψίας 0-RTT και να αποφύγετε εντελώς τις καθυστερήσεις χειραψίας. Επιπλέον, είναι πλέον δυνατή η κρυπτογράφηση μεμονωμένων πακέτων δεδομένων. Αυτό σας επιτρέπει να μην περιμένετε την ολοκλήρωση της λήψης δεδομένων από τη ροή, αλλά να αποκρυπτογραφήσετε τα λαμβανόμενα πακέτα ανεξάρτητα. Αυτός ο τρόπος λειτουργίας ήταν γενικά αδύνατος στο TCP, επειδή Το TLS και το TCP λειτουργούσαν ανεξάρτητα το ένα από το άλλο και το TLS δεν μπορούσε να γνωρίζει σε ποια κομμάτια θα τεμαχίζονταν τα δεδομένα TCP. Και επομένως, δεν μπορούσε να προετοιμάσει τα τμήματα του έτσι ώστε να χωρούν στα τμήματα TCP ένα προς ένα και να μπορούν να αποκρυπτογραφηθούν ανεξάρτητα. Όλες αυτές οι βελτιώσεις επιτρέπουν στην QUIC να μειώσει την καθυστέρηση σε σύγκριση με το TCP.
Τρίτον, η έννοια της ροής φωτός σάς επιτρέπει να αποσυνδέσετε τη σύνδεση από τη διεύθυνση IP του πελάτη. Αυτό είναι σημαντικό, για παράδειγμα, όταν ένας πελάτης αλλάζει από ένα σημείο πρόσβασης Wi-Fi σε άλλο, αλλάζοντας την IP του. Σε αυτήν την περίπτωση, όταν χρησιμοποιείτε το TCP, εμφανίζεται μια μακρά διαδικασία κατά την οποία λήγει το χρονικό διάστημα των υπαρχουσών συνδέσεων TCP και δημιουργούνται νέες συνδέσεις από μια νέα IP. Στην περίπτωση του QUIC, ο πελάτης απλώς συνεχίζει να στέλνει πακέτα στον διακομιστή από μια νέα IP με το παλιό αναγνωριστικό ροής. Επειδή Το αναγνωριστικό ροής είναι πλέον μοναδικό και δεν χρησιμοποιείται ξανά· ο διακομιστής κατανοεί ότι ο πελάτης έχει αλλάξει IP, στέλνει ξανά χαμένα πακέτα και συνεχίζει την επικοινωνία στη νέα διεύθυνση.
Τέταρτον, το QUIC υλοποιείται σε επίπεδο εφαρμογής και όχι σε επίπεδο λειτουργικού συστήματος. Αυτό, αφενός, σας επιτρέπει να κάνετε γρήγορα αλλαγές στο πρωτόκολλο, επειδή Για να λάβετε μια ενημέρωση, πρέπει απλώς να ενημερώσετε τη βιβλιοθήκη, αντί να περιμένετε για μια νέα έκδοση λειτουργικού συστήματος. Από την άλλη πλευρά, αυτό οδηγεί σε έντονη αύξηση της κατανάλωσης επεξεργαστή.
Και τέλος, οι τίτλοι. Η συμπίεση κεφαλίδας είναι ένα από τα πράγματα που διαφέρει μεταξύ QUIC και gQUIC. Δεν βλέπω το νόημα να αφιερώνω πολύ χρόνο σε αυτό, θα πω απλώς ότι στην έκδοση που υποβλήθηκε για τυποποίηση, η συμπίεση κεφαλίδας έγινε όσο το δυνατόν παρόμοια με τη συμπίεση κεφαλίδας στο HTTP/2. Μπορείτε να διαβάσετε περισσότερα .
Πόσο πιο γρήγορο είναι;
Είναι μια δύσκολη ερώτηση. Γεγονός είναι ότι μέχρι να έχουμε ένα πρότυπο, δεν υπάρχει τίποτα ιδιαίτερο να μετρήσουμε. Ίσως τα μόνα στατιστικά που έχουμε είναι στατιστικά από την Google, η οποία χρησιμοποιεί το gQUIC από το 2013 και το 2016 ότι περίπου το 90% της επισκεψιμότητας που πηγαίνει στους διακομιστές τους από το πρόγραμμα περιήγησης Chrome χρησιμοποιεί πλέον το QUIC. Στην ίδια παρουσίαση αναφέρουν ότι οι σελίδες φορτώνουν περίπου 5% γρηγορότερα μέσω του gQUIC και υπάρχουν 30% λιγότερα τραύλισμα στη ροή βίντεο σε σύγκριση με το TCP.
Το 2017, μια ομάδα ερευνητών με επικεφαλής τον Arash Molavi Kakhki δημοσίευσε να μελετήσει την απόδοση του gQUIC σε σύγκριση με το TCP.
Η μελέτη αποκάλυψε αρκετές αδυναμίες του gQUIC, όπως η αστάθεια στη μίξη πακέτων δικτύου, η απληστία (αδικία) στο εύρος ζώνης του καναλιού και η πιο αργή μεταφορά μικρών (έως 10 kb) αντικειμένων. Το τελευταίο, ωστόσο, μπορεί να αντισταθμιστεί χρησιμοποιώντας 0-RTT. Σε όλες τις άλλες περιπτώσεις που μελετήθηκαν, το gQUIC έδειξε αύξηση στην ταχύτητα σε σύγκριση με το TCP. Είναι δύσκολο να μιλήσουμε για συγκεκριμένους αριθμούς εδώ. Διαβάστε καλύτερα ή .
Εδώ πρέπει να ειπωθεί ότι αυτά τα δεδομένα αφορούν ειδικά το gQUIC και δεν σχετίζονται με το πρότυπο που αναπτύσσεται. Τι θα συμβεί για την QUIC: εξακολουθεί να είναι μυστικό, αλλά υπάρχει ελπίδα ότι οι αδυναμίες που εντοπίστηκαν στο gQUIC θα ληφθούν υπόψη και θα διορθωθούν.
Λίγο από το μέλλον: τι γίνεται με το HTTP/3;
Αλλά εδώ όλα είναι ξεκάθαρα: το API δεν θα αλλάξει με κανέναν τρόπο. Όλα θα παραμείνουν ακριβώς όπως ήταν στο HTTP/2. Λοιπόν, εάν το API παραμείνει το ίδιο, η μετάβαση στο HTTP/3 θα πρέπει να επιλυθεί χρησιμοποιώντας μια νέα έκδοση της βιβλιοθήκης στο backend που υποστηρίζει τη μεταφορά QUIC. Είναι αλήθεια ότι θα πρέπει να διατηρήσετε τις παλιές εκδόσεις του HTTP για αρκετό καιρό, γιατί Το Διαδίκτυο δεν είναι προς το παρόν έτοιμο για πλήρη μετάβαση στο UDP.
Ποιος ήδη υποστηρίζει
Εδώ υπάρχουσες υλοποιήσεις QUIC. Παρά την έλλειψη προτύπου, η λίστα δεν είναι κακή.
Κανένα πρόγραμμα περιήγησης δεν υποστηρίζει αυτήν τη στιγμή QUIC σε μια έκδοση παραγωγής. Πρόσφατα υπήρχαν πληροφορίες ότι η υποστήριξη για HTTP/3 συμπεριλήφθηκε στον Chrome, αλλά μέχρι στιγμής μόνο στο Canary.
Από τα backend, το HTTP/3 υποστηρίζει μόνο и , αλλά ακόμα πειραματικό. NGINX στα τέλη της άνοιξης 2019 , ότι άρχισαν να εργάζονται για την υποστήριξη HTTP/3, αλλά δεν την έχουν ολοκληρώσει ακόμα.
Ποια είναι τα προβλήματα;
Εσείς και εγώ ζούμε στον πραγματικό κόσμο, όπου καμία μεγάλη τεχνολογία δεν μπορεί να φτάσει στις μάζες χωρίς να συναντήσει αντίσταση, και η QUIC δεν αποτελεί εξαίρεση.
Το πιο σημαντικό πράγμα είναι ότι πρέπει να εξηγήσετε με κάποιο τρόπο στο πρόγραμμα περιήγησης ότι το "https://" δεν είναι πλέον γεγονός ότι οδηγεί στη θύρα TCP 443. Μπορεί να μην υπάρχει καθόλου TCP. Η κεφαλίδα Alt-Svc χρησιμοποιείται για αυτό. Σας επιτρέπει να πείτε στο πρόγραμμα περιήγησης ότι αυτός ο ιστότοπος είναι επίσης διαθέσιμος σε ένα τέτοιο πρωτόκολλο σε αυτήν και σε αυτή τη διεύθυνση. Θεωρητικά, αυτό θα έπρεπε να λειτουργεί σαν γούρι, αλλά στην πράξη θα συναντήσουμε το γεγονός ότι το UDP μπορεί, για παράδειγμα, να απαγορευτεί σε ένα τείχος προστασίας για να αποφευχθούν επιθέσεις DDoS.
Αλλά ακόμα κι αν το UDP δεν απαγορεύεται, ο υπολογιστής-πελάτης μπορεί να βρίσκεται πίσω από έναν δρομολογητή NAT που έχει ρυθμιστεί να κρατά μια συνεδρία TCP κατά διεύθυνση IP και επειδή χρησιμοποιούμε UDP, το οποίο δεν έχει περίοδο λειτουργίας υλικού, το NAT δεν θα κρατήσει τη σύνδεση και μια περίοδο λειτουργίας QUIC .
Όλα αυτά τα προβλήματα οφείλονται στο γεγονός ότι το UDP δεν είχε χρησιμοποιηθεί στο παρελθόν για τη μετάδοση περιεχομένου στο Διαδίκτυο και οι κατασκευαστές υλικού δεν μπορούσαν να προβλέψουν ότι αυτό θα συνέβαινε ποτέ. Με τον ίδιο τρόπο, οι διαχειριστές δεν καταλαβαίνουν ακόμη πώς να ρυθμίσουν σωστά τα δίκτυά τους για να λειτουργεί το QUIC. Αυτή η κατάσταση θα αλλάξει σταδιακά και, σε κάθε περίπτωση, τέτοιες αλλαγές θα χρειαστούν λιγότερο χρόνο από την εφαρμογή ενός νέου πρωτοκόλλου επιπέδου μεταφοράς.
Επιπλέον, όπως έχει ήδη περιγραφεί, το QUIC αυξάνει σημαντικά τη χρήση της CPU. Ντάνιελ Στένμπεργκ ανάπτυξη επεξεργαστή έως και τρεις φορές.
Πότε θα φτάσει το HTTP/3;
Πρότυπο έως τον Μάιο του 2020, αλλά δεδομένου ότι τα έγγραφα που έχουν προγραμματιστεί για τον Ιούλιο του 2019 παραμένουν ημιτελή αυτή τη στιγμή, μπορούμε να πούμε ότι η ημερομηνία πιθανότατα θα μετατεθεί πίσω.
Λοιπόν, η Google χρησιμοποιεί την εφαρμογή gQUIC από το 2013. Αν κοιτάξετε το αίτημα HTTP που αποστέλλεται στη μηχανή αναζήτησης Google, θα δείτε αυτό:
Ευρήματα
Το QUIC μοιάζει τώρα με μια μάλλον ακατέργαστη, αλλά πολλά υποσχόμενη τεχνολογία. Λαμβάνοντας υπόψη ότι τα τελευταία 20 χρόνια, όλες οι βελτιστοποιήσεις των πρωτοκόλλων επιπέδου μεταφοράς αφορούσαν κυρίως το TCP, το QUIC, το οποίο στις περισσότερες περιπτώσεις έχει την καλύτερη απόδοση, φαίνεται ήδη εξαιρετικά καλό.
Ωστόσο, εξακολουθούν να υπάρχουν άλυτα προβλήματα που θα πρέπει να αντιμετωπιστούν τα επόμενα χρόνια. Η διαδικασία μπορεί να καθυστερήσει λόγω του γεγονότος ότι εμπλέκεται υλικό, το οποίο σε κανέναν δεν αρέσει να ενημερώνει, αλλά παρόλα αυτά όλα τα προβλήματα φαίνονται αρκετά επιλύσιμα και αργά ή γρήγορα θα έχουμε όλοι το HTTP/3.
Το μέλλον είναι προ των πυλών!
Πηγή: www.habr.com