1222
How TCP and UDP packets come to the world (lemmy.one)
submitted 3 years ago* by to c/programmerhumor@lemmy.ml
46 comments fedilink hide all child comments
 
you are viewing a single comment's thread
view the rest of the comments
[–] 13 points 3 years ago (7 children)

So, UDP just sends it out there and anyone can intercept it?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 14 child comments
    •
  • [–] 43 points 3 years ago (1 child)

    No. Both UDP and TCP can be intercepted the same. The difference is that UDP sends a packet to an address. But doesn't have any in built system to check that it arrived, that it arrived intact or to resend if it didn't. There's also no built in way to protect against spoofing or out of order packet delivery. But generally implementations will handle the ones that are important of those themselves.

    TCP establishes a circuit, packets are sent, verified and resent if required until the original data, in the correct order is delivered to the application. Also there is some protection against spoofing with sequence numbering. The downside is that time sensitive data might be delayed because of the retransmission and re-assembling. Which is why time sensitive streams like VoIP are usually sent over UDP.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 27 points 3 years ago (4 children)

    No. UDP is at the packet level. Interception is a different layer.

    To use to today's language, UDP yeets the packets at you as fast as it can generate them.

    It doesn't care if you catch any of them.

    Don't yeet the baby.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 8 child comments
    •
  • [–] 40 points 3 years ago (1 child)

    actually, do yeet the baby if you have an application with different needs. for example, if you want to play a game, you're better off yeeting 60 babies a second and just hope that whoever is on the side catches enough of them to get a smooth stream of babies, than making sure every baby is handed gently to the next person and get the whole line clogged up the moment anything disrupts it. if you just use the yeetomatic 3000 you're always getting fresh babies on the other end, a few might just be dropped in the process

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 7 points 3 years ago (1 child)

    Don’t yeet the baby.

    or at least care if you catch any of them.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 4 points 3 years ago (3 children)

    I mean generally, I don't think we yeet babies. We yeet lots of things, but usually not babies.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 6 child comments
    •
  • [–] 3 points 3 years ago* (1 child)

    What do you mean interception is at a different layer? You can capture at any layer as long as the payload isn't encrypted, and if it is, you still get layers 1 through 4 (Physical, Link, Network, and Transport).

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 7 points 3 years ago

    UDP is a transport protocol. OSI layer 4. It sits atop the packet (network/L3) layer which is where IP dictates where a packet is going. A broadcast or multicast IP address would mean it can be observed by many machines, but unicast is still the most common, and is routed to just one machine.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 3 years ago

    The benefit is that you don't need to wait for verification from the user that they got the packet before you can send the next group of packets. If you're, say, watching a stream, it's not important that you received the packets because that's just a few skipped frames or a second of lag, whereas the tradeoff on overhead is pretty big.

    TCP is more important with like file downloads where it's okay if it takes a couple hours to get a really big file as long as that file isn't corrupted or missing any data.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 3 points 3 years ago

    You'd have to be somewhere in the route from A to B to intercept it. But TCP is no different in that regard.

    TCP is connection based so both sides need to agree to connect before data is exchanged. UDP is connectionless, so it will send data from A to B (and vice versa) regardless of if the other side is available.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 3 years ago* (last edited 3 years ago) (2 children)

    From what I can tell yes. There's no established connection, the data is sort of just broadcasted.

    Edit: I was operating under a misunderstanding, please refer to andrew's response.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 8 points 3 years ago

    Broadcast would mean it's sent to anyone. UDP packets still usually have a unicast address and thus are routed by routers and switches to specific machines, but as a connectionless protocol, UDP never validates which, if any, packets are received by the recipient like TCP does. If any verification is needed that needs to be handled higher in the OSI stack. E.g. by the application layer.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 5 points 3 years ago

    No no, it's not "broadcasted". It still has a fixed sender and receiver IP address, but UDP doesn't verify whether the receiver got the data or not. You can implement that over UDP, but you have to do it yourself.

    With TCP, the packet will retransmitted automatically if the receiver didn't tell the sender "yep, I got it".

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 3 years ago

    No, instead of using TLS for encryption (like most TCP traffic) UDP will use things like DTLS and SIP

    Or if you're asking about the actual transport it's more like TCP is going to your friend's house and calling your mom to let her know you're there vs UDP is going to their house and not calling.

  • permalink
  • fedilink
  • source
  • parent