So TCP is using a 16-bit checksum which only detects honest transmission error caused by noise in the transmission. However, one can easily swap two 16-bit words in a message, which has a 100% probability of being undetected. For stronger integrity checks, such as whether a man in the middle attacker actively changed the message, it is recommended to perform those checks at the application level.
But to the application, the TCP connection looks just like a stream of bytes, and at some point, the application may (or may not) detect that modified values were received (the modified message might still seem valid). How would a programmer handle this optimally?
I have the suspicion that this is not even possible without implementing your own packets on top of TCP, and then request the other party to re-send those higher-level packets. But if we go that far, why not directly use UDP and implement those higher-level packets with resend-requests in UDP? The only thing you'd still have to do in UDP would be the manual ordering of packets, but that seems comparatively easy. Also, UDP is faster than TCP, and you could directly use authenticated encryption on the protocol level, so instead of a 16-bit checksum, you'd have strong cryptographic guarantees about the integrity of the channel.
TL;DR: TCP makes it fucking hard to handle undetected transmission errors
Questioning validity of TCP