The standard ping command does not use TCP or UDP. It uses ICMP. To be more precise ICMP type 8 (echo message) and type 0 (echo reply message) are used.
ICMP has no ports!
See RFC792 for further details.
DHCP cannot use TCP as the transport protocol because TCP requires both end-points to have unique IP addresses. At the time a host is required to use DHCP, it does not have an IP address it can source the packets from, nor does it have the IP address of the DHCP server. So it uses 0.0.0.0 as the source IP address and 255.255.255.255 (broadcast) as the ...
Interesting perspective and question!
Yes, most of what UDP does is supply a standard means for multiple applications to co-exist using the same IP address, by defining the concept of UDP ports.
The exciting part about UDP isn't so much the network protocol but the API implemented by operating systems and socket libraries. While not part of the UDP ...
TCP is about as fast as you can make something with its reliability properties. If you only need, say, sequencing and error detection, UDP can be made to serve perfectly well. This is the basis for most real-time protocols such as voice, video streaming etc, where lag and jitter are more important than "absolute" error correction.
Fundamentally, TCP says ...
UDP is a transport protocol, like TCP. That means it provides a protocol for an application to use IP. Like TCP, UDP has addressing (ports) to which applications bind so that datagrams destined to bound applications get sent by UDP to the correct applications. UDP for IPv4 also provides an optional checksum, but the checksum is required for IPv6.
UDP is a ...
Since the source has no IP address (0.0.0.0) and the destination is everyone (255.255.255.255), it's hard to see how you would identify a particular session. But even if you could, what would be the benefit? The data in a DHCP message is quite small (~300 bytes), so it can easily fit into a single segment. It's not worth the overhead to establish a TCP ...
IP is a Layer 3 protocol. TCP/UDP are Layer 4 protocols. They each serve different purposes.
Layer 3 is in charge of end to end delivery. Its sole function is adding whatever is necessary to a packet to get a packet from one host to another.
Layer 4 is in charge of service-to-service delivery. Its sole function is to segregate data streams. Your computer ...
There are multiple reasons why TCP wouldn't work for DHCP(v4.)
First of all, TCP is connection-oriented. A TCP connection is defined between two particular hosts. However, when a DHCP client first starts up, it doesn't know which host(s) it wants to talk to. Its only option is to broadcast a DHCP DISCOVER message to all hosts on the local network. ...
While there is no formal "connection" with UDP there is still a convention that clients send requests and expect to get responses back with the source IP and port swapped with the Destinatoin IP and port.
Stateful firewalls and NATs therefore assume that packets with a given combination of source IP/source port/Destination IP/Destination port and the ...
There's no such thing as "UDP ICMP "echo"". traceroute sends a UDP probe with an increasing TTL. That probe is a single datagram destined for a high port which is unlikely to be a listening service. As the datagram flows out across the network, the TTL decrements until it hits zero at which point an ICMP ERROR ("time exceeded") is generated. That ICMP ...
I would encourage you to look at how higher level protocols that utilize UDP actually use it. Classic and well documented examples are DNS (in most cases at least, it's possible to do DNS over TCP but it's really uncommon), DHCP, NTP, and PTP.
All of these protocols have some specific things in common:
They care about being able to coexist with other ...
The answer is that it can be either broadcast or unicast - and in some cases both unicast and broadcast before it reaches the client when an ip helper-address is used.
A client doesn't actually have an IP address until the DISCOVER-OFFER-REQUEST-ACK exchange is completed. It is possible (although very unlikely) to have a situation arise where the server ...
Details vary but basically it goes something like.
The two peers both open a UDP socket bound to a random local port
The two peers both contact a server on the internet. This server responds and tells them what IP and port their packet was received from. Since the server is on the Internet the IP/port seen by the server is the external IP and port
The two ...
A switch learns the source MAC from the sender. If the destination is not in the CAM table, the switch floods the frame out all ports. So if the receiver never responds, the switch will never learn the receiver's MAC and it will always flood the frame.
Be aware of the broadcast flag, see RFC2131 (page 24):
A client that cannot receive unicast IP datagrams until its
software has been configured with an IP address SHOULD set the
BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
DHCPREQUEST messages that client sends. The BROADCAST bit will
provide a hint to ...
UDP is obviously a send-and-forget protocol. For example, during an NMap UDP scan, the only way to definitively prove that a UDP port is open is if you receive a response from that port. Keep in mind that many services may not reply to arbitrary data and require protocol or application-specific requests in order to warrant a response. Certain ICMP codes can ...
Your firewall is maintaining a connection table for UDP connections. For example, when you send a DNS query, the firewall creates an entry for that flow so that the DNS reply will be allowed back into your network. The entries in the table time out after 30 seconds of no activity.
UDP with reliability can indeed be a substitute for TCP. We already have an example of it: it's called QUIC.
Among other applications, QUIC improves performance of connection-oriented web applications that are currently using TCP. It does this by establishing a number of multiplexed connections between two endpoints over User Datagram ...
This is a quick recipe:
1) Start a packet sniffer:
sudo tcpdump -n -i eth2 icmp &
$ tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
2) Send an UDP packet:
$ echo reply-me | nc -u 18.104.22.168 1000
3) If you receive 'ICMP port unreachable', that ...
This is not the hosts that decide which route a packet will follow, each router in the path make it's own decision.
(Actually, the originating host could use the IP strict source option to force the packets to go through a specific route, but it's rarely, if ever, used, and it's totally ignored by routers on the Internet)
So each router can change the ...
IP protocol build on Ethernet or something, Why an IP packet can be 65535 bytes when Ethernet can only send 1500 bytes?
Ethernet is one of several physical layers which can be used to to transport IP (and also protocols besides IP). The size of the packet a physical layer can transport is specific to this physical layer, other physical layers have other ...
Transport of both UDP and TCP packets from one router to the next is done at the IP layer and solely based on the information at this layer. This means, that there is no distinction between UDP and TCP and in both cases change of path, congestion or router hickups can cause loss, duplication or reordering of packets.
But, contrary to UDP, TCP can deal with ...
I would take a look at iperf. You should be able to use built in reporting in iperf to validate the amount of traffic dropped.
iperf is typically ran across the network between two systems. I have iperf3 installed on two CentOS machines, as you can see below, one is configured as the server and the other the client.
Install the iperf rpm, start the ...
You asked a good question. Don't let anyone tell you otherwise.
Regrettably, there is no rule of thumb for the types of protocols that use TCP verses the types of protocols that use UDP.
The decision whether a protocol uses one or the other come down to whomever wrote/created the protocol to begin with.
If they didn't want to bother with writing their own ...
I'd like to give you an additional answer especially to this part of the question:
... someone says ICMP uses Port 7
Port 7 (both TCP and UDP) is used for the "echo" service.
If this service is available on a computer, UDP port 7 could be used instead of ICMP to perform a "ping".
However, most modern computers don't have the "echo" service running, so ...
A NAT router doesn't know when to remove a UDP mapping - it guesses.
The router simply ages (or times) out the entry when it hasn't been used for a period of time (usually between 5 and 60 minutes).
With TCP, there's also a similar aging/timeout to make sure that forgotten or lost sessions don't pile up, but it's much longer. Of course, normal TCP ...
Using a search for "linux ethernet packet generator" gives me packeth as the first hit.
Has both a GUI and CLI version
Generates not only UDP, but many other protocols as well, including QinQ
Is packaged for RedHat as an rpm, or Debian package
netcat and tcpdump Solution:
If it was me, I would just do a quick-and-dirty ten second netcat ...
The roots of the two technologies just are not really related.
When Bob Metcalfe, et al. were creating ethernet, they were not working with Vint Cerf, et al. who were creating IP. These were two completely separate efforts. When ethernet was created, it was not at all clear that IP would become dominant, and ethernet was just one of several LAN ...
This is a frequently asked question. The answer below is one of the best answers from another site.
In situations where you really want to get a simple answer to another
server quickly, UDP works best. In general, you want the answer to be
in one response ...