TCP transforms unreliable networks into reliable communication through verification: handshakes that prove mutual reachability, sequence numbers that track every byte, and acknowledgments that confirm receipt—building trust where the network provides none.
Two machines that have never met need to agree on a shared starting point before exchanging data. The three-way handshake is how they synchronize—and it contains a vulnerability that attackers ruthlessly exploit.
TCP assigns a sequence number to every byte and demands acknowledgment of receipt—a simple system that transforms chaotic, unreliable networks into dependable communication.
TCP's sliding window gives receivers a way to say "slow down" without losing data. Here's how window advertisements, scaling, and zero-window probes keep fast senders from overwhelming slow receivers.
TCP doesn't trust the network. Every packet carries an implicit question—did you get this?—and silence is treated as loss. Here's how retransmission turns an unreliable network into a reliable channel.
TCP senders can't see the network—they only know when packets vanish. From this silence, they must infer congestion and restrain themselves. The alternative is collapse: a network saturated with retransmissions, accomplishing nothing.
A crashed server can't say goodbye—it just vanishes. TCP keep-alive probes the silence, finds the dead, and lets the living move on.
TCP options are how a 1970s protocol survives in a gigabit world—negotiating segment sizes to avoid fragmentation, scaling windows beyond their original 64KB limit, and using timestamps to keep high-speed connections sane.
TCP's three-way handshake forces every connection to pay a round-trip tax before sending data. TCP Fast Open lets returning clients skip the formalities—bundling their request into the very first packet. It works perfectly, except when it doesn't.
Nagle's algorithm was brilliant in 1984—batching tiny packets saved the bandwidth-starved Internet from drowning in overhead. Four decades later, it's often the reason your game feels sluggish or your terminal lags. Here's when to embrace it, when to kill it with TCP_NODELAY, and why the answer has flipped.
When you close a TCP connection, it haunts your system for 60 seconds. TIME_WAIT isn't a bug—it's TCP refusing to forget until the network catches up.
FIN ends a TCP connection like saying goodbye before hanging up. RST ends it like the line going dead mid-sentence. Knowing which happened—and why—separates minutes of debugging from hours.
War diese Seite hilfreich?