Esiste un algoritmo per fingerprinting l'algoritmo di controllo della congestione TCP utilizzata in una sessione di catturato?
-
22-08-2019 - |
Domanda
Vorrei un programma per determinare l'algoritmo di controllo della congestione TCP utilizzato in una sessione TCP catturato .
L'articolo di Wikipedia riferimento afferma:
TCP New Reno è il più comunemente implementato l'algoritmo, il supporto è SACCO molto comune ed è un'estensione Reno / New Reno. La maggior parte degli altri sono proposte concorrenti che devono ancora valutazione. Partendo con la 2.6.8 Linux kernel acceso il default implementazione da Reno a Bic. Il implementazione di default era di nuovo cambiato cubi nel 2.6.19 versione.
Inoltre:
TCP composto è un Microsoft implementazione di TCP che mantiene due finestre di congestione diversi contemporaneamente, con l'obiettivo di raggiungimento di buone prestazioni su LFN pur non pregiudicare l'equità. Esso ha stato ampiamente distribuito con Microsoft Windows Vista e Windows Server 2008 ed è stato portato a più vecchio Microsoft le versioni di Windows così come Linux.
Quali sarebbero alcune strategie per determinare quale algoritmo CC è in uso (da un terzo cattura della sessione)?
Aggiorna
Questo progetto ha costruito uno strumento per fare questo:
L'Internet è stato di recente evolvendo da congestione omogenea controllo di congestione eterogenea controllo. Diversi anni fa, Internet il traffico è stato controllato principalmente dalla algoritmo standard TCP AIMD, mentre il traffico Internet è ora controllata da molti controllo di congestione TCP diverso algoritmi, come AIMD, BIC, cubica, CTCP, HSTCP, HTCP, HYBLA, Illinois, LP, STCP, VEGAS, VENO, WESTWOOD +, e SI. Tuttavia, non v'è molto poco lavorare sulle prestazioni e stabilità studio di Internet con controllo della congestione eterogenea. Uno motivo fondamentale è la mancanza di Informazioni per la distribuzione di diversi Algoritmi TCP. Gli obiettivi di questa progetto sono:
1) develop tools for identifying the TCP algorithms in the Internet, 2) conduct large-scale TCP-algorithm measurements in the Internet.
Soluzione
Ci sono molti algoritmi di controllo più congestione che si parla qui, la parte superiore della mia testa l'elenco comprende:. Veloce, scalabile, HSTCP, HTCP, Bic, Cubic, Veno, Vegas
Ci sono anche piccole variazioni di loro a causa di correzioni di bug nelle implementazioni reali e direi che le implementazioni in diversi sistemi operativi si comportano anche leggermente diversi l'uno dall'altro.
Ma se ho bisogno di cercare di trovare un'idea che sarebbe stato per stimare la RTT della connessione, si può provare a guardare il tempo impiegato tra il terzo e il quarto pacchetti, come i primi e secondi pacchetti può essere viziata da ARP e altri algoritmi di scoperta lungo il percorso.
Dopo aver ottenuto un preventivo per RTT si potrebbe provare a perfezionare lungo la strada, io non sono esattamente sicuro di come si possa fare ciò, però. Ma non si richiede una specifica completa per il programma, solo idee: -)
Con l'RTT capito si può provare a mettere i pacchetti in bidoni RTT e contare il numero di pacchetti di dati in volo in ogni bin. In questo modo sarete in grado di "complotto"-cwnd stimato (# di pacchetti in bin) a tempo e provare alcuni pattern matching lì.
Un'alternativa sarebbe quella di andare lungo la traccia e cercare di "run" nella tua testa i diversi algoritmi di controllo della congestione e vedere se la decisione in qualsiasi punto corrisponde con la decisione avresti fatto. Ciò richiederà alcuni intervalli di clemenza e di precisione.
Questo suona decisamente come un compito interessante e stimolante!