Η OpenAI αναδιαμόρφωσε το WebRTC stack της γύρω από ένα stateless relay που κάνει routing βάσει του ICE ufrag

Ο περιορισμός που επέβαλε την επανασχεδίαση: το μοντέλο θυρών του WebRTC έναντι του Kubernetes

Η ομάδα της OpenAI πλαισιώνει το πρόβλημα με λειτουργικούς όρους και όχι με όρους προϊόντος. Η εξυπηρέτηση πάνω από 900 εκατομμυρίων εβδομαδιαίων ενεργών χρηστών σήμαινε ότι το συμβατικό μοντέλο ανάπτυξης WebRTC — μία δημόσια UDP θύρα ανά συνεδρία — έπαψε να ταιριάζει στην υποδομή τους.

Εξηγούν τον λόγο. Σε υψηλή ταυτοχρονικότητα, η αντιστοίχιση μίας θύρας ανά συνεδρία σε αναγκάζει να εκθέτεις και να διαχειρίζεσαι πολύ μεγάλα εύρη δημόσιων UDP θυρών. Οι load balancers στο cloud και οι υπηρεσίες Kubernetes δεν έχουν σχεδιαστεί γύρω από δεκάδες χιλιάδες δημόσιες UDP θύρες. Αυτή η επιφάνεια είναι δύσκολο να ασφαλιστεί, δύσκολο να ελεγχθεί, και εχθρική προς το autoscaling, καθώς τα pods συνεχώς προστίθενται, αφαιρούνται και προγραμματίζονται εκ νέου, ενώ κάθε ένα θα έπρεπε να δεσμεύει και να διαφημίζει ένα σταθερό εύρος θυρών.

Η προφανής λύση — μία μοναδική UDP θύρα ανά server με demultiplexing σε επίπεδο εφαρμογής — λύνει το πρόβλημα του αριθμού θυρών αλλά δημιουργεί ένα δεύτερο πρόβλημα. Τα ICE και DTLS είναι stateful, οπότε η διαδικασία που δημιούργησε μια συνεδρία πρέπει να συνεχίσει να λαμβάνει τα πακέτα αυτής της συνεδρίας. Σε έναν στόλο με load balancing, το πρώτο πακέτο μπορεί ακόμα να καταλήξει στο λάθος instance.

Routing σε ένα πεδίο που υπάρχει ήδη στο handshake

Η απάντηση της OpenAI διαχωρίζει το routing πακέτων από τον τερματισμό του πρωτοκόλλου. Ένα ελαφρύ relay σε Go με μικρό δημόσιο αποτύπωμα βρίσκεται μπροστά από έναν stateful transceiver που κατέχει ολόκληρη τη συνεδρία WebRTC — τους ελέγχους συνδεσιμότητας ICE, το DTLS handshake, τα κλειδιά SRTP και τον κύκλο ζωής. Το relay ποτέ δεν αποκρυπτογραφεί το media ούτε εκτελεί μηχανές κατάστασης ICE· διαβάζει μόνο τα απαραίτητα μεταδεδομένα πακέτου για να επιλέξει έναν προορισμό.

Το έξυπνο σημείο είναι πού βρίσκεται η υπόδειξη routing. Αντί να προσθέσει μια υπηρεσία αναζήτησης στο hot path, η OpenAI κωδικοποιεί μεταδεδομένα routing στο ICE username fragment (ufrag), έναν σύντομο αναγνωριστικό που ήδη ανταλλάσσεται κατά τη ρύθμιση και επαναλαμβάνεται στα STUN binding requests. Ο transceiver δημιουργεί ένα server-side ufrag που μεταφέρει αρκετή πληροφορία για να προσδιορίσει το cluster προορισμού και τον transceiver που τον κατέχει.

Έτσι, το πρώτο πακέτο του media path από τον client — συνήθως ένα STUN binding request που στέλνεται σε ένα κοινό relay VIP όπως 203.0.113.10:3478 — αναλύεται από το relay, το οποίο αποκωδικοποιεί το ufrag και το προωθεί στον σωστό transceiver. Τα επόμενα πακέτα DTLS, RTP και RTCP ρέουν χωρίς επανα-αποκωδικοποίηση. Αν ένα relay επανεκκινηθεί, το επόμενο πακέτο STUN ανακατασκευάζει την αντιστοίχιση από το ufrag· μια Redis cache διατηρεί την αντιστοίχιση client-IP-προς-transceiver, ώστε η ανάκτηση να μπορεί να συμβεί ακόμα πιο νωρίς.

Αυτό που ο browser δεν προσέχει ποτέ

Για έναν frontend engineer, το καθοριστικό χαρακτηριστικό αυτής της δουλειάς είναι αρνητικό: ο client δεν βλέπει τίποτα καινούργιο. Η OpenAI αναφέρει ρητά ότι, από την οπτική γωνία του client, τίποτα στη συνεδρία WebRTC δεν αλλάζει. Ο transceiver συνεχίζει να παρουσιάζει μια κανονική ροή WebRTC και συνεχίζει να κατέχει όλη την κατάσταση του πρωτοκόλλου· άλλαξε μόνο το εσωτερικό routing.

Για εμάς, αυτό σήμαινε αλλαγή στη μορφή της ανάπτυξης του WebRTC μας χωρίς να αλλάξει αυτό που οι clients περιμένουν από το ίδιο το WebRTC.Montana Labs

Πρόκειται για μια σκόπιμη σχεδιαστική αρχή που αναφέρουν ως «διατήρηση της σημασιολογίας του πρωτοκόλλου στην άκρη». Επειδή οι clients συνεχίζουν να μιλούν τυπικό WebRTC, η διαλειτουργικότητα με browsers και mobile παραμένει ακέραια — η ομάδα μπορεί να αναδιαμορφώσει τη δική της υποδομή χωρίς να διανέμει προσαρμοσμένη συμπεριφορά client ή να κατακερματίσει την υποστήριξη μεταξύ πλατφορμών. Η πολυπλοκότητα μεταφέρθηκε σε ένα λεπτό επίπεδο routing, όχι σε κάθε backend υπηρεσία και όχι στον client.

Το άρθρο αναγνωρίζει επίσης το οικοσύστημα WebRTC στο οποίο βασίζεται, σημειώνοντας ότι ο Justin Uberti, ένας από τους αρχικούς αρχιτέκτονες του WebRTC, και ο Sean DuBois, δημιουργός της υλοποίησης Pion σε Go, είναι πλέον συνάδελφοι στην OpenAI. Η πρώτη υλοποίηση transceiver ήταν μία μοναδική υπηρεσία Go βασισμένη στο Pion.

Επιλέγοντας τη «βαρετή» επιλογή: χωρίς SFU, χωρίς kernel bypass

Δύο αποφάσεις ξεχωρίζουν για τη συγκράτηση που δείχνουν. Πρώτον, η OpenAI απέρριψε το SFU (selective forwarding unit) στο οποίο καταλήγουν εξ ορισμού πολλές ομάδες. Ένα SFU έχει λογική για κλήσεις πολλών συμμετεχόντων, αλλά η κίνηση της OpenAI είναι κυρίως 1:1 — ένας χρήστης προς ένα μοντέλο — και ευαίσθητη στην καθυστέρηση σε κάθε γύρο. Το αποτέλεσμα του συνδυασμού relay-plus-transceiver, γράφουν, επιβεβαίωσε ότι ένας σχεδιασμός χωρίς SFU ήταν η σωστή προεπιλογή και επέτρεψε στις υπηρεσίες inference να κλιμακώνονται όπως συνηθισμένες υπηρεσίες αντί να λειτουργούν ως peers WebRTC.

Δεύτερον, αρνήθηκαν το kernel bypass. Το relay εκτελείται εξ ολοκλήρου σε userspace ως συνηθισμένη διαδικασία Go, ρυθμισμένο με SO_REUSEPORT για να διανέμει πακέτα σε workers, με runtime.LockOSThread για να καθηλώνει ροές σε πυρήνες CPU για τοπικότητα cache, και με προ-δεσμευμένα buffers για να αποφεύγεται η επιβάρυνση από τον garbage collection. Αυτό ήταν αρκετό για να διαχειριστούν την παγκόσμια κίνηση πραγματικού χρόνου με σχετικά μικρό αποτύπωμα relay, οπότε διατήρησαν τον απλούστερο σχεδιασμό.

Η γεωγραφία προστίθεται σαν επιπλέον επίπεδο: το Global Relay τοποθετεί σημεία εισόδου κοντά στους χρήστες για να μικρύνει το πρώτο hop, και η γεωγραφική και προσεγγιστική καθοδήγηση της Cloudflare δρομολογεί τη σηματοδοσία σε ένα κοντινό cluster transceiver, με το ufrag να διασφαλίζει ότι το media φτάνει ακόμα στον αγκυρωμένο transceiver.

Το συμπέρασμα: τα μεταδεδομένα routing ανήκουν στο πρωτόκολλο που ήδη χρησιμοποιείτε

Η συγκεκριμένη προέκταση αυτής της ανακοίνωσης είναι ότι το ICE ufrag μπορεί να λειτουργήσει επίσης ως ντετερμινιστικός δρομολογητής πρώτου πακέτου. Ενσωματώνοντας υποδείξεις routing σε ένα πεδίο που το WebRTC ήδη μεταφέρει, η OpenAI πέτυχε session-sticky forwarding σε έναν ολόκληρο στόλο χωρίς εξάρτηση από αναζήτηση στο hot path και χωρίς να σπάσει την τυπική συμπεριφορά του client.

Για ομάδες που χτίζουν φωνητική επικοινωνία πραγματικού χρόνου πάνω σε WebRTC, το μάθημα που μπορεί να επαναχρησιμοποιηθεί δεν είναι ο transceiver ή το relay ως ονομασία — είναι η σειρά ενεργειών. Λύστε την ασυμβατότητα ανάπτυξης (UDP θύρες έναντι Kubernetes) με ένα λεπτό stateless επίπεδο forwarding, κρατήστε τα δύσκολα stateful κομμάτια σε ένα και μόνο σημείο, και προσφύγετε σε εξωτικά εργαλεία όπως το kernel bypass μόνο όταν η συνήθης περίπτωση το απαιτεί πραγματικά. Η πορεία της OpenAI δείχνει ότι συνήθως δεν το απαιτεί.