Jak wybrać numer portu dla nowego narzędzia?

Tworzę wewnętrzne narzędzie do współpracy, które będzie wykorzystywać centralny serwer (w intranecie) i jeden lub więcej portów do komunikacji gniazd z klientami. Wiem, że wiele portów jest zarezerwowanych do określonych celów, a inne są konwencjonalnie wykorzystywane do określonych rodzajów ruchu.

Jak powinienem wybrać domyślny port, który prawdopodobnie nie został „zajęty” przez kogoś innego za jego narzędzie? Czy istnieje baza danych, która identyfikuje wszystkie znane (nawet niekonwencjonalne) użycie portów?

port intranet

— Jace Browning
źródło

Zasadniczo jest to problem tylko wtedy, gdy coś już korzysta z portu na serwerze. Jednak port powinien być konfigurowalny. Widziałem, że sporo oprogramowania ma zakodowane porty, co nie jest tym, czego chcesz.

— devicenull

@devicenull Zdecydowanie będę mieć możliwość zastąpienia wartości domyślnej.

— Jace Browning

Jeśli twoja broda jest wystarczająco szara, możesz użyć RPC i zarejestrować własny punkt końcowy. msdn.microsoft.com/en-us/library/windows/desktop/…

— Ryan Ries

Jeśli nie masz ważnego powodu, aby tego nie robić, lepiej użyć istniejących protokołów tam, gdzie możesz. a) Naturalne jest myślenie, że możesz wykonać lepszą pracę, dla większości ludzi to nieprawda. Ale nawet jeśli możesz, czy lepiej jest przeciwdziałać b) narzędzia / urządzenia sieciowe są już skonfigurowane do pracy z istniejącymi standardami. Dodanie nowych wiąże się z barierą i dużym nakładem pracy.

— JamesRyan

Dla czegoś, co jest wewnętrzną współpracą, cokolwiek> 1024 i <32768 (powinno chronić przed efemerycznymi powiązaniami portów) i NIE jest wymienione w rejestrze portów IANA, byłoby OK, pod warunkiem, że skutecznie komunikujesz się z wewnętrznymi oddziałami, które przejąłeś port.

— Matthew Ife

Odpowiedzi:

Tak, IANA prowadzi oficjalny rejestr usług i numerów portów .

Proces nadawania numeru portu jest udokumentowany w RFC 6335 . Proces weryfikacji jest wymagany dla każdego przypisania portu, ale jest znacznie bardziej rygorystyczny dla portów <1024; takie przypisania wymagają (między innymi), aby twój protokół był udokumentowany w RFC.

(Należy pamiętać, że ten proces jest stosunkowo nowy i że istnieje wiele przypisanych portów, które zostały współużytkowane.)

Dla <1024 porty 1021 i 1022 są zarezerwowane do eksperymentów; powyżej, do eksperymentów możesz po prostu użyć portu dynamicznego> = 49152.

— Michael Hampton
źródło

Skrót do wyszukiwania „nieprzypisany”: iana.org/assignments/service-names-port-numbers/…

— Jace Browning

W większości przypadków lepiej jest po prostu użyć HTTP, ponieważ wcześniej czy później pojawi się zapora ogniowa, którą musisz przejść. Większość systemów operacyjnych pozwala na podział przestrzeni adresowej HTTP między procesy.

— Ian Ringrose
źródło

Jestem zdezorientowany, czy nie mogę używać HTTP na żadnym porcie? Nie chcę domyślnie :80lub :8080ponieważ istnieje duża możliwość, że będą już używane. Czy moje pytanie wciąż nie jest ważne?

— Jace Browning

@JaceBrowning, tak, możesz, ale korzystanie z dowolnego innego portu to tylko dziwna historia :-). Każdy przyzwoity system operacyjny pozwoli ci podzielić przestrzeń nazw HTTP między aplikacjami.

— Ian Ringrose