WebSocket size istemci ve sunucu arasında tek bir TCP bağlantısı üzerinden kalıcı, iki yönlü bir kanal sağlar. Bağlantı açıldıktan sonra, her iki taraf da istediği zaman mesaj gönderebilir; bu da onu canlı sohbetlerin, borsa akışlarının, çok oyunculu oyunların ve kontrol panellerinin temel taşı yapar. Bunu test etmek, talep-yanıt API'sini test etmekten farklı bir alıştırmadır, çünkü incelenecek tek bir yanıt yoktur. Bir akış vardır.
Bu kılavuz pratiktir. curl'ün WebSocket ile yapabileceklerini ve yapamayacaklarını, özel araç websocat'i nasıl kullanacağınızı ve bir GUI istemcisinin ne zaman daha iyi bir seçenek olduğunu kapsar. Buradaki her komut gerçektir ve kopyalamaya hazırdır.
WebSocket testi neden REST testi gibi değildir?
Bir REST testi bir işlemdir. Bir talep gönderirsiniz, bir yanıt alırsınız, onu doğrularsınız, işiniz biter. Bir WebSocket testi bir sohbettir. Bir bağlantıyı bir kez açarsınız, ardından ömrü boyunca birçok mesaj alışverişi yaparsınız ve mesajlar istenmeden gelebilir.
Bu, kontrol ettiğiniz şeyleri değiştirir. Bağlantının HTTP'den doğru bir şekilde yükseltildiğini onaylarsınız. Sunucunun ilk mesajınızı kabul ettiğini ve beklendiği gibi yanıt verdiğini onaylarsınız. Sunucu tarafından itilen mesajların siz istemeden geldiğini onaylarsınız. Bağlantının nasıl kapandığını ve hangi kapatma koduyla kapandığını izlersiniz. Tek seferlik istekler için tasarlanmış bir araç tüm bunlarla zorlanır, bu yüzden evrensel HTTP aracı olan curl sadece kısmen uygundur. Daha geniş test resminde, bir test senaryosu ile bir test durumu arasındaki fark, bir WebSocket sohbeti ile tek bir mesaj kontrolüne düzgün bir şekilde eşleşir.
WebSocket el sıkışması
Her WebSocket bağlantısı, yükseltme isteyen bir HTTP isteği olarak başlar. İstemci Upgrade: websocket ve Connection: Upgrade başlıklarını artı bir Sec-WebSocket-Key gönderir ve sunucu HTTP 101 Switching Protocols ile yanıt verir. Bundan sonra, bağlantı artık HTTP değildir. RFC 6455'te tanımlanan WebSocket çerçeve protokolünü konuşur.
Bu, curl'ün sınırlamasının temelidir. Klasik curl HTTP konuşur. Yükseltme başlıklarını gönderebilir, ancak el sıkışmasından sonra WebSocket mesajlarını çerçeveleyemez ve çerçeveden çıkaramaz. Ham başlık bayraklarıyla tam bir WebSocket oturumunu taklit etmeye çalışmak, el sıkışmasının ötesine geçmez. Çerçeveleri anlayan bir araca ihtiyacınız var.
curl ile WebSocket testi
Modern curl, sürüm 7.86 ve sonrası, deneysel yerel WebSocket desteği ekledi. Hala deneysel olarak işaretlenmiş olmasına rağmen, basit kontroller için gerçekten kullanılabilir.
Önce sürümünüzü onaylayın:
curl --version
Eğer 7.86 veya daha yenisini kullanıyorsanız, bir WebSocket uç noktasına doğrudan bağlanabilirsiniz. İşte gönderdiğiniz her şeyi yanıtlayan herkese açık bir eko sunucusuna bağlantı:
curl --include --no-buffer \
--header "Connection: Upgrade" \
--header "Upgrade: websocket" \
--header "Sec-WebSocket-Version: 13" \
--header "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \
https://echo.websocket.org
--include bayrağı yanıt başlıklarını gösterir, böylece 101 durumunu onaylayabilirsiniz ve --no-buffer curl'ün çıktıyı tutmasını engeller, bu bir akış için önemlidir. Güvenli bağlantılar için, https:// kullandığınız gibi tam olarak bir wss:// URL'si kullanın.
curl'ün WebSocket desteği tek bir konuda parlar: bir uç noktanın erişilebilir olduğunu ve yükseltmeyi tamamladığını onaylamak. Birkaç mesaj gönderdiğiniz ve yanıtları okuduğunuz etkileşimli bir oturum için gariptir, çünkü curl bir mesaj döngüsü etrafında inşa edilmemiştir. Bir betikte hızlı bir "bu uç nokta canlı mı" kontrolü için uygundur. Gerçek etkileşimli testler için özel bir araca yönelin. Bu kontrolleri bir pipeline'a dahil ediyorsanız, CI/CD'de API testlerini otomatikleştirme kılavuzumuz, komut satırı kontrollerini bir derlemeye bağlamayı kapsar.
websocat ile WebSocket testi
websocat, çoğu insanın WebSocket çalışması için gerçekten istediği komut satırı aracıdır. Amaca yönelik olarak tasarlanmıştır, çerçeveleri düzgün bir şekilde anlar ve WebSocket için bir netcat gibi davranır.
Paket yöneticinizle kurun, örneğin macOS'ta brew install websocat veya cargo install websocat aracılığıyla. Ardından bağlanma ve sohbet tek bir komutla yapılır:
websocat wss://echo.websocket.org
Bu etkileşimli bir oturum açar. Bir satır yazın, enter tuşuna basın ve mesaj olarak gönderilir. Sunucunun yanıtları geldikçe yazdırılır. Tek bir mesaj göndermek ve çıkmak için, onu boruyla içeri aktarın:
echo '{"action":"subscribe","channel":"prices"}' | websocat wss://stream.example.com/feed
websocat ayrıca faydalı ekstraları da işler. Kimlik doğrulama gerektiren uç noktalar için başlıklar geçirebilirsiniz:
websocat --header "Authorization: Bearer your-token-here" wss://api.example.com/socket
Ve bir istemciyi test etmek için yerel bir sunucu olarak çalıştırabilir veya bir WebSocket'i düz bir TCP bağlantı noktasına köprüleyebilirsiniz. Komut satırı WebSocket testi için websocat, curl'ün yapamadığı hemen hemen her şeyi kapsar. Doğrulamaları başka yerlerde yaptığınız gibi ele alın; faydalı API doğrulamaları yazma hakkındaki notlarımız, mesaj yüklerini kontrol etmek için de geçerlidir.
Bir GUI aracıyla WebSocket testi
Komut satırı araçları, betikler ve hızlı kontroller için harikadır. Mesaj zaman çizelgesini görmek, yapılandırılmış JSON'u rahatça göndermek ve kurcalarken bağlantıyı açık tutmak istediğiniz keşif testleri için yorucudur.
Apidog, bunun için özel olarak oluşturulmuş bir WebSocket istemcisine sahiptir. Bir ws:// veya wss:// URL'si girer, bağlanır ve gönderilen ve alınan her mesajı JSON sözdizimi vurgulamasıyla bir zaman çizelgesi görünümünde görürsünüz. Bağlantıları kaydedebilir, kimlik doğrulama için başlıklar ve sorgu parametreleri ayarlayabilir ve denemeler yaparken bağlantıyı canlı tutabilirsiniz. REST, GraphQL ve SOAP'ı aynı uygulamada işler, bu nedenle WebSocket testi, ayrı bir araçta değil, API çalışmalarınızın geri kalanıyla birlikte yer alır. Görsel bir zaman çizelgesiyle WebSocket uç noktalarını test etmek için Apidog'u indirin.
Bir GUI, yabancı bir WebSocket API'sini keşfederken, mesajların neden gelmediğini ayıklarken veya bir ekip arkadaşıyla tekrarlanabilir bir testi paylaşırken doğru seçimdir. Komut satırı, kontrolün denetimsiz çalışmasını istediğinizde doğru seçimdir. Çoğu mühendis, göreve göre seçim yaparak her ikisini de kullanır. GUI seçeneklerine daha geniş bir bakış açısı istiyorsanız, ücretsiz çevrimiçi API test araçları derlememiz WebSocket'i işleyen birkaçını içerir.
Basit bir WebSocket test kontrol listesi
- Yükseltmeyi onaylayın. Bağlantı HTTP 101 döndürmelidir. Dönmüyorsa, uç nokta, yol veya başlıklarınız yanlıştır.
- Kimlik doğrulamayı kontrol edin. Birçok WebSocket sunucusu, bir başlıkta veya sorgu parametresinde bir jeton bekler. Açılan ve hemen kapanan bir bağlantı genellikle reddedilen bir jeton anlamına gelir.
- Bilinen bir mesaj gönderin ve yanıtı doğrulayın. API'nizin anladığı gerçek bir yük kullanın ve yanıt şeklini onaylayın.
- Sunucu tarafından itilen mesajları doğrulayın. Bir kanala abone olun ve güncellemelerin sizden daha fazla istek gelmeden ulaştığını onaylayın.
- Kapanışı test edin. Bağlantıyı kapatın ve kapanış kodunu kontrol edin. Temiz bir kapanış 1000'dir; diğer kodlar belirli sorunları işaret eder.
- Hata yollarını test edin. Hatalı biçimli bir mesaj gönderin ve sunucunun sessizce düşmek yerine mantıklı bir şekilde yanıt verdiğini onaylayın.
Bunları tekrarlanabilir bir sete dönüştürmek için, API test paketleri oluşturma kılavuzumuz WebSocket akışları için de REST kadar geçerlidir.
Çalışmayan bir WebSocket bağlantısında hata ayıklama
Bir WebSocket bağlantısı başarısız olduğunda, nedeni neredeyse her zaman küçük bir problem grubundan biridir. Sırayla gözden geçirin.
URL şemasıyla başlayın. ws:// bekleyen bir sayfadan veya bağlamdan wss:// adresine yapılan bir bağlantı veya tersi, hemen başarısız olur. Tarayıcılar ayrıca HTTPS üzerinden sunulan bir sayfadan gelen ws:// bağlantısını da engeller, çünkü bu güvenli ve güvensiz içeriği karıştırır. Şemanın ortama uygun olduğunu onaylayın.
Ardından, el sıkışma yanıtını kontrol edin. HTTP 101 görmüyorsanız, sunucu yükseltmeyi asla kabul etmemiştir. 404, yolun yanlış olduğu anlamına gelir. 401 veya 403, kimlik doğrulamasının yükseltmeden önce başarısız olduğu anlamına gelir. 400 genellikle eksik veya hatalı biçimli bir yükseltme başlığı anlamına gelir. curl'ün --include bayrağı ve websocat'in ayrıntılı modu size bu yanıtı gösterir, böylece bir el sıkışma hatasını daha sonraki bir problemden ayırt edebilirsiniz.
El sıkışması başarılı olur ancak bağlantı saniyeler sonra düşerse, boşta kalma zaman aşımlarına ve ping veya pong çerçevelerine bakın. Birçok sunucu, hala hayatta olduğunu kanıtlamak için istemcinin ping çerçevelerini yanıtlamasını bekler ve sessiz kalan bağlantıları kapatırlar. Sunucunun önündeki bir proxy veya yük dengeleyici de kendi programına göre boşta kalan bağlantıları öldürebilir. Son olarak, kapanış kodunu okuyun. Kodlar RFC 6455'te tanımlanmıştır ve 1006 gibi bir kod, temiz bir el sıkışması olmayan anormal bir kapanışı işaret ederken, 1011 bir sunucu hatasını işaret eder. Kapanış kodu genellikle hangi tarafın pes ettiğini ve nedenini söyler.
WebSocket kontrollerini otomatikleştirme
Tek seferlik manuel bir test, bir uç noktanın bugün çalıştığını doğrular. Gelecek hafta bir regresyondan sizi korumaz. Bunun için WebSocket kontrolünün denetimsiz çalışması gerekir.
Komut satırı araçları bunu basitleştirir. Küçük bir betik, websocat ile bir bağlantı açabilir, bilinen bir mesaj gönderebilir, yanıtı yakalayabilir ve beklenen bir değerle karşılaştırabilir, ardından eşleşmezse sıfır olmayan bir değerle çıkabilir. Bu betik, diğer test adımları gibi bir CI pipeline'ına düşer. Apidog gibi senaryo çalıştırıcısı olan bir GUI aracı, gönderilen mesajlar ve yanıtlardaki doğrulamalar dahil olmak üzere bir WebSocket akışını kaydedebilir ve bir programa göre veya bir pipeline tetikleyicisinden yeniden oynatabilir.
Otomatik WebSocket testlerini odaklanmış tutun. Bağlantının yükseltildiğini doğrulayın, bilinen bir istek ve yanıt çiftini doğrulayın ve abone olunan bir kanalın bir zaman aşımı içinde en az bir itilen mesaj gönderdiğini doğrulayın. Uzun süreli bir bağlantının her olası mesajını doğrulamaya çalışmak, testi yavaş ve değişken hale getirir. Bir test durumunu keskin tutan aynı kısıtlama, bir WebSocket kontrolünü güvenilir tutar: tek bir açık şeyi test edin ve bunu iyi test edin.
Sıkça sorulan sorular
curl WebSocket bağlantılarını test edebilir mi?
Kısmen. curl 7.86 ve sonrası, el sıkışmayı tamamlayabilen ve temel mesajları değiş tokuş edebilen deneysel yerel WebSocket desteğine sahiptir, bu da bir uç noktanın erişilebilir olduğunu doğrulamak için yeterlidir. Birçok mesaj içeren etkileşimli oturumlar için gariptir. Gerçek WebSocket testi için websocat veya Apidog gibi bir GUI istemcisi daha uygun bir seçenektir.
ws ve wss arasındaki fark nedir?
ws:// şifrelenmemiş bir WebSocket bağlantısıdır ve wss:// TLS ile şifrelenmiştir, HTTP'nin HTTPS'ye karşılık gelen WebSocket eşdeğeridir. Yerel geliştirme dışındaki her şey için daima wss:// kullanın, çünkü ws:// mesajları düz metin olarak gönderir. Araçlar, şifreleme dışında iki URL'yi aynı şekilde ele alır.
WebSocket bağlantım neden açılıyor ve sonra hemen kapanıyor?
En yaygın neden kimlik doğrulamadır. Sunucu bir başlıkta veya sorgu parametresinde bir jeton bekliyor ve geçerli bir jeton alamıyorsa, TCP bağlantısını kabul eder ve sonra kapatır. Kapanış kodunu kontrol edin, jetonunuzu doğrulayın ve sunucunun beklediği şekilde gönderdiğinizi onaylayın.
WebSocket testi için websocat curl'den daha mı iyidir?
Özellikle WebSocket için, evet. websocat amaca yönelik olarak inşa edilmiştir, çerçeve protokolünü tam olarak anlar, etkileşimli oturumları, özel başlıkları ve mesajların içeri ve dışarı borulanmasını destekler. curl, WebSocket desteği hala deneysel olan genel bir HTTP aracıdır. Hızlı bir erişilebilirlik kontrolü için curl'ü ve gerçek test için websocat'i kullanın.
Sunucunun bir istek olmadan mesajları ittiğini nasıl test ederim?
Bağlantıyı açın, API gerektiriyorsa ilgili kanala veya olaya abone olun, ardından bekleyin ve izleyin. websocat ile itilen mesajlar geldikçe yazdırılır. Apidog gibi bir GUI istemcisi ile mesaj zaman çizelgesinde görünürler. Mesajların sizden başka bir girdi olmadan ulaştığını onaylayın, çünkü talep dışı teslimat WebSocket'in amacıdır.