It doesn't seem like VMware is the culprit here, mainly because it has nothing to do with anything above layer 3. Here's some points to look into and possible fixes.
[1] VMware's network driver does not handle TCP, or IP. It's just layer 2; it
implements one of a couple kinds of network hardware, that's it.
[2] VMware Guest Tools does install a para-virtualized network card driver
- vmxnet2/vmxnet3. It communicates with the physical network device by
communicating with the host OS, rather than emulating a network driver. That
potentially may do something wonky with something above layer 3, even though
it really should not be.
[3] VMware does have a virtual network switch, which forwards frames between
the physical NIC and virtual NIC based on MAC address.
[4] VMware may handle moving frames from a virtual NIC to a physical differently
than moving it to another virtual NIC.
[5] VMware provides VMDirectPath I/O, which allows the guest to directly address
the network hardware.
[6] TSO/LSO/LRO can have a negative impact on performance in Linux (though
supposedly, LRO only works on vmnet3 drivers, and from VM-to-VM,
for Linux).
[7] Emulated network devices may not be able to process traffic fast enough,
resulting in rx errors on the virtual switch.
[8] Promiscuous mode will make the guest OS receive network traffic from
everything going across the virtual switch or on the same network segment
(when using VLANs).
[1] You can try changing the VMware guest's emulated network card (vlance, e1000) and trying your thing again, but I doubt it will change much.
[2] Try installing or uninstalling VMware Guest Tools and corresponding drivers.
[3] Nothing to do here, really. If you have multiple guests sharing one physical NIC, try changing it to just one?
[4] Try your test again between two VMs on the same host.
[1] Your guest OS may have bugs. In its emulated network drivers, in its
tcp/ip stack, in its applications, etc.
[2] An intermediary piece of software may be fucking with your network
connection. IPtables firewall, router/firewall on your host OS, after
the host OS/before your internet connection, at your destination host, etc.
[3] Sometimes, intermittent network traffic makes it look like there is a
specific cause, when really the problem is hiding in the time it takes
you to test.
[4] The Linux tcp/ip stack (and network drivers) collect statistics about
erroneous network traffic.
[5] Network traffic will show missing packets, duplicate packets, unexpected
terminations, etc.
[6] Your host OS or network hardware may be buggin'.
[1] Try a different guest OS.
[2] Make sure you have no firewall rules on the guest, host, internet gateway, etc. Try a different destination host.
[3] Run tests in bulk, collect lots of samples and look for patterns.
[4] Check for dropped packets, errors on the network interface, in tcp/ip stats.
[5] Tcpdump the connection to see what happens when it succeeds or fails.
[6] Try a different host for your VM.
edit one more idea: Look at the response headers for the request to the site. The content length is 1413 bytes. Add on the TCPv6 and IPv6 header overhead (and http headers, etc) and this is probably over 1500 bytes, the typical MTU maximum. Try requesting a "hello world" text file and try your test again.
[2] Try installing or uninstalling VMware Guest Tools and corresponding drivers.
[3] Nothing to do here, really. If you have multiple guests sharing one physical NIC, try changing it to just one?
[4] Try your test again between two VMs on the same host.
[5] Try this, or not?
[6] Try enabling or disabling LRO. Or play with all three settings and see what happens. https://kb.vmware.com/selfservice/microsites/search.do?langu...
[7] Try increasing buffer sizes. https://kb.vmware.com/selfservice/microsites/search.do?langu...
[8] Disable promiscuous mode on your NIC.
Other non-VMware things to investigate:
[1] Try a different guest OS.[2] Make sure you have no firewall rules on the guest, host, internet gateway, etc. Try a different destination host.
[3] Run tests in bulk, collect lots of samples and look for patterns.
[4] Check for dropped packets, errors on the network interface, in tcp/ip stats.
[5] Tcpdump the connection to see what happens when it succeeds or fails.
[6] Try a different host for your VM.
edit one more idea: Look at the response headers for the request to the site. The content length is 1413 bytes. Add on the TCPv6 and IPv6 header overhead (and http headers, etc) and this is probably over 1500 bytes, the typical MTU maximum. Try requesting a "hello world" text file and try your test again.