DEV Community: REV

Kubernetes Ingress: HTTP and HTTPS Traffic Management

REV — Sun, 04 Oct 2026 08:33:01 +0000

Read the full article on medium

Introduction

A hands-on Kubernetes infrastructure project demonstrating how to expose a web application through Kubernetes Ingress, route HTTP/HTTPS traffic with Contour and Envoy, provision infrastructure with Terraform, configure DNS, and automate TLS certificates with cert-manager and Let's Encrypt.

The project was built and documented as a practical infrastructure walkthrough, with configuration files, terminal commands, Kubernetes resources, and runtime output used to verify each stage of the deployment.

Architecture:

flowchart TD
    Client["Internet<br/>HTTP / HTTPS"] --> LB["Google Cloud<br/>Load Balancer"]

    DNS["DNS"] --> LB
    LB --> Ingress["Kubernetes Ingress<br/>Contour"]
    Ingress --> Envoy["Envoy<br/>Proxy / Routing"]
    Envoy --> Service["ClusterIP<br/>Service"]
    Service --> Pods["Nginx Pods<br/>Web Server"]

    CM["cert-manager"] --> LE["Let's Encrypt"]
    LE --> Cert["TLS Certificate"]
    Cert --> Ingress

What this project demonstrates

Provisioning a Google Kubernetes Engine (GKE) cluster with Terraform
Connecting to and validating a Kubernetes cluster with "gcloud" and "kubectl"
Installing Contour as a Kubernetes Ingress controller
Using Envoy as the data-plane proxy
Deploying an Nginx web application
Exposing the application internally with a "ClusterIP" Service
Routing external traffic through an Ingress resource
Assigning and validating an external load balancer IP
Configuring DNS for the Ingress endpoint
Installing cert-manager
Issuing TLS certificates through Let's Encrypt
Configuring HTTPS on the Ingress
Verifying Kubernetes resources and certificate status from the command line

Technology Stack

Technology	Purpose
Kubernetes	Container orchestration
Google Kubernetes Engine (GKE)	Managed Kubernetes cluster
Terraform	Infrastructure provisioning
Contour	Kubernetes Ingress controller
Envoy	Layer 7 proxy and traffic routing
Nginx	Example web application
cert-manager	TLS certificate lifecycle management
Let's Encrypt	Certificate authority
DNS / DDNS	Domain-to-IP resolution
`kubectl`	Kubernetes administration
`gcloud`	Google Cloud authentication and cluster access

Project Structure

Click Kubernetes Ingress to access GitHub repository.

.
├── terraform/
│   ├── gke-cluster.tf
│   ├── variables.tf
│   └── ...
│
├── kubernetes/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   ├── ingress-updated.yaml
│   ├── letsencrypt-cm-issuer.yaml
│   └── certificate.yaml
│
└── README.md

Deployment Flow

1. Provision the GKE Cluster

Terraform is used to define and provision the Google Kubernetes Engine infrastructure.

Initialize and validate the Terraform configuration:

terraform init
terraform validate
terraform fmt

Apply the configuration:

terraform apply

The infrastructure creates the Kubernetes environment required for the remainder of the deployment.

The original implementation also configured the cluster's service account and node pool through Terraform.

2. Connect to the Cluster

Authenticate with Google Cloud:

gcloud auth login

Retrieve the cluster credentials:

gcloud container clusters get-credentials <cluster_name> \
  --zone <zone_name> \
  --project <project_id>

Validate the connection:

kubectl get nodes -o wide

Example runtime output from the original deployment showed two GKE nodes in the "Ready" state:

NAME                                   STATUS   VERSION
gke-dev-cluster-gke-np-...             Ready    v1.30.3-gke.1639000
gke-dev-cluster-gke-np-...             Ready    v1.30.3-gke.1639000

This provides runtime evidence that the cluster was provisioned successfully and was accessible through "kubectl".

3. Install Contour

Contour is deployed as the Kubernetes Ingress controller.

kubectl apply -f contour.yaml

Verify the controller and Envoy workloads:

kubectl get pods -n projectcontour -o wide

The deployment produced Contour and Envoy workloads across the GKE nodes.

The runtime output included:

contour-...    1/1   Running
contour-...    1/1   Running
envoy-...      2/2   Running
envoy-...      2/2   Running

This verifies that both the control-plane components and Envoy proxy instances were running successfully.

4. Deploy the Nginx Application

The application uses Nginx.

Apply the deployment:

kubectl apply -f deployment.yaml

Create the Kubernetes Service:

kubectl apply -f service.yaml

The application is exposed internally through a "ClusterIP" Service:

apiVersion: v1
kind: Service
metadata:
  name: gore-svc
spec:
  type: ClusterIP
  selector:
    app: gore
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80

"ClusterIP" keeps the application service internal to the cluster. Contour/Envoy provides the external entry point and routes requests to this service.

Verify the service:

kubectl get services -o wide

Example:

NAME       TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)
gore-svc   ClusterIP   34.118.238.166  <none>        80/TCP

5. Configure the Ingress

The Ingress resource connects the external traffic path to the internal application service.

Apply the configuration:

kubectl apply -f ingress.yaml

Verify the Ingress:

kubectl get ingress

Example output from the deployment:

NAME           CLASS     HOSTS   ADDRESS          PORTS
gore-ingress   contour   *       35.229.120.117   80,443

The external address is assigned to the load balancer managed by the Contour/Envoy deployment.

Inspect the Envoy service:

kubectl get -n projectcontour service envoy -o wide

Example:

NAME    TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)
envoy   LoadBalancer   34.118.236.21   35.229.120.117   80:30899/TCP,443:31661/TCP

At this point, the application can be reached through the external load balancer address.

6. Configure DNS

The external load balancer IP needs to be associated with a domain name before HTTPS can be configured cleanly.

The original implementation used a DDNS provider to create a DNS record pointing to the external IP.

Conceptually:

flowchart TD
    Domain["gore2.example-domain"] -->|DNS resolution| IP["35.229.120.117"]
    IP -->|HTTP / HTTPS| LB["Google Cloud Load Balancer"]
    LB -->|Ingress traffic| Contour["Contour"]
    Contour -->|Proxy / routing| Envoy["Envoy"]
    Envoy -->|Forward request| Service["Nginx Service"]

Verify that the DNS record resolves to the external address before proceeding with certificate issuance.

7. Install cert-manager

Install cert-manager into the cluster:

kubectl apply -f cert-manager.yaml

Verify the cert-manager workloads:

kubectl get pods -n cert-manager

cert-manager manages the lifecycle of the TLS certificate and Kubernetes Secret used by the Ingress.

8. Configure Let's Encrypt

Create an Issuer for the Let's Encrypt production environment:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-production
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <your-email>
    privateKeySecretRef:
      name: letsencrypt-production
    solvers:
      - http01:
          ingress:
            name: gore-ingress
            ingressClassName: contour

Apply the configuration:

kubectl apply -f letsencrypt-cm-issuer.yaml

Verify the Issuer:

kubectl describe issuer letsencrypt-production

The original deployment returned:

Reason: ACMEAccountRegistered
Status: True
Type: Read

This confirms that the ACME account was successfully registered with Let's Encrypt.

9. Create the TLS Certificate

Create a Kubernetes "Certificate" resource:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gore-tls
spec:
  secretName: gore-tls
  issuerRef:
    name: letsencrypt-production
    kind: Issuer
  commonName: "your-domain.example"
  dnsNames:
    - "your-domain.example"
  usages:
    - digital signature
    - key encipherment
    - server auth

Apply it:

kubectl apply -f certificate.yaml

Verify the certificate:

kubectl describe certificate gore-tls

The original deployment reported:

Message: Certificate is up to date and has not expired
Reason:  Ready
Status:  True
Type:    Ready

The certificate resource also exposed its validity and renewal timestamps through Kubernetes status information.

10. Enable HTTPS on the Ingress

Update the Ingress configuration to reference the TLS Secret created by cert-manager.

Apply the updated configuration:

kubectl apply -f ingress-updated.yaml

Verify the Ingress:

kubectl get ingress

Expected structure:

NAME           CLASS     HOSTS                  ADDRESS          PORTS
gore-ingress   contour   your-domain.example    <external-ip>   80,443

At this stage, traffic follows the HTTPS path:

flowchart TD
    Client["Client"] -->|HTTPS| DNS["DNS"]
    DNS --> LB["External Load Balancer"]
    LB --> CE["Contour / Envoy"]
    CE -->|TLS termination| Service["ClusterIP Service"]
    Service --> Nginx["Nginx"]

Verification Checklist

The deployment was verified progressively rather than treating "terraform apply" or "kubectl apply" as proof of success.

Infrastructure

[x] GKE cluster provisioned with Terraform
[x] Cluster credentials configured
[x] Kubernetes nodes reachable
[x] Nodes reported "Ready"

Ingress

[x] Contour installed
[x] Envoy deployed
[x] Envoy service exposed through a load balancer
[x] Ingress resource created
[x] External IP assigned

Application

[x] Nginx deployment created
[x] "ClusterIP" service created
[x] Ingress routed traffic to the application

DNS

[x] DNS record created
[x] DNS mapped to the external load balancer address

TLS

[x] cert-manager installed
[x] Let's Encrypt Issuer configured
[x] ACME account registered
[x] Certificate resource created
[x] Certificate reported "Ready"
[x] Ingress configured for HTTPS

What I Learned

This project demonstrates the relationship between several infrastructure layers that are often documented independently:

flowchart TD
    Terraform["Terraform"] --> GKE["GKE"]
    GKE --> Kubernetes["Kubernetes"]

    Kubernetes --> Deployment["Deployment"]
    Deployment --> Nginx["Nginx"]

    Kubernetes --> Service["Service"]
    Service --> ClusterIP["ClusterIP"]

    Kubernetes --> Ingress["Ingress"]
    Ingress --> Contour["Contour"]
    Contour --> Envoy["Envoy"]
    Envoy --> LB["Load Balancer"]
    LB --> DNS["DNS"]
    DNS --> HTTPS["HTTPS"]
    HTTPS --> CertManager["cert-manager"]
    CertManager --> LetsEncrypt["Let's Encrypt"]

The main takeaway is that Kubernetes Ingress is not an isolated resource. It sits inside a larger request path involving DNS, load balancing, ingress controllers, services, application workloads, and TLS infrastructure.

Contract-First Architecture: Governing Microservice Boundaries with OpenAPI 3.2 and Spectral

REV — Sun, 04 Oct 2026 08:09:42 +0000

Introduction

In a distributed system, an API contract is more than documentation.

It defines the boundary between services and tells consumers what data they can send, what data they can receive, and which representations are considered valid.

When an implementation and its contract drift apart, consumers begin to depend on behavior that may no longer be guaranteed. Frontends, mobile applications, and downstream services can end up reverse-engineering behavior from implementation details instead of relying on an explicit contract.

This is one reason contract-first API design is useful.

In a contract-first approach, the API specification is designed before the implementation. The specification becomes a shared scope that developers, consumers, reviewers, and tooling can reuse.

This article explores how OpenAPI 3.2 can be used to model strict API contracts, represent state-dependent resources, standardize error responses with RFC 9457 Problem Details, and enforce API conventions with Spectral and GitHub Actions.

The aim is not to use every feature OpenAPI provides. But to make repeatable rules enforceable.

What this article covers

Strict schema modeling with OpenAPI 3.2
Modeling state-dependent resources with "oneOf" and "allOf"
The role of "discriminator" in polymorphic schemas
The relationship between OpenAPI 3.2 and JSON Schema Draft 2020-12
Standardizing API errors with RFC 9457
Modeling a payment lifecycle as an API contract
Turning API conventions into Spectral rules
Running those rules locally and in CI/CD

Prerequisites

You should have a basic understanding of:

HTTP methods and status codes
REST APIs
YAML
JSON Schema
OpenAPI
Git and GitHub Actions

The examples use OpenAPI 3.2.1.

1. Contract-First Architecture

There are two common approaches to designing APIs: code-first and contract-first.

In a code-first design, developers begin with implementation and generate or derive the API specification from the resulting code.

In a contract-first approach, the API interface is defined before implementation.

Neither approach eliminates the need for business logic. The difference is where the API boundary is established.

Consider a service that exposes a withdrawal operation:

POST /accounts/005/withdraw

A code-first implementation might define the request structure inside the application and expose the resulting endpoint.

A contract-first design starts by describing the request:

schema:
  type: object
  properties:
    amount:
      type: integer
      minimum: 100
    currency:
      type: string
      enum:
        - ZAR
        - USD
        - EUR
  required:
    - amount
    - currency

The contract now establishes several rules:

"amount" must be an integer.
"amount" must be at least "100".
"currency" must be one of the permitted values.
Both fields are required.

The API boundary therefore rejects representations that violate these constraints before they reach the deeper application logic.

This distinction matters.

A schema can deny a misrepresented data. It cannot, by itself, determine whether a business operation or logic is permitted.

For example, a schema can establish that a withdrawal contains a valid amount. The application must still determine whether the account has sufficient funds, whether the account is active, and whether the withdrawal is permitted at the point of request.

This gives us a useful separation:

flowchart TD
    Contract["API contract"]
    ContractQuestion["What does valid data look like?"]

    Schema["Schema validation"]
    SchemaQuestion["Does the request have a valid representation?"]

    Application["Application logic"]
    ApplicationQuestion["Is the operation permitted?"]

    Domain["Domain state transition"]

    Contract --> ContractQuestion
    ContractQuestion --> Schema
    Schema --> SchemaQuestion
    SchemaQuestion --> Application
    Application --> ApplicationQuestion
    ApplicationQuestion --> Domain

The contract establishes the scope.

The application establishes the behavior.

2. Strict Schema Modeling

Strict schema modeling helps make the set of valid API representations explicit.

Consider an account resource:

{
  "accountStatus": "active",
  "balance": 50000,
  "currency": "ZAR"
}

This representation contains state that may influence what operations the client can perform.

If an API accepts a poorly defined scope:

schema:
  type: object

the contract says very little about what makes up a valid instance.

A stricter schema can define the expected structure:

type: object
properties:
  accountStatus:
    type: string
    enum:
      - active
      - suspended
      - closed

  balance:
    type: integer
    minimum: 0

  currency:
    type: string
    enum:
      - ZAR
      - USD
      - EUR

required:
  - accountStatus
  - balance
  - currency

Now the API contract describes a much smaller set of valid representations.

This is useful because downstream consumers no longer have to infer the shape of the resource from implementation behavior.

The important principle is:

A strict schema should express meaningful domain constraints, not merely add keywords for the sake of strictness.

3. Modeling State With Polymorphism

Some resources do not have the same representation in every state.

An account can be:

Account
├── Pending
├── Verified
└── Suspended

Each state may have different required properties.

For instance:

A pending account may require a name.
A verified account may also require "verifiedAt".
A suspended account may addtionally require "suspendedAt".

OpenAPI supports composition through JSON Schema keywords such as "oneOf" and "allOf".

A simplified model looks like this:

components:
  schemas:

    AccountBase:
      type: object
      required:
        - status
      properties:
        status:
          type: string
          enum:
            - PENDING
            - VERIFIED
            - SUSPENDED

    Account:
      oneOf:
        - $ref: '#/components/schemas/Pending'
        - $ref: '#/components/schemas/Verified'
        - $ref: '#/components/schemas/Suspended'

      discriminator:
        propertyName: status
        mapping:
          PENDING: '#/components/schemas/Pending'
          VERIFIED: '#/components/schemas/Verified'
          SUSPENDED: '#/components/schemas/Suspended'

    Pending:
      allOf:
        - $ref: '#/components/schemas/AccountBase'
        - type: object
          properties:
            name:
              type: string
          required:
            - name

    Verified:
      allOf:
        - $ref: '#/components/schemas/AccountBase'
        - type: object
          properties:
            name:
              type: string
            verifiedAt:
              type: string
              format: date-time
          required:
            - name
            - verifiedAt

    Suspended:
      allOf:
        - $ref: '#/components/schemas/AccountBase'
        - type: object
          properties:
            name:
              type: string
            suspendedAt:
              type: string
              format: date-time
          required:
            - name
            - suspendedAt

The model separates common properties from state-specific properties.

"AccountBase" contains information common to all states.
"Pending", "Verified", and "Suspended" extend that base representation with state-specific requirements.
"oneOf" then defines the possible representations of "Account".

What "oneOf" does:

"oneOf" requires the instance to validate against exactly one of the listed schemas.

That makes it useful when the states represent a different format.

For example:

Account:
  oneOf:
    - $ref: '#/components/schemas/Pending'
    - $ref: '#/components/schemas/Verified'
    - $ref: '#/components/schemas/Suspended'

A payload should therefore match one and only one of those alternatives.

What "allOf" does:

"allOf" combines schemas.

This example:

Verified:
  allOf:
    - $ref: '#/components/schemas/AccountBase'
    - type: object
      ...

means that a verified account must satisfy both the base schema and the additional verified-account schema.

This is important when multiple states share a common structure but add different requirements.

4. The Role of "discriminator"

A common misconception is that "discriminator" performs the validation. It does not.

OpenAPI 3.2.1 defines the discriminator as a hint that helps identify which schema is expected to validate a polymorphic payload. It does not change the validation outcome.

In this snippet:

discriminator:
  propertyName: status
  mapping:
    PENDING: '#/components/schemas/Pending'
    VERIFIED: '#/components/schemas/Verified'
    SUSPENDED: '#/components/schemas/Suspended'

the "status" property tells consumers which schema corresponds to the payload.

The actual validation still comes from "oneOf".

The difference becomes clear:

oneOf
  │
  └── defines the validation alternatives

discriminator
  │
  └── helps identify the expected alternative

A useful rule is:

Use "discriminator" when it improves the representation, serialization, deserialization, or consumer experience of a polymorphic model. Do not introduce it simply because the model contains multiple schemas.

5. Schema Validation Is Not Domain Logic

Strict schemas can describe valid representations of domain state.

They cannot, by themselves, enforce every state transition.

For example:

Verified:
  allOf:
    - $ref: '#/components/schemas/AccountBase'
    - type: object
      properties:
        verifiedAt:
          type: string
          format: date-time
      required:
        - verifiedAt

The following representation is invalid:

{
  "status": "VERIFIED"
}

because "verifiedAt" is required by the "Verified" schema.

This representation satisfies the schema:

{
  "status": "VERIFIED",
  "verifiedAt": "2026-09-22T10:30:00Z"
}

But schema validation still does not answer a very important question:

Was this account actually allowed to transition from "PENDING" to "VERIFIED"?

That decision belongs to your application.

The core differences can be summarized as:

Concern	Responsible layer
Data type	Schema
Required fields	Schema
Allowed values	Schema
Representation of a state	Schema
Whether a transition is permitted	Application/domain logic
Authorization	Application/security layer
Database transaction	Application/data layer

This boundary is necessary because an API specification should not be treated as a replacement for domain logic.

6. OpenAPI 3.2 and JSON Schema

OpenAPI 3.2.1 defines the Schema Object as a superset of JSON Schema Draft 2020-12. Unless OpenAPI adds specific semantics, Schema Object keywords follow JSON Schema behavior.

This provides a fine tuned schema vocabulary than treating an API specification as a simple description of field names and types.

This specification:

{
  "type": "payment",
  "amount": 50000,
  "currency": "ZAR",
  "metadata": {}
}

can be modeled using rules that describe what constitutes a valid instance.

The difference is between:

describing an approximate payload shape and defining the set of representations the API accepts or produces.

A schema can make this decision very precise.

However, JSON Schema validation still operates on the representation.

It does not know whether a payment should be settled, whether a user is authorized to settle it, or whether a transaction violates a business decision.

It is worth mentioning that:

Schema validation protects the API scope; domain logic protects the business rules behind it.

7. Standardizing Errors With RFC 9457

HTTP status codes communicate the broad outcome of an HTTP request, but they do not always provide enough information for a client to understand a specific application problem.

Imagine three regional services returning the same underlying failure in different formats:

flowchart TD
    Client["Client"]
    Gateway["API Gateway"]

    ZA["South Africa Region"]
    EU["Europe Region"]
    US["US Region"]

    Payment["Payment Service"]

    Client --> Gateway
    Gateway --> ZA
    Gateway --> EU
    Gateway --> US

    ZA --> Payment
    EU --> Payment
    US --> Payment

South Africa might return:

{
  "error": "payment_failed",
  "message": "payment provider unavailable"
}

Europe might return:

{
  "code": "SERVICE_PROVIDER_DOWN",
  "reason": "upstream unavailable"
}

The US might return:

{
  "status": 503,
  "errorMessage": "temporary failure"
}

The HTTP status may communicate a similar outcome, but the response bodies expose three different contracts.

A client now needs separate handling logic for each representation.

RFC 9457, Problem Details for HTTP APIs, provides a standardized structure for communicating machine-readable problem information.

A problem response might look like:

{
  "type": "https://api.example.com/problems/provider-unavailable",
  "title": "Payment provider unavailable",
  "status": 503,
  "detail": "The payment provider is temporarily unavailable.",
  "instance": "/payments/12345"
}

The standard members communicate different pieces of information:

Member	Purpose
"type"	Identifies the problem type
"title"	Provides a short human-readable summary
"status"	Indicates the HTTP status associated with the problem
"detail"	Describes the specific occurrence
"instance"	Identifies the particular occurrence

RFC 9457 does not require every problem response to contain all five members. For example, "type" has a defined default of "about:blank" when or if you omit it.

You can nevertheless choose to make these members mandatory as part of your own API policy.

This gives you a specific outcome:

RFC 9457 ── defines the problem-details model
Your API policy ── can impose stricter requirements

Problem Details can also be extended with application-specific members:

{
  "type": "https://api.example.com/problems/provider-unavailable",
  "title": "Payment provider unavailable",
  "status": 503,
  "detail": "Payment provider is temporarily unavailable.",
  "instance": "/payments/12345",
  "region": "eu-west-1",
  "retryable": true
}

The additional members are application-specific extensions rather than standard RFC 9457 members.

8. Modeling an Enterprise Payment Contract

We can now combine the concepts from earlier.

Suppose a payment service has three lifecycle states:

flowchart TD
    Unsettled["UNSETTLED"]
    Settled["SETTLED"]
    Failed["FAILED"]

    Unsettled -->|"POST /settle"| Settled
    Unsettled -->|"failure"| Failed

Your API contract can describe the representations of those states while the application logic controls whether a transition is permitted.

A simplified endpoint might look like this:

openapi: 3.2.1

info:
  title: Payment API
  version: 1.0.1
  description: >
    API contract for managing payment lifecycle states.

paths:

  /v1/payments/{paymentId}/settle:

    post:
      summary: Settle a payment
      operationId: settlePayment

      parameters:
        - $ref: '#/components/parameters/PaymentId'

      responses:

        '200':
          description: Payment successfully settled.
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/SettledPayment'

        '409':
          description: >
            The payment cannot be settled because its current
            state does not permit settlement.
          content:
            application/problem+json:
              schema:
                $ref: '#/components/schemas/ProblemDetails'

The resulting flow looks like this:

flowchart TD
    Contract["API Contract"]
    State["Payment state model"]

    Unsettled["UNSETTLED"]
    Settled["SETTLED"]
    Failed["FAILED"]

    Domain["Domain logic"]

    Success["Success"]
    Failure["Failure"]

    Status200["200"]
    StatusError["409 / 422 / 503"]

    ProblemType["application/problem+json"]
    ProblemDetails["ProblemDetails"]

    Contract --> State

    State --> Unsettled
    State --> Settled
    State --> Failed

    Unsettled -->|"POST /settle"| Domain

    Domain --> Success
    Domain --> Failure

    Success --> Status200
    Failure --> StatusError

    StatusError --> ProblemType
    ProblemType --> ProblemDetails

dot

This separation gives each layer a clear responsibility:

flowchart TD
    OpenAPI["OpenAPI<br/>Defines the interface"]
    Schema["Schema<br/>Defines valid representations"]
    Application["Application<br/>Enforces business rules"]
    Domain["Domain logic<br/>Controls state transitions"]
    ProblemDetails["Problem Details<br/>Standardizes failure representation"]

    OpenAPI --> Schema
    Schema --> Application
    Application --> Domain
    Domain --> ProblemDetails

This scope:

status:
  const: SETTLED

means that an instance represented as "SettledPayment" must contain the value "SETTLED".

It does not mean OpenAPI will prevent an application from changing a payment from "FAILED" to "SETTLED".

That transition must be enforced by the application.

9. From Documentation to Governance

Imagine that your API has adopted RFC 9457 and now expects all error responses to use:

application/problem+json

with:

#/components/schemas/ProblemDetails

A new endpoint could accidentally introduce:

'409':
  content:
    application/json:
      schema:
        $ref: '#/components/schemas/Error'

while the rest of the API uses:

'409':
  content:
    application/problem+json:
      schema:
        $ref: '#/components/schemas/ProblemDetails'

A reviewer may catch the inconsistency in a small API.

Trying to catch inconsistencies cross dozens of services and hundreds of operations, relying on manual review becomes difficult.

This is where API governance tooling becomes useful.

10. Automating API Governance With Spectral

Spectral can evaluate an OpenAPI document against a set of rules.

Instead of merely documenting a convention:

All error responses must use Problem Details.

we can encode the requirement as an executable rule.

This changes the diagram:

flowchart TD
    Convention["Written convention"]
    Rule["Spectral rule"]
    Validation["Automated validation"]
    Feedback["Developer feedback"]
    CICD["CI/CD enforcement"]

    Convention --> Rule
    Rule --> Validation
    Validation --> Feedback
    Feedback --> CICD

Click spectral ruleset for complete rules.

Rule 1: Require Problem Details fields

Your API policy can require the canonical "ProblemDetails" schema to contain:

"type"
"title"
"status"
"detail"
"instance"

A Spectral rule can express that requirement:

problem-details-required-fields:
  description: >
    The ProblemDetails schema must contain
    type, title, status, detail, and instance.

  message: >
    ProblemDetails must define type, title, status,
    detail, and instance.

  given: $.components.schemas.ProblemDetails

  severity: error

  then:
    - field: required
      function: schema
      functionOptions:
        schema:
          type: array
          contains:
            const: type

    - field: required
      function: schema
      functionOptions:
        schema:
          type: array
          contains:
            const: title

    - field: required
      function: schema
      functionOptions:
        schema:
          type: array
          contains:
            const: status

    - field: required
      function: schema
      functionOptions:
        schema:
          type: array
          contains:
            const: detail

    - field: required
      function: schema
      functionOptions:
        schema:
          type: array
          contains:
            const: instance

The rule has four valuable concepts:

given: WHERE does the rule apply?
then: WHAT must be true?
function: HOW is the condition evaluated?
severity: WHAT happens when it fails?

Rule 2: Enforce the Error Schema Across the API

The first rule checks the schema itself.

The second rule checks how that schema is used.

error-response-problem-details:
  description: >
    Every 4xx and 5xx response must reference
    the ProblemDetails schema.

  message: >
    All 4xx and 5xx responses must use
    #/components/schemas/ProblemDetails.

  given: "$.paths[*][*].responses[?(@property >= '400' && @property < '600')]"

  severity: error

  then:
    field: content.application/problem+json.schema.$ref
    function: pattern

    functionOptions:
      match: "^#/components/schemas/ProblemDetails$"

The JSONPath expression determines what Spectral examines.

$.paths: every API path
[*]: every path item
[*]: every operation
.responses: every response
[?(@property >= '400' && @property < '600')]: every 4xx and 5xx response

The rule then checks:

content
  └── application/problem+json
        └── schema
              └── $ref

and requires that reference to resolve to:

#/components/schemas/ProblemDetails

Rule 3: Enforce the Media Type

The schema reference is only part of the convention.

The response should also use the RFC 9457 media type: application/problem+json

We can encode that requirement separately:

problem-details-media-type:
  description: >
    Every 4xx and 5xx response must use
    application/problem+json.

  message: >
    Error responses must use the RFC 9457 media type
    application/problem+json.

  given: "$.paths[*][*].responses[?(@property >= '400' && @property < '600')].content"

  severity: error

  then:
    field: application/problem+json
    function: truthy

The three rules now enforce different layers of the same policy:

flowchart TD
    Rule1["Rule 1"] --> Check1["Is the canonical ProblemDetails schema complete?"]
    Check1 --> Rule2["Rule 2"]

    Rule2 --> Check2["Do error responses reference that schema?"]
    Check2 --> Rule3["Rule 3"]

    Rule3 --> Check3["Do error responses use the correct media type?"]

This is where your documentation takes the right shape.

11. Running Spectral Locally

Once the contract and ruleset exist, Spectral can validate the API description.

Install the CLI:

npm install -g @stoplight/spectral-cli

Click enterprise payment contract to see full contract.

Then run:

spectral lint examples/openapi/enterprise_payment_contract.yaml \
   --ruleset examples/openapi/.spectral.yaml \
   --fail-severity=warn

This contract should complete without rule violations.

Now deliberately introduce an invalid reference:

$ref: '#/components/schemas/Errors'

instead of:

$ref: '#/components/schemas/ProblemDetails'

Run the linter again:

spectral lint examples/openapi/enterprise_payment_contract.yaml \
   --ruleset examples/openapi/.spectral.yaml \
   --fail-severity=warn

The result should contain errors similar to:

- error  error-response-problem-details
All 4xx and 5xx responses must use
#/components/schemas/ProblemDetails.

- error  invalid-ref
#/components/schemas/Errors does not exist.

- error  problem-details-required-fields
ProblemDetails must define type, title,
status, detail, and instance.

Aside from the error message, the feedback loop is also important:

flowchart TD
    Developer["Developer changes contract"]
    Spectral["Spectral evaluates contract"]
    Violation["Rule violation detected"]
    Feedback["Developer receives immediate feedback"]
    Corrected["Contract is corrected"]

    Developer --> Spectral
    Spectral --> Violation
    Violation --> Feedback
    Feedback --> Corrected
    Corrected --> Developer

12. Enforcing the Contract in CI/CD

Local validation is necessary, but sometimes developers can forget to run it.

The same rules defined earlier can also be run in CI.

A simplified GitHub Action specification looks like this:

name: API Contract

on:
  pull_request:

jobs:
  spectral:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Install Spectral
        run: npm install -g @stoplight/spectral-cli

      - name: Lint OpenAPI contract
        run: |
          spectral lint \
            examples/openapi/enterprise_payment_contract.yaml \
            --ruleset examples/openapi/.spectral.yaml \
            --fail-severity=warn

Running a pull request activates the spectral linter and we see an error like this:

Run spectral lint enterprise_payment_contract.yaml --ruleset .spectral.yaml --fail-severity=warn

/home/runner/work/technical-articles/technical-articles/enterprise_payment_contract.yaml

  37:23  error  error-response-problem-details
          All 4xx and 5xx responses must use #/components/schemas/ProblemDetails.

  37:23  error  invalid-ref
          '#/componente/schemas/Errors' does not exist

 185:16  error  problem-details-required-fields
          ProblemDetails must define type, title, status, detail, and instance.

See failed PR for more information.

This creates another valid restriction:

flowchart TD
    Developer["Developer"]
    CLI["Spectral CLI"]
    Feedback["Local feedback"]
    Commit["Git commit"]
    PR["Pull request"]
    Actions["GitHub Actions"]
    Spectral["Spectral"]

    Pass["PASS"]
    Fail["FAIL"]
    Continue["Continue"]
    Fix["Fix contract"]

    Developer --> CLI
    CLI --> Feedback
    Feedback --> Commit
    Commit --> PR
    PR --> Actions
    Actions --> Spectral

    Spectral --> Pass
    Spectral --> Fail

    Pass --> Continue
    Fail --> Fix

GitHub Actions itself does not automatically prevent a merge. The rules defined produces a status check. Repository branch-protection rules can then require that check to pass before a pull request can be merged.

This creates two validation boundaries:

Developer boundary
    │
    └── Fast local feedback

Repository boundary
    │
    └── Automated PR validation

13. Why This Matters

The value of this approach is not the number of OpenAPI features used. The value comes from connecting several layers of logic.

flowchart TD
    API["API design"]
    OpenAPI["OpenAPI contract"]
    Schema["Schema constraints"]
    Domain["Domain state model"]
    Errors["Standardized error representation"]
    Spectral["Spectral governance"]
    CICD["CI/CD enforcement"]

    API --> OpenAPI
    OpenAPI --> Schema
    Schema --> Domain
    Domain --> Errors
    Errors --> Spectral
    Spectral --> CICD

Each layer addresses a different problem.

OpenAPI defines the interface.
JSON Schema constrains data representations.
Application logic enforces business rules and state transitions.
RFC 9457 provides a standardized representation for HTTP API problems.
Spectral turns API conventions into executable rules.
CI/CD continuously applies those rules to proposed changes.

The result is not an API that is automatically correct. It is an API whose rule-based assumptions are explicit, testable, and easier to keep consistent as the system grows.

Conclusion

A contract-first API is more than a document describing endpoints. It is an concise representation of the boundary between systems.

OpenAPI 3.2 provides the structure for describing that boundary. Its Schema Object builds on JSON Schema, allowing API authors to express increasingly precise rules over valid data representations. Polymorphic constructs such as "oneOf" and "allOf" can model resources whose representations differ by state, while "discriminator" can help consumers identify the expected schema without changing validation semantics.

These schemas still have limits.

They can describe valid representations, but they cannot replace application logic, authorization, transactions, or domain state-transition rules.

For error responses, RFC 9457 provides a standardized Problem Details model. An organization can then impose additional requirements on top of that standard, such as requiring specific members or using a problem schema across its services.

Finally, Spectral turns those conventions into executables.

Instead of relying entirely on reviewers to notice contract drift, the repository can continuously evaluate the specification against explicit rules. Running those rules locally gives developers immediate feedback, while CI/CD provides an additional validation layer before changes are merged.

Read the full article on GitHub

The Journey of a Network Packet: A TCP/IP Guide

REV — Thu, 23 May 2024 20:55:34 +0000

Prerequisite
The TCP/IP Model
- Computer Networking in Today's Digital Landscape
- The significance of Networking to End-Users
- Benefits of the TCP/IP Model
Understanding the TCP/IP Model
- The Link Layer
- The Network Layer
- The Transport Layer
- The Application Layer
Functions of the TCP/IP Model
Understanding Packets
- What is in a packet header
- Common types of Network Packets
The Journey of a Packet
Summary

The internet works through the seamless transmission of packets. Packets are the basic unit of data exchange. This article provides an overview of the journey of a packet across the TCP/IP model. Elucidating its critical role in networking.

Prerequisite:

Basic understanding of Computer networks
Familiarity with the OSI model
Basic knowledge of TCP/IP protocol suite
Basic networking tools WireShark

The TCP/IP Model

Before we begin our journey, let us first understand what Computer Networking is. Its relevance in IT operations, Cloud services, and the internet.

Computer Networking in Today's Digital Landscape

Computer networking involves transferring and exchanging data between interconnected computing devices or nodes over physical or wireless technologies, following a set of rules known as communication protocols. Computer networking enables devices and endpoints to connect on a local area network (LAN) or larger networks like the internet or private wide area networks (WANs). This connectivity is essential for service providers, businesses, and consumers worldwide to share resources, access services, and communicate. Networking supports a wide range of activities, from telephone calls and text messaging to streaming video and the Internet of Things.

Cloud services and internet functionality enable seamless integration and communication between on-premises infrastructure and cloud platforms, facilitating data transfer, application deployment, and access to cloud-based resources. Networking provides the underlying infrastructure for cloud services such as virtual private clouds - VPCs load balancers, and content delivery networks (CDNs), ensuring reliable and scalable cloud solutions.

The Significance of Networking to End-Users

End-users should care about networking because it is essential for accessing shared resources, internet connectivity, and optimal application performance. Networking directly impacts productivity and efficiency by enabling seamless communication and collaboration. It also plays a crucial role in ensuring the security and privacy of data and protecting against unauthorized access and cyber threats. Moreover, staying informed about networking helps end-users leverage emerging technologies like cloud computing and IoT, enhancing their digital experience and personal or professional growth.

Benefits of the TCP/IP Model

Global Adoption: The TCP/IP model is the foundation of internet communication, enabling seamless connectivity among devices across different vendors and platforms, thus promoting worldwide interconnectivity in the digital realm.
Scalability and Adaptability: With its modular architecture the TCP/IP model effortlessly integrates new technologies and protocols, ensuring it can meet evolving networking needs and readily accommodate future advancements.
Cross-Platform Compatibility: The TCP/IP model facilitates smooth communication across diverse devices and platforms, allowing for data exchange between various protocols and technologies and enhancing connectivity in the digital landscape.
Standardization of the Internet: As the standard for Internet communication, the TCP/IP model guides the development and implementation of networking protocols and technologies. With a unified framework, it promotes compatibility and consistency across networks.

Understanding The TCP/IP Model

The TCP/IP model is a structure that outlines the protocols and standards governing data transmission across networks. It consists of four interlinked layers, each responsible for facilitating network communication. Named after its primary protocols, TCP guarantees dependable data delivery, while IP manages data packet routing and addressing.

Internet Model	Description
Application	Bidirectional reliable byte stream between two applications, using application-specific semantics (HTTP, BitTorrent)
Transport	Guarantees correct, in-order end-to-end delivery of data
Network	Delivers datagram end-to-end. Best effort delivery - with no guarantees. Must use the Internet Protocol (IP)
Link	Delivers data over a single link between an end host and router or between routers

At the top of the TCP/IP model is the Application layer, with applications like BitTorrent and WorldWideWeb, which communicate to its peer layer. When the application has data to transmit, it sends it to the transport layer, whose job is to deliver the data reliably or otherwise to the destination. The transport layer then forwards this data to the network layer responsible for segmenting the data into packets, each tagged with the correct destination and address. Subsequently, the link layer receives the packet, which ensures its delivery from one node to the next along its path. The data progresses hop by hop through routers until it reaches the destination. All four layers facilitate reliable communication between applications in the end hosts. Each layer has a different responsibility, with higher layers building upon those beneath them, culminating in a bidirectional, reliable byte stream communication between applications.

The Link Layer

The link layer is the foundation of the TCP/IP protocol model, functioning as the interface between the network hardware and the rest of the network stack. Its primary role is to facilitate the transmission and reception of data across the physical network, providing a means for devices to communicate within the local area network (LAN).

The key responsibilities of the link layer include managing communication with the network adapter, coordinating data transmission according to the appropriate access method (Ethernet, token ring), formatting data into frames for transmission, handling errors in incoming frames, and acknowledging receipt of data frames while ensuring reliable delivery. Additionally, the link layer assigns addresses to network interface devices, which allows communication with devices on other networks.

The Network Layer

The network layer's primary function is to ensure the end-to-end delivery of packets across the internet - from the source and reaching the destination. Packets serve as a fundamental component in the network. They denote data accompanied by a header, its content, destination, and origin.

Network layer packets are called datagrams. They include the data and a header containing the - to and from - addresses. The network layer hands the datagram to the link layer, telling it to send it to the first link. The link layer says if you give me a datagram to send, I will transmit it over one link for you.

At the other end of the link is a router. The link layer of the router accepts the datagram from the link and hands it up to the network layer inside the router. The network layer on the router examines the destination address of the datagram. It then routes the datagram, one hop at a time, to its eventual destination. And it does this by sending it to the link layer again. To carry it over to the next link, which is passed to the network layer on the next router and so on, until it reaches the network layer of its destination.

The network layer does not need to concern itself with how the link layer sends the datagram over each link. This separation of concerns between the network and link layers allows each to focus on its job without worrying about how the other layer works. It also means that a single network layer has a common way of talking to many link layers by simply handling the datagrams to send. The modularity of each layer makes this separation of concerns possible, coupled with a well-defined API to the layer below.

When we send packets to the internet, we must use the internet protocol (IP). It is the IP that holds the internet together. The IP strives to deliver datagrams to their intended destinations. But it does not guarantee successful delivery. Datagrams can be lost, delivered out of sequence, or not delivered. Despite these potential issues, the internet can still function effectively. Applications often require another protocol layered on the IP to ensure reliable data delivery. This protocol operates at the transport layer and its responsibility is managing end-to-end communication between applications.

The Transport Layer

The Transmission Control Protocol — TCP — is the most common Transport layer. The TCP’s job is to guarantee that the data sent by an application at one end of the internet is delivered correctly to the application at the other end. If the network layer drops some datagrams, the TCP will transmit them multiple times if needed. If the network layer delivers them out of order — perhaps if two packets follow a different path to their destination. TCP will put the data back into the correct order again.

TCP provides applications with a service that ensures that data is delivered correctly and in the intended order - despite the unreliable nature of the underlying network layer's datagram delivery service. This means that TCP guarantees the correct sequencing and delivery of data packets, addressing issues like packet loss, out-of-order delivery, and duplication. Applications like web and email clients greatly benefit from TCP's reliability because it allows them to focus on their core functionalities without complex internal error-handling mechanisms. By relying on TCP, these applications can delegate the responsibility of reliable data transfer, thus abstracting away the complexities of network communication and ensuring seamless and dependable data transmission.

However, not every service requires a reliable delivery of data packets. Consider a scenario of a video snippet transmission via packets during a WhatsApp call. If there is a network latency, multiple re-transmissions of packets may not be essential. Opting to forego re-transmission could be the optimal choice. UDP: User Datagram Protocol can be used for applications that do not need a reliable delivery service.

The Application Layer

The application layer is at the top of the TCP/IP model, and it defines TCP/IP application protocols and facilitates the interface between host programs and Transport layer services for network usage. The Application layer includes several high-level services such as DNS (Domain Naming System), HTTP (Hypertext Transfer Protocol), Telnet, SSH, etc.

Every application interacts with the transport layer through a well-defined API, originating from the application layer to access the underlying TCP or UDP service. Applications mostly want a bidirectional reliable byte stream between endpoints, using their protocols to define the syntax of data exchange.

For example, when a web client sends a GET request to a web server, it sends the request as an ASCII string along with the URL. From the application layer's viewpoint, the request is sent straight to its peer at the receiving end (the web server application) without knowing the underlying transmission configurations. The application layer delegates the GET request to the TCP layer for accurate delivery, which in turn utilizes the services of the network layer and relies on the link layer for transmission.

Functions of the TCP/IP Model

Logical Addressing:
TCP/IP implements logical addressing to accommodate numerous hosts across diverse networks. IP manages this mechanism, ensuring data packets reach the appropriate networks and nodes.
IP Manages Routing:
Handling the critical task of routing data packets, IP determines the next node along the transmission path from source to destination. This ensures that data packets reach their intended destinations, even if the sender is unaware of the specific location.
TCP Ensures Error and Flow Control:
Establishing a virtual connection between senders and receivers, TCP maintains continuous communication and incorporates error and flow control mechanisms. Enabling reliable data transfer and ensures connection stability throughout the transmission process.
TCP Supports Applications:
TCP assigns unique TCP and UDP ports to applications, which allows for the seamless differentiation of specific applications and their communication link.

Understanding Packets

A packet consists of the data intended for delivery and a header containing information about its destination and origin within the network. When a user requests to load an image, the image file is not transmitted from the web server to the user's computer as a single entity. Instead, the image is broken into bits of packets, transmitted across the internet via cables, and then reassembled by the user's computer to reconstruct the original image.

The efficiency, reliability, scalability, and flexibility make packets vital in internet communication. Breaking data into smaller packets or sizes optimizes network resources, while error detection and correction mechanisms enhance reliability. The internet employs packet switching. Packet switching divides data into smaller packets for efficient transmission between computers. This approach enhances network performance by allowing multiple connections in parallel over the same wires and enabling networking equipment to process packets independently. Packet switching also enhances network resilience and efficiency by permitting packets to take various paths to their destination, encouraging data exchange among billions of devices.

What is in a packet header?

Examining the IPv4 packet header, we can see what travels with a packet to its destination.

Bit 0: Typically refers to the first bit in a bit sequence. In networking, the order in bits transfer can depend on the network protocol used. For instance, Ethernet and IP do not specifically define the order in which individual bits travel on the wire, but rather the order of bytes and fields.
IPv4 Header: Contains several critical fields for routing and handling packets. The most important fields include:
- Destination IP Address: Indicates the packet's intended recipient.
- Source IP Address: Indicates the packet's origin.
- Protocol ID: Specifies the higher-level protocol used in the data field (e.g., TCP, UDP). This field helps the destination host demultiplex arriving data, routing it to the appropriate protocol handler. For example, a Protocol ID value of 6 indicates that the data contains a TCP segment and is thus passed to the TCP processing module.

The Internet Assigned Numbers Authority (IANA) defines over 140 different protocol numbers representing various transport and network layer protocols.

Version: This 4-bit field specifies the IP version in use. The values are 4 for IPv4 and 6 for IPv6. The header described here is for IPv4.
Total Length: This 16-bit field specifies the entire packet size - including the header and data in bytes. The maximum size is 65,535 bytes (64 KB).
Time to Live (TTL): This 8-bit field prevents packets from circulating indefinitely. Each router that forwards the packet decrements the TTL by 1. TTL discards the packet when it reaches zero. This mechanism ensures packets do not loop forever.
Packet Identification: This 16-bit field identifies the fragments of an original IP packet.
Flags: This 3-bit field controls and identifies fragments. The most significant bit is reserved. The remaining two bits are:
- DF (Don't Fragment): The packet cannot be fragmented.
- MF (More Fragments): Indicates more fragments. If not set, it indicates the last fragment.
Fragment Offset: This 13-bit field specifies the position of fragments in the original packet, measured in 8-byte blocks.
Type of Service (ToS): This field indicates the quality of service desired for the packet. Routers can use the ToS to prioritize packets.
Header Length: This 4-bit field indicates the length of the IP header in 32-bit words. The minimum value is 5 (20 bytes), and the maximum is 15 (60 bytes), accommodating optional fields.
Header Checksum: This 16-bit field checks the header's integrity. It ensures the header is uncorrupted in transit. The header rejects the packet if the checksum does not match the calculated value.

Common Types of Network Packets

Packet Type	Purpose	Example	Function
Data Packets	Transport user data or application-specific information	Segments of emails or file downloads	Encapsulate user data and ensure delivery from source to destination
Control Packets	Manage and control network communications	TCP control packets like SYN, SYN-ACK, and ACK	Facilitate establishment, maintenance, and termination of network sessions
Routing Packets	Inform routers about network topology changes and determine the best path	OSPF and BGP packets	Maintain and update routing tables to ensure data takes the most efficient path
Fragmentation Packets	Divide large data packets into smaller fragments to accommodate MTU	IP fragmentation packets	Allows the transmission of large packets over networks with smaller MTU sizes
Acknowledgement Packets	Confirm successful receipt of data packets	TCP ACK packets	Provide feedback to the sender upon receiving data correctly, ensuring reliable transmission
Broadcast Packets	Simultaneously send data to all nodes in a local network segment	ARP requests	Enable network-wide communication for tasks like address resolution and network discovery

The Journey of a Packet

The TCP/IP Model picks up a stream of data from the application layer, and the transport layer breaks the stream into a segment of data that it reliably delivers to an application running on another computer. The transport layer sends these segments as network layer packets - which the network layer delivers to other computers.

application [streams of data] -> transport [breaks the stream of data into segments] -> network [sends network layer packets to other computers].

Almost all web traffic is over TCP. Its typical operation is between a client and a server. To open a connection a client sends a connection request, which the server responds to. This exchange takes three messages, called the three-way handshake.

The first step of the message is when the client sends a Synchronize message to the server, often called the SYN.
The second step is when the server responds with a synchronized message. Acknowledging the client Synchronize or a Synchronize / Acknowledge message - called a SYN/ACK.
The third and final step is when the client responds by acknowledging the server Synchronize, called an ACK.

From the network layer point of view, packets sent to different applications on the same computer look the same. Hence, we need two addresses to open a TCP stream to another program.

The first is the IP address: the address of the network layer.
The second is a TCP port: this tells the computer software which application to deliver.

Web servers usually run on TCP Port 80. So when we open a connection to a web server, we send IP packets to the computer's IP address. Those IP packets have TCP segments whose destination port is 80.

But how does an IP Packet get to its destination

Given that a direct physical link between a client (say, A) and a server may not exist. Client A often connects to an intermediary, typically a router. This router, in turn, establishes connections with other routers in the network. The journey of IP packets from client A to the server involves multiple stages, known as hops, where each hop represents a connection between two routers. If client A accesses the network via Wi-Fi, the hop involves wireless communication to reach the network access point. Conversely, if client A employs a wired connection like Ethernet, the data transmission traverses physical cables, eliminating the need for wireless hops.

A wired connection from the access point leads to the broader internet. The router forwards client A packet along this wired hop. A router can have many links connecting to it. Upon the arrival of each packet, the router determines the appropriate outbound link for transmission. Routers possess IP addresses, which may lead to delivering a packet to its corresponding software and not forwarding it.

Inside the stream

Inside each hop

For example, IP packets are forwarded to the router IP address when you log in to a router using TCP.

How does a router make this decision

The router achieves this through a forwarding table. It comprises IP address patterns and their associated outbound links. When a packet arrives, it assesses which entry in the forwarding table best matches its pattern and directs the packet through the link specified in that entry. Typically, the term best signifies the most specific match.

The default route is the least specific. It matches every IP address. If a packet arrives and there is nothing but the default one, the router will use the default route.

Summary

In computer networking, packets follow the TCP/IP Model. It begins at the application layer when an app wants to send data. The transport layer, with protocols like TCP and UDP, deals with splitting data, controlling the flow, and finding errors. The packet gets wrapped in an IP header that guides it across the internet at the network layer. Lastly, the link layer ensures the packet goes over the physical network. When the packet reaches its destination, it reverses the steps. It begins at the link layer, where it is received and decoded. The network layer looks at the IP header to discern where the packet should go. The transport layer checks the data for problems and puts it in order if needed. Finally, the Application layer hands the data to the receiving app. Along the way, packets are handled to ensure they go from the source to the destination.