TCP può fornire più di 65535 porte?

50

È possibile configurare un sistema Linux in modo che fornisca più di 65.535 porte? L'intenzione sarebbe quella di avere più di 65.000 demoni in ascolto su un determinato sistema.

Chiaramente ci sono porte utilizzate, quindi ciò non è possibile per questi motivi, quindi pensateci come un esercizio teorico nel tentativo di capire dove TCP sarebbe restrittivo nel fare qualcosa del genere.

— slm
fonte

11

Qual è la motivazione per questa domanda? Perché vuoi avere tanti demoni in ascolto?

— Warren Young,

1

Inoltre, avrai difficoltà a iniziare molti processi. (Suppongo che intendi un processo per demone.)

— Warren Young,

13

Mentre non c'è nulla che ti limiti formalmente a indossare 65 paia di pantaloni contemporaneamente, sarebbe pratico idiozia da provare. Se puoi mostrarmi una macchina che può elaborare fruttuosamente 10'000 porte TCP contemporaneamente, questa potrebbe essere una domanda astratta interessante.

— msw,

13

La natura di questa Q è del tutto teorica, nessuno scopo è quello di comprendere i limiti di TCP e il numero di porte.

— slm

1

Il fatto è, tuttavia, che è stato definito in un modo che lo lega a varie questioni pratiche che coinvolgono lo spazio RAM richiesto dai processi dak 64k +. Qualsiasi macchina che probabilmente avrai adesso o per il prossimo decennio o giù di lì esaurirà la RAM prima di raggiungere il limite di ascolto. Se riformuli la domanda per parlare solo degli ascoltatori TCP , lasciando completamente fuori la discussione sui demoni, quel problema scompare. È possibile ammortizzare lo spazio dello stack assegnando un migliaio di socket a ciascun demone basato su eventi a thread singolo, ad esempio.

— Warren Young,

84

Osservando RFC per TCP: RFC 793 - Transmission Control Protocol , la risposta sembrerebbe essere no a causa del fatto che un'intestazione TCP è limitata a 16 bit per il campo della porta di origine / destinazione.

ss # 1

IPv6 migliora le cose?

No. Anche se IPv6 ci fornirà uno spazio di indirizzi IP molto più ampio, 32 bit contro 128 bit, non tenta di migliorare la limitazione del pacchetto TCP di 16 bit per i numeri di porta. È interessante notare che RFC per IPv6: protocollo Internet, specifica versione 6 (IPv6) , il campo IP doveva essere ampliato.

Quando TCP viene eseguito su IPv6, il metodo utilizzato per calcolare il checksum viene modificato, come da RFC 2460 :

Qualsiasi protocollo di trasporto o di altro livello superiore che includa gli indirizzi dall'intestazione IP nel suo calcolo del checksum deve essere modificato per l'uso su IPv6, per includere gli indirizzi IPv6 a 128 bit anziché gli indirizzi IPv4 a 32 bit.

ss # 2

Quindi, come puoi ottenere più porte?

Un approccio sarebbe quello di impilare ulteriori indirizzi IP usando più interfacce. Se il tuo sistema ha più NIC questo è più facile, ma anche con una sola NIC, puoi utilizzare interfacce virtuali (alias. Alias ) per allocare più IP se necessario.

NOTA: l' utilizzo degli alias è stato soppiantato mediante il iproute2quale è possibile utilizzare invece per impilare gli indirizzi IP su una singola interfaccia (ad es. eth0).

Esempio

$ sudo ip link set eth0 up
$ sudo ip addr add 192.0.2.1/24 dev eth0
$ sudo ip addr add 192.0.2.2/24 dev eth0
$ ip addr show dev eth0
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
      pfifo_fast state DOWN qlen 1000
    link/ether 00:d0:b7:2d:ce:cf brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.1/24 brd 192.0.2.255 scope global eth1
    inet 192.0.2.2/24 scope global secondary eth1

Fonte: iproute2: Life after ifconfig

Riferimenti

— slm
fonte

3

Non sarebbe possibile selezionare tra oltre 65.536 demoni usando solo la porta di destinazione, ma se uno avesse memoria e larghezza di banda illimitate, potrebbe avere oltre 32.000 connessioni con ogni indirizzo TCP distinto su ogni porta in arrivo.

— supercat,

7

È possibile configurare un sistema Linux in modo che fornisca più di 65.535 porte?

No.

L'intenzione sarebbe quella di avere più di 65.000 demoni in ascolto su un determinato sistema.

Quindi hai bisogno di:

una iptablesconfigurazione che reindirizza sul contenuto del traffico o
un "servizio broker di servizio" o "servizio multiplexor" che accetterà connessioni in entrata su una singola porta e lo instraderà al demone appropriato "dietro di esso". Se si desidera che i protocolli standard passino senza modifiche, potrebbe essere necessario implementare lo sniffing / il riconoscimento dei protocolli in questo servizio multiplexor, in modo tale che un firewall IDS o layer 7 possa alterare; completamente possibile con la stragrande maggioranza dei protocolli.

Per il secondo articolo, è possibile progettare questo servizio per gestire più di 2 ^ 16 "porte" se proprio lo si desidera. Sono sicuro che l'impatto sulle prestazioni sarà minimo rispetto al carico di 2 ^ 16 + ascoltatori in esecuzione.

I demoni in Linux possono essere in ascolto su socket unix presenti nel filesystem, quindi il tuo "servizio multiplexor" potrebbe mantenere una mappatura interna della porta esterna <-> socket unix interno. Probabilmente ti imbatterai in un limite di processo del kernel (processi a 32Kbyte?) Prima di rimanere senza inode su qualsiasi file system moderno.

— LawrenceC
fonte

Ho annullato il downgrade perché dici che non è possibile, quindi prosegui spiegando come farlo utilizzando più IP e il bilanciamento del carico, anche se in modo molto confuso.

— suprjami,

2

Più di 64 KB di porte su un singolo sistema sono impossibili. Probabilmente sono possibili più di 64 KB di ascoltatori , ma è necessario disporre di listener proxy o frontend che "suddividano" le connessioni in entrata nei listener reali "backend" giusti. Ad esempio, potresti fare qualcosa di folle come un NAT interno a più indirizzi IP interni.

— LawrenceC,

2

Sbagliato. Le persone sono riuscite a ottenere mezzo milione di connessioni simultanee su un singolo sistema. Sì, sono necessari più IP e bilanciamento del carico (non necessariamente sullo stesso sistema), ma un singolo sistema può aprire più di 64k porte e anche più di 64k listener se fatto correttamente.

— suprjami,

2

Solo perché non c'è una buona risposta in cui volevo entrare.

Un modo per farlo sarebbe quello di aggiungere un'opzione IP che specifica l'estensione della porta. L'opzione deve essere progettata per adattarsi alla parte facoltativa dell'intestazione IP e verrebbe ignorata da hop sconosciuti.

Utilizzeresti questa opzione e le sue informazioni per estendere l'origine, la destinazione o entrambi i numeri di porta.

Le limitazioni non funzioneranno automaticamente nel software esistente semplicemente aggiungendo l'opzione in ogni caso, dovranno essere riscritte per sfruttare l'opzione indipendentemente dal modo in cui è implementata, il software esistente e i firewall ignoreranno il pacchetto o lo elaboreranno come al solito utilizzando il valore nei campi della porta di origine e di destinazione.

In breve, non è facile da fare e sarebbe meglio farlo usando un singolo listener riutilizzabile e i dati contenuti nel payload del pacchetto.

È inoltre possibile consentire più facilmente il riutilizzo delle porte nel software, il che può aiutare a superare questa limitazione riutilizzando le porte del server per più connessioni client.

Rtsp, ad esempio, può utilizzare l'intestazione SessionId insieme a varie altre intestazioni nel payload del pacchetto IP per determinare per quale connessione è stata emessa la richiesta e agire di conseguenza, ad esempio se il socket da cui è stato recapitato il messaggio non è lo stesso del socket indirizzo remoto a cui corrisponde la sessione, quindi è possibile consentire a una sessione di essere aggiornata con il nuovo socket per l'elaborazione, negare il messaggio o una varietà di altre azioni a seconda dell'applicazione.

Un server HTTP può anche fare questo o qualsiasi altro tipo di server.

La cosa fondamentale da ricordare quando si consente il riutilizzo delle porte è che è necessario prendere in considerazione anche l'indirizzo IP di origine.

— ghiandaia
fonte

-2

Si, puoi !

È stato fatto prima, ad esempio il server di crittografia Edgehill, che ha> 25.000.000 di demoni in esecuzione online.

— Bullrun
fonte

9

Prendi in considerazione l'idea di espandere la tua risposta in modo da includere alcune indicazioni su come l'OP potrebbe ottenere questo risultato, documentazione a supporto della tua risposta o relativa spiegazione.

— HalosGhost,

Potete fornire riferimenti a questa affermazione? Una rapida ricerca mi fa credere che qualunque cosa sia distribuita su molte macchine.

— Thomas Guyot-Sionnest,