The previous entry was on typical output of System.Net and System.Net.Sockets trace sources.
Lets try to retrieve some image twice and see how caching is going to help us. We need first to enable caching as it is disabled by default:
More info on caching configuration here: http://msdn.microsoft.com/en-us/library/6szcd7yh.aspx
Upon first HttpWebRequest, cache key is checked and not found:
Whole image is read then using System.Net.Sockets.
After System.Net.Sockets completes reading a response from our first request, System.Net.Cache evaluates if it is "worth it" to cache:
If it is, like in our case, it copies the contents of response to the cache. As already mentioned in few blogs, System.Net.Cache uses IE cache, which is why we can see reference to the local profile directory in the above log. As of this writing it means that having a profile for the app user is required, read more here: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=263447&wa=wsignin1.0 and original here.
Upon second request for the same image, no network communication is taking place because cache is first consulted for the key presence:
And then for the cache item not being stale:
After those checks image is read from the cache, no work for the System.Net.Sockets required!