SURLConnection got its start a decade ago, with the original release of Safari in 2003, as an abstraction on top of the Core Foundation / CFNetwork APIs. The name NSURLConnection actually refers to a group of the interrelated components that form the Foundation URL Loading System: NSURLRequest, NSURLResponse, NSURLProtocol, NSURLCache, NSHTTPCookieStorage, NSURLCredentialStorage, and its namesake, NSURLConnection.
NSURLRequest objects are passed to an NSURLConnection object. The delegate (conforming to the erstwhile informal and protocols) responds asynchronously as an NSURLResponse, and any associated NSData are sent from the server.
Before a request is sent to the server, the shared cache is consulted, and depending on the policy and availability, a cached response may be returned immediately and transparently. If no cached response is available, the request is made with the option to cache its response for any subsequent requests.
In the process of negotiating a request to a server, that server may issue an authentication challenge, which is either handled automatically by the shared cookie or credential storage, or by the connection delegate. Outgoing requests could also be intercepted by a registered NSURLProtocol object to seamlessly change loading behavior as necessary.
For better or worse, NSURLConnection has served as the networking infrastructure for hundreds of thousands of Cocoa and Cocoa Touch applications and has held up rather well, considering. But over the years, emerging use cases–on the iPhone and iPad, especially–have challenged several core assumptions, and created cause for refactoring.