In a replay attack communication/message over secure network is (sent again)/replayed to the receiver of the message by an attacker .The attack may be 

• Man in the middle attack where the attacker has access to communication. It should be noted that the attacker need not decrypt the message.The attack could be successful by simply resending the whole encrypted message.
• Man in the brower.

Stopping replay attack

• Timestamp is a part of encrypted message : If the attacker resends the whole encrypted messsage and if the time elapsed is more than a certain value the receiver of the message should reject the communication/message. If the timestamp is generated by client then client and server need to have synchronized clocks.
• randomly generated token/nonce stored in user's session , let us see the steps of how a replay attack can happen and how it will fail.
  • A user "A" makes a GET request
  • The server
    • generates a random token "T1"
    • stores a copy of the token in the session of user "A"( ie server remembers token "T1" was given to user "A")
    • attach a copy of the token in the
      being sent in response and sends to the response to client.
  • The user "A" fills the form and sends a POST request to the server.
  • The server receives the post request from user and extracts the  attached token and then processess the request only if the atached token matches the token stored in user's session.
  • Also once post request is handled the server invalidates the token (this will also help in idempotency/ same user accidently resubmits form)
  •  Attacker "B" makes a GET request.
  • The server
    • generates a random token "T2"
    • stores a copy of the token in the session of attacker "B"( ie server remembers token "T2" was given to user "B")
    • attach a copy of the token in the
      being sent in response and sends to the response to client.
  • The user B tries to execute a replay attack (the post request sent by user A will be replayed by attacker B)
  • The server will extract attached token T1 from the replayed request and compare it to the token stored in session of which is T2.
  • T1 and T2 do not match and the replay request will fail.  
• randomly generated token/nonce stored in replay cache.
  • here the token is not stored in user's session but in a replay cache. if a token attached to request exists in replay cache then the request will not be exeucted. This will block both accidental replay twice by one user and replay attack by an attacker.  The advantages of this approach is that the server need not remember which token was issued to which client ie need not remember per client state. This can really help horizontal scalability. typically for horizontal scalability centralized session stores are used. The main downside is that to stop replay cache from growing without limits timestamps are required. old timestamp tokens should be evicted from replay cache .