TCP/IP is a suite of networking protocols that defines how data is addressed, routed, and reliably delivered across interconnected networks. The name combines two of its core protocols: the Internet Protocol (IP), which handles addressing and packet routing, and the Transmission Control Protocol (TCP), which provides ordered, reliable, connection-oriented byte-stream delivery on top of IP.
In practice
In embedded systems, a TCP/IP stack is typically required when a device communicates over Ethernet, Wi-Fi, or cellular (LTE/NB-IoT) networks -- for example, IoT sensors posting data to a cloud endpoint, industrial controllers using Modbus TCP, or embedded web servers serving a configuration UI. On higher-end parts (Cortex-A SoCs running Linux, for instance), the host OS provides a full-featured TCP/IP stack. On bare-metal or RTOS-based Cortex-M devices, a lightweight third-party stack is usually integrated instead -- common choices include lwIP, uIP, and picoTCP. The EmbeddedRelated post "Interfacing LINUX with microcontrollers" discusses bridging the gap between Linux-hosted networking and smaller MCU targets.
The suite covers more than just TCP and IP. UDP (connectionless, lower overhead) and ICMP (diagnostics, ping) are core suite protocols; DNS (name resolution) and DHCP (address assignment) are application-layer protocols commonly used alongside the suite; and TLS (transport security), while not part of the TCP/IP suite itself, is a near-universal addition in practical deployments. Many embedded TCP/IP deployments use UDP rather than TCP for latency-sensitive or resource-constrained cases where dropped packets are acceptable or handled at the application layer.
A key practical consideration is memory footprint. A minimal lwIP configuration can fit in a few kilobytes of RAM, but a full-featured stack with TLS, a BSD socket API, and multiple simultaneous connections can demand tens to hundreds of kilobytes. Stack selection and configuration require careful budgeting on MCUs with limited SRAM. The post "Designing Communication Protocols, Practical Aspects" covers tradeoffs relevant to choosing and layering protocols in embedded designs.
TCP presents specific pitfalls for embedded targets: the Nagle algorithm can introduce unexpected latency for small writes; the TIME_WAIT state holds socket resources after a connection closes; and a remote host silently disappearing (power loss, network failure) may not be detected without TCP keepalives or an application-layer heartbeat. These issues are manageable but frequently surprise developers coming from desktop networking backgrounds.
Frequently asked
Do I need a full TCP/IP stack, or can I use a simpler alternative?
It depends on the transport and application protocol. If the device communicates over
Ethernet or Wi-Fi using standard internet protocols (HTTP,
MQTT,
CoAP over
UDP, etc.), a TCP/IP
stack is required. For purely local wired links between two MCUs, lighter-weight framing protocols over
UART or
SPI are often sufficient -- no IP needed. The post 'Designing Communication Protocols, Practical Aspects' discusses how to evaluate these tradeoffs.
What lightweight TCP/IP stacks are commonly used on bare-metal or RTOS-based MCUs?
lwIP is the most widely used option on Cortex-M class devices and is supported out of the box by STM32 (via STM32Cube), NXP (via MCUXpresso SDK), and others. uIP targets highly constrained devices and is commonly associated with small 8-bit and 16-bit MCUs, though it is not limited exclusively to those. picoTCP and
FreeRTOS-Plus-TCP are also used in RTOS environments. Each makes different tradeoffs in footprint, features, and API compatibility with BSD sockets.
What is the difference between TCP and UDP, and when should I use each in an embedded design?
TCP is connection-oriented and guarantees ordered, reliable delivery at the cost of higher overhead, connection state, and retransmission delays.
UDP is connectionless and adds almost no overhead beyond IP, but delivers no guarantees. For embedded use: TCP suits command/response protocols, firmware updates over the network, and web servers where reliability matters. UDP suits telemetry streams, real-time sensor data, and protocols like
CoAP or SNTP that handle reliability at the application layer or can tolerate loss.
How does a TCP/IP stack relate to a network driver and the physical layer?
The
stack operates above the hardware. At the bottom sits a MAC/PHY driver (for
Ethernet) or a Wi-Fi or cellular modem driver. The driver passes raw Ethernet frames up to the stack's network interface layer, and the stack handles IP routing, TCP/
UDP session management, and the socket API above that. On many STM32 Ethernet-capable parts, ST's HAL provides the MAC driver and lwIP plugs in above it via a netif abstraction.
What is a common cause of TCP connections silently 'hanging' on an embedded target?
TCP has no built-in mechanism to detect that a remote peer has disappeared without sending a FIN or RST (for example, due to a power failure or network partition). Without TCP keepalives enabled, or an application-layer heartbeat, the local socket can remain open indefinitely waiting for data that will never arrive. On embedded targets with a limited number of sockets, this quickly exhausts resources. Enabling TCP keepalives (SO_KEEPALIVE with tuned intervals) or implementing an application-level ping/timeout is the standard remedy.
Differentiators vs similar concepts
TCP/IP is sometimes used loosely to mean the entire internet protocol suite, though it more specifically refers to the suite centered on TCP and IP. The two protocols differ in role: IP handles addressing and best-effort packet delivery (IPv4 or IPv6), while TCP adds reliability, ordering, and flow control on top of IP.
UDP is a separate transport-layer protocol in the same suite -- connectionless and lower-overhead -- and is frequently used in embedded applications alongside or instead of TCP. TCP/IP should not be confused with physical-layer or link-layer standards (
Ethernet, Wi-Fi,
PPP): those operate below IP and carry IP packets as their payload.
