Tag Info

Hot answers tagged

59

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 ...


37

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.


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.


19

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, ...


18

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.


17

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 ...


17

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 ...


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

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 ...


14

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.


13

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 ...


13

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 ...


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 ...


11

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 ...


11

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. ...


11

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 ...


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, ...


10

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 ...


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.


8

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 ...


8

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


7

Based on the image of your capture, it looks like a DOS and not a DDOS since the originating ip address is the same. It looks like they're trying to connect to UDP port 17 (QOTD - http://en.wikipedia.org/wiki/QOTD), if I'm reading the capture correctly, which I might not be since I've never used tcpdump. How about starting out by blocking just that ip ...


7

By definition, if a UDP packet is dropped, the receiver cannot sent a notice back to the sender because nothing was received. You can layer your own acknowledgement system on top of UDP. Even a simple "if no data has been received in X seconds, send a packet to the sender indicating such". You can embed your own sequence numbers into the UDP packets, so that ...


7

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 ...


7

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. ...


7

It looks to me your server is being used in a DNS amplification attack. I don't know the pricing model of Amazon EC2, but I'd be surprised if this traffic didn't count. It works like this: Someone is sending a DNS query to your server with the spoofed IP 108.162.233.15. Your server answers this query to the real victim - 108.162.233.15. The query is ...


6

What is efficient way for sending such small amounts of data reliably? (UDP with ack?) Yes, this is essentially what UDP was invented for. That or use long lived TCP connections. Why my headers are bigger than 40 bytes (60 or 52)? Most OSes include much more than the bare minimum. How can I print key-value list of headers instead of hex ...


6

OpenVPN over UDP also uses TLS, so it is equally effected just like HTTPS. I have verified this by looking at a packet capture, and saw that the Heartbeat extension is advertised. Many public tools just check for TLS/STARTTLS servers, but there is no reason why someone cannot craft a special tool for OpenVPN. The TLS layer in OpenVPN runs on a proprietary ...


6

Yes, OpenVPN derives its encryption entirely from OpenSSL. The OpenVPN community has posted a response to Heartbleed: https://community.openvpn.net/openvpn/wiki/heartbleed



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