Consider this scenario:
I've 10 Mbps internet connection. One user is downloading 1GB file from internet over TCP called TCP.file and another 1GB file from internet using UDP called UDP.file.
Assume there are no issues with the server (or upstream) serving files over TCP & UDP. There is no packet inspection or anything, just plain router.
Which download will complete first? Will it be TCP.file or UDP.file? And why?
I've two arguments:
1) TCP.file will compete first. Because TCP has flow control and can gobble up entire 10 Mbps BW.
2) UDP.file will compete first. Since UDP has less overhead and no flow control, this can also send consume entire 10 Mbps BW.
Can anyone tell which is correct?
Related
It is a SpringBoot website and deployed in one Linux server. We use Jmeter to do the load test.
We mock 500 users to visit the webiste index page simultaneously. The index page is very simple html, no database connection,so it is a quite short connection.
After about 2 minutes, Jmeter starts to throw timeout exception as bleow
I guess this is because of website reaching its capacity and running out of connection.
I get one quesiton here, why does website reach its capacity 2 minutes later after Jemter starts. If its TCP connection capacity for this website is 1000, I guess it will reach 1000 very soon after the Jmeter starts, not 2 minutes.
Besides, I see many TCP connections are in TIME_WAIT status in Linux server. I guess this may be related with the connection timeout?
Edit: Someone thinks it is running of port. Someone thinks it is running out of connection. And someone thinks it is running out of processing thread(eg. What does this messge java.net.ConnectException/Connection timed out mean in log.jtl file of Jmeter?). I don't know which one is the exact reason...
Most probably this is due to underlying Linux TCP/IP kernel stack configuration, as per Linux TCP/IP tuning for scalability article:
By default, a connection is supposed to stay in the TIME_WAIT state for twice the msl. Its purpose is to make sure any lost packets that arrive after a connection is closed do not confuse the TCP subsystem (the full details of this are beyond the scope of this article, but ask me if you’d like details). The default msl is 60 seconds, which puts the default TIME_WAIT timeout value at 2 minutes. Which means you’ll run out of available ports if you receive more than about 400 requests a second, or if we look back to how nginx does proxies, this actually translates to 200 requests per second. Not good for scaling.
SO double check timeouts along with maximum number of ports/sockets/files on the Linux server - my expectation is that the aforementioned parameters need to be tuned for high loads.
It's also a good practice to have monitoring of baseline OS health metrics in place (CPU, RAM, Network, Disk, swap usage, etc.). You can use i.e. JMeter PerfMon Plugin or JMeter SSHMon Listener for this.
In the client-server environment, when client sends a packet (with source ip / dest ip / ports ... etc) requesting "GET /index.php ... etc",
at the server application (daemon) arrives the whole packet (the whole bits of data) including mac, IPs, ports, tcp flags, payload ? Or just the payload ?
Because I don;t understand how the scripts can read remote address (like echo $_SERVER['REMOTE_ADDR']; )
The server machine gets the whole packet. Its kernel and TCP/IP stack receives and processes it. The application server is using a socket to talk to the kernel, which is a higher-layer interface than raw packets; therefore it has a different view. Assuming we are talking about TCP, you will find among other things:
Information from the physical or datalink layer (such as source and destination MAC addresses) is not available on the socket (unless you do very fancy and probably non-portable things).
Some information from the IP & TCP layer is made available so the application can retrieve it using special system calls such as getsockname() and getpeername(). This includes the IP addresses and ports.
The application is not concerned with most of the rest of the information from the IP & TCP layers and it is not made available on the socket. For example, options, window size, checksum, fragment offset.
The application sends and receives data on the socket as though it was a continuous stream of bytes. It does not know or care how the datastream is broken up into small packets each containing a piece of the data.
for the specific case of $_SERVER['REMOTE_ADDR']; which you highlight, this information comes from the aforementioned getpeername() system call. PHP calls this for you and makes the information available.
I'm a beginner to ethernet programming, I want to access the ethernet port and send/recieve packets to/from it. I thought of using the CIM_EthernetPort class, but don't know how to do it. please help. I have to write a program to send data to an embedded system.
I don't think you quite understand what sockets are.
What protocol does your embedded device use? If it's TCP or UDP (or even a raw link protocol) it's pretty much using a socket by definition.
The only reason you might need to talk to an ethernet adapter without using sockets is if you want to write something like a wire level monitor or packet sniffer.
ps -------------------------------------------------------------
Sockets are just an abstraction of a network connection, since a UDP connection has an endpoint and a port it's a bit philosophical wether you are using sockets if you talk directly to the network card hardware.
You don't specify a baud rate as such on ethernet, the card hw will negotiate a speed.
There is very little overhead in sending data by UDP using sockets and it's usually a very efficent way of receiving data. Do you have an RTOS on the embedded device or were you trying to talk to the network adaptor directly with some sort of polling?
pps ------------------------------------------------------------------
If it is at all possible to use UDP on the embedded device - DO SO.
If you start with, I just need to send a few numbers, you ultimately end up re-inventing and re-solving all the things UDP was invented to do.
By using standard protocols you also get tools to let you test each end of the connection (there are UDP equivalents of hyperterm for free).
Also there is no need for multiple devices now, but there may be in the future. I argued for using UDP on a previous product I worked on - where the designers were thinking of ethernet as just a faster serial link. Being able to network many units of this product together has created a huge new market.
I am trying to measure latency to a server that I don't control. This is in a colocated environment, so the latency is on the order of 500 us (.5 ms).
I understand that Cisco gear frequently deprioritizes ICMP traffic, making ping times unreliable. Is there a way for me to tell if this is the case on the gear I am traversing?
Can I use TCP acknowledgements to determine the minimum latency to the remote server? To do this, I would somehow need to force the remote server to send a TCP ack immediately on receiving my data.
Try hping. You can send acks and measure the latency:
hping -A -p 80 host
or with a SYN:
hping -S -p 80 host
Also note, deprioritization on a layer-2 link is unlikely (but possible). In addition, seeing ARP being slower than ICMP doesn't necessarily mean ICMP isn't deprioritized---it might mean bandwidth is insufficient to hit the limiting threshold.
ARP will almost always be slower because it broadcasts and may suffer port-queuing at the switch. You could unicast ARP, but that might look suspicious if anyone is looking for it.
You could try using arping, which does a ping using ARPs.
I recently turned on Windows Firewall logging on my computer and started tracking incoming and outgoing connections. Something curious about the logfiles is that I have noticed numerous UDP packets (in fact, it constitutes basically all of my incoming traffic) that don't have my host as destination or source showing up in the logs.
I thought this might be a implementation detail for UDP (the packets are hopping over my computer in the subnet) but Wikipedia'ing UDP didn't enlighten me any more, and I don't see why my computer should be forwarding these packets in the first place.
Any ideas?
Edit 1: Here is what a log file line with the mysterious UDP packet looks like:
2008-10-11 16:04:31 ALLOW UDP 18.243.7.218 239.255.255.250 49152 3702 0 - - - - - - - RECEIVE
Is 239.255.255.250 a broadcast address? Now that you mention it, the UDP packets I'm seeing have very specific destinations, basically 224.0.0.252, 239.255.255.250, 18.243.255.255. I also get phantom ICMP pings addressed to 224.0.0.1.
The packets addressed to IPs starting with 239 and 224 are multicast packets. This is a way to address traffic to a group of computers without broadcasting it to an entire network. It is used by various legitimate protocols.
224.0.0.252 is the address used by the Link Local Name Resolution protocol.
239.255.255.250 is the address used by the Simple Service Discovery Protocol.
224.0.0.1 is the all hosts address, used by your router to see who on your network is willing to participate in multicast conversations.
The ones addressed to 18.243.255.255 look like broadcasts, again this is used by many legitimate protocols such as Bonjour.
As recommended by Luka, a good protocol analyzer like Wireshark will tell you precisely what each of these packets are and what they contain.
It depends on the type of connection you are on.
On most cable modem ISP's you are basicly on the same LAN as your neigburs, and can usualy see some of their traffic (like brodcast).
Id recomend you install packet sniffer and see what is realy going on.
Good multiplatform packet sniffer is Wireshark
Hard to say without analyzing the log data, but they could be broadcast packets on the segment, in which case you're system would listen to them. This is possible in IPv4 and IPv6.
Your system should not be forwarding them unless it's set up to route, but it can certainly be listening to packets all the time (various network protocols use UDP).