Do not study protocols as isolated acronyms—study the dependency each protocol satisfies
A network transaction is a chain of cooperating protocols. If a student types a hostname into a browser, name resolution may happen before the browser can contact the server; local delivery is needed to reach the next hop; IP carries traffic across networks; transport reaches the service; and the application protocol completes the user's request. The strongest AP Networking reasoning identifies which dependency failed and what the evidence rules out.
Protocol question shortcut
For every protocol, know five things: purpose → layer/function → transport/port when relevant → failure signature → discriminating test.
One HTTPS request can depend on several protocols before a page appears
The exact sequence depends on what is already cached/configured and on the network design, but the dependency idea is crucial: “the website is down” does not identify which protocol failed.
Organize protocols by job, not alphabetically
| Job | Protocol / technology | Transport / common port | High-value understanding |
|---|---|---|---|
| Local delivery | Ethernet | Link layer | Frames and MAC-based local forwarding |
| IPv4 next-hop resolution | ARP | Local link function | Maps a local IPv4 next-hop address to link-layer addressing information |
| Routed delivery | IPv4 / IPv6 | Network layer | Logical addressing and forwarding across networks |
| Control/diagnostic messaging | ICMP | Network layer | Supports messages used by tools such as ping; not an application-port test |
| Reliable transport | TCP | Transport | Connection-oriented ordered byte stream with reliability mechanisms |
| Datagram transport | UDP | Transport | Lower-overhead datagrams without TCP's connection/reliability machinery |
| Configuration | DHCP | UDP 67/68 | Can provide address, prefix/mask, gateway, DNS and lease information |
| Name resolution | DNS | UDP/TCP 53 | Queries records; DNS is not simply “the Internet” |
| Web | HTTP / HTTPS | TCP 80 / 443 | HTTPS protects HTTP using TLS |
| Remote administration | SSH | TCP 22 | Encrypted remote administration |
| Legacy remote terminal | Telnet | TCP 23 | Legacy plaintext remote terminal; security concern |
| Email transfer | SMTP | TCP 25 | Message transfer/relay role; deployments may use other submission/security ports |
| Mailbox access | IMAP / POP3 | TCP 143 / 110 | Mailbox access/retrieval roles; secured variants commonly use other ports |
Swipe horizontally to see the complete protocol map.
Port numbers are useful defaults, not magical identities. Services can be configured on nonstandard ports, and a port number alone does not tell you whether the expected application is healthy.
ARP answers a local IPv4 delivery question—not “where is the remote server?”
When an IPv4 host needs to send to a destination on its local subnet, it needs local link-layer delivery information for that destination. When the destination is remote, the host normally needs link-layer information for the local next hop/default gateway, not the remote server's MAC address.
DHCP failure can create several downstream symptoms at once
DHCP is not merely an “IP address protocol.” A normal lease can include an address, subnet information, default gateway, DNS servers, and other options. That means one DHCP problem can produce symptoms that students mistakenly diagnose as separate routing or DNS failures.
A useful troubleshooting distinction is whether the DHCP server is unreachable, the request cannot cross the required network boundary/relay path, the address pool is exhausted, or the returned options are wrong.
DNS failure can break names while IP connectivity remains healthy
Pattern supporting DNS investigation
Direct IP reachability succeeds, but hostname resolution fails or returns an unexpected record.
Pattern that does not prove DNS
“The website will not open” by itself. The failure could occur at transport, routing, TLS, or the application.
DNS can use both UDP and TCP on port 53. Avoid the oversimplification that DNS is “always UDP.”
Ping is useful evidence, but students routinely overclaim what it proves
Transport choice follows application requirements, not a simple “better/worse” ranking
| Characteristic | TCP | UDP | Reasoning consequence |
|---|---|---|---|
| Connection behavior | Connection-oriented | Connectionless datagrams | TCP maintains more transport state |
| Ordering | Ordered byte stream | No transport-layer ordering guarantee | Applications using UDP handle needed behavior themselves |
| Reliability mechanisms | Acknowledgments/retransmission | No TCP-style built-in reliability | UDP is not synonymous with “bad”; requirements differ |
| Overhead/state | More transport machinery | Simpler transport | Tradeoff depends on application goals |
Swipe horizontally to compare TCP and UDP.
Study the deeper comparison in TCP vs. UDP.
A successful TCP connection is a boundary marker, not proof of application success
Likewise, if TCP/443 cannot establish while ICMP works, investigate the service listener, filtering, path policy, or transport-specific conditions rather than concluding the entire IP path is down.
An HTTP response—even an error—can prove the request reached application processing
Students often treat every non-200 HTTP response as “the network failed.” But an HTTP status such as a client or server error means an HTTP-speaking endpoint processed enough of the request to return an application-layer response.
Similar user goals can be implemented by protocols with very different security properties
| Goal | Legacy / less protected example | Protected alternative | Important distinction |
|---|---|---|---|
| Remote terminal/admin | Telnet | SSH | SSH provides encrypted remote administration; Telnet is plaintext. |
| Web browsing | HTTP | HTTPS | HTTPS uses TLS to protect HTTP communication. |
| File transfer | FTP | SFTP / FTPS | SFTP and FTPS are not the same protocol: SFTP is associated with SSH; FTPS adds TLS protection to FTP. |
Swipe horizontally to compare protocol security.
Security analysis should go beyond “encrypted/not encrypted.” Ask what is protected, how peers are authenticated, and whether the deployment/configuration actually provides the expected protection.
SMTP, IMAP, and POP3 solve different parts of email delivery
SMTP
Used for message transfer/relay and, in real deployments, message submission workflows. Think “sending/transfer role.”
IMAP
Designed for accessing and managing mailbox content while keeping server-side mailbox state useful across clients.
POP3
Provides mailbox retrieval behavior with a historically simpler download-oriented model.
Do not answer an email-protocol question by matching a memorized port alone. First identify whether the scenario describes sending/relay or mailbox access/retrieval.
A port is an endpoint identifier, not proof that the expected service is working
| Common service | Common port | Transport | Exam reasoning |
|---|---|---|---|
| SSH | 22 | TCP | Secure remote administration |
| Telnet | 23 | TCP | Legacy plaintext terminal |
| SMTP | 25 | TCP | Mail transfer/relay role |
| DNS | 53 | UDP and TCP | Name-resolution service |
| DHCP server/client | 67 / 68 | UDP | Dynamic client configuration |
| HTTP | 80 | TCP | Unencrypted HTTP by default |
| POP3 | 110 | TCP | Mailbox retrieval |
| IMAP | 143 | TCP | Mailbox access |
| HTTPS | 443 | TCP | HTTP protected with TLS |
Swipe horizontally to see the full port table.
For focused review, use Common Network Ports for AP Networking.
The site works by IP but not by name
Best interpretation: The evidence supports basic client configuration and IP reachability while directly identifying a name-resolution failure. DNS becomes a stronger target than DHCP, Ethernet, or the remote IP path.
Ping works, but the secure web service does not
The server and tested IP path are reachable, and another TCP service succeeds. The evidence makes a total network outage unlikely. Focus on TCP/443-specific filtering, service availability, or policy rather than DNS or a disconnected cable.
DHCP can be the first broken dependency even when the complaint is “DNS doesn't work”
DNS may indeed fail, but the earlier dependency is client configuration. If DHCP was expected to supply the DNS server and gateway, diagnose the lease/configuration path before treating DNS as an independent root cause.
Use protocol-specific tests to challenge your first hypothesis
“DNS is broken.”
Run a direct name-resolution query and inspect the returned server/record behavior. A correct resolution weakens DNS as the cause of the current symptom.
“The server is unreachable.”
Test the relevant IP path and then the actual required transport port. A ping alone is insufficient for a TCP-service claim.
“DHCP is broken.”
Inspect the client's lease/configuration and whether other clients on the same segment receive expected options.
“HTTPS is blocked.”
Test TCP/443 specifically. If it establishes and TLS/application processing begins, basic port blocking is a weaker explanation.
Change one fact and the best protocol diagnosis can change
| Initial evidence | Changed fact | New implication |
|---|---|---|
| Name fails; direct IP works | DNS lookup now succeeds with expected address | Move beyond basic name resolution toward transport/TLS/application evidence. |
| Ping works; HTTPS fails | TCP/443 now establishes | Move past basic TCP reachability toward TLS/application processing. |
| Client has no usable configuration | Valid DHCP lease appears with correct options | DHCP becomes less likely as the active failure; test the next dependency. |
| Remote network unreachable | Gateway and remote IP now respond | Basic tested IP routing is supported; investigate the required service. |
Swipe horizontally to practice changed-fact reasoning.
Correct these protocol mistakes before they cost points
- “DNS is always UDP.” DNS uses both UDP and TCP port 53 depending on the transaction.
- “Ping proves the website is working.” Ping does not test TCP/443, TLS, or HTTP processing.
- “ARP finds the remote server's MAC across the Internet.” ARP is used for local IPv4 neighbor/next-hop resolution.
- “UDP is bad because it is unreliable.” UDP intentionally provides simpler datagram transport; applications choose transport based on requirements.
- “SFTP is just FTP with encryption turned on.” SFTP and FTPS are distinct approaches; SFTP is associated with SSH, while FTPS protects FTP with TLS.
- “Port 443 means the application is healthy.” A port is an endpoint identifier; TLS or application behavior can still fail.
- “An HTTP 404 means the network failed.” Receiving the HTTP response shows the transaction reached application processing.
Which protocol dependency failed first?
Interpretation: The evidence carries the transaction through DNS, IP reachability, TCP, and TLS. An HTTP 403 Forbidden is an application-layer response indicating the request reached HTTP processing but was not authorized for the requested resource. Replacing the cable or changing DNS contradicts the supplied evidence.
Use PURPOSE → EVIDENCE → LIMIT → NEXT TEST
Example: “Because DNS successfully resolves the hostname to the expected IP, basic name resolution is working. That does not prove HTTPS is reachable, so the next useful test is the required TCP/443 path.”
24 interactive network-protocol reasoning flashcards
These cards test protocol purpose, ports, dependency logic, evidence interpretation, troubleshooting, and common exam traps.