Same port for multiple functionalities?

[PickleRick]

Big warning at the beginning - it's not a question of "should I do that", it's not a question of best practices. I'm not going to do something like that in production (and probably not even in lab environment). It's purely a theoretical question.

As we all know, there is usually a separate port for deployment server, separate one for HEC, separate one for REST calls between SH(s) and indexer(s). I was wondering how much of those functionalities could be squashed into a single port (possibly with a help of an external reverse-proxy). I suppose HEC and DS could be really good candidates to squish together. Any others?

Just to make myself absolutely clear - I don't want it to be quick and well-performing. I'm just wondering if it would work at all.

[richgalloway]

I suspect it would not work at all.  The software probably is depending on the network to keep different types of requests apart.  IOW, there is no logic to read a packet, determine its type (HEC, management, etc), and route it to the appropriate process/thread.

[PickleRick]

OK. Let me be more specific. I know that on the server's side you bind DS to one port, HEC to another and so on.

But if you put a rev-proxy in front of the server and route requests to proper background ports depending on the context path?

[richgalloway]

I be impressed if a reverse proxy could correct separate and route the requests properly, but I suppose it's possible.

[PickleRick]

You can of course route the requests based on the Host header so as long as multiple names resolve to the same IP it should be pretty easy (I have multiple Splunk components - including multiple SH-clusters - WebUIs configured behind a single proxy).