Networking
wpisy (13)
- Warstwy HTTP w przeglądarce: od fetch() do QUIC9/9
Od fetch() do pierwszego bajtu
Cały lifecycle w jednym miejscu: polityki przeglądarki, cache, connection, wire format, headers i body. Dopiero z tym modelem Network panel odpowiada na…
- Warstwy HTTP w przeglądarce: od fetch() do QUIC8/9
HTTP/3 i QUIC: ten sam HTTP, inny transport
QUIC usuwa transportowy head-of-line blocking i taniej zestawia sesję, ale nie naprawia zależności, które frontend tworzy własnym kodem.
- Warstwy HTTP w przeglądarce: od fetch() do QUIC7/9
HTTP/2: multiplexing zmienił frontendowy network model
Ta sama semantyka HTTP, inny wire format. Wiele równoległych requestów nie znaczy wielu socketów, a niezależność streamów kończy się na TCP.
- Warstwy HTTP w przeglądarce: od fetch() do QUIC6/9
HTTP/1.1: skąd wzięły się waterfall i bundling
Bundling, sprite'y i domain sharding były odpowiedzią na koszt wielu requestów. Architektura frontendu dopasowała się do ograniczeń protokołu.
- Warstwy HTTP w przeglądarce: od fetch() do QUIC5/9
Connections: dlaczego jeden fetch() nie oznacza jednego połączenia
Request i połączenie mają różny lifecycle. Pulą połączeń zarządza przeglądarka, a frontend wpływa na nią tylko przez architekturę zasobów i originów.
- 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 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.
- 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.
- 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.