Hi, everyone I'm having a question about possible duplicate message delivery in TCP. Here's the scene:
Time 1: 3-way handshake has been successfully finished. Client sends a packet with data to server.
Time 2: Server receives the packet, sends the data to application level.
Time 3: Before server sends out ACK, it crashes and reboots.
Time 4: Client times out and resends the packet with data.
Time 5: Server starts up, receives the resent packet and responds with RST.
Time 6: Client tears down connection.
Attention: the data has been accepted by the server (such as picking out 1000 USD from your account) and delivered to the application level but client doesn't know it. If the client tries again (say, picking out another 1000 USD from your account), what a mess?
TCP does not work very well with out of order segments. Only a little re-ordering can cause a 20% retransmission rate as well as a large reduction of the congestion window. In practice, routes are fairly stable during the life time of TCP connections or burst of activity on long lived TCP connections. Brand name routers that support load sharing (using multiple next-hops to a single destination) go to lengths to cause any single stream to use a single route.Barry Margolin (barmar@genuity.net) writes on 25 September 2001
Although TCP is able to handle packets that arrive out of order, its performance is much better if this doesn't happen. Sending packets along different paths is likely to result in out of order delivery, so modern routers take steps to avoid this. The oldest mechanism they used for this is destination-based route caching: the first time a router needs to send to a particular destination address it selects one of the possible paths and then remembers this for all future packets to that address. Modern, high-performance routers do flow-based route caching; they peek into the TCP layer's header47 to get the port numbers, and cache a specific path based on the IP addresses and ports.