Posso eseguire la sessione TCP / IP per meno di 60 secondi?

8

Il nostro server è sovraccarico di sessioni TCP / IP, ne abbiamo 1200-1500. La maggior parte di essi è sospesa nello stato TIME_OUT. Si scopre che una connessione nello stato TIME_OUT occupa un socket fino a quando è trascorso il timeout di 60 secondi.

Il problema è che il server non risponde e molti client non vengono serviti.

Ho fatto un semplice test: scarica un file XML dal server con Internet Explorer 8.0 Il download termina in una frazione di secondo. Ma poi vedo che la connessione TCP / IP si blocca nello stato TIME_OUT per 60 secondi.

Esiste un modo per sbarazzarsi di TIME_OUT in attesa o rendere meno per liberare il socket per le nuove connessioni?

Comprendo perché la connessione TCP / IP entra nello stato TIME_OUT, ma non capisco perché Internet Explorer non chiuda la connessione al termine del download del file XML.

I dettagli.

Il nostro server esegue un servizio Web scritto in Perl (mod-perl). Il servizio fornisce dati meteorologici ai clienti. Il client è un'applicazione Flash (in realtà il controllo ActiveX Flash incorporato nell'applicazione Windows).

Sistema operativo: Ubuntu

L'opzione "Keep Alive" di Apache è impostata su 0

— par
fonte

Se capisci perché entra nello stato TIME_OUT, devi capire perché questo è necessario per prevenire altri attacchi e problemi. È possibile ridurre questo timeout, ma ci sono altre conseguenze nel farlo.

— davr

La sintassi è KeepAlive on|off. KeepAlive 0è la sintassi di Apache 1.1; Presumo che tu non lo stia usando.

— mark4o

La sessione 1500 T / O non rende il sistema non rispondente. C'è un altro motivo.

— poige

Le connessioni passano attraverso un router economico?

— LatinSuD,

7

Questa è un'impostazione nello stack TCP. Dal momento che non sappiamo quale piattaforma stai utilizzando, non possiamo dire esattamente come si chiama e come modificarlo.

AGGIORNARE

Quindi stai usando Ubuntu. È possibile utilizzare sysctlper ridurre il net.inet.tcp.mslvalore a metà della TIME_WAITdurata desiderata (in millisecondi - vedi man -S 4 tcp), ad es sysctl net.inet.tcp.msl=2500. Prestare attenzione alle implicazioni di farlo in relazione ai pacchetti erranti che possono arrivare dopo il TIME_WAITtermine del periodo.

— vladr
fonte

Il nostro server esegue Ubuntu, ho aggiornato i dettagli

— par

«1200 - 1500 di loro» non si esauriscono nemmeno con la calcolatrice, quindi non è il motivo per mettere a punto msl

— poige

1

Presumo che tu intenda TIME_WAIT. Il peer che avvia la chiusura attiva è quello che entra TIME_WAIT(vedere il diagramma di transizione dello stato qui ), quindi se è possibile far chiudere la connessione al client, si sposterà TIME_WAITil client. Vedi questa risposta per maggiori dettagli e un link a un buon articolo sui TIME_WAITproblemi e su come risolverli.

Un'altra alternativa, se non si riesce a far chiudere il client con la chiusura attiva, è ripristinare la connessione impostando il ritardo su false prima di chiuderla. Ciò causa un RSTinvio anziché FIN.

— Len Holgate
fonte

Oh grazie mille! Ma come posso controllare la connessione TCP / IP quando l'utente carica un file XML con Internet Explorer?

— par

TIME_WAITè normale e, a meno che le prestazioni del tuo server non soffrano a causa sua non è qualcosa di cui mi preoccuperei troppo. Quando il socket è inserito TIME_WAIT, occupa alcune risorse ma ciò non significa che la connessione sia ancora aperta o che il server lo stia ancora elaborando.

— Len Holgate,

0

Il server che non risponde probabilmente non ha nulla a che fare con il numero di connessioni nello stato TIME_WAIT. Non è chiaro cosa si intende per "occupa un socket" - il server dovrebbe da tempo avere closeil socket in quel punto. Il sistema dovrebbe essere in grado di gestire decine di migliaia di connessioni nello stato TIME_WAIT.

— David Schwartz
fonte