AFP vs SMB su Mac (+ migliorare performance SMB)

[EdoFede]

Ciao a tutti,

apro questo thread dopo essermi imbattuto in un problema fastidioso a cui ho trovato soluzione.

Premessa: Ho server/NAS in rete a casa da molti anni, con supporto a protocolli AFP, SMB e altri. Ero abituato ad accedervi dalla sidebar di Finder, dove trovavo il server/NAS, entrando poi nella share che mi serviva al momento.
Fino a Mavericks (forse anche Yosemite, ma non sicuro al 100%..) l'accesso avveniva automaticamente con protocollo AFP, successivamente hanno pensato bene di passare a SMB come protocollo default.
In pratica, dopo l'aggiornamento mi sono trovato le share molto più lente, la cpu molto più carica durante i trasferimenti ed in generale la navigazione era molto meno responsiva di prima.

Ho aggirato il problema con un semplice script che monta tutte le mie share (oppure con cmd+K e connessione diretta), ma volevo verificare meglio sta faccenda.

Ho quindi fatto un test di velocità di trasferimento, che vi riporto.
La prova consiste nel montare la stessa share in diverse modalità e trasferire lo stesso file su SSD del mac locale.



Partiamo con AFP

Questa la velocità di trasferimento:


Questo il carico CPU durante il trasferimento (su i7 4.0 GHz):


Come si nota, il trasferimento satura la connessione gigabit (121 MB/s su 125 MB/s teorici).



Passiamo ora a SMB

Velocità di trasferimento non dimezzata, ma quasi...


Carico CPU sensibilmente più elevato:


Inutile aggiungere che con macchine meno performanti (CPU), la differenza si fa sentire decisamente di più.
Ad esempio con il mio vecchio Mac Mini (mid 2011), il trasferimento via SMB andava decisamente più lento rispetto a questa prova.


A questo punto, ho svolto la stessa prova con le stesse modalità, ma...
Da windows 10 su bootcamp

Velocità di trasferimento leggermente più bassa e carico CPU leggermente più alto (il 7% è calcolato sul totale, non sul singolo thread come su OS X)




La stessa prova su macchina virtuale windows 10
(stessa identica installazione da cui ho clonato il disco per bootcamp oggi stesso)



La copia, tanto per complicare le cose , avviene dal NAS verso una share su Mac condivisa tramite parallels.
Velocità di trasferimento uguale, carico CPU nella VM uguale (risulta doppio nel riepilogo perché sulla VM ho configurato 4 vCPU delle 8 disponibili), carico CPU su host più elevato.



Che succede?!
Insomma... possibile che dopo aver passato le connessioni verso SMB, dichiarando oltretutto migliori performance (!!! - se ritrovo il link apple lo posto), ci si trovi nella situazione in cui il trasferimento fa pena SOLO su OS X e che vada addirittura meglio dentro una macchina virtuale?
Eh si, possibilissimo. anzi è proprio così!

Fortunatamente dopo un po' di indagini, ho trovato il colpevole: il Packet Signing SMB !

Una breve verifica conferma che viene attivato di default quando Mac si connette ad una share SMB (ultima riga):




Soluzione
La soluzione è quindi disattivare il packet signing nel file di configurazione del client SMB.
Procedura descritta qui:
https://support.apple.com/en-us/HT205926" onclick="window.open(this.href);return false;



Un altro test a valle della modifica conferma che ora è tutto ok.

Velocità lievemente inferiore rispetto ad AFP:


Carico CPU ora basso (leggermente più basso anche rispetto ad AFP):


Assurdo che di default sia attivata sta roba...(che su una LAN ha veramente poco senso...)



E invece che succede sul Server/NAS?!
In ultimo, per non lasciare punti aperti, vediamo la differenza lato NAS

Trasferimento via AFP:


Trasferimento via SMB:


Decisamente più alto il carico CPU con SMB



Ciao,
Edo

[LeoTM]

bel lavoro

[Hammarby]

Bel lavoro?
Disattivare il calcolo della firma sui pacchetti non è un fare bel lavoro.
SMB è un protocollo Microsoft, ed ha una serie di caratteristiche, tra cui la pesantezza e la sicurezza.
Se Apple non è stata in grado di implementarlo efficientemente, non è un problema di protocollo,
e se si decide di rinunciare alla sicurezza ed alla consistenza dei dati trasportati, poi non ci si venga a lamentare se si corrompono i dati.

[LeoTM]

Bel lavoro?
Disattivare il calcolo della firma sui pacchetti non è un fare bel lavoro.
SMB è un protocollo Microsoft, ed ha una serie di caratteristiche, tra cui la pesantezza e la sicurezza.
Se Apple non è stata in grado di implementarlo efficientemente, non è un problema di protocollo,
e se si decide di rinunciare alla sicurezza ed alla consistenza dei dati trasportati, poi non ci si venga a lamentare se si corrompono i dati.

Se l'ottica è utilizzarlo nella rete di casa non vedo nessun problema nell'operazione di cui sopra.
Sui apple e i soliti casini con smb (ma anche afp) non mi dilungo, ci ho litigato per anni con la loro incompetenza in merito a share di rete.

[EdoFede]

Bel lavoro?
Disattivare il calcolo della firma sui pacchetti non è un fare bel lavoro.
SMB è un protocollo Microsoft, ed ha una serie di caratteristiche, tra cui la pesantezza e la sicurezza.
Se Apple non è stata in grado di implementarlo efficientemente, non è un problema di protocollo,
e se si decide di rinunciare alla sicurezza ed alla consistenza dei dati trasportati, poi non ci si venga a lamentare se si corrompono i dati.

Ah guarda, ho saputo che son morti parecchi a disattivarlo!
Scherzi a parte... mi sembra un po' fuori luogo il tono del tuo intervento.
Mi spiego, sperando di tornare su toni più tranquilli.

Innanzitutto ci tengo a correggere l'ultima tua affermazione, che sembra allarmare gli altri lettori senza motivo: disattivando il packet signing non si rinuncia affatto alla consistenza dei dati trasportati, ne si rischiano corruzioni.

Il packet signing è stato sviluppato per evitare che un utente malintenzionato (o un bot) possa "sniffare" pacchetti in transito sulla rete locale ed impossessarsi od alterare il contenuto dei pacchetti in transito durante un trasferimento dati SMB.
(Un documento microsoft inerente, a supporto: https://technet.microsoft.com/en-us/library/jj852239(v=ws.11" onclick="window.open(this.href);return false;).aspx )

Ora, avessi un servizio SMB aperto verso internet, oppure fossi una banca con una LAN enorme e potenziali problemi di sicurezza, chiaramente NON sarebbe certo questa la strada da percorrere.
D'altra parte, in ambienti dove la sicurezza è a questi livelli, i server SMB vengono configurati per richiedere obbligatoriamente il packet signing (oltre a tanti altri accorgimenti anche a livello di segmentazione della rete). Quindi, anche in questi casi, il problema non si pone.

Come scritto chiaramente nella premessa, si tratta di tutt'altro scenario: una rete casalinga

Mi sbilancio inoltre aggiungendo che non vedo alcun problema ad effettuare la stessa operazione anche su reti aziendali dove non ci siano rischi imminenti di attacchi dall'interno. Anche perchè in questo caso, direi che ci sono 10.000 modi più semplici per violare una rete dall'interno, senza ricorrere agli stratagemmi che il packet signing cerca di arginare

Sul fatto che Apple non sia stata in grado di implementarlo efficientemente, sono d'accordo con te.
Come del resto accade con protocolli proprietari che devono integrarsi con mondi differenti. Difatti ho un luuuungo elenco di problemi assurdi di comunicazione tra sistemi eterogenei dovuti quasi sempre al utilizzo di SMB e il relativo Samba per sistemi non windows.

Ciao,
Edo

[Hammarby]

Sulla propria rete ognuno fa come vuole, però proprio in quel bollettino Microsoft spiega che

Codice: Seleziona tutto

Implementation of digital signatures in high-security networks helps to prevent the impersonation of client computers and servers, which is known as "session hijacking." But misuse of these policy settings is a common error that can cause data loss or problems with data access or security.
...
Using SMB packet signing can impose up to a 15 percent performance degradation on file service transactions.

ed in ogni caso chi legge questi suggerimenti, prima di attuarli dovrebbe capire cosa sta facendo.

Hai fatto bene a postare il link al bollettino Microsoft

Un saluto,
/H

[kext]

ehm, in caso di collisione tra pacchetti?

[EdoFede]

ed in ogni caso chi legge questi suggerimenti, prima di attuarli dovrebbe capire cosa sta facendo.

senza dubbio

Era rivolto ai meno smanettoni (o meno dentro l'ambiente). Chiaro che se uno gestisce una rete di una certa dimensione, deve avere un approccio differente.


kext: in che senso collisione tra pacchetti?
Le collisioni vengono gestite a livello più basso, non interessano i protocolli su application layer (smb, ftp, ssh, ecc...)

Ciao,
Edo

[kext]

Solo per curiosità: il Packet signing SMB a che livello opera?

[EdoFede]

Sempre application layer

[kext]

Quindi opera a livello del protocollo.. Mh, mi son fatto ingannare dal nome..

[scap61]

ricordo male che smb e' nato in ibm ma poi approppriato da windows ??

[EdoFede]

Si, nato da IBM, poi Microsoft ne ha sviluppato la sua versione:
https://en.wikipedia.org/wiki/Server_Me ... ck#History" onclick="window.open(this.href);return false;

[kext]

stamane ho fatto le pulizie sul mac di produzione con una bella passata di zeri su tutto il disco e reinstallando macOS..
Bene, dopo aver letto giorni fa questo topic, ho deciso di fare delle prove empiriche sul campo con AFP e SMB. Preciso che in LAN ero presente solo io con 3 mac (di cui uno è il server).

Con AFP avevo sì banda/velocità in più, ma in confronto con SMB la differenza era della misura del 10% e basso carico sulla CPU.
Con SMB, invece, la velocità variava a seconda della dimensione del file, con picchi di 105mbps (picco positivo), media degli 85mbps ma anche cali intorno ai 45-50mbps (picco negativo); il carico sulla CPU è maggiore rispetto ad AFP, quasi del 15-20% in più..

Caso vuole che con le stesse immagini .dmg trasferite con AFP, 2 su 8 le ho dovute riaprire/scaricare di nuovo poiché corrotte; con SMB, invece, nessun problema di nessun tipo. In totale ho trasferito 260gb con AFP (2 dmg corrotti) e 260gb con SMB (0 dmg corrotti)..
Domani provo con il macbookpro in Wi-Fi e vedo se cambia qualcosa (oltre alla velocità, ovviamente)..

[EdoFede]

Corruzioni con AFP???

Ho trasferito tera e tera di roba via AFP da vari mac a vari nas/server, senza mai alcuna corruzione. (tra l'altro quasi sempre usando AFP via UDP, non via TCP).

Mi sembra stranissimo che sia un problema di protocollo.
Andavi in AFP via UDP o TCP?