SSH tunnel bandwidth overhead

[NTolerance]

I'm using an SSH tunnel to stream mp3s from a remote HTTP server. I'm just wondering what sort of bandwidth overhead an SSH tunnel imposes when used as opposed to a conventional connection to the HTTP server.

[NTolerance]

bump for curiosity

[tamoneya]

i dont think(feel free to correct me) ssh has much overhead bandwidth. It is transferring more or less the same amount of data but just in an encrypted form. The main over head of SSH lies in the encrypting and decrypting of the data which is an overhead on the CPU. Still given most of the computers today with high clock rate multicore processors it isnt an issue most of the time.

[NTolerance]

Excellent, thanks. One wonders why anyone bothers opening ports on routers when SSH tunnels work so well.

[tamoneya]

an ssh tunnel still requires an open port and it requires that computer authenticate with each other and exchange keys. For many protocols this doesnt make any sense and is totally unnecessary.

[NTolerance]

an ssh tunnel still requires an open port and it requires that computer authenticate with each other and exchange keys. For many protocols this doesnt make any sense and is totally unnecessary.

I was mainly referring to personal use such as mp3 streaming, mythweb access, file transfer, etc... After getting QoS tweaked on my router I've been able to eek every last bit per second out of my 384kb/sec upload and can usually stream 320kbps mp3s without interruption.

[weazzle]

i dont think(feel free to correct me) ssh has much overhead bandwidth. It is transferring more or less the same amount of data but just in an encrypted form. The main over head of SSH lies in the encrypting and decrypting of the data which is an overhead on the CPU. Still given most of the computers today with high clock rate multicore processors it isnt an issue most of the time.

Actually, SSH does add some overhead to the packet. SSH has its own packets into which it wraps data before handing it off for TCP/IP encapsulation. This packet contains length (4 bytes), padding length (1 byte), data section (depends on MTU), padding(4-255 bytes), and Message Authentication Code (length varies, probably 20 bytes or less).

Max MTU is 1500 bytes, you lose 66 bytes due to encapsulation (header information). This leaves you with 1434 bytes unencrypted. When using ssh encryption, worst case scenario uses around 380 bytes, cutting you down to 1054 bytes of actual data.

Keep in mind this is worst case, but there is always some overhead.