Nmap online course

TCP/IP Suite of Protocols: Layers, Roles, and Common Protocols

Learn how the TCP/IP protocol suite works, including its four layers, encapsulation, addressing, common protocols, and how TCP/IP concepts help interpret Nmap results.

What Is the TCP/IP Suite?

The TCP/IP suite is the family of interoperable networking protocols and conventions used to communicate across IP networks, including the Internet. It enables endpoints such as computers, phones, servers, and network devices to exchange data over a local network or across multiple routed networks.

The name comes from two foundational protocols: Transmission Control Protocol (TCP) and Internet Protocol (IP). TCP/IP is not one protocol. It is a coordinated suite in which protocols at different layers perform separate jobs.

A typical communication lifecycle looks like this:

1. An application creates data, such as an HTTP request.
2. Transport protocols identify the destination service and may add reliability or other delivery features.
3. IP adds logical source and destination addresses and allows routers to forward the data between networks.
4. The local network technology places the packet inside a frame for delivery across the next link.
5. The destination removes the headers, interprets each layer's information, and passes the application data to the correct process.

This process is called encapsulation when information is added while data moves down the stack. The reverse process, decapsulation, removes and interprets that information at the receiving endpoint.

The Four-Layer TCP/IP Model

The commonly taught TCP/IP model has four layers. Each layer has a distinct responsibility and provides services to the layer above it. A protocol is associated with a layer according to its primary function, even though real implementations can interact across layer boundaries.

TCP/IP Compared with OSI

The seven-layer OSI model is a useful reference model, but it is not the main protocol architecture used to operate the Internet. The TCP/IP application layer broadly combines OSI's application, presentation, and session functions. TCP/IP's network access layer broadly combines OSI's data-link and physical functions. The TCP/IP internet and transport layers correspond more closely to OSI's network and transport layers.

These models are teaching tools. Actual protocols and operating-system components do not always fit perfectly into one box. See the OSI model lesson for a more detailed comparison.

Encapsulation and Network Addressing

Suppose a browser sends an HTTP request. The application message is passed to TCP, which creates a segment and adds source and destination port numbers. IP then wraps that segment in a packet containing source and destination IP addresses. Ethernet or another link technology wraps the packet in a frame containing local source and destination MAC addresses.

For UDP, the transport data unit is commonly called a datagram. The resulting conceptual structure is:

Application message: HTTP request
        ↓
TCP segment or UDP datagram: transport header + application data
        ↓
IP packet: IP header + segment or datagram
        ↓
Link-layer frame: Ethernet header/trailer + IP packet

At the destination, the link layer checks the frame and removes its wrapper. IP processes the packet, the transport layer selects the process associated with the destination port, and the application receives the original message.

A MAC address is used for the current local-link hop. An IP address remains relevant as a packet travels between networks. A port number identifies a transport endpoint on the destination host. A domain name is a human-readable identifier that applications can translate into an address.

ARP helps an IPv4 host discover the MAC address associated with a local next-hop IP address. DNS helps applications translate names into IP addresses and can provide other records as well.

Network Access and Link-Layer Protocols

The network access, or link, layer handles local transmission. It defines how data is framed, how devices use a particular local medium, and how a frame reaches a neighboring device. Ethernet is a common link technology. An Ethernet frame is not the same thing as an IP packet: the frame is the local container, while the packet is the IP-layer unit carried inside it.

ARP on IPv4 Ethernet Networks

When a host needs to send an IPv4 packet to a device on the same local network, it needs that device's MAC address. If the mapping is not already cached, the host sends an ARP request, typically as a local broadcast. The device owning the requested IP address sends an ARP reply containing its MAC address. The sender can then build an Ethernet frame.

For a remote destination, the host normally resolves the MAC address of its default gateway, not the MAC address of the final remote server. The router receives the local frame, removes it, and forwards the IP packet in a new frame on the next link.

Client asks: Who has 192.0.2.1?
Gateway replies: 192.0.2.1 is at 00:11:22:33:44:55
Client sends an Ethernet frame to that MAC address

Internet-Layer Protocols

IP and Routing

Internet Protocol (IP) provides logical addressing and moves packets toward destination networks. A router examines the destination IP address, consults its routing information, and forwards the packet through an appropriate interface or next hop. This process is called routing.

IP is a best-effort protocol. IP itself does not guarantee delivery, preserve packet order, retransmit lost data, or establish a session. Those features may be supplied by TCP or implemented by the application.

ICMP and Diagnostics

Internet Control Message Protocol (ICMP) carries control, diagnostic, and selected error-reporting messages. The ping utility commonly sends an ICMP Echo Request and waits for an ICMP Echo Reply. ICMP travels inside IP packets and still depends on local link delivery at each hop.

ICMP is not a replacement for TCP or UDP application transport. A host may respond to ping while refusing a TCP connection, or it may block ICMP while allowing a web service to work.

Transport-Layer Protocols

The transport layer provides process-to-process delivery. Port numbers distinguish services or processes on a host. For example, a web server may listen on TCP port 80 or 443, while a DNS service commonly uses UDP port 53 and may also use TCP.

TCP

Transmission Control Protocol (TCP) is connection-oriented. Before normal data exchange, endpoints establish a connection. TCP provides ordered delivery, acknowledgments, retransmission of data believed to be lost, and flow control so a sender can adapt to the receiver's capacity.

UDP

User Datagram Protocol (UDP) is connectionless. It sends independent datagrams with low overhead and no built-in guarantee of delivery, ordering, retransmission, or session establishment. An application may add its own reliability, or it may tolerate loss to reduce delay and protocol overhead.

An application chooses TCP or UDP according to its design. Reliability, ordering, latency, overhead, and how loss is handled all matter. A port number suggests where a service may be listening, but it does not prove which protocol or application is actually in use.

Application-Layer Protocols

Application-layer protocols define the messages, commands, requests, responses, file operations, and naming data exchanged by user-facing services.

DNS translates host names to IP addresses and can return other record types. HTTP defines web requests and responses. FTP supports file transfers. Telnet provides an older remote-terminal protocol, but its plaintext behavior makes it unsuitable for modern secure administration.

Well-known port assignments are conventions, not proof. An administrator can run HTTP on an unusual port, run an unrelated service on port 80, or configure a service to use both TCP and UDP. Nmap's service and version detection can provide stronger evidence than a port number alone. See determine service version.

Protocol Interaction: Opening a Website

1. A user enters a domain name in a browser.
2. The browser or operating system asks DNS for an IP address.
3. The host compares the destination with its local subnet. If the destination is remote, it selects the default gateway.
4. If necessary, ARP resolves the local next-hop IP address, usually the gateway's address, to a MAC address.
5. The browser opens a TCP connection to the web service, commonly port 80 or 443.
6. HTTP carries the request and response over the TCP connection. For HTTPS, encryption is added by TLS around the HTTP exchange.
7. IP packets are routed between networks. Ethernet or another link technology handles delivery across each individual local hop.
8. At the server, the layers decapsulate the data and deliver the HTTP request to the web application.

Domain name → DNS → destination IP
Destination IP → local route decision → next-hop IP
Next-hop IP → ARP → next-hop MAC
TCP port → TCP connection
HTTP → request and response
IP → routing across networks
Ethernet → local delivery on each hop

Protocol Interaction: Using Ping

1. The user runs a command such as ping example.com.
2. DNS may first resolve example.com to an IP address.
3. The tool sends an ICMP Echo Request inside an IP packet.
4. Local link addressing delivers the packet directly to the destination or to the default gateway.
5. A reachable host may return an ICMP Echo Reply.

A missing reply does not conclusively prove that the host or service is down. Loss, a routing problem, filtering, disabled ICMP responses, or an unreachable target can all produce the same symptom.

Protocol Interaction: FTP or Telnet

FTP and Telnet demonstrate application protocols using TCP. The client selects the server's IP address and TCP port, and TCP establishes the connection before the application exchanges commands and data. TCP handles ordering, acknowledgments, and retransmission beneath the FTP or Telnet messages.

Telnet's lack of modern encryption means that commands and credentials can be exposed to observers. SSH is the appropriate contemporary choice for secure remote command-line access.

Useful Diagnostic Commands

These commands illustrate different parts of the stack. Availability and syntax can vary by operating system.

ping example.com
nslookup example.com
dig example.com
arp -a
ip neigh

• ping example.com demonstrates name resolution and ICMP reachability testing.
• nslookup example.com queries DNS using a commonly available utility.
• dig example.com provides detailed DNS responses where dig is installed.
• arp -a displays cached IP-to-MAC mappings on systems supporting that syntax.
• ip neigh displays neighbor and ARP cache entries on many Linux systems.

TCP/IP Concepts in Nmap

Understanding TCP/IP makes Nmap output easier to interpret. A host is an endpoint with an IP address, a port is a TCP or UDP transport endpoint, and a service is the application that may be listening there. Nmap observes packets and responses rather than directly reading the target's configuration.

A TCP SYN scan sends a TCP probe that resembles the first step of connection establishment. A response such as SYN/ACK suggests that the port is accepting connections, while a reset commonly indicates that the host is reachable but the port is closed. Filtering can prevent either response from reaching the scanner.

nmap -sS -p 80,443 <target>

A UDP scan sends UDP probes. Because UDP has no TCP-style handshake, an application response can suggest that a port is open, while an ICMP port-unreachable response can indicate that it is closed. If neither a useful UDP response nor a confirming ICMP error arrives, Nmap may report open|filtered.

nmap -sU -p 53 <target>

Filtering devices can suppress, modify, or rate-limit responses. Therefore, an absent reply does not always indicate an inactive host or service. This is especially important when interpreting UDP results and filtered TCP probes. The lessons on port states, interpreting scan results, TCP, and UDP provide further detail.

Troubleshooting by Layer

A Host Name Does Not Resolve

This usually points first to the application layer and DNS. Verify the configured resolver, query the name with nslookup or dig, and distinguish failure to resolve a name from failure to reach the resulting IP address.

Local Hosts Are Reachable but Remote Networks Are Not

Check the internet layer: the IP address, subnet mask or prefix, default gateway, and routing configuration. Confirm that the gateway is reachable on the local network and that a route exists for the remote destination.

A Local IPv4 Host Cannot Be Reached by IP Address

Check the network access layer. Inspect ARP or neighbor-cache entries, verify that both devices are on the expected VLAN or local segment, and look for duplicate IP addresses or stale mappings.

Ping Fails but a Web Application Works

ICMP may be filtered or disabled independently of TCP and HTTP. Test the specific application service rather than treating ping as a complete connectivity test.

A UDP Scan Has No Clear Result

UDP has no handshake, and a firewall may silently discard probes. An open|filtered result means Nmap cannot distinguish an open service from filtering based on the observed responses alone. Use authorized, service-specific verification when appropriate.

Exam-Ready Summary

• The TCP/IP suite is a collection of protocols for communication across local and routed IP networks.
• The four layers are application, transport, internet, and network access/link.
• Encapsulation adds headers downward; decapsulation removes and interprets them upward.
• MAC addresses support local-link delivery; IP addresses support logical addressing and routing; ports identify processes; domain names are resolved by DNS.
• ARP maps local IPv4 addresses to MAC addresses, commonly using a broadcast request and a reply.
• IP is best-effort and does not guarantee delivery, ordering, or retransmission.
• ICMP supports control and diagnostics, including ping, but is not application transport.
• TCP provides connection-oriented, ordered, acknowledged, retransmitted delivery; UDP provides connectionless, low-overhead datagrams without those built-in guarantees.
• Port numbers suggest services but do not prove them. Nmap service detection supplies additional evidence.
• Filtering and packet loss can make an absent response ambiguous, particularly during UDP scanning.

Next Steps

Review IP addresses, MAC addresses, and TCP and UDP ports before studying host discovery or UDP scanning.