Jedno żądanie, jeden wynik: laboratorium WebSocket
Interaktywna analiza identyfikatorów żądań, limitów czasu i obsługi duplikatów oraz granic, dzięki którym mała symulacja jest użyteczna.
Lab Projektowanie protokołów · Ukończony
WebSocket: eksperyment z żądaniami i odpowiedziami
Interaktywny Lab o identyfikatorach żądań, limitach czasu, błędach serwera i duplikatach. Zmieniaj warunki i obserwuj wynik każdej operacji.
Wypróbuj eksperyment ↓- Rola
- Projektant i inżynier
- Okres
- wrz 2026
- Technologie
- TypeScript · Astro · Web Components
Lab / 01
WebSocket: żądanie i odpowiedź
Co się stanie, gdy odpowiedź się spóźni, zwróci błąd lub dotrze dwa razy? Zmień warunki, wyślij żądanie i obserwuj wynik.
Symulacja lokalna w przeglądarce · bez połączenia z serwerem
- Oczekujące
- 0
- Udane
- 0
- Błąd
- 0
- Limit czasu
- 0
| ID żądania | Status | Opóźnienie / limit | Dod. kopie |
|---|
Nie ma jeszcze żądań. Wybierz scenariusz lub ustaw własne warunki.
Dziennik zdarzeń · najnowsze na górze
Do 40 operacji i 100 ostatnich zdarzeń w jednym przebiegu. Wyczyść przebieg, aby zacząć ponownie.
Problem
Kanał wiadomości nie określa, jak produkt powinien dopasowywać odpowiedzi, kończyć oczekiwanie i obsługiwać powtórzone żądania. Potrzebny jest jawny protokół aplikacji.
Ograniczenia
- Działa na statycznej stronie bez backendu i zewnętrznego połączenia.
- Pokazuje zachowanie aplikacji, a nie wydajność sieci czy pełny cykl życia WebSocket.
Moja rola
Zbudowałem lokalną symulację w przeglądarce, która pokazuje cykl życia żądań dzięki ustawieniom warunków i dziennikowi zdarzeń.
Kluczowe decyzje
Dopasowanie przez ID żądania
Każda operacja ma unikalny ID. Duplikaty zachowują go i pozostają jedną operacją logiczną.
Jeden wynik operacji
Sukces, błąd aplikacji lub limit czasu kończą oczekiwanie. Spóźnione i dodatkowe odpowiedzi pozostają w dzienniku, ale nie zmieniają wyniku.
Ponowne użycie wyniku serwera
Symulowany serwer oblicza jeden wynik na ID. Kopie odtwarzają go bez ponownego wykonania. To model edukacyjny, a nie trwały magazyn kluczy idempotencji.
Rezultaty
- Cztery stany, konfigurowalne opóźnienie i błędy, duplikaty oraz gotowe scenariusze.
- Do 40 operacji i 100 ostatnich zdarzeń; czyszczenie anuluje wszystkie zegary.
Wnioski
- Limit czasu kończy oczekiwanie klienta, ale nie dowodzi, że serwer niczego nie wykonał.
- Odrzucanie dodatkowych odpowiedzi przez klienta i idempotencja serwera rozwiązują różne części problemu.
Trzy porównania
- Wyślij żądanie w scenariuszu Pomyślny wynik, a potem wyślij kolejne z mniejszym opóźnieniem, zanim pierwsze się zakończy. Kolejność zakończenia może różnić się od kolejności wysłania.
- Wybierz Spóźniona odpowiedź i wyślij żądanie. Operacja przekroczy limit czasu; późniejsza odpowiedź trafi do dziennika i zostanie zignorowana.
- Wybierz Duplikaty żądań. Trzy dostarczenia użyją jednego ID, jednego wykonania na serwerze i jednego wyniku na kliencie.
Błędy oznaczają tu odpowiedzi aplikacji, a nie utratę pakietów. Model pomija nawiązywanie połączenia, ponowne łączenie, uwierzytelnianie i trwałe przechowywanie. Artykuł towarzyszący wyjaśnia znaczenie tych granic.