TCP_vs_UDP

TCP

• It is connection oriented
  • official “start” and “end”
• It is reliable
  • Confirmation of delivery
  • sender is aware of the error
  • Data is delivered in correct order
• Flow control
  • TCP adjusts transmission rate to safely use maximum available bandwidth without exceeding it
• More overhead
  • packet has more header data

UDP

• It is not connection oriented
  • no official “start” and “end”
  • connection defined by timeout (2 minutes is common)
• No confirmation of delivery
  • Fire and Forget
  • No awareness of error
  • No intrinsic data ordering
• No Flow control
  • UDP transmits as fast as it can
• Less overhead
  • packet has less header data

Myths

• UDP is faster
  • both have identical speed
• TCP is more secure
  • security is identical
  • No security provided by TCP or UDP
• UDP is unreliable
  • UDP does not provide reliability
  • Protocols implement their own reliability
• TCP is guaranteed delivery
  • TCP provides confirmation of delivery
  • Cannot magically make data arrive if the wires are broken for example

Ideas of TCP

• https://www.youtube.com/watch?v=JFch3ctY6nE&list=PLIFyRwBY_4bS-PQZoF0UySdG0sH9VA0bn
• Sequence Numbers track what is sent
• Acknowledgement Numbers track what is received
• Sequence / Acknowledgement numbers are a measure of bytes
• TCP caches everything sent for duration of “Retransmission Timeout”
  • If no ACK is received, segment is resent
• Initially, TCP sent an ACK after every received segment
  • Delayed Acknowledgements - send ACK every other segment
  • ACKnowledgements are cumulative
• Window Size limits how much unacknowledged data can be sent
  • aka “bytes in flight”
• Window Size sent in each segment
  • Can be dynamically updated through connection (Flow Control)
• TCP is bidirectional - both peers can send data
  • Both peers have a SEQ# to track bytes sent
  • Both peers have an ACK# to track bytes received
• Initial Sequence Numbers (ISN) are randomly chosen by sender
  • Must be shared at connection established (3-way handshake)
• TCP Connection starts with 3-way handshake; includes 4 events:
  • A ⇒ B: SYNchronize with my Initial Sequence Number of X
  • A ⇐ B: I received your SYN, I ACKnowledge that I am ready for X+1
  • A ⇐ B: SYNchronize with my Initial Sequence Number of Y
  • A ⇒ B: I received your SYN, I ACKnowledge that I am ready for Y+1
  • Step 2 and 3 is combined into single packet
• TCP has two options for closing a connection:
  • Graceful method - FIN flags
  • Ungraceful method - RST flags
• Graceful connection closing: Four-way closure with FIN flags:
  • A ⇒ B: I have FINished sending data, my last Sequence# is X
  • A ⇐B: I ACKnowledge receiving your FIN with Ack# X+1
  • A ⇐ B: I have FINished sending data, my last Sequence# is Y
  • A ⇒ B: I ACKnowledge receiving your FIN with Ack# Y+1
  • Step 2 and 3 may or may not be combined into single packet
  • It is possible to disconnect one way connection and have the other way connection active
• Ungraceful connection closing: One-way with RST flags:
  • A ⇐> B: Something went wrong… sending a RESET flag
  • RST is Unacknowledged, can be sent by either party

TCP: Three-way handshake

• A ⇒ B: SYN
• A ⇐ B: SYN/ACK
• A ⇒ B: ACK

sequenceDiagram
    Client->>+Server: SYN Packet
    Server-->>-Client: SYN/ACK Packet
    Client->>+Server: ACK Packet

Use cases of UDP

• Applications with Small Requests and Responses
  • If most messages < 300 bytes fit inside single packet
  • If TCP additional overhead is unnecessary
  • Example: DNS
    • UDP - 2 packets
      • A ⇒ B: request IP of domain name
      • A ⇐ B: response with IP
    • TCP - 11 packets
      • 3-way handshake: 3 packets
        • A ⇒ B: SYN
        • A ⇐ B: ACK / SYN
        • A ⇒ B: ACK
      • requesting IP for domain name: 4 packets
        • A ⇒ B: request IP of domain name
        • A ⇐ B: ACK
        • A ⇐ B: response with IP
        • A ⇒ B: ACK
      • closing connection both side: 2 + 2
        • A ⇒ B: FIN
        • A ⇐ B: ACK
        • A ⇐ B: FIN
        • A ⇒ B: ACK
  • Examples:
    • Network Time Protocol (NTP)
    • Dynamic Host Configuration protocol (DHCP)
    • SNMP, Syslog
• Applications with built-in Delivery Confirmation system
  • They have their own system to ensure reliability
  • Example:
    • Trivial File Transfer Protocol (TFTP)
    • Includes its own acknowledgement system
  • Examples:
    • QUIC (HTTP/3)
    • RTP, SNMP
• Applications that involve live or streamed content
  • It is okay to miss some part of the data
  • Whenever Latest / real-time packet is more important than Older dropped packet
  • It will be problematic to replay the lost data later since context will be lost
  • Example:
    • Voice over Internet Protocol (VoIP)
    • RTP, SRTP, SIP, H.323
  • Use cases
    • Live TV Multiplayer Video Games

TCP Packet

• Max packet size not specified

---
title: "TCP Packet"
---
packet-beta
  0-15: "Source Port"
  16-31: "Destination Port"
  32-63: "Sequence Number"
  64-95: "Acknowledgment Number"
  96-99: "Data Offset"
  100-105: "Reserved"
  106: "URG"
  107: "ACK"
  108: "PSH"
  109: "RST"
  110: "SYN"
  111: "FIN"
  112-127: "Window"
  128-143: "Checksum"
  144-159: "Urgent Pointer"
  160-191: "(Options and Padding)"
  192-255: "Data (variable length)"

UDP Packet

• Length Header = Total Packet Size in bytes
  • = Header Size + Data size
  • = 2 bytes
• Min Packet Size = Only Header Size
  • = source port + destination port + length + checksum
  • = 8 bytes
• Max Packet size = 2^16 bits = 65,535 bytes

packet-beta
title UDP Packet
0-15: "Source Port"
16-31: "Destination Port"
32-47: "Length"
48-63: "Checksum"
64-95: "Data (variable length)"

Ports

• Both TCP and UDP have ports which is 2 bytes long $(2^8{)}^2=2^{16}=65,535$
• The server runs on pre-defined port, and
• The client sends request:
  • destination port must be the same as pre-defined server port
  • source port is randomly chosen
• Ports belong to L4 layer
• IP addresses belong to L3 layer and not defined in TCP, UDP spec