The TCP/IP Model

Introduction

Every time you open a website, send a message, upload a file, or call an API, data travels between devices over a network.

From a developer’s perspective, this process looks simple:

const response = await fetch("https://api.example.com/users");

const users = await response.json();

We provide a URL, send a request, and receive a response. The browser and operating system handle most of the complexity behind the scenes.

But several important questions remain:

• How does the computer know where to send the request?
• How does the data travel across different networks?
• What happens if some data is lost along the way?
• How does the receiving computer put everything back in the correct order?
• How do two computers establish and terminate a connection?
• What actually happens when we call fetch()or axios.post()?

To answer these questions, we need to understand two closely related concepts: the TCP/IP model and the Transmission Control Protocol (TCP).

The TCP/IP model explains how network communication is organized into layers. TCP is one of the protocols operating within that model, responsible for providing reliable, ordered communication between applications.

Let’s start with the big picture and gradually move toward the details.

1. Understanding the TCP/IP Model

What is the TCP/IP model?

The TCP/IP model, also known as the Internet protocol suite, describes how computers communicate across interconnected networks.

It organizes network communication into layers. Each layer has a specific responsibility and works with the layers above and below it.

Imagine sending a parcel to someone in another city.

You put your items in a box, write the recipient’s address on it, hand it to a delivery company, and let the delivery network determine how to transport it.

You do not need to understand every truck, warehouse, or road involved in the delivery. Each participant has a defined responsibility.

Network communication follows a similar idea.

An application creates data. Transport protocols manage communication between applications. IP handles addressing and forwarding between networks. Link technologies deliver data across an individual network connection.

Together, these responsibilities allow applications running on different devices and operating systems to communicate.

A brief history

The TCP/IP protocols emerged from research into interconnected computer networks during the 1970s, including work supported by DARPA.

One important goal was to allow different kinds of networks to communicate with one another. Instead of requiring every computer to use the same hardware or local networking technology, the architecture allowed different networks to interconnect through a common internet protocol.

The TCP/IP protocol suite was implemented, tested, and refined in real networks. It became the foundation of the modern Internet.

The OSI model, meanwhile, provides a seven-layer reference framework that is widely used to teach and reason about networking.

These models serve related but different purposes. OSI is a conceptual reference model; TCP/IP describes the architecture around the protocols that power Internet communication.

Why do we need layers?

Consider sending an API request from a laptop to a remote server.

The application needs a way to describe its request. It should not have to implement packet routing, network addressing, Wi-Fi transmission, or retransmission after every possible transmission failure.

Instead, responsibilities are separated:

• The application defines the meaning and format of the request.
• The transport layer manages communication between applications.
• The Internet layer moves packets between networks.
• The network access layer delivers data over a local link.

This separation makes it possible to replace one technology without redesigning the entire communication system.

For example, a web application can communicate with a server through Wi-Fi, Ethernet, or a mobile network without needing to understand the details of each technology.

2. The Four Layers of the TCP/IP Model

The traditional TCP/IP model contains four layers:

1. Application
2. Transport
3. Internet
4. Network Access, also called the Link layer

Some educational resources use a five-layer model by separating the physical layer from the data link layer. Both representations are useful, depending on how much detail you want to study.

Layer 4: Application Layer

Responsibility: Provides protocols through which applications exchange meaningful information.

When you visit a website, send an email, or look up a domain name, application-layer protocols define how the relevant messages are structured and interpreted.

Common examples include:

• HTTP and HTTPS — web communication
• DNS — translating domain names into network addresses
• SMTP — sending email
• DHCP — obtaining network configuration
• SSH — secure remote access
• FTP — file transfer

For example, a simplified HTTP request might look like this:

GET /users HTTP/1.1
Host: api.example.com
Accept: application/json

This describes what the client wants: the /usersresource from api.example.com.

The application layer defines the request’s meaning. It does not decide which router the data should pass through or how Wi-Fi transmits the bits.

In the TCP/IP model, this layer combines responsibilities associated with the OSI Application, Presentation, and Session layers.

Layer 3: Transport Layer

Responsibility: Provides communication between applications running on different hosts.

Two important transport protocols are TCP and UDP.

TCP (Transmission Control Protocol) provides a reliable, ordered byte stream. It uses sequence numbers, acknowledgments, retransmissions, flow control, and congestion control to manage communication.

UDP (User Datagram Protocol) provides datagram-based communication without TCP’s built-in delivery and ordering guarantees.

Their characteristics suit different requirements.

For example, downloading a file generally requires complete, ordered data. A real-time application may prefer minimizing delay over retransmitting every lost piece of information.

TCP and UDP also use port numbers to help deliver incoming data to the appropriate application endpoint.

An IP address identifies a network interface or host address in the network context. A port identifies a transport endpoint associated with an application or service.

Layer 2: Internet Layer

Responsibility: Provides logical addressing and moves packets across interconnected networks.

The Internet layer allows a host on one network to communicate with a host on another.

The main protocol is IP, including IPv4 and IPv6.

Other important protocols include ICMP, which supports network control and error reporting, and protocols used for Internet-layer multicast and security functions.

Suppose your computer is communicating with a server in another country.

Your computer creates an IP packet with a source IP address and a destination IP address. Routers examine the destination address and forward the packet toward the destination network.

The route may contain several routers. Each router makes forwarding decisions based on its routing information.

IP is connectionless: it does not establish a TCP-style connection before forwarding individual packets. Consequently, IP itself does not provide TCP’s guarantees of reliable, in-order delivery.

An important distinction: ARP is used primarily in IPv4 networks to resolve an IPv4 address to a link-layer address on the local network. It is not a replacement for IP. IPv6 uses Neighbor Discovery rather than ARP.

Layer 1: Network Access or Link Layer

Responsibility: Delivers data over a particular local network link.

Examples include:

• Ethernet
• Wi-Fi (IEEE 802.11)
• Point-to-Point Protocol (PPP)

Depending on the technology, this layer handles framing, local addressing, medium access, and error detection.

For Ethernet and Wi-Fi, link-layer frames normally contain source and destination MAC addresses.

When a computer sends a packet to a destination outside its local network, the frame is usually addressed to the local router or next hop—not directly to the remote server’s MAC address.

The router removes the incoming link-layer frame and forwards the IP packet through another link using a new frame appropriate for that link.

The physical transmission may use electrical signals, light, or radio waves. In the traditional four-layer TCP/IP model, physical transmission details are included within the broad network access layer. In the five-layer model, they are described separately in the Physical layer.

TCP/IP layers at a glance

The mapping is approximate. The TCP/IP and OSI models do not divide every responsibility in exactly the same way.

3. How Data Travels Through the TCP/IP Stack

Understanding the layers is useful. Understanding how they work together is even more important.

Imagine you call an API from a web application:

await fetch("https://api.example.com/orders", {
  method: "POST",
  headers: {
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    productId: 42,
    quantity: 2
  })
});

At the application level, you are sending a request containing JSON data.

But the JSON object is not directly transmitted across the Internet as a single JavaScript object. The browser and operating system convert the request into the appropriate protocol representations.

For a typical HTTPS connection using TCP, the process can be simplified as follows.

Step 1: Application data

The application creates an HTTP request, including information such as the method, path, headers, and body.

When HTTPS is used over TCP, TLS also participates by protecting application data before it is carried by TCP.

Step 2: Transport encapsulation

TCP takes bytes from the outgoing data stream and places them into TCP segments.

A TCP header contains fields such as:

• Source port
• Destination port
• Sequence number
• Acknowledgment number
• Control flags
• Receive-window information
• Checksum

The source and destination ports identify the relevant transport endpoints.

TCP also assigns sequence numbers to the bytes in its stream so the receiver can track which bytes have arrived and which bytes are still expected.

Step 3: Internet encapsulation

IP places the TCP segment inside an IP packet.

The IP header contains information such as:

• Source IP address
• Destination IP address
• Protocol identifier
• Other fields required for forwarding and packet handling

The destination IP address helps routers forward the packet toward its destination.

Step 4: Link-layer encapsulation

The packet is placed into a link-layer frame, such as an Ethernet or Wi-Fi frame.

On a typical Ethernet network, the frame includes local source and destination MAC addresses, along with an error-detection field.

The frame is then transmitted across the current link.

Step 5: Physical transmission

The frame is represented by signals appropriate for the network technology: electrical signals over copper, light through optical fiber, or radio waves over wireless.

At the receiving device, the process is reversed. The link layer processes the frame, IP processes the packet, TCP processes the segment, and the application eventually receives the appropriate data.

Visualizing encapsulation

Application data
       |
       v
+---------------------------+
| TCP header | Application  |  TCP segment
|            | data         |
+---------------------------+
       |
       v
+----------------------------------+
| IP header | TCP segment          |  IP packet
+----------------------------------+
       |
       v
+----------------------------------------------+
| Link header | IP packet | Link trailer       |  Frame
+----------------------------------------------+
       |
       v
 Electrical signals / light / radio transmission

Each layer adds information required by its own function. At the receiving end, the corresponding layers process and remove those headers as needed.

This process is called encapsulation at the sender and decapsulation at the receiver.

What are the different data units called?

Networking terminology depends on the layer:

• Application layer: message or application data
• TCP: segment
• UDP: datagram
• IP: packet or IP datagram
• Link layer: frame
• Physical transmission: bits represented by physical signals

People sometimes use the word “packet” informally for several of these units. When studying TCP, it is useful to distinguish them carefully.

One more important point: an HTTP request does not necessarily correspond to one TCP segment or one IP packet. TCP is a byte-stream protocol. It decides how bytes are carried in segments according to available data, the maximum segment size, network conditions, and other factors.

4. Introduction to TCP

Now that we understand where TCP fits into the network stack, let’s explore why it exists and how it works.

TCP stands for Transmission Control Protocol. It is a connection-oriented transport protocol designed to provide reliable, ordered delivery of a byte stream between two endpoints.

Consider sending a file over a network.

If you send a file containing one million bytes, you do not want the receiving application to silently lose a few bytes, receive the bytes in the wrong order, or unknowingly accept corrupted data.

TCP helps protect the application from these transport-level problems.

However, TCP does not make the underlying network perfectly reliable. Instead, it detects certain problems and uses mechanisms such as acknowledgments and retransmissions to recover when possible.

If communication fails for long enough, TCP can report an error rather than guaranteeing that the data will eventually arrive.

Why can't we send everything in one piece?

Network technologies have limits on how much data they can carry efficiently in one transmission unit.

For example, Ethernet typically uses a maximum frame size that constrains the size of the IP packet that can be carried without fragmentation. The usable space for TCP data is smaller still because protocol headers occupy part of the packet.

A large amount of application data therefore needs to be carried in multiple TCP segments.

TCP does not require developers to manually split their request into these segments. The networking stack handles that work.

Suppose an application supplies 4,000 bytes to a TCP connection. For an illustrative example, assume TCP carries those bytes in two segments, each containing 2,000 bytes of data.

The first segment contains part of the stream. The second contains the following bytes.

The receiver uses sequence numbers and acknowledgments to track the byte stream.

Real networks may use many smaller segments, and the exact sizes are determined by the applicable limits and network conditions.

What does TCP provide?

TCP has several important responsibilities.

1. Reliable delivery

TCP tracks transmitted bytes and uses acknowledgments, timers, and retransmissions to recover from detected loss when possible.

2. Ordered delivery

The receiving application sees the byte stream in sequence, even if underlying IP packets arrive out of order.

3. Error detection

TCP uses a checksum to detect corruption in the TCP segment. A segment that fails checksum validation is not accepted as valid TCP data.

4. Flow control

The receiver advertises how much data it is prepared to accept. This helps prevent a fast sender from overwhelming the receiver’s available buffering capacity.

5. Congestion control

TCP adjusts transmission behavior in response to network congestion. This helps prevent senders from overwhelming the network.

6. Full-duplex communication

Both endpoints can send and receive data independently over the same connection.

These functions explain why TCP is useful for applications that depend on reliable, ordered transfer.

5. How TCP Establishes a Connection: The Three-Way Handshake

Before two endpoints exchange data over a new TCP connection, they generally perform a process called the three-way handshake.

The handshake synchronizes their initial sequence numbers and helps establish that both directions of communication are working.

It consists of three steps:

1. SYN
2. SYN-ACK
3. ACK

Let’s examine each step.

Step 1: The client sends SYN

A client wants to establish a TCP connection with a server.

It sends a TCP segment with the SYN flag set.

The segment contains the client's initial sequence number, abbreviated as ISN.

For this example, assume:

Client ISN = 1000

The outgoing segment is:

Client  ->  Server

Flags: SYN
Seq:   1000

The SYN flag indicates a request to synchronize sequence numbers and establish a connection.

The sequence number establishes the starting point for the client's sequence-number space.

In simple terms, the client is saying:

“I want to establish a TCP connection, and this is my initial sequence number.”

Step 2: The server responds with SYN-ACK

The server receives the SYN and responds with a segment that sets both SYN and ACK.

Assume the server chooses this initial sequence number:

Server ISN = 2000

The server replies:

Server  ->  Client

Flags: SYN, ACK
Seq:   2000
Ack:   1001

Why is the acknowledgment number 1001 rather than 1000?

Because the SYN flag consumes one sequence number.

The server has received the client's SYN at sequence number 1000. It acknowledges that control information by indicating the next expected sequence number: 1001.

The server also supplies its own initial sequence number, 2000.

In simple terms, the server is saying:

“I received your connection request. I am willing to establish the connection, and this is my initial sequence number.”

Step 3: The client sends ACK

The client receives the server's SYN-ACK and sends an acknowledgment:

Client  ->  Server

Flags: ACK
Seq:   1001
Ack:   2001

Why is the acknowledgment number 2001?

The server's SYN also consumes one sequence number. The client therefore acknowledges the server's initial sequence number by sending Ack = 2001.

The handshake is now complete.

Both endpoints have synchronized their initial sequence numbers and acknowledged the peer's SYN.

Application data can now be exchanged.

The complete three-way handshake

           CLIENT                         SERVER
              |                              |
              |  SYN                         |
              |  Seq = 1000                  |
              |----------------------------->|
              |                              |
              |  SYN-ACK                     |
              |  Seq = 2000                  |
              |  Ack = 1001                  |
              |<-----------------------------|
              |                              |
              |  ACK                         |
              |  Seq = 1001                  |
              |  Ack = 2001                  |
              |----------------------------->|
              |                              |
              |      CONNECTION READY        |

Why three steps?

Each side needs to synchronize its own sending sequence numbers and acknowledge the sequence number proposed by the other side.

The third message confirms that the client received the server's initial sequence number.

The handshake also helps ensure that the connection is not established merely because an old or delayed connection request has appeared on the network.

Real systems choose initial sequence numbers using mechanisms designed to make them difficult to predict. The fixed numbers above are only for illustration.

Remember: establishing a TCP connection does not, by itself, encrypt the communication or authenticate the server's identity. Those are separate responsibilities, commonly handled by TLS when HTTPS is used.

6. TCP Sequence Numbers and Acknowledgments

Sequence numbers and acknowledgment numbers are central to TCP's reliability.

To understand them, first remember this rule:

TCP sequence numbers count bytes, not packets.

Every byte in the TCP stream occupies a position in the sequence-number space.

The sequence number in a segment identifies the sequence number of its first data byte, except that SYN has special sequencing behavior.

What does a sequence number mean?

Suppose a TCP segment contains:

Seq = 1001
Data length = 2000 bytes

The first byte has sequence number 1001.

The segment contains the following byte sequence numbers:

1001, 1002, 1003, ... , 3000

That is 2,000 bytes.

The next expected byte is 3001.

Therefore, if the receiver has successfully received this entire byte range in sequence, it can acknowledge:

Ack = 3001

What does an acknowledgment number mean?

An acknowledgment number identifies the next byte the receiver expects.

For example:

Ack = 3001

means:

“I have received all bytes up to 3000 in the relevant sequence, and I expect byte 3001 next.”

TCP acknowledgments are generally cumulative. An acknowledgment for byte 3001 confirms receipt of the preceding byte range, not merely the arrival of one particular packet.

Acknowledgments can also be sent alongside outgoing data, so an acknowledgment does not always need to occupy a separate segment.

Why are these numbers important?

Suppose a sender transmits three segments:

Segment 1: bytes 1001–2000
Segment 2: bytes 2001–3000
Segment 3: bytes 3001–4000

Imagine that Segment 2 is lost while Segments 1 and 3 arrive.

The receiver cannot acknowledge the entire continuous byte range through 4000. It can acknowledge the contiguous bytes it has received, while TCP mechanisms may indicate that later bytes are also present.

The sender can use acknowledgments, retransmission timers, and other loss-recovery mechanisms to recover missing data.

When the missing bytes arrive, the receiver can deliver the restored byte stream in order to the application.

This is one of the essential differences between TCP and a transport protocol that does not provide TCP's built-in reliable, ordered byte-stream service.

7. TCP Data Transfer: A Worked Example

Let's put these concepts together using actual sequence numbers.

Assumptions

Suppose a client wants to send 4,000 bytes to a server.

For simplicity, assume:

• The client’s initial sequence number is 1000.
• The server’s initial sequence number is 2000.
• The client sends all 4,000 bytes in two segments of 2,000 bytes each.
• Both segments arrive successfully and in order.
• The server does not send application data during this example.

The segment sizes are deliberately simplified for learning. Actual TCP segment sizes vary with the network and the connection.

Segment 1: Client sends the first 2,000 bytes

The client's SYN used sequence number 1000.

Therefore, the first application-data byte begins at sequence number 1001.

The first segment contains:

Client  ->  Server

Seq:         1001
Data length: 2000 bytes
Byte range:  1001–3000

After receiving all these bytes, the server expects byte 3001 next.

It acknowledges:

Server  ->  Client

Ack: 3001

The acknowledgment confirms receipt of the contiguous byte range through byte 3000.

Segment 2: Client sends the remaining 2,000 bytes

The client continues from the next sequence number.

Client  ->  Server

Seq:         3001
Data length: 2000 bytes
Byte range:  3001–5000

The server receives the bytes and acknowledges the next expected byte:

Server  ->  Client

Ack: 5001

The sender can now infer that the receiver has acknowledged the complete 4,000-byte data range in this example.

The complete example

The data segments can also carry acknowledgment information in their TCP headers. The table leaves unneeded fields blank to focus on the sequence-number calculation.

What if a segment is lost?

Now suppose Segment 2 never reaches the server.

The client has sent the data, but the server has not received the complete range.

TCP can detect the problem through mechanisms such as retransmission timeouts or duplicate acknowledgments, depending on the circumstances.

The sender retransmits the missing data when TCP's loss-recovery logic calls for it.

The server can then reconstruct the continuous byte stream and pass the appropriate bytes to the receiving application.

TCP may retransmit data without the application having to issue the original write operation again.

However, this does not mean TCP can overcome every failure. If the network or peer remains unavailable, the connection may eventually time out or fail.

8. Flow Control and Congestion Control

These two mechanisms are related to TCP's ability to transmit data efficiently, but they solve different problems.

Flow control: Protecting the receiver

A receiver has finite memory and processing capacity.

If a sender transmits data faster than the receiver can accept it, the receiver's available buffer space may run out.

TCP uses a receive window to communicate how much additional data the receiver is currently prepared to accept.

The sender uses this information to avoid overwhelming the receiver.

Imagine a small cup being filled from a large water container. The sender must regulate how much water it pours so the cup does not overflow.

That is the basic idea behind flow control.

Congestion control: Protecting the network

Even when the receiver can accept data quickly, the network path may become congested.

For example, several senders might transmit large volumes of traffic through the same router or network link.

TCP congestion control adjusts the sender's behavior in response to network conditions. It helps reduce excessive traffic and encourages more efficient use of available capacity.

Flow control considers the receiver's capacity. Congestion control considers the network's capacity.

Both matter when transferring large amounts of data.

9. How TCP Terminates a Connection: The Four-Way Handshake

TCP supports full-duplex communication. This means both endpoints can send data independently.

As a result, finishing one direction does not automatically mean that the other direction has finished.

TCP uses FIN and ACK flags to close the two directions in an orderly manner.

A typical graceful connection termination can be illustrated as four steps.

Step 1: The client sends FIN

Assume the client has sent all 4,000 application-data bytes from the previous example.

The byte range was 1001 through 5000, so the next sequence number is 5001.

The client sends:

Client  ->  Server

Flags: FIN
Seq:   5001

FIN indicates that the client has finished sending data on this connection.

FIN consumes one sequence number, just like SYN.

It does not mean the server must immediately stop sending data. The server can still send data in the other direction while the connection is half-closed.

In simple terms, the client is saying:

“I have no more data to send.”

Step 2: The server acknowledges FIN

The server acknowledges the client's FIN:

Server  ->  Client

Flags: ACK
Ack:   5002

Why 5002?

The FIN was sent at sequence number 5001 and consumes one sequence number. The next expected sequence number is therefore 5002.

The client has now received an acknowledgment of its request to finish sending.

The server's direction of communication may still remain open.

Step 3: The server sends its own FIN

When the server has finished sending its own data, it can send a FIN.

In our simplified example, the server has not sent application data. Its SYN used sequence number 2000, so its next sequence number is 2001.

The server sends:

Server  ->  Client

Flags: FIN, ACK
Seq:   2001
Ack:   5002

The ACK acknowledges the client's FIN. The FIN indicates that the server has also finished sending data.

This segment can carry both control flags at once.

In simple terms, the server is saying:

“I have acknowledged your request to finish, and I have no more data to send either.”

Step 4: The client acknowledges the server's FIN

The client acknowledges the server's FIN:

Client  ->  Server

Flags: ACK
Seq:   5002
Ack:   2002

The server's FIN used sequence number 2001 and consumed one sequence number. The client therefore acknowledges it with Ack = 2002.

Both directions have now been closed through the graceful exchange.

The complete connection termination

           CLIENT                         SERVER
              |                              |
              |  FIN                         |
              |  Seq = 5001                  |
              |----------------------------->|
              |                              |
              |  ACK                         |
              |  Ack = 5002                  |
              |<-----------------------------|
              |                              |
              |  FIN, ACK                    |
              |  Seq = 2001                  |
              |  Ack = 5002                  |
              |<-----------------------------|
              |                              |
              |  ACK                         |
              |  Seq = 5002                  |
              |  Ack = 2002                  |
              |----------------------------->|
              |                              |
              |     GRACEFUL CLOSURE         |

This example assumes the server has no additional application data to send. If it sends data, its sequence numbers will advance accordingly.

The four steps represent a common graceful-close exchange. In real traffic, acknowledgments and FIN flags may be combined differently, so a packet capture does not always show four separate packets.

Why does termination differ from connection establishment?

During setup, a SYN-ACK segment combines two purposes: the server acknowledges the client's SYN while sending its own SYN.

During termination, each endpoint needs to finish its own sending direction. One endpoint may acknowledge the peer's FIN before it is ready to send its own FIN.

That is why the traditional explanation uses a three-way handshake for setup and a four-step exchange for graceful closure.

One final detail: the endpoint that actively closes the connection typically enters the TCP TIME_WAITstate for a period. This helps protect against delayed segments from the old connection and allows retransmitted FIN segments to be handled correctly. Therefore, an endpoint's internal TCP state may not disappear immediately after the final ACK is sent.

10. Why TCP Is Called a Reliable Byte Stream

It is tempting to think of TCP as a mechanism that sends packets from one computer to another.

A more useful way to understand it is this:

TCP gives an application an ordered byte stream, even though the underlying network carries individual packets.

Suppose an application writes these bytes:

Hello World

The TCP receiver might receive them through several segments, or some segments might contain bytes from more than one application write.

TCP ensures that the receiving application gets the bytes in the proper order.

However, TCP does not preserve the boundaries of individual application writes.

For example, if a program performs two writes, one containing Helloand another containing World, the receiving program might read all the bytes together, or it might receive them through multiple reads.

The receiving application must use its own message format, framing, or protocol to determine where one application-level message ends and another begins.

This distinction is especially important when implementing application protocols over TCP sockets.

What TCP does not guarantee

TCP has important limitations.

TCP does not guarantee that the remote application processed your request.

A successful TCP acknowledgment confirms that bytes have been received by the peer's TCP implementation, not that the application has finished processing them or committed a database transaction.

TCP does not encrypt the data.

Encryption and server authentication are typically provided by TLS for HTTPS connections using TCP.

TCP cannot guarantee successful delivery if the connection fails permanently.

It attempts to deliver bytes reliably. If communication cannot be recovered, it can report a failure to the application.

These distinctions matter when building APIs and distributed systems. An application may still need timeouts, retries, request identifiers, idempotency, and error handling.

11. TCP/IP in a Real Web Request

Let's connect everything back to our original fetch()example.

Suppose your browser needs to send a request to:

https://api.example.com/orders

A simplified view of the process is:

1. DNS resolution: The browser or operating system resolves the hostname to an IP address, using cached or newly obtained DNS information as necessary.
2. Connection setup: For a typical HTTPS-over-TCP connection, the client establishes a TCP connection with the server. An existing connection may be reused.
3. TLS setup: If needed, the client and server establish the TLS security context to protect the HTTPS communication.
4. Application request: The HTTP request is prepared and passed through the protocol stack.
5. Encapsulation: Data is carried through TCP segments, IP packets, and link-layer frames.
6. Routing: Routers forward IP packets toward the destination network. Different packets may not necessarily follow an identical route.
7. TCP processing at the server: The server's TCP stack validates segments, tracks sequence numbers, acknowledges received bytes, handles retransmissions as needed, and presents the ordered byte stream to the application.
8. Application processing: The web server and application interpret the HTTP request and prepare a response.
9. Response delivery: The response travels back through the networking stack, and the client receives it.

This is a simplified explanation. In practice, DNS may be cached, a TCP connection might already exist, and newer protocols such as HTTP/3 use QUIC over UDP instead of TCP.

The key idea is that the application does not need to implement routing, link-layer framing, or TCP retransmission logic itself. Each layer performs a different part of the communication process.

12. Common Misconceptions About TCP/IP

Misconception 1: Every HTTP request becomes exactly one TCP segment

Not true.

TCP carries a byte stream. One request may span several TCP segments, and a segment may carry data from different application writes. TCP segmentation is not defined by the boundaries of JavaScript objects or application writes.

Misconception 2: An IP packet contains the MAC address of the final server

Not usually.

On Ethernet or Wi-Fi networks, the link-layer destination address identifies the receiver on the current link, typically the next hop. As a packet passes through routers, each outgoing link uses its own frame.

The IP destination generally continues to identify the intended destination host, although mechanisms such as Network Address Translation can change IP addresses.

Misconception 3: An ACK means the server has completed the request

No.

A TCP acknowledgment confirms receipt of a contiguous range of bytes by the receiving TCP endpoint. It does not prove that the remote application has processed the request, written data to storage, or completed a business operation.

Misconception 4: TCP prevents all data loss

TCP attempts to recover from lost or damaged segments by using retransmission and other mechanisms. It cannot guarantee that a connection will survive every network failure.

If a connection cannot recover, the application may receive an error.

Misconception 5: TCP sequence numbers identify packets

Sequence numbers identify positions in a byte stream. Several bytes in a segment are represented by a sequence range, and acknowledgment numbers identify the next expected byte.

Misconception 6: Closing the connection only requires one side to say goodbye

TCP is full duplex. Each endpoint can independently finish sending data, so graceful closure requires the two sending directions to be shut down and acknowledged.

Conclusion

TCP/IP provides the architecture that allows applications to communicate across diverse networks.

The layers divide communication into manageable responsibilities. The application layer defines meaningful messages, the transport layer manages application-to-application communication, the Internet layer provides logical addressing and forwarding, and the network access layer handles delivery across individual links.

TCP builds on this architecture to provide a reliable, ordered byte stream. It uses a handshake to establish a connection, sequence numbers and acknowledgments to track data, retransmissions to recover from detected loss, flow control to protect receivers, and congestion control to respond to network conditions.

The three-way handshake establishes the initial connection. The data-transfer mechanisms keep track of the byte stream. The graceful-close exchange allows both endpoints to finish sending independently.

The next time you write:

await fetch("https://api.example.com/orders");

remember that the request relies on multiple layers of protocols working together. What looks like a single function call in your application involves addressing, encapsulation, routing, transport-level state, acknowledgments, and many other details.

Understanding these mechanisms changes how you think about networking. Instead of treating the Internet as a black box, you can reason about how data moves, where failures may occur, and which layer is responsible for handling them.

Further Reading

For readers who want to study the underlying specifications, these documents are useful starting points:

• RFC 9293 — Transmission Control Protocol (TCP)
• RFC 1122 — Requirements for Internet Hosts: Communication Layers
• RFC 791 — Internet Protocol
• RFC 1180 — A TCP/IP Tutorial