Perché non è sensato dedicare più di una porta TCP / IP a http? Sebbene sia ingenuo ingenuo, non è in qualche modo intuitivo pensare che le prestazioni del server possano in qualche modo essere aumentate?
Perché non è sensato dedicare più di una porta TCP / IP a http? Sebbene sia ingenuo ingenuo, non è in qualche modo intuitivo pensare che le prestazioni del server possano in qualche modo essere aumentate?
Risposte:
La porta 80 è una porta ben nota , il che significa che è ben nota come la posizione in cui normalmente si trovano i server HTTP. Puoi trovarlo documentato nella RFC HTTP / 1.1 .
Avere un valore predefinito è utile proprio perché non è necessario digitarlo nel browser Web con l'URI. Se si esegue un server HTTP (o di fatto qualsiasi servizio) su una porta non standard, si forza il client a ricordare il numero a 16 bit arbitrario scelto e lo si digita.
Oltre a questa ostilità, non vi è alcun vantaggio in termini di prestazioni: una porta è solo una parte della (dst ip:port, src ip:port)
4-tupla che identifica in modo univoco una connessione TCP. Se due connessioni condividono a dst ip:port
, ciò non significa che condividano alcune risorse di sistema: possono risiedere in thread diversi o in processi diversi.
Ora, se si dispone di servizi logicamente diverse, che sia accadono utilizzare HTTP, non v'è alcun problema con loro in esecuzione su porte diverse. Rende l'URI un po 'più brutto.
Il server non spreca risorse gestendo le connessioni in una o più porte. Le risorse del server sono allocate per gestire le connessioni e il numero di porta è solo un modo per connettere un programma specifico a una connessione specifica.
Ad esempio: il server HTTP sa che ascolterà le connessioni che arrivano nella porta 80. E il server sa che ogni volta che riceve una richiesta sulla porta 80, la gestirà sul server http. Successivamente, il server http gestirà la comunicazione e quindi consumerà risorse.
Sembri pensare ai porti come qualcosa di reale; è solo un numero senza segno a 16 bit (0-65535) che è un'etichetta nell'intestazione di un pacchetto IP. Questo aiuta con il multiplexing a livello di applicazione. Quando un pacchetto in arrivo arriva su una scheda di rete, il sistema operativo riceve una notifica. Verifica a quale porta è stato indirizzato il pacchetto in entrata, quindi inoltra il pacchetto alla sola applicazione corretta. Se stai eseguendo il tuo server web (nginx) per l'ascolto sulla porta 80, solo nginx riceve i pacchetti inviati alla porta 80.
Quando un client (IP: 100.200.100.200) invia una richiesta HTTP al server (55.55.55.55), invia tale richiesta alla porta di destinazione 80 sul server (55.55.55.55:80), ma la porta di origine viene scelta casualmente dal Sistema operativo per il browser web (qualcosa come 45490). La risposta HTTP dal server Web viene quindi da (55.55.55.55:80), ma inviata alla destinazione (il tuo IP) (100.200.100.200:45490). Il sistema operativo del tuo computer sa che i pacchetti in arrivo sulla porta 45490 (da 55.55.55.55:80) devono essere dati al browser web che ha effettuato la richiesta. Poiché ogni connessione univoca a un sito Web dal client ottiene una porta casuale univoca, è possibile disporre di più browser Web che si collegano allo stesso sito Web e quando una pagina viene ricaricata in un browser, le altre finestre non vengono interessate.
Ogni pacchetto IP ha sia l'indirizzo IP di origine che quello di destinazione e la porta disponibili nell'intestazione. Il sistema operativo e l'applicazione (browser Web o server Web) possono utilizzare entrambi per capire l'azione appropriata su come elaborare il pacchetto.
Le porte 80 e 443 sono le porte "predefinite" per HTTP / HTTPS
Ciò significa che non è necessario specificare la porta ( http://www.example.com:80 , https://www.example.com:443 ) quando si utilizza un browser Web.
Se si desidera che un server Web sia in ascolto su qualsiasi altra porta, gli utenti devono aggiungere manualmente la porta all'URL o deve essere codificato in qualsiasi collegamento a quella porta specifica.
Inoltre, la maggior parte dei proxy e dei firewall non consentirà connessioni a tali porte a meno che non siano specificamente configurate per farlo (senza configurazione, i proxy in uscita non ascolteranno porte non predefinite, quindi non inoltreranno la richiesta ai server Web, mentre i firewall semplicemente bloccare tentativi di connessione non TCP80 / 443)
Tutto ciò limita ciò che può essere fatto a livello TCP / IP
Un modo per migliorare le prestazioni sarebbe avere un dispositivo / servizio di bilanciamento del carico in ascolto di TCP80 / 443 che reindirizzerebbe quindi la richiesta a server su porte e / o ip differenti (Bilanciamento locale) o anche a siti remoti diversi (Bilanciamento globale). Ma questo è un altro argomento del tutto
L'aggiunta di porte extra non aggiunge ulteriore larghezza di banda o qualcosa del genere, una porta è più un'etichetta che una pipa , può "crescere" tanto quanto è necessario senza rallentare a causa della pipa piena.
Se un server riceve troppe richieste, il server ovviamente rallenterà, tuttavia questo non è il tipo di problema che può essere risolto aggiungendo un altro numero di porta.
Se hai utilizzato porte casuali, l'utente dovrebbe aggiungere i numeri di porta corretti ogni volta che è andato sul tuo sito. cioè www.esempio.it:80; www.example.com:81; www.esempio.it:82 ecc
Non aumenterebbe le prestazioni per utilizzare più porte. Le porte di origine per ogni connessione sono porte effimere e comunque così diverse
Ogni connessione TCP / IP ha un sourceIP: sourcePort e un destinationIP: destinationPort.
Quando si avvia una connessione, si utilizzerà sempre 80 come porta di destinazione (il che ha senso poiché il Server deve solo ascoltare sulla porta 80 per HTTP e non su più porte). Il trucco è che sourcePort è dinamico per ogni connessione.
Esempio:
user1: 1.1.1.1:29999 a 2.2.2.2:80
user2: da 1.1.1.2:45333 a 2.2.2.2:80
Non confondere una porta diversa per una diversa connessione fisica o una larghezza di banda di rete più elevata o prestazioni di elaborazione del server. Ciò che il server ottiene sono i pacchetti TCP o UDP, che hanno un numero di porta come parte dell'indirizzo. Passano ancora attraverso gli stessi cavi, passano attraverso lo stesso hardware e driver dell'interfaccia di rete e così via.
Se dovessi inviare due pacchetti a un server, in termini di risorse che il server spende per elaborare questi due pacchetti, non importa se uno dei due ha numeri di porta diversi o gli stessi numeri di porta associati ad essi, la gestione interna essere vicini all'identico.
Pertanto, questo non è un metodo per aumentare le prestazioni in alcun modo.
L'unica possibile eccezione a ciò è se si dovessero associare due diversi demoni (o due copie dello stesso) in esecuzione contemporaneamente ai due diversi numeri di porta e se ciascuno di questi demoni si espandesse in modo estremamente grave con il carico. Che in genere non è il caso.
Come menzionato Remi, le porte 80 e 443 sono le porte "predefinite" per HTTP / HTTPS.
La maggior parte delle reti e dei firewall non blocca il traffico che attraversa queste porte. Quindi utilizzare queste porte è più semplice poiché la maggior parte delle volte potrebbe non essere necessario preoccuparsi dei firewall che bloccano il servizio, altrimenti potrebbe essere necessario riconfigurare le regole del firewall e ottenere le approvazioni dalla conformità / sicurezza per lo stesso.
Come hanno detto tutti gli altri qui, è praticamente inutile ospitare un server Web su qualsiasi porta diversa dalla porta 80 ... a meno che non lo si stia ospitando da casa. Molti ISP limitano le porte TCP / UDP in uscita 80 e 443 ( IANA definisce rispettivamente HTTP e HTTPS ) e, in questo caso, l'utilizzo di tali porte riduce le velocità di caricamento del sito, ecc. Tuttavia, IANA ha assegnato 3 porte HTTP-ALT per sia TCP che UDP. Questi sono: 591, 8008 e 8080. Anche l'uso di queste porte è accettabile, ma renderai l'inferno la vita degli amministratori del server.
Fonte dei numeri di porta: https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml