TCP, UDP, HTTP and DNS

In short

TCP and UDP are the two transport-layer protocols that carry application data between processes, identified by port numbers; TCP is connection-oriented, reliable and flow- and congestion-controlled, while UDP is a thin, connectionless datagram service. HTTP is the request-response application protocol of the web, and DNS is the distributed naming system that maps names like www.irctc.co.in to IP addresses before any connection is made. Together they form the stack behind every web page, UPI payment, OTT stream and REST API in use in India. This is the highest-yield area of computer networks for GATE CS (TCP header fields, window and throughput numericals, handshake sequences) and for placement rounds at TCS, Infosys, Wipro, Cognizant, Amazon, Cisco, Juniper, Nutanix, Jio and Paytm, where "TCP vs UDP", "what happens when you type a URL" and "explain 3-way handshake" are near-certain questions.

Explained

Transport layer services, ports and sockets

• The transport layer provides process-to-process delivery; the network layer only reaches the host. Multiplexing at the sender and demultiplexing at the receiver use port numbers.
• Port is a 16-bit number (0-65535). Well-known: 0-1023 (HTTP 80, HTTPS 443, DNS 53, FTP 20/21, SSH 22, Telnet 23, SMTP 25, DHCP 67/68, TFTP 69, POP3 110, IMAP 143, SNMP 161, LDAP 389, MySQL 3306 - registered, RDP 3389). Registered: 1024-49151. Dynamic/ephemeral: 49152-65535.
• A socket = (IP address, port number). A TCP connection is identified by the 4-tuple (source IP, source port, destination IP, destination port); UDP demultiplexes on destination IP and port alone, so one UDP socket can receive from many senders.
• Connection-oriented vs connectionless: TCP sets up state at both ends before data flows; UDP just sends. Both run over IP, which is best-effort.

UDP in detail

• Header is exactly 8 bytes, 4 fields of 2 bytes each: source port, destination port, length (header + data, minimum 8), checksum.
• Checksum is computed over a pseudo-header (source IP, destination IP, protocol = 17, UDP length) plus the UDP header and data, using 16-bit one's complement addition. It is optional in IPv4 (all-zero means unused) and mandatory in IPv6.
• Properties: no handshake, no acknowledgement, no retransmission, no ordering, no flow control, no congestion control. Message boundaries are preserved (one sendto = one datagram).
• Why it is used: minimal 8-byte overhead, no connection setup delay, no head-of-line blocking from retransmission, and it supports broadcast and multicast (TCP cannot).
• Applications: DNS queries, DHCP, TFTP, SNMP, RIP, NTP, VoIP and video conferencing (RTP over UDP), online gaming, IPTV, and QUIC (which carries HTTP/3 and implements reliability itself in user space).
• Limitation: unreliable and unresponsive to congestion, so UDP-heavy traffic can crowd out TCP flows unless the application adds its own control.

TCP: segment format and connection management

• Header: 20 bytes minimum, 60 bytes maximum (options up to 40 bytes). Fields in order:
  • Source port (16), destination port (16).
  • Sequence number (32) - byte number of the first data byte of the segment. Acknowledgement number (32) - next byte expected (cumulative ACK).
  • Data offset / header length (4 bits) - header size in 32-bit words (5 to 15). Reserved (3-4 bits).
  • Flags: CWR, ECE, URG, ACK, PSH, RST, SYN, FIN.
  • Window size (16) - receiver's free buffer in bytes, so maximum 65,535 unless the window scale option (shift up to 14) is used.
  • Checksum (16) - mandatory, over pseudo-header + header + data. Urgent pointer (16).
  • Options: MSS, window scale, SACK permitted, timestamps, no-operation, end-of-options.
• Three-way handshake (connection establishment):
  1. Client → server: SYN, seq = x (client ISN), advertises MSS and window.
  2. Server → client: SYN + ACK, seq = y, ack = x + 1.
  3. Client → server: ACK, seq = x + 1, ack = y + 1; data may ride on this segment.
  4. SYN and FIN consume one sequence number each though they carry no data. A random ISN protects against stale segments and blind spoofing.
  5. SYN flooding: half-open connections fill the backlog; mitigated by SYN cookies, backlog limits and firewalls.
• Connection release - four-way (symmetric close): FIN → ACK → FIN → ACK. The side that closes first enters TIME_WAIT for 2×MSL (MSL commonly 30-120 s, typically 60 s giving 2 min) so that duplicate segments die out and the final ACK can be retransmitted.
• States (seen in netstat/ss): CLOSED, LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME_WAIT. Half-close lets one direction finish while the other still sends.
• RST aborts a connection abruptly - sent, for example, on a SYN to a closed port.

TCP reliability and flow control

• Byte-stream abstraction: no message boundaries; the application must frame its own records (a common interview point and the reason HTTP has Content-Length).
• Cumulative ACK with a single retransmission timer per connection; the receiver may delay an ACK (up to 500 ms, typically 200 ms, and at least every second segment).
• Retransmission timeout (RTO) from Jacobson's algorithm: smoothed RTT and its deviation (formulas below). Karn's rule: do not use the RTT of a retransmitted segment, and double the RTO on each timeout (exponential backoff).
• Fast retransmit: three duplicate ACKs trigger retransmission without waiting for the timer. SACK lets the receiver report non-contiguous blocks received so only genuine holes are resent.
• Flow control = protecting the *receiver*, using the advertised window (sliding window of bytes). Zero window stops the sender; a persist timer probes with a window-probe segment to avoid deadlock if the window update is lost.
• Silly window syndrome: tiny segments waste overhead. Receiver side - Clark's solution (advertise zero until half the buffer or one MSS is free); sender side - Nagle's algorithm (send the first small piece, then buffer small data until the outstanding data is ACKed or a full MSS accumulates). TCP_NODELAY disables Nagle for interactive or latency-sensitive traffic.
• TCP uses Go-Back-N-like cumulative ACKs with Selective-Repeat-like buffering, so it is a hybrid of the two textbook sliding-window protocols.

TCP congestion control

• Congestion control protects the *network*; the sender's rate is min(congestion window cwnd, receiver window rwnd).
• Slow start: cwnd starts at 1-10 MSS and doubles every RTT (exponential) until cwnd ≥ ssthresh.
• Congestion avoidance: cwnd grows by about 1 MSS per RTT (additive increase, linear).
• Loss detected by timeout (Tahoe behaviour, severe): ssthresh = cwnd/2, cwnd = 1 MSS, restart slow start.
• Loss detected by 3 duplicate ACKs (TCP Reno, fast recovery): ssthresh = cwnd/2, cwnd = ssthresh (+3 MSS during recovery), continue in congestion avoidance - no return to cwnd = 1.
• The resulting AIMD sawtooth gives fairness among flows sharing a bottleneck. TCP Tahoe, Reno, NewReno, SACK, CUBIC (the Linux default, window grows as a cubic function of time since the last loss - better on high bandwidth-delay links) and BBR (Google; models bottleneck bandwidth and RTT instead of treating loss as the only signal).
• ECN (Explicit Congestion Notification) lets routers mark instead of drop; signalled with the ECE/CWR flags.
• Bufferbloat: over-large router buffers delay the loss signal and inflate latency; fought with AQM such as CoDel and FQ-CoDel.

HTTP

• Stateless, text-based request-response protocol over TCP port 80 (HTTPS 443). State is added by cookies, URL parameters, hidden fields or server-side sessions.
• Request = request line (method, URL/path, version) + headers + blank line + optional body. Response = status line (version, code, reason) + headers + blank line + body.
• Methods: GET (retrieve; safe and idempotent), POST (submit, not idempotent), PUT (replace, idempotent), PATCH (partial, not idempotent), DELETE (idempotent), HEAD (headers only), OPTIONS, TRACE, CONNECT (tunnelling, used by proxies for TLS).
• Status code classes: 1xx informational (100 Continue, 101 Switching Protocols); 2xx success (200 OK, 201 Created, 204 No Content, 206 Partial Content); 3xx redirection (301 Moved Permanently, 302 Found, 304 Not Modified); 4xx client error (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 405 Method Not Allowed, 409 Conflict, 429 Too Many Requests); 5xx server error (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout).
• Common headers: Host (mandatory in 1.1, enables virtual hosting), User-Agent, Accept, Content-Type, Content-Length, Transfer-Encoding: chunked, Authorization, Cookie/Set-Cookie, Cache-Control, ETag, If-None-Match, If-Modified-Since, Location, Connection.
• Versions: HTTP/1.0 - one request per TCP connection (non-persistent). HTTP/1.1 - persistent connections (keep-alive) by default, pipelining (rarely used), chunked transfer, host header, byte ranges. HTTP/2 - binary framing, multiplexed streams on one TCP connection, HPACK header compression, server push; removes HTTP-level head-of-line blocking but not TCP-level. HTTP/3 - over QUIC on UDP, with per-stream loss recovery and faster (often 0-RTT or 1-RTT) setup.
• Non-persistent vs persistent: a non-persistent fetch costs 2 RTT per object (1 RTT handshake + 1 RTT request/response) plus transmission; persistent costs 1 RTT per object after the first.
• HTTPS = HTTP inside TLS. TLS 1.2 adds about 2 RTT of handshake, TLS 1.3 about 1 RTT (0-RTT on resumption); it provides confidentiality, integrity and server authentication via X.509 certificates from a CA. In India, HTTPS is effectively mandatory for payment and government services, and CCA-licensed CAs issue certificates under the IT Act, 2000.
• Caching and proxies: browser cache, forward proxy, reverse proxy and CDN; Cache-Control: max-age, validators ETag and Last-Modified producing 304 Not Modified. REST APIs use HTTP methods and status codes over JSON; CORS controls cross-origin browser access.

DNS

• A distributed, hierarchical database translating domain names to IP addresses (and more). Mostly UDP port 53; TCP port 53 when the reply exceeds the UDP limit (512 bytes classically, larger with EDNS0) and for zone transfers (AXFR).
• Hierarchy: root (13 named root server addresses, a to m, served by hundreds of anycast instances) → TLDs (gTLD .com, .org, .net; ccTLD .in, with second levels .co.in, .ac.in, .gov.in, .nic.in, .res.in, .edu.in) → authoritative name servers for each zone. .in is operated by the National Internet Exchange of India (NIXI) through the INRegistry.
• Name read right to left: in www.cse.iitb.ac.in. the trailing dot is the root. An FQDN is at most 255 bytes, each label at most 63.
• Resolution types: a recursive query asks the local/recursive resolver to do all the work and return the final answer; the resolver then issues iterative queries to root, TLD and authoritative servers, each returning a referral.
• **Steps for www.example.in**: check browser cache → OS cache (hosts file first) → local recursive resolver cache → root (referral to .in) → .in TLD servers (referral to example.in's NS) → authoritative server returns the A record → resolver caches it for the record's TTL and answers the client.
• Record types: A (IPv4), AAAA (IPv6), CNAME (alias to another name), MX (mail exchanger, with preference), NS (name servers of a zone), SOA (start of authority: primary server, serial, refresh, retry, expire, minimum TTL), PTR (reverse lookup under in-addr.arpa), TXT (SPF, DKIM, DMARC, domain verification), SRV (service location), CAA (which CAs may issue), SOA/NS delegation at zone cuts.
• Caching and TTL: every record carries a TTL in seconds; short TTLs (60-300 s) suit failover, long TTLs (86,400 s) cut query load. Negative caching stores NXDOMAIN answers.
• Load balancing and resilience: multiple A records (round-robin), GeoDNS and CDN CNAMEs, anycast for root and large resolvers. Public resolvers: 8.8.8.8 / 8.8.4.4 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9).
• Security: DNS spoofing/cache poisoning (Kaminsky attack) countered by source-port randomisation, 0x20 encoding and DNSSEC (signed records: RRSIG, DNSKEY, DS, NSEC/NSEC3) giving origin authentication and integrity - not confidentiality. DoH/DoT (DNS over HTTPS/TLS) encrypt the query. DNS amplification is a common reflection DDoS vector. In India, DNS-level blocking is used by ISPs to implement court and MeitY orders under Section 69A of the IT Act, 2000.
• Tools: nslookup, dig, host, ipconfig /displaydns, ipconfig /flushdns, systemd-resolve --statistics.

Key points

• Port - 16-bit process identifier; HTTP 80, HTTPS 443, DNS 53, SMTP 25, SSH 22, FTP 21.
• Socket pair - a TCP connection is uniquely identified by the 4-tuple of IPs and ports, so one server port serves thousands of clients.
• UDP header - fixed 8 bytes: source port, destination port, length, checksum; TCP header 20-60 bytes.
• Three-way handshake - SYN, SYN+ACK, ACK; SYN and FIN each consume one sequence number.
• Four-way close - FIN/ACK in each direction; the active closer waits 2×MSL in TIME_WAIT.
• Sequence number - counts bytes, not segments, and is 32 bits, so it wraps after 4 GB on a connection.
• ACK number - the *next* byte expected (cumulative), not the last byte received.
• Flow control - receiver-driven, via the 16-bit advertised window; window scaling extends it for high-speed links.
• Congestion control - sender-driven; rate = min(cwnd, rwnd); slow start is exponential, congestion avoidance is linear (AIMD).
• Timeout vs 3 duplicate ACKs - timeout drops cwnd to 1 MSS (slow start); 3 dup ACKs trigger fast retransmit and fast recovery to cwnd = ssthresh.
• Nagle and Clark - sender- and receiver-side cures for silly window syndrome; TCP_NODELAY turns Nagle off.
• HTTP is stateless - cookies, sessions and tokens add state; Host header is mandatory in HTTP/1.1.
• Idempotent methods - GET, HEAD, PUT, DELETE, OPTIONS, TRACE; POST and PATCH are not.
• Status classes - 1xx info, 2xx success, 3xx redirect, 4xx client error, 5xx server error.
• HTTP/2 vs HTTP/3 - HTTP/2 multiplexes streams over one TCP connection; HTTP/3 runs over QUIC/UDP and removes TCP head-of-line blocking.
• DNS queries - recursive from client to resolver, iterative from resolver to root, TLD and authoritative servers; answers cached for the TTL.
• DNS records - A, AAAA, CNAME, MX, NS, SOA, PTR, TXT, SRV, CAA; a CNAME must not coexist with other record types for the same name.
• DNSSEC authenticates DNS data; DoH/DoT encrypt it - different problems, different solutions.

Formulas and examples

Example 1 - Bandwidth-delay product and window scaling. A link between Mumbai and Singapore has bandwidth 100 Mbps and RTT 60 ms.

• BDP = 100 × 10⁶ × 0.060 = 6 × 10⁶ bits = 6,000,000 / 8 = 750,000 bytes ≈ 732 KB.
• The plain 16-bit window allows only 65,535 bytes, giving throughput ≈ 65,535 × 8 / 0.060 ≈ 8.74 Mbps - only about 8.7% of the link.
• Required window scale factor: 750,000 / 65,535 ≈ 11.4, so a shift of at least 4 (×16 → 1,048,560 bytes) fills the pipe. Answer: window scaling is essential; without it throughput caps near 8.7 Mbps.

Example 2 - Slow start and congestion avoidance. MSS = 1 KB, initial cwnd = 1 MSS, ssthresh = 8 MSS, RTT = 100 ms. A timeout occurs just after the transmission in which cwnd = 10 MSS.

• Slow start: RTT 1 → 1, RTT 2 → 2, RTT 3 → 4, RTT 4 → 8 MSS. cwnd now equals ssthresh, so growth turns linear.
• Congestion avoidance: RTT 5 → 9, RTT 6 → 10 MSS. Timeout at cwnd = 10 MSS.
• New values: ssthresh = 10/2 = 5 MSS, cwnd = 1 MSS, restart slow start: 1, 2, 4, then (cwnd 4 → next would be 8 > 5) switch to linear at 5, 6, 7...
• Data sent in the first 6 RTTs = 1 + 2 + 4 + 8 + 9 + 10 = 34 KB; average throughput = 34 KB / 0.6 s ≈ 56.7 KB/s ≈ 453 kbps.

Example 3 - HTTP page load, non-persistent vs persistent. A page has 1 base HTML file and 8 small images, RTT = 50 ms, transmission time negligible, no parallel connections.

• Non-persistent HTTP/1.0: 2 RTT per object × 9 objects = 18 × 50 ms = 900 ms.
• Persistent HTTP/1.1: 1 RTT handshake + 9 × 1 RTT for the objects = 10 × 50 ms = 500 ms.
• Non-persistent with 4 parallel connections: base object 2 RTT = 100 ms; 8 images in ⌈8/4⌉ = 2 rounds × 2 RTT = 4 RTT = 200 ms; total 300 ms.
• HTTP/2 (multiplexed, one connection): 1 RTT handshake + 1 RTT for the HTML + 1 RTT for all 8 images as parallel streams = 150 ms (100 ms if the server pushes the images; add ~1 RTT for TLS 1.3).

Example 4 - DNS resolution time with and without cache. A student opens www.ac.example.in. Resolver cache is empty. RTTs: client↔resolver 5 ms, resolver↔root 180 ms, resolver↔.in TLD 60 ms, resolver↔authoritative 30 ms.

• Cold lookup = 5 + 180 + 60 + 30 = 275 ms before the TCP SYN is even sent.
• With the TLD referral already cached, only the authoritative step remains: 5 + 30 = 35 ms.
• With the A record cached and TTL unexpired: ≈ 5 ms (or ~0 ms from the browser's own cache).
• If the record's TTL is 300 s and the site receives 6,000 lookups per hour from this resolver, at most 3,600/300 = 12 upstream queries per hour reach the authoritative server - a 99.8% reduction.

Example 5 - Sequence and acknowledgement numbers. A client's ISN is 1,000; the server's is 5,000. The client then sends 500 bytes, and the server replies with 1,200 bytes.

• Handshake: SYN seq = 1000 → SYN+ACK seq = 5000, ack = 1001 → ACK seq = 1001, ack = 5001.
• Client data segment: seq = 1001, 500 bytes (bytes 1001-1500). Server ACK: ack = 1501.
• Server data: seq = 5001, 1,200 bytes. If the MSS is 1,000 bytes it is split into seq = 5001 (1,000 bytes) and seq = 6001 (200 bytes); the client's cumulative ACK is 6201.
• If the *first* segment is lost, the second's arrival makes the client repeat ack = 5001; three such duplicate ACKs trigger fast retransmit of bytes 5001-6000. A lost *last* segment produces no duplicate ACKs, so it waits for the RTO.

# Checking all four protocols from a terminal
dig +trace www.iitb.ac.in          # full iterative path: root -> .in -> authoritative
nslookup -type=MX iitbombay.org    # mail exchanger records
curl -I https://www.india.gov.in   # HTTP response headers and status line
ss -tan | grep -c ESTAB            # count established TCP connections
tcpdump -n 'tcp[tcpflags] & tcp-syn != 0'   # capture handshake SYNs

Where it is used

• IT services and product companies (TCS, Infosys, Wipro, HCLTech, Zoho, Freshworks): REST/HTTPS APIs, load balancers, session and cookie handling, HTTP status-code-driven error design.
• Fintech and UPI stack (NPCI, Razorpay, PhonePe, Paytm, banks): every UPI and card call is HTTPS over TCP with mutual TLS, strict timeouts and idempotency keys because POST is not idempotent; RBI rules push payment data to servers in India.
• Telecom and ISPs (Jio, Airtel, BSNL, ACT): TCP optimisation, CGNAT, DNS resolver fleets, DNS-level blocking of sites under Section 69A orders, and peering at NIXI exchanges.
• Streaming, gaming and conferencing (JioHotstar, SonyLIV, Dream11, Zoom): HTTP adaptive streaming (HLS/DASH) over TCP, voice and video on RTP/UDP, QUIC for mobile networks.
• Networking and cloud roles (Cisco, Juniper, Nokia, Arista, Nutanix, AWS/Azure India): packet capture and analysis with Wireshark, firewall and load-balancer rules by port, troubleshooting retransmissions and window sizes; CCNA and RHCSA syllabi cover this directly.
• Government and e-governance (NIC, UIDAI, GSTN, IRCTC, DigiLocker): .gov.in/.nic.in DNS zones run by NIC, HTTPS with CCA-licensed certificates, Aadhaar and GST APIs over HTTPS.

Interview questions

• Q: When would you choose UDP over TCP? A: When low latency and low overhead matter more than reliability - DNS, DHCP, VoIP, live video, gaming - or when broadcast/multicast is needed, or when the application implements its own reliability as QUIC does.
• Q: Why is connection setup three-way and release four-way? A: Setup needs each side to learn and confirm the other's initial sequence number, which SYN+ACK can combine; release is per-direction because TCP allows half-close, so each side sends its own FIN when it has finished sending.
• Q: What does TIME_WAIT do and why 2×MSL? A: It keeps the 4-tuple reserved so stale duplicates from the old connection expire and the final ACK can be retransmitted if the peer's FIN repeats; 2×MSL covers one maximum segment lifetime each way.
• Q: Difference between flow control and congestion control? A: Flow control stops a fast sender from overrunning the receiver's buffer using the advertised window; congestion control stops senders from overloading the network using cwnd, slow start and AIMD.
• Q: How does TCP react differently to a timeout and to three duplicate ACKs? A: A timeout implies severe congestion: ssthresh = cwnd/2 and cwnd falls to 1 MSS with slow start restarted. Three duplicate ACKs mean packets are still flowing, so fast retransmit sends the missing segment and cwnd drops only to ssthresh (fast recovery).
• Q: Why does the acknowledgement number carry the *next* expected byte? A: Because TCP ACKs are cumulative; "next expected" unambiguously confirms every byte before it and immediately tells the sender where to resume.
• Q: If TCP is reliable, why do web pages still fail to load? A: TCP guarantees only delivery of bytes it can deliver; DNS failures, TLS certificate errors, server 5xx responses, firewall drops, routing loss beyond retransmission limits and timeouts all break the page above or below TCP.
• Q: What exactly happens when you type a URL and press Enter? A: Browser/OS/resolver DNS lookup for the host, TCP three-way handshake to port 80/443, TLS handshake if HTTPS, an HTTP GET with the Host header, server response with a status code and body, rendering plus further requests for assets, and connection reuse or close.
• Q: Why is HTTP called stateless, and how do sessions work then? A: Each request is independent and the server keeps no required memory of earlier ones; state is carried by cookies, tokens (JWT) or a session ID that indexes server-side storage.
• Q: Why does DNS prefer UDP, and when does it use TCP? A: UDP avoids handshake latency for small single-packet queries; TCP is used when responses exceed the UDP size limit (truncated, TC bit set), for zone transfers, and for DoT.
• Q: Difference between a CNAME and an A record, and one restriction on CNAME? A: An A record maps a name to an IPv4 address; a CNAME maps a name to another name. A CNAME cannot coexist with other records for the same name and so cannot be used at a zone apex (providers offer ALIAS/ANAME instead).
• Q: Does DNSSEC encrypt DNS traffic? A: No - it signs records to prove authenticity and integrity, preventing spoofing and cache poisoning; encryption/privacy requires DNS over TLS or DNS over HTTPS.
• Q: What problem does HTTP/2 solve, and what does it not? A: It removes HTTP-level head-of-line blocking by multiplexing streams over one connection with compressed binary headers, but a lost TCP segment still stalls all streams - which is why HTTP/3 moved to QUIC over UDP.

Common mistakes

• Writing the TCP header as fixed 20 bytes in every calculation, or the UDP header as 20 bytes - UDP is always 8, TCP is 20-60.
• Treating sequence numbers as segment counters; they count bytes, and SYN/FIN each consume one number though they carry no data.
• Saying the ACK number is the last byte received instead of the next byte expected (an off-by-one that loses marks).
• Confusing flow control with congestion control, or forgetting that the sending rate is min(cwnd, rwnd) - not cwnd alone.
• In slow start problems, continuing to double past ssthresh, or setting cwnd = ssthresh after a *timeout* (that is the fast-recovery rule, not the timeout rule).
• Forgetting the handshake RTT in HTTP timing problems, or using 1 RTT per object for non-persistent HTTP/1.0 instead of 2.
• Claiming TCP preserves message boundaries, or that UDP has "a smaller window" - UDP has no window at all.
• Describing DNS resolution as purely recursive end-to-end: the client's query is recursive, but the resolver's queries to root/TLD/authoritative servers are iterative.
• Assuming a DNS change takes effect instantly; old answers persist for the remaining TTL and in client and browser caches.

Related topics

OSI and TCP/IP models · IP addressing and subnetting · Socket programming · Network security: firewalls, VPN and IDS · Routing algorithms and protocols · Data link layer: framing, error control and MAC