Protokol QUIC sangat menarik untuk ditonton, itulah sebabnya kami suka menulis mengenainya. Tetapi jika penerbitan terdahulu tentang QUIC lebih bersifat sejarah (sejarah tempatan, jika anda suka) sifat dan perkakasan, hari ini kami gembira untuk menerbitkan terjemahan jenis yang berbeza - kami akan bercakap tentang aplikasi sebenar protokol pada 2019. Lebih-lebih lagi, kita tidak bercakap tentang infrastruktur kecil yang berpangkalan di garaj yang dipanggil, tetapi mengenai Uber, yang beroperasi hampir di seluruh dunia. Bagaimana jurutera syarikat membuat keputusan untuk menggunakan QUIC dalam pengeluaran, cara mereka menjalankan ujian dan perkara yang mereka lihat selepas melancarkannya dalam pengeluaran - di bawah pemotongan.
Gambar boleh diklik. Selamat membaca!
Uber mempunyai skala global, iaitu 600 bandar kehadiran, di mana setiap satunya aplikasi bergantung sepenuhnya pada Internet wayarles daripada lebih 4500 pengendali selular. Pengguna menjangkakan apl itu bukan sahaja pantas, tetapi dalam masa nyata - untuk mencapai ini, apl Uber memerlukan kependaman rendah dan sambungan yang sangat boleh dipercayai. Malangnya, tetapi timbunan tidak berfungsi dengan baik dalam rangkaian wayarles dinamik dan terdedah kepada kerugian. Kami menyedari bahawa dalam kes ini, prestasi yang lemah adalah berkaitan secara langsung dengan pelaksanaan TCP dalam kernel sistem pengendalian.
Untuk menyelesaikan masalah, kami memohon , protokol pemultipleksan saluran moden yang memberikan kami lebih kawalan ke atas prestasi protokol pengangkutan. Pada masa ini kumpulan kerja menyeragamkan QUIC sebagai .
Selepas ujian yang meluas, kami membuat kesimpulan bahawa melaksanakan QUIC dalam aplikasi kami akan menghasilkan kependaman ekor yang lebih rendah berbanding dengan TCP. Kami melihat pengurangan dalam julat 10-30% untuk trafik HTTPS dalam aplikasi pemandu dan penumpang. QUIC juga memberi kami kawalan hujung ke hujung ke atas pakej pengguna.
Dalam artikel ini, kami berkongsi pengalaman kami dalam mengoptimumkan TCP untuk aplikasi Uber menggunakan tindanan yang menyokong QUIC.
Teknologi terkini: TCP
Hari ini, TCP ialah protokol pengangkutan yang paling banyak digunakan untuk menyampaikan trafik HTTPS di Internet. TCP menyediakan aliran bait yang boleh dipercayai, dengan itu mengatasi kesesakan rangkaian dan kehilangan lapisan pautan. Penggunaan meluas TCP untuk trafik HTTPS adalah disebabkan oleh ubiquity sebelumnya (hampir setiap OS mengandungi TCP), ketersediaan pada kebanyakan infrastruktur (seperti pengimbang beban, proksi HTTPS dan CDN), dan kefungsian luar kotak yang tersedia. pada hampir kebanyakan platform dan rangkaian.
Kebanyakan pengguna menggunakan apl kami semasa dalam perjalanan, dan kependaman ekor TCP hampir sama dengan permintaan trafik HTTPS masa nyata kami. Ringkasnya, pengguna di seluruh dunia pernah mengalami perkara ini - Rajah 1 menunjukkan kelewatan di bandar utama:
Rajah 1: Kependaman ekor berbeza-beza di seluruh bandar utama Uber.
Walaupun kependaman dalam rangkaian India dan Brazil lebih tinggi daripada di AS dan UK, kependaman ekor adalah lebih tinggi daripada kependaman purata. Dan ini benar walaupun untuk AS dan UK.
TCP atas prestasi udara
TCP dicipta untuk berwayar rangkaian, iaitu, dengan penekanan pada pautan yang boleh diramal. Walau bagaimanapun, tanpa wayar rangkaian mempunyai ciri dan kesukaran tersendiri. Pertama, rangkaian wayarles terdedah kepada kerugian akibat gangguan dan pengecilan isyarat. Sebagai contoh, rangkaian Wi-Fi sensitif kepada gelombang mikro, bluetooth dan gelombang radio lain. Rangkaian selular mengalami kehilangan isyarat () disebabkan oleh pantulan/penyerapan isyarat oleh objek dan bangunan, serta daripada dari jiran . Ini membawa kepada lebih ketara (4-10 kali ganda) dan lebih pelbagai dan kehilangan paket berbanding dengan sambungan berwayar.
Untuk memerangi turun naik dan kerugian lebar jalur, rangkaian selular biasanya menggunakan penimbal besar untuk letupan trafik. Ini boleh menyebabkan beratur yang berlebihan, yang bermaksud kelewatan yang lebih lama. Selalunya TCP menganggap baris gilir ini sebagai pembaziran kerana tamat masa yang dilanjutkan, jadi TCP cenderung untuk menyampaikan dan dengan itu mengisi penimbal. Masalah ini dikenali sebagai (), dan ini sangat Internet moden.
Akhir sekali, prestasi rangkaian selular berbeza mengikut pembawa, rantau dan masa. Dalam Rajah 2, kami mengumpul kelewatan median trafik HTTPS merentas sel dalam julat 2 kilometer. Data dikumpul untuk dua pengendali selular utama di Delhi, India. Seperti yang anda lihat, prestasi berbeza dari sel ke sel. Juga, produktiviti satu operator berbeza daripada produktiviti kedua. Ini dipengaruhi oleh faktor seperti corak kemasukan rangkaian dengan mengambil kira masa dan lokasi, mobiliti pengguna, serta infrastruktur rangkaian dengan mengambil kira kepadatan menara dan nisbah jenis rangkaian (LTE, 3G, dll.).
Rajah 2. Kelewatan menggunakan jejari 2 km sebagai contoh. Delhi, India.
Selain itu, prestasi rangkaian selular berbeza mengikut masa. Rajah 3 menunjukkan kependaman median mengikut hari dalam seminggu. Kami juga melihat perbezaan pada skala yang lebih kecil, dalam satu hari dan jam.
Rajah 3. Kelewatan ekor boleh berbeza dengan ketara antara hari, tetapi untuk operator yang sama.
Semua di atas menyebabkan prestasi TCP menjadi tidak berkesan dalam rangkaian wayarles. Walau bagaimanapun, sebelum mencari alternatif kepada TCP, kami ingin membangunkan pemahaman yang tepat mengenai perkara berikut:
- adakah TCP penyebab utama di sebalik latensi ekor dalam aplikasi kami?
- Adakah rangkaian moden mempunyai kelewatan pergi dan balik (RTT) yang ketara dan pelbagai?
- Apakah kesan RTT dan kerugian terhadap prestasi TCP?
Analisis Prestasi TCP
Untuk memahami cara kami menganalisis prestasi TCP, mari kita lihat dengan pantas cara TCP memindahkan data daripada pengirim kepada penerima. Pertama, penghantar mewujudkan sambungan TCP, melakukan tiga hala : Pengirim menghantar paket SYN, menunggu paket SYN-ACK daripada penerima, kemudian menghantar paket ACK. Pas kedua dan ketiga tambahan dibelanjakan untuk mewujudkan sambungan TCP. Penerima mengakui penerimaan setiap paket (ACK) untuk memastikan penghantaran yang boleh dipercayai.
Jika paket atau ACK hilang, pengirim menghantar semula selepas tamat masa (RTO, ). RTO dikira secara dinamik berdasarkan pelbagai faktor, seperti jangkaan kelewatan RTT antara pengirim dan penerima.
Rajah 4. Pertukaran paket melalui TCP/TLS termasuk mekanisme penghantaran semula.
Untuk menentukan prestasi TCP dalam aplikasi kami, kami memantau penggunaan paket TCP selama seminggu pada trafik pertempuran yang datang dari pelayan tepi India. Kami kemudian menganalisis sambungan TCP menggunakan . Selain itu, kami mencipta aplikasi Android yang menghantar trafik yang dicontohi ke pelayan ujian, meniru trafik sebenar sebanyak mungkin. Telefon pintar dengan aplikasi ini telah diedarkan kepada beberapa pekerja, yang mengumpul log selama beberapa hari.
Keputusan kedua-dua eksperimen adalah konsisten antara satu sama lain. Kami melihat latensi RTT yang tinggi; nilai ekor hampir 6 kali lebih tinggi daripada nilai median; purata aritmetik kelewatan adalah lebih daripada 1 saat. Banyak sambungan terputus, menyebabkan TCP menghantar semula 3,5% daripada semua paket. Di kawasan sesak seperti lapangan terbang dan stesen kereta api, kami menyaksikan kerugian sebanyak 7%. Keputusan ini menimbulkan keraguan tentang kebijaksanaan konvensional yang digunakan dalam rangkaian selular mengurangkan kerugian pada tahap pengangkutan dengan ketara. Berikut adalah keputusan ujian daripada aplikasi "simulator":
Metrik rangkaian
Nilai
RTT, milisaat [50%,75%, 95%,99%]
[350, 425, 725, 2300]
Perbezaan RTT, saat
Secara purata ~1,2 s
Kehilangan paket pada sambungan yang tidak stabil
Purata ~3.5% (7% di kawasan terlebih muatan)
Hampir separuh daripada sambungan ini mempunyai sekurang-kurangnya satu kehilangan paket, kebanyakannya paket SYN dan SYN-ACK. Kebanyakan pelaksanaan TCP menggunakan nilai RTO 1 saat untuk paket SYN, yang meningkat secara eksponen untuk kerugian berikutnya. Masa pemuatan aplikasi mungkin meningkat kerana TCP mengambil masa yang lebih lama untuk mewujudkan sambungan.
Dalam kes paket data, nilai RTO yang tinggi sangat mengurangkan penggunaan berguna rangkaian dengan kehadiran kerugian sementara dalam rangkaian wayarles. Kami mendapati bahawa purata masa penghantaran semula adalah lebih kurang 1 saat dengan kelewatan ekor hampir 30 saat. Latensi tinggi pada tahap TCP ini menyebabkan tamat masa HTTPS dan permintaan semula, meningkatkan lagi kependaman dan ketidakcekapan rangkaian.
Walaupun persentil ke-75 RTT yang diukur adalah sekitar 425 ms, persentil ke-75 untuk TCP ialah hampir 3 saat. Ini membayangkan bahawa kehilangan menyebabkan TCP mengambil 7-10 pas untuk berjaya menghantar data. Ini mungkin akibat daripada pengiraan RTO yang tidak cekap, ketidakupayaan TCP untuk bertindak balas dengan cepat terhadap kerugian dalam tetingkap dan ketidakcekapan algoritma kawalan kesesakan, yang tidak membezakan antara kerugian tanpa wayar dan kerugian akibat kesesakan rangkaian. Berikut ialah keputusan ujian kehilangan TCP:
Statistik kehilangan paket TCP
Nilai
Peratusan sambungan dengan sekurang-kurangnya 1 paket kehilangan
45%
Peratusan sambungan dengan kehilangan semasa persediaan sambungan
30%
Peratusan sambungan dengan kehilangan semasa pertukaran data
76%
Taburan kelewatan dalam penghantaran semula, saat [50%, 75%, 95%,99%] [1, 2.8, 15, 28]
Taburan bilangan penghantaran semula untuk satu paket atau segmen TCP
[1,3,6,7]
Aplikasi QUIC
Pada asalnya dibangunkan oleh Google, QUIC ialah protokol pengangkutan moden berbilang benang yang berjalan di atas UDP. Pada masa ini QUIC masuk (kami sudah menulis bahawa terdapat, seolah-olah, dua versi QUIC, ingin tahu β lebih kurang. penterjemah). Seperti yang ditunjukkan dalam Rajah 5, QUIC diletakkan di bawah HTTP/3 (sebenarnya, HTTP/2 di atas QUIC ialah HTTP/3, yang kini sedang diseragamkan secara intensif). Ia menggantikan sebahagian lapisan HTTPS dan TCP dengan menggunakan UDP untuk membentuk paket. QUIC hanya menyokong pemindahan data selamat kerana TLS terbina sepenuhnya ke dalam QUIC.
Rajah 5: QUIC berjalan di bawah HTTP/3, menggantikan TLS, yang sebelum ini dijalankan di bawah HTTP/2.
Berikut ialah sebab yang meyakinkan kami untuk menggunakan QUIC untuk penguatan TCP:
- Penubuhan sambungan 0-RTT. QUIC membenarkan penggunaan semula kebenaran daripada sambungan sebelumnya, mengurangkan bilangan jabat tangan keselamatan. Pada masa akan datang akan menyokong 0-RTT, tetapi jabat tangan TCP tiga hala masih diperlukan.
- mengatasi penyekatan HoL. HTTP/2 menggunakan satu sambungan TCP bagi setiap pelanggan untuk meningkatkan prestasi, tetapi ini boleh menyebabkan penyekatan HoL (head-of-line). QUIC memudahkan pemultipleksan dan menyampaikan permintaan kepada aplikasi secara bebas.
- kawalan kesesakan. QUIC berada di lapisan aplikasi, menjadikannya lebih mudah untuk mengemas kini algoritma pengangkutan utama yang mengawal penghantaran berdasarkan parameter rangkaian (bilangan kerugian atau RTT). Kebanyakan pelaksanaan TCP menggunakan algoritma , yang tidak optimum untuk trafik sensitif kependaman. Algoritma yang dibangunkan baru-baru ini seperti , memodelkan rangkaian dengan lebih tepat dan mengoptimumkan kependaman. QUIC membolehkan anda menggunakan BBR dan mengemas kini algoritma ini semasa ia digunakan. .
- penambahan semula kerugian. QUIC memanggil dua TLP () sebelum RTO dicetuskan - walaupun kerugian sangat ketara. Ini berbeza daripada pelaksanaan TCP. TLP menghantar semula terutamanya paket terakhir (atau yang baharu, jika ada) untuk mencetuskan pengisian semula dengan pantas. Mengendalikan kelewatan ekor amat berguna untuk cara Uber mengendalikan rangkaiannya, iaitu untuk pemindahan data yang pendek, sporadis dan sensitif kependaman.
- ACK dioptimumkan. Oleh kerana setiap paket mempunyai nombor urutan yang unik, tiada masalah paket apabila ia dihantar semula. Paket ACK juga mengandungi masa untuk memproses paket dan menjana ACK pada bahagian pelanggan. Ciri-ciri ini memastikan QUIC mengira RTT dengan lebih tepat. ACK dalam QUIC menyokong sehingga 256 jalur , membantu pengirim menjadi lebih berdaya tahan untuk mengocok paket dan menggunakan lebih sedikit bait dalam proses itu. ACK terpilih () dalam TCP tidak menyelesaikan masalah ini dalam semua kes.
- penghijrahan sambungan. Sambungan QUIC dikenal pasti oleh ID 64-bit, jadi jika pelanggan menukar alamat IP, ID sambungan lama boleh terus digunakan pada alamat IP baharu tanpa gangguan. Ini adalah amalan yang sangat biasa untuk aplikasi mudah alih di mana pengguna bertukar antara Wi-Fi dan sambungan selular.
Alternatif kepada QUIC
Kami mempertimbangkan pendekatan alternatif untuk menyelesaikan masalah sebelum memilih QUIC.
Perkara pertama yang kami cuba ialah menggunakan TPC PoP (Points of Presence) untuk menamatkan sambungan TCP lebih dekat dengan pengguna. Pada asasnya, PoP menamatkan sambungan TCP dengan peranti mudah alih yang lebih dekat dengan rangkaian selular dan memproksi trafik kembali ke infrastruktur asal. Dengan menamatkan TCP dengan lebih dekat, kami berpotensi mengurangkan RTT dan memastikan bahawa TCP lebih responsif kepada persekitaran wayarles dinamik. Walau bagaimanapun, percubaan kami telah menunjukkan bahawa kebanyakan RTT dan kerugian datang daripada rangkaian selular dan penggunaan PoP tidak memberikan peningkatan prestasi yang ketara.
Kami juga melihat penalaan parameter TCP. Menyediakan tindanan TCP pada pelayan tepi heterogen kami adalah sukar kerana TCP mempunyai pelaksanaan yang berbeza merentas versi OS yang berbeza. Sukar untuk melaksanakan ini dan menguji konfigurasi rangkaian yang berbeza. Mengkonfigurasi TCP secara langsung pada peranti mudah alih tidak dapat dilakukan kerana kekurangan kebenaran. Lebih penting lagi, ciri seperti sambungan 0-RTT dan ramalan RTT yang dipertingkatkan adalah kritikal kepada seni bina protokol, dan oleh itu adalah mustahil untuk mencapai faedah yang ketara dengan menala TCP sahaja.
Akhir sekali, kami menilai beberapa protokol berasaskan UDP yang menyelesaikan masalah penstriman videoβkami ingin melihat sama ada protokol ini akan membantu dalam kes kami. Malangnya, mereka sangat kekurangan dalam banyak tetapan keselamatan, dan juga memerlukan sambungan TCP tambahan untuk metadata dan maklumat kawalan.
Penyelidikan kami telah menunjukkan bahawa QUIC mungkin satu-satunya protokol yang boleh membantu masalah trafik Internet, sambil mengambil kira keselamatan dan prestasi.
Integrasi QUIC ke dalam platform
Untuk berjaya membenamkan QUIC dan meningkatkan prestasi aplikasi dalam persekitaran sambungan yang lemah, kami menggantikan tindanan lama (HTTP/2 berbanding TLS/TCP) dengan protokol QUIC. Kami menggunakan perpustakaan rangkaian daripada , yang mengandungi protokol asal, versi Google - gQUIC. Pelaksanaan ini juga sentiasa ditambah baik untuk mengikuti spesifikasi IETF terkini.
Kami mula-mula menyepadukan Cronet ke dalam apl Android kami untuk menambah sokongan untuk QUIC. Integrasi dilakukan dengan cara yang dapat mengurangkan kos migrasi sebanyak mungkin. Daripada menggantikan sepenuhnya susunan rangkaian lama yang menggunakan perpustakaan , kami telah menyepadukan Cronet DI BAWAH rangka kerja API OkHttp. Dengan melakukan penyepaduan dengan cara ini, kami mengelakkan perubahan pada panggilan rangkaian kami (yang digunakan oleh ) pada peringkat API.
Sama seperti pendekatan untuk peranti Android, kami melaksanakan Cronet ke dalam apl Uber pada iOS, memintas trafik HTTP daripada rangkaian menggunakan . Abstraksi ini, yang disediakan oleh Yayasan iOS, mengendalikan data URL khusus protokol dan memastikan bahawa kami boleh menyepadukan Cronet ke dalam aplikasi iOS kami tanpa kos penghijrahan yang ketara.
Menyelesaikan QUIC pada Google Cloud Balancers
Di bahagian belakang, penyiapan QUIC disediakan oleh infrastruktur pengimbangan Beban Awan Google, yang menggunakan pengepala sebagai respons untuk menyokong QUIC. Secara umum, pengimbang menambah pengepala alt-svc pada setiap permintaan HTTP, dan ini sudah mengesahkan sokongan QUIC untuk domain. Apabila klien Cronet menerima respons HTTP dengan pengepala ini, ia menggunakan QUIC untuk permintaan HTTP berikutnya kepada domain tersebut. Setelah pengimbang melengkapkan QUIC, infrastruktur kami secara eksplisit menghantar tindakan ini melalui HTTP2/TCP ke pusat data kami.
Prestasi: Keputusan
Prestasi output adalah sebab utama untuk carian kami untuk protokol yang lebih baik. Sebagai permulaan, kami membuat pendirian dengan untuk mengetahui cara QUIC akan berkelakuan di bawah profil rangkaian yang berbeza. Untuk menguji prestasi QUIC pada rangkaian dunia sebenar, kami menjalankan eksperimen semasa memandu di sekitar New Delhi menggunakan trafik rangkaian yang dicontohi sangat serupa dengan panggilan HTTP dalam apl penumpang.
Eksperimen 1
Peralatan untuk eksperimen:
- menguji peranti Android dengan tindanan OkHttp dan Cronet untuk memastikan kami membenarkan trafik HTTPS melalui TCP dan QUIC masing-masing;
- pelayan emulasi berasaskan Java yang menghantar jenis pengepala HTTPS yang sama dalam respons dan memuatkan peranti klien untuk menerima permintaan daripadanya;
- proksi awan yang terletak secara fizikal berhampiran dengan India untuk menamatkan sambungan TCP dan QUIC. Manakala untuk penamatan TCP kami menggunakan proksi terbalik pada , sukar untuk mencari proksi songsang sumber terbuka untuk QUIC. Kami sendiri membina proksi terbalik untuk QUIC menggunakan tindanan QUIC asas daripada Chromium dan ia menjadi kromium sebagai sumber terbuka.
Rajah 6. Suite ujian jalan TCP lwn QUIC terdiri daripada peranti Android dengan OkHttp dan Cronet, proksi awan untuk menamatkan sambungan dan pelayan emulasi.
Eksperimen 2
Apabila Google menyediakan QUIC dengan , kami menggunakan inventori yang sama, tetapi dengan satu pengubahsuaian: bukannya NGINX, kami mengambil pengimbang beban Google untuk menamatkan sambungan TCP dan QUIC daripada peranti, serta menghalakan trafik HTTPS ke pelayan emulasi. Pengimbang diedarkan ke seluruh dunia, tetapi gunakan pelayan PoP yang paling hampir dengan peranti (terima kasih kepada geolokasi).
Rajah 7. Dalam percubaan kedua, kami ingin membandingkan kependaman penyiapan TCP dan QUIC: menggunakan Google Cloud dan menggunakan proksi awan kami.
Akibatnya, beberapa pendedahan menanti kita:
- penamatan melalui PoP meningkatkan prestasi TCP. Memandangkan pengimbang menamatkan sambungan TCP lebih dekat dengan pengguna dan sangat dioptimumkan, ini menghasilkan RTT yang lebih rendah, yang meningkatkan prestasi TCP. Dan walaupun QUIC kurang terjejas, ia masih mengatasi prestasi TCP dari segi mengurangkan kependaman ekor (sebanyak 10-30 peratus).
- ekor terjejas . Walaupun proksi QUIC kami berada lebih jauh daripada peranti (kira-kira 50 ms kependaman lebih tinggi) daripada pengimbang beban Google, ia memberikan prestasi yang serupa - pengurangan 15% dalam kependaman berbanding pengurangan 20% dalam persentil ke-99 untuk TCP. Ini menunjukkan bahawa peralihan batu terakhir adalah halangan dalam rangkaian.
Rajah 8: Keputusan daripada dua eksperimen menunjukkan bahawa QUIC mengatasi prestasi TCP dengan ketara.
Lawan trafik
Diilhamkan oleh percubaan, kami telah melaksanakan sokongan QUIC dalam aplikasi Android dan iOS kami. Kami menjalankan ujian A/B untuk menentukan kesan QUIC di bandar tempat Uber beroperasi. Secara umum, kami melihat pengurangan ketara dalam kelewatan ekor di kedua-dua wilayah, pengendali telekom dan jenis rangkaian.
Graf di bawah menunjukkan peratusan peningkatan dalam ekor (95 dan 99 persentil) mengikut wilayah makro dan jenis rangkaian yang berbeza - LTE, 3G, 2G.
Rajah 9. Dalam ujian pertempuran, QUIC mengatasi TCP dari segi kependaman.
Hanya ke hadapan
Mungkin ini hanyalah permulaan - pelepasan QUIC ke dalam pengeluaran telah menyediakan peluang yang menakjubkan untuk meningkatkan prestasi aplikasi dalam kedua-dua rangkaian yang stabil dan tidak stabil, iaitu:
Peningkatan liputan
Setelah menganalisis prestasi protokol pada trafik sebenar, kami melihat bahawa kira-kira 80% sesi berjaya menggunakan QUIC untuk Semua permintaan, manakala 15% sesi menggunakan gabungan QUIC dan TCP. Kami menganggap bahawa gabungan itu disebabkan oleh tamat masa perpustakaan Cronet kembali kepada TCP, kerana ia tidak dapat membezakan antara kegagalan UDP sebenar dan keadaan rangkaian yang lemah. Kami sedang mencari penyelesaian kepada masalah ini sambil kami berusaha ke arah pelaksanaan QUIC yang seterusnya.
pengoptimuman QUIC
Trafik daripada apl mudah alih adalah sensitif kependaman, tetapi tidak sensitif lebar jalur. Selain itu, aplikasi kami digunakan terutamanya pada rangkaian selular. Berdasarkan eksperimen, latensi ekor masih tinggi walaupun menggunakan proksi untuk menamatkan TCP dan QUIC berhampiran pengguna. Kami sedang mencari cara untuk menambah baik pengurusan kesesakan dan meningkatkan kecekapan algoritma pemulihan kerugian QUIC.
Dengan ini dan beberapa penambahbaikan lain, kami merancang untuk meningkatkan pengalaman pengguna tanpa mengira rangkaian dan wilayah, menjadikan pengangkutan paket yang mudah dan lancar lebih mudah diakses di seluruh dunia.
Sumber: www.habr.com