You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
|`TcpConnectionStage`| TCP transport with connection reuse (from Servus.Akka) — returns leases to the pool on keep-alive, requests new connections on close |
54
54
55
55
**Keep-alive handling:**
56
56
57
-
After decoding each response, `Http11ConnectionStage` evaluates the `Connection` header internally:
57
+
After decoding each response, `Http11ClientConnectionStage` evaluates the `Connection` header internally:
58
58
59
59
-`Connection: keep-alive` (or HTTP/1.1 default) → the connection lease is returned to the connection manager actor for reuse
60
60
-`Connection: close` → the lease is released without returning it to the idle queue; the next request triggers a new connection
61
61
62
62
**Pipelining:**
63
63
64
-
`Http11ConnectionStage` uses a FIFO queue internally to correlate requests with responses, enabling HTTP/1.1 pipelining: multiple requests can be in-flight on the same connection, and responses are matched to requests in order.
64
+
`Http11ClientConnectionStage` uses a FIFO queue internally to correlate requests with responses, enabling HTTP/1.1 pipelining: multiple requests can be in-flight on the same connection, and responses are matched to requests in order.
65
65
66
66
---
67
67
@@ -76,13 +76,13 @@ HTTP/2 provides **stream multiplexing** — many logical requests share a single
`Http20ConnectionStage` tracks both **connection-level** and **stream-level** window sizes. It emits `WINDOW_UPDATE` frames when the consumer reads data, preventing the remote server from stalling. The Akka.Streams backpressure demand signal is translated into HTTP/2 flow-control credits.
94
+
`Http20ClientConnectionStage` tracks both **connection-level** and **stream-level** window sizes. It emits `WINDOW_UPDATE` frames when the consumer reads data, preventing the remote server from stalling. The Akka.Streams backpressure demand signal is translated into HTTP/2 flow-control credits.
95
95
96
96
---
97
97
@@ -106,13 +106,13 @@ HTTP/3 runs over **QUIC** instead of TCP. Each request uses an independent QUIC
|`Http30ConnectionStage`| Central unified stage: QPACK-encodes request headers, emits `HEADERS` + `DATA` frames over QUIC streams, handles frame encoding/decoding using QUIC variable-length encoding, manages connection-level frames (`SETTINGS`, `GOAWAY`), handles stream multiplexing and lifecycle, assembles per-stream frames into `HttpResponseMessage`, and QPACK-decodes response headers |
115
+
|`Http30ClientConnectionStage`| Central unified stage: QPACK-encodes request headers, emits `HEADERS` + `DATA` frames over QUIC streams, handles frame encoding/decoding using QUIC variable-length encoding, manages connection-level frames (`SETTINGS`, `GOAWAY`), handles stream multiplexing and lifecycle, assembles per-stream frames into `HttpResponseMessage`, and QPACK-decodes response headers |
116
116
|`QuicConnectionStage`| QUIC transport (from Servus.Akka) — acquires a QUIC connection from the manager actor, writes/reads bytes over QUIC streams |
117
117
118
118
**QPACK header compression:**
@@ -136,7 +136,7 @@ When a connection arrives at TurboHTTP Server, the server mirrors the client arc
136
136
|`Http20ServerEngine`| HTTP/2 | Stream multiplexing over a single connection; uses HPACK header compression; flow-control windows at connection and stream level |
Each server engine implements `IServerProtocolEngine` and registers itself with the `ProtocolRouter`. When a connection arrives, the router detects the protocol from the initial bytes (HTTP/1.x format, HTTP/2 preface `PRI * HTTP/2.0`, or QUIC Initial packet) and routes the connection to the appropriate engine's state machine for the duration of that connection.
139
+
Each server engine implements `IServerProtocolEngine`. When a connection arrives, the `NegotiatingServerEngine` delegates to `ProtocolRouter` to detect the protocol from ALPN negotiation (TLS) or the initial bytes (HTTP/1.x format, HTTP/2 preface `PRI * HTTP/2.0`, or QUIC Initial packet) and routes the connection to the appropriate version-specific engine for the duration of that connection.
Copy file name to clipboardExpand all lines: docs/architecture/pipeline.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -59,7 +59,7 @@ If the cache entry is stale but has an `ETag` or `Last-Modified` validator, `Cac
59
59
60
60
### 2. Keep-Alive Feedback (HTTP/1.1 only)
61
61
62
-
After each HTTP/1.1 response, `Http11ConnectionStage` evaluates the `Connection` header internally and decides whether to reuse the TCP connection for the next request or close it and request a new one from the connection manager actor.
62
+
After each HTTP/1.1 response, `Http11ClientConnectionStage` evaluates the `Connection` header internally and decides whether to reuse the TCP connection for the next request or close it and request a new one from the connection manager actor.
63
63
64
64
This loop is invisible to the caller — the `Engine` and higher layers see only a continuous stream of `HttpResponseMessage` objects.
65
65
@@ -73,7 +73,7 @@ When `RetryBidiStage` decides a request should be retried, it re-enters the pipe
73
73
74
74
### 5. QPACK Table Sync (HTTP/3 only)
75
75
76
-
HTTP/3 uses QPACK for header compression. The server sends decoder table updates on a dedicated QUIC stream; `Http30ConnectionStage` processes these updates internally to keep the encoder and decoder dynamic tables in sync.
76
+
HTTP/3 uses QPACK for header compression. The server sends decoder table updates on a dedicated QUIC stream; `Http30ClientConnectionStage` processes these updates internally to keep the encoder and decoder dynamic tables in sync.
Copy file name to clipboardExpand all lines: docs/architecture/scenarios.md
+16-16Lines changed: 16 additions & 16 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,14 +18,14 @@ Here's what happens when you send a request with different HTTP versions. The de
18
18
4.`RedirectBidiStage` and `CookieBidiStage` inject matching cookies from `CookieJar`.
19
19
5.`CacheBidiStage` checks the cache — on a miss, the request continues.
20
20
6.`ContentEncodingBidiStage` compresses the request body if a compression policy is configured.
21
-
7.`Engine` routes the request to `Http10Engine`.
22
-
8.`Http10ConnectionStage` serialises the request to bytes with `Connection: close`.
21
+
7.`Engine` routes the request to `Http10ClientEngine`.
22
+
8.`Http10ClientConnectionStage` serialises the request to bytes with `Connection: close`.
23
23
9.`TcpConnectionStage` (from Servus.Akka) requests a connection lease from `TcpConnectionManagerActor` and sends the bytes over TCP.
24
24
25
25
### Response Path
26
26
27
-
10. The server's response bytes arrive via TCP and flow through `TcpConnectionStage` into `Http10ConnectionStage`.
28
-
11.`Http10ConnectionStage` parses the HTTP/1.0 response (body length determined by `Content-Length` or EOF) and correlates it to the pending request.
27
+
10. The server's response bytes arrive via TCP and flow through `TcpConnectionStage` into `Http10ClientConnectionStage`.
28
+
11.`Http10ClientConnectionStage` parses the HTTP/1.0 response (body length determined by `Content-Length` or EOF) and correlates it to the pending request.
29
29
12.`ContentEncodingBidiStage` decompresses the body if needed.
30
30
13.`CacheBidiStage` caches the response if it is cacheable.
31
31
14.`RetryBidiStage` passes the response through (no retry needed for a successful response).
@@ -50,7 +50,7 @@ HTTP/1.1 follows the same request/response path as HTTP/1.0 except for one criti
50
50
51
51
### Keep-Alive Handling
52
52
53
-
After `Http11ConnectionStage` decodes the response and correlates it to the pending request, it evaluates the `Connection` header internally:
53
+
After `Http11ClientConnectionStage` decodes the response and correlates it to the pending request, it evaluates the `Connection` header internally:
54
54
55
55
-`Connection: keep-alive` (or HTTP/1.1 default) → the connection lease is returned to `TcpConnectionManagerActor` for reuse
56
56
-`Connection: close` → the lease is released without returning it to the idle queue; the next request triggers a new connection
@@ -59,7 +59,7 @@ On **reuse**, the next request to the same host can skip connection setup entire
59
59
60
60
### Pipelining
61
61
62
-
`Http11ConnectionStage` uses a FIFO queue internally to correlate requests with responses, enabling HTTP/1.1 pipelining: multiple requests can be in-flight on the same connection simultaneously, and responses are matched to requests in order.
62
+
`Http11ClientConnectionStage` uses a FIFO queue internally to correlate requests with responses, enabling HTTP/1.1 pipelining: multiple requests can be in-flight on the same connection simultaneously, and responses are matched to requests in order.
63
63
64
64
---
65
65
@@ -73,13 +73,13 @@ HTTP/2 is fundamentally different from HTTP/1.x. A single TCP connection carries
73
73
74
74
### Request Framing
75
75
76
-
1.`Http20ConnectionStage` assigns the next available stream ID (1, 3, 5, …), HPACK-encodes the request headers into a `HEADERS` frame, and serialises the body (if any) into `DATA` frame(s).
77
-
2.`Http20ConnectionStage` applies connection-level and stream-level flow control — it will withhold frames if the server's receive window is exhausted.
76
+
1.`Http20ClientConnectionStage` assigns the next available stream ID (1, 3, 5, …), HPACK-encodes the request headers into a `HEADERS` frame, and serialises the body (if any) into `DATA` frame(s).
77
+
2.`Http20ClientConnectionStage` applies connection-level and stream-level flow control — it will withhold frames if the server's receive window is exhausted.
78
78
3.`TcpConnectionStage` (from Servus.Akka) sends the frames over TCP (injecting the HTTP/2 connection preface on the first connection).
79
79
80
80
### Connection-Level Frames
81
81
82
-
While request/response streams are active, `Http20ConnectionStage` also handles:
82
+
While request/response streams are active, `Http20ClientConnectionStage` also handles:
83
83
84
84
-**`SETTINGS`** — initial and updated connection parameters; acknowledges server `SETTINGS` with `SETTINGS ACK`
85
85
-**`PING`** — round-trip latency measurement; responds to server `PING` with `PING ACK`
@@ -88,8 +88,8 @@ While request/response streams are active, `Http20ConnectionStage` also handles:
88
88
89
89
### Response Assembly
90
90
91
-
4. Raw bytes from TCP flow through `TcpConnectionStage` into `Http20ConnectionStage`.
92
-
5.`Http20ConnectionStage` parses the bytes into HTTP/2 frames (handling partial frames across TCP boundaries), routes connection-level frames to internal handlers, assembles per-stream `HEADERS` + `DATA` frames into an `HttpResponseMessage`, HPACK-decodes response headers, and correlates each assembled response back to its pending request using the stream ID.
91
+
4. Raw bytes from TCP flow through `TcpConnectionStage` into `Http20ClientConnectionStage`.
92
+
5.`Http20ClientConnectionStage` parses the bytes into HTTP/2 frames (handling partial frames across TCP boundaries), routes connection-level frames to internal handlers, assembles per-stream `HEADERS` + `DATA` frames into an `HttpResponseMessage`, HPACK-decodes response headers, and correlates each assembled response back to its pending request using the stream ID.
93
93
6. The response continues through `ContentEncodingBidiStage`, `CacheBidiStage`, `RetryBidiStage`, `CookieBidiStage`, and `RedirectBidiStage` — the same response chain as HTTP/1.x.
94
94
95
95
### Stream ID Exhaustion
@@ -108,21 +108,21 @@ HTTP/3 replaces TCP with **QUIC**, a UDP-based transport that provides built-in
108
108
109
109
### Request Framing
110
110
111
-
1.`Http30ConnectionStage` QPACK-encodes the request headers into a `HEADERS` frame, and the body (if any) into `DATA` frame(s).
112
-
2.`Http30ConnectionStage` manages connection-level concerns — `SETTINGS`, `GOAWAY`, and stream lifecycle.
111
+
1.`Http30ClientConnectionStage` QPACK-encodes the request headers into a `HEADERS` frame, and the body (if any) into `DATA` frame(s).
112
+
2.`Http30ClientConnectionStage` manages connection-level concerns — `SETTINGS`, `GOAWAY`, and stream lifecycle.
113
113
3.`QuicConnectionStage` (from Servus.Akka) requests a QUIC connection from `QuicConnectionManagerActor` and sends the bytes over the network.
114
114
115
115
### Connection-Level Frames
116
116
117
-
While request/response streams are active, `Http30ConnectionStage` handles:
117
+
While request/response streams are active, `Http30ClientConnectionStage` handles:
118
118
119
119
-**`SETTINGS`** — connection parameters exchanged at startup
120
120
-**`GOAWAY`** — graceful shutdown; after receiving `GOAWAY`, no new streams are opened on this connection
121
121
122
122
### Response Assembly
123
123
124
-
4. Raw bytes from QUIC flow through `QuicConnectionStage` into `Http30ConnectionStage`.
125
-
5.`Http30ConnectionStage` parses the bytes into HTTP/3 frames, routes connection-level frames to internal handlers, assembles per-stream `HEADERS` + `DATA` frames into an `HttpResponseMessage`, and QPACK-decodes response headers.
124
+
4. Raw bytes from QUIC flow through `QuicConnectionStage` into `Http30ClientConnectionStage`.
125
+
5.`Http30ClientConnectionStage` parses the bytes into HTTP/3 frames, routes connection-level frames to internal handlers, assembles per-stream `HEADERS` + `DATA` frames into an `HttpResponseMessage`, and QPACK-decodes response headers.
126
126
6. The response continues through `ContentEncodingBidiStage`, `CacheBidiStage`, `RetryBidiStage`, `CookieBidiStage`, and `RedirectBidiStage` — the same response chain as HTTP/1.x and HTTP/2.
0 commit comments