Linux Slow Start: la modifica della route ip non ha alcun effetto sulla finestra iniziale

Ho cambiato la finestra iniziale di TCPC nella mia macchina su 10, come mostrato di seguito

[user@site etc]$ sudo ip route change default via 17.255.209.1 dev eth0  proto static initcwnd 10

E modificato tcp_slow_start_after_idlecome mostrato di seguito

[user@site etc]$ sudo sysctl -a | grep tcp_slow_start_after_idle
net.ipv4.tcp_slow_start_after_idle = 0

di seguito viene fornita una conferma dello spettacolo del percorso ip

[user@site etc]$ ip route show
default via 17.255.209.1 dev eth0  proto static  initcwnd 10
169.254.0.0/16 dev eth0  scope link  metric 1002
17.255.209.0/24 dev eth0  proto kernel  scope link  src 17.255.209.19

Ora, quando eseguo un tcpdump sul sito Web, non mi sembra di vedere un cambiamento nella finestra iniziale con WIN / MSS che rimane 4 come predefinito. 5840/1460 = 4

[user@site etc]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and port 80'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:17:45.048174 IP 21.101.151.198.45873 > 17.255.209.19.http: Flags [S], seq 2008673341, win 5840, options [mss 1460,sackOK,TS val 1724223146 ecr 0,nop,wscale 6], length 0

Il colpo di curl che ho fatto alla pagina web ha richiesto circa 30 KB di dati.

[user@machine ~]$ curl http://www.site.com/js/main.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 88212  100 88212    0     0   179k      0 --:--:-- --:--:-- --:--:--  272k

Cosa potrebbe esserci di sbagliato nel mio approccio?

nocciolo

[user~]$ uname -r
3.0.4x86_64-linode21

Come aggiornamento, ecco i risultati quando provo google.com

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.google.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:20:28.033236 IP 17.255.209.19.42799 > 74.125.127.106.http: Flags [S], seq 3148947324, win 14600, options [mss 1460,sackOK,TS val 193695310 ecr 0,nop,wscale 4], length 0

Come puoi vedere WIN / MSS è 14600/1460 = 10 in questo caso

Ho provato a colpire il mio sito dalla stessa macchina server attraverso l'arricciatura ed ecco il risultato:

[user@site ~]$ sudo tcpdump -n -i any 'tcp[tcpflags] & (tcp-syn|tcp-ack) == tcp-syn and host www.site.com'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:25:14.584338 IP 17.255.209.19.35008 > 17.255.209.19.http: Flags [S], seq 3894567470, win 32792, options [mss 16396,sackOK,TS val 193981861 ecr 0,nop,wscale 4], length 0

WIN / MSS è 32792/16396 = 2 in questo caso

— Quintin Par
fonte

tieni presente che se stai colpendo questo da una macchina linux dovrai anche essere su 3.0, scorrerai i sorgenti / tag per confermare l'esatta versione 3 che ha istallato la modifica

— Sam Saffron

@QuintinPar Potresti aggiungere l'output di tcpdump con la connessione in uscita dalla tua macchina di prova?

— Kupson,

@kupson Ho aggiornato la domanda

— Quintin Par

Per quanto ne so, non è possibile influenzare la finestra iniziale sulle connessioni in entrata. La tua connessione a google mostra che IW è impostato su 10. Inferface loopback è abbastanza speciale con quell'MTU di grandi dimensioni, forse c'è un limite sulla finestra iniziale nel sorgente del kernel.

— kupson,

tieni presente che 2 cose determineranno l'IW. Finestra di congestione iniziale massima dei client e server IW. Il più piccolo vince. Esegui il test da 2 macchine, il server dovrebbe avere l'IW impostato di default in 3.0 ... e i client XP / Vista / Win7 non limitano l'IW, quindi fai dei buoni client per il test. 3.0 Anche i client Linux funzionano, ma devono essere una macchina separata.

— Sam Saffron,

Risposte:

Penso che tu stia fraintendendo come funziona TCP.

Ogni pacchetto inviato pubblicizzerà sempre una finestra del ricevitore (aka. RWIN) e un fattore di ridimensionamento opzionale, vedere RFC 1323

Al mittente non è consentito inviare più della quantità di dati specificata in RWIN senza che venga riconosciuta. A seconda della finestra di congestione, il mittente può decidere di compilare RWIN oppure no.

Quindi, ci sono due bit di informazione che sono pubblici nei pacchetti TCP. RWIN sul server e RWIN sul client. Entrambe queste figure determinano quale può essere la dimensione massima della finestra di congestione su entrambe le estremità.

L'RWIN sul server è interessante quando stiamo cercando di ottimizzare le prestazioni per esempio caricamenti di file.

L'RWIN sul client è interessante quando stiamo cercando di determinare la velocità di download.

Nessuno di questi numeri rende pubblica la finestra di congestione sull'altra estremità .

Quindi, se ho un RWIN di 64k, la finestra di congestione sul server può essere QUALSIASI numero inferiore a 64k.

L'unico modo per determinare quale sia la finestra di congestione effettiva è contare i pacchetti.

Se lo so:

Il mio tempo di andata e ritorno (RTT) è di ~ 200 ms.
Ho appena richiesto una risorsa di 100k.
Ho un RWIN di 64k.

Se ricevo 2 pacchetti dal server che sono lunghi 1452 byte entro ~ 200 ms, è probabile che la finestra di congestione sul server sia più piccola di 4356, perché se fossero inviati 3 pacchetti più grandi. Se IW fosse impostato su 10, vedrei un'esplosione di 10 pacchetti attorno al segno di 200 ms.

Se si modifica l'IW e si desidera confermare che la modifica ha funzionato, è necessario contare i pacchetti per ottenere una stima sulla dimensione della finestra di congestione sul server.

Ricorda, probabilmente vorrai guardare la conversazione direttamente dopo SYN, SYN-ACK, ACK per assicurarti di non guardare al centro di una conversazione (dove la finestra di congestione potrebbe essere già cresciuta).

— Sam Saffron
fonte

La differenza tra la finestra di congestione e la finestra tcp è dichiarata in 20.6 (avvio lento) di TCP / IP Illustrated: "L'avvio lento aggiunge un'altra finestra al TCP del mittente: la finestra di congestione, chiamata cwnd" (grassetto è mio). C'è un diagramma di sequenza in 20.7 che lo mostra durante il trasferimento di massa.

— Kyle Brandt,

La dimensione della finestra sarà la più piccola: dimensione della finestra di iniz server o client RWIN. Poiché 5840 è il RWIN predefinito per Linux 2.6, sembra che il tuo client sia il fattore limitante qui.

Prova da una finestra di Windows. Windows XP ha un RWIN di 64k, la versione 8k più recente.

Fonte: http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/ (La parte interessante è sotto il video)

Modifica: espandere la risposta per renderla più chiara:

Nell'handshake TCP, il client invia un pacchetto SYN al server inviando la dimensione massima consentita della finestra. (Come mostra l'output di tcpdump, questi sono 5840 byte)
Il server ora risponde con SYN ACK e le dimensioni della finestra su cui desidera concordare. Questa dimensione della finestra può essere solo più piccola di quella proposta dal cliente, non più grande. Indipendentemente dalla configurazione del server, con quel client non può mai avere dimensioni di finestra maggiori di 5840 byte.
Il cliente restituisce ACK e si scambiano felicemente i dati per sempre.

Modifica2: I tcpdumps aggiunti alla domanda mostrano il server che apre le connessioni a google e si funge da CLIENTE.

— Qualcuno
fonte

La finestra iniziale (proposta nel pacchetto SYN) è 5840. In questo momento è un primo pacchetto e la macchina di invio non sa nulla del ricevitore (l'ho provato con "ip route flush cache").

— kupson,

Uh, 17.255.209.0 è la tua sottorete del server, giusto? Il pacchetto che stai vedendo è DAL 21.101.151.198.45873 AL 17.255.209.19.http. Non sono un esperto dell'output di tcpdump, ma per me questo dice: Ciao Server, sono il tuo client, mi piacciono le finestre a 5840 byte. :) Il pacchetto successivo sarebbe il server che risponde con ACK, 5840 è fantastico, evviva. :)

— Qualcuno il

Solo per sottolineare, penso che tu abbia capito nel modo sbagliato: il primo mittente è il client mentre apre la connessione, non il tuo server. È il client che offre la finestra di 5840 byte. Il server non può proporre una finestra più grande, solo una più piccola.

— Qualcuno il

Non sono l'autore originale di questa domanda. L'ho provato (con risultati simili) sul mio ambiente di test e non posso cambiarlo. La dimensione della finestra di congestione iniziale (initcwnd) non ha nulla a che fare con l'altro lato della connessione.

— kupson,

Non conosco la tua configurazione. Il poster originale chiedeva perché, nonostante aumentasse la dimensione della finestra iniziale sul server, la sua connessione di prova ha una dimensione della finestra di 5840 byte. La risposta è: poiché il client con cui ha testato non consente una finestra di dimensioni maggiori. Non posso commentare altre configurazioni o forse altri problemi / bug con il concetto in generale.

— Qualcuno il