Talk about a late reply, but since I stumbled upon this post (among a few others) while trying to fix a similar problem, thought I'd post an improvement that worked for me.
Generally, for unusually slow internet connectivity,
nettop(1) is better than lsof for figuring out which process is choking the internet bandwidth. It is pre-installed and (crucially) shows realtime data transfer rate for each connection (which lsof lacks).
In the Terminal:
$ nettop
Then hit 'd' and look for entries with consistently large values in the 'bytes in' or 'bytes out' column. The 'd' instructs nettop to only show differences in each screen refresh.
Practical usage notes:
If you don't recognize the process name, Google it.
If you don't want the process around, get the pid (the number next to the process name in nettop), and kill it with "kill -9 <pid>". If that doesn't solve it, find out if you can politely tell the process to stop (for e.g. I logged out of AppStore, iBooks, iTunes and killed storeagent again).
If you're interested in what the process is doing over the network, use the client port number for a particular connection (e.g. '53133' from 10.0.0.1:53133->74.125.68.100:80) to run a
tcpdump(1) on to see what packets are being exchanged: sudo tcpdump -nnvvXSs 1514 port 53133
If you're interested in who the process is talking to, but the destination IP address doesn't have a reverse DNS hostname (like in the previous example), then try visiting that IP address in a web browser as
https://IP, click the broken lock icon in the address bar, and view the certificate details to find out which domain is served there (*.google.com in this case). This won't work if SSL port 443 isn't open on the destination.