bittorrent vs HTTP

A while ago I put together my document FTP vs HTTP that compares data transfers done using those two protocols. Similarities and differences.

Today I’m taking the next step in this little series and I offer you Bittorrent vs HTTP! This document discusses differences in areas such as:

  • Transfer Speed
  • Streaming
  • Uplink
  • Firewalls
  • Redundancy
  • Server Load
  • Encryption
  • Protocol Standards

As usual, I’m all ears for your valuable input and help on making it more accurate and more detailed than I manage to myself. Point out my mistakes, my weird use of words or whatever. Post a comment here or email me.

bittorrent vs http

6 thoughts on “bittorrent vs HTTP”

  1. Personally I would say something like “…easily blocked by firewall admins, and often corporate/public wifi firewalls do because of the common illegal usage of bittorrent.” Or something like that, but of course it’s your thing and I’m probably just ranting too much.

  2. Yeah, I was trying to avoid getting into politics in there so I think “easily blocked” is enough as then everyone can figure out themselves what that means in corporate or similar environments…

  3. I want to disagree with you on the streaming bit… Doesn’t the client request the chunks it wants to get? I don’t see why you couldnt create a client which downloads the chunks in order so it could be used to stream audio/video across…

  4. Hm, yes… I need to rephrase that section a bit and clarify my reasoning.

    As you say, a client could probably attempt to ask for the chunks in a sequential order. I think the main problem with that is that clients typically do the chunks in a random order to share the load optimally and best deal with the situation where no peer has the missing piece. I mean, a bittorrent download can easily reach a missing chunk that may be missing for a good while simply because none of the peers have it yet.

Comments are closed.