Well, you have it right in how nonces are used to make sure that the keys in different SSL sessions; this effectively prevents someone from taking an SSL record from one session, and injecting it into another -- because the keys aren't the same, it won't pass the integrity tests.
However, that's not the only place we care about replay attacks; we can also be concerned about someone taking an SSL record from one session, and replaying it latter in that same session. Because the keys are the same, we can't use the above logic.
So, what SSL transmitter does when it computes the MAC for a record is logically prepend the current byte count; that is, the number of bytes that have passed through this SSL connection so far. This byte count is not sent over the wire, but it is implied. When the receiver gets the record, it also logically prepends its current byte count (which should match the transmitter's); and so it should compute the same MAC. After processing the record, both the transmitter and the receiver updates its current byte count (based on how long the record was).
Now, if someone should replay that record, the receiver would then logically prepend its current byte count (which would not match what the transmitter prepended when it originally generated the record); because that count is different, the receiver would generate a different MAC, and so the record would be rejected.
That gives you the answer, I want to close with one clarification; you mentioned SSL; well, the current version of the protocol is known as TLS. There are several versions (TLS 1.0, 1.1 and 1.2); TLS 1.2 handles the byte count slightly differently; however it does the same job. There's also something known as DTLS; for that protocol, the count (which is a count of records, and not bytes) is explicitly sent within the record.