How to drop to a lower osi layer?

Question

Is there a way I can initiate a higher level connection i.e. an http connection and then at some point "down grade" it to a lower layer or tcp? Basically, once the connection has been made with http I want to be able to just grab the socket and use it with my own custom protocol.

Answer 1

Basically, once the connection has been made with http I want to be able to just grab the socket and use it with my own custom protocol

You don't "downgrade" to a lower OSI layer in this case. Instead you define your own application level protocol which first consists of something similar to HTTP followed by whatever you need then. OSI layers are just an abstraction in thinking (i.e. deal with bytes at layer 4 TCP instead of structured messages at layer 7).

As for implementing your own protocol using existing HTTP libraries: if this is possible and how this is done fully depends on the HTTP library. Some keep the underlying TCP socket for their own and some might allow the developer to directly deal with it. Some allow the developer to just create HTTP request as string and parse HTTP response from string and keep the control of the TCP socket fully at the developer.

Answer 2

There are two answers, one for the general case, and one for HTTP. And it also depends on how you created the HTTP "connection" in the first place.

Most operating systems only provide abstractions (sockets) up to the TCP/UDP layer, and everything else above (i.e. the application layer protocols) is usually handled by – wait for it – the application. So when you're using e.g. an SSH client or an SMTP client or an IRC client, the app can always "drop down" to the raw TCP stream because that's what the app had in the first place. The app itself builds everything on top of the OS-provided TCP connection.

---

HTTP, being so widespread, is somewhat of an exception and does often have shared libraries (such as libcurl or python-requests) and even OS-provided abstractions (such as WinHTTP).

Libraries such as libcurl act as part of the application and just build on top of the same TCP sockets provided by the OS. Some of them do allow access to the underlying sockets; others do not. In any case, these are optional to use – some programs still prefer to handroll an HTTP client for no good reason.

But the other reason why HTTP is an exception is that the application does not normally initiate an "HTTP connection" in the first place. HTTP is a stateless protocol; most HTTP client libraries use request/response as the abstraction and only open TCP connections on demand. Multiple requests might share the underlying TCP connection, or they might not. (The protocol might be HTTP/1.1 or it might be HTTP/2.)

In other words, often there simply isn't a lower-layer connection anymore by the time you ask for one.

---

There are exceptions to that too. Many browsers and websites these days use websockets, which start as an ordinary HTTP request but switch to a duplex TCP-like stream connection afterwards. (This is not necessarily raw TCP, however – websockets might still use TLS and they might have their own framing layer. I think websockets over HTTP/2 inherit its framing.)