5 ms·

Most internet applications use HTTP because real networking is a pain, designing a custom protocol correctly is difficult, and HTTP provides enough functionalit

Most internet applications use HTTP because real networking is a pain, designing a custom protocol correctly is difficult, and HTTP provides enough functionality and flexibility to munge network traffic any way you want. They use JSON because it's the least pain in the ass of all the data formats. Custom protocol over UDP is the fastest, which NFS supports, so NFS is basically the fastest (unless you get into wonky multiplex-streamed custom apps). However, UDP apps do not often work well through firewalls.

skissane 6y ago
I'm wondering if we are going to see NFS-over-QUIC. Widespread adoption of QUIC may make more firewalls become UDP-friendly.
- ComputerGuru 6y ago
  NFS is a really slow churning wheel. I think you’ll probably first see an inefficient generic option to tunnel tcp over quic (on both ends) that someone will hack to support nfs before you see an NFSv5 with quic support.
- fulafel 6y ago
  NFS is not particularly married to UDP though, unless we're talking about old timey NFSv2. There was even a WebNFS spec back in the day designed to let Java applets mount stuff over the internet.
anderspitman 6y ago
I feel like I'm fairly familiar with the tradeoffs. I'm simply making an observation that it's interesting to me that filesystem access over HTTP isn't bigger than it is.
- dnautics 6y ago
  > filesystem access over HTTP isn't bigger than it is. I don't think it's a trade-off thing. It's conceptual; FS over HTTP is not bigger than it is because filesystems are a much more stateful concept that often has to support coordinative transactions (like locks) whereas HTTP is a stateless protocol by design, so there's fundamentally a mismatch. That's why HTTP is better matched for an object system like S3 which is capable of being transported over stateless links and gives fewer coordination guarantees and is only eventually consistent.
  - anderspitman 6y ago
    You can support locks for HTTP if you need them (WebDAV does), though I would argue they aren't necessary for a large number of useful tasks. You don't have to implement all the semantics of a filesystem in order to benefit. The main benefit comes from making a filesystem-like construct accessible in the browser. As I said before, Google Drive is a good example of this (and it's an object system, so that's an orthogonal issue), but it's a complicated protocol (as is S3) in a walled garden.

skissane 6y ago

I'm wondering if we are going to see NFS-over-QUIC. Widespread adoption of QUIC may make more firewalls become UDP-friendly.

ComputerGuru 6y ago
NFS is a really slow churning wheel. I think you’ll probably first see an inefficient generic option to tunnel tcp over quic (on both ends) that someone will hack to support nfs before you see an NFSv5 with quic support.
fulafel 6y ago
NFS is not particularly married to UDP though, unless we're talking about old timey NFSv2. There was even a WebNFS spec back in the day designed to let Java applets mount stuff over the internet.

anderspitman 6y ago

I feel like I'm fairly familiar with the tradeoffs. I'm simply making an observation that it's interesting to me that filesystem access over HTTP isn't bigger than it is.

dnautics 6y ago
> filesystem access over HTTP isn't bigger than it is. I don't think it's a trade-off thing. It's conceptual; FS over HTTP is not bigger than it is because filesystems are a much more stateful concept that often has to support coordinative transactions (like locks) whereas HTTP is a stateless protocol by design, so there's fundamentally a mismatch. That's why HTTP is better matched for an object system like S3 which is capable of being transported over stateless links and gives fewer coordination guarantees and is only eventually consistent.
- anderspitman 6y ago
  You can support locks for HTTP if you need them (WebDAV does), though I would argue they aren't necessary for a large number of useful tasks. You don't have to implement all the semantics of a filesystem in order to benefit. The main benefit comes from making a filesystem-like construct accessible in the browser. As I said before, Google Drive is a good example of this (and it's an object system, so that's an orthogonal issue), but it's a complicated protocol (as is S3) in a walled garden.