---
title: "14 — Networks, Protocols, and the Day-to-Day Tools"
uid: networks-protocols-and-tools
tags: ["firewalls", "proxies", "collaboration", "roadmap:software-architect", "networking", "tcp-ip", "https", "git", "http", "osi"]
excerpt: "Networks are layered models — every protocol and device lives at a specific layer. Name the layer before reaching for a fix, and you've named where to debug."
date: 2026-08-13T03:27:39+0000
source: https://www.aveshina.my.id/en/blog/networks-protocols-and-tools
---

OSI models and protocol acronyms were my least favorite cluster until I found its one habit. The model that organized it: **networks are layered models, and every protocol and device lives at a specific layer — name the layer, and you've named where to debug** [1]. That habit — naming the layer before reaching for a fix — is the practical payoff of the whole cluster, and it carries over from networking into almost everything else an architect does.

A computer network is a set of computers sharing resources, communicating over common protocols across wired, optical, and wireless connections arranged in various topologies [1]. The architect's job isn't to build the network; it's to design systems that communicate across it correctly and securely.

## The layered models: OSI and TCP/IP

The **OSI model** has seven layers; the **TCP/IP model** is a more summarized four-layer framework that actually underlies how the internet works [2][3]. The roadmap's point is that these models help a developer design systems for interoperability — they describe the distinct responsibilities (physical link, network routing, transport, application) so you can reason about where a failure lives.

```figure
<svg viewBox="0 0 600 340" xmlns="http://www.w3.org/2000/svg" class="my-6 w-full max-w-2xl" role="img" aria-label="OSI 7-layer model mapped to TCP/IP 4-layer model. Left column: OSI layers 7 Application, 6 Presentation, 5 Session, 4 Transport, 3 Network, 2 Data Link, 1 Physical. Right column: TCP/IP layers Application (maps to OSI 5-6-7), Transport (4), Internet (3), Link (1-2).">
  <g font-family="ui-sans-serif, system-ui, sans-serif" text-rendering="geometricPrecision">
    <text x="160" y="24" font-size="13" font-weight="700" fill="#1e1b4b" text-anchor="middle">OSI — 7 layers</text>
    <text x="460" y="24" font-size="13" font-weight="700" fill="#134e4a" text-anchor="middle">TCP/IP — 4 layers</text>

    <!-- OSI layers -->
    <g font-size="11" fill="#1e1b4b">
      <rect x="60" y="40" width="200" height="32" rx="5" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.3"/>
      <text x="80" y="60" font-weight="700">7</text><text x="110" y="60">Application</text>

      <rect x="60" y="76" width="200" height="32" rx="5" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.3"/>
      <text x="80" y="96" font-weight="700">6</text><text x="110" y="96">Presentation</text>

      <rect x="60" y="112" width="200" height="32" rx="5" fill="#e0e7ff" stroke="#6366f1" stroke-width="1.3"/>
      <text x="80" y="132" font-weight="700">5</text><text x="110" y="132">Session</text>

      <rect x="60" y="148" width="200" height="32" rx="5" fill="#ccfbf1" stroke="#0d9488" stroke-width="1.3"/>
      <text x="80" y="168" font-weight="700">4</text><text x="110" y="168">Transport</text>

      <rect x="60" y="184" width="200" height="32" rx="5" fill="#fef9c3" stroke="#ca8a04" stroke-width="1.3"/>
      <text x="80" y="204" font-weight="700">3</text><text x="110" y="204">Network</text>

      <rect x="60" y="220" width="200" height="32" rx="5" fill="#fce7f3" stroke="#db2777" stroke-width="1.3"/>
      <text x="80" y="240" font-weight="700">2</text><text x="110" y="240">Data Link</text>

      <rect x="60" y="256" width="200" height="32" rx="5" fill="#fce7f3" stroke="#db2777" stroke-width="1.3"/>
      <text x="80" y="276" font-weight="700">1</text><text x="110" y="276">Physical</text>
    </g>

    <!-- mapping lines -->
    <path d="M260,72 C310,72 320,60 360,60" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>
    <path d="M260,96 C310,96 320,60 360,60" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>
    <path d="M260,128 C310,128 320,60 360,60" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>
    <path d="M260,164 C310,164 320,148 360,148" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>
    <path d="M260,200 C310,200 320,196 360,196" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>
    <path d="M260,236 C310,236 320,244 360,244" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>
    <path d="M260,272 C310,272 320,244 360,244" fill="none" stroke="#64748b" stroke-width="1.2" stroke-dasharray="3 3"/>

    <!-- TCP/IP layers -->
    <g font-size="11" fill="#134e4a">
      <rect x="360" y="44" width="200" height="52" rx="5" fill="#ccfbf1" stroke="#0d9488" stroke-width="1.3"/>
      <text x="380" y="74" font-weight="700">Application</text>
      <text x="480" y="74" font-size="9.5" fill="#0f766e">HTTP, DNS, …</text>

      <rect x="360" y="128" width="200" height="40" rx="5" fill="#ccfbf1" stroke="#0d9488" stroke-width="1.3"/>
      <text x="380" y="153" font-weight="700">Transport</text>
      <text x="480" y="153" font-size="9.5" fill="#0f766e">TCP, UDP</text>

      <rect x="360" y="180" width="200" height="40" rx="5" fill="#ccfbf1" stroke="#0d9488" stroke-width="1.3"/>
      <text x="380" y="205" font-weight="700">Internet</text>
      <text x="480" y="205" font-size="9.5" fill="#0f766e">IP</text>

      <rect x="360" y="228" width="200" height="56" rx="5" fill="#ccfbf1" stroke="#0d9488" stroke-width="1.3"/>
      <text x="380" y="260" font-weight="700">Link</text>
      <text x="480" y="260" font-size="9.5" fill="#0f766e">Ethernet, Wi-Fi</text>
    </g>

    <text x="300" y="316" font-size="10.5" fill="#64748b" text-anchor="middle" font-style="italic">TCP/IP collapses OSI's seven into four practical layers that map to real protocols</text>
  </g>
</svg>
```

The reason both models exist: OSI is the teaching/reference model (more granular, good for thinking), and TCP/IP is the one the internet actually runs on (simpler, maps directly to real protocols like IP, TCP, HTTP) [3]. An architect reasons in TCP/IP and references OSI when the granularity helps.

## HTTP and HTTPS: the application layer

At the application layer lives **HTTP**, the protocol underlying most web communication — defining how clients and servers exchange requests and responses [4]. **HTTPS** adds encryption on top of HTTP using TLS, protecting data in transit from being read or altered [4]. Nearly every modern web architecture relies on understanding how these protocols handle requests, headers, and status codes. The architect-relevant details: HTTP methods (GET, POST, PUT, DELETE), status codes, headers, and the fact that HTTPS is HTTP wrapped in TLS rather than a different protocol.

## Proxies and firewalls: the intermediaries

Between client and server sit two important categories of intermediary.

A **proxy** is an intermediary server between a client and destination, forwarding requests and often adding caching, load balancing, or filtering [5]. **Reverse proxies** sit in front of backend servers to distribute traffic and hide internal infrastructure; **forward proxies** sit in front of clients. Architects use proxies to improve performance, security, and manageability.

A **firewall** is a network security device that monitors and filters traffic based on an organization's security policies [6]. It sits between a trusted network and an untrusted one (often the internet), allowing or denying traffic by rule. The architect's concern is that the firewall policy has to permit the traffic the system needs — a system that works on a developer's machine can silently fail in production because a firewall rule blocks the port.

## The day-to-day tools

The roadmap tucks the collaboration tooling in alongside the technical skills, and they share a theme: they're how the work is tracked, communicated, and versioned.

- **Git** — the distributed version control system tracking changes to code over time, supporting branching and merging workflows that let teams develop features in isolation before combining them [7]. Almost every modern project relies on Git as its source-control foundation.
- **Slack** — the messaging layer connecting people to the information they need [8].
- **Trello** — a visual project-management tool based on boards, lists, and cards, popular for smaller teams or lightweight tracking [9].
- **Atlassian tools (Jira, Confluence, Bitbucket, etc.)** — support project tracking and documentation at scale: Jira manages tasks, sprints, and issues; Confluence stores documentation and design discussions [10]. Many enterprise teams standardize on these for both daily work tracking and long-term knowledge management.

These aren't architecture in the systems sense, but they're the substrate the architecture work happens on. An architect who can't read a Jira board or a Git diff is cut off from where the actual decisions get made and recorded.

## How I use this

When a system can't talk to another system, I walk the TCP/IP layers: is the link up, is routing (IP) reaching the host, is the transport (TCP) establishing, is the application (HTTP) getting a sane response? Most "it doesn't work" incidents collapse to one layer once I check them in order. Firewalls and proxies I treat as explicit design constraints — the architecture has to fit the firewall rules and route through the proxies the environment provides. And I keep the collaboration tools as first-class: a decision that isn't in Git, Confluence, or a tracked ticket might as well not exist, because no one will find it again.

## References

[1] "Networks," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/networks](https://roadmap.sh/software-architect/networks)

[2] Cloudflare, "What is the OSI model?," [Online]. Available: [https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/](https://www.cloudflare.com/learning/ddos/glossary/open-systems-interconnection-model-osi/)

[3] "TCP/IP Model," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/tcpip-model](https://roadmap.sh/software-architect/tcpip-model)

[4] "HTTP, HTTPS," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/http-https](https://roadmap.sh/software-architect/http-https)

[5] "Proxy server," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Proxy_server](https://en.wikipedia.org/wiki/Proxy_server)

[6] Cloudflare, "What is a Firewall?," [Online]. Available: [https://www.cloudflare.com/learning/security/what-is-a-firewall/](https://www.cloudflare.com/learning/security/what-is-a-firewall/)

[7] "Git," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/git](https://roadmap.sh/software-architect/git)

[8] Slack, "Getting Started with Slack," [Online]. Available: [https://slack.com/intl/en-in/help/categories/360000049043](https://slack.com/intl/en-in/help/categories/360000049043)

[9] Trello, "Trello Guide," [Online]. Available: [https://trello.com/guide](https://trello.com/guide)

[10] "Atlassian Tools," roadmap.sh — Software Architect. [Online]. Available: [https://roadmap.sh/software-architect/atlassian-tools](https://roadmap.sh/software-architect/atlassian-tools)

```quiz
Q: How does TCP/IP relate to the OSI model?
- TCP/IP replaces OSI and they have nothing in common
- TCP/IP is a summarized four-layer model that maps to OSI's seven layers and underlies the real internet
correct: 1
explain: OSI is the granular reference model; TCP/IP collapses it into four practical layers (Application, Transport, Internet, Link) that map directly to real protocols like HTTP, TCP, and IP.

Q: HTTPS is best described as…
- a completely different protocol from HTTP
- the same HTTP conversation wrapped in TLS encryption
correct: 1
explain: HTTPS isn't a separate protocol — it's HTTP wrapped in a TLS encryption layer, protecting data in transit from being read or altered.

Q: What's the difference between a forward proxy and a reverse proxy?
- A forward proxy sits in front of clients; a reverse proxy sits in front of backend servers
- A forward proxy caches data; a reverse proxy does not
correct: 0
explain: Forward proxies sit in front of clients (and hide them); reverse proxies sit in front of backend servers, distributing traffic and hiding internal infrastructure.

Q: A system works on a developer's laptop but fails to connect in production. A likely cause, given the networking cluster, is…
- the production firewall policy doesn't permit the traffic the system needs
- the developer's laptop uses a different programming language
correct: 0
explain: Firewalls enforce security policies between trusted and untrusted networks. A port or protocol allowed on a developer's machine can be blocked by a production firewall rule, causing silent connection failures.

Q: Why does the roadmap list Git, Slack, Trello, and Jira alongside networking for an architect?
- Because they're the substrate on which architecture work is tracked, versioned, and communicated
- Because an architect must host these tools personally
correct: 0
explain: These tools are where decisions get made, tracked, and recorded. A decision not captured in Git, Confluence, or a ticket is effectively invisible to the team.
```