WebSocket टेस्टिंग

यह क्यों ज़रूरी है

हर message का कोई status code नहीं होता, इसलिए खोया हुआ, दोहराया गया या गलत क्रम में आया update कोई error नहीं देता: customer बस "delivered" के बाद "picked up" देखता है, या एक chat message दो बार। और क्योंकि connections घंटों खुले रहते हैं, कुछ failures quick check में कभी नहीं दिखतीं: idle connections काटने वाला proxy, connection के बीच में expire होता session, हर client के साथ बढ़ती server memory।

Tester का सवाल "यह request क्या लौटाती है?" से बदलकर हो जाता है "क्या पहुँचना चाहिए, किस क्रम में, कितने समय में, और drop के बाद क्या होता है?"

Opening handshake: HTTP से WebSocket तक

Client एक HTTP/1.1 GET भेजता है जिसमें Upgrade: websocket, Sec-WebSocket-Version: 13 और एक random Sec-WebSocket-Key होती है। Accept करने वाला server 101 Switching Protocols और उसी key से निकली Sec-WebSocket-Accept value लौटाता है; उसके बाद वही TCP connection WebSocket frames ले जाता है। Production में ws:// नहीं, TLS वाला wss:// होना चाहिए।

इस HTTP/1.1 handshake में कोई और status मतलब WebSocket खुला ही नहीं (HTTP/2 पर RFC 8441 इसकी जगह CONNECT request और 200 जवाब इस्तेमाल करता है), इसलिए access rules यहीं टेस्ट होते हैं। Cookies handshake के साथ जाती हैं, और RFC 6455 कहता है कि अगर Origin header ऐसी site बताए जिसे server स्वीकार नहीं करता, तो server को 403 लौटाना चाहिए। Browser scripts custom headers नहीं जोड़ सकतीं, इसलिए token अक्सर URL में जाता है, जहाँ वह logs में पहुँच सकता है। Script को rejected handshake का status कभी नहीं दिखता, सिर्फ़ close code 1006 वाला failed connection; असली status developer tools के Network panel में पढ़ें।

• Session नहीं, expired session या access नहीं: 101 नहीं, बल्कि contract में लिखा 401 या 403।
• ऐसा origin जिसे server स्वीकार नहीं करता: 403। Browser हमेशा उस page का origin भेजता है जिसमें वह चल रहा है, इसलिए किसी दूसरी site से, जैसे WebSocket Tester से, connect करना पहले से ही foreign origin का test है; गायब या नकली Origin के लिए browser के बाहर का client चाहिए। सिर्फ़ उन systems को टेस्ट करें जो आपके हैं या जिन्हें टेस्ट करने की आपको लिखित अनुमति है।
• HTTPS पर served page जो ws:// खोले: browser इसे mixed content मानकर block करता है।

GET /live HTTP/1.1
Host: shop.example.test
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
Origin: https://shop.example.test

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

आज़माएँ: WebSocket टेस्टर

Messages, control frames और close codes

Data frames में चलता है। Message text (UTF-8) या binary होता है और कई frames में फैल सकता है। Ping control frame का जवाब pong से देना ज़रूरी है; browsers यह अपने-आप करते हैं पर दोनों को scripts से छिपाते हैं, इसलिए applications अक्सर अपना heartbeat message जोड़ती हैं। Built-in acknowledgements नहीं होते: अगर client को जानना है कि message process हुआ, तो application एक reply तय करती है, आम तौर पर id लौटाकर।

Messages को REST body की तरह टेस्ट करें: required fields, types, अनजाने message types, malformed JSON, और size limit व उससे एक byte ऊपर। कोई भी पक्ष close frame से connection खत्म करता है, जिसमें आम तौर पर code और optional reason होते हैं; दूसरा पक्ष अपने close frame से जवाब देता है। RFC 6455 के सबसे आम codes:

• 1000 normal closure; 1001 going away, जैसे server का बंद होना या browser का page छोड़ना।
• 1003 ऐसा data type जिसे endpoint स्वीकार नहीं करता; 1007 message type से मेल न खाता data, जैसे text में invalid UTF-8; 1008 policy violation; 1009 message बहुत बड़ा; 1011 server में unexpected condition, यानी 500 का समकक्ष।
• 1005 और 1006 कभी close frame में भेजे नहीं जाते: endpoint खुद 1005 तब बताता है जब उसे मिले close frame में code न हो, और 1006 तब जब connection बिना close frame के खत्म हो, जैसे network drop, killed process या proxy timeout के बाद।
• 4000 से 4999 तक के codes private use के लिए हैं: कोई API expired session के लिए 4401 तय कर सकती है, और उसका मतलब वही है जो उस API का documentation कहता है।

आज़माएँ: JSON Schema वैलिडेटर आज़माएँ: JSON फ़ॉर्मेटर

Ordering और reconnection की टेस्टिंग

एक connection पर frames उसी क्रम में पहुँचते हैं जिसमें भेजे गए; WebSocket TCP पर चलता है और कुछ भी उनका क्रम नहीं बदलता। Ordering defects application से आते हैं: कई server workers का publish करना, reconnect के बाद replay, client में asynchronous handling। हर message में sequence number test को जाँचने के लिए कुछ देता है।

Reconnection application का काम है। RFC 6455 सलाह देता है कि पहली कोशिश से पहले random delay हो और हर failure के बाद लंबा delay (back-off), ताकि हज़ारों clients recover हो रहे server पर एक साथ न टूट पड़ें। Reconnect के बाद client को फिर authenticate करना, फिर subscribe करना और छूटे messages पूरे करने होते हैं।

• Ordering: numbered messages की एक burst भेजें, और दो clients से एक साथ events; हर receiver को एक ही क्रम दिखे, बिना gaps या duplicates के।
• Drop: session के बीच network काटें (Wi-Fi बंद करें या proxy रोकें), events होने दें, फिर network लौटाएँ; हर छूटा update ठीक एक बार दिखे।
• Idle: proxy timeout से ज़्यादा देर चुप रहें; heartbeat connection खुला रखे, या client recover करे।
• Connected रहते session expire या access revoke हो: server private data भेजना बंद करे, और client अंतहीन reconnect की जगह user से sign in करवाए।

Load में WebSockets

यहाँ requests per second से ज़्यादा मायने रखते हैं एक साथ खुले connections, नए handshakes की दर, प्रति second deliver होते messages, और event से हर subscriber तक पहुँचने का delay। हर खुला connection server और हर proxy पर memory और एक socket रोकता है, चुप रहने पर भी। k6 और Gatling जैसे tools WebSocket clients script कर सकते हैं; load सिर्फ़ उन्हीं environments पर डालें जिनकी आपको अनुमति है।

• अपेक्षित peak connections तक ramp up करें और वहाँ टिके रहें, हर simulated client को असली users की तरह अपना test user और token देकर; failed handshakes और प्रति connection memory record करें।
• Fan-out: एक event हज़ारों subscribers तक; delivery latency median और 95th percentile (वह समय जिसके भीतर 95% deliveries पूरी होती हैं) पर report करें, एक ही machine की clock या synchronised clocks से नापकर।
• Reconnection storm: deployment की तरह सारे connections एक साथ गिराएँ; back-off reconnects को फैलाए और service recover हो।
• Slow consumers और soak (normal load पर लंबा run): धीरे पढ़ने वाला client server से बिना limit messages queue न करवाए, और घंटों में memory न बढ़े।

आज़माएँ: लोड टेस्ट डेटा जनरेटर

Worked example: live order tracking feed

Delivery app का contract: seq हर update पर एक बढ़ता है और status कभी पीछे नहीं जाता; कुछ न बदले तो हर 20 seconds में heartbeat आता है; reconnect के बाद client अपना lastSeq भेजता है और server सिर्फ़ बड़े seq वाले updates replay करता है; close codes हैं 1000 (user ने tracking बंद की), 1008 (invalid message) और 4401 (session expired, reconnect नहीं)। Sample में -> client से server और <- server से client है।

इससे निकली test conditions, हर एक frame log में दिखने वाली:

• दूसरे customer के order B-2077 को subscribe करने पर उसका कोई update न आए। Contract यह नहीं बताता कि server error message देगा या close code: यह test basis का gap है, जिसे पहले team के साथ तय करें।
• बिना orderId का subscribe, या ऐसा text जो JSON नहीं है, 1008 से close हो; 1011 का मतलब है कि server गलत input पर fail हुआ।
• एक मिनट तक कुछ न बदले तो लगभग हर 20 seconds में heartbeat आए और connection खुला रहे।
• seq 1 के बाद network काटें, order दो बार आगे बढ़ाएँ, network लौटाएँ: client lastSeq 1 के साथ फिर subscribe करे और 2 व 3 एक बार, क्रम से पाए।
• Session expire होने पर client को 4401 मिले, वह reconnect बंद करे और user से sign in करवाए।

-> {"type":"subscribe","orderId":"A-1042","lastSeq":0}
<- {"type":"subscribed","orderId":"A-1042"}
<- {"type":"status","orderId":"A-1042","seq":1,"status":"accepted"}
<- {"type":"heartbeat"}
<- {"type":"status","orderId":"A-1042","seq":2,"status":"picked_up"}
<- {"type":"status","orderId":"A-1042","seq":3,"status":"delivered"}

आज़माएँ: WebSocket टेस्टर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• RFC 6455: The WebSocket ProtocolIETF · 2011HTTP पर WebSocket हैंडशेक, फ़्रेमिंग, मास्किंग, ping/pong और क्लोज़ कोड।
• The WebSocket API — MDNMDN Web Docs (Mozilla)ब्राउज़र का WebSocket API: कनेक्शन खोलना, मैसेज भेजना और क्लोज़ इवेंट संभालना।
• OWASP Web Security Testing Guide (WSTG)OWASP Foundationवेब एप्लिकेशन और API की सुरक्षा कमज़ोरियों को परखने की संदर्भ कार्यप्रणाली, एक-एक टेस्ट के रूप में।