20

I am trying to understand tcp connections between a browser and a web server. I have a web server running on my local machine, and can browse to it just fine, as expected, using localhost:3000 or 127.0.0.1:3000. (I am running "rails s"and WEBrick.)

I wanted to put a software intermediary between the browser and the web server, and so began experimenting with socat. The following works just fine:

socat TCP-LISTEN:8080,fork TCP:localhost:3000

I can browse to localhost:8080 and things work as expected. However, if I omit the ",fork" argument like so,

socat TCP-LISTEN:8080 TCP:localhost:3000

the local rails web site is quite broken looking in the browser.

Why is that fork argument necessary? Why wouldn't a browser <--> web server connection work without it?

ks1322
  • 33,961
  • 14
  • 109
  • 164
user691307
  • 485
  • 2
  • 5
  • 15

1 Answers1

43

Without the fork, socat will accept a single TCP connection, forward data bidirectionally between the two endpoints for as long as that connection remains open, then exit. You can see this yourself easily:

  • Run socat in one terminal window
  • Telnet to localhost 8080 in another terminal window. It connects to the socat instance.
  • Telnet to localhost 8080 in a third terminal window. You get a connection refused error, because socat is not listening for new connections anymore: it has moved on to servicing the one it already got.
  • Type an HTTP request into the second terminal window. You'll get an HTTP response, and then socat will exit as the connection is closed.

The fork option just makes it fork a new child to process the newly accepted connection while the parent goes back to waiting for new connections.

socat's use of fork() rather than something more sophisticated like preforking or connection pooling is the reason you wouldn't want to implement high-performance middleware with socat!

Celada
  • 21,627
  • 4
  • 64
  • 78
  • What I am actually trying to do is write my own "in-between" program between a browser and a web server. It opens a client TCP connection to the web server, and a "listen" TCP server on another port. The browser opens a client connection to the listen port. So on the one browser side, there is a sequence of multiple TCP sessions that open and close. But on the web server side, there is just one established TCP connection. That fails. I'm thinking my homebrew intermediary could close and re-open the web server connection each time a client starts and stops a tcp connection. sound ok? – user691307 Mar 09 '12 at 18:50
  • Sounds OK, and also the simplest thing to do. Your code opens a new connection to the server every time the HTTP user agent does, and closes them at the same time too. That's a lot less work than interpreting the contents of the HTTP requests to figure out when you might or might not be able to tweak the contents to aggregate several connections form the client onto one connection towards the server. That way lies the implementation of a full-fledged HTTP proxy server! – Celada Mar 10 '12 at 15:46
  • Thanks for explanation. Is this to mean that socat with fork and piping to tee to a single file will clobber the outputs ? – daparic Feb 24 '19 at 10:49