4 ms·

I grew up in rural Iowa with a poor Internet connection (satellite) that dropped packets if there were thick clouds, any snow or rain, even wind sometimes. Inte

by mholt 10y ago

I grew up in rural Iowa with a poor Internet connection (satellite) that dropped packets if there were thick clouds, any snow or rain, even wind sometimes. Integrity checks would have helped a lot.

mikeash 10y ago
TCP already covers that sort of thing. What HTTPS adds is integrity checks against an intelligent attacker, not just random natural interference.
- jasonuhl 10y ago
  TCP only gives you 16 bits of checksum, which is really not enough. I used to work for a CDN which served downloads over HTTP, and when the object size grew to a few gigabytes a non-negligible percentage of users ended up with corruption. The SSL MAC is valuable even in the absence of enemy action.
  - mikeash 10y ago
    Makes sense. Thanks for the informed correction.
  - DanielDent 10y ago
    This is a really interesting 'real world' anecdote. Do you know of any related data available publicly? i.e. "on our network, X bits in Y terabytes end up with undetected corruption, meaning that approximately Z% of downloads of a 2GB file will have at least one bit error".
    - Dolores12 10y ago
      From http://noahdavids.org/self_published/CRC_and_checksum.html http://noahdavids.org/self_published/CRC_and_checksum.html In "Performance of Checksums and CRCs over Real Data" Stone and Partridge estimated that between 1 in 16 million and 1 in 10 billion TCP segments will have corrupt data and a correct TCP checksum. This estimate is based on their analysis of TCP segments with invalid checksums taken from several very different types of networks. The wide range of the estimate reflects the wide range of traffic patterns and hardware in those networks. One in 10 billion sounds like a lot until you realize that 10 billion maximum length Ethernet frames (1526 bytes including Ethernet Preamble) can be sent in a little over 33.91 hours on a gigabit network (10 * 10^9 * 1526 * 8 / 10^9 / 60 / 60 = 33.91 hours), or about 26 days over a T3.
jonathanoliver 10y ago
The worst is when you hit bandwidth caps and they cut you off. Gotta love background downloads...
- mholt 10y ago
  Remember those "download accelerator" programs? Even when we had dial-up (no weather interference over the air), we had corrupted downloads quite often.

by mholt 10y ago

I grew up in rural Iowa with a poor Internet connection (satellite) that dropped packets if there were thick clouds, any snow or rain, even wind sometimes. Integrity checks would have helped a lot.

mikeash 10y ago

TCP already covers that sort of thing. What HTTPS adds is integrity checks against an intelligent attacker, not just random natural interference.

jasonuhl 10y ago
TCP only gives you 16 bits of checksum, which is really not enough. I used to work for a CDN which served downloads over HTTP, and when the object size grew to a few gigabytes a non-negligible percentage of users ended up with corruption. The SSL MAC is valuable even in the absence of enemy action.
- mikeash 10y ago
  Makes sense. Thanks for the informed correction.
- DanielDent 10y ago
  This is a really interesting 'real world' anecdote. Do you know of any related data available publicly? i.e. "on our network, X bits in Y terabytes end up with undetected corruption, meaning that approximately Z% of downloads of a 2GB file will have at least one bit error".
  - Dolores12 10y ago
    From http://noahdavids.org/self_published/CRC_and_checksum.html http://noahdavids.org/self_published/CRC_and_checksum.html In "Performance of Checksums and CRCs over Real Data" Stone and Partridge estimated that between 1 in 16 million and 1 in 10 billion TCP segments will have corrupt data and a correct TCP checksum. This estimate is based on their analysis of TCP segments with invalid checksums taken from several very different types of networks. The wide range of the estimate reflects the wide range of traffic patterns and hardware in those networks. One in 10 billion sounds like a lot until you realize that 10 billion maximum length Ethernet frames (1526 bytes including Ethernet Preamble) can be sent in a little over 33.91 hours on a gigabit network (10 * 10^9 * 1526 * 8 / 10^9 / 60 / 60 = 33.91 hours), or about 26 days over a T3.

jonathanoliver 10y ago

The worst is when you hit bandwidth caps and they cut you off. Gotta love background downloads...

mholt 10y ago
Remember those "download accelerator" programs? Even when we had dial-up (no weather interference over the air), we had corrupted downloads quite often.