1) if header is corrupted under some cases (header crc says body len could be wrong) then as I understand we must skip all body data and read the next message. How to skip? async_read_until seemed to be the solution, but manual told that it may read surplus data into streambuf - it will be hard to deal with that data because I am reading directly from socket to some allocated memory (as was told above)
How do you know the number of bytes you have to skip? If you determine that your header is corrupted, the length info can't be trusted any more. You'd have to employ some framing method for your packets so you can reliably detect the next packet start. In this case you shouldn't skip a given number of bytes but rather until a new frame start can be detected.
2) actually, can it be that in tcp stream data will be corrupted? I guess, yes - so header contains bodylen and crc for body and for header? is such solution an overhead?
It's theoretically possible, but very unlikely. Note that TCP/IP employs checksums itself and should retransmit any packet which is detected as faulty. IIRC it's only a 16 bit checksum, so if you throw completely mangled data every 65536th packet would make it through the check sum (statistically of course). Note that you'd have to have a very unreliable media for that to be of concern, something which would make normal communication next to impossible.
3) maybe I do some global design mistakes?
Before you delve into check sum protection for you data too much, you should check what TCP/IP already has to offer. Do you have an analysis of your expected error pattern (bit errors, dropped bytes, erased bits, bundle errors) ? What's the acceptable error rate of the data you transfer ? What's the error rate of your TCP/IP channel ?