WebSocket memberi Anda saluran dua arah yang persisten antara klien dan server melalui satu koneksi TCP. Setelah koneksi terbuka, kedua belah pihak dapat mengirim pesan kapan saja, yang menjadikannya tulang punggung obrolan langsung, umpan perdagangan, game multipemain, dan dasbor. Mengujinya adalah latihan yang berbeda dari menguji API permintaan-respons, karena tidak ada satu pun respons untuk diperiksa. Ada sebuah aliran.
Panduan ini bersifat praktis. Ini mencakup apa yang bisa dan tidak bisa dilakukan curl dengan WebSocket, cara menggunakan alat khusus websocat, dan kapan klien GUI menjadi pilihan yang lebih baik. Setiap perintah di sini nyata dan siap disalin.
Mengapa pengujian WebSocket tidak seperti pengujian REST
Pengujian REST adalah sebuah transaksi. Anda mengirim satu permintaan, Anda mendapatkan satu respons, Anda menegaskannya, Anda selesai. Pengujian WebSocket adalah percakapan. Anda membuka koneksi sekali, lalu bertukar banyak pesan selama masa pakainya, dan pesan dapat tiba tanpa diminta.
Hal itu mengubah apa yang Anda periksa. Anda mengkonfirmasi bahwa koneksi ditingkatkan dengan benar dari HTTP. Anda mengkonfirmasi bahwa server menerima pesan pertama Anda dan membalas seperti yang diharapkan. Anda mengkonfirmasi bahwa pesan yang didorong server tiba tanpa Anda meminta. Anda mengamati bagaimana koneksi ditutup, dan dengan kode penutupan apa. Alat yang dibuat untuk permintaan sekali pakai akan kesulitan dengan semua ini, itulah sebabnya curl, alat HTTP universal, hanya cocok sebagian. Untuk gambaran pengujian yang lebih luas, perbedaan antara skenario pengujian dan kasus pengujian cocok dengan percakapan WebSocket versus pemeriksaan pesan tunggal.
Handshake WebSocket
Setiap koneksi WebSocket dimulai sebagai permintaan HTTP yang meminta untuk ditingkatkan. Klien mengirim header Upgrade: websocket dan Connection: Upgrade ditambah Sec-WebSocket-Key, dan server menjawab dengan HTTP 101 Switching Protocols. Setelah itu, koneksi tidak lagi HTTP. Ini berbicara protokol frame WebSocket yang didefinisikan dalam RFC 6455.
Inilah akar dari keterbatasan curl. curl klasik berbicara HTTP. Ini dapat mengirim header peningkatan, tetapi tidak dapat membingkai dan membatalkan bingkai pesan WebSocket setelah handshake. Mencoba memalsukan sesi WebSocket penuh dengan flag header mentah tidak berfungsi setelah handshake itu sendiri. Anda memerlukan alat yang memahami frame.
Menguji WebSocket dengan curl
curl modern, versi 7.86 dan yang lebih baru, menambahkan dukungan WebSocket asli eksperimental. Ini benar-benar dapat digunakan untuk pemeriksaan sederhana, dengan catatan bahwa itu masih ditandai eksperimental.
Pertama, konfirmasikan versi Anda:
curl --version
Jika Anda menggunakan 7.86 atau yang lebih baru, Anda dapat terhubung ke endpoint WebSocket secara langsung. Berikut adalah koneksi ke server echo publik, yang membalas apa pun yang Anda kirim:
curl --include --no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Sec-WebSocket-Version: 13" \
--header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://echo.websocket.org
Flag --include menampilkan header respons sehingga Anda dapat mengkonfirmasi status 101, dan --no-buffer menghentikan curl agar tidak menahan output, yang penting untuk sebuah aliran. Untuk koneksi aman, gunakan URL wss:// persis seperti Anda menggunakan https://.
Dukungan WebSocket curl menonjol untuk satu hal: mengkonfirmasi bahwa sebuah endpoint dapat dijangkau dan menyelesaikan peningkatan. Ini canggung untuk sesi interaktif di mana Anda mengirim beberapa pesan dan membaca balasan, karena curl tidak dibangun di sekitar loop pesan. Untuk pemeriksaan cepat "apakah endpoint ini aktif" dalam sebuah skrip, itu tidak masalah. Untuk pengujian interaktif yang sebenarnya, gunakan alat khusus. Jika Anda membuat skrip pemeriksaan ini ke dalam pipeline, panduan kami tentang mengotomatiskan pengujian API di CI/CD mencakup menghubungkan pemeriksaan baris perintah ke dalam build.
Menguji WebSocket dengan websocat
websocat adalah alat baris perintah yang paling diinginkan orang untuk pekerjaan WebSocket. Ini dibuat khusus, memahami frame dengan benar, dan berperilaku seperti netcat untuk WebSocket.
Instal dengan manajer paket Anda, misalnya brew install websocat di macOS atau melalui cargo install websocat. Kemudian menghubungkan dan mengobrol adalah satu perintah:
websocat wss://echo.websocket.org
Itu membuka sesi interaktif. Ketik baris, tekan enter, dan itu dikirim sebagai pesan. Balasan server akan tercetak saat tiba. Untuk mengirim satu pesan dan keluar, masukkan melalui pipe:
echo '{"action":"subscribe","channel":"prices"}' | websocat wss://stream.example.com/feed
websocat juga menangani tambahan yang berguna. Anda dapat meneruskan header untuk endpoint yang diautentikasi:
websocat --header "Authorization: Bearer your-token-here" wss://api.example.com/socket
Dan Anda dapat menjalankannya sebagai server lokal untuk menguji klien, atau menjembatani WebSocket ke port TCP biasa. Untuk pengujian WebSocket baris perintah, websocat mencakup hampir semua yang tidak bisa dilakukan curl. Perlakukan penegasan dengan cara yang sama seperti di tempat lain; catatan kami tentang menulis penegasan API yang berguna juga berlaku untuk memeriksa payload pesan.
Menguji WebSocket dengan alat GUI
Alat baris perintah sangat bagus untuk skrip dan pemeriksaan cepat. Mereka melelahkan untuk pengujian eksplorasi, di mana Anda ingin melihat lini masa pesan, mengirim JSON terstruktur dengan nyaman, dan menjaga koneksi tetap terbuka saat Anda mengotak-atiknya.
Apidog memiliki klien WebSocket khusus yang dibangun untuk ini. Anda memasukkan URL ws:// atau wss://, terhubung, dan melihat setiap pesan yang dikirim dan diterima dalam tampilan lini masa dengan penyorotan sintaks JSON. Anda dapat menyimpan koneksi, mengatur header dan parameter kueri untuk autentikasi, dan menjaga koneksi tetap aktif saat Anda bereksperimen. Ini menangani REST, GraphQL, dan SOAP dalam aplikasi yang sama, sehingga pengujian WebSocket berada di samping pekerjaan API Anda yang lain daripada di alat terpisah. Unduh Apidog untuk menguji endpoint WebSocket dengan lini masa visual.
GUI adalah pilihan yang tepat saat Anda menjelajahi API WebSocket yang tidak dikenal, men-debug mengapa pesan tidak tiba, atau berbagi pengujian yang dapat direproduksi dengan rekan tim. Baris perintah adalah pilihan yang tepat saat Anda ingin pemeriksaan berjalan tanpa pengawasan. Kebanyakan insinyur menggunakan keduanya, memilih sesuai tugas. Jika Anda ingin pandangan yang lebih luas tentang opsi GUI, rangkuman kami tentang alat pengujian API online gratis mencakup beberapa yang menangani WebSocket.
Daftar periksa pengujian WebSocket sederhana
- Konfirmasi peningkatan. Koneksi harus mengembalikan HTTP 101. Jika tidak, endpoint, jalur, atau header Anda salah.
- Periksa autentikasi. Banyak server WebSocket mengharapkan token di header atau parameter kueri. Koneksi yang terbuka lalu segera ditutup sering kali berarti token ditolak.
- Kirim pesan yang diketahui dan verifikasi balasan. Gunakan payload nyata yang dipahami API Anda dan konfirmasikan bentuk responsnya.
- Verifikasi pesan yang didorong server. Berlangganan saluran dan konfirmasikan bahwa pembaruan tiba tanpa permintaan lebih lanjut dari Anda.
- Uji penutupan. Tutup koneksi dan periksa kode penutupan. Penutupan yang bersih adalah 1000; kode lain menandakan masalah tertentu.
- Uji jalur kegagalan. Kirim pesan yang salah format dan konfirmasikan bahwa server merespons dengan masuk akal daripada menjatuhkan secara diam-diam.
Untuk mengorganisir ini ke dalam rangkaian yang dapat diulang, panduan kami tentang membangun rangkaian pengujian API berlaku untuk alur WebSocket sama seperti untuk REST.
Mendebug koneksi WebSocket yang tidak berfungsi
Ketika koneksi WebSocket gagal, penyebabnya hampir selalu salah satu dari sejumlah kecil masalah. Atasi secara berurutan.
Mulai dengan skema URL. Koneksi ke wss:// dari halaman atau konteks yang mengharapkan ws://, atau sebaliknya, gagal segera. Browser juga memblokir koneksi ws:// dari halaman yang dilayani melalui HTTPS, karena itu mencampur konten aman dan tidak aman. Konfirmasikan skema cocok dengan lingkungan.
Selanjutnya, periksa respons handshake. Jika Anda tidak melihat HTTP 101, server tidak pernah setuju untuk meningkatkan. Kode 404 berarti jalurnya salah. Kode 401 atau 403 berarti autentikasi gagal sebelum peningkatan. Kode 400 sering kali berarti header peningkatan yang hilang atau salah format. Flag --include curl dan mode verbose websocat keduanya menunjukkan respons ini, sehingga Anda dapat membedakan kegagalan handshake dari masalah selanjutnya.
Jika handshake berhasil tetapi koneksi terputus beberapa detik kemudian, perhatikan batas waktu idle dan frame ping atau pong. Banyak server mengharapkan klien untuk menjawab frame ping untuk membuktikan bahwa itu masih hidup, dan mereka menutup koneksi yang diam. Proxy atau penyeimbang beban di depan server juga dapat menghentikan koneksi idle sesuai jadwalnya sendiri. Terakhir, baca kode penutupan. Kode-kode tersebut didefinisikan dalam RFC 6455, dan kode seperti 1006 menunjukkan penutupan abnormal tanpa handshake bersih, sementara 1011 menandakan kesalahan server. Kode penutupan biasanya memberi tahu Anda sisi mana yang menyerah dan mengapa.
Mengotomatiskan pemeriksaan WebSocket
Pengujian manual satu kali mengkonfirmasi bahwa endpoint berfungsi hari ini. Ini tidak melindungi Anda dari regresi minggu depan. Untuk itu, pemeriksaan WebSocket harus berjalan tanpa pengawasan.
Alat baris perintah membuat ini mudah. Skrip kecil dapat membuka koneksi dengan websocat, mengirim pesan yang diketahui, menangkap balasan, dan membandingkannya dengan nilai yang diharapkan, lalu keluar bukan-nol jika tidak cocok. Skrip itu masuk ke pipeline CI seperti langkah pengujian lainnya. Alat GUI dengan runner skenario, seperti Apidog, dapat menyimpan alur WebSocket, termasuk pesan yang dikirim dan penegasan pada balasan, dan memutar ulang sesuai jadwal atau dari pemicu pipeline.
Fokuskan pengujian WebSocket otomatis. Tegaskan bahwa koneksi ditingkatkan, tegaskan satu pasangan permintaan dan respons yang diketahui, dan tegaskan bahwa saluran yang berlangganan mengirimkan setidaknya satu pesan yang didorong dalam batas waktu. Mencoba menegaskan setiap kemungkinan pesan dari koneksi berumur panjang membuat pengujian lambat dan tidak stabil. Pembatasan yang sama yang menjaga kasus pengujian tetap tajam menjaga pemeriksaan WebSocket tetap andal: uji satu hal yang jelas, dan uji dengan baik.
Pertanyaan yang sering diajukan
Bisakah curl menguji koneksi WebSocket?
Sebagian. curl 7.86 dan yang lebih baru memiliki dukungan WebSocket asli eksperimental yang dapat menyelesaikan handshake dan bertukar pesan dasar, yang cukup untuk mengkonfirmasi bahwa sebuah endpoint dapat dijangkau. Ini canggung untuk sesi interaktif dengan banyak pesan. Untuk pengujian WebSocket yang sebenarnya, websocat atau klien GUI seperti Apidog lebih cocok.
Apa perbedaan antara ws dan wss?
ws:// adalah koneksi WebSocket yang tidak terenkripsi, dan wss:// dienkripsi dengan TLS, setara dengan WebSocket dengan HTTP versus HTTPS. Selalu gunakan wss:// untuk apa pun di luar pengembangan lokal, karena ws:// mengirim pesan dalam teks biasa. Alat memperlakukan kedua URL secara identik selain dari enkripsi.
Mengapa koneksi WebSocket saya terbuka lalu segera ditutup?
Penyebab paling umum adalah autentikasi. Jika server mengharapkan token di header atau parameter kueri dan tidak mendapatkan token yang valid, ia menerima koneksi TCP lalu menutupnya. Periksa kode penutupan, verifikasi token Anda, dan konfirmasikan bahwa Anda mengirimnya dengan cara yang diharapkan server.
Apakah websocat lebih baik daripada curl untuk pengujian WebSocket?
Untuk WebSocket secara khusus, ya. websocat dibuat khusus, sepenuhnya memahami protokol frame, mendukung sesi interaktif, header kustom, dan memipa pesan masuk dan keluar. curl adalah alat HTTP umum yang dukungan WebSocket-nya masih eksperimental. Gunakan curl untuk pemeriksaan jangkauan cepat dan websocat untuk pengujian yang sebenarnya.
Bagaimana cara menguji bahwa server mendorong pesan tanpa permintaan?
Buka koneksi, berlangganan saluran atau acara yang relevan jika API memerlukannya, lalu tunggu dan amati. Dengan websocat, pesan yang didorong tercetak saat tiba. Dengan klien GUI seperti Apidog, pesan tersebut muncul di lini masa pesan. Konfirmasikan bahwa pesan tiba tanpa masukan lebih lanjut dari Anda, karena pengiriman tanpa diminta adalah inti dari WebSocket.