
BitTorrent vs. HTTP - mrzool
https://daniel.haxx.se/docs/bittorrent-vs-http.html
======
sametmax
I wish browsers and OS would implement torrent by default. Not only would it
make the sharing file experience (downoading, sending, etc) much better, but
it would open the door to many cool P2P stuff on the client side.

It's a standard, we know it works and how.

~~~
zython
Yeah, thats cool but I dont want to pay to be a part of Microsoft's/Apple's/
you-name-it's insfrastructure.

I dont want to be (potentiall forced to) distribute software.

With recent developments in net neutrality and data plans, p2p could
drastically impact my data plan and cost me money.

Sure I can see why you would think the potential is, but for me p2p data
distribution is out of the question, at least for now.

~~~
johnnyhead
Man, windows 10 already does that. In the advanced update options there is a
distributing method menu and it is pretty clear they are using our machines to
distribute updates to others.

Disclaimer: Haven't checked in a while and can not do it now, but it was there
until not long ago.

~~~
ChrisClark
Yes it's still there. I just turned it off last week. But still let it share
the updates with the other computers in my household LAN.

~~~
atmosx
Is this on by default?

~~~
smhenderson
IIRC yes, unless your internet connection is marked as Metered, in which case
the default is off.

What I can't remember and am unable to check at the moment is whether Metered
is turned on by default or not.

But regardless of defaults, if you mark a connection as Metered than the
background update distribution is turned off.

~~~
tracker1
Metered is part of your connection settings, iirc, like when you establish a
connection to a new wifi network. Other applications may be effected by
metered networks, and iirc updates don't run at all when on a metered network.

------
discreditable
BitTorrent can cheat a little with web seeds. It treats an HTTP host as a
"seed" in the swarm.
[https://en.wikipedia.org/wiki/BitTorrent#Web_seeding](https://en.wikipedia.org/wiki/BitTorrent#Web_seeding)

~~~
derefr
Speaking of web seeds, the magnet: URI scheme—with an embedded web seed—has
everything it needs to be an all-in-one subresource integrity + CDN-neutral
subresource caching mechanism. If browsers could resolve magnet: links
natively, you could just link all your page's resources as magnet: resources
with the copies on your own servers acting as the web seeds.

------
kiliankoe
> While clients (probably) could ask for chunks in a chronological order and
> then get the data in a sequential manner [...]

Why probably? This is exactly how the immensely popular Popcorn Time worked.

~~~
fnord123
It's literally in the same sentence. In the part that you elided:

"it will not at all distribute the load as evenly among the peers as the
"random access" method does."

If people only stay to download the file and then disconnect then there will
be a higher concentration of parts from the beginning of the file than to the
end. This reduces the resiliency of the swarm.

~~~
kiliankoe
I only wanted to bring up that the beginning of the sentence made it sound
like a theoretical concept that might work, but no one has ever tried or seen
in practice. The concerns are definitely valid.

~~~
Retric
Depends on the algorithm but you need not go 100% one way or the other. The
basic rule can be 70% download next part and 30% download rare bits. The swarm
is slightly less resilient, but seeders are still generally uploading the rare
bits not the start of the file. This also tends to make a faster swarm as new
downloads have something to trade.

~~~
WhiteOwlLion
You could have an algorithm change how pieces are requested based on
availability (seed to peer ratio). If a torrent has high availability, then
there is little harm in retrieving pieces sequentially.

------
motoboi
He forgot to mention a very important aspect of bittorrent: the uTP (micro-TP)
protocol.

uTP is a very nice bittorrent over UDP protocol implementing LEDBAT congestion
control algorithm [1].

1 -
[https://en.m.wikipedia.org/wiki/LEDBAT](https://en.m.wikipedia.org/wiki/LEDBAT)

~~~
JepZ
Everything there looks very pro HTTP like... But hey, curl doesn't support
bittorrent afaik. So why should haxx.se care ;-)

------
na85
One thing I always fail to see in these types of comparison articles is that
BitTorrent will happily destroy any ability for those sharing your connection
to use it if you let it.

Probably due to the sorry state of affairs that is the consumer router space,
running BitTorrent renders even web browsing painfully slow and sometimes
completely nonfunctional.

Why BitTorrent does this while normal http transfers do not is not clear to
me. Perhaps due to the huge number of connections made.

Either way, when given a choice I'll always take a direct HTTP transfer over a
torrent, for no other reason than the fact that I'd like to be able to watch
cat videos while the download completes.

~~~
pktgen
This is caused by bufferbloat, which you can read more about at
[https://www.bufferbloat.net/projects/bloat/wiki/Introduction...](https://www.bufferbloat.net/projects/bloat/wiki/Introduction/).
The good thing is it's easy to fix.

On your upstream side (i.e. data you send out to the Internet), you can
control this by using a router that supports an AQM like fq_codel or cake.
Rate limit your WAN interface outbound to whatever upstream speed your ISP
provides. This will move the bottleneck buffer to your router (rather than
your DSL modem, cable modem, etc., where it's usually uncontrolled and
excessive) and the AQM will control it.

Controlling bufferbloat on the downstream side (i.e. data you receive from the
Internet) is more difficult, but still possible. You can't directly control
this buffering because it occurs on your ISP's DSLAM, CMTS, etc., but you can
indirectly control it by rate limiting your WAN inbound to slightly below your
downstream rate and using an AQM. This will cause some inbound packets to be
dropped, which will then cause the sender (if TCP or another protocol with
congestion control) to back off. The result will be a minor throughput
decrease but a latency improvement, since the ISP-side buffer no longer gets
saturated.

~~~
the8472
While bufferbloat is an issue it's not the only one. Poorly designed NAT
implementations easily suffer from connection tracking table saturation due to
the many socket endpoint pairs they have to track when you're using
bittorrent. Doubly so when using bitrorent with DHT.

~~~
pktgen
That's a good point.

The best thing to do is avoid home networking equipment entirely. The Ubiquiti
EdgeRouter products are cheap and good, as is building your own router and
sticking Linux/*BSD/derivative distros on it.

------
niftich
Bittorrent has innate support for content addressing, while HTTP is location-
addressed: there is simply _no_ way to decouple a content's location from its
identity with HTTP. You can try to fake it, of course, with more indirection,
but each hop requires communications with a specific location reachable with
HTTP.

In fortunate circumstances, Bittorrent, it can run fully P2P without needing
'servers' \-- depending on whether you have to holepunch a NAT, whether you're
okay with peer discovery taking longer in the DHT without a tracker, and
whether you're okay with no fallback webseed as a seed-of-last-resort. Magnet
links, a distinct concept not only applicable to Bittorrent, are the cherry on
top, which enable even the ".torrent" file (or rather, the equivalent
information) to be found without having to possess the .torrent file itself,
from just a hash.

BT's architecture has a nice effect that popular content consumes fewer of the
original host's bandwidth than it would with HTTP, but this works best if peer
interest roughly coincides in time. This is why it's a good fit for
distributing patches [1][2], or newly released episodic content, and a fairly
poor fit for anything else.

The Bittorrent extensions (BEPs) vary widly in quality, clarity, verbosity,
and rigor, and aren't always up to the level of HTTP extensions acknowledged
by the IETF. Most BEPs were implemented in only one product and then submitted
as a BEP retroactively, while throughout its lifetime most of HTTP's
enhancements were discussed and developed in a semi-open, but publicly
viewable process in the IETF with more emphasis on consensus and early
prototyping, rather than final implementation and retroactive standardization.
These days this process has partially been subsumed by prominent vendors
implementing a behavior, running it for an extended amount of time as a
proprietary enhancement, then submitting a slightly altered version to the
IETF for discussion, so admittedly the two enhancement processes are a lot
more similar now than they've been in the past.

[1] [http://arstechnica.com/business/2012/04/exclusive-a-
behind-t...](http://arstechnica.com/business/2012/04/exclusive-a-behind-the-
scenes-look-at-facebook-release-engineering/) [2]
[http://wow.gamepedia.com/Blizzard_Downloader](http://wow.gamepedia.com/Blizzard_Downloader)

------
Forbo
I really hope that things like ZeroNet start to get more attention/integration
into browsers. I see amazing potential for the democratization of the web
using technologies like this.

[https://zeronet.io/](https://zeronet.io/)

------
d33
> HTTP is an established and formalized protocol standard by the IETF.

> Bittorrent is a protocol designed by the company named Bittorrent and there
> is a large amount of variations and extensions in implementations and
> clients.

Extensions are in many cases standarized. There's a lot of variations in HTTP
as well.

One important thing that's missed is that a magnet link also contains a hash
of the torrent file, which points to a specific file. Over HTTP, everyone
across the network connection can change the contents of the file and there's
no automated way of detecting that.

~~~
robryk
HTTP is standardized, but lots of stuff doesn't follow the standard in the
areas that didn't use to matter. Then we get problems like this:

[https://bugs.chromium.org/p/chromium/issues/detail?id=616212](https://bugs.chromium.org/p/chromium/issues/detail?id=616212)

that have to be worked around by assuming that other devices might not adhere
to the specification.

------
RedHatTurtle
Isnt IPFS the best adaptation of "bittorrent ideas" to the http general use
case?

On an unrelated issue, it baffles me how people with uncapped internet refuse
to help serve content to other people, like enabling the distribution of
windows updates. I would love to have that on linux and would never dare to
turn it of unless is was reaching my data cap. It's just liek seeding you
torrents, hell i have seed ratios of over 100 for some linux distro images.

------
LinuxBender
My personal preference would be MPTCP, then BitTorrent, Googles idea for UDP
HTTP, then plain TCP HTTP.

Many things can benefit from MPTCP however, including BitTorrent.

------
sleepychu
Not sure if Daniel reads this but:

> _only gets a few_

/s/gets/has/

------
sigi45
So much wrong/missing and missleading information. It would be better to
delete it.

------
inconclusive
Why we still use HTTP is beyond me. And I don't mean about the speed issues.
Why have a protocol that's so complicated when most of the things we need to
build with it are either simpler or reimplement parts of the protocol.

~~~
mreithub
Could you elaborate your issues with HTTP a bit? What kind of protocol would
do a better job?

Minimal implementations of HTTP (and I'm strictly talking about the transport
protocol, not about HTML, JS, ...) is dead simple and relatively easy to
implement.

Of course there's a ton of extensions (gzip compression, keepalive, chunks,
websockets, ...), but if you simply need to 'add HTTP' to one of your projects
(and for some reason none of the existing libraries can be used) it shouldn't
take too many lines of code until you can serve a simple 'hello world' site.

On top of all that, it's dead simple to put any one of the many existing
reverse proxies/load balancers in front of your custom HTTP server to add load
balancing, authentication, rate limiting (and all of those can be done in a
standard way)

Furthermore, HTTP has the huge advantage of being readily available on pretty
much every piece of hardware that has even the slightest idea of networking.
Any new technology would have to fight a steep uphill battle to convince
existing users to switch.

Have I mentioned that it's standardized and open?

~~~
ue_
My friend once mentioned that FTP would be a good option, I'm not sure why
though. I think they regarded HTTP as superfluous for the purpose of what we
use the web for.

~~~
protomyth
Anyone who has to deal with ftp on firewalls would say ftp (and ftps) would do
well to disappear from the world.

~~~
mreithub
It's not just firewalls. The fact that (unencrypted) FTP is still widely used
today when better alternatives like SFTP (via SSH) have existed for years
strikes me as odd.

(I'm speaking about authenticated connections. For anonymous access - which
should be read-only anyway - you're usually better off using HTTP anyway)

~~~
ashark
I once had to provide an FTP-like interface to user directories for the
website's users. Couldn't find an easy way to do it with SFTP without creating
Linux users. Found an FTPS daemon that would let me call an external script
for auth and set a root directory, which made it trivial (once I deciphered
its slightly-cryptic docs).

So in that case, at least, I was very glad FTP(S) was still around.

