Miglior intervallo di numeri di porta TCP per applicazioni interne [chiuso]

Lavoro in un luogo in cui ciascuna delle nostre applicazioni interne viene eseguita su una singola istanza Tomcat e utilizza una porta TCP specifica. Quale sarebbe il miglior intervallo di porte IANA da utilizzare per queste app al fine di evitare collisioni di numeri di porta con qualsiasi altro processo sul server?

Basate su http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml , queste sono le opzioni come le vedo attualmente:

1. Porte di sistema (0-1023): non voglio utilizzare nessuna di queste porte perché il server potrebbe eseguire servizi su porte standard in questo intervallo
2. Porte utente (1024-49151): Dato che le applicazioni sono interne, non intendo richiedere a IANA di riservare un numero per nessuna delle nostre applicazioni. Tuttavia, vorrei ridurre la probabilità che la stessa porta venga utilizzata da un altro processo, ad esempio Oracle Net Listener su 1521.
3. Porte dinamiche e / o private (49152-65535): questo intervallo è ideale per i numeri di porta personalizzati. La mia unica preoccupazione è se questo dovesse accadere:

   un. Configuro una delle mie applicazioni per utilizzare la porta X
   b. L'applicazione è inattiva per alcuni minuti o ore (a seconda della natura dell'app), lasciando la porta inutilizzata per un po ',
   c. Il sistema operativo assegna il numero di porta X a un altro processo, ad esempio, quando quel processo agisce come un client che richiede una connessione TCP a un altro server. Ciò riesce dato che rientra nella gamma dinamica e X è attualmente inutilizzato per quanto riguarda il sistema operativo, e
   d. L'app non si avvia perché la porta X è già in uso

Non riesco a capire perché te ne importa. Oltre alla regola dei privilegi "non utilizzare porte inferiori a 1024", dovresti essere in grado di utilizzare qualsiasi porta perché i tuoi client dovrebbero essere configurabili per parlare con qualsiasi indirizzo IP e porta!

Se non lo sono, allora non sono stati fatti molto bene. Torna indietro e fallo correttamente :-)

In altre parole, eseguire il server all'indirizzo IP Xe alla porta, Yquindi configurare i client con tali informazioni. Quindi, se trovi che devi eseguire un server diverso su Xche è in conflitto con il tuo Y, basta riconfigurare il server e i client per utilizzare una nuova porta. Questo è vero sia che i tuoi client siano codice o persone che digitano URL in un browser.

Io, come te, non cercherò di ottenere numeri assegnati da IANA poiché dovrebbe essere per servizi così comuni che molti, molti ambienti li useranno (pensa SSH o FTP o TELNET).

La tua rete è la tua rete e, se vuoi i tuoi server sulla porta 1234 (o anche le porte TELNET o FTP per quella materia), sono affari tuoi. Caso in questione, nella nostra area di sviluppo mainframe, la porta 23 viene utilizzata per il terminal server 3270 che è una bestia molto diversa da telnet. Se vuoi telnet sul lato UNIX del mainframe, usi la porta 1023. A volte è fastidioso se usi client telnet senza specificare la porta 1023 poiché ti collega a un server che non sa nulla del protocollo telnet - dobbiamo rompere dal client telnet e farlo correttamente:

telnet big_honking_mainframe_box.com 1023

Se davvero non riesci a rendere configurabile il lato client, scegline uno nel secondo intervallo, come 48042, e usalo semplicemente, dichiarando che qualsiasi altro software su quelle scatole (incluso qualsiasi aggiunto in futuro) deve tenersi fuori dalla tua strada .

Ho deciso di scaricare i numeri di porta assegnati da IANA, filtrare le porte utilizzate e ordinare ogni intervallo "Non assegnato" in ordine decrescente della maggior parte delle porte disponibili. Ciò non ha funzionato, poiché il file csv ha intervalli contrassegnati come "Non assegnati" che si sovrappongono ad altre prenotazioni di numeri di porta. Ho espanso manualmente gli intervalli di numeri di porta assegnati , lasciandomi con un elenco di tutti i numeri di porta assegnati. Ho quindi ordinato l'elenco e generato il mio elenco di intervalli non assegnati.

Poiché questa pagina stackoverflow.com si è classificata molto in alto nella mia ricerca sull'argomento, ho pensato di pubblicare gli intervalli più ampi qui per chiunque fosse interessato. Questi sono sia per TCP che per UDP in cui il numero di porte nell'intervallo è almeno 500.

Total   Start   End
829     29170   29998
815     38866   39680
710     41798   42507
681     43442   44122
661     46337   46997
643     35358   36000
609     36866   37474
596     38204   38799
592     33657   34248
571     30261   30831
563     41231   41793
542     21011   21552
528     28590   29117
521     14415   14935
510     26490   26999

Fonte (tramite il pulsante di download CSV):

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

Risposta breve: utilizza una porta utente non assegnata

Oltre la risposta di chi raggiunge: seleziona e distribuisci una soluzione di rilevamento delle risorse. Chiedi al server di selezionare dinamicamente una porta privata. Chiedi ai clienti di utilizzare la discovery delle risorse.

Il rischio che un server fallisca perché la porta su cui vuole ascoltare non è disponibile è reale; almeno è successo a me. Un altro servizio o un cliente potrebbe arrivare prima.

È possibile ridurre quasi totalmente il rischio di un client evitando le porte private, che vengono distribuite dinamicamente ai client.

Il rischio che da un altro servizio è minimo se si utilizza una porta utente. Il rischio di una porta non assegnata è solo che un altro servizio è configurato (o dinamicamente) utilizza quella porta. Ma almeno è probabilmente sotto il tuo controllo.

L'enorme documento con tutte le assegnazioni delle porte, comprese le porte utente, è qui: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt cerca il token Unassigned .