Czy dwie aplikacje na tym samym komputerze mogą łączyć się z tym samym portem i adresem IP? Idąc krok dalej, czy jedna aplikacja może nasłuchiwać żądań pochodzących z określonego adresu IP, a druga do innego zdalnego adresu IP? Wiem, że mogę mieć jedną aplikację, która uruchamia dwa wątki (lub widelce), aby mieć podobne zachowanie, ale czy dwie aplikacje, które nie mają ze sobą nic wspólnego, mogą zrobić to samo?
283
Odpowiedzi:
Odpowiedź różni się w zależności od rozważanego systemu operacyjnego. Ogólnie jednak:
W przypadku TCP nie. Możesz mieć jednocześnie tylko jedną aplikację nasłuchującą na tym samym porcie. Teraz, jeśli masz 2 karty sieciowe, możesz mieć jedną aplikację nasłuchującą na pierwszym adresie IP, a drugą na drugim adresie IP, używając tego samego numeru portu.
W przypadku UDP (multiemisje) wiele aplikacji może subskrybować ten sam port.
Edycja: Od wersji jądra Linux 3.9 i nowszych dodano obsługę wielu aplikacji nasłuchujących na tym samym porcie za pomocą tej
SO_REUSEPORT
opcji. Więcej informacji jest dostępnych w tym artykule lwn.net.źródło
Tak (dla TCP) możesz mieć dwa programy nasłuchujące na tym samym gnieździe, jeśli programy są do tego przeznaczone. Gdy gniazdo jest tworzone przez pierwszy program, upewnij się, że
SO_REUSEADDR
opcja jest ustawiona na gnieździe przed tobąbind()
. Jednak może to nie być to, czego chcesz. To, co robi, to przychodzące połączenie TCP zostanie przekierowane do jednego z programów, a nie do obu, więc nie powiela połączenia, pozwala tylko dwóm programom na obsługę przychodzącego żądania. Na przykład, serwery WWW będą miały wiele procesów nasłuchujących na porcie 80, a O / S wyśle nowe połączenie do procesu, który jest gotowy na przyjęcie nowych połączeń.Zezwala innym gniazdom na
bind()
ten port, chyba że aktywne gniazdo nasłuchujące jest już powiązane z tym portem. Umożliwia to obejście komunikatów o błędach „Adres już używany” podczas próby ponownego uruchomienia serwera po awarii.źródło
SO_REUSEADDR
z pewnością nie pozwala na jednoczesne słuchanie dwóch gniazd TCP, przynajmniej na Uniksie. Ma na celu ominięcieTIME_WAIT state
: unixguide.net/network/socketfaq/4.5.shtml . Może to działać w systemie Windows, ale nie ma gwarancji, że żądanie i tak dotrze do właściwego serwera).Tak.
Wiele nasłuchujących gniazd TCP, wszystkie powiązane z tym samym portem, może współistnieć, pod warunkiem że wszystkie są powiązane z różnymi lokalnymi adresami IP. Klienci mogą łączyć się z dowolnymi, których potrzebują. To wyklucza
0.0.0.0
(INADDR_ANY
).Może istnieć wiele akceptowanych gniazd, wszystkie przyjmowane z tego samego gniazda nasłuchującego, wszystkie z tym samym numerem portu lokalnego co gniazdo nasłuchujące.
Wiele gniazd UDP wszystkie powiązane z tym samym portem mogą wszystkie istnieć jednocześnie, pod warunkiem, że są takie same warunki jak w (1) lub wszystkie mają
SO_REUSEADDR
ustawioną opcję przed powiązaniem.Porty TCP i porty UDP zajmują różne przestrzenie nazw, więc użycie portu dla TCP nie wyklucza jego użycia dla UDP i odwrotnie.
Odniesienie: Stevens & Wright, Illustrated TCP / IP, Tom II.
źródło
W zasadzie nie.
Nie jest napisane w kamieniu; ale w taki sposób zapisywane są wszystkie interfejsy API: aplikacja otwiera port, pobiera do niego uchwyt, a system operacyjny powiadamia go (za pośrednictwem tego uchwytu), gdy nadchodzi połączenie klienta (lub pakiet w przypadku UDP).
Jeśli system operacyjny zezwoli na otwarcie dwóch aplikacji przez ten sam port, skąd będzie wiedział, o której powiadomić?
Ale ... są na to sposoby:
źródło
iptables -m statistic --mode random --probability 0.5
jest zabawne.listen()
. Bardziej prawdopodobne jest pytanie o otwarcie go w zaporze ogniowej. Zbyt wiele błędów tutaj i wszystkie nieskorygowane w ciągu 7 lat. Odpowiedź również pomija przypadek powiązania z innym adresem lokalnym o tym samym numerze portu. W rzeczywistości jest to całkowicie niepoprawne.Tak, zdecydowanie . O ile pamiętam Od jądra w wersji 3.9 (nie jestem pewien co do wersji) wprowadzono obsługę tego
SO_REUSEPORT
.SO_RESUEPORT
pozwala na powiązanie z dokładnie tym samym portem i adresem, o ile pierwszy serwer ustawia tę opcję przed powiązaniem swojego gniazda.Działa zarówno dla TCP, jak i UDP . Więcej informacji znajduje się w łączu: SO_REUSEPORT
Uwaga : Akceptowana odpowiedź nie jest już zgodna z moją opinią.
źródło
Nie. Tylko jedna aplikacja może jednocześnie łączyć się z portem, a zachowanie, jeśli wymuszenie jest nieokreślone.
Dzięki gniazdom multiemisji - które brzmią jak nigdzie w pobliżu tego, co chcesz - więcej niż jedna aplikacja może połączyć się z portem, o ile SO_REUSEADDR jest ustawione w opcjach każdego gniazda.
Możesz to zrobić, pisząc proces „master”, który akceptuje i przetwarza wszystkie połączenia, a następnie przekazuje je dwóm aplikacjom, które muszą nasłuchiwać na tym samym porcie. Takie podejście przyjmują serwery WWW i takie, ponieważ wiele procesów musi słuchać 80.
Poza tym zajmujemy się szczegółami - otagowałeś zarówno TCP, jak i UDP, co to jest? Jaka platforma?
źródło
Możesz mieć jedną aplikację nasłuchującą na jednym porcie dla jednego interfejsu sieciowego. Dlatego możesz mieć:
httpd
nasłuch na zdalnie dostępnym interfejsie, np192.168.1.1:80
127.0.0.1:80
Przykładem użycia może być użycie
httpd
modułu równoważenia obciążenia lub serwera proxy.źródło
Innym sposobem jest użycie programu nasłuchującego w jednym porcie, który analizuje rodzaj ruchu (ssh, https itp.), Który przekierowuje wewnętrznie do innego portu, na którym nasłuchuje „prawdziwa” usługa.
Na przykład dla systemu Linux sslh: https://github.com/yrutschle/sslh
źródło
Podczas tworzenia połączenia TCP należy poprosić o połączenie z określonym adresem TCP, który jest kombinacją adresu IP (v4 lub v6, w zależności od używanego protokołu) i portu.
Gdy serwer nasłuchuje połączeń, może poinformować jądro, że chce nasłuchiwać określonego adresu IP i portu, tj. Jednego adresu TCP lub tego samego portu na każdym z adresów IP hosta (zwykle określanego za pomocą adresu IP
0.0.0.0
), która jest skutecznie słuchać na wiele różnych „adresów TCP” (na przykład192.168.1.10:8000
,127.0.0.1:8000
itd)Nie, nie możesz mieć dwóch aplikacji nasłuchujących na tym samym „adresie TCP”, ponieważ kiedy nadejdzie wiadomość, skąd jądro będzie wiedziało, która aplikacja ma przekazać wiadomość?
Jednak w większości systemów operacyjnych możesz skonfigurować kilka adresów IP na jednym interfejsie (np. Jeśli masz
192.168.1.10
na interfejsie, możesz również skonfigurować192.168.1.11
, jeśli nikt inny w sieci go nie używa), aw takich przypadkach możesz mogą mieć osobne aplikacje nasłuchujące na porcie8000
na każdym z tych dwóch adresów IP.źródło
Jeśli co najmniej jeden ze zdalnych adresów IP jest już znany, statyczny i przeznaczony do rozmowy tylko z jedną z twoich aplikacji, możesz użyć reguły iptables (tabela nat, łańcuch PREROUTING), aby przekierować przychodzący ruch z tego adresu na „wspólny” port lokalny do każdy inny port, na którym właściwa aplikacja faktycznie nasłuchuje.
źródło
Tak i nie. Tylko jedna aplikacja może aktywnie nasłuchiwać na porcie. Ale ta aplikacja może przekazać swoje połączenie z innym procesem. Możesz mieć wiele procesów działających na tym samym porcie.
źródło
Tak.
Z tego artykułu:
https://lwn.net/Articles/542629/
źródło
Jeśli przez aplikacje rozumiesz wiele procesów, to tak, ale ogólnie NIE. Na przykład serwer Apache uruchamia wiele procesów na tym samym porcie (zazwyczaj 80). Robi się to poprzez wyznaczenie jednego z procesów do faktycznego połączenia z portem, a następnie użycie tego procesu do przekazania różnych procesów, które przyjmują połączenia.
źródło
Możesz zmusić dwie aplikacje do nasłuchiwania tego samego portu w tym samym interfejsie sieciowym.
Może być tylko jedno gniazdo nasłuchujące dla określonego interfejsu sieciowego i portu, ale to gniazdo może być współużytkowane przez kilka aplikacji.
Jeśli masz proces nasłuchiwania w procesie aplikacji, a ty
fork
ten proces, gniazdo zostanie odziedziczone, więc technicznie będą teraz dwa procesy nasłuchujące na tym samym porcie.źródło
Próbowałem następujące, z
socat
:I chociaż nie nawiązałem połączenia z gniazdem, nie mogę słuchać dwa razy na tym samym porcie, pomimo tej
reuseaddr
opcji.Dostaję tę wiadomość (której się wcześniej spodziewałem):
źródło
Wystarczy podzielić się tym, o czym wspomniał @jnewton. Uruchomiłem proces nginx i osadzony proces tomcat na moim komputerze Mac. Widzę oba przebieg procesu przy 8080.
źródło
Krótka odpowiedź:
Przechodząc od odpowiedzi podanej tutaj . Możesz mieć dwie aplikacje nasłuchujące na tym samym adresie IP i numerze portu, więc jeden z nich jest portem UDP, a drugi portem TCP.
Wyjaśnienie:
Koncepcja portu jest istotna na warstwie transportowej stosu TCP / IP, więc dopóki używasz różnych protokołów warstwy transportowej stosu, możesz mieć wiele procesów nasłuchujących na tej samej
<ip-address>:<port>
kombinacji.Jedną z wątpliwości, które ludzie mają, jest to, że jeśli dwie aplikacje działają na tej samej
<ip-address>:<port>
kombinacji, w jaki sposób klient działający na zdalnym komputerze rozróżnia te dwie? Jeśli spojrzysz na nagłówek pakietu warstwy IP ( https://en.wikipedia.org/wiki/IPv4#Header ), zobaczysz, że do zdefiniowania protokołu używane są bity od 72 do 79, w ten sposób można dokonać rozróżnienia.Jeśli jednak chcesz mieć dwie aplikacje w tej samej
<ip-address>:<port>
kombinacji TCP , to odpowiedź brzmi nie (ciekawe ćwiczenie to uruchomienie dwóch maszyn wirtualnych, nadanie im tego samego adresu IP, ale różnych adresów MAC i zobacz, co się stanie - zauważysz to czasami VM1 otrzyma pakiety, a innym razem VM2 otrzyma pakiety - w zależności od odświeżenia pamięci podręcznej ARP).Wydaje mi się, że poprzez uruchomienie dwóch aplikacji na tym samym
<op-address>:<port>
, chcesz osiągnąć pewnego rodzaju równoważenie obciążenia. W tym celu możesz uruchamiać aplikacje na różnych portach i pisać reguły tabeli IP, aby rozdzielić ruch między nimi.Zobacz także odpowiedź @ user6169806.
źródło