Transport and Application ProtocolsIntroductionComputer networks are useful only when applications can exchange information predictably, efficiently and securely. The Internet protocol suite achieves this through cooperation between transport protocols, which provide end-to-end communication between processes, and application protocols, which define the meaning and format of exchanged data. The transport layer is concerned with delivery between applications rather than merely between hosts. It identifies applications using port numbers, may establish sessions, controls the rate of transmission and can detect or recover from loss. The application layer defines services such as web browsing, name resolution, automatic configuration, file transfer, electronic mail, remote administration, monitoring, time synchronisation and voice communication. This chapter compares TCP and UDP and examines reliability, flow control, congestion control, ports and sessions. It then analyses important application protocols and their practical use in network design and troubleshooting. Learning objectivesAfter studying this chapter, a learner should be able to: - distinguish TCP from UDP and select an appropriate transport protocol;
- explain ports, sockets, sessions, reliability, flow control and congestion control;
- describe how TCP establishes, maintains and terminates communication;
- explain the purpose and operation of HTTP/HTTPS, DNS, DHCP, FTP/SFTP, email, SSH, SNMP and NTP;
- compare real-time communication protocols and explain why voice and video often use UDP;
- analyse protocol choices, security risks and troubleshooting evidence in a practical network;
- apply protocol knowledge to a small organisational network design.
1. The transport layer: communication between processesAn IP address identifies a network interface or host. It does not, by itself, identify the particular application that should receive data. Transport protocols add this capability through port numbers. A port is a 16-bit logical identifier, ranging from 0 to 65,535. Ports 0–1,023 are traditionally called well-known ports; registered ports occupy 1,024–49,151, and dynamic or ephemeral ports are normally selected temporarily by clients from the upper range. Operating systems and current standards may implement allocation policies that differ from this simple classification. A socket is commonly described by an IP address, transport protocol and port number. A TCP connection is identified more precisely by a four-tuple: (source IP, source port, destination IP, destination port) The protocol is also part of the communication context. A web server may listen on TCP port 443 while many clients use different ephemeral source ports. Network Address Translation (NAT) can additionally translate addresses and ports at a boundary device. A server normally performs the following sequence: bind to a local address and port, listen for requests, accept a connection or receive datagrams, process application data and send a response. A client generally selects an ephemeral port, resolves the server address, initiates communication and releases the local resources when finished. Sessions and connection stateA session is a period of logical interaction between endpoints. TCP maintains connection state, including sequence numbers, acknowledgements, receive windows and timers. UDP does not create a transport-layer session; an application can nevertheless maintain its own session using identifiers, timeouts and authentication tokens. Thus, “connectionless” does not mean that an application cannot have a conversation; it means that UDP itself does not negotiate or maintain a reliable connection state. 2. TCP and UDPTCP characteristicsTransmission Control Protocol (TCP) is connection-oriented and provides a reliable, ordered byte stream. It does not preserve application message boundaries: if an application writes three blocks, the receiver may read them in different groupings. Applications requiring records must define framing, such as a length field or delimiter. TCP reliability is based on sequence numbers, acknowledgements, checksums, retransmission timers and a sliding-window mechanism. Lost, duplicated or out-of-order segments can be detected. TCP reorders data and delivers it to the application in sequence. A checksum detects corruption, but recovery generally requires retransmission. A typical TCP connection begins with a three-way handshake: - The client sends SYN, proposing an initial sequence number.
- The server replies with SYN and ACK, acknowledging the client’s sequence number and proposing its own.
- The client sends ACK, confirming the server’s sequence number.
The handshake establishes shared state and helps both sides confirm reachability. Connection termination normally uses FIN and ACK exchanges; a reset (RST) can abort a connection immediately. TCP uses two related forms of rate control. Flow control protects the receiver, while congestion control protects the network. The receiver advertises a receive window, often denoted rwnd, representing the amount of data it can accept. The sender’s usable outstanding-data limit is constrained by both receiver capacity and congestion conditions: sending window = min(rwnd, cwnd) Here, cwnd is the congestion window. This relationship is a conceptual model; the exact implementation also depends on acknowledgement behaviour, segmentation, buffering and TCP version. TCP congestion control commonly begins with slow start, in which the congestion window increases rapidly, followed by congestion avoidance, in which growth is more conservative. Packet loss, duplicate acknowledgements or retransmission timeout can cause the sender to reduce its sending rate. Modern TCP implementations use algorithms such as CUBIC or other standards-based variants. The details differ, so “TCP increases speed” should not be interpreted as a single universal formula. UDP characteristicsUser Datagram Protocol (UDP) is connectionless and provides datagrams. It supplies source and destination ports and an integrity checksum, but it does not guarantee delivery, ordering, duplicate suppression or retransmission. Each datagram retains its application message boundary. UDP has low protocol overhead and avoids the delay of a TCP handshake. It is useful when: - timely delivery is more important than perfect delivery, as in interactive voice;
- the application implements its own reliability or sequencing;
- a service uses multicast or broadcast;
- a short transaction would not benefit from connection establishment;
- a modern application protocol, such as QUIC, requires UDP as a substrate.
UDP is not automatically faster or safer than TCP. An application that sends aggressively over UDP can contribute to congestion and may be filtered by firewalls. Responsible UDP applications implement suitable rate control, security and loss handling. TCP–UDP comparison| Property | TCP | UDP |
|---|
| Communication model | Connection-oriented byte stream | Connectionless datagrams | | Delivery guarantee | Reliable through acknowledgements and retransmission | Best effort | | Ordering | Preserved for delivered byte stream | Not guaranteed | | Message boundaries | Not preserved | Preserved per datagram | | Flow control | Built in | Application responsibility | | Congestion control | Built in and implementation-dependent | Not inherently provided | | Typical uses | HTTPS, SSH, FTP control, email transfer | DNS queries, DHCP, streaming and real-time media | | Main cost | State, handshake and retransmission delay | Loss and ordering must be handled elsewhere |
The choice should follow application requirements, not habit. A file transfer normally requires complete and ordered data, whereas a voice call may prefer a late or missing audio packet to be discarded rather than retransmitted after it is no longer useful. 3. Performance conceptsImportant measures include throughput, latency, jitter, loss and availability. Throughput is the rate of successfully delivered data, commonly measured in bit/s. Latency is delay from sender to receiver or, in some measurements, round-trip time. Jitter is variation in packet arrival time. Packet loss is the proportion of packets that fail to arrive or are discarded. For a path with round-trip time RTT and a TCP receive window W measured in bits, a simplified bandwidth-delay relationship gives: throughput ≤ W / RTT This is an idealised upper bound for a continuously transmitting window-based sender. It assumes that the window, rather than another bottleneck, limits transmission and ignores protocol overhead, loss and implementation effects. For example, if W = 8,000,000 bits and RTT = 0.1 seconds, the bound is 80,000,000 bit/s, or 80 Mbit/s. The result is not a guarantee of achieved throughput. Flow control addresses a receiver that cannot process data quickly enough. Congestion control addresses a network path whose queues or links are becoming overloaded. Confusing these controls leads to poor diagnosis: increasing a receiver buffer may not solve congestion, and reducing application transmission may not solve a slow disk. 4. Application protocols4.1 HTTP and HTTPSThe Hypertext Transfer Protocol (HTTP) is an application protocol for requesting and transferring resources. A client sends a request containing a method, target and headers; the server returns a status code, headers and optionally a body. Common methods include GET, POST, PUT, PATCH and DELETE. Status codes are grouped as 2xx success, 3xx redirection, 4xx client-side error and 5xx server-side error. HTTP is stateless at the protocol level: each request contains the information needed for that request. Applications create continuity using cookies, authorisation tokens, server-side sessions or other mechanisms. HTTP/1.1 commonly uses persistent TCP connections. HTTP/2 multiplexes streams over a connection and compresses headers. HTTP/3 uses QUIC, which operates over UDP and provides encrypted, multiplexed transport features. HTTPS is HTTP protected by Transport Layer Security (TLS). TLS provides server authentication through certificates, confidentiality through encryption and integrity through authenticated cryptography. Certificate validation depends on a trusted certification path, correct host names, validity periods and appropriate client verification. HTTPS protects data in transit but does not make a vulnerable web application secure, nor does it prevent phishing or compromise of an endpoint. 4.2 DNSThe Domain Name System (DNS) maps names such as example.edu to resource records. A resolver may obtain answers from cache or query authoritative servers through the hierarchical system: root, top-level-domain and authoritative name servers. Common records include: | Record | Purpose |
|---|
| A | IPv4 address | | AAAA | IPv6 address | | CNAME | Canonical-name alias | | MX | Mail-exchange server | | NS | Authoritative name server | | TXT | Text used for verification and policy information | | PTR | Reverse mapping, commonly address to name |
DNS commonly uses UDP port 53 for ordinary queries and TCP port 53 for zone transfers or responses that require TCP; DNS software can also use TCP for other operational reasons. DNSSEC adds origin authentication and integrity for signed DNS data, but it does not encrypt ordinary DNS queries. DNS over TLS and DNS over HTTPS encrypt the resolver communication channel, with different deployment and policy implications. A cached answer is retained according to its time to live (TTL). Caching improves performance and reduces load, but changes are not necessarily visible immediately. DNS failures can therefore arise from incorrect records, expired delegation, unavailable authoritative servers, stale caches or local resolver configuration. 4.3 DHCPDynamic Host Configuration Protocol (DHCP) automatically supplies configuration such as an IP address, subnet mask, default gateway, DNS resolver and lease duration. In the common IPv4 exchange, a client broadcasts DHCPDISCOVER, servers respond with DHCPOFFER, the client broadcasts DHCPREQUEST and the selected server sends DHCPACK. This is often summarised as DORA. Because an initial client may not yet have an IP address, DHCP uses broadcast and relay agents can forward messages across routed networks. DHCP does not replace authentication or endpoint security. Rogue DHCP servers can provide malicious gateways or DNS settings; switch security controls, trusted ports and monitoring reduce this risk. IPv6 uses DHCPv6 alongside router advertisements, and the operational model differs from IPv4 DHCP. 4.4 FTP and SFTPFile Transfer Protocol (FTP) separates a control connection from data connections. Traditional FTP uses TCP and can operate in active or passive mode. Its basic form sends credentials and data without modern confidentiality, so it should not be exposed to untrusted networks. SFTP is the SSH File Transfer Protocol, a subsystem of SSH. It is not “secure FTP” in the sense of being FTP protected by TLS; it is a different protocol that transfers files through an SSH connection, commonly TCP port 22. FTPS is FTP protected with TLS and is also distinct from SFTP. Correctly identifying these protocols is essential when configuring firewalls and clients. 4.5 Electronic mailEmail involves several protocols. SMTP is used to transfer mail between clients and mail servers or between mail servers. Submission commonly uses authenticated, encrypted service on port 587; port 25 is traditionally used for server-to-server SMTP, though deployments vary. IMAP allows clients to access and synchronise messages stored on a server. POP3 typically downloads messages and has fewer synchronisation features. TLS can protect SMTP, IMAP and POP connections, but the security of the complete mail path depends on configuration at each hop. Mail systems use DNS MX records to locate receiving servers. SPF records publish permitted sending hosts, DKIM provides a domain-associated cryptographic signature, and DMARC publishes a policy and reporting mechanism based on domain alignment. These mechanisms reduce spoofing but do not eliminate malware, compromised accounts or social engineering. Users and administrators must still apply filtering, authentication, patching and awareness controls. 4.6 SSHSecure Shell (SSH) provides encrypted remote login, command execution, tunnelling and file transfer. It authenticates servers using host keys and users using passwords, public keys or other mechanisms. Public-key authentication is generally preferable to password-only access when managed correctly. Best practices include disabling unnecessary direct administrative login, using least privilege, protecting private keys, applying multi-factor authentication where supported, restricting source addresses and monitoring logs. SSH tunnelling can securely carry another application through an encrypted connection, but it may bypass organisational controls if unmanaged. Administrators should treat tunnels as a governance concern, not merely as a convenience. 4.7 SNMPSimple Network Management Protocol (SNMP) supports monitoring and management of network devices. A management station can request values from an agent using GET, receive asynchronous TRAP or INFORM notifications, and in some environments perform SET operations. Managed objects are organised in a Management Information Base (MIB) and identified by object identifiers. SNMPv1 and SNMPv2c use community strings and do not provide strong confidentiality. SNMPv3 supports authentication, integrity and privacy options. Monitoring systems should use SNMPv3 where possible, restrict management access, use read-only permissions unless changes are required, and protect management traffic on dedicated or controlled networks. 4.8 NTPNetwork Time Protocol (NTP) synchronises clocks across systems, normally using UDP port 123. Accurate time supports event correlation, authentication protocols, certificates, distributed applications and legal or operational records. NTP uses a hierarchy of stratum levels: a lower stratum generally indicates a source closer to a reference clock, but stratum alone does not guarantee accuracy. Incorrect time can cause apparently unrelated failures, including rejected certificates, Kerberos authentication errors and misleading logs. Organisations should configure trusted time sources, restrict which systems may provide time, monitor offset and avoid uncontrolled public or internal time services. 5. Real-time communication protocolsVoice and interactive video are sensitive to delay and jitter. A retransmission that arrives after a speech segment has been played is often useless. Real-time Transport Protocol (RTP) commonly carries media over UDP and includes sequence numbers and timestamps. These fields allow receivers to detect loss, reconstruct timing and smooth variation with a jitter buffer. RTP itself does not provide complete call signalling, encryption or guaranteed delivery. Session Initiation Protocol (SIP) establishes, modifies and terminates multimedia sessions. It can locate users, negotiate capabilities and coordinate ringing and termination. Session Description Protocol (SDP) describes media formats, addresses and ports within signalling messages. Real-time Transport Control Protocol (RTCP) carries quality reports and related control information. WebRTC enables browser-based real-time audio, video and data communication. It uses mechanisms including ICE for connectivity establishment, STUN to discover a public address in many NAT situations, TURN as a relay when direct connectivity fails, DTLS-SRTP for media protection and SCTP over DTLS for data channels. A signalling service is still required to exchange session information; signalling is not defined as one single mandatory protocol by WebRTC. Quality is often assessed using delay, jitter, packet loss and a user-perceived measure such as conversational quality. A practical design uses traffic classification, adequate bandwidth, low queueing delay, appropriate access-point capacity and careful firewall/NAT policy. Encryption protects content but may make some inspection and troubleshooting more difficult. 6. Applied case: a small college networkBackgroundThis illustrative case concerns a college with two buildings, 1,200 users, a web-based learning platform, VoIP handsets, wireless access, central file services and a small email system. Users report slow web access, intermittent phone audio and occasional login failures. Problem analysisThe network team captures traffic and examines logs. DNS response times are high because clients use an overloaded resolver. DHCP leases are too short, generating unnecessary renewal traffic. Voice packets show variable delay during large backups. The email server accepts weak authentication, and several switches expose SNMPv2c to broad address ranges. Authentication failures correlate with incorrect clocks on two servers. The evidence demonstrates why protocol symptoms must be interpreted by layer. A web timeout may originate in DNS, TCP establishment, TLS negotiation, server processing or congestion. A voice complaint may reflect jitter rather than low average bandwidth. Approach and solutionThe team deploys redundant caching DNS resolvers and verifies authoritative records. DHCP lease duration is aligned with device mobility and address-pool capacity; relay configuration is checked between VLANs. Voice traffic is placed in a dedicated voice VLAN, marked according to policy and given carefully tested quality-of-service treatment. Backups are scheduled outside peak hours and rate-limited to protect interactive traffic. The web platform is placed behind HTTPS with valid certificates and secure session settings. Email submission requires authenticated TLS, while SPF, DKIM and DMARC are configured and monitored. SNMPv3 replaces community-string monitoring, management access is restricted to the monitoring system, and write access is removed where unnecessary. NTP is centralised using trusted sources, and monitoring alerts on excessive clock offset. SSH access is limited to an administration network and uses managed keys with multi-factor authentication. Outcome and learning pointsAfter implementation, name resolution becomes predictable, voice jitter falls during backup periods, certificate and authentication errors decline, and monitoring provides more trustworthy device data. The case illustrates five principles: select protocols according to service requirements; separate application, transport and network symptoms; secure management traffic; treat time and naming as infrastructure services; and verify improvements with measurements rather than assumptions. 7. Security, governance and best practicesProtocol security is a system responsibility. Administrators should: - use TLS, SSH, SFTP or other authenticated encryption instead of clear-text alternatives;
- apply least privilege to ports, services, SNMP operations and administrative accounts;
- segment user, server, voice, guest and management networks;
- restrict exposed services with firewalls and access-control lists;
- patch protocol implementations and remove obsolete versions;
- collect logs while respecting privacy and retention requirements;
- synchronise clocks and protect time sources;
- monitor DNS, DHCP, authentication, certificate expiry, loss, latency and jitter;
- test backups, failover and incident-response procedures.
Encryption does not solve every problem. Metadata may remain visible, endpoints may be compromised, keys may be mishandled, and application-level authorisation may be defective. Organisations must also comply with data-protection, communications, acceptable-use and records-retention requirements applicable to their jurisdiction. Contemporary networks increasingly use encrypted transport, HTTP/3 and QUIC, cloud-managed DNS and identity-aware access controls. Artificial intelligence can assist anomaly detection and traffic classification, but its results require validated data, explainable escalation procedures and human oversight. Automated blocking based on an incorrect model can interrupt critical services. Chapter SummaryTransport protocols deliver data between applications. Ports identify services, while sockets and TCP connection tuples distinguish simultaneous conversations. TCP provides an ordered, reliable byte stream through sequencing, acknowledgements and retransmission; it also implements receiver flow control and network congestion control. UDP provides lightweight datagrams without built-in reliability, ordering or congestion control, making it suitable when low overhead, multicast or timeliness is important. HTTP defines web exchanges, while HTTPS adds TLS protection. DNS resolves names and supports service discovery; DHCP supplies network configuration; FTP and SFTP provide different file-transfer models; SMTP, IMAP and POP support different parts of email; SSH enables secure administration; SNMP supports monitoring; and NTP provides essential time synchronisation. RTP, SIP, SDP, RTCP and WebRTC support real-time communication, where delay and jitter can be more harmful than occasional loss. Effective network engineering combines protocol knowledge with measurement, segmentation, secure configuration, monitoring and governance. A symptom such as “the network is slow” must be decomposed into name resolution, connection setup, transport behaviour, application processing and path performance. Key TermsPort: A 16-bit logical identifier for an application endpoint. Socket: An endpoint identified by an address, protocol and port. Session: A logical period of interaction between communicating parties. TCP: A connection-oriented, reliable, ordered byte-stream transport protocol. UDP: A connectionless datagram transport protocol with minimal guarantees. Sequence number: A number used to identify the position of data in a transport stream. Acknowledgement: A message indicating successfully received data or control information. Flow control: Regulation that prevents a sender overwhelming a receiver. Congestion control: Regulation that limits traffic offered to an overloaded network path. RTT: Round-trip time between sending a message and receiving its response. HTTP: Application protocol for transferring web resources. HTTPS: HTTP protected by Transport Layer Security. DNS: Hierarchical naming system that maps names to resource records. DHCP: Protocol for automatically supplying host network configuration. SFTP: SSH File Transfer Protocol, distinct from FTP and FTPS. SMTP: Protocol used for email submission and transfer. SSH: Secure Shell protocol for encrypted remote access and tunnelling. SNMP: Protocol for monitoring and managing network devices. NTP: Protocol for synchronising system clocks. RTP: Protocol commonly used to transport real-time media with sequence and timing information. Review QuestionsShort Answer Questions- What is the purpose of a transport-layer port number?
- State two differences between TCP and UDP.
- Distinguish flow control from congestion control.
- What is the role of DNS in a network?
- Why is accurate time important for authentication and troubleshooting?
Long Answer Questions- Explain the TCP three-way handshake and the mechanisms TCP uses to provide reliable delivery.
- Compare HTTP, HTTPS, HTTP/2 and HTTP/3, including the roles of TLS, TCP and QUIC.
- Describe the operation and security considerations of DHCP in a routed enterprise network.
- Explain how SMTP, IMAP, DNS MX records, SPF, DKIM and DMARC work together in email delivery.
- Discuss the roles of SIP, SDP, RTP, RTCP and WebRTC in a real-time communication system.
Analytical / Application Questions- A file transfer is complete but a voice call becomes unintelligible whenever backups run. Analyse the likely transport and performance causes and propose a network solution.
- Users can reach a learning platform by IP address but not by name. Develop a structured troubleshooting procedure using DNS, DHCP, client configuration and server evidence.
- Design a secure management approach for switches using SSH, SNMPv3 and NTP. Specify access restrictions, authentication, monitoring and failure-handling measures.
Multiple Choice Questions with AnswersQuestion 1Which property is provided by TCP but not inherently by UDP? A. Port numbers B. Reliable ordered delivery C. IP addressing D. Checksums Correct Answer: B. Reliable ordered delivery Question 2What does TCP flow control primarily protect against? A. A receiver being overwhelmed B. A forged DNS record C. An expired certificate D. A missing routing table Correct Answer: A. A receiver being overwhelmed Question 3Which DNS record identifies a mail-exchange server? A. A B. CNAME C. MX D. PTR Correct Answer: C. MX Question 4Which protocol commonly provides secure file transfer through SSH? A. SFTP B. TFTP C. POP3 D. SNMPv2c Correct Answer: A. SFTP Question 5What is the main protection added by HTTPS? A. Automatic data backup B. TLS-based confidentiality and integrity C. Guaranteed server availability D. Removal of all application vulnerabilities Correct Answer: B. TLS-based confidentiality and integrity Question 6Which sequence correctly represents the common IPv4 DHCP exchange? A. ACK, OFFER, DISCOVER, REQUEST B. DISCOVER, OFFER, REQUEST, ACK C. REQUEST, DISCOVER, ACK, OFFER D. OFFER, ACK, REQUEST, DISCOVER Correct Answer: B. DISCOVER, OFFER, REQUEST, ACK Question 7Why can UDP be appropriate for interactive voice? A. It guarantees every packet arrives B. It automatically retransmits late audio C. It can avoid retransmission delay for time-sensitive media D. It encrypts media without additional protocols Correct Answer: C. It can avoid retransmission delay for time-sensitive media Question 8Which SNMP version provides authentication, integrity and privacy options? A. SNMPv1 B. SNMPv2c C. SNMPv3 D. SNMP over FTP Correct Answer: C. SNMPv3 Question 9What is the principal purpose of NTP? A. Synchronising system clocks B. Assigning IP addresses C. Transferring web pages D. Negotiating email recipients Correct Answer: A. Synchronising system clocks Question 10If a window-limited sender has W = 8,000,000 bits and RTT = 0.1 s, what idealised throughput bound is W/RTT? A. 0.8 Mbit/s B. 8 Mbit/s C. 80 Mbit/s D. 800 Mbit/s Correct Answer: C. 80 Mbit/s
|