Qual è l'uso della colonna Recv-Q e Send-Q nell'output di comando netstat E quando lo usiamo nello scenario in tempo reale? Nel mio sistema, entrambe le colonne sono sempre mostrate come zero. Qual è il significato per questo?Uso di Recv-Q e Send-Q
Dalla mia pagina man:
Recv-Q
Fondata: Il numero di byte non copiati dal programma utente collegato a questa presa.
Ascolto: dal kernel 2.6.18 questa colonna contiene il backlog syn corrente.
Send-Q
Fondata: Il numero di byte non riconosciuti dall'host remoto .
Ascolto: dal kernel 2.6.18 questa colonna contiene la dimensione massima del backlog syn.
Se questo è bloccato a 0, ciò significa solo che le applicazioni, su entrambi i lati della connessione, e la rete tra loro, stanno facendo OK. I valori istantanei effettivi possono essere diversi da 0, ma in modo transitorio e fuggitivo che non si ha la possibilità di osservarlo realmente.
Esempio di scenario di vita reale in cui questo potrebbe essere diverso da 0 (su connessioni stabilite ma penso che si ottiene l'idea):
Recentemente ho lavorato su un dispositivo embedded Linux a parlare con un (mal progettato) dispositivo di terze parti. Su questo dispositivo di terze parti, l'applicazione si è chiaramente bloccata a volte, non leggendo i dati ricevuti sulla connessione TCP, facendo sì che la finestra TCP scendesse a 0 e rimanesse bloccata lì per decine di secondi (fenomeno osservato tramite wireshark su una porta speculare tra i 2 ospiti). In tal caso:
Recv-Q: esecuzione netstatil terzo dispositivo parte (che avevo non significare fare) può avere mostrerebbe un aumento Recv-Q, fino a un valore tetto dove l'altro lato (io) interrompe l'invio di dati perché la finestra ottiene fino a 0, poiché l'applicazione non legge i dati disponibili su suo socket e questi dati rimangono bufferizzati nell'implementazione TCP nel il SO, non andando per l'applicazione bloccata ->dal lato ricevitore , problema di applicazione.
Send-Q: esecuzione netstat sul mia lato (che non ho provato perché 1/il problema era chiaro da Wireshark e fu il primo caso di cui sopra e 2/questo non era al 100% riproducibile) possono avere mostrare un non-zero Send-Q, se l'altra implementazione TCP lato a livello del sistema operativo sono stati stucked e si fermò ACKnowleding miei dati ->dal lato del mittente , ricevendo implementazione TCP (tipicamente a t he livello OS) problema.
Nota che lo scenario Send-Q descritto sopra può anche essere un problema lato di invio (lato mia) se mia implementazione Linux TCP era comportato male e ha continuato a inviare i dati dopo la finestra TCP è sceso a 0 : il lato ricevente non ha più spazio per questi dati -> non ACKnowledge.
Si noti inoltre che il problema Send-Q potrebbe non essere causato dal ricevitore, ma da qualche problema di routing tra il mittente e il destinatario. Alcuni pacchetti sono "al volo" tra i 2 host, ma non ancora ACKnowledge. D'altra parte, il problema Recv-Q è definitivamente su un host: pacchetti ricevuti, ACK riconosciuti, ma non letti ancora dall'applicazione.
EDIT:
Nella vita reale, con gli host e le applicazioni, come si può ragionevolmente aspettarsi, scommetterei la questione Send-Q per essere causato la maggior parte del tempo da qualche problema di routing non schifosi/scarsa prestazione della rete tra il lato di invio e quello di ricezione. Lo stato "on the fly" dei pacchetti non dovrebbe mai essere dimenticato:
Il pacchetto può essere in rete tra il mittente e il destinatario,
(o percepiti, ma ACK non ancora inviare, vedi sopra)
o l'ACK può trovarsi sulla rete tra il destinatario e il mittente.
Richiede un RTT (round time trip) per un pacchetto da inviare e quindi ACKed.