There has to be more processing done than the simple 'it adds up' explanation because of a number of problems.
1. The TCP checksum is a 16-bit checksum so you can't simply permute the characters in Connection and always expect to get the same answer.
2. The position at which Connection starts may not be on a 16 bit boundary and thus the permutation would have to take into account this positioning.
3. The header could be split across packets making this much harder.
In the example given nnCoection makes sense because the 16-bit words nn and Co have been swapped which will not alter the checksum as long as Connection was starting on a 16-bit boundary.
2) TCP is a byte oriented protocol, so there is no endian or word boundary problems.
3) Nothing is going to split a IP package between the backend servers and and the frontend balancer, where the later sees the "Connection". If something between the balancer and the client splits, it is its problem to recompute the new CRC
TCP doesn't use a CRC, it uses the algorithm described in RFC 1071 (http://www.ietf.org/rfc/rfc1071.txt) which relies on ones-complement summing of 16-bit word values. Thus the position at which Connection appears does matter, as does the swapping of characters.
1. The TCP checksum is a 16-bit checksum so you can't simply permute the characters in Connection and always expect to get the same answer.
2. The position at which Connection starts may not be on a 16 bit boundary and thus the permutation would have to take into account this positioning.
3. The header could be split across packets making this much harder.
In the example given nnCoection makes sense because the 16-bit words nn and Co have been swapped which will not alter the checksum as long as Connection was starting on a 16-bit boundary.