Certified: The GIAC GISF Audio Course

In this episode, we’re going to turn the idea of network communication into a story you can picture, because the internet is not magic and it is not one single connection. When people say a device talks to a website, what they really mean is that the device follows a set of rules that decide how to start a conversation, how to keep it organized, and how to end it cleanly. Two of the most important rule sets are Transmission Control Protocol (T C P) and User Datagram Protocol (U D P), and they make different promises about reliability and speed. On top of those, the web adds its own steps, including handshakes that set expectations and sometimes create encryption before real content is exchanged. If you understand the roles of these pieces, you will stop seeing networking as a pile of jargon and start seeing it as a predictable sequence of events. That sequence becomes especially important in security, because defenders and attackers both rely on how these conversations begin and what assumptions they make.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

Before T C P or U D P can matter, two devices need a way to identify where data should go, and that starts with addressing and routing. Internet Protocol (I P) is the basic system that lets packets move across networks, kind of like putting a destination address on an envelope so the postal system can deliver it. I P is focused on getting packets from one place to another, but it does not guarantee that packets arrive, arrive in order, or arrive only once. That is not because I P is broken, but because it was designed to be flexible and scalable, even when networks are busy or unreliable. Once packets can move, the next question becomes how a device knows which application should receive the data, because a laptop might be browsing the web, streaming music, and syncing files at the same time. That is where ports come in, which are like numbered doors on a building that help traffic reach the right service. T C P and U D P both use ports to deliver data to the correct application process.

A helpful mental model is to imagine that I P gets you to the right building, and a port gets you to the right room inside that building. When your browser reaches out to a web server, it is not enough to know the server’s I P address, because the server may host many services. The port number tells the server what kind of conversation you want, such as web traffic. The combination of your device’s address and port, and the server’s address and port, forms a unique conversation space often called a socket. You do not need to memorize the formal definition right now, but you should remember that many conversations can exist at once, even between the same two devices, because ports create separation. This separation is also part of why network logs and security monitoring often mention port numbers. They are clues about what kind of service is being contacted and what kind of behavior to expect.

Now the story splits into two styles of communication. T C P is like a phone call where both sides agree to talk, confirm that they can hear each other, and keep track of what was said so nothing important is lost. U D P is more like shouting short messages across a room without checking that the other person heard each one. That might sound careless, but it can be very effective when speed matters more than perfect delivery, or when the application can tolerate missing pieces. The reason these two approaches exist is that different applications have different priorities. Some data must arrive exactly and in order, like the contents of a web page or a file download. Other data is time-sensitive and becomes less useful if it is delayed, like voice or video where a missing moment might be better than a late moment. By choosing T C P or U D P, an application chooses which tradeoff it prefers, and that choice shapes how the network behaves.

The classic event that makes T C P feel real is its handshake, which is a short sequence used to establish a reliable connection before actual data flows. The handshake is often described as three steps, where a client requests a connection, the server acknowledges, and the client confirms. The deeper point is not the exact labels, but the purpose: both sides agree on starting conditions and prove that the path works in both directions. This matters because many network problems are asymmetric, meaning a device can send traffic out but cannot reliably receive responses back. The handshake helps detect that early. It also allows the two sides to agree on technical details like sequence numbers, which are counters used to track what data has been sent and what data has been received. Once the handshake completes, T C P treats the connection as a managed stream, not just isolated packets. This is why T C P is so often used for things that must be correct, even on imperfect networks.

After the handshake, T C P keeps its promise of reliability by using acknowledgments and retransmissions. An acknowledgment is simply a message that says, I received up to this point, which lets the sender know what can be considered delivered. If acknowledgments do not arrive, the sender assumes something was lost and sends the missing data again. This process gives T C P the ability to correct for packet loss, but it also introduces overhead and delays, because extra messages and waiting are part of the reliability bargain. Another part of the bargain is ordering, because data sent in one sequence should be delivered in that same sequence to the application. If packets arrive out of order, T C P can buffer and rearrange them before handing the data up to the application. For a beginner, the important takeaway is that T C P does a lot of behind-the-scenes work so applications can pretend they have a clean, continuous channel, even when the underlying network is messy.

T C P also includes controls that prevent a fast sender from overwhelming a slow receiver, which is a major reason the internet can function at scale. Flow control is the idea that the receiver can signal how much data it is ready to handle, so the sender does not flood it with more than it can buffer. Congestion control is related but broader, because it is about the network itself becoming overloaded, not just the receiving device. When there is congestion, packets get dropped, delays increase, and everyone suffers if senders do not slow down. T C P includes algorithms that adjust sending rates based on signs of loss and delay, which is why performance can change depending on network conditions. Security professionals care about these behaviors because certain attacks try to create congestion or manipulate these mechanisms to degrade service. Even without thinking about attacks, this explains why the same website can feel fast at one moment and sluggish at another, even if nothing changed on the website itself.

U D P takes a simpler approach, and that simplicity is its biggest feature. With U D P, there is no built-in handshake that establishes a connection, and there are no built-in acknowledgments, retransmissions, or ordering guarantees. Each message, called a datagram, is sent as a standalone unit. That can reduce delay because you are not spending time setting up and maintaining a connection, and it can reduce overhead because there are fewer control messages. It also means the application must decide what to do if a datagram is missing, duplicated, or out of order. Many real systems accept that tradeoff because the application can handle it more effectively than the network layer can. For example, a streaming app might prefer to skip a missing chunk rather than pause and wait for it, because the user notices stutters more than tiny gaps. For beginners, it is enough to remember that U D P is not unreliable because it is bad, but because it is intentionally minimal.

A great way to see U D P in everyday life is to think about quick lookups and short requests where speed matters and the message size is small. Domain Name System (D N S) often uses U D P for queries because asking for a name to address mapping is usually a quick question with a quick answer, and the system is built to retry if needed. That retry logic is a good example of how applications can build reliability on top of U D P when they want it, but only in the ways they need. Another modern example is Quick UDP Internet Connections (Q U I C), which is used by some web traffic to reduce delays by handling connection management and security on top of U D P. You do not need to memorize Q U I C details, but noticing the pattern matters: engineers sometimes choose U D P as a fast foundation and then add custom reliability and security features above it. That choice highlights how flexible the internet stack is, and why security monitoring cannot assume that all web-like behavior is always T C P.

Now let’s connect this to how web communication actually begins, because browsing the web is more than just sending a request. At a high level, the browser needs to find the server’s address, establish a transport conversation, and then speak the web protocol. Hypertext Transfer Protocol (H T T P) is the language used for requesting and delivering web content, but it typically relies on a transport underneath it, often T C P. If the site uses encryption, then the browser also performs a security handshake before sending meaningful H T T P messages. That security handshake is usually part of Transport Layer Security (T L S), which creates a protected channel so outsiders cannot easily read or modify what is being exchanged. When people say a site uses H T T P S, they mean H T T P running over a T L S protected connection. The important beginner idea is that multiple handshakes may occur in a row, and each one has a distinct job in the overall story.

The transport handshake and the security handshake can be easy to mix up, so it helps to separate their purposes. The T C P handshake is about establishing a reliable transport channel between two endpoints, proving that both directions work, and setting up tracking so data can be delivered correctly. The T L S handshake is about agreeing on encryption settings, proving the identity of the server in a way the browser can validate, and establishing keys that will be used to protect the session. In a sense, T C P makes sure the conversation is stable, and T L S makes sure the conversation is private and resistant to tampering. After those foundations are in place, H T T P becomes the content conversation where the browser asks for pages, images, scripts, and other resources. Many of the delays you experience on the web are caused not by the server generating the page, but by these setup steps and the time it takes for packets to travel back and forth. Seeing the setup as a sequence makes performance and security behaviors feel less mysterious.

There is also an important concept called round trips, which is simply the number of back-and-forth exchanges needed before something useful can happen. Every handshake adds at least one round trip, and round trips are limited by physics and network routing. If your device is far from a server, each round trip takes longer, and multiple handshakes can add noticeable delay. That is why modern web designs try to reduce handshake costs and reuse existing connections when possible. It is also why attackers sometimes target handshake processes, because forcing repeated handshakes can consume resources on servers and slow down users. Even without focusing on attacks, you can now see why a secure web experience has a cost: encryption requires agreement, agreement requires messages, and messages require time. The good news is that these costs are usually worth it, because the alternative is sending sensitive data in a form that is easier to intercept or manipulate.

Security monitoring often pays special attention to handshake behavior because it reveals intent and can expose anomalies. A normal user browsing a website tends to produce predictable patterns: a D N S lookup, followed by a connection attempt, followed by a secure handshake, followed by a burst of web requests. If you see many connection attempts that never complete handshakes, that can indicate scanning, misconfiguration, or a denial-of-service style pattern. If you see a device constantly reaching out to many destinations on unusual ports, that can indicate automated probing or malware trying to call home. If you see repeated failures in T L S negotiation, that might mean a system is outdated or something is interfering with trust validation. You do not need to become an analyst today, but you should recognize that the early steps of communication produce valuable signals. Those signals exist precisely because protocols have rules, and rules create patterns that can be observed.

A common beginner misconception is to treat T C P as secure and U D P as insecure, but that is not the right way to think about it. T C P offers reliability features, not secrecy, and U D P offers speed and simplicity, not automatic danger. Security depends on what protections are used above the transport, how identity is validated, and how systems are configured to accept or reject traffic. You can run encrypted, authenticated protocols over both T C P and U D P, and you can run unprotected communication over both as well. Another misconception is that a handshake means two devices trust each other, when in reality a handshake may only mean they agreed on mechanics, not on legitimacy. Attackers can complete handshakes too, which is why additional checks, monitoring, and access controls matter. The better mental rule is that T C P and U D P describe how messages move, while security is a separate layer of decisions about who is allowed to talk, what they are allowed to do, and how you verify they are who they claim to be.

By now, you can tell the story of web communication as a clean chain of events, and that is the skill you want to keep. A device joins a network and learns where to send questions and traffic, then it resolves names, then it chooses a transport style, then it may negotiate security, and only then does it exchange meaningful application data. T C P emphasizes correctness through handshakes, acknowledgments, ordering, and rate controls, which makes it a natural fit for many web and file-style interactions. U D P emphasizes low overhead and speed, which makes it useful for time-sensitive traffic and for newer designs that build their own connection logic above it. Web handshakes layer on top of transport to create encrypted sessions and to make the browser confident about the server’s identity. If you can narrate those steps in your own words, you are building a foundation that will support nearly every future topic in networking and security, because the best way to reason about risk is to understand how communication actually starts and what assumptions it makes.