TCP/IP

TCP/IP in plain terms

TCP/IP is the family of protocols that lets computers communicate across the Internet. IP handles addressing and routing: it moves packets from one network location toward another. TCP sits above IP and provides reliable, ordered communication between applications. When a browser loads a web page over HTTPS, IP helps packets travel between networks, TCP establishes and maintains the connection, TLS protects the session, and HTTP carries the application request and response.

The term is often used casually, but defenders benefit from being precise. A network can be reachable at the IP layer while an application is broken. A TCP connection can fail before any HTTP request is logged. A UDP flood can saturate a link without creating TCP state. A Layer 7 request flood can overwhelm an application even when IP routing and TCP handshakes are healthy. Knowing which part is failing is the difference between a fast response and a noisy incident call.

Why protocol layers matter during DDoS

DDoS attacks pressure different resources depending on the layer they target. Network-layer floods try to consume bandwidth, routing capacity, or packet-processing capacity. Transport-layer attacks pressure connection state, handshake behavior, or flow tracking. Application-layer attacks send requests that force the service to spend CPU, memory, database, cache, or third-party API capacity. The user sees the same broad symptom, such as a slow or unreachable site, but the defender needs a more specific diagnosis.

TCP/IP vocabulary helps teams ask better questions. Are packets reaching the edge? Are TCP connections completing? Are TLS handshakes succeeding? Are HTTP requests reaching the application? Are responses slow because the origin is overloaded, or because traffic is being dropped before the request arrives? Each answer points to different evidence and different controls. Without that separation, teams may scale the application while the access link is saturated, or tune firewall policy while the database is the real bottleneck.

IP: addressing, routing, and reachability

IP provides the addressing and routing foundation. For availability work, useful IP-level questions include which public addresses or prefixes are affected, which networks are sending traffic, whether packets are being dropped, and whether traffic paths changed. Flow logs, router counters, firewall counters, cloud network metrics, and external synthetic checks can reveal problems that application logs cannot.

IP addresses are useful operational signals, but they are not identity. Addresses can be shared by many users, hidden behind carrier-grade NAT, reassigned over time, or spoofed in some attack classes. Blocking an address can be necessary during an incident, but it should be treated as a control decision with false-positive risk, not as proof of who is behind the traffic. Stronger decisions combine IP evidence with behavior, protocol context, route sensitivity, session state, and business impact.

TCP: connections, state, and reliability

TCP gives applications a reliable stream. It handles connection setup, ordering, retransmission, and flow control. Those features make the web usable, but they also create state that can be exhausted. A SYN flood pressures the early connection lifecycle. Slow client behavior can keep connections open longer than expected. Too much connection churn can overwhelm listeners, load balancers, or firewalls before the application sees a request.

Defenders should monitor TCP health directly. Useful signals include new connection attempts, established connections, incomplete handshakes, resets, retransmissions, connection duration, and listener errors. Those metrics help separate "the application is returning errors" from "clients cannot connect." They also help tune keepalive behavior, backlog settings, connection limits, and proxy policy in a way that matches real user behavior.

UDP and ICMP still affect web availability

TCP/IP discussions often focus on TCP because web traffic usually relies on it, but UDP and ICMP matter for availability too. UDP is connectionless and is used by protocols such as DNS and some modern transport designs. Because it does not require the same connection setup as TCP, it appears in many flood and reflection scenarios. ICMP supports diagnostics and network behavior, and it can also appear in reflection or filtering incidents.

The practical takeaway is that a web outage may start outside web traffic. A UDP reflection flood can saturate bandwidth before HTTP requests arrive. ICMP filtering can affect troubleshooting or path behavior. DNS problems can prevent users from finding the service even if the web servers are healthy. Defenders should avoid assuming that every availability incident is an HTTP incident just because the business impact is a failed website.

Choosing controls by failure point

Controls work best when placed where the failure occurs. If the problem is bandwidth saturation, upstream DDoS mitigation or provider filtering may be required. If the problem is connection-state exhaustion, TCP proxying, SYN protection, listener tuning, and connection-rate controls may help. If the problem is expensive application requests, caching, route-aware rate limits, bot detection, queue protection, and application hardening become more relevant.

This is why layered defense is not just a slogan. Each layer sees different evidence and can take different actions. Edge networks can absorb volume. Load balancers can manage connection behavior. Web servers can enforce timeouts and request limits. Applications can validate input, prioritize critical paths, and shed expensive work. Monitoring should line up with those layers so responders can see whether a control is reducing the right kind of pressure.

Common misconceptions

One misconception is that TCP/IP is a single protocol. It is better understood as a suite, with different responsibilities at different layers. Another is that a successful TCP connection means the service is healthy. It only proves that one part of the path worked; the application can still fail later. A third is that IP addresses are stable user identities. They are useful for traffic analysis, but they are often shared, dynamic, or misleading.

It is also common to over-trust one dashboard. Application performance monitoring may miss lower-layer drops. Network flow data may not show which application route was expensive. Firewall logs may show blocked traffic without proving customer impact. Good incident response compares these views instead of forcing every symptom into the tool that is most familiar to one team.

Operational habits for resilient teams

Resilient teams maintain a simple map of their request path: DNS, routing, edge network, TCP termination, TLS, proxy, cache, application, database, and third-party dependencies. They know which metrics represent each stage and who can act on them. They also test failure modes before an incident, including link saturation, connection pressure, slow clients, origin overload, and regional provider issues.

During an incident, start with classification. Is the service unreachable, unable to establish TCP connections, slow after requests arrive, or failing only on specific application routes? Then choose the control that matches the evidence. After the incident, update baselines and runbooks. TCP/IP knowledge is not academic trivia for defenders. It is the shared language that lets network, security, and application teams respond to DDoS and availability events without talking past each other.