Whenever two computers, servers, smartphones, CCTV systems, applications, websites, games, or other network devices communicate over an IP network, simply knowing the destination IP address is not enough. The systems also need rules governing how application data should be transported.

Two of the most important protocols responsible for this job are:

• TCP — Transmission Control Protocol
• UDP — User Datagram Protocol

Both operate at the Transport Layer of the TCP/IP networking model and are generally associated with Layer 4 of the OSI model.

Although TCP and UDP perform a similar basic function—transporting application data between endpoints—their designs are fundamentally different.

The simplest distinction is:

TCP focuses on reliable and ordered delivery.

UDP focuses on minimal overhead and low latency.

That simple distinction, however, hides a large amount of networking technology. Understanding TCP and UDP is essential for network administrators, IT engineers, software developers, cybersecurity professionals, firewall administrators, CCTV technicians and anyone troubleshooting network applications.

1. Where Do TCP and UDP Fit in Networking?

A simplified TCP/IP stack can be represented as:

Application Layer
       ↓
Transport Layer
   TCP / UDP
       ↓
Internet Layer
       IP
       ↓
Network Access Layer
Ethernet / Wi-Fi etc.

An application such as a browser does not normally send Ethernet frames itself.

Instead, application data passes through different layers.

For example:

Web Browser
     ↓
HTTP / HTTPS
     ↓
TCP
     ↓
IP
     ↓
Ethernet / Wi-Fi
     ↓
Network

With modern HTTP/3, the path is different:

Web Browser
     ↓
HTTP/3
     ↓
QUIC
     ↓
UDP
     ↓
IP
     ↓
Ethernet / Wi-Fi

Therefore, UDP should not simply be viewed as an old or primitive alternative to TCP. Modern protocols such as QUIC deliberately use UDP as a foundation while implementing sophisticated reliability and congestion-control mechanisms above it.

2. What Is TCP?

TCP stands for Transmission Control Protocol.

TCP is a connection-oriented transport protocol designed to provide reliable, ordered communication between applications.

Before normal application data is exchanged, TCP establishes a logical connection between the two endpoints.

TCP provides mechanisms for:

• Connection establishment
• Reliable delivery
• Sequence numbering
• Acknowledgements
• Retransmission
• Duplicate detection
• Ordered delivery
• Flow control
• Congestion control
• Error detection
• Connection termination

Because of these mechanisms, TCP is widely used where losing or rearranging data would be unacceptable.

Examples include:

• Web browsing
• File transfers
• Email
• Remote administration
• Database communication
• Business applications
• Traditional web APIs

3. TCP Is Connection-Oriented

Suppose Computer A wants to communicate with Server B.

TCP normally establishes the connection first.

This process is commonly known as the:

TCP Three-Way Handshake

The basic process is:

Client                         Server

   SYN  ------------------------>

        <---------------- SYN-ACK

   ACK  ------------------------>

Connection Established

Step 1 — SYN

The client sends a TCP segment with the SYN flag set.

Conceptually:

Client → Server
SYN

SYN means synchronization and is involved in establishing initial sequence-number state.

Step 2 — SYN-ACK

The server responds:

Server → Client
SYN + ACK

The server acknowledges the client's request and provides its own synchronization information.

Step 3 — ACK

The client sends:

Client → Server
ACK

The TCP connection is now established and application data can be exchanged.

4. Why Does TCP Use Sequence Numbers?

IP networks do not inherently guarantee that packets will arrive in the exact order in which they were transmitted.

TCP therefore maintains sequencing information.

Imagine an application sends data that TCP handles conceptually as portions:

Data 1
Data 2
Data 3
Data 4

If network behavior causes the receiver to obtain data in a different order, TCP can use sequence information to reconstruct the correct byte stream.

Conceptually:

Received:

Data 1
Data 3
Data 2
Data 4

TCP can deliver the application stream in its correct logical order rather than simply handing the application incorrectly ordered data.

5. TCP Acknowledgements

TCP uses acknowledgements to help confirm successful receipt of data.

Conceptually:

Sender                  Receiver

Data -------------------->

     <---------------- ACK

TCP acknowledgements are more sophisticated than simply saying "packet number 1 received." TCP sequence and acknowledgement numbers refer to positions in the TCP byte stream.

If expected data does not appear to have been successfully delivered, TCP can retransmit it.

6. TCP Retransmission

Suppose data is transmitted but lost somewhere in the network.

Sender

   Data
     |
     X  Packet/Data Lost
     |
Receiver

TCP has mechanisms for detecting missing data and retransmitting it.

Conceptually:

Send Data
   ↓
Data lost
   ↓
Loss detected
   ↓
Retransmission
   ↓
Receiver obtains data

Retransmission is one major reason TCP is considered reliable.

It also explains why TCP may experience increased latency when packet loss is significant.

7. TCP Provides Ordered Delivery

TCP presents applications with an ordered byte stream.

If network packets arrive out of order, TCP handles reassembly before the application receives the corresponding stream data.

This is essential for applications such as:

• File downloads
• Email
• Database queries
• Web documents
• Software downloads

Imagine downloading:

ABCDEF

If portions were permanently delivered to the application as:

ABEFCD

the resulting file could be corrupted.

TCP prevents this type of transport-layer ordering problem.

8. TCP Flow Control

TCP also prevents a fast sender from overwhelming a slower receiver.

This mechanism is known as flow control.

The receiver advertises how much data it can currently accept through TCP's receive-window mechanism.

Conceptually:

Fast Sender
     ↓
TCP Flow Control
     ↓
Slower Receiver

The sender adjusts the amount of outstanding data accordingly.

9. TCP Congestion Control

Flow control and congestion control are related but different.

Flow control protects the receiving endpoint.

Congestion control attempts to avoid overwhelming the network path.

TCP implementations use congestion-control algorithms to determine how aggressively data should be transmitted.

Depending on operating system and implementation, algorithms may include mechanisms such as:

• Slow start
• Congestion avoidance
• Fast retransmit
• Fast recovery

Modern operating systems may use different congestion-control algorithms.

10. TCP Header

A TCP segment contains a TCP header followed by application data.

Important TCP header fields include:

• Source Port
• Destination Port
• Sequence Number
• Acknowledgement Number
• Data Offset
• Flags
• Window Size
• Checksum
• Urgent Pointer
• Options

A TCP header is normally at least 20 bytes, with additional TCP options potentially increasing its size.

11. Important TCP Flags

TCP uses several control flags.

Common ones include:

SYN

Used when establishing a connection.

ACK

Indicates acknowledgement information is valid.

FIN

Used during graceful connection termination.

RST

Immediately resets a TCP connection.

PSH

Requests prompt delivery of buffered data toward the application.

Other flags and extensions also exist.

12. TCP Connection Termination

A TCP connection should eventually be closed.

A graceful shutdown commonly involves FIN and ACK exchanges.

A simplified example:

Client                         Server

FIN ---------------------------->

    <------------------------- ACK

    <------------------------- FIN

ACK ---------------------------->

Actual TCP behavior can vary depending on which side closes first and whether both directions are closed simultaneously.

TCP can also terminate connections abruptly using RST.

13. What Is UDP?

UDP stands for User Datagram Protocol.

UDP is a connectionless transport protocol.

Unlike TCP, UDP does not establish a transport-layer connection using a three-way handshake before sending application datagrams.

Conceptually:

Sender

Datagram 1 --------> Receiver
Datagram 2 --------> Receiver
Datagram 3 --------> Receiver

The sender can transmit UDP datagrams without first establishing a TCP-style session.

This results in considerably less protocol machinery.

14. Does UDP Guarantee Delivery?

No.

UDP itself does not guarantee that a datagram will reach its destination.

A datagram may be:

• Delivered
• Lost
• Duplicated
• Delayed
• Delivered out of order

UDP does not itself provide TCP-style:

• Retransmission
• Ordered byte-stream delivery
• Connection establishment
• Flow control
• Congestion control

However, this statement needs an important qualification:

Applications and higher-level protocols running over UDP can implement any reliability mechanisms they require.

QUIC is a major modern example.

15. Why Use UDP If Delivery Is Not Guaranteed?

Because reliability is not always the only—or even the most important—requirement.

Consider a live voice conversation.

Suppose someone says:

Good morning.

If a tiny portion of audio is lost, retransmitting it 2 seconds later may be useless. The conversation has already moved forward.

For real-time applications, fresh data can be more useful than late data.

This makes UDP attractive for applications where low latency is critical.

Examples can include:

• VoIP
• Real-time audio
• Live video
• Online gaming
• DNS
• DHCP
• NTP
• Some VPN implementations
• Real-time telemetry

16. UDP Header

UDP has a much simpler header than TCP.

The standard UDP header is only 8 bytes.

It contains four fields:

Source Port
Destination Port
Length
Checksum

Each field is 16 bits.

This simplicity contributes to UDP's low protocol overhead.

17. TCP vs UDP Header Size

At their minimum standard header sizes:

TCP Header: 20 bytes minimum
UDP Header: 8 bytes

TCP headers may be larger because of TCP options.

Therefore, UDP normally has lower transport-layer header overhead.

But header size alone should not be used to decide which protocol is "faster." Application design, congestion control, connection setup, network conditions, encryption and loss recovery can matter much more.

18. TCP vs UDP — Major Technical Differences

Feature	TCP	UDP
Full Name	Transmission Control Protocol	User Datagram Protocol
Transport Type	Connection-oriented	Connectionless
Reliability	Built in	Not built in
Ordering	Built in	Not guaranteed
Retransmission	Built in	Not built in
Acknowledgement	Yes	No TCP-style ACK
Flow Control	Yes	No
Congestion Control	Yes	No built-in UDP mechanism
Handshake	Yes	No
Minimum Header	20 bytes	8 bytes
Data Model	Byte stream	Datagrams/messages
Protocol Overhead	Higher	Lower
Typical Latency Goal	Reliable transport	Low overhead/latency
Typical Uses	Web, email, SSH, FTP	DNS, voice, games, streaming
Broadcast/Multicast	Not inherently	Can support
Connection State	Maintained	Minimal transport state

19. TCP Does Not Preserve Application Message Boundaries

This is an important programming concept.

TCP is a byte-stream protocol.

Suppose an application performs three writes:

HELLO
WORLD
TEST

The receiving application should not assume that three corresponding reads will return exactly those three chunks.

It may receive something conceptually like:

HELLOWORLDTEST

or different divisions of the same stream.

Applications using TCP therefore need their own message-framing method, such as:

• Fixed-length messages
• Length prefixes
• Delimiters
• Structured application protocols

UDP behaves differently because it preserves datagram boundaries.

20. UDP Is Datagram-Oriented

If an application sends one UDP datagram, the receiver processes it as a datagram rather than as part of one continuous byte stream.

Conceptually:

Datagram A
Datagram B
Datagram C

This characteristic can simplify some real-time and request/response application designs.

21. What Are TCP and UDP Ports?

Both TCP and UDP use port numbers.

A port helps the operating system identify which application or service should receive incoming transport traffic.

For example:

Server IP:
192.168.1.100

The same server might simultaneously provide several services.

192.168.1.100:443
192.168.1.100:22
192.168.1.100:53

The IP address identifies the host/interface context, while the transport port helps identify the service endpoint.

22. Port Number Range

TCP and UDP port numbers are 16-bit values:

0 – 65535

IANA conventionally divides them into:

0–1023
Well-Known/System Ports

1024–49151
Registered/User Ports

49152–65535
Dynamic/Private Ports

Client systems frequently use temporary ephemeral ports when initiating connections or requests.

23. TCP Port and UDP Port Are Different Namespaces

An important point:

TCP port 53 and UDP port 53 are not the same transport endpoint.

A service may listen on:

TCP 53

and separately on:

UDP 53

Firewalls therefore frequently ask whether a rule should permit:

TCP
UDP
or Both

The protocol matters in addition to the port number.

24. Common TCP Ports

Examples include:

Service	Common Port	Transport
FTP Control	21	TCP
SSH	22	TCP
Telnet	23	TCP
SMTP	25	TCP
HTTP	80	TCP
POP3	110	TCP
IMAP	143	TCP
HTTPS	443	TCP traditionally
SMB	445	TCP
RDP	3389	TCP and UDP supported

Exact application behavior should always be checked rather than assuming a service uses only one protocol.

25. Common UDP Ports

Examples include:

Service	Common Port	Transport
DNS	53	UDP commonly; TCP also used
DHCP Server	67	UDP
DHCP Client	68	UDP
TFTP	69	UDP
NTP	123	UDP
SNMP	161	UDP
SNMP Trap	162	UDP

26. DNS Uses Both UDP and TCP

It is incorrect to say simply:

DNS uses UDP.

DNS commonly uses UDP for ordinary queries because of its efficiency.

However, DNS also supports TCP and may use it when appropriate, including cases involving response handling, specific protocol requirements and zone transfers.

Therefore:

DNS → UDP and TCP

is more accurate.

27. HTTPS Can Also Involve UDP

Traditionally:

HTTP → TCP
HTTPS → TCP

Modern networking adds an important exception.

HTTP/3 uses QUIC, and QUIC runs over UDP.

Therefore modern HTTPS traffic can involve:

HTTP/3
   ↓
QUIC
   ↓
UDP
   ↓
IP

This is an excellent example of why saying "UDP is unreliable, therefore applications over UDP are unreliable" is misleading.

QUIC implements sophisticated reliability, encryption and congestion-control functionality above UDP.

28. TCP Example — Downloading a File

Imagine downloading a 500 MB software installer.

The file must arrive correctly.

If parts of the data are lost, they need to be recovered.

TCP is well suited because it provides:

Sequence tracking
       +
Acknowledgements
       +
Loss detection
       +
Retransmission
       +
Ordered delivery

The application ultimately receives a reliable byte stream or experiences a connection failure rather than silently accepting random missing stream bytes.

29. UDP Example — Live Video

Imagine watching a live camera stream.

A packet containing a fraction of an old video frame is lost.

Retransmitting it much later may not be useful because the viewer is already watching newer frames.

Depending on the streaming protocol, application and codec, the system may prefer to tolerate some loss and continue.

Therefore UDP can be useful for real-time media transport.

30. UDP Example — Online Gaming

In many online games, a server continuously receives information such as:

Player position
Direction
Movement
Actions
Game state updates

Suppose an older position update is lost.

By the time it could be retransmitted, a newer position may already exist.

Some game networking systems therefore favor low-latency datagram communication and implement application-specific handling for important events.

Not all game traffic uses UDP exclusively; actual architecture varies by game.

31. UDP Example — VoIP

Voice communication is time-sensitive.

A late audio packet may have little value.

VoIP systems can therefore use RTP or similar technologies over UDP.

The priority becomes:

Low delay
+
Low jitter
+
Continuous playback

rather than retransmitting every old piece of voice data.

32. TCP and Latency

TCP can introduce latency through mechanisms such as:

• Connection establishment
• Retransmissions
• Ordered delivery
• Congestion control
• Loss recovery

However, saying:

TCP is slow.

is technically oversimplified.

TCP can achieve extremely high throughput and excellent performance.

A better statement is:

TCP provides more built-in transport functionality and reliability, which can introduce additional protocol behavior and latency compared with raw UDP.

33. UDP Is Not Automatically Faster

Another misconception is:

UDP is always faster than TCP.

Not necessarily.

UDP has lower transport overhead, but application performance depends on:

• Network quality
• Application design
• Packet loss
• Latency
• Bandwidth
• Congestion
• Encryption
• Server processing
• Application-level retransmission
• Packet size
• Routing
• Protocol implementation

A poorly designed UDP application can perform worse than a well-optimized TCP application.

34. Packet Loss in TCP and UDP

Consider a network suffering 5% packet loss.

TCP

TCP will generally attempt to recover missing stream data.

This may result in:

Packet Loss
     ↓
Loss Detection
     ↓
Retransmission
     ↓
Additional Delay

UDP

UDP itself simply sends datagrams.

Datagram Lost
     ↓
UDP does not retransmit it

Whether anything happens afterward depends entirely on the application protocol.

35. TCP and Head-of-Line Blocking

TCP provides an ordered byte stream.

Suppose later data arrives while an earlier part of the stream is missing.

TCP generally cannot deliver later stream bytes past the missing gap as though nothing happened.

It must recover the missing portion.

This can cause head-of-line blocking at the TCP stream level.

Modern protocols such as QUIC were partly designed to improve transport behavior for modern multiplexed applications.

36. TCP Checksum and UDP Checksum

Both protocols contain checksum mechanisms used to detect corruption.

The checksum helps determine whether transport data was damaged during transmission.

It is important to understand that a checksum is primarily an error-detection mechanism.

It is not encryption.

A checksum does not make traffic confidential.

37. TCP/UDP and Encryption

Neither basic TCP nor basic UDP inherently means:

Encrypted

or:

Secure

Encryption normally comes from higher-level technologies.

For example:

HTTPS
   ↓
TLS
   ↓
TCP

or:

HTTP/3
   ↓
QUIC with TLS-based security
   ↓
UDP

Therefore:

TCP does not automatically mean secure.

UDP does not automatically mean insecure.

Security depends on the complete protocol stack and application design.

38. TCP/UDP and Firewalls

Firewalls commonly create rules based on:

Source IP
Destination IP
Source Port
Destination Port
Transport Protocol
Direction
Connection State

A firewall rule might allow:

TCP
Destination Port 443

but block:

UDP
Destination Port 443

This could allow traditional HTTPS over TCP while potentially interfering with HTTP/3/QUIC traffic, depending on the environment and browser behavior.

39. Stateful Firewall Behavior

TCP connections are relatively easy for a stateful firewall to track because TCP contains explicit connection states and flags.

For example:

SYN
SYN-ACK
ACK
ESTABLISHED
FIN

UDP has no equivalent connection establishment.

However, stateful firewalls and NAT devices commonly create temporary pseudo-state/session mappings for UDP traffic.

These mappings generally expire after an inactivity timeout.

40. TCP/UDP and NAT

NAT devices must keep track of communication flows.

A TCP flow can conceptually be identified using values such as:

Source IP
Source Port
Destination IP
Destination Port
Protocol

For example:

192.168.1.50:51000
        ↓
TCP
        ↓
142.x.x.x:443

UDP NAT mappings are also maintained, but because UDP has no TCP-style connection closing process, timeout behavior becomes especially important.

41. What Is a Socket?

In software development, applications commonly communicate through sockets.

A TCP server might create:

TCP Socket
↓
Bind
↓
Listen
↓
Accept
↓
Send/Receive

A UDP server generally follows a simpler model:

UDP Socket
↓
Bind
↓
Receive Datagram
↓
Send Datagram

Exact APIs vary by operating system and programming language.

42. TCP Communication Example

Consider a web client connecting from:

192.168.1.25

using temporary source port:

53001

to a server:

203.0.113.20

on HTTPS port:

443

The flow could be represented as:

192.168.1.25:53001
        ↓
      TCP
        ↓
203.0.113.20:443

A connection is uniquely distinguished using endpoint information including IP addresses, ports and protocol.

43. UDP Communication Example

A DNS query might conceptually look like:

192.168.1.25:54000
        ↓
      UDP
        ↓
DNS Server:53

The DNS server responds to the client's source port.

There is no TCP three-way handshake for the normal UDP exchange.

44. TCP and UDP in CCTV/IP Camera Systems

Both protocols can appear in CCTV environments.

An IP camera system may use different protocols for different purposes:

HTTP/HTTPS → Configuration
RTSP → Stream control
RTP → Media transport
TCP/UDP → Transport mechanisms
ONVIF → Device discovery/control functions

Depending on camera, NVR/DVR and software configuration, video may be transported using TCP or UDP.

TCP Streaming

Potential advantages:

• Better tolerance of packet loss through retransmission
• Useful on unstable networks when complete ordered transport matters

Potential disadvantage:

• Retransmission can increase latency

UDP Streaming

Potential advantages:

• Lower latency
• Suitable for real-time viewing

Potential disadvantage:

• Lost datagrams may translate into visible artifacts or missing media data unless compensated for elsewhere.

45. TCP and UDP in Remote Desktop

Microsoft RDP can use both TCP and UDP in modern implementations.

TCP provides reliable communication.

UDP can improve responsiveness for suitable types of interactive traffic and network conditions.

This illustrates an important principle:

Modern applications do not always choose TCP OR UDP. They may use both.

46. TCP and UDP in VPNs

VPN technologies may use TCP, UDP or other IP protocols depending on the VPN.

For real-time tunneling, UDP is frequently attractive because it avoids placing one TCP reliability system directly inside another TCP transport layer.

Running TCP-based application traffic inside a TCP-based VPN tunnel can sometimes create inefficient interactions during packet loss—a situation commonly discussed as TCP-over-TCP performance problems.

This is one reason many VPN implementations prefer UDP transport where practical.

47. How to Check TCP Connections in Windows

Windows provides several useful tools.

Netstat

netstat -ano

This can display active connections, listening ports and associated process IDs.

To display TCP information:

netstat -ano -p tcp

For UDP:

netstat -ano -p udp

UDP output looks different because UDP does not have TCP-style connection states.

48. TCP States in Windows

When examining TCP connections, you may encounter states such as:

LISTENING
ESTABLISHED
SYN_SENT
SYN_RECEIVED
FIN_WAIT_1
FIN_WAIT_2
CLOSE_WAIT
CLOSING
LAST_ACK
TIME_WAIT

These states reflect different stages of TCP's connection lifecycle.

For example:

LISTENING means a server application is waiting for incoming TCP connections.

ESTABLISHED means a TCP connection is active.

TIME_WAIT is a normal TCP state associated with recently closed connections and helps prevent delayed segments from an old connection being confused with a newer one.

49. PowerShell TCP Troubleshooting

Windows PowerShell can provide detailed TCP information.

For example:

Get-NetTCPConnection

You can also inspect UDP endpoints:

Get-NetUDPEndpoint

To test whether a remote TCP port is reachable:

Test-NetConnection server.example.com -Port 443

This is especially useful when diagnosing:

• Firewall problems
• Server listening issues
• Port forwarding
• Remote access
• Application connectivity

50. Why Ping Cannot Test TCP or UDP Ports

A common networking mistake is assuming:

Ping successful = application port working

Ping normally uses ICMP, not TCP or UDP.

Therefore:

Ping Successful

does not prove:

TCP 443 Working

and it does not prove:

UDP 53 Working

A server can respond to ping while an application port is blocked.

Likewise, a server can block ping while TCP services continue working normally.

51. TCP vs UDP and Port Forwarding

Routers often require a protocol when creating a port-forwarding rule.

For example:

External Port: 5000
Internal IP: 192.168.1.100
Internal Port: 5000
Protocol: TCP

If the application actually uses UDP, a TCP-only forwarding rule will not solve the problem.

Some routers therefore provide options:

TCP
UDP
TCP/UDP
Both

Always determine which protocol the application actually requires instead of selecting "Both" automatically.

52. TCP vs UDP for Software Developers

When designing an application, TCP is often appropriate when:

• Every byte matters
• Correct ordering matters
• Reliable delivery is required
• File integrity matters
• Application complexity should be reduced by relying on transport reliability

UDP may be appropriate when:

• Low latency is critical
• Some packet loss is tolerable
• The application needs datagram semantics
• Broadcast or multicast is required
• The application implements its own reliability
• Real-time information quickly becomes obsolete

53. Should You Choose TCP or UDP?

The decision should not simply be:

TCP = Good
UDP = Bad

or:

UDP = Fast
TCP = Slow

Instead ask:

Does every piece of data need to arrive?

If yes, TCP or a reliable protocol built above UDP may be appropriate.

Does order matter?

If yes, the protocol must provide ordering where required.

Is low latency more important than recovering old data?

UDP may be attractive.

Does the application need multicast/broadcast?

UDP is generally more suitable.

Is application complexity important?

TCP already provides substantial reliability machinery.

54. TCP vs UDP — Real-World Decision Table

Requirement	Likely Choice
File transfer	TCP
Traditional web browsing	TCP
HTTP/3	UDP through QUIC
Email	TCP
SSH	TCP
DNS query	Usually UDP
DNS zone transfer	TCP
DHCP	UDP
Live voice	Often UDP
Real-time gaming	Often UDP
Network time	UDP
Database communication	Commonly TCP
Remote administration	Commonly TCP
Real-time camera stream	TCP or UDP
VPN	Depends on protocol

55. Common Misconceptions About TCP and UDP

Misconception 1: UDP packets always arrive faster.

Not necessarily.

UDP has lower protocol overhead, but total application performance depends on the complete network and application design.

Misconception 2: UDP is bad because it is unreliable.

Incorrect.

UDP intentionally provides a minimal datagram transport service. Reliability can be unnecessary or implemented at another layer.

Misconception 3: TCP never loses packets.

IP packets carrying TCP segments can absolutely be lost.

TCP's advantage is that it detects and recovers from loss according to its algorithms.

Misconception 4: TCP is secure.

TCP itself does not provide application-data confidentiality.

Misconception 5: UDP cannot provide reliable applications.

Protocols built over UDP can implement reliability.

QUIC proves this clearly.

Misconception 6: A port number tells you the protocol.

No.

You must specify:

IP Protocol + Port

For example:

TCP/53
UDP/53

are distinct.

56. TCP and UDP Performance Troubleshooting

When troubleshooting TCP, investigate:

• Packet loss
• Retransmissions
• Round-trip time
• TCP resets
• Window sizes
• Congestion
• MTU/MSS issues
• Firewall state
• Server listening state
• NAT
• DNS
• Application timeout

When troubleshooting UDP, investigate:

• Packet loss
• Jitter
• Latency
• Firewall rules
• NAT timeout
• MTU/fragmentation
• Application-level responses
• Port forwarding
• QoS
• Bandwidth congestion

Packet-analysis tools such as Wireshark are extremely useful for investigating both protocols.

57. TCP vs UDP Packet Capture

In Wireshark, display filters can be used such as:

tcp

or:

udp

A TCP handshake can often be recognized as:

SYN
SYN, ACK
ACK

UDP traffic does not show an equivalent transport handshake.

Packet capture is one of the best ways to understand how TCP and UDP actually behave on a real network.

58. Technical Summary

TCP and UDP are two foundational transport protocols of IP networking.

TCP provides:

Connection establishment
Reliable byte stream
Sequencing
Acknowledgements
Retransmission
Flow control
Congestion control
Ordered delivery

UDP provides:

Connectionless datagrams
Small header
Low protocol overhead
No built-in retransmission
No built-in ordering
No built-in flow control
No built-in congestion control

Neither protocol is universally better.

They solve different networking problems.

A useful way to remember their fundamental philosophies is:

TCP:
"Maintain a reliable ordered conversation."

UDP:
"Send this datagram with minimal transport machinery."

Modern networking further demonstrates that this distinction does not mean applications over UDP must be unreliable. Protocols such as QUIC can build sophisticated reliable and secure communication over UDP.

Understanding these differences is critical when configuring firewalls, port forwarding, VPNs, CCTV systems, DNS, web servers, remote desktops, cloud applications and custom network software.

Frequently Asked Questions (FAQ)

1. What is TCP?

TCP stands for Transmission Control Protocol. It is a connection-oriented transport protocol that provides reliable and ordered byte-stream communication.

2. What is UDP?

UDP stands for User Datagram Protocol. It is a connectionless transport protocol designed to send independent datagrams with minimal transport overhead.

3. What is the biggest difference between TCP and UDP?

TCP provides built-in reliability, ordering and retransmission. UDP does not provide these features itself.

4. Is TCP faster than UDP?

There is no universal answer. UDP has lower transport overhead, but actual application performance depends on network conditions and protocol design.

5. Is UDP faster than TCP?

UDP can reduce connection and transport overhead, which makes it attractive for low-latency applications, but it is not automatically faster in every application.

6. Does TCP guarantee delivery?

TCP attempts reliable delivery and retransmission while the connection remains viable. If communication becomes impossible, the connection eventually fails rather than providing an absolute physical guarantee that communication can always succeed.

7. Does UDP guarantee delivery?

No. UDP itself provides no delivery guarantee.

8. Does TCP guarantee packet order?

TCP presents an ordered byte stream to the application, even when underlying IP packets arrive out of order.

9. Does UDP preserve order?

UDP does not guarantee datagram ordering.

10. What happens when a TCP packet is lost?

TCP's loss-recovery mechanisms generally cause missing data to be retransmitted.

11. What happens when a UDP datagram is lost?

UDP itself takes no recovery action. The application decides whether recovery is necessary.

12. What is the TCP three-way handshake?

It is the connection-establishment sequence:

SYN
SYN-ACK
ACK

13. Does UDP have a handshake?

No TCP-style transport handshake is required before UDP datagrams can be sent.

14. What is the minimum TCP header size?

Normally 20 bytes.

15. What is the UDP header size?

8 bytes.

16. Does HTTPS use TCP or UDP?

Traditional HTTP/1.1 and HTTP/2 HTTPS connections normally use TCP. HTTP/3 uses QUIC over UDP.

17. Does DNS use TCP or UDP?

DNS uses both. Ordinary queries commonly use UDP, while TCP is used in various situations including zone transfers and when required by the DNS exchange.

18. Does RDP use TCP or UDP?

Modern Microsoft RDP implementations can use both TCP and UDP.

19. Does video streaming use TCP or UDP?

Both are possible depending on the streaming technology, application and delivery method.

20. Which protocol is better for CCTV?

It depends on the network and application. TCP can provide reliable ordered transport, while UDP may provide lower-latency real-time delivery.

21. Which is better for online games?

Many real-time games use UDP for time-sensitive state information, but actual implementations can use TCP, UDP or both.

22. Which protocol is better for file transfer?

TCP is commonly preferred because file data must arrive reliably and in the correct order.

23. Can TCP packets be lost?

Yes. Network packets carrying TCP segments can be lost. TCP then uses loss-recovery mechanisms.

24. Is UDP insecure?

Not inherently. UDP itself does not provide encryption, but neither does basic TCP. Security depends on higher-level protocols.

25. Is TCP encrypted?

No. TCP by itself does not encrypt application data.

26. Can UDP traffic be encrypted?

Yes. Protocols operating over UDP can provide encryption. QUIC is a major example.

27. Why does a firewall ask TCP or UDP?

Because TCP and UDP are different transport protocols with separate port namespaces. A TCP rule does not automatically permit UDP traffic on the same port.

28. Can TCP and UDP use the same port number?

Yes. TCP port 53 and UDP port 53, for example, are separate transport endpoints.

29. How many TCP/UDP ports exist?

Port numbers range from 0 through 65535 for each protocol.

30. What are ephemeral ports?

They are temporary ports commonly assigned to clients when initiating network communication.

31. Why is UDP used for VoIP?

Because real-time voice often benefits more from low latency than from retransmitting audio that has already become outdated.

32. Why is TCP used for email?

Email transmission requires reliable delivery of the data stream, making TCP suitable.

33. Why is TCP used for SSH?

SSH requires reliable, ordered communication between client and server.

34. Can UDP support broadcast?

Yes. UDP is commonly used for broadcast-based networking applications where the underlying network supports it.

35. Can UDP support multicast?

Yes. UDP is commonly used with IP multicast.

36. Does TCP support multicast?

TCP's connection-oriented unicast model is not designed for normal IP multicast communication.

37. What is TCP TIME_WAIT?

TIME_WAIT is a normal state after certain TCP connection closures that helps prevent delayed packets from an old connection interfering with a newer connection using the same endpoint combination.

38. What is TCP RST?

RST means reset and is used to terminate or reject a TCP connection immediately.

39. What is TCP FIN?

FIN indicates that one side has finished sending data in that direction and is involved in graceful TCP connection shutdown.

40. Can ping test a TCP port?

No. Standard ping uses ICMP rather than TCP.

41. Can a server respond to ping while TCP is blocked?

Yes.

42. Can a website work when ping is blocked?

Yes. A firewall can block ICMP echo while allowing HTTPS traffic.

43. What tool can check TCP connections in Windows?

You can use:

netstat -ano

or PowerShell:

Get-NetTCPConnection

44. How can I check UDP endpoints in Windows?

PowerShell provides:

Get-NetUDPEndpoint

45. How can I test TCP port 443?

In Windows PowerShell:

Test-NetConnection example.com -Port 443

46. Does UDP have an ESTABLISHED state?

No. UDP does not have TCP-style connection states such as ESTABLISHED.

47. Why can UDP have NAT problems?

NAT devices maintain temporary UDP mappings, and these can expire because UDP has no TCP-style connection lifecycle.

48. What is QUIC?

QUIC is a modern transport protocol that runs over UDP and provides features including reliability, congestion control, multiplexed streams and integrated cryptographic security.

49. Why does HTTP/3 use UDP?

HTTP/3 uses QUIC over UDP to obtain modern transport capabilities without being constrained by TCP's stream-level behavior and operating-system TCP implementations.

50. Which should I use when developing software?

Choose based on application requirements. Use TCP when reliable ordered byte-stream delivery is desired. Consider UDP when low latency, datagram semantics, multicast/broadcast, or custom transport behavior is important.

#Tags

#TCP #UDP #TCPvsUDP #TransmissionControlProtocol #UserDatagramProtocol #Networking #ComputerNetworking #NetworkProtocol #TCPIP #TransportLayer #OSIModel #Layer4 #TCPProtocol #UDPProtocol #TCPHandshake #ThreeWayHandshake #NetworkSecurity #NetworkEngineering #NetworkAdministrator #ITSupport #ITEngineer #TCPPorts #UDPPorts #PortNumbers #PacketLoss #NetworkLatency #NetworkPerformance #TCPHeader #UDPHeader #TCPConnection #NetworkTroubleshooting #Wireshark #Firewall #PortForwarding #NAT #DNS #HTTP #HTTPS #HTTP3 #QUIC #VoIP #OnlineGaming #VideoStreaming #CCTV #IPCamera #RDP #VPN #SocketProgramming #NetworkBasics #CyberSecurity