(The below is all speculation, I don't know how Apple's updater works internally.)
There are definitely architectures that can perform a secure update over HTTP. Almost all Linux distributions distribute packages in plaintext, and verify them by verifying the hashes (SHA-1, SHA-256, etc.) from the repository metadata. The repository metadata, in turn, is signed with a GPG key that your host verifies, and was installed with your original installation media. (If your original install media was backdoored, all bets are off forever.)
So what does this have to do with your Apple update? Apple could be using a similar scheme -- send a hash over HTTPS, download over HTTP, then verify the hash. Software updates like this are a case where all you really need is integrity (I know some people would like confidentiality, but let's be honest, if an attacker sees you download X bytes over HTTPS from apple.com, and the latest apple update is X bytes, you've lost confidentiality already), and integrity can be achieved without sending the file itself over HTTPS.
In fact, this technique maybe preferable -- Apple could have a small number of servers serving update metadata under their direct control (i.e., URL and hash of the update) and then use a 3rd party CDN to distribute the update, reducing bandwidth costs, latency, etc. If the update were served by the CDN directly over HTTPS without the verification step (i.e., all integrity is from HTTPS), then the CDN (or someone who compromises the CDN) could replace the update with a modified version.
Whether or not the duplicate ACKs are something to worry about is largely a separate question. My level of concern would depend on a number of things: are they outbound or inbound ACKs? What are the TTLs? What are the sequence numbers? It's really hard to say, but I suspect duplicate ACKs are far more likely caused by a network misconfiguration somewhere (even if not your network) than by an attacker.