IP statica su GCP contro velocità VPN: tre variabili, un test
Un indirizzo riservato non è un’impostazione di velocità. Separa il ciclo di vita dell’indirizzo, il livello di rete e il trasporto OpenVPN prima di confrontare il throughput su Compute Engine.
Il trasferimento è diventato più veloce dopo la prenotazione dell’indirizzo, e la conclusione si è scritta da sola. Peccato che la stessa modifica abbia anche spostato il tunnel da UDP a TCP, spostato il test a un’altra sera e forse sia atterrata su una VM di un’altra zona. Prenotare un indirizzo esterno risolve un problema di ciclo di vita: mantiene lo stesso endpoint tra i riavvii. Non ha alcun meccanismo che accelererebbe i pacchetti, quindi la differenza di velocità in quell’esperimento appartiene alle altre variabili, e la decisione davanti a voi è quale testare dopo.
Che cosa compra davvero un indirizzo riservato
Compute Engine distingue gli indirizzi effimeri, allocati e rilasciati con l’istanza, dagli indirizzi statici che voi riservate e conservate. Quella differenza riguarda la conservazione e la fatturazione, non il percorso che compie un pacchetto. Un endpoint stabile è davvero utile per i record DNS, i profili di accesso remoto, le liste di autorizzazione dei partner e le regole del firewall che non dovrebbero cambiare al riavvio di una VM.
Sono buone ragioni per riservarne uno. Nessuna di esse è una ragione di throughput.
Tenete livello, indirizzo e trasporto come tre variabili
Google Cloud vende anche i livelli di servizio di rete Premium e Standard, ed entrambi seguono percorsi diversi verso internet con una diversa disponibilità di funzioni. L’indirizzamento statico è ortogonale a entrambi, quindi trattate statico e Premium come fatti non correlati su una VM e non come sinonimi. Registrate il livello effettivo, la regione e qualsiasi interconnect o attachment in gioco, perché descrivono il percorso in un modo che l’etichetta dell’indirizzo non farà mai.
Tre variabili, tre esperimenti separati, altrimenti il risultato è una storia e non una misura.
Progettate un test che risponda a una domanda
Tenete la VM, l’indirizzo, la posizione del client, la destinazione e il carico di lavoro fissi mentre confrontate profili UDP e TCP approvati. Servono sia un listener del server per trasporto sia regole del firewall corrispondenti; modificare una parola chiave del client e lasciare il listener invariato mette alla prova solo la vostra pazienza. Usate un trasferimento ripetibile e registrate direzione, durata, flussi singoli o paralleli e le unità, perché MB/s e Mb/s differiscono di un fattore otto.
Osservate anche la CPU della VM, perché un’istanza piccola si satura sul lavoro di crittografia o softirq molto prima della rete, e quel tetto sembrerà esattamente un limite del fornitore.
I contatori di ritrasmissione e perdita della VM e del client separano i problemi di percorso da quelli di trasporto, e una barra di avanzamento non può. Una sequenza praticabile con iperf3 richiede circa dieci minuti per trasporto. Avviate il server dall’altra parte, fate girare il client trenta secondi in ciascuna direzione e ripetete ogni direzione tre volte. Scartate la prima esecuzione di ogni serie, poi confrontate le velocità di mittente e destinatario insieme al numero di ritrasmissioni che le esecuzioni TCP stampano.
Perché UDP e TCP differiscono meccanicamente
OpenVPN su UDP trasporta datagrammi e lascia al trasporto proprio dell’applicazione la gestione delle perdite. Su TCP, il flusso affidabile del tunnel sta sotto un flusso applicativo già affidabile, così un segmento perso blocca tutto ciò che lo segue mentre la connessione esterna ritrasmette secondo il proprio calendario. Quel comportamento di testa di coda è una proprietà del tunnelling di TCP dentro TCP, non una politica del fornitore. Anche la gestione di MTU e MSS differisce tra i due modi, il che cambia il comportamento di frammentazione sullo stesso percorso.
Una prova TCP più veloce dimostra quindi che TCP era più veloce quel giorno su quel percorso, e nulla di più generale.
Scrivete il risultato in modo che sopravviva alla revisione
Una conclusione difendibile ha una forma: questo profilo, su questa dimensione di macchina, su questo livello di rete, ha sostenuto questo carico misurato in questa direzione in queste condizioni. Qualcosa di più ampio richiede più esecuzioni di quante una sera possa fornirne. Se il caso più lento resta inspiegato, conservatelo come osservazione con le sue prove di pacchetti e risorse invece di inventare una limitazione che nessun documento del fornitore descrive.
La stabilità dell’indirizzo e la velocità di trasferimento possono contare entrambe per la stessa distribuzione, e la decisione utile è quale delle due state comprando con ogni modifica.