29 Jun
2022
29 Jun
'22
4:45 a.m.
On Tue, Jun 28, 2022 at 10:05:26AM -0700, Adam Thornton wrote:
And I think we already have the answer about what the abstraction is, albeit at an
application rather than the kernel level.
To answer Rob's question: I think the abstraction is now much farther up the stack.
To a pretty good first approximation, almost all applications simply definte their own
semantics on top of HTTP(S) (OK, OK, Websockets muddy the waters again) and three-to-five
verbs. There's an incantation to establish a circuit (or a "session" if
you're under the age of 50, I guess), and then you GET, DELETE, and at least one of
PUT/POST/PATCH, for "read", "unlink", and "write". This
does seem to be a more record-oriented (kids these days get snippy if you call them
"records" rather than "objects" but w/e) format than a stream of bytes
(or at least you put an abstraction layer in between your records and the stream-of-octets
that's happening).
Yes it is effectively records, or RPCs w/o state between requests. So akin to DNS queries
over UDP, rather than DNS queries over TCP.
As the whole HTTP model allows for proxies, at which point the request (GET, HEAD, POST,
etc) includes
an endpoint address (DNS name and port) and path at that endpoint. Having
'session' state is built at
a level above HTTP, by cookies or redirecting to magic URIs encoding the session ID after
the query (the '?').
The fact that this all happens to run over a TCP connection, simply means that we have
stacked sets of
VCs. An application VC on top of a connectionless HTTP on top of a TCP 'VC'.
One could argue that
Websockets simplifies this by ripping out the HTTP layer, and having the top VC then just
being message
framing within the TCP session.
(Ignoring for the moment TLS on top of TCP, or HTTP/3 being on top of QUIC, hence UDP)
This is certainly not efficient at a wire protocol
level, but it's a fairly small cognitive burden for people who just want to write
applications that communicate with each other.
Sort of, in that I recently investigated the Go HTTP client/server APIs as someone was
asking us about
implementing a MiTM HTTP(S) "firewall". Depending upon how one deals with it,
it hides the VCs and exposes
the connectionless RPCs.
With such a MiTM in place, the 'nice' RPC in a session is effectivly forced back
to the 'nasty' RPC in datagrams, even though the endpoints may be unaware, but
they already include the whole datagram remote address in the request. Responses come
back by 'magic' without explicit address.
So maybe from that perspective one could model HTTP request/response as RPCs over SVCs,
those being raised and torn down for each exchange.
DF