Fletcher's algorithm (John G. Fletcher, 1982) maintains two running sums — the first accumulates blocks, the second accumulates the first — then packs both into the output word. It's stronger than a plain block sum against burst errors and byte-reordering, cheaper than CRC-32, and ships in TCP/UDP (as a related 1's-complement variant), OSI CLNS/CLNP, TLS, ZFS, and many embedded protocols. Fletcher-16 uses 8-bit blocks and mod 255, Fletcher-32 uses 16-bit blocks and mod 65535, Fletcher-64 uses 32-bit blocks and mod 232−1.
IP checksum is the 16-bit 1's-complement sum used by IPv4 headers, ICMP, TCP, and UDP (RFC 1071). It's cheaper than Fletcher-16 but weaker — it misses adjacent-word swaps that Fletcher catches. Adler-32 is a Fletcher-like sum used in zlib, with prime moduli that improve short-message detection.
Each byte updates both running sums: sum1 = (sum1 + byte) mod 255, then sum2 = (sum2 + sum1) mod 255. The final checksum packs them: (sum2 << 8) | sum1. Note how sum2 grows quadratically — that's what gives Fletcher its position-sensitive strength.
John G. Fletcher, then at Lawrence Livermore, described the algorithm in An Arithmetic Checksum for Serial Transmissions (IEEE Trans. Comm., January 1982). His goal was a link-level checksum stronger than the widely used single-byte modular sum but cheaper than the polynomial CRCs of the day. The two running sums make the checksum position-aware: reordering the same bytes changes sum2, which a plain sum would miss entirely. The modulus is one less than the block base (255 for 8-bit blocks, 65535 for 16-bit) so that any all-ones block still contributes; using the base itself would create a null block that could be hidden. Fletcher-32 became the default choice for OSI CLNP, DECnet Phase IV, and later ZFS's non-cryptographic on-disk metadata. The related TCP/UDP checksum is the 16-bit 1's-complement sum from RFC 1071 — simpler than Fletcher but requiring the same end-around carry.