Το πρωτόκολλο QUIC σε δράση: πώς το υλοποίησε η Uber για να βελτιστοποιήσει την απόδοση

Το πρωτόκολλο QUIC είναι εξαιρετικά ενδιαφέρον για παρακολούθηση, γι' αυτό μας αρέσει να γράφουμε γι' αυτό. Αλλά αν οι προηγούμενες δημοσιεύσεις για το QUIC είχαν περισσότερο ιστορικό (τοπική ιστορία, αν θέλετε) χαρακτήρα και υλικό, σήμερα είμαστε στην ευχάριστη θέση να δημοσιεύσουμε μια μετάφραση διαφορετικού είδους - θα μιλήσουμε για την πραγματική εφαρμογή του πρωτοκόλλου το 2019. Επιπλέον, δεν μιλάμε για μικρές υποδομές που βασίζονται σε ένα λεγόμενο γκαράζ, αλλά για την Uber, η οποία λειτουργεί σχεδόν σε όλο τον κόσμο. Πώς οι μηχανικοί της εταιρείας κατέληξαν στην απόφαση να χρησιμοποιήσουν το QUIC στην παραγωγή, πώς πραγματοποίησαν τις δοκιμές και τι είδαν μετά την κυκλοφορία του στην παραγωγή - κάτω από την περικοπή.

Οι εικόνες μπορούν να κάνουν κλικ. Απολαύστε την ανάγνωση!

Η Uber έχει παγκόσμια κλίμακα, συγκεκριμένα 600 πόλεις παρουσίας, σε καθεμία από τις οποίες η εφαρμογή βασίζεται εξ ολοκλήρου στο ασύρματο Internet από περισσότερους από 4500 φορείς εκμετάλλευσης κινητής τηλεφωνίας. Οι χρήστες αναμένουν ότι η εφαρμογή δεν θα είναι απλώς γρήγορη, αλλά σε πραγματικό χρόνο - για να επιτευχθεί αυτό, η εφαρμογή Uber χρειάζεται χαμηλό λανθάνοντα χρόνο και μια πολύ αξιόπιστη σύνδεση. Αλίμονο, αλλά η στοίβα HTTP / 2 δεν τα πάει καλά σε δυναμικά και επιρρεπή σε απώλειες ασύρματα δίκτυα. Συνειδητοποιήσαμε ότι σε αυτή την περίπτωση, η χαμηλή απόδοση σχετίζεται άμεσα με τις υλοποιήσεις TCP σε πυρήνες λειτουργικών συστημάτων.

Για να λύσουμε το πρόβλημα, κάναμε αίτηση QUIC, ένα σύγχρονο πρωτόκολλο πολυπλεξίας καναλιών που μας δίνει περισσότερο έλεγχο στην απόδοση του πρωτοκόλλου μεταφοράς. Επί του παρόντος η ομάδα εργασίας IETF τυποποιεί την QUIC ως HTTP / 3.

Μετά από εκτεταμένες δοκιμές, καταλήξαμε στο συμπέρασμα ότι η εφαρμογή του QUIC στην εφαρμογή μας θα είχε ως αποτέλεσμα χαμηλότερες καθυστερήσεις ουράς σε σύγκριση με το TCP. Παρατηρήσαμε μείωση του εύρους 10-30% για την κίνηση HTTPS στις εφαρμογές οδηγού και επιβατών. Η QUIC μας έδωσε επίσης έλεγχο από άκρο σε άκρο στα πακέτα χρηστών.

Σε αυτό το άρθρο, μοιραζόμαστε την εμπειρία μας στη βελτιστοποίηση του TCP για εφαρμογές Uber χρησιμοποιώντας μια στοίβα που υποστηρίζει QUIC.

Τελευταία τεχνολογία: TCP

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

Οι περισσότεροι χρήστες χρησιμοποιούν την εφαρμογή μας εν κινήσει και οι καθυστερήσεις TCP tail δεν ήταν καθόλου κοντά στις απαιτήσεις της επισκεψιμότητας HTTPS σε πραγματικό χρόνο. Με απλά λόγια, οι χρήστες σε όλο τον κόσμο το έχουν βιώσει - Το Σχήμα 1 δείχνει τις καθυστερήσεις σε μεγάλες πόλεις:

Σχήμα 1: Ο λανθάνοντας χρόνος διαφέρει από τις κύριες πόλεις της Uber.

Αν και ο λανθάνοντας χρόνος στα δίκτυα της Ινδίας και της Βραζιλίας ήταν υψηλότερος από ό,τι στις ΗΠΑ και το Ηνωμένο Βασίλειο, ο λανθάνοντας χρόνος είναι σημαντικά υψηλότερος από τον μέσο λανθάνοντα χρόνο. Και αυτό ισχύει ακόμη και για τις ΗΠΑ και το Ηνωμένο Βασίλειο.

Επιδόσεις TCP over the air

Το TCP δημιουργήθηκε για ενσύρματο δίκτυα, δηλαδή με έμφαση σε εξαιρετικά προβλέψιμους συνδέσμους. Ωστόσο, ασύρματος τα δίκτυα έχουν τα δικά τους χαρακτηριστικά και δυσκολίες. Πρώτον, τα ασύρματα δίκτυα είναι επιρρεπή σε απώλειες λόγω παρεμβολών και εξασθένησης σήματος. Για παράδειγμα, τα δίκτυα Wi-Fi είναι ευαίσθητα σε μικροκύματα, bluetooth και άλλα ραδιοκύματα. Τα κυψελωτά δίκτυα υποφέρουν από απώλεια σήματος (χαμένο μονοπάτι) λόγω ανάκλασης/απορρόφησης του σήματος από αντικείμενα και κτίρια, καθώς και από παρέμβαση από γειτονικές πύργους κυττάρων. Αυτό οδηγεί σε πιο σημαντικές (4-10 φορές) και πιο ποικίλες Ώρα μετ' επιστροφής (RTT) και απώλεια πακέτων σε σύγκριση με μια ενσύρματη σύνδεση.

Για την καταπολέμηση των διακυμάνσεων του εύρους ζώνης και των απωλειών, τα κυψελωτά δίκτυα συνήθως χρησιμοποιούν μεγάλα buffer για εκρήξεις κίνησης. Αυτό μπορεί να οδηγήσει σε υπερβολική ουρά, πράγμα που σημαίνει μεγαλύτερες καθυστερήσεις. Πολύ συχνά το TCP αντιμετωπίζει αυτήν την ουρά ως χαμένη λόγω παρατεταμένου χρονικού ορίου, έτσι το TCP τείνει να αναμεταδίδει και έτσι να γεμίζει το buffer. Αυτό το πρόβλημα είναι γνωστό ως bufferbloat (υπερβολική αποθήκευση δικτύου, διόγκωση buffer), και αυτό είναι πολύ σοβαρό πρόβλημα σύγχρονο Διαδίκτυο.

Τέλος, η απόδοση του κυψελοειδούς δικτύου ποικίλλει ανάλογα με τον πάροχο, την περιοχή και την ώρα. Στο Σχήμα 2, συλλέξαμε τις διάμεσες καθυστερήσεις της επισκεψιμότητας HTTPS μεταξύ κελιών εντός εύρους 2 χιλιομέτρων. Συλλέχθηκαν δεδομένα για δύο μεγάλους φορείς εκμετάλλευσης κινητής τηλεφωνίας στο Δελχί της Ινδίας. Όπως μπορείτε να δείτε, η απόδοση διαφέρει από κελί σε κελί. Επίσης, η παραγωγικότητα ενός χειριστή διαφέρει από την παραγωγικότητα του δεύτερου. Αυτό επηρεάζεται από παράγοντες όπως τα πρότυπα εισόδου στο δίκτυο που λαμβάνουν υπόψη τον χρόνο και την τοποθεσία, την κινητικότητα των χρηστών, καθώς και την υποδομή δικτύου λαμβάνοντας υπόψη την πυκνότητα των πύργων και την αναλογία των τύπων δικτύου (LTE, 3G, κ.λπ.).

Σχήμα 2. Καθυστερήσεις χρησιμοποιώντας ως παράδειγμα ακτίνα 2 km. Δελχί, Ινδία.

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

Εικόνα 3. Οι καθυστερήσεις ουράς μπορεί να διαφέρουν σημαντικά μεταξύ των ημερών, αλλά για τον ίδιο χειριστή.

Όλα τα παραπάνω κάνουν την απόδοση του TCP να είναι αναποτελεσματική στα ασύρματα δίκτυα. Ωστόσο, προτού αναζητήσουμε εναλλακτικές λύσεις για το TCP, θέλαμε να αναπτύξουμε μια ακριβή κατανόηση σχετικά με τα ακόλουθα σημεία:

• είναι το TCP ο κύριος ένοχος πίσω από τις καθυστερήσεις στις εφαρμογές μας;
• Έχουν τα σύγχρονα δίκτυα σημαντικές και ποικίλες καθυστερήσεις μετ' επιστροφής (RTT);
• Ποιος είναι ο αντίκτυπος του RTT και της απώλειας στην απόδοση του TCP;

Ανάλυση απόδοσης TCP

Για να κατανοήσουμε πώς αναλύσαμε την απόδοση του TCP, ας ρίξουμε μια γρήγορη ματιά στον τρόπο με τον οποίο το TCP μεταφέρει δεδομένα από έναν αποστολέα σε έναν δέκτη. Αρχικά, ο αποστολέας δημιουργεί μια σύνδεση TCP, εκτελώντας μια τριμερή σύνδεση χειραψία: Ο αποστολέας στέλνει ένα πακέτο SYN, περιμένει ένα πακέτο SYN-ACK από τον δέκτη και μετά στέλνει ένα πακέτο ACK. Ένα επιπλέον δεύτερο και τρίτο πέρασμα ξοδεύεται για τη δημιουργία της σύνδεσης TCP. Ο παραλήπτης βεβαιώνει την παραλαβή κάθε πακέτου (ACK) για να εξασφαλίσει αξιόπιστη παράδοση.

Εάν χαθεί ένα πακέτο ή ένα ACK, ο αποστολέας εκπέμπει εκ νέου μετά από ένα χρονικό όριο (RTO, χρονικό όριο αναμετάδοσης). Το RTO υπολογίζεται δυναμικά με βάση διάφορους παράγοντες, όπως η αναμενόμενη καθυστέρηση RTT μεταξύ του αποστολέα και του παραλήπτη.

Εικόνα 4. Η ανταλλαγή πακέτων μέσω TCP/TLS περιλαμβάνει έναν μηχανισμό αναμετάδοσης.

Για να προσδιορίσουμε την απόδοση του TCP στις εφαρμογές μας, παρακολουθήσαμε τα πακέτα TCP χρησιμοποιώντας tcpdump για μια εβδομάδα σχετικά με την κίνηση μάχης που προέρχεται από διακομιστές αιχμής της Ινδίας. Στη συνέχεια αναλύσαμε τις συνδέσεις TCP χρησιμοποιώντας tcptrace. Επιπλέον, δημιουργήσαμε μια εφαρμογή Android που στέλνει προσομοιωμένη κίνηση σε δοκιμαστικό διακομιστή, μιμούμενο την πραγματική κίνηση όσο το δυνατόν περισσότερο. Τα smartphone με αυτήν την εφαρμογή διανεμήθηκαν σε αρκετούς υπαλλήλους, οι οποίοι συνέλεξαν αρχεία καταγραφής για αρκετές ημέρες.

Τα αποτελέσματα και των δύο πειραμάτων ήταν συνεπή μεταξύ τους. Είδαμε υψηλές καθυστερήσεις RTT. Οι τιμές της ουράς ήταν σχεδόν 6 φορές υψηλότερες από τη διάμεση τιμή. ο αριθμητικός μέσος όρος των καθυστερήσεων είναι περισσότερο από 1 δευτερόλεπτο. Πολλές συνδέσεις είχαν απώλειες, με αποτέλεσμα το TCP να αναμεταδίδει το 3,5% όλων των πακέτων. Σε περιοχές με κυκλοφοριακή συμφόρηση, όπως αεροδρόμια και σιδηροδρομικοί σταθμοί, είδαμε απώλειες 7%. Αυτά τα αποτελέσματα θέτουν αμφιβολίες για τη συμβατική σοφία που χρησιμοποιούνται στα κυψελωτά δίκτυα προηγμένα κυκλώματα αναμετάδοσης να μειώσει σημαντικά τις απώλειες σε επίπεδο μεταφορών. Παρακάτω είναι τα αποτελέσματα των δοκιμών από την εφαρμογή "simulator":

Μετρήσεις δικτύου
Σημασίες

RTT, χιλιοστά του δευτερολέπτου [50%,75%, 95%,99%]
[350, 425, 725, 2300]

Απόκλιση RTT, δευτερόλεπτα
Κατά μέσο όρο ~1,2 δευτ

Απώλεια πακέτων σε ασταθείς συνδέσεις
Μέσος όρος ~3.5% (7% σε υπερφορτωμένες περιοχές)

Σχεδόν οι μισές από αυτές τις συνδέσεις είχαν τουλάχιστον μία απώλεια πακέτων, οι περισσότερες από αυτές πακέτα SYN και SYN-ACK. Οι περισσότερες υλοποιήσεις TCP χρησιμοποιούν τιμή RTO 1 δευτερολέπτου για πακέτα SYN, η οποία αυξάνεται εκθετικά για τις επόμενες απώλειες. Οι χρόνοι φόρτωσης εφαρμογών ενδέχεται να αυξηθούν λόγω του ότι το TCP χρειάζεται περισσότερο χρόνο για τη δημιουργία συνδέσεων.

Στην περίπτωση των πακέτων δεδομένων, οι υψηλές τιμές RTO μειώνουν σημαντικά τη χρήσιμη χρήση του δικτύου παρουσία παροδικών απωλειών σε ασύρματα δίκτυα. Βρήκαμε ότι ο μέσος χρόνος αναμετάδοσης είναι περίπου 1 δευτερόλεπτο με καθυστέρηση ουράς σχεδόν 30 δευτερόλεπτα. Αυτές οι υψηλές καθυστερήσεις σε επίπεδο TCP προκάλεσαν χρονικά όρια HTTPS και εκ νέου αιτήματα, αυξάνοντας περαιτέρω τον λανθάνοντα χρόνο και την αναποτελεσματικότητα του δικτύου.

Ενώ το 75ο εκατοστημόριο του μετρημένου RTT ήταν περίπου 425 ms, το 75ο εκατοστημόριο για το TCP ήταν σχεδόν 3 δευτερόλεπτα. Αυτό υποδηλώνει ότι η απώλεια έκανε το TCP να λάβει 7-10 περάσματα για την επιτυχή μετάδοση δεδομένων. Αυτό μπορεί να είναι συνέπεια του αναποτελεσματικού υπολογισμού του RTO, της αδυναμίας του TCP να ανταποκριθεί γρήγορα στην απώλεια τελευταία πακέτα στο παράθυρο και την αναποτελεσματικότητα του αλγορίθμου ελέγχου συμφόρησης, που δεν κάνει διάκριση μεταξύ απωλειών ασύρματης επικοινωνίας και απωλειών λόγω συμφόρησης δικτύου. Παρακάτω είναι τα αποτελέσματα των δοκιμών απώλειας TCP:

Στατιστικά στοιχεία απώλειας πακέτων TCP
Αξία

Ποσοστό συνδέσεων με τουλάχιστον 1 απώλεια πακέτου
45%

Ποσοστό συνδέσεων με απώλειες κατά τη ρύθμιση της σύνδεσης
30%

Ποσοστό συνδέσεων με απώλειες κατά την ανταλλαγή δεδομένων
76%

Κατανομή καθυστερήσεων στην αναμετάδοση, δευτερόλεπτα [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]

Κατανομή του αριθμού των αναμεταδόσεων για ένα πακέτο ή τμήμα TCP
[1,3,6,7]

Εφαρμογή του QUIC

Αρχικά αναπτύχθηκε από την Google, το QUIC είναι ένα σύγχρονο πρωτόκολλο μεταφοράς πολλαπλών νημάτων που τρέχει πάνω από το UDP. Αυτήν τη στιγμή το QUIC είναι μέσα διαδικασία τυποποίησης (Έχουμε ήδη γράψει ότι υπάρχουν, λες, δύο εκδόσεις του QUIC, περίεργες μπορεί να ακολουθήσει τον σύνδεσμο – περίπου. μεταφράστης). Όπως φαίνεται στο Σχήμα 5, το QUIC τοποθετείται κάτω από το HTTP/3 (στην πραγματικότητα, το HTTP/2 πάνω από το QUIC είναι το HTTP/3, το οποίο τώρα τυποποιείται εντατικά). Αντικαθιστά εν μέρει τα επίπεδα HTTPS και TCP χρησιμοποιώντας το UDP για να σχηματίσει πακέτα. Το QUIC υποστηρίζει μόνο ασφαλή μεταφορά δεδομένων καθώς το TLS είναι πλήρως ενσωματωμένο στο QUIC.

Εικόνα 5: Το QUIC εκτελείται με HTTP/3, αντικαθιστώντας το TLS, το οποίο προηγουμένως εκτελούνταν με HTTP/2.

Παρακάτω είναι οι λόγοι που μας έπεισαν να χρησιμοποιήσουμε το QUIC για την ενίσχυση TCP:

• Εγκατάσταση σύνδεσης 0-RTT. Το QUIC επιτρέπει την επαναχρησιμοποίηση εξουσιοδοτήσεων από προηγούμενες συνδέσεις, μειώνοντας τον αριθμό των χειραψιών ασφαλείας. Στο μέλλον TLS1.3 θα υποστηρίζει 0-RTT, αλλά θα εξακολουθεί να απαιτείται μια τριπλή χειραψία TCP.
• ξεπερνώντας τον αποκλεισμό HoL. Το HTTP/2 χρησιμοποιεί μία σύνδεση TCP ανά πελάτη για να βελτιώσει την απόδοση, αλλά αυτό μπορεί να οδηγήσει σε αποκλεισμό HoL (head-of-line). Το QUIC απλοποιεί την πολυπλεξία και παρέχει ανεξάρτητα αιτήματα στην εφαρμογή.
• έλεγχος συμφόρησης. Το QUIC βρίσκεται στο επίπεδο εφαρμογής, διευκολύνοντας την ενημέρωση του κύριου αλγόριθμου μεταφοράς που ελέγχει την αποστολή με βάση τις παραμέτρους δικτύου (αριθμός απωλειών ή RTT). Οι περισσότερες υλοποιήσεις TCP χρησιμοποιούν τον αλγόριθμο ΚΥΒΙΚΟΣ, το οποίο δεν είναι βέλτιστο για κυκλοφορία ευαίσθητη σε λανθάνουσα κατάσταση. Αλγόριθμοι που αναπτύχθηκαν πρόσφατα όπως BBR, μοντελοποιήστε με μεγαλύτερη ακρίβεια το δίκτυο και βελτιστοποιήστε τον λανθάνοντα χρόνο. Το QUIC σάς επιτρέπει να χρησιμοποιείτε το BBR και να ενημερώνετε αυτόν τον αλγόριθμο όπως χρησιμοποιείται. βελτίωση.
• αναπλήρωση των απωλειών. Η QUIC καλεί δύο TLP (καθετήρας απώλειας ουράς) πριν από την ενεργοποίηση του RTO - ακόμα και όταν οι απώλειες είναι πολύ αισθητές. Αυτό είναι διαφορετικό από τις υλοποιήσεις TCP. Το TLP αναμεταδίδει κυρίως το τελευταίο πακέτο (ή το νέο, εάν υπάρχει) για να ενεργοποιήσει τη γρήγορη αναπλήρωση. Ο χειρισμός των καθυστερήσεων ουράς είναι ιδιαίτερα χρήσιμος για τον τρόπο με τον οποίο η Uber λειτουργεί το δίκτυό της, συγκεκριμένα για σύντομες, σποραδικές και ευαίσθητες σε καθυστέρηση μεταφορές δεδομένων.
• βελτιστοποιημένο ACK. Δεδομένου ότι κάθε πακέτο έχει έναν μοναδικό αριθμό σειράς, δεν υπάρχει πρόβλημα διακρίσεις πακέτα όταν αναμεταδίδονται. Τα πακέτα ACK περιέχουν επίσης χρόνο για την επεξεργασία του πακέτου και τη δημιουργία ενός ACK στην πλευρά του πελάτη. Αυτά τα χαρακτηριστικά διασφαλίζουν ότι η QUIC υπολογίζει το RTT με μεγαλύτερη ακρίβεια. Το ACK σε QUIC υποστηρίζει έως και 256 μπάντες ΝΑΚ, βοηθώντας τον αποστολέα να είναι πιο ανθεκτικός στην ανακάτεμα πακέτων και να χρησιμοποιεί λιγότερα byte στη διαδικασία. Επιλεκτική ACK (ΣΑΚΟΣ) στο TCP δεν λύνει αυτό το πρόβλημα σε όλες τις περιπτώσεις.
• μετεγκατάσταση σύνδεσης. Οι συνδέσεις QUIC προσδιορίζονται από ένα αναγνωριστικό 64-bit, επομένως εάν ένας πελάτης αλλάξει διευθύνσεις IP, το παλιό αναγνωριστικό σύνδεσης μπορεί να συνεχίσει να χρησιμοποιείται στη νέα διεύθυνση IP χωρίς διακοπή. Αυτή είναι μια πολύ κοινή πρακτική για εφαρμογές για κινητές συσκευές όπου ο χρήστης αλλάζει μεταξύ Wi-Fi και συνδέσεων κινητής τηλεφωνίας.

Εναλλακτικές λύσεις για την QUIC

Εξετάσαμε εναλλακτικές προσεγγίσεις για την επίλυση του προβλήματος πριν επιλέξουμε το QUIC.

Το πρώτο πράγμα που προσπαθήσαμε ήταν να αναπτύξουμε TPC PoPs (Points of Presence) για να τερματίσουμε τις συνδέσεις TCP πιο κοντά στους χρήστες. Ουσιαστικά, τα PoP τερματίζουν μια σύνδεση TCP με μια κινητή συσκευή πιο κοντά στο δίκτυο κινητής τηλεφωνίας και μεταφέρουν την κίνηση πίσω στην αρχική υποδομή. Τερματίζοντας το TCP πιο κοντά, μπορούμε ενδεχομένως να μειώσουμε το RTT και να διασφαλίσουμε ότι το TCP ανταποκρίνεται περισσότερο σε ένα δυναμικό ασύρματο περιβάλλον. Ωστόσο, τα πειράματά μας έδειξαν ότι το μεγαλύτερο μέρος του RTT και των απωλειών προέρχεται από δίκτυα κινητής τηλεφωνίας και η χρήση PoP δεν προσφέρει σημαντική βελτίωση της απόδοσης.

Εξετάσαμε επίσης τη ρύθμιση των παραμέτρων TCP. Η δημιουργία μιας στοίβας TCP στους ετερογενείς διακομιστές αιχμής μας ήταν δύσκολη επειδή το TCP έχει ανόμοιες υλοποιήσεις σε διαφορετικές εκδόσεις λειτουργικού συστήματος. Ήταν δύσκολο να εφαρμοστεί αυτό και να δοκιμαστούν διαφορετικές διαμορφώσεις δικτύου. Η απευθείας διαμόρφωση του TCP σε κινητές συσκευές δεν ήταν δυνατή λόγω έλλειψης αδειών. Το πιο σημαντικό, χαρακτηριστικά όπως οι συνδέσεις 0-RTT και η βελτιωμένη πρόβλεψη RTT είναι κρίσιμες για την αρχιτεκτονική του πρωτοκόλλου και επομένως είναι αδύνατο να επιτευχθούν σημαντικά οφέλη με τον συντονισμό μόνο του TCP.

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

Η έρευνά μας έδειξε ότι το QUIC είναι ίσως το μόνο πρωτόκολλο που μπορεί να βοηθήσει στο πρόβλημα της κίνησης στο Διαδίκτυο, λαμβάνοντας ταυτόχρονα υπόψη τόσο την ασφάλεια όσο και την απόδοση.

Ενσωμάτωση του QUIC στην πλατφόρμα

Για την επιτυχή ενσωμάτωση του QUIC και τη βελτίωση της απόδοσης της εφαρμογής σε περιβάλλοντα κακής συνδεσιμότητας, αντικαταστήσαμε την παλιά στοίβα (HTTP/2 μέσω TLS/TCP) με το πρωτόκολλο QUIC. Χρησιμοποιήσαμε τη βιβλιοθήκη δικτύου Cronet του Έργα Chromium, το οποίο περιέχει την αρχική, έκδοση Google του πρωτοκόλλου - gQUIC. Αυτή η υλοποίηση επίσης βελτιώνεται συνεχώς για να ακολουθεί τις πιο πρόσφατες προδιαγραφές IETF.

Πρώτα ενσωματώσαμε το Cronet στις εφαρμογές μας Android για να προσθέσουμε υποστήριξη για το QUIC. Η ενσωμάτωση πραγματοποιήθηκε με τέτοιο τρόπο ώστε να μειωθεί όσο το δυνατόν περισσότερο το κόστος μετανάστευσης. Αντί να αντικαταστήσετε πλήρως την παλιά στοίβα δικτύωσης που χρησιμοποιούσε τη βιβλιοθήκη OkHttp, έχουμε ενσωματώσει το Cronet ΣΤΟ πλαίσιο API OkHttp. Κάνοντας την ενσωμάτωση με αυτόν τον τρόπο, αποφύγαμε αλλαγές στις κλήσεις δικτύου μας (οι οποίες χρησιμοποιούνται από Αναβάθμιση) σε επίπεδο API.

Παρόμοια με την προσέγγιση για συσκευές Android, εφαρμόσαμε το Cronet σε εφαρμογές Uber στο iOS, παρεμποδίζοντας την κυκλοφορία HTTP από το δίκτυο APIχρησιμοποιώντας Πρωτόκολλο NSURL. Αυτή η αφαίρεση, που παρέχεται από το Ίδρυμα iOS, χειρίζεται δεδομένα URL για συγκεκριμένα πρωτόκολλα και διασφαλίζει ότι μπορούμε να ενσωματώσουμε το Cronet στις εφαρμογές μας για iOS χωρίς σημαντικό κόστος μετεγκατάστασης.

Ολοκλήρωση του QUIC στο Google Cloud Balancers

Στην πίσω πλευρά, η ολοκλήρωση QUIC παρέχεται από την υποδομή εξισορρόπησης φορτίου Google Cloud, η οποία χρησιμοποιεί alt-svc κεφαλίδες σε απαντήσεις για υποστήριξη QUIC. Γενικά, ο εξισορροπητής προσθέτει μια κεφαλίδα alt-svc σε κάθε αίτημα HTTP και αυτό ήδη επικυρώνει την υποστήριξη QUIC για τον τομέα. Όταν ένας πελάτης Cronet λαμβάνει μια απάντηση HTTP με αυτήν την κεφαλίδα, χρησιμοποιεί το QUIC για επόμενα αιτήματα HTTP σε αυτόν τον τομέα. Μόλις ο εξισορροπητής ολοκληρώσει το QUIC, η υποδομή μας στέλνει ρητά αυτήν την ενέργεια μέσω HTTP2/TCP στα κέντρα δεδομένων μας.

Απόδοση: Αποτελέσματα

Η απόδοση εξόδου είναι ο κύριος λόγος για την αναζήτησή μας για καλύτερο πρωτόκολλο. Αρχικά, δημιουργήσαμε ένα περίπτερο με εξομοίωση δικτύουγια να μάθετε πώς θα συμπεριφέρεται το QUIC σε διαφορετικά προφίλ δικτύου. Για να δοκιμάσουμε την απόδοση της QUIC σε δίκτυα πραγματικού κόσμου, πραγματοποιήσαμε πειράματα ενώ οδηγούσαμε στο Νέο Δελχί χρησιμοποιώντας προσομοιωμένη κίνηση δικτύου που μοιάζει πολύ με τις κλήσεις HTTP στην εφαρμογή επιβατών.

Πείραμα 1

Εξοπλισμός για το πείραμα:

• δοκιμάστε συσκευές Android με στοίβες OkHttp και Cronet για να διασφαλίσετε ότι επιτρέπουμε την κυκλοφορία HTTPS μέσω TCP και QUIC αντίστοιχα.
• ένας διακομιστής εξομοίωσης που βασίζεται σε Java που στέλνει τον ίδιο τύπο κεφαλίδων HTTPS στις απαντήσεις και φορτώνει συσκευές-πελάτες για να λαμβάνει αιτήματα από αυτές.
• διακομιστές μεσολάβησης cloud που βρίσκονται φυσικά κοντά στην Ινδία για τον τερματισμό των συνδέσεων TCP και QUIC. Ενώ για τον τερματισμό TCP χρησιμοποιήσαμε αντίστροφο διακομιστή μεσολάβησης nginx, ήταν δύσκολο να βρεθεί αντίστροφος διακομιστής ανοιχτού κώδικα για το QUIC. Δημιουργήσαμε μόνοι μας έναν αντίστροφο διακομιστή μεσολάβησης για την QUIC χρησιμοποιώντας τη βασική στοίβα QUIC από το Chromium και δημοσιεύθηκε σε χρώμιο ως ανοιχτού κώδικα.

Εικόνα 6. Η σουίτα δοκιμών δρόμου TCP vs QUIC αποτελούνταν από συσκευές Android με OkHttp και Cronet, διακομιστές μεσολάβησης cloud για τερματισμό συνδέσεων και διακομιστή εξομοίωσης.

Πείραμα 2

Όταν η Google έκανε διαθέσιμο το QUIC με Εξισορρόπηση φόρτου Google Cloud, χρησιμοποιήσαμε το ίδιο απόθεμα, αλλά με μία τροποποίηση: αντί για NGINX, χρησιμοποιήσαμε τους εξισορροπητές φορτίου της Google για να τερματίσουμε τις συνδέσεις TCP και QUIC από συσκευές, καθώς και για να δρομολογήσουμε την κυκλοφορία HTTPS στον διακομιστή εξομοίωσης. Οι εξισορροπητές διανέμονται σε όλο τον κόσμο, αλλά χρησιμοποιούν τον διακομιστή PoP που βρίσκεται πιο κοντά στη συσκευή (χάρη στη γεωγραφική τοποθεσία).

Εικόνα 7. Στο δεύτερο πείραμα, θέλαμε να συγκρίνουμε τον λανθάνοντα χρόνο ολοκλήρωσης του TCP και του QUIC: χρησιμοποιώντας το Google Cloud και χρησιμοποιώντας τον διακομιστή μεσολάβησης cloud.

Ως αποτέλεσμα, μας περίμεναν αρκετές αποκαλύψεις:

• Ο τερματισμός μέσω PoP βελτίωσε την απόδοση TCP. Εφόσον οι εξισορροπητές τερματίζουν τις συνδέσεις TCP πιο κοντά στους χρήστες και είναι εξαιρετικά βελτιστοποιημένοι, αυτό έχει ως αποτέλεσμα χαμηλότερα RTT, γεγονός που βελτιώνει την απόδοση TCP. Και παρόλο που το QUIC επηρεάστηκε λιγότερο, εξακολουθούσε να έχει καλύτερη απόδοση από το TCP όσον αφορά τη μείωση του λανθάνοντος χρόνου (κατά 10-30 τοις εκατό).
• επηρεάζονται οι ουρές άλματα δικτύου. Παρόλο που ο διακομιστής μας QUIC βρισκόταν πιο μακριά από τις συσκευές (περίπου 50 ms υψηλότερος λανθάνων χρόνος) από τους εξισορροπητές φορτίου της Google, παρείχε παρόμοια απόδοση - μείωση 15% στον λανθάνοντα χρόνο έναντι μείωσης 20% στο 99ο εκατοστημόριο για το TCP. Αυτό υποδηλώνει ότι η μετάβαση του τελευταίου μιλίου είναι ένα σημείο συμφόρησης στο δίκτυο.

Εικόνα 8: Τα αποτελέσματα από δύο πειράματα δείχνουν ότι το QUIC ξεπερνά σημαντικά το TCP.

Καταπολέμηση της κυκλοφορίας

Εμπνευσμένοι από τον πειραματισμό, έχουμε εφαρμόσει την υποστήριξη QUIC στις εφαρμογές μας Android και iOS. Πραγματοποιήσαμε δοκιμές A/B για να προσδιορίσουμε τον αντίκτυπο του QUIC στις πόλεις όπου δραστηριοποιείται η Uber. Γενικά, παρατηρήσαμε σημαντική μείωση στις καθυστερήσεις ουράς και στις δύο περιοχές, στους φορείς τηλεπικοινωνιών και στον τύπο δικτύου.

Τα παρακάτω γραφήματα δείχνουν τις ποσοστιαίες βελτιώσεις στις ουρές (95 και 99 εκατοστημόρια) ανά μακροπεριοχή και διαφορετικούς τύπους δικτύου - LTE, 3G, 2G.

Σχήμα 9. Σε δοκιμές μάχης, το QUIC ξεπέρασε το TCP όσον αφορά τον λανθάνοντα χρόνο.

Μόνο προς τα εμπρός

Ίσως αυτό είναι μόνο η αρχή - η κυκλοφορία του QUIC στην παραγωγή έχει προσφέρει εκπληκτικές ευκαιρίες για τη βελτίωση της απόδοσης της εφαρμογής τόσο σε σταθερά όσο και σε ασταθή δίκτυα, συγκεκριμένα:

Αυξημένη κάλυψη

Έχοντας αναλύσει την απόδοση του πρωτοκόλλου σε πραγματική κυκλοφορία, είδαμε ότι περίπου το 80% των περιόδων σύνδεσης χρησιμοποίησε με επιτυχία το QUIC για όλα αιτήματα, ενώ το 15% των περιόδων σύνδεσης χρησιμοποιούσε συνδυασμό QUIC και TCP. Υποθέτουμε ότι ο συνδυασμός οφείλεται στο ότι η βιβλιοθήκη Cronet κλείνει πίσω στο TCP, καθώς δεν μπορεί να διακρίνει μεταξύ πραγματικών αποτυχιών UDP και κακών συνθηκών δικτύου. Αυτήν τη στιγμή αναζητούμε μια λύση σε αυτό το πρόβλημα καθώς εργαζόμαστε για την επακόλουθη εφαρμογή του QUIC.

Βελτιστοποίηση QUIC

Η επισκεψιμότητα από εφαρμογές για κινητά είναι ευαίσθητη σε καθυστέρηση, αλλά όχι ευαίσθητη στο εύρος ζώνης. Επίσης, οι εφαρμογές μας χρησιμοποιούνται κυρίως σε δίκτυα κινητής τηλεφωνίας. Με βάση πειράματα, οι καθυστερήσεις ουράς εξακολουθούν να είναι υψηλές, παρόλο που χρησιμοποιείται διακομιστής μεσολάβησης για τον τερματισμό του TCP και του QUIC κοντά στους χρήστες. Αναζητούμε ενεργά τρόπους βελτίωσης της διαχείρισης συμφόρησης και βελτίωσης της αποτελεσματικότητας των αλγορίθμων ανάκτησης απωλειών QUIC.

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

Πηγή: www.habr.com