Quick answer: what are TCP and UDP?
TCP means Transmission Control Protocol. UDP means User Datagram Protocol. TCP provides a connection-oriented, reliable, ordered byte stream. UDP sends separate datagrams and does not itself guarantee delivery, order, or duplicate protection. The biggest difference is who owns recovery: TCP performs it in the transport; a UDP-based application decides which loss, ordering, timing, and recovery rules it needs.
Neither transport is automatically faster for every job. TCP can delay later data while it recovers an earlier loss; UDP lets an application decide whether a late packet is still worth using. For live media, that decision belongs to the protocol and workflow above the transport. SRT runs over UDP. RTSP commonly uses TCP for control, while its media can use UDP or interleaved TCP. Callaba does not change TCP or UDP itself.
TCP and UDP FAQ
- What do TCP and UDP stand for?
TCP stands for Transmission Control Protocol. UDP stands for User Datagram Protocol.
- What is the biggest difference between TCP and UDP?
TCP delivers an ordered byte stream and retransmits missing data. UDP delivers independent datagrams without those delivery or ordering guarantees, so the application chooses its recovery behavior.
- Is UDP connectionless?
UDP is connectionless at the transport layer: it has no TCP-style connection setup or built-in delivery state. An application using UDP can still create its own session, authentication, and recovery rules.
- Is UDP faster than TCP?
UDP has less transport-layer work, but that does not make every UDP application faster. The useful comparison is whether the complete application path meets its delivery and timing deadline on the real network.
- Does multicast use TCP or UDP?
IP multicast is normally used with UDP. TCP is designed for one-to-one connections and does not provide IP multicast delivery.
- What are UDP packets and UDP ports?
A UDP packet is a datagram with source and destination port numbers. A UDP port identifies the receiving application endpoint on a host; it is not a physical network port.
- How does UDP send data?
An application gives UDP a datagram and a destination IP address and port. UDP adds its header and sends that datagram without a connection handshake. A UDP client can send another datagram immediately, but delivery, ordering, duplicate handling, and replies belong to the application.
- What does a UDP header contain?
A UDP header is eight bytes long and contains four fields: source port, destination port, datagram length, and checksum. The checksum covers the UDP header and payload; its requirements differ between IPv4 and IPv6.
- Which OSI layer uses TCP and UDP?
TCP and UDP operate at the transport layer, Layer 4 of the OSI model. Applications use them above IP, while the application protocol defines the finished service behavior.
- What commonly uses UDP?
Common examples include DNS queries, DHCP, NTP, RTP media, multicast delivery, and QUIC. Each application protocol adds the session, security, congestion, timing, or recovery behavior it requires.
- When is UDP preferred?
UDP fits applications that need datagram boundaries, multicast, or control over which late data should be recovered or discarded. It is often useful for real-time media and small request-response exchanges, provided the application implements the reliability and congestion behavior it needs.
- Can UDP transfer files?
Yes, when an application protocol supplies the missing reliability. TFTP uses UDP and adds block acknowledgements and retries. Many other file-transfer paths use TCP, while newer protocols may build reliable transfer over UDP; the transport name alone does not guarantee a complete file.
- Does video streaming use TCP or UDP?
It can use either. The application protocol and playback deadline decide the transport path: SRT runs over UDP, RTSP media can use UDP or interleaved TCP, and HTTP streaming follows the transport used by its HTTP version. Test the complete media path rather than choosing from the transport label alone.
Transport choice is a choice about failure behavior. Ask what the application should do with a late, lost, duplicated, or reordered unit of data before asking whether TCP or UDP is faster.
TCP and UDP do not define the complete streaming experience
They carry application protocols with different recovery, timing, congestion, encryption, and playback designs. This page compares transport behavior. Implementation belongs with the chosen protocol: SRT, WebRTC, HLS streaming, or RTMP. No product claim follows from the transport name alone.
TCP presents a reliable ordered byte stream
The current TCP standard, RFC 9293, defines a connection-oriented reliable byte stream. TCP detects loss and retransmits, preserves order for the application, and applies congestion behavior. The application does not receive later bytes ahead of a missing portion of the same stream.
That is valuable when missing data would make the next operation unusable. It can also make timeliness depend on recovery. “Reliable” describes delivered bytes, not a promise that a live viewer receives them before their deadline.
UDP sends datagrams without delivery guarantees
RFC 768 defines a minimal datagram transport. UDP itself does not guarantee delivery, ordering, or duplicate protection. Message boundaries remain visible, and an application can decide which late data is still useful.
That freedom is not permission to ignore congestion, sizing, integrity, or recovery. The IETF’s UDP usage guidelines, RFC 8085, describe responsibilities that a well-behaved application must address.
Define the unit that can be late
For a file, every byte may be required eventually. For a live conversation, a very late audio packet may be less useful than the current speech. For contribution, the receiver may use retransmission inside a bounded window. For segmented playback, the application may build a buffer and fetch objects over HTTP. Write the useful lifetime of data, loss tolerance, ordering need, and recovery window for the actual media path.
Separate message boundaries from media boundaries
TCP exposes bytes rather than preserving application messages, so the application must frame its own units. UDP preserves datagram boundaries, but a media frame may span several datagrams or several media items may share a larger application object. Packet capture should therefore be joined with the application’s sequence numbers, timestamps, and frame or segment identifiers. Counting datagrams alone rarely explains the visible interruption.
Test payload size on the real route. Fragmentation, encapsulation, tunnels, or a smaller path MTU can turn an apparently harmless message into multiple network pieces with a higher loss surface. Change size only with the application’s current guidance and observe the resulting media, rather than treating one packet-size rule as universal.
Run a packet-lab comparison on the intended network
Normal path, representative duration, synchronized clocks.
Add one measured condition: delay, variation, loss, reorder, or constrained capacity.
Sender, transport, receiver, buffer, media continuity, recovery time.
Same content and condition after one application change.
Capture round-trip time, loss and reorder events, throughput, send queue, receive timing, application retransmissions, buffer level, freezes, audio gaps, and time to recover. The round-trip delay guide helps define that measurement. Avoid declaring UDP faster or TCP safer from a single clean-network run.
Include middleboxes and competing traffic
Enterprise firewalls, carrier networks, NAT mappings, proxies, VPNs, and load balancers can affect reachability and idle behavior differently from a laboratory switch. Test from the actual offices, mobile networks, remote sites, and cloud regions in scope. Observe connection establishment, sustained flow, idle periods, reconnect, and policy denial without labelling every failure an inherent transport limitation.
Add representative competing traffic and run more than one session when concurrency matters. Watch queue growth and recovery for both the media flow and its neighbours. A configuration that looks responsive in isolation may become unfair or unstable when several encoders share an uplink.
| Application need | Question for TCP | Question for UDP-based design | Observed result |
|---|---|---|---|
| Complete ordered data | Can retransmission finish inside the deadline? | Which reliability layer restores missing units? | Completion, delay, and recovery under loss |
| Live timeliness | What happens while an earlier byte is recovered? | Which packets may expire, and how is loss concealed? | Media continuity and age of delivered content |
| Network fairness | How does the connection respond to congestion? | What congestion behavior does the application implement? | Rate change, queue growth, competing traffic |
| Reachability | Does the deployed path permit and sustain it? | Do policies and middleboxes permit the application flow? | Connection rate across real sites and devices |
HTTP transport depends on the HTTP version
Do not write that all HTTP streaming uses TCP. HTTP/1.1 and HTTP/2 normally run over TCP. HTTP/3 maps HTTP semantics over QUIC, and QUIC uses UDP; see the current HTTP/3 standard, RFC 9114. An HLS deployment therefore needs its HTTP version named before transport behavior is described.
Security also belongs above the bare transport. TCP and UDP by themselves do not establish the authentication, confidentiality, authorization, key rotation, or replay behavior of the finished media service. Record the secure application protocol and certificate or key lifecycle separately, then verify it under reconnect and failover conditions.
Failure case: recovery succeeds after the moment has passed
During a live test, a loss event pauses delivery, the missing data is recovered, and playback resumes with a larger delay. Align sender, receiver, and player traces. Identify whether the pause occurs in transport recovery, an application retry, or the playback buffer. Compare with the written deadline. The correct response may be a different buffer, recovery window, media policy, or application protocol—not a blind switch of transport.
Hand the failure contract to the application protocol
Record which data must arrive, how long it stays useful, allowable reordering, loss concealment, congestion behavior, encryption requirement, network restrictions, and the measured recovery result. Then choose and test the application protocol that implements those needs. Re-run the impaired-network case after configuration, because a transport label cannot validate the finished media path.
Keep the packet capture, application log, media recording, impairment settings, and clock notes together. Future changes can then be compared with the same failure rather than with a vague memory of better performance.
