1.5Common applications and protocols

"The web loads but only email will not send," "it will not open by name but works if I type the IP directly"—to isolate such symptoms you must be able to identify which app uses which protocol and port number, and whether that is TCP or UDP. A port number is like the "room number of the destination," and a firewall decides which traffic to pass by this number. Building on the difference between TCP and UDP, this section learns the common protocols and port numbers frequent in support—not as a memorized list but by identifying them in connection with symptoms.

1.5.1Choosing between TCP and UDP

• TCP is connection-oriented. Before communicating, it establishes a connection with a three-way handshake (SYN -> SYN/ACK -> ACK) and guarantees reliability through ordering and retransmission. Use it where loss is unacceptable—web (HTTP/HTTPS), email, file transfer. In exchange, its overhead is higher.
• UDP is connectionless. Without a handshake or retransmission, it sends with low latency and low overhead. It suits cases where immediacy matters more than occasional loss—DNS queries, DHCP, and voice/video (VoIP, streaming). If reliability is needed, the application compensates.

1.5.2Common protocols and port numbers

• HTTP (80/TCP) = web browsing; HTTPS (443/TCP) = encrypted web browsing (protected by TLS); today's web is almost all HTTPS. DNS (53) = name resolution translating a domain name to an IP address, with queries mainly over UDP (large responses also use TCP).
• DHCP (67/68, UDP) = automatically distributes IP address, subnet mask, gateway, and DNS at startup. NTP (123, UDP) = time synchronization of devices (important for correlating logs and validating certificates). ICMP (no port number) = the reachability/error-notification mechanism used by ping and traceroute; it has no port number like TCP/UDP.
• Distinguish three file-transfer protocols: FTP (20/21, TCP) = the classic transfer (two ports for control and data; unencrypted), SFTP (22, TCP) = encrypted transfer over SSH (secure), TFTP (69, UDP) = simple, lightweight transfer (device config/firmware distribution; minimal authentication and retransmission). They sound alike, but note SFTP is secure while TFTP is simple and over UDP.

Suppose a user reports, "our internal web system opens if I type the IP address directly, but not by the usual URL (name)." With knowledge of protocols and ports you can quickly narrow the cause. If it opens by direct IP, TCP reachability to that server (HTTP 80 or HTTPS 443) is likely alive. Yet it will not open by name, so the suspect is a failure of DNS (53), which translates a name to an IP. You can lay out steps: check with nslookup whether the name resolves, and if not, review the DNS server settings or the DNS address handed out by DHCP. On another day, someone reports, "a newly brought-in PC will not connect, and its IP address is a strange value starting with 169.254." Addresses starting with 169.254 are the automatic assignment (APIPA) used when no address could be obtained from DHCP, so DHCP (67/68) traffic likely is not reaching it. And if "log timestamps differ across devices so I cannot trace the sequence of a fault," suspect a time-synchronization problem via NTP (123). In this way, linking a symptom (will not open by name / strange IP / clocks off) to the corresponding protocol and port (DNS 53 / DHCP 67-68 / NTP 123) makes the next move concrete. Port numbers and the TCP/UDP distinction are not mere memorization but a vocabulary for translating symptoms into causes.

1.5.3Section summary

• TCP gives reliability via the three-way handshake (web, email, file transfer); UDP is connectionless and low-latency (DNS, DHCP, VoIP)
• Key ports: HTTP 80 / HTTPS 443 / DNS 53 / DHCP 67-68 / FTP 20-21 / SFTP 22 / TFTP 69 / NTP 123; ICMP has no port number
• Isolate by linking symptoms (will not open by name = DNS / strange 169.254 IP = DHCP / clock drift = NTP) to protocols and ports