bps (bit al secondo)

bps (bit al secondo, b minuscola) è l’unità standard per la velocità di trasmissione dati. Multipli comuni: kbps (kilobit, 10³), Mbps (megabit, 10⁶), Gbps (gigabit, 10⁹).

Distinzione cruciale: bps (bit) non è Bps (byte). 1 byte = 8 bit, quindi una connessione internet da 100 Mbps fornisce un massimo teorico di 12,5 MB/s (megabyte al secondo). Il rapporto 8× è una fonte comune di confusione nel marketing degli ISP — “100 megabit” suona veloce ma scarica file a velocità di “12,5 megabyte” al secondo.

Velocità di riferimento:

• Modem dial-up (anni ’90): 56 kbps
• Audio CD: 1.411 kbps (PCM non compresso)
• MP3 (alta qualità): 320 kbps
• Spotify (Premium): 320 kbps Ogg Vorbis
• Video YouTube 1080p: ~5 Mbps
• Netflix 4K HDR: ~25 Mbps
• Fibra ottica moderna: 1-10 Gbps
• USB 3.2: 20 Gbps
• Thunderbolt 4: 40 Gbps
• Backbone datacenter Ethernet: 100-400 Gbps

Per la capacità di archiviazione dati, il byte (o kilobyte, megabyte, ecc.) è l’unità standard. La convenzione è essenzialmente: velocità in bit, capacità in byte. Quasi ogni scheda tecnica di prodotto segue questa regola.

Perché gli ISP citano i bit e non i byte: la convenzione risale all’era in cui la maggior parte dei dati era testo su linea seriale e il bit era l’unità naturale sul filo. Ha anche un vantaggio di marketing: “100 Mbps” suona otto volte più grande di “12,5 MB/s”, quindi ogni piano consumer-ISP è quotato in bit. I produttori di storage hanno imparato il trucco inverso e citano i byte (un disco da 1 TB sembra più grande di “8 Tbit”). Entrambe le convenzioni sono tecnicamente corrette ma garantiscono che il numero dall’aspetto più grande si trovi sempre accanto al prezzo.

Larghezza di banda pubblicizzata vs effettiva: una connessione da 100 Mbps raramente fornisce 12,5 MB/s in pratica. L’overhead TCP (~3-5%), i costi dell’handshake TLS, il framing della richiesta/risposta HTTP e la congestione dell’ultimo miglio mangiano insieme il 10-30% della velocità nominale su un sito web tipico. Per un test di velocità pulito come fast.com o speedtest.net, aspettati di vedere l’85-95% della velocità pubblicizzata; per download di file reali da un singolo server in un altro paese, il 50-70% è normale. Correlato: latenza, hertz. Riferimento: ITU-T — Standard di trasmissione dati.

Esempio pratico: quanto tempo ci vuole per scaricare un gioco da 4 GB

Un gioco da 4 GB su una connessione da 100 Mbps: converti in bit = 4 × 8 = 32 Gbit = 32.000 Mbit. Tempo minimo teorico = 32.000 / 100 = 320 s ≈ 5 min 20 s. Nel mondo reale: assumendo l’80% della velocità pubblicizzata a causa dell’overhead TCP e HTTP, circa 6 min 40 s. Su una linea in fibra da 1 Gbps lo stesso download richiede ~40 s; su un cavo da 25 Mbps saturo condiviso con uno stream Netflix 4K (che consuma ~25 Mbps del collegamento), la larghezza di banda rimanente può essere inferiore a 1 Mbps e il download si estende oltre un’ora. Ecco perché le cache CDN-edge e il multiplexing HTTP/2 — entrambi i quali aumentano la concorrenza effettiva senza aumentare i bps grezzi — contano più della velocità di picco del collegamento per l’esperienza di navigazione.

Quando la distinzione bit/byte morde nel codice

I preset di transcodifica video sono quotati in bps (kbps per l’audio, Mbps per il video); i limiti di archiviazione nei container, le policy del ciclo di vita S3 e i limiti di memoria Lambda sono in byte. Mescolare questi ha causato bug reali in produzione: un allarme di uscita CDN impostato su “50 MB/s” quando la metrica era in realtà 50 Mbps è scattato 8 volte troppo spesso e è stato silenziato, mascherando un vero incidente di esfiltrazione in almeno un postmortem pubblicato. L’abitudine difensiva: includi sempre l’unità nei nomi delle variabili — video_bitrate_mbps, non video_bitrate. Vedi anche kibibyte per la trappola parallela binario-vs-decimale sul lato dello storage, e il RFC 1191 dell’IETF sul path MTU discovery per capire perché la velocità effettiva sul filo raramente corrisponde al numero nominale.