TCP and UDP in Automotive Ethernet: How to Choose for Diagnostics, Service Communication, and Network Management

Automotive Ethernet is penetrating from high-end models to mainstream platforms. With the advancement of domain-centralized architectures and central computing architectures, in-vehicle communication is no longer just the domain of CAN bus. Ethernet carries more and more services—DoIP diagnostics, SOME/IP service communication, and UdpNM network management all run on top of transport layer protocols.

The two core transport layer protocols, TCP and UDP, determine whether these services can run stably. Many engineers, when designing automotive networks, understand these two protocols only at the level of "TCP is reliable, UDP is fast." But when it comes to port planning, connection management, and retransmission strategies, more detailed judgment is often required.

The Role of the Transport Layer: Process-to-Process Delivery

The network layer's IP protocol is responsible for delivering data to the target host, but a host runs dozens or hundreds of processes. What actually needs to communicate are processes, not hosts. The transport layer solves exactly this problem: delivering data to specific application processes.

Process identification relies on port numbers—16 bits, ranging from 0 to 65535. This range is divided into three segments: 0 to 1023 are well-known ports, uniformly allocated by IANA and not to be occupied in system design; 1024 to 49151 are registered ports, requiring IANA registration to prevent duplication. In automotive scenarios, DoIP uses port 13400 and SOME/IP SD uses port 30490, both in this range; 49152 to 65535 are dynamic ports, freely used by clients.

In vehicle architecture design, the dynamic port range needs segmented planning by domain. For example, the autonomous driving domain and the smart cockpit domain each get a segment, avoiding port allocation conflicts between different domains' applications. This issue is easily overlooked in the early stages of a project, and only discovered when multiple domains are integrated—rework costs are high.

The endpoint of transport layer communication is called a socket, composed of an IP address plus a port number. A connection is uniquely identified by a five-tuple: source IP, destination IP, source port, destination port, and protocol. This five-tuple is fundamental in automotive Ethernet packet capture analysis—when you see abnormal traffic, the first step is confirming whether the five-tuple matches expectations.

TCP: How Reliability Is Achieved

TCP is byte-stream oriented, with every byte numbered. The sequence number is the number of the first data byte in the current segment, and the acknowledgment number is the next byte sequence number expected to be received. This design determines that TCP's acknowledgment mechanism is cumulative acknowledgment, not individual acknowledgment.

The first 20 bytes of the TCP header are fixed, with options variable up to 40 bytes, so the header length ranges from 20 to 60 bytes. Several fields directly determine the approach to packet capture analysis: the data offset field takes values from 5 to 15, in units of 4 bytes, corresponding to a header of 20 to 60 bytes; among the six control bits, SYN establishes connections, FIN releases them, ACK acknowledges, RST resets connections, PSH immediately delivers to the application, and URG marks urgent data; the window size tells the sender how much data the receiver can still accept—this is the basis for flow control.

The checksum's coverage, in addition to the header and data, requires prepending a 12-byte pseudo-header including source IP, destination IP, protocol number, and length. This design verifies whether data has been delivered to the wrong host.

Among the option fields, MSS (Maximum Segment Size) is a key parameter negotiated by both parties during connection establishment. Ethernet MTU is 1500 bytes; subtracting the 20-byte IP header and 20-byte TCP header leaves a maximum MSS of 1460. If MSS is set too small, network utilization is low; if too large, it causes IP layer fragmentation—both situations affect the real-time performance of automotive networks. The window scaling option solves the problem that a 16-bit window can only reach 64KB maximum. In networks with high latency-bandwidth products, a 64KB window is far from sufficient; the shift factor can be up to 14, expanding the window to 2 to the 30th power minus 1. The timestamp option is used to calculate RTT and prevent sequence number wraparound, while SACK selective acknowledgment lets the receiver notify the sender to retransmit only the missing portion when receiving discontinuous bytes, rather than retransmitting the entire window.

The Practical Impact of Connection Establishment and Release

TCP connection establishment requires a three-way handshake, and release requires a four-way handshake. During the handshake, the ACK number is always the other party's sequence number plus 1. SYN and FIN each occupy one sequence number, so the client's final ACK must wait 2MSL before the connection is truly closed.

In automotive scenarios, the direct impact of this mechanism is: when a diagnostic device establishes a DoIP connection with a vehicle, sufficient connection establishment time must be reserved. If an ECU attempts to establish a TCP connection during startup while the network stack is not yet fully initialized, handshake failure will delay diagnostic session establishment. Many OEM diagnostic specifications explicitly require that ECUs wait a period of time after power-up before allowing diagnostic connections—this is the reason.

The four-way handshake also requires attention. The active closer must wait 2MSL after sending the final ACK before releasing the connection. If a vehicle frequently establishes and disconnects connections during diagnostics, this waiting time accumulates, affecting diagnostic efficiency. This is why DoIP diagnostics generally recommend maintaining long connections rather than re-establishing connections for each operation.

The Reliability Trio: Retransmission, Flow Control, Congestion Control

TCP's reliable transmission equals ACK acknowledgment plus retransmission—this mechanism is called ARQ (Automatic Repeat reQuest).

For timeout retransmission (RTO), each segment has a timer; if unacknowledged on timeout, it is retransmitted. RTO must be dynamically calculated—set too long and the link idles; set too short and unnecessary retransmissions occur. The formula given by RFC 2988 is RTO equals the weighted average round-trip time plus 4 times the deviation. In automotive Ethernet, RTT is usually very small, and RTO settings need to be adjusted based on measured data from the specific link, not directly applying public network defaults.

Fast retransmission solves the problem of excessively long timeout waits. The receiver immediately sends an ACK indicating the missing number upon receiving out-of-order segments. The sender, upon receiving 3 consecutive duplicate ACKs, determines packet loss and retransmits immediately without waiting for timeout. This mechanism is especially important when flashing large blocks of data during automotive diagnostics—if retransmission waits for RTO timeout, flashing time is noticeably extended.

Flow control solves the problem of the sender being too fast for the receiver to keep up. TCP uses a sliding window to keep the sender from exceeding the receiver's processing capability. The send buffer is divided into four segments: sent and acknowledged, sent but unacknowledged, sendable, and not sendable. If the sequence numbers within the window are exhausted without receiving acknowledgment, transmission must stop.

Congestion control solves a global problem. Flow control is an end-to-end matter; congestion control is a network-wide matter. The core idea: if there's no congestion, increase the congestion window; if there is, decrease it. During slow start, the window grows exponentially from a small value, transitioning to congestion avoidance after reaching the slow start threshold, where the window grows linearly. Once timeout occurs, the threshold drops to half its current value, and the window restarts slow start. Upon receiving 3 duplicate ACKs, fast retransmission and fast recovery are triggered—no need to return to slow start, only halving the threshold.

Automotive networks have fixed topologies and controllable link quality, so the aggressiveness of congestion control can be appropriately adjusted. For example, in a closed in-vehicle network, the initial slow start window can be set larger than public networks, reducing wait time during connection establishment.

UDP: The Value of the Minimalist Route in Automotive Scenarios

UDP adds only two things on top of IP: port multiplexing/demultiplexing and error detection. Four characteristics: connectionless, best-effort delivery, message-oriented, and no congestion control. The header is only 8 bytes, with four fields each occupying 2 bytes.

In automotive scenarios, UDP's value is not in being "fast" but in being "appropriate." SOME/IP SD service discovery uses UDP port 30490 because service discovery is periodic broadcast or multicast—losing one or two packets doesn't affect overall functionality, and the next cycle will resend. UdpNM network management also uses UDP because network management messages are sent periodically, and occasional packet loss won't cause network state judgment errors.

Conversely, if these scenarios were forced to use TCP, every message would require connection establishment, acknowledgment, and retransmission—the real-time performance of network management messages would actually decrease. Using the wrong protocol is more troublesome than using no protocol.

How to Choose in Automotive Scenarios: Several Practical Judgment Dimensions

Look at whether the service requires reliable delivery. DoIP diagnostic flashing of large data blocks—losing a single byte could cause flashing failure, so TCP must be used. Periodic network management messages—losing one or two packets doesn't affect functionality, so UDP is more appropriate.

Look at whether the communication mode is one-to-one or one-to-many. TCP only supports one-to-one; UDP supports one-to-many and multicast. SOME/IP SD service discovery requires multicast, making UDP the necessary choice.

Look at real-time requirements. UDP has no congestion control and sends immediately, offering better real-time performance. But this also means UDP requires the application layer to do its own flow control, otherwise it may overwhelm the receiver.

Look at header overhead. TCP header is 20 to 60 bytes, UDP header is 8 bytes. In bandwidth-constrained automotive environments, the difference in header overhead accumulates into considerable bandwidth consumption in scenarios with many small messages.

Automotive Ethernet design is essentially a trade-off between reliability and real-time performance. TCP guarantees reliability at the cost of latency and overhead; UDP guarantees real-time performance at the cost of requiring the application layer to provide reliability guarantees. Understanding this, selection is no longer a question of "which is better" but "which is more appropriate."