I have been reading about HTTP/2 and the idea of server pushing resources to the client preemptively seems nice. But what if the client does not need it because the client has already cached it from the last visit?
There seems to be an RST_STREAM that lets the client immediately terminate a stream. But what happens if the server is too fast and has already sent it? Is RST_STREAM effective to signal the server of already cached files?
Yes that's the point of RST_STREAM.
You are correct that this raises risks of happening too late, for both:
The server - which will have wasted time fetching the resource by the time the RST_STREAM message is received.
The client - as some/most/all of the resource may have been sent by the time the client realised it doesn't need to and sends the reset stream. This wastes time and resources (particularly bandwidth on mobile for example!).
The RST_STREAM should be a measure of last resort, rather than something you depend on to prevent pushing off resources. Otherwise it could easily become a performance problem rather than a solution.
We need to get smart about only pushing when it's likely a resource is needed and there are various ways this could be achieved, but as yet no accepted standard. I've blogged about one method using cookies for example, and various other cache digests based on cookies and other options have been suggested. The HTTP/2 spec as (probably deliberately) silent on how best to implement this.
Personally I think Server Push is one of the most interesting parts of HTTP/2 that will take us a while how to use appropriately, and could lead to all sorts of interesting applications. Just like some performance boasting techniques (e.g. concatenation, spriting... etc.) under HTTP/1.1 took a while and some experimentation to help push what the protocol could do - though it's interesting that they have all now become anti-patterns under HTTP/2. Maybe some of the techniques for server push will become the same way in the future when HTTP/3 comes along!
