The IP layer can't answer that. IP only gets data from one machine to another machine. Getting data to the right program on that machine is the transport layer's job, and it does it with two protocols you will meet in every networks exam: UDP and TCP.

The easiest way to understand how they differ is to look at their headers. A header is the small block of control information stuck to the front of your data. Whatever a protocol can do, it can only do because some field in its header makes it possible. UDP's header is tiny, so UDP does very little. TCP's header is bigger, and every extra field pays for a feature.

This post walks through both headers field by field, then works out two exam-style problems at the end.

First, ports and sockets

Think of an apartment building. The building's street address gets the courier to the right building. The flat number gets the parcel to the right family.

• The IP address is the building address. It identifies the machine.
• The port number is the flat number. It identifies the process (program) on that machine.

A port number is a 16-bit unsigned integer, so it can be anything from 0 to 65,535. Some ports are well known: 80 for HTTP, 443 for HTTPS, 53 for DNS, 22 for SSH.

Put an IP address and a port together and you get a socket address, written like 192.168.1.10:443. A socket address names one exact endpoint on the whole internet: this program, on this machine.

Notice that a client program, like your browser, does not use port 443 itself. The OS gives it a random temporary port (often above 49152), called an ephemeral port. The server is the side that sits on the well-known port and waits.

Both UDP and TCP start their headers with a source port and a destination port. That is the part they have in common. Everything after that is where they split.

Where this header lives

Before reading the fields, it helps to see where the transport header sits. Your message gets wrapped layer by layer, like a letter going into an envelope that then goes into a courier bag.

The application hands its data down. TCP or UDP sticks its header in front and the result is called a segment (TCP) or a user datagram (UDP). IP then adds its own header in front of that, and so on down the stack. The receiver peels the layers off in reverse order. By the time the transport layer sees the packet, the IP header is already gone, which is why the transport header needs its own port numbers.

The UDP header: 8 bytes and done

UDP (User Datagram Protocol) is connectionless. It does not set up a connection, does not number its packets, and does not resend anything that gets lost. It hands your data to IP and moves on. People call this "best effort" delivery.

A UDP packet is called a user datagram. Its header is always exactly 8 bytes (64 bits), split into four 16-bit fields:

How to read this diagram: each row is 32 bits (4 bytes) wide. The numbers along the top count bit positions. So the first row holds two 16-bit fields side by side.

Source port (16 bits)

The port of the program that sent the datagram. If the sender doesn't expect any reply, it is allowed to put 0 here.

Destination port (16 bits)

The port of the program that should receive it. A DNS query, for example, goes to port 53.

Length (16 bits)

The total size of the user datagram in bytes, header plus data. Since the header alone is 8 bytes, this field can never be less than 8. A datagram with no data at all has Length = 8.

A quick formula worth remembering:

Data size = Length - 8

Checksum (16 bits)

Used to detect errors. The checksum is calculated over three things: the UDP header, the data, and a 12-byte pseudo-header borrowed from the IP layer. The pseudo-header contains the source and destination IP addresses, the protocol number, and the UDP length. Including it means a datagram that reached the wrong machine will fail the check, even if its own bytes arrived intact.

In IPv4, the UDP checksum is optional. A sender that skips it fills the field with all zeros. In IPv6 it is mandatory.

The pseudo-header, field by field

The pseudo-header trips up a lot of students, so here it is drawn out:

Add those up: 4 + 4 + 1 + 1 + 2 = 12 bytes. The pseudo-header is never transmitted. The sender builds it in memory just to compute the checksum, and the receiver builds the same thing from the IP header it received. If anything differs, the checksum fails.

The protocol field is a nice detail: it means a UDP datagram can't pass as TCP, because 17 and 6 produce different checksums.

That is the entire UDP header. Two ports, a length, a checksum. No sequence numbers, no acknowledgments, no flags. This is why UDP is fast and why it can lose packets without noticing.

The TCP header: 20 to 60 bytes of bookkeeping

TCP (Transmission Control Protocol) makes very different promises. It is connection-oriented, reliable, and treats your data as a continuous stream of bytes. Before sending anything, the two sides set up a connection using the three-way handshake. After that, TCP has to:

• notice lost data and resend it,
• put bytes back in order if they arrive scrambled,
• slow down if the receiver can't keep up,
• close the connection cleanly at the end.

Each of these needs a field in the header. That is why the TCP header is at least 20 bytes and can grow to 60 bytes when options are added.

A TCP packet is called a segment. Here is its header:

The first five rows (5 × 4 = 20 bytes) are always there. The Options row is the only part that changes size.

1. Source and destination ports (16 bits each)

Same job as in UDP: which program sent this, and which program should get it.

2. Sequence number (32 bits)

TCP doesn't number packets. It numbers bytes. Every byte you send gets its own number.

When a connection starts, each side picks a random starting number called the Initial Sequence Number (ISN). The sequence number in a segment's header is the number of the first data byte inside that segment.

An example makes this clear. Say the ISN is 1000, and the sender sends three segments of 100 bytes each:

(The first data byte is ISN + 1 because the SYN at the start of the connection uses up one sequence number.)

If segment 2 arrives before segment 1, the receiver looks at the sequence numbers and puts them back in order.

3. Acknowledgment number (32 bits)

This is how the receiver says what it has received. TCP acknowledgments are cumulative. An acknowledgment number of X means:

"I've received every byte up to X - 1. Send me byte X next."

So in the table above, after receiving all three segments correctly, the receiver sends back ACK = 1301.

This field only counts when the ACK flag (below) is set to 1.

4. Data offset, also called HLEN (4 bits)

Tells the receiver how long the TCP header is, so it knows where the header ends and the data begins.

The catch, and the thing exams love: the value is counted in 4-byte words, not in bytes.

Header length in bytes = HLEN × 4

• With no options, the header is 20 bytes, so HLEN = 20 / 4 = 5 (binary 0101).
• The largest 4-bit value is 15 (binary 1111), so the biggest possible header is 15 × 4 = 60 bytes.
• That leaves 60 - 20 = 40 bytes as the most space options can ever take.

HLEN can never be less than 5. If you see HLEN = 3 in a question, that segment is invalid.

5. Reserved (6 bits)

Kept for future use and set to zero. Newer TCP versions use some of these bits for Explicit Congestion Notification (the ECE and CWR flags), but for most university syllabi you can treat this as 6 reserved bits.

6. Control flags (6 bits)

Six one-bit switches. Each one is either on (1) or off (0), and together they control the connection.

A trick for remembering the order from left to right: Unskilled Attackers Pester Real Security Folks (URG, ACK, PSH, RST, SYN, FIN).

Watching the flags in action: the three-way handshake

Flags make more sense once you see them used. This is how a client and server open a TCP connection, and what each header carries:

1. The client sends a segment with SYN = 1 and its starting sequence number, say 1000. This segment has no data.
2. The server replies with SYN = 1 and ACK = 1. It picks its own starting number (5000) and acknowledges the client with ack = 1001.
3. The client sends ACK = 1 with ack = 5001. The connection is open.

Why 1001 and not 1000? A SYN counts as one byte of sequence space even though it carries no data, so the next expected number moves up by one. Closing works the same way with FIN, and a FIN also uses up one sequence number.

7. Window size (16 bits)

This is how TCP does flow control. The receiver uses this field to say how many more bytes it currently has room for in its buffer.

Picture pouring water from a jug into a glass. A fast sender is the jug, a slow receiver is the glass. The window field is the receiver telling the sender how much space is left in the glass, so nothing spills over.

Being 16 bits, the window can go up to 65,535 bytes. That turned out to be too small for fast modern networks, so a Window Scale option was added. With scaling, the effective window can reach about 1 GB.

8. Checksum (16 bits)

Works the same way as UDP's checksum: it covers the TCP header, the data, and the 12-byte IP pseudo-header. The difference is that in TCP the checksum is always mandatory.

9. Urgent pointer (16 bits)

Only used when the URG flag is 1. Its value is added to the sequence number to find where the urgent data inside the segment ends. The classic example is pressing Ctrl + C in a remote terminal session: the interrupt should jump the queue instead of waiting behind everything else.

10. Options (0 to 40 bytes)

Extra settings, mostly agreed on during connection setup. Three you should know:

• MSS (Maximum Segment Size): the largest chunk of data a host is willing to receive in one segment, chosen so IP doesn't have to fragment it.
• Window Scaling: lets the window grow past 65,535 bytes, as described above.
• SACK (Selective Acknowledgment): lets the receiver say "I got bytes 1 to 100 and 201 to 300, but not 101 to 200," so the sender only resends the missing piece instead of everything after it.

UDP vs TCP side by side

A good way to remember which apps use which: in a video call, a frame that shows up late is useless, so it's better to drop it and move on. That suits UDP. When you download a PDF, one missing byte corrupts the whole file, so you need every byte. That suits TCP.

Two worked problems

These are the kinds of questions that show up in GATE and semester exams. Try them before reading the solution.

Problem 1: decode a UDP header

A UDP header in hexadecimal is: CB84 000D 001C 001C

Find the source port, destination port, total length, and the size of the data.

Solution. Split the 8 bytes into four 16-bit fields and convert each to decimal.

• Source port = 52100
• Destination port = 13
• Total length = 28 bytes
• Data size = 28 - 8 = 20 bytes

Bonus inference: the destination port 13 is a well-known port (the daytime service) and the source port is a large random number, so this packet is going from a client to a server.

Problem 2: decode a TCP header

A TCP header in hexadecimal is:

05320017 00000001 00000000 500207FF 00000000

Find the ports, sequence number, header length, which flags are set, and the window size.

Solution. Take it one 32-bit word at a time.

Word 1, 0532 0017:

• Source port = 0x0532 = 1330
• Destination port = 0x0017 = 23 (Telnet)

Word 2, 00000001: sequence number = 1

Word 3, 00000000: acknowledgment number = 0

Word 4, 5002 07FF: this one needs unpacking into bits.

5      0    0    2
0101   0000 0000 0010
HLEN | Reserved (6) | Flags (6)

• HLEN = 0101 = 5, so the header is 5 × 4 = 20 bytes (no options)
• The last 6 bits are 000010. Reading them as URG ACK PSH RST SYN FIN, only SYN is 1
• Window = 0x07FF = 2047 bytes

Word 5, 0000 0000: checksum and urgent pointer are both 0.

So this is a SYN segment with ACK = 0, which means it is the very first segment of a three-way handshake: a client asking to open a Telnet connection.

Quick self-check

1. What is the smallest value the UDP Length field can hold? (8)
2. A TCP header has HLEN = 1010 in binary. How many bytes of options does it carry? (10 × 4 = 40 bytes total, so 40 - 20 = 20 bytes of options)
3. Which header field is how TCP does flow control? (Window size)
4. In IPv4, can a UDP sender skip the checksum? (Yes, by sending all zeros. In IPv6 it can't.)
5. Which segments of the three-way handshake have SYN = 1? (The first two)
6. How big is the IPv4 pseudo-header, and is it sent over the network? (12 bytes. No, it is only used to compute the checksum.)
7. A client's SYN has seq = 3000. What ack number does the server put in its SYN+ACK? (3001)

Wrapping up

When you're stuck on a TCP or UDP question, go back to the headers. UDP has four fields because it only does addressing, length, and an error check, and that is why it is quick and why it can lose data. TCP adds sequence numbers, acknowledgment numbers, flags, and a window, and each of those fields is the reason it can deliver every byte in order over a network that loses and reorders packets. If you can draw both header diagrams from memory and remember that HLEN counts in 4-byte words, you're ready for most exam questions on this topic.

Introduction

When you send a file to the computer next to you in the lab, it passes through a small box on the wall or under the desk: a switch. That box decides which cable your data goes out on. It makes that decision thousands of times a second, and it does it using nothing but MAC addresses.

That decision is what we call data link layer switching. Before we get to it, let's place it in the OSI model.

The physical layer (Layer 1) only moves raw bits, 0s and 1s, over a cable or radio. The data link layer (Layer 2) sits just above it. It takes that stream of bits and groups it into chunks called frames. Every frame carries two hardware addresses in its header: the MAC address of the sender (source) and the MAC address of the receiver (destination).

A MAC address is a 48-bit address burned into every network card, usually written like AA:BB:CC:11:22:33. Switching at Layer 2 is all about reading these addresses and moving frames to the right place.

What is data link layer switching?

Data link layer switching is the process of forwarding frames from one network segment to another using their destination MAC address. It happens at Layer 2 of the OSI model. The devices that do it are called bridges and switches.

When a frame arrives, the switch reads the destination MAC address and checks its MAC address table. That table tells it which port leads to that address, and the frame goes out of that port only.

In this picture the switch already knows that B is on port 2, so A's frame leaves through port 2 and nowhere else.

Here's an analogy that makes it easier to remember. Think of a security guard at the gate of an apartment building with four wings. Parcels arrive all day. On his first day he knows nobody, so for every parcel he walks through all four wings calling out the name. Each time a resident sends a parcel out, though, he writes in his register which wing they came from. After a few days the register is full, and he walks straight to the right wing.

The switch is that guard. The wings are its ports, the parcels are frames, the names are MAC addresses, and the register is the MAC address table.

Bridge vs switch

You'll see both words used for the same job, and that's fair, because a switch is a bridge with more ports. The difference is mostly size and speed.

The logic is identical. Everything in the rest of this post applies to both, so I'll use "switch" from here on.

How a switch works

Every frame that enters a switch goes through the same two steps.

Step 1: learn from the source

The switch reads the source MAC address and notes the port the frame arrived on. If host A's frame came in on port 1, the table now says "A is on port 1." Nobody configures this by hand. The switch builds the table from the traffic it sees.

Step 2: decide using the destination

Next it looks up the destination MAC address in the table. One of three things happens:

In all three cases A's frame for B comes in on port 1. Only the result of the table lookup changes what happens next.

Filtering confuses students at first. If the sender and receiver sit on the same port (say, two PCs on a hub that plugs into one switch port), the receiver already got the frame on that segment. Sending it back would waste bandwidth, so the switch throws it away.

Table entries don't last forever. If the switch doesn't hear from a MAC address for a while (300 seconds by default on most switches), it deletes the entry. This is called aging, and it keeps the table correct when a laptop is unplugged or moved.

A worked example

Take a switch with three ports. Host A is on port 1, B on port 2 and C on port 3. The table starts empty.

Each panel shows the table right after one frame. The switch only ever adds the sender, which is why a host that never sends anything stays unknown.

Flooding happened only once, for the very first frame. After three frames the switch knows every host and sends each frame to exactly one port. C also received A's first frame during that flood, but its network card saw that the destination wasn't its own MAC address and discarded it.

This is also why bridges are said to ignore the payload. The switch reads only the frame header. Whatever is inside, IPv4, IPv6 or anything else, passes through untouched.

Types of bridging

Textbooks usually describe three types.

1. Simple bridging joins exactly two network segments. The bridge is configured by hand (statically), so an administrator tells it which addresses sit on which side. Picture two small office LANs on the same floor linked by one bridge.
2. Multi-port bridging uses one device with many ports, each port leading to its own segment. A modern switch is really a multi-port bridge.
3. Learning (transparent) bridging is the type we walked through above. The bridge builds its MAC table by itself from the source addresses of incoming frames. It's called transparent because the hosts never know it's there. They send frames exactly as they would on a plain cable, with no settings to change.

Almost every switch you'll touch today is a multi-port, learning bridge.

Key features

MAC address learning

The switch fills its own MAC table by watching source addresses, as in the worked example. Nobody types entries in, and old entries age out on their own.

Frame filtering

A frame goes only where it needs to go. Traffic between two hosts on ports 1 and 2 never appears on port 3, so the rest of the network stays quiet.

Loop prevention with STP

Network engineers often connect switches with two cables, so one can take over if the other breaks. That spare cable creates a loop, and loops are a serious problem at Layer 2.

Suppose a broadcast frame leaves switch S1 on cable 1. S2 floods it back to S1 on cable 2. S1 floods it again, and the frame goes round and round. An IP packet in a loop would eventually die, because its TTL (time to live) field drops by one at every router. An Ethernet frame has no TTL field, so it circles forever. Within seconds the links fill up with copies of the same frames. This is called a broadcast storm. The MAC tables also keep flipping, because the same source address keeps arriving from two different ports.

The Spanning Tree Protocol (STP, IEEE 802.1D) fixes this. The switches talk to each other, find the loops and put one port on each redundant path into a blocked state. Only one active path remains between any two switches. If the active cable fails, STP unblocks the spare one.

On the left, both cables carry the same broadcast round and round. On the right, STP has blocked one port, so the loop is broken while the spare cable stays ready.

VLAN support

A VLAN (virtual LAN) splits one physical switch into several separate logical networks. You might put the CSE lab on VLAN 10 and the office staff on VLAN 20, all on the same switch. Each VLAN becomes its own broadcast domain, so a broadcast in VLAN 10 never reaches VLAN 20.

Some articles say VLANs join networks into a larger one. It works the other way round. A VLAN divides a network, and traffic between two VLANs needs a router or a Layer 3 switch. Layer 2 switching alone can't move a frame from one VLAN to another.

Advantages

Network segmentation

This is the advantage examiners ask about most, so it needs two definitions.

A collision domain is the part of a network where two devices sending at the same moment will collide. On an old hub, every port shares one collision domain. A switch gives each port its own collision domain, so a PC on port 1 and a PC on port 5 can send at the same time without trouble.

A broadcast domain is the part of a network that a broadcast frame reaches. A switch floods broadcasts out of every port, so the whole switch is still one broadcast domain. Only a router, or VLANs, can split broadcast domains.

An easy line to remember: switches break up collision domains, routers break up broadcast domains.

Transparent operation

Plugging in a switch requires no change on any computer. Hosts keep sending frames the way they always did, and the switch works out the rest.

Protocol independence

The switch reads only the Layer 2 header. It forwards an IPv4 packet, an IPv6 packet or anything else inside the frame the same way.

Scalability

When a lab grows, you connect another switch to an existing one. The new switch learns its own MAC table, STP keeps the paths loop-free, and the network grows without being redesigned.

Conclusion

Data link layer switching moves frames between ports using MAC addresses. A switch learns where each host is from the source address, then forwards, filters or floods each frame based on the destination address. STP stops loops from turning into broadcast storms, and VLANs let one switch act as several separate networks.

If you keep one sentence from this post, make it this: source to learn, destination to decide.

Quick quiz

Try these before you look at the answers.

1. Which address does a switch use to build its MAC table?
2. A frame arrives with a destination MAC that isn't in the table. What does the switch do?
3. A 24-port switch with no VLANs has how many collision domains and how many broadcast domains?
4. Why can a frame loop forever between switches when an IP packet can't?
5. The table says host D is on port 3, and a frame for D arrives on port 3. What happens?

Answers

1. The source MAC address. The destination is used only to decide where the frame goes.
2. It floods the frame out of every port except the one it came in on.
3. 24 collision domains and 1 broadcast domain.
4. Ethernet frames have no TTL field, so nothing removes them. STP prevents the loop in the first place.
5. The switch filters (drops) the frame, because D is on the same segment and has already received it.