Dotaz: 3 http servery na jednom porte

[Compton]

Mam na jednom porte pustene 2 HTTP servery su to nase custom riesenia, ktore sme si napisali sami (bezia tam 2 weby ktorych serverova cast je v C++)

No a k tomu som teraz chcel pustit na rovnakom porte 80 aj XAMPP s PHP 7.3 X64 a servovat tam PHP stranku. Ale XAMPP odmieta pustit Apache pise ze port je uz obsadeny.

Nase 2 servery si navzajom rozumeju preco Apache si s nimi nerozumie? Alebo je pes zakopany v niecom inom?

Vsetky weby a webove aplikacie by mali bezat na svojej domene druheho radu ale IP aj port je len jeden pre cely server.

Odpovědi

[Jendа]

Nase 2 servery si navzajom rozumeju preco Apache si s nimi nerozumie?

Otázka spíš je jaktože si ty dva servery rozumějí. Jak to máš nastavené? To se ti nějak podařilo opravdu nabindovat dva programy na stejný port? Když přijde nové spojení, jak se rozhoduje, který z nich ho dostane?

Osobně jsem tohle vždycky řešil tak, že jsem servery nabindoval třeba na :8001, :8002 a :8003 a na portu 80 (443) spustil nějakou proxy (haproxy, nginx, lighttpd…), která podle domény, cesty atd. spojení předala na jeden z těch serverů.

[bigBRAMBOR]

nabindovat dva programy na stejný port

spíš netuší co píše, mozna tam bezi dva weby, ale bude to jedna aplikace, ktera pak rozhoduje kam to strčí

[Andrej]

<offtopic>

No, tohle by chtělo malé upřesnění pro úplnost.

Nabindovat dva programy na stejný port samozřejmě lze. Klíčová slova, jak toho docílit:

• setsockopt(...)
• SOL_SOCKET
• SO_REUSEADDR

Tohle^^^ (na obou socketech) zajistí, že se dá pak zavolat bind(...) dvakrát na stejnou adresu.

Háček je „jenom“ v tom, že takové nastavení je irelevantní pro situaci popsanou v dotazu, protože neslouží / nemá sloužit ke sdílení portu několika servery (resp. nevím, jak je v takovém případě definované chování), nýbrž ke sdílení portu několika klienty, kteří pak volají connect(...) na různé adresy.

Protože TCP spojení je čtveřice (adresa, port, adresa, port), je jasné, že změnou jednoho prvku (kteréhokoliv) se dá vytvořit další spojení. Multiplexování na straně serveru je známější — accept(...) —, zatímco multiplexování na straně klienta (výše uvedený socket option) je méně známé / méně používané / méně snadno použitelné.

Otázka za 100 bodů by byla, co se stane, když se přes sockety se SO_REUSEADDR bind(...)nuté na stejnou adresu připojím dvakrát k témuž serveru (adresa, port). Odpověď neznám; vždy jsem klientský multiplexing používal jen s různými servery. Kdo zná odpověď, třeba ji sem pro zajímavost postne.

</offtopic>

[debian+]

To sluzi nasledne ako softwarovy hub? Tj. dostanu obaja, a koho sa to tyka to a la zahodi?

[Andrej]

Ne, každý klientský socket je jiné spojení a směřuje jen na ten jeden server, kam vede. Spojení jsou rozlišitelná, protože jedno je [adresa_klienta, port_klienta, adresa_serveru_1, port_serveru_1] a druhé je [adresa_klienta, port_klienta, adresa_serveru_2, port_serveru_2].

Pojmem „multiplexing“ jsem myslel, že se na jednom portu dá udržovat víc oddělených TCP spojení, nikoliv že se něco rozesílá víckrát (což se neděje).

Je to v principu stejné jako psát na straně serveru do socketu, který předtím vrátil accept(...). Taky se to pošle jenom tomu jednomu klientovi, který je na daném spojení, přestože adresa:port serveru třeba zrovna obsluhuje naráz spoustu klientů.

[Josef Kufner]

Reálně však potřebuješ mít unikátní už dvojici IP a port na serveru, neboť jinak nepoznáš, které službě to spojení poslat.

[Andrej]

Spojení od accept(...) nepotřebuju nijak poznávat, v tom okamžiku už je vše potřebné zařízeno a identifikováno.

Pokud otevírám víc spojení z jednoho klienta (stejná adresa a stejný port, pomocí SO_REUSEADDR), musím (jako vždy) při connect(...) vědět, kam se připojuju, a jednotlivá spojení by se měla lišit — jinými slovy, alespoň adresy serverů nebo alespoň porty serveru/ů by se měly lišit. (Pokud se neliší, k takové situaci směřuje kvízová otázka v mém posledním odstavci výše. Nikdy jsem takovou situaci nezkoušel. Tipuju, že kernel by měl tohle detekovat a vrátit chybu při connect(...).)

[Filip Jirsák]

Mam na jednom porte pustene 2 HTTP servery

Nemáte. (Musely by být každý na jiné IP adrese, a to podle dalšího textu nemáte.)

Možná řešení jsou dvě:

1. Zjistěte, jak to doopravdy máte, a pro nový server to udělejte stejně.

2. Dát před ty servery reverzní proxy server (nejčastěji se používá nginx, případně HAproxy, šlo by pro to použít i Apache), který bude podle pravidel (doména, URL apod.) směrovat požadavky na příslušné backend servery.

Ve skutečnosti jsou nejspíš řešení 1 a 2 ta samá.

[Andrej]

Co takhle použít něco jako name-based virtual hosting z Apache jako „frontend + proxy + třetí server“ a ty dva C++ servery jako backendy k tomu? Pak by to mohlo fungovat všechno naráz a ještě k tomu by ty C++ servery mohly být klidně v plaintextu, protože TLS by za ně řešil ten frontend. Name-based virtual hosting na TLS a na stejném portu funguje bez nejmenších potíží, byť zastaralá dokumentace někdy mylně tvrdí opak.

Takhke^^^ jsem měl kdysi na jednom portu asi 20 „serverů“. Tak 10 z nich byly dynamické pseudo-rádoby-domény 3. řádu (hvězdička z pohledu DNS, podadresáře s různými vlastníky z pohledu Apache) a pak tam bylo pár fixních serverů/subdomén, dva byly v Javě, jeden byl v Ruby, pak tam byl taky nějaký Git frontend v nevímčem atd. Dokonce se dalo nastavit, že některé servery se představovaly wildcard certifikátem a jiné měly svůj vlastní certifikát od jiné autority a používaly/vyžadovaly autentifikaci certifikátem. Všechno na jednom portu. (TLS samozřejmě povinné; máme 21. století atd.)

Už dávno ten setup nemám v provozu, ale Apache tohle uměl vzájemně propojit už minimálně 10 let zpátky.

Dokonce mám dojem, že to matchování URL má mnohem jemnější granularitu než „celé“ domény, takže možnostem nastavení se meze nekladou.