Coursify

TCP Header, Checksum Verification, and UDP-to-TCP Mismatch Reasoning

TCP Header, Checksum Verification, and UDP-to-TCP Mismatch Reasoning

Verified Sources
Nov 1, 2026

A TCP segment starts with a fixed 20-byte header (plus optional Options). The checksum is a 16-bit keywordones’-complement checksum that protects the TCP header and the TCP payload against corruption, and also includes a conceptual keywordpseudo-header to detect misrouting. 2

The problem gives a UDP “checksum” value and then asks what happens in a host that “adds the 16-bit words over all necessary fields excluding the checksum” and obtains a 16-bit result.

Key TCP checksum facts to use:

  • TCP checksum is computed as the 16-bit keywordones’ complement sum of 16-bit words, including a pseudo-header, with the checksum field treated as 0 during computation.
  • At the receiver, the standard check is: after recomputation over the same coverage including the received checksum field, the final result should be 0xFFFF0xFFFF (equivalently, “all ones” for one’s complement verification). This “result equals 0xFFFF0xFFFF” criterion is described in checksum verification discussions.

Also note: the host “receives a UDP segment” but is asked to apply the TCP/Internet-style checksum procedure. In real stacks, UDP and TCP use different transport pseudo-header formats and length/coverage rules, but the question explicitly instructs the receiver’s arithmetic procedure and asks the accept/reject outcome from that computed residual.

Footnotes

  1. Transmission Control Protocol (TCP) – RFC 793, header format and fields - TCP header layout and control fields. ↩

  2. RFC 9293 – TCP checksum rules (ones’ complement, pseudo-header, alignment, coverage) - Formal checksum computation/verification requirements. ↩ ↩2

  3. Implementation of the Internet Checksum (IETF materials) – validation rule - Receiver validation uses “result == 0xFFFF then checksum is valid”. ↩

Draw and describe the TCP header (fixed part)

The minimum TCP header is 20 bytes = 160 bits, organized as the fields below. The following bit layout is the canonical one per 2:

Field-by-field description (fixed header)

  • keywordSource Port (16): port number of the sender application.
  • keywordDestination Port (16): port number of the receiver application.
  • keywordSequence Number (32): identifies the first data octet carried in this segment (special handling when SYN is present). 2
  • keywordAcknowledgment Number (32): valid when ACK flag is set; indicates next sequence number expected. 2
  • keywordData Offset (4): TCP header length in 32-bit words (where payload begins). 2
  • Reserved (6): must be zero.
  • keywordFlags / control bits (6): URG, ACK, PSH, RST, SYN, FIN.
  • Window (16): advertised receive window size.
  • keywordChecksum (16): 16-bit ones’ complement checksum including pseudo-header conceptually prefixed.
  • Urgent Pointer (16): meaningful if URG flag is set.
  • Options + Padding: optional fields; padding ensures 32-bit alignment. 2

Footnotes

  1. Transmission Control Protocol (TCP) – RFC 793, header format and fields - TCP header layout and control fields. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11

  2. RFC 9293 – TCP checksum rules (ones’ complement, pseudo-header, alignment, coverage) - Formal checksum computation/verification requirements. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

Checksum check: decide whether the segment is correctly received

  1. 1
    Step 1

    The host computes a 16-bit result over the necessary words excluding the checksum and gets 00110010 0000110100110010\ 00001101 (binary). Convert that to 0x3210D0x3210D-style? Instead, keep it as the given 16-bit pattern: 00110010 0000110100110010\ 00001101 equals 0x320x0D0x32 0x0D in bytes, i.e., the 16-bit value is 0b00110010000011010b0011001000001101.

  2. 2
    Step 2

    For a correct ones’-complement checksum, the receiver’s verification result should be 0xFFFF0xFFFF (all ones) under the standard check procedure.

    Footnotes

    1. Implementation of the Internet Checksum (IETF materials) – validation rule - Receiver validation uses “result == 0xFFFF then checksum is valid”. ↩

  3. 3
    Step 3

    The computed value is 0b00110010000011010b0011001000001101, which is not 0xFFFF=11111111111111110xFFFF = 1111111111111111. Therefore the segment is considered corrupted (checksum mismatch).

  4. 4
    Step 4

    With a checksum mismatch, the receiver discards the segment and does not deliver it to the application. In TCP specifically, a corrupted segment is ignored (and no valid ACK for its data is generated based on corrupt contents). This behavior follows the general rule that checksum mismatch indicates error and the packet/segment is dropped.

    Footnotes

    1. Implementation of the Internet Checksum (IETF materials) – validation rule - Receiver validation uses “result == 0xFFFF then checksum is valid”. ↩

How to remember the checksum verdict quickly

"For Internet-style ones’-complement checksum verification, the receiver’s recomputation is expected to produce 0xFFFF0xFFFF when the segment is uncorrupted. Anything else ⇒ mismatch ⇒ discard."

Footnotes

  1. Implementation of the Internet Checksum (IETF materials) – validation rule - Receiver validation uses “result == 0xFFFF then checksum is valid”. ↩

UDP vs TCP caveat (but we follow the prompt arithmetic)

"In real networking, UDP and TCP do checksum differently (UDP has its own pseudo-header/coverage rules; TCP also uses pseudo-header and header fields). Here, the question explicitly instructs you to run the receiver’s described 16-bit-word addition and then decide based on the checksum-mismatch outcome."
2

Footnotes

  1. RFC 9293 – TCP checksum rules (ones’ complement, pseudo-header, alignment, coverage) - Formal checksum computation/verification requirements. ↩

  2. Implementation of the Internet Checksum (IETF materials) – validation rule - Receiver validation uses “result == 0xFFFF then checksum is valid”. ↩

Is the segment correctly received?

No. The receiver’s verification residual is 001100100000110100110010\\ 00001101, which is not the expected ones’-complement checksum verification value 0xFFFF=11111111111111110xFFFF = 1111111111111111. Therefore the segment is not correctly received.

What does the receiver do?

Since the computed checksum verification does not match the required validity pattern, the receiver:

  1. Treats the segment as corrupted (checksum error).
  2. Discard(s) the segment rather than delivering it to the upper layer.
  3. In TCP terms, it will not accept the data/metadata implied by the corrupted segment (so it won’t use it to advance TCP sequence/ACK processing based on this bad checksum).

This is consistent with the general Internet checksum validation rule: when the verification result is not 0xFFFF0xFFFF, the checksum is invalid and the packet/segment must be dropped.

Footnotes

  1. Implementation of the Internet Checksum (IETF materials) – validation rule - Receiver validation uses “result == 0xFFFF then checksum is valid”. ↩ ↩2

Receiver-side decision workflow

Segment received

1) Arrival

Host obtains the segment bytes for processing."

Split into 16-bit words

2) Parse + word split

Receiver prepares the checksum computation word-aligned input."

Recompute checksum residual

3) Ones’-complement recomputation

Receiver calculates the verification result using ones’-complement arithmetic."

Compare to $0xFFFF$

4) Verdict

If mismatch: discard; if match: accept."

Upper-layer outcome

5) Deliver or drop

Accepted segments are delivered; corrupted segments are dropped."

Common questions about checksum verification

Knowledge Check

Question 1 of 4
Q1Single choice

In TCP, the checksum field is computed using which arithmetic rule?

Explore Related Topics

1

Serial Throughput in UART: Bytes Sent in 15 Seconds at 9600 baud (Odd Parity, 2 Stop Bits)

2

TCP/IP vs OSI: Which Abstraction Layer Is Missing?

3

RS-232 Communication Interface: Principles, Signaling, and Neat Diagrams

Browse all research articles