There can be several things going on - the most common would be the use of TCP Fast Retransmission which is a mechanism by which a receiver can indicate that it has seen a gap in the received sequence numbers that implies the loss of one or more packets in transit. The repeated acknowledgements at the last known value before the gap signal which packets the sender should retransmit. This can occur without waiting for the acknowledgement timeout for the lost packet to hit on the transmitter - which, as the name implies, means recovering a lot faster.
It's also possible that the same symptom of gaps in sequence numbers might be seen in a situation where packets are being delivered out of order. As above, if the receiver sees (for example) a segment with sequence #5 followed by another with #7 before seeing sequence #6 then it might try to begin to trigger a fast retransmit. Upon seeing #6 arrive, though, it would stop sending the duplicate acknowledgements.
A less common cause would be certain media problems where certain packets might end up being seen more than once. If this is the case, however, you're likely to see other problems on the link (...including other packets showing as dupes in Wireshark).
So - if you're seeing a few random duplicate ACK's but no (or few) actual retransmissions then it's likely packets arriving out of order. If you're seeing a lot more duplicate ACK's followed by actual retransmission then some amount of packet loss is taking place. Both situations are, unfortunately, entirely possible on the global Internet. If you're seeing other kinds of duplicate packets as CRC issues and generally slow performance then it might make sense to look at link issues on your own network.
In order to optimize the use of high latency links, receivers avoid acknowledging every single packet. Otherwise in a e.g. 300ms you would only be able to send 3 packets per second. Being 1500 bytes the usual maximum MTU for an Ethernet link you can see how this is not scalable (4.5KB/sec? bring back the 56Kbps modem days!)
So how is this issue solved?
Receivers advertise a receive window when negotiating the three way handshake. This receive window is also known as the TCP window. This window is a value in the TCP header that goes from 0 to 64KB. If the receiver advertises a receive window (let me call it RWIN for short from now on) of 64KB on a 300ms link, the sender can send 64KB worth of packets until having to sit waiting for an acknowledgement. This means you might see ~20 sent packets and only one ACK at the end (this is not accurate: You should see at least one ACK every other packet, but you'll see them delayed). Given an unlimited link bandwidth, this combination of link latency and RWIN will let you transfer files up to 192KB/sec. Much better than before, 42 times faster! still not enough for today's links though. There's a byte in the TCP header that specifies a multiplier for the receive window up to 256, which gives you about 50MB receive window.
The above actually explains one of the reasons you don't see one ACK per each received packet, but as you can see there's way more into the RWIN topic and, just so you know, the sender is not always willing to send as much data as possible without waiting for an acknowledgement (e.g the sender application might not have that much to send); so analysing a specific behaviour on this topic might prove tricky.
You have also mentioned you see a bunch of ACKs together and as another response said, delayed ACKs might be the reason in some scenarios, although another reason why you'll see a bunch of ACKs seemingly sent together is if the receiver is quick at ingesting the data it has in the receive buffers. The receiver will acknowledge segments before fully filing the receive window, prompting the sender to keep sending data (as the receive window does not fill up). This way once again you can improve the maximum bandwidth you can use.
If, on the other hand, the receiver is slow at ingesting the data received, the receive window will fill up and the receiver will have to instruct the sender to stop sending data. You would see this reflected on the advertised receive window shrinking during the capture, until it hits zero.
One more reason you might see several ACKs seemingly together is Selective Acknowledgement:
If the receiver advertised a receive window of 15K, the sender would send 10 packets of 1.5K without waiting for an ACK. Let's imagine the receiver got packets from 1 to 4 and from 6 to 10 - the receiver will start acknowledging those segments received up until #4, at which point it will start explicitly marking the first and last seq number for packets received while acknowledging #4 for every packet received after #5. The sender will realize the receiver has packets 1 to 4 and 6 to 10, but not packet 5, so it will retransmit this (and only this) packet.
Some network analysers might tag this bunch of ACKs as duplicated ACK by looking just at their "ACK" field (always the one from the last received packet) and not the SLE/SRE for first/last seq number acknowledged.
Best Answer
When a link becomes saturated and the queueing depth increases significantly a sudden delay is introduced to the stream. This often causes unnecessary retransmissions because the ACKs for the queued data segments were't received in the expected time window (or the ACKs were delayed in the opposite direction).
With a constant load level the retransmissions should even out as TCP's RTT tracking adapts but with the loads changing permanently, retransmission counts will likely stay on that level.
QoS can help reduce the queueing delay but there's only so much you can do from one side of a link.