It's important to distinguish between reliability in the protocol and reliability in the implementation. Spending time and money to be reliable in the face of d

It's important to distinguish between reliability in the protocol and reliability in the implementation. Spending time and money to be reliable in the face of disasters like falling planes is about the implementation. An example of reliability at the protocol level is TCP vs. raw IP. IP routers will try to get your packets to their destinations, but they'll also happily discard them if that's more convenient. TCP adds some reliability - the other side will let you know if they didn't get everything. The issue you bring up with HTTP is actually related to HTTP being synchronous rather than unreliable. If you wrote your program to fetch data by sending an email, it would probably work even if the SMTP server that had the data was down: your local SMTP server would store your message and forward it when the destination server came back up.