ServerSocket accetta socket di ritorno su una porta arbitraria?

Question

Ho visto molte risposte simili a questo per quanto riguarda i server socket in java: "Supponiamo che tu abbia un server con un serverocket sulla porta 5000. Il client A e il client B si connetteranno al nostro server

Client A invia una richiesta al Server sulla porta 5000. La porta sul lato del Cliente A viene scelta dal Sistema Operativo, in genere il SO seleziona la porta successiva disponibile Il punto di partenza per questa ricerca è il numero di porta precedentemente utilizzato + 1 (quindi, ad esempio, se il sistema operativo si è verificato per la porta 45546 di recente, il sistema operativo proverebbe quindi 45547).

Supponendo che non vi siano problemi di connessione, il server riceve la richiesta del client A di connettersi sulla porta 5000. Il server quindi apre la sua prossima porta disponibile, e lo invia al cliente. Qui, il client A si collega alla nuova porta e il server ha di nuovo disponibile la porta 5000. "

Ho visto risposte come questa in più domande su StackOverflow su come viene utilizzata una porta diversa nel socket restituito del accept() della porta su cui è in ascolto ServerSocket. Ho sempre avuto l'impressione che TCP sia identificato dal quartetto di informazioni:

IP client: porta client e IP server: porta server - anche protocollo (per distinguere TCP da UDP)

Quindi, perché accept() deve restituire un socket associato a una porta diversa? Il quartetto di informazioni inviato in ogni intestazione non distingue più connectio ns alla stessa porta server di macchine diverse abbastanza dove non avrebbe bisogno di usare porte diverse sulla macchina server per la comunicazione?

Answer 1

Si è corretti nelle informazioni dell'intestazione del pacchetto TCP. Contiene:

Client IP | Client Port | Server IP | Server Port | Protocol 

Oppure, in modo più appropriato (dal client/server diventano fonte di confusione quando si pensa di trasferimento bidirezionale):

Source IP | Source Port | Destination IP | Destination Port | Protocol 

connessioni multiple verso lo stesso porto di server verranno da diverso porte sul client. Un esempio può essere:

0.0.0.0:45000 -> 1.1.1.1:80 
0.0.0.0:45001 -> 1.1.1.1:80 

La differenza nei porti client è sufficiente per disambiguare le due prese, ed avere così due connessioni separate. Non è necessario che il server apra un altro socket su un'altra porta. Riceve una presa dal metodo accept, ma è assegnata alla stessa porta e ora è un percorso di ritorno al client appena accettato.

FTP, d'altra parte, ha un modello in cui il server aprirà una nuova porta non privilegiata (> 1023) e lo invierà al client per il client a cui connettersi (questo è indicato come "FTP passivo" "). Questo serve a risolvere problemi in cui il client si trova dietro un firewall e non può accettare connessioni dati in entrata dal server. Tuttavia, questo non è il caso in un tipico server HTTP (o qualsiasi altra implementazione socket standard). È una funzionalità stratificata su FTP.

Answer 2

Il server apre la propria successiva porta disponibile e lo invia al client.

No. Si crea un nuovo socket con il numero di porta locale stesso. Nessun secondo numero di porta viene assegnato o inviato al client.Il segmento SYN/ACK che è la risposta del server alla richiesta di connessione non contiene un secondo numero di porta.

Qui, Client Un collega alla nuova porta,

No. Il cliente prende atto del/pacchetto ACK SYN e il client è connesso alla porta originaleda allora in poi, dopo aver riconosciuto il SYN/ACK. Non c'è una seconda connessione.

e il server ora ha di nuovo la porta 5000 disponibile ".

E 'sempre fatto.

Ho visto risposte come questo in domande a risposta multipla su StackOverflow su come una porta diversa viene utilizzato nel socket restituito dell'accettazione() della porta su cui è in ascolto ServerSocket.

Qualsiasi risposta di questo tipo è errato e dovrebbe essere messo in down con 'pregiudizio estremo' e commentato negativamente. L'handshake TCP è definito in RFC 793 e non specifica l'allocazione e lo scambio di una seconda porta e un secondo messaggio di connessione. Ci sono solo tre messaggi, che non sono nemmeno sufficienti per questo.

Quindi perché accept() deve restituire un socket associato a una porta diversa?

Non funziona.

Il quartetto di informazioni inviato in ogni intestazione non distingue più connessioni alla stessa porta server da macchine diverse abbastanza da non dover utilizzare diverse porte sulla macchina server per la comunicazione?

Sì.