HTTP
wpisy (30)
- seria · 9 części
Warstwy HTTP w przeglądarce: od fetch() do QUIC
Dwie linie z fetch() zakrywają kilka warstw: browser API, semantykę HTTP, wire protocol i transport. Seria rozdziela je tak, żeby Network panel dał się czytać.
- Realtime w przeglądarce: od pollingu do WebTransport7/7
Polling, Streaming, SSE, WebSocket czy WebTransport?
Wybór wynika z modelu ruchu: świeżości danych, kierunku, częstotliwości, kolejności i niezawodności. Najprostszy poprawny mechanizm zwykle wygrywa.
- Realtime w przeglądarce: od pollingu do WebTransport6/7
WebTransport: streams i datagramy dla realtime nad HTTP/3
HTTP/3 i QUIC dają jednej sesji wiele niezależnych streamów oraz datagramy. Nie każde dane muszą dotrzeć niezawodnie i w kolejności.
- Realtime w przeglądarce: od pollingu do WebTransport5/7
WebSockets: trwały kanał komunikacji w obu kierunkach
Po handshake nie ma już requestów i odpowiedzi, tylko frames. Trwałe połączenie jest stanem, który dotyka load balancera, deployu i fan-outu między instancjami.
- Gateway API bez magii4/4
Migracja z ingress-nginx do Gateway API
Migracja z ingress-nginx nie jest mechaniczną translacją YAML-a. Najpierw trzeba oddzielić kontrakt aplikacji od zachowań konkretnego kontrolera.
- Realtime w przeglądarce: od pollingu do WebTransport4/7
Server-Sent Events: protokół zdarzeń nad HTTP streamingiem
Standardowy format zdarzeń i reconnect nad strumieniem HTTP. Last-Event-ID daje wznowienie, ale trwałości eventów w systemie już nie załatwia.
- Gateway API bez magii3/4
GatewayClass: kontrakt z implementacją
GatewayClass nie jest nazwą środowiska. To punkt, w którym Kubernetes Gateway API spotyka się z konkretnym kontrolerem.
- Gateway API bez magii2/4
Gateway to nie zawsze to samo gateway
Słowo gateway miesza produkt, rolę sieciową i Kubernetes API. Bez tego rozdziału łatwo porównywać rzeczy z różnych warstw.
- Realtime w przeglądarce: od pollingu do WebTransport3/7
HTTP Streaming: jedna odpowiedź, wiele fragmentów danych
Odpowiedź może powstawać w czasie. Chunk transportowy nie jest wiadomością, więc framing i backpressure stają się sprawą aplikacji.
- Gateway API bez magii1/4
Od Service do Gateway API: skąd wziął się problem
Ingress nie przegrał dlatego, że był zły. Przegrał, bo jego mała specyfikacja nie miała języka na produkcyjne zachowania HTTP.