- What is TCP/IP?
- Where TCP/IP comes from
- TCP vs IP: two protocols, two different jobs
- Which protocols make up the TCP/IP suite
- The four layers of the TCP/IP model
- How a transfer works, step by step
- Ports and sockets: how two applications find each other
- TCP/IP today: IPv6, QUIC and encryption
- Conclusion
- Frequently asked questions
You press Enter on a web address and a page appears. In the time it takes you to blink, a handful of protocols you never asked about have already agreed on how to move your data across the planet. TCP/IP is the name of that arrangement, and once you see how it splits the work, it stops being a mystery.
Keep one idea and the rest of this piece falls into place: IP gets your data to the right machine, and TCP gets it there complete and in order. The web, your email, video calls and streaming music all sit on top of those two jobs.
Below you will see what the name really means, how its two main protocols divide the chores, which other protocols travel in the same family and how its four layers share the load. Then you will follow one request, step by step, from your keyboard to a server and back.
What is TCP/IP?
TCP/IP is really a family of protocols arranged in layers. The name comes from the two best-known members of that family: the Transmission Control Protocol (TCP) and the Internet Protocol (IP).
The goal is easy to state and hard to deliver. Any device on the network should be able to exchange information with any other, even when they come from different vendors, run different operating systems and sit behind several intermediate networks. To pull that off, TCP/IP cuts data into small units called packets, stamps each one with an origin and a destination, routes it across the network and puts it back together at the other end.
That independence from any single vendor is why it won. TCP/IP is the common language of the internet, and of the overwhelming majority of private and corporate networks too.
Where TCP/IP comes from
Two men signed the original design in the mid-1970s: Vint Cerf and Bob Kahn. The first written specification was RFC 675, published in December 1974, and it is the document where the word Internet first appears. DARPA paid for the work as part of the programme that produced ARPANET, the network that came before today’s internet.
That early specification bundled transport and addressing into a single protocol. Not long after, the design split in two. IP got its own document in RFC 791 (1981) and TCP in RFC 793 (1981). Separating them let the transport side evolve without touching addressing, and the arrangement still holds today under a revision in RFC 9293 (2022).
ARPANET adopted it as a standard in the early 1980s, and from then on any network that wanted to talk to the internet had to speak it.
It had competition. IBM machines spoke SNA, DEC machines spoke DECnet, and each stack worked best with hardware from the same maker. TCP/IP went the other way and stayed open, which is exactly what a network of networks demanded.
TCP vs IP: two protocols, two different jobs
Yes, they are different, and so different that neither works without the other. IP handles addressing and routing. TCP handles reliable transport. Two problems, two layers.
IP works at the network layer. It stamps a source and a destination address on every packet and decides which path sends it towards the next hop. It does this on a best-effort basis. It tries hard to deliver and guarantees nothing. A packet can be lost, arrive twice or turn up out of order, and IP does not care.
TCP works at the transport layer and picks up whatever IP leaves loose. Before it sends anything it opens a connection. Then it numbers the data, acknowledges what arrives, retransmits what is lost and reorders what shows up out of sequence. If the network is congested, TCP slows down so it does not make things worse.
Think of the postal service. IP is the addressing system and the postmen who carry every package to the right building. TCP is the clerk who checks that the whole shipment left, that none of it arrived broken and that it can be stacked in the right order. Without addresses you would not know where to send anything. Without TCP’s checks you would never know whether the full delivery arrived.
TCP vs UDP: the other transport-layer option
TCP is not the only transport protocol. UDP (User Datagram Protocol) does the opposite: it opens no connection, confirms nothing and retransmits nothing. It is lighter and faster, at the price of guaranteeing neither delivery nor order.
That does not make it worse. For some jobs it is the right pick. Resolving a domain name or starting a video call gains nothing from waiting for acknowledgements that arrive too late anyway. Pick according to what the application needs:
| TCP | UDP | |
|---|---|---|
| Connection | Yes (three-way handshake) | No |
| Reliability | Acknowledges, retransmits and orders | No guarantees |
| Speed and overhead | Slower, more control | Faster, minimal control |
| Order of data | Guaranteed | Not guaranteed |
| Typical uses | Web, email, file transfer | DNS, real-time voice and video, gaming, DHCP |
Which protocols make up the TCP/IP suite
TCP/IP is a broad family. Beyond TCP and IP, it carries supporting protocols that solve specific jobs. These are the ones you will meet most often:
- ICMP (Internet Control Message Protocol). Carries error and control messages. It is the protocol behind
ping. - ARP (Address Resolution Protocol). Translates an IP address into a MAC address inside the local network. Without it, a packet would know which IP to go to but not which device to hand itself to (RFC 826).
- IGMP (Internet Group Management Protocol). Manages multicasting: sending the same stream of data to several machines at once.
- DNS (Domain Name System). Translates names such as
opguardian.cominto IP addresses. - HTTP and HTTPS. The protocol of the web. HTTPS adds encryption through TLS, described in RFC 8446.
- SMTP, IMAP and POP3. The email protocols: one to send and the others to read.
- FTP, SFTP and SSH. File transfer and remote administration of machines.
- DHCP. Automatically hands out IP addresses to the devices on a network.
The four layers of the TCP/IP model
The model organises all of the above into four layers. Each layer uses the services of the one below and offers its own to the layer above, so a change in one layer does not force you to touch the rest. From the bottom up:
| Layer | What it does | Protocols and examples |
|---|---|---|
| Network access | Sends the bits over the physical medium and delivers the frame to the neighbouring machine | Ethernet, Wi-Fi, ARP |
| Internet | Addresses and routes packets between networks | IP (IPv4 and IPv6), ICMP, IGMP |
| Transport | Communicates end to end, with or without guarantees | TCP, UDP |
| Application | Offers the network to user applications | HTTP, HTTPS, DNS, SMTP, FTP |
Network access layer
Also called the network interface layer, this one connects the device to the physical medium, whether that is the Ethernet cable, the Wi-Fi signal or the fibre. Here packets travel encapsulated in frames and physical addresses are used, the MAC addresses. Routers consult them to hand a packet to the next hop inside the local network.
Internet layer
This is where IP lives. Its mission is to get a packet out of one network and into another, however many intermediate hops that takes. Every device has an IP address that identifies its network and its position inside it. The classic version, IPv4, is described in RFC 791, and its successor, IPv6, in RFC 8200.
The two versions differ above all in size. An IPv4 address is 32 bits long, about 4.3 billion possible addresses, a pool that ran dry years ago. An IPv6 address is 128 bits, a pool big enough for every device on the planet to hold billions of them. Private ranges such as 192.168.x.x keep internal networks from burning through public addresses, and NAT lets many devices share one.
Transport layer
Here data stops being a loose packet and becomes a conversation between two applications. TCP and UDP are the two protocols of this layer, and they mark its big split in behaviour: TCP guarantees that everything arrives and arrives intact, while UDP prioritises speed and leaves the guarantees to the application.
Ports also live here, and they let one machine serve the web, email and a video call at the same time without mixing them up. Flow control and congestion control are managed here too, the mechanisms that stop a fast sender from drowning a slow receiver. When the network misbehaves for reasons other than bandwidth, the cause usually sits in how TCP reacts to latency and packet loss. It pays to learn to measure and improve your internet speed before you blame your plan.
Application layer
This is the top layer, the one you actually see: the browser, the email client, the messaging app. Application protocols such as HTTP, DNS, SMTP and FTP leave the travel to the layers below and focus on what the bytes mean. Underneath, TCP or UDP hands them a pipeline that is either reliable or fast.
How a transfer works, step by step
Theory lands better with a real case. Imagine you type a web address and press Enter:
- Name resolution. The system asks DNS which IP address corresponds to that domain.
- Three-way handshake. TCP opens the connection. The client sends a SYN, the server answers SYN-ACK and the client closes with an ACK.
- Encryption. If the site uses HTTPS, a TLS session is negotiated and the content travels encrypted.
- Segmentation. The request is split into TCP segments, which are encapsulated into IP packets and, finally, into frames at the network access layer.
- Routing. Every router reads the destination IP and forwards the packet to the next hop.
- Acknowledgements and reassembly. The server acknowledges the segments it received. The ones that are lost are retransmitted, and TCP puts everything back in order at the end.
- Tear-down. Once the transfer is done, the connection is closed in an orderly way.
All of it happens in milliseconds and out of sight. The whole point of TCP/IP is that none of those steps ever has to concern you.
Ports and sockets: how two applications find each other
An IP address gets you to a device. It does not get you to the application that should answer the connection. That is the job of the port, a number attached to the IP. Address, port and protocol together make up a socket, the exact point where two programs talk.
IANA, the body that coordinates these identifiers, reserves ports 0 to 1023 for well-known services. Port 80 is HTTP and port 443 is HTTPS. Ports above 1024 work as the source of outgoing connections and let one machine tell several applications apart at once.
A socket is written as an address and a port joined together, for example 203.0.113.10:443. That split lets one server hold thousands of conversations at the same time, each one identified by its own four-part tuple of source and destination address and port. The web’s real-time protocols build on that same socket. WebSocket opens one of those connections and keeps it open so both ends can talk at once.
TCP/IP today: IPv6, QUIC and encryption
The model is over forty years old and still adapting. IPv4 addresses ran out long ago, so IPv6 has been rolling out alongside for years with a far larger address space. Most current devices run «dual stack» and speak both at once.
The transport of the web has shifted too. QUIC, defined in RFC 9000, runs over UDP and takes over much of the work TCP used to do, with lower latency when it opens a connection. It is the foundation of HTTP/3. Encryption, once optional, is now the norm, and almost all modern traffic travels under TLS.
None of those changes breaks the model. The pieces get swapped out, and the four-layer architecture stays exactly where it was.
Conclusion
TCP/IP is the communication architecture that holds the internet together, a family of protocols spread across four layers. IP solves addressing, TCP takes care of reliable transport, and supporting protocols such as ICMP, ARP and DNS sit around them.
That split by layers is what lets you troubleshoot better. A problem lives in the name (DNS), in delivery (IP), in the connection (TCP) or in the application, and now you can narrow it down. You do not need to memorise specifications. Keep the map in your head, know who does what, and every network problem turns into a process of elimination.
Frequently asked questions
Are TCP/IP and the OSI model the same thing?
No. OSI is a theoretical model of seven layers, and TCP/IP is the practical model of four that was actually implemented. That is why they are so often explained together: people talk about «layer 3» (the OSI network layer) to refer to the internet layer of TCP/IP.
What is the difference between TCP and IP?
IP deals with addressing and routing. It decides which way each packet goes and towards which machine. TCP deals with reliable transport. It opens the connection, acknowledges delivery, retransmits what is lost and reorders what arrives out of sequence. They work at different layers and need each other.
What is the difference between TCP and UDP?
TCP guarantees delivery. It opens a connection, acknowledges and retransmits. UDP guarantees nothing, but it is lighter and faster. You choose based on what the application needs. TCP suits the web, email and downloads. UDP suits DNS, voice, real-time video and online gaming.
Why does the internet use TCP/IP and not another protocol?
Because it was born to be independent of the vendor and of the technology behind each network, and its layered design lets it evolve without being rebuilt from scratch. Other protocols work in closed environments, but they do not offer that neutrality, which is precisely what a worldwide network made of different networks needs.
Does TCP/IP work the same way with IPv6?
Yes. IPv6 changes addressing and the packet format, but the layered model and the rest of the family stay the same. What is common today is dual stack: a device has both IPv4 and IPv6 and picks whichever is available on each connection.