Tag Info

Hot answers tagged

64

You can find a good summary here: What is the difference between UDP and TCP internet protocols? Both TCP and UDP work at transport layer TCP/IP model, but have very different usage. The most important differences are: Reliability: TCP: connection-oriented UDP: connectionless Ordered: TCP: order of message receipt is guaranteed UDP: order is not ...


38

And the CEO level explanation: UDP is when you throw your paper in the general direction of the bin. TCP is when it misses, you throw exact copies of the same paper again and again until it falls into the bin. There would be paper wastage, even resent TCP packets result in wastage of network or system resources.


23

Linux auditing can help. It will at least locate users and processes making datagram network connections. UDP packets are datagrams. First, install the auditd framework on your platform and ensure that auditctl -l returns something, even if it says that no rules are defined. Then, add a rule to watch the system call socket() and tag it for easy finding ...


21

Web servers work with the HTTP (and HTTPS) protocol which is TCP based. As a general rule, if people neglect to specify whether they mean TCP/UDP/SomethingElse then they probably mean TCP.


21

The diagram on Wikipedia is horrible. Hopefully what I'm about to write is clearer. The maximum payload in 802.3 ethernet is 1500 bytes. This is the data you're trying to send out over the wire (and what the MTU is referring to). [payload] <- 1500 Bytes The payload is encapsulated in an Ethernet Frame (which adds the Source/Destination MAC, VLAN tag, ...


20

It uses TCP. It would be difficult to run it on UDP without the guarantee of packets arriving. If the packets don't arrive, the encrypted data will not be decipherable.


19

HTTPS can run over any reliable stream transport protocol. Normally that's TCP, but it could also be SCTP. It is NOT expected to run over UDP, which is an unreliable datagram protocol (in fact, while that's not its official name, that's a good way to remember what it is). The IANA assignment for UDP is historical; at the time, nearly every protocol was ...


18

can TCP packets arrive to receiver by pieces? Yes. IP supports fragmentation, though TCP generally tries to determine the path MTU and keep its packets smaller than that for performance reasons. Fragmentation increases the datagram loss rate catastrophically. If a path has a 10% packet loss rate, fragmenting a datagram into two packets makes the ...


17

You can't be sure that they really physically arrive at once. The Data link layers below TCP/UDP might split your packet up if they want to. Especially if you send data over the internet or any networks outside of your control it's hard to predict that. But no matter if the data arrives in one packet or multiple packets at the receiver. The OS should ...


17

The type of packet that is sent differs depending on the implementation. By default Windows tracert uses ICMP and both Mac OS X and Linux traceroute use UDP. I don't have BSD or Solaris machines or any other OS on hand to check but the man page for the Mac OS X version mentions its provenance is BSD 4.3. The Mac and Linux versions I have offer the ability ...


17

You can use netstat, but you need the right flags, and it only works if the process that is sending the data is still alive. It won't find the traces of something that came briefly to life, sent UDP traffic, then went away. It also requires local root privileges. That said: Here's me starting an ncat on my local host, sending UDP traffic to port 2345 on ...


16

You can use netcat - just start it, and type something inside, and pres the return key. nc -u <host> <port> And on the other side you can listen with netcat too (you should see the written text), or just start a tcpdump, and see packets coming in.


15

To quote the nc man page: -l Used to specify that nc should listen for an incoming connection rather than initiate a connection to a remote host. It is an error to use this option in conjunction with the -p, -s, or -z options. Additionally, any timeouts specified with the -w option are ignored. The key here is that -p cannot be combined ...


14

In our instance, our problem was solved by sysctl parameters, one different from Maciej. Please note that I do not speak for the OP (buecking), I came on this post due to the problem being related by the basic detail (no multicast traffic in userland). We have an application that reads data sent to four multicast addresses, and a unique port per multicast ...


13

Create a new chain which will accept any TCP and UDP packets, and jump to that chain from the individual IP/port permissive rules: iptables -N ACCEPT_TCP_UDP iptables -A ACCEPT_TCP_UDP -p tcp -j ACCEPT iptables -A ACCEPT_TCP_UDP -p udp -j ACCEPT iptables -A zone_lan_forward -d 1.2.3.0/24 -j ACCEPT_TCP_UDP This adds the overhead of a few extra lines, but ...


13

HTTP (1.0 without connection keep alive) is connectionless because once a single HTTP request is serviced, the connection is closed and not reused. HTTP requests are not TCP protocol data units, so that TCP is connection-oriented with respect to TCP protocol data units doesn't stop HTTP from being connectionless with respect to HTTP protocol data units. ...


12

There is no such thing as an "open" UDP port, at least not in the sense most people are used to think (which is answering something like "ok I've accepted your connection"). UDP is session-less, so "a port" (read: the UDP protocol in the operating system IP stack) will never respond "success" on its own. UDP ports only have two states: listening or not. ...


12

You are probably looking for RFC 6056 - Recommendations for Transport-Protocol Port Randomization ("Best Current Practice"). Technically there is no requirement that the ephemeral port be >1024 or random (you could build a system that always initiates connections from port 12 because you like the number 12), it's just not "normal" to do so (and an awful ...


12

The startup performance of a TCP connection is dictated by the round trip time, and every phase of the handshake takes one half of that. The more delay, the worse the initial performance of the connection. If TCP could be securely and safely completed in a one-way handshake, it would be, because that would be faster. So, it is 3-way not because there is ...


12

This can occur if you create a socket, but never connect() or bind() with it. Your best bet may be to strace (-fF) the application, and then cross-reference with the output of lsof to determine which sockets are causing the issue. As a bonus method of debugging: if you wrap your socket calls with debugging information and write them out to /dev/null, it'll ...


12

ARP Connection oriented or connectionless? Connectionless - it's just a request and a response (or a broadcast just letting everyone know about something). It uses TCP It doesn't use TCP - TCP is a layer 4 protocol, whereas ARP is glue between layers 2 and 3.


11

RSS too is enabled in the NIC settings, with 8 queues. Which unfortunately did not mean that RSS was being employed, as netsh int tcp show global showed: TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : disabled After running (btw without rebooting) netsh int tcp set global rss=enabled RSS ...


11

You can't rely on UDP to deliver packets in order because the specification doesn't provide those guarantees. Even assuming the most ideal situation, a single piece of ethernet cable between two hosts, there is still the matter of the OS, the network stack, the NIC driver, and the libc implementation that your writing against. At every step in that chain, ...


11

You need to use netcat instead, telnet only supports tcp. Something like this will work: $ nc -u localhost 48772 netcat is installed by default on most modern linux machines (assuming that's what you have). Also for completeness sake I want to point out that there's another tool called socat which describes itself as 'netcat++'. Might be a good thing ...


11

Try iperf An article that explains the different steps: http://taosecurity.blogspot.com/2006/09/generating-multicast-traffic.html


10

Don't load balance your DNS. It's an incredibly light protocol - you'd need an enormous amount of traffic to need more than one box (in which case you'll just be bottlenecking on your load balancer anyway), and there's resilience built in because you can use multiple NS records in your delegation (other servers will be used if one's down).


9

When tcpdump is running, it will be fairly prompt at reading in the incoming frames. My hypothesis is that the NIC's packet ring buffer settings may be a bit on the small size; when tcpdump is running it is getting emptied in a more timely manner. If you're a Red Hat subscriber, then this support article is very useful Overview of Packet Reception. It has ...


9

You can use netcat or nc. It supports TCP and UDP. Use the -u for UDP sockets. You can read man nc for more details.


9

I think that you may be looking for Mosh, the Mobile Shell



Only top voted, non community-wiki answers of a minimum length are eligible