I was thinking about it and got an idea, that I will read data until byte with 0 value is detected After this there will be a try to read the header. If the read header is corrupted (probably we are on the middle of the message body) then try again and again.. until normal header is read.
This sounds like a protocol with message framing like HDLC.
I guess, connections will be very different - standard wire connections, gprs, 3g, wifi..
But note that apart from TCP/IP capabilities some of these transfer media have their own error detection or correction schemes in their underlying layers.
And the aim is to provide max reliability with minimal cost - I try to count every byte and so also thinking about need to implement own additional checks for packet corruption.
Do you have any practical tests which show excessive error rates for one of these channels (apart from dropped packets) ? If these are indeed you channels, I would expect very low error rates. Chances are a decent check sum over your whole packet would do the job. If a packet turns out corrupt, you may as well drop the connection and start from scratch. If it's imperative that you maintain the connection, packet framing might be inevitable. If you expect rare bit errors, a simple FEC scheme might be the solution, since it avoids a lot of protocol overhead for data retransmits.
Also I'm thinking about using UDP - as I understand, I will have lower reliability, but I will not need to skip any data - each message is delivered separately.
UDP introduces a number of additional hurdles which TCP/IP handles for you: correct ordering of packets, handling of dropped packets, simpe bit error detection. Be sure you know these implications before you drop TCP/IP