Rafiqul.dev

Generic Function in Python with Singledispatch

Rafiqul Hasan — Tue, 27 Mar 2018 00:00:00 GMT

Imagine, you can write different implementations of a function of the same name in the same scope, depending on the types of arguments. Wouldn’t it be great? Of course, it would be. There is a term for this. It is called “Generic Function”. Python recently added support for generic function in Python 3.4 (<a href="https://www.python.org/dev/peps/pep-0443/" target="_blank">PEP 443</a>). They did this to the functools module by adding @singledispatch decorator.

What is Singledispatch?

At this point, you may be wondering what is singledispatch. Okay, let’s go with generic function again.

A generic function is composed of multiple functions implementing the same operation for different types. Which implementation should be used during a call is determined by the dispatch algorithm. When the implementation is chosen based on the type of a single argument, this is known as single dispatch.

In Python, implementation is chosen based on the type of the first argument of function. So in simple, you define a default function and then register additional versions of that functions depending on the type of the first argument.

Singledispatch in Action

Let’s see singledispatch in action. There are few steps for writing a generic function with singledispatch.

Import singledispatch from functools.
Define an default or fallback function with @singledispatch decorator. It’s our generic function.
Then, Register additional implementations by passing the type in register() attribute of the generic function. It’s a decorator, so you decorate your implementations like this @function_name.register(type). You can also register lambdas and pre-existing functions.

Now, we will implement a generic function called fprint, which will print something in a formatted way based on the type. For list it will print index and value along with type of value and for dict it will print key-value pair along with their type etc. By default it will print the passed argument along with it’s type. Let’s define our default function first.

from functools import singledispatch


@singledispatch
def fprint(data):
    print(f'({type(data).__name__}) {data}')

I am not going to explain the implementation. It’s fairly basic. It’s the default or fallback implementation of our generic function. We define a function and decorate it with @singledispatch decorator. If there is no registered implementation for a specific type, its method resolution order is used to find a more generic implementation. The original function decorated with @singledispatch is registered for the base object type, which means it is used if no better implementation is found.

Remember the next step? Now, it’s time for registering the overloaded implementations. Let’s implement for list first.

@fprint.register(list)
def _(data):
    formatted_header = f'{type(data).__name__} -> index : value'
    print(formatted_header)
    print('-' * len(formatted_header))
    for index, value in enumerate(data):
        print(f'{index} : ({type(value).__name__}) {value}')

In case you are wondering why I am using _ as name. It’s because, I want only one generic function. If you give it a name, you will get the option to use this specific function independently. Assume that we gave a name to the above function list_print and didn’t decorate with @fprint.register(list). Now, we can use fprint.register() as function like this fprint.register(list, list_print). We can also stack more than one decorator for multiple type just like this.

@fprint.register(list)
@fprint.register(set)
@fprint.register(tuple)
def _(data):
    formatted_header = f'{type(data).__name__} -> index : value'
    print(formatted_header)
    print('-' * len(formatted_header))
    for index, value in enumerate(data):
        print(f'{index} : ({type(value).__name__}) {value}')

We almost finished our generic function except for dict type. Here is our full code along with implementation for dict type.

from functools import singledispatch


@singledispatch
def fprint(data):
    print(f'({type(data).__name__}) {data}')


@fprint.register(list)
@fprint.register(set)
@fprint.register(tuple)
def _(data):
    formatted_header = f'{type(data).__name__} -> index : value'
    print(formatted_header)
    print('-' * len(formatted_header))
    for index, value in enumerate(data):
        print(f'{index} : ({type(value).__name__}) {value}')


@fprint.register(dict)
def _(data):
    formatted_header = f'{type(data).__name__} -> key : value'
    print(formatted_header)
    print('-' * len(formatted_header))
    for key, value in data.items():
        print(f'({type(key).__name__}) {key}: ({type(value).__name__}) {value}')

Now, it's time for the ultimate test. Let's call the same fprint function with different data types.

>>> fprint('hello')
(str) hello

>>> fprint(21)
(int) 21

>>> fprint(3.14159)
(float) 3.14159

>>> fprint([2, 3, 5, 7, 11])
list -> index : value
---------------------
0 : (int) 2
1 : (int) 3
2 : (int) 5
3 : (int) 7
4 : (int) 11

>>> fprint({2, 3, 5, 7, 11})
set -> index : value
--------------------
0 : (int) 2
1 : (int) 3
2 : (int) 5
3 : (int) 7
4 : (int) 11

>>> fprint((13, 17, 23, 29, 31))
tuple -> index : value
----------------------
0 : (int) 13
1 : (int) 17
2 : (int) 23
3 : (int) 29
4 : (int) 31

>>> fprint({'name': 'John Doe', 'age': 32, 'location': 'New York'})
dict -> key : value
-------------------
(str) name: (str) John Doe
(str) age: (int) 32
(str) location: (str) New York

Summing It Up

As you can see, Python provides a clear way to define and extend generic functions. It opens some interesting possibilities to refactor your code. If you are interested to learn more about singledispatch, you should check out <a href="https://www.python.org/dev/peps/pep-0443/" target="_blank">PEP 443</a> and functools <a href="https://docs.python.org/3/library/functools.html#functools.singledispatch" target="_blank">docs</a>.

FastAPI Deconstructed: Anatomy of a Modern ASGI Framework

Rafiqul Hasan — Tue, 19 Nov 2024 00:00:00 GMT

Recently I had the opportunity to talk about the FastAPI under the hood at PyCon APAC 2024. The title of the talk was “FastAPI Deconstructed: Anatomy of a Modern ASGI Framework”. Then, I thought why not have a written version of the talk. And, I have decided to write. Something like a blog post. So, here it is.

You can find the slide here: https://github.com/shopnilsazal/fastapi-deconstructed

FastAPI has quickly become one of the go-to frameworks for Python developers who need high performance and developer-friendly API frameworks. With support for asynchronous programming, dependency injection, and automatic OpenAPI documentation, FastAPI stands out for its speed and ease of use. This post will break down the core components of FastAPI, detailing how each part from ASGI and Uvicorn to Starlette and Pydantic works together to create a robust, modern web framework.

Hello World

Let’s begin with the fundamentals of a FastAPI application. A “Hello World” example in FastAPI is very straightforward.

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def hello():
    return {"message": "Hello, World!"}

With a simple setup like this, FastAPI takes care of:

Defining an asynchronous route.
Parsing and validating requests.
Serializing JSON responses.
Generating automatic API docs.

Here’s how we can run this application.

uvicorn main:app

hypercorn main:app

granian --interface asgi main:app

We can see, there are multiple ways to run our application. The main thing is, we need an ASGI compliant server to run our application. We can use any server that implements ASGI protocol. But for simplicity, in this post I will use uvicorn as the example of ASGI server to explain related things.

Building Blocks

FastAPI’s functionality is layered on top of several powerful components:

ASGI: The asynchronous protocol layer that handles communication between the server and the application.
Uvicorn: A high-performance ASGI server that serves FastAPI applications.
Starlette: An ASGI framework providing routing, middleware, and request/response handling.
Pydantic: A library for data validation and parsing, used in FastAPI to ensure data consistency and reliability.
Dependency Injection: A built-in dependency injection system that makes it easy to inject dependencies like database connections, services, or configuration etc.
Automatic API Doc: Automatically generates an OpenAPI specification for API, which provides detailed documentation and interactive features.

ASGI - The Protocol Layer

ASGI, or the Asynchronous Server Gateway Interface, serves as the foundation of FastAPI, enabling asynchronous programming by providing a standardized interface between the application and server. ASGI evolved from WSGI (Web Server Gateway Interface) to support real-time web features like WebSockets and multiple concurrent connections, allowing Python applications to handle high loads without blocking. Currently ASGI protocol describes HTTP/1.1, HTTP/2 and WebSocket.

flowchart LR
    A[Client] -->|Sends HTTP Request| B[ASGI Server]
    B --> |Parse and Translate <br/> to Scope and Events| C[ASGI App]

Here’s how a request flow of ASGI application looks like from a very high level. When client sends a HTTP request, the ASGI server accepts the request and parse & translate it to scope and events (we will see details of scope and events a little bit later). Then, the ASGI app receive the scope and events and process the request. Now let’s see some details about the ASGI protocol itself.

ASGI Components:

Scopes: ASGI defines a scope for each connection. This is a dictionary containing the connection’s metadata. For HTTP requests, this includes method, path, query string, headers, etc. Each request or connection is encapsulated in a unique scope.

Example HTTP scope:

scope = {
    "type": "http",  # The type of connection ("http", "websocket")
    "http_version": "1.1",  # HTTP version
    "method": "GET",  # HTTP method, like GET, POST
    "path": "/hello",  # URL path requested by the client
    "query_string": b"name=John",  # Query string in the request
    "headers": [  # HTTP/Websocket headers
        (b"host", b"example.com"),
        (b"user-agent", b"Mozilla/5.0"),
        (b"accept", b"text/html"),
    ],
    "client": ("127.0.0.1", 12345),  # Client IP address and port
    "server": ("127.0.0.1", 8000),  # Server IP address and port
}

Events: ASGI operates on events for handling requests. Events are async functions used to receive incoming data or send outgoing data:
- Receive: An awaitable callable that the application calls to receive events (such as HTTP requests or WebSocket messages).
- Send: An awaitable callable that the application uses to send responses back to the server.
Lifespan Events: ASGI also supports lifespan events, which handle startup and shutdown operations. These events allow setup or cleanup tasks (such as initializing or closing a database connection) to run at the server start or stop.

This is a simple ASGI app looks like. No framework, just a simple Python async function.

async def app(scope, receive, send):
    assert scope['type'] == 'http'

    await send({
        'type': 'http.response.start',
        'status': 200,
        'headers': [
            [b'content-type', b'text/plain'],
        ],
    })
    await send({
        'type': 'http.response.body',
        'body': b'Hello, world!',
    })

Uvicorn - The ASGI Server

Uvicorn is the ASGI server that powers FastAPI applications. You could run a FastAPI app with any other ASGI server. Uvicorn is designed for speed and efficiency, making it an ideal choice for applications that require high concurrency. Uvicorn is built on top of uvloop, a high-performance implementation of the asyncio event loop, which enhances its ability to handle I/O-bound tasks efficiently.

Request Lifecycle in Uvicorn:

Accept Connection: Uvicorn accepts a connection and creates an ASGI scope for the incoming HTTP request, including metadata like headers and method.
Dispatch Request: The scope is dispatched to the FastAPI application. Uvicorn uses uvloop to asynchronously manage the flow.
Receive Data: Uvicorn processes incoming request data through ASGI receive events.
Send Response: FastAPI responds with an ASGI send event. Uvicorn packages the response (status code, headers, body) and returns it to the client.

Starlette - The ASGI Framework Layer

We can’t talk about FastAPI without Starlette. Starlette is a lightweight ASGI framework that provides FastAPI with its core functionality. Starlette serves as the backbone of FastAPI, handling the low-level routing, middleware, and ASGI compatibility, while FastAPI adds Pydantic validation, dependency injection, and additional tools for building APIs efficiently.

Lifecycle of a Web Request

Now, let’s visualize the full lifecycle of a http request using a starlette hello world example as the ASGI app.

Starlette Application (app.py):

from starlette.applications import Starlette
from starlette.responses import JSONResponse
from starlette.routing import Route

# Route handler for "/hello"
async def hello(request):
    return JSONResponse({'message': 'Hello, World!'})

# Defining the routes
routes = [
    Route('/hello', hello),
]

# Creating the Starlette app
app = Starlette(debug=True, routes=routes)

Running the App with Uvicorn

uvicorn app:app --host 127.0.0.1 --port 8000

Client Request:

curl http://127.0.0.1:8000/hello

This will return the JSON response {"message": "Hello, World!"}.

Now, let’s follow the request step-by-step, from the moment the client sends an HTTP request to the response being returned.

Step 1: Client Sends HTTP Request

The client sends an HTTP request to the server. For example, a GET request to the /hello endpoint.

GET /hello HTTP/1.1
Host: 127.0.0.1:8000
User-Agent: curl/7.64.1
Accept: */*

Step 2: Uvicorn Accepts the Request

Uvicorn runs a socket server that listens for incoming TCP connections on the specified host/port (e.g., 127.0.0.1:8000). When an HTTP request arrives, Uvicorn:

Accepts the TCP connection.
Parses the HTTP request from the raw TCP data using h11 (a pure-Python HTTP/1.1 library) or httptools (Python binding for the nodejs HTTP parser).

Here, Uvicorn will convert the incoming request into ASGI scope and events.

Step 3: Uvicorn Converts HTTP Request to ASGI Scope

When Uvicorn receives an HTTP request, it converts it into an ASGI scope object.

scope = {
    "type": "http",
    "http_version": "1.1",
    "method": "GET",
    "path": "/hello",
    "query_string": b"",
    "headers": [
        (b"host", b"127.0.0.1:8000"),
        (b"user-agent", b"curl/7.64.1"),
        (b"accept", b"*/*"),
    ],
    "client": ("127.0.0.1", 12345),
    "server": ("127.0.0.1", 8000),
}

Type: The type of connection, which is http for an HTTP request.
HTTP Version: Version of the HTTP protocol (e.g., 1.1).
Method: The HTTP method used in the request (GET, POST, etc.).
Path: The URL path requested (e.g., /hello).
Headers: A list of header key-value pairs.
Client: The client’s IP and port.
Server: The server’s IP and port.

Step 4: Uvicorn Passes the Scope to the ASGI Application

Once Uvicorn has created the ASGI scope, it will start the ASGI application (in this case, Starlette) by calling the application callable:

async def app(scope, receive, send):
    ...

Uvicorn invokes the Starlette app, passing in the scope object.

Step 5: Starlette Processes the Request

Starlette, being an ASGI-compliant framework, takes over at this point. It matches the route (in this case, /hello) and invokes the corresponding route handler.

In this case, the hello function is called when the /hello route is requested. Starlette internally uses the ASGI scope to match the incoming request’s method and path with the defined route.

Request Object: Starlette creates an HTTP request object from the scope and ASGI events received from Uvicorn.
Receiving Events (receive): Starlette receives events that represent parts of the HTTP request, including the request body.

request_event = {
    "type": "http.request",
    "body": b"",  # Request body
    "more_body": False,  # Indicates whether more data will be sent
}

The body field contains the request body (in case of a POST request), and more_body tells the application whether the request body is complete or more data will follow (useful for streaming large files).

Response Handling: The hello route returns a JSONResponse, which wraps the response data and sends it back as ASGI events.

Step 6: Starlette Returns the Response

After processing the request, Starlette sends back the response to Uvicorn by emitting ASGI events like http.response.start and http.response.body:

Starting the Response (http.response.start):

response_start_event = {
    "type": "http.response.start",
    "status": 200,  # HTTP status code
    "headers": [
        (b"content-type", b"application/json"),
    ],
}

This tells Uvicorn to begin sending the HTTP response headers, with a status code of 200 and a content type of application/json.

Sending the Response Body (http.response.body):

response_body_event = {
    "type": "http.response.body",
    "body": b'{"message": "Hello, World!"}',  # JSON response body
    "more_body": False,
}

This sends the response body containing the JSON message {"message": "Hello, World!"}. The more_body: False indicates that this is the final part of the body and that the response is complete.

Step 7: Uvicorn Sends the HTTP Response Back to the Client

Uvicorn receives the ASGI events emitted by Starlette and translates them into HTTP responses. Specifically:

http.response.start triggers Uvicorn to send the HTTP status line and headers (e.g., HTTP/1.1 200 OK).
http.response.body sends the response body (e.g., {"message": "Hello, World!"}) to the client.

Uvicorn closes the connection when it has sent all parts of the response. Let's visualize the journey for better understandning:

sequenceDiagram
    autonumber

    participant Client
    participant Server as ASGI Server
    participant App as ASGI App

    Client->>Server: HTTP request (bytes)

    Note over Server: Parse HTTP <br/> Build ASGI scope
    Server->>App: call app(scope, receive, send)

    alt Request body available
        App->>Server: await receive()
        Server-->>App: http.request <br />(body chunk)
    end

    App->>App: Validate & process request

    alt Valid request
        App->>Server: await send(http.response.start)
        App->>Server: await send(http.response.body)
        Server-->>Client: HTTP response
    else Invalid request
        App->>Server: await send(http.response.start)
        App->>Server: await send(http.response.body (error))
        Server-->>Client: HTTP error response
    end

FastAPI - The High-Level Framework

FastAPI builds upon Starlette to create a framework that’s ideal for developing RESTful APIs. FastAPI’s focus on asynchronous programming, Pydantic integration for data validation, and dependency injection make it powerful and developer-friendly.

Key Features:

Starlette-based routing and request handling.
Pydantic-based data validation.
Dependency Injection system.
Automatic OpenAPI and API documentation generation.

Pydantic - Data Validation and Serialization

FastAPI’s data validation relies on Pydantic, a library that simplifies the handling of complex data types and validation. Pydantic enables FastAPI to enforce strict data validation rules on incoming request data and outgoing response data.

Pydantic Model Example:

from fastapi import FastAPI
from pydantic import BaseModel

# Initialize FastAPI app (this is like initializing Starlette)
app = FastAPI()

# Pydantic model for request data validation
class Item(BaseModel):
    name: str
    price: float
    is_offer: bool = None

# Route with path parameters and Pydantic request body validation
@app.post("/items/")
async def create_item(item: Item):
    return {"item": item}

In the example above:

Client sends a request:

curl -X POST "<http://127.0.0.1:8000/items/>" -H "Content-Type: application/json" -d '{"name": "Table", "price": 150.0}'

FastAPI validates the request body and returns:

{
  "item": {
    "name": "Table",
    "price": 150.0,
    "is_offer": null
  }
}

If a required field (e.g., name) is missing, FastAPI will return an automatic validation error with 422 http status code:

{
  "detail": [
    {
      "loc": ["body", "name"],
      "msg": "field required",
      "type": "value_error.missing"
    }
  ]
}

Pydantic also converts data types as needed, making it easier to handle complex data without extensive validation code.

Dependency Injection in FastAPI

FastAPI’s dependency injection system allows modular, reusable code by injecting resources like database connections, authentication layers, or shared configurations directly into route functions.

Dependency Injection Example:

from fastapi import Depends

def get_db():
    db = DatabaseConnection()
    try:
        yield db
    finally:
        db.close()

@app.get("/items/")
async def read_items(db=Depends(get_db)):
    return db.fetch_all_items()

With Depends, FastAPI manages dependencies automatically, enabling clean, modular, and testable code. Dependency injection is especially useful for managing external services, as it allows centralized control of resource lifecycles.

OpenAPI and Swagger Documentation in FastAPI

FastAPI’s automatic documentation generation feature provides Swagger and ReDoc interfaces without additional setup. By using route definitions, parameter types, and data models, FastAPI creates real-time OpenAPI documentation, making it easy to test and integrate API endpoints.

With documentation available at /docs (Swagger UI) and /redoc (ReDoc), FastAPI provides developers with a quick and interactive way to explore API routes, making it easier for teams and external developers to work with the API.

Request Lifecycle in FastAPI

Here’s a summary of how a request flows through FastAPI:

Client Sends Request: The client sends an HTTP request to the server.
Uvicorn (ASGI Server): Uvicorn receives the request and creates an ASGI scope.
Starlette (Routing): Starlette routes the request to the correct endpoint based on path and method.
FastAPI Endpoint: FastAPI processes any dependencies, validates incoming data with Pydantic, and handles the request.
Response: Uvicorn receives the response from FastAPI and sends it back to the client.

Conclusion

FastAPI’s architecture combines multiple components to achieve a fast, reliable, and easy-to-use API framework:

ASGI is the backbone of modern Python web frameworks. It enables asynchronous operations.
Uvicorn provides efficient connection handling.
Starlette is the core web framework handling routing and middlewares.
FastAPI extends Starlette with data validation via Pydantic, dependency injection & automatic API docs.

The Journey of an HTTP Request in Python: Part 1

Rafiqul Hasan — Thu, 11 Dec 2025 00:00:00 GMT

When you type a URL into your browser and hit enter, an extraordinary journey begins. Within milliseconds, your request traverses network cables, gets processed by operating system kernels, flows through Python runtimes, and eventually produces the response you see on screen. This journey is so fast and seamless that we rarely stop to think about the complex choreography happening beneath the surface.

This two-part series traces the complete journey of an HTTP request in Python's ASGI ecosystem. Part 1 focuses on the operating system layer, how packets arrive at your network card, flow through the kernel's TCP/IP stack and land in socket buffers. Part 2 will explore the application layer, how Python's asyncio event loop, ASGI servers like Uvicorn and your web framework collaborate to turn those bytes into responses.

By the end of this series, you'll understand exactly what happens when someone makes a request to your FastAPI application, and why ASGI is designed the way it is.

Let's begin at the lowest level, where photons become packets, and hardware becomes software.

The Big Picture

Before we dive into details, let's visualize the complete journey from a high level:

flowchart TD

    A[Browser sends HTTP Request over TCP] 
        -->|TCP Packet sent over network| B[Network Interface Card <br/> NIC - Physical Layer]

    B -->|Hardware Interrupt| C[Kernel Network Stack <br/> L2 → L3 → L4 processing]

    C -->|Packet validated & queued| D[TCP/IP: Reassembly, checksum, flow-control]

    D -->|Payload copied into <br/> socket receive buffer| E[Socket File Descriptor <br/> Kernel socket + buffers]

    E -->|system call </br> epoll/select/recv| F[Python Runtime <br/> Interpreter + asyncio]

    F -->|asyncio selector </br> ready FD detected| G[ASGI Server - Uvicorn<br/>HTTP parsing, ASGI lifespan handler]

    G -->|Invoke ASGI application <br/> scope/receive/send| H[ASGI Application - FastAPI <br/> Routing, middleware, handler execution]

    H -->|Return Response object <br/> body, headers, status| G

    G -->|Serialize & write response bytes send| E

    E -->|Kernel places data into socket send buffer| D

    D -->|TCP segmentation, ACK handling, window checks| C

    C -->|Hand packet to NIC driver| B

    B -->|Transmit TCP Packet over network| A

This diagram shows the complete path, but it barely scratches the surface. Let's explore each layer in detail.

1. The Kernel Receives Data

Network Interface and Interrupts

When data arrives at your server, the first component to know about it isn't your Python application or even the operating system's high-level network code. It's the Network Interface Card (NIC) hardware itself.

Here's what happens:

Packet Arrival: The NIC receives electrical signals (or light pulses for fiber) representing your HTTP request
DMA Transfer: The NIC uses Direct Memory Access to write the packet data directly into a pre-allocated kernel memory buffer
Hardware Interrupt: The NIC triggers a hardware interrupt to notify the CPU that data has arrived
Interrupt Handler: The kernel's interrupt handler is invoked, which schedules the network stack to process this data

This all happens in microseconds, and it's happening for potentially thousands of packets per second on a busy server.

sequenceDiagram
    participant NIC as Network Card
    participant KM as Kernel Memory
    participant CPU as CPU
    participant NS as Network Stack
    
    NIC->>KM: DMA write packet data
    NIC->>CPU: Hardware interrupt
    CPU->>CPU: Save current state
    CPU->>NS: Schedule packet processing
    NS->>NS: Process TCP/IP layers
    NS->>KM: Write to socket buffer

TCP/IP Stack Processing

Once the interrupt handler schedules packet processing, the kernel's network stack processes the packet through multiple protocol layers. This happens entirely in kernel space.

Ethernet Layer: Strips off the Ethernet frame, validates the destination MAC address
IP Layer: Validates IP header, checks destination IP, handles fragmentation if needed
TCP Layer: This is where the real work happens. The kernel:
- Validates checksum: Ensures data integrity
- Looks up connection: Uses (src_ip, src_port, dst_ip, dst_port) to find the socket
- Checks sequence numbers: Handles out-of-order packets and duplicates
- Updates state machine: Manages TCP states (ESTABLISHED, FIN_WAIT, etc.)
- Performs flow control: Adjusts receive window based on buffer availability
- Sends ACK: Acknowledges received data automatically
Delivering to the socket: Once the kernel identifies the destination socket, it:
- Copies payload data into the socket's receive buffer
- Updates buffer pointers and available byte count
- Wakes any process/coroutine waiting on this socket (via the wait queue)

Let's visualize the journey:

sequenceDiagram
    participant NIC as Network Interface Card
    participant LinkL as Link Layer (Ethernet)
    participant IP as Network Layer (IP)
    participant TCP as Transport Layer (TCP)
    participant Socket as Socket Buffer
    
    NIC->>LinkL: Packet arrives via DMA
    Note over LinkL: Strip Ethernet header (14 bytes)<br/>Validate MAC
    
    LinkL->>IP: Pass to IP layer
    Note over IP: Strip IP header (20+ bytes)<br/>Validate checksum, TTL, destination IP
    
    IP->>TCP: Pass to TCP layer
    Note over TCP: Strip TCP header (20+ bytes)<br/>Hash lookup: find socket<br/>Validate checksum
    
    alt Sequence in order
        TCP->>Socket: Copy payload to recv buffer
        TCP->>Socket: Update expected_seq
        TCP->>NIC: Send ACK (automatic)
    else Sequence out of order
        TCP->>TCP: Queue in reassembly buffer
        TCP->>NIC: Send duplicate ACK
    end
    
    TCP->>Socket: Update bytes_available
    TCP->>Socket: Update receive window
    Note over Socket: Data ready for application<br/>Process woken via wait queue

The entire journey from NIC interrupt to socket buffer typically takes 10-100 microseconds on modern hardware. This processing happens for every single packet, which is why kernel optimization is crucial for high-performance networking.

Socket Buffers: The Kernel-Userspace Bridge

Once the kernel identifies which socket the packet belongs to using the connection's four-tuple source IP:port, dest IP:port, it writes the data into that socket's receive buffer, a ring buffer allocated in kernel memory. This buffer is the critical interface between kernel space and user space.

Each socket maintains two buffers:

// Kernel maintains these internally (simplified representation)
struct socket_buffers {
    char recv_buffer[SO_RCVBUF];  // Default: 208KB on Linux
    char send_buffer[SO_SNDBUF];  // Default: 208KB on Linux
    size_t recv_bytes_available;
    size_t send_bytes_used;
    wait_queue_head_t wait_queue; // Processes waiting on this socket
};

When TCP segments arrive, the kernel:

Validates sequence numbers and checksums
Reassembles out-of-order segments using sequence numbers
Writes data to the receive buffer
Sends ACK back to sender (automatic)
Wakes any process/coroutine blocked on this socket

The receive buffer size determines TCP's receive window—how much unacknowledged data the sender can transmit. If your application doesn't read fast enough and the buffer fills, the kernel advertises a zero window, throttling the sender.

For sending, when you call send(), data is copied from user space to the kernel's send buffer. The kernel then:

Segments data into TCP packets (Maximum Segment Size typically 1460 bytes)
Transmits segments with sequence numbers
Retains copies until ACKed (for potential retransmission)
Removes acknowledged data from buffer

You can inspect and tune buffer sizes:

import socket

sock = socket.socket()
# Check current sizes
recv_buf = sock.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)
send_buf = sock.getsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF)

# Increase for high-bandwidth connections
sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1048576)  # 1MB
sock.setsockopt(socket.SOL_SOCKET, socket.SO_SNDBUF, 1048576)

These buffers decouple application read/write speed from network speed, enabling efficient pipelining and flow-control essential for TCP's reliability guarantees. Let's take a look at the full picture:

sequenceDiagram
    participant Net as Network
    participant Kernel as Kernel Space<br/>(TCP + Buffers)
    participant Syscall as System Call<br/>Boundary
    participant App as Application<br/>(User Space)
    
    Note over Net,App: Receiving Data
    
    Net->>Kernel: TCP segments arrive
    Kernel->>Kernel: Validate & reassemble
    Kernel->>Kernel: Write to receive buffer (208KB)
    Kernel->>Net: Send ACK automatically
    Kernel->>Kernel: Update bytes_available
    Kernel-->>App: Wake blocked coroutine
    
    App->>Syscall: recv(4096)
    Note over Syscall: Copy from kernel to user space
    Syscall->>App: Return data bytes
    
    Note over Net,App: Sending Data
    
    App->>Syscall: send(response)
    Note over Syscall: Copy from user to kernel space
    Syscall->>Kernel: Write to send buffer (208KB)
    
    Kernel->>Kernel: Segment into TCP packets (MSS 1460)
    Kernel->>Kernel: Retain copy until ACKed
    Kernel->>Net: Transmit segments
    
    Net-->>Kernel: ACK received
    Kernel->>Kernel: Remove acknowledged data from buffer

2. System Calls and File Descriptors

The Socket File Descriptor

In Unix-like systems, the philosophy is "everything is a file", including network sockets. When your application creates a socket, the kernel returns a file descriptor: a small non-negative integer that serves as an index into the process's file descriptor table.

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
fd = sock.fileno()  # Returns an integer like 3, 4, 5, etc.
print(f"Socket file descriptor: {fd}")

What the file descriptor represents:

The kernel maintains a per-process table mapping file descriptors to kernel data structures. For sockets, this points to a struct socket containing:

Socket buffers (send/receive)
Connection state (ESTABLISHED, CLOSE_WAIT, etc.)
Peer address (IP:port)
Protocol-specific data (TCP sequence numbers, window size)
File operations table (read, write, close functions)

Why file descriptors matter:

Every socket operation requires passing this file descriptor to the kernel:

import os

# All these operations use the file descriptor internally
data = sock.recv(4096)        # → recv(fd, buffer, 4096)
sock.send(b"data")            # → send(fd, "data", 4)
sock.close()                  # → close(fd)

# You can even use low-level os functions
os.read(fd, 4096)             # Works! Treats socket like a file
os.write(fd, b"data")         # Also works!

File descriptor limits:

Each process has limits on open file descriptors (typically 1024 by default, configurable up to system limits). This matters for servers handling thousands of connections:

# Check current limits
ulimit -n  # Soft limit: 1024

# Increase for production servers
ulimit -n 65536

When you run out of file descriptors, accept() fails with "Too many open files", a common production issue. ASGI servers handle this by configuring appropriate limits and connection pooling.

System Calls: Crossing the Boundary

System calls are the mechanism for transitioning from user space (where your Python code runs) to kernel space (where the OS manages hardware and resources). This transition is expensive compared to normal function calls. It involves context switching, privilege level changes, and potentially copying data.

What happens during a system call:

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

This innocent-looking Python call triggers:

Python → C library wrapper
C library → software interrupt (syscall instruction)
CPU switches to kernel mode
Kernel validates parameters, performs operation
CPU switches back to user mode
Return value propagated back to Python

Here are the key system calls involved in our HTTP request journey:

import socket

# socket() - Create socket structure in kernel
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# bind() - Associate socket with address
sock.bind(('0.0.0.0', 8000))

# listen() - Mark socket as passive, create accept queue  
sock.listen(128)

# accept() - Retrieve connection from queue (blocks if empty)
client, addr = sock.accept()

# recv() - Copy data from kernel buffer to user space
data = client.recv(4096)

# send() - Copy data from user space to kernel buffer
client.send(b"HTTP/1.1 200 OK\r\n\r\n")

# close() - Release socket resources
client.close()

Let's look at what happens during a recv() call:

sequenceDiagram
    participant App as Python Application
    participant Lib as Python Socket Library
    participant Kernel as Linux Kernel
    participant Buffer as Socket Buffer
    
    App->>Lib: sock.recv(4096)
    Lib->>Kernel: recv() syscall
    Note over Kernel: Switch to kernel mode
    Kernel->>Buffer: Check if data available
    alt Data available
        Buffer->>Kernel: Return data
        Kernel->>Lib: Copy to user space
        Lib->>App: Return bytes
    else No data available
        Kernel->>Kernel: Block process
        Note over Kernel: Process sleeps until data arrives
        Buffer->>Kernel: Data arrives
        Kernel->>Lib: Copy to user space
        Lib->>App: Return bytes
    end

Blocking vs Non-Blocking Sockets

Traditional socket programming is blocking. When you call recv() and there's no data available, your process goes to sleep until data arrives. This is fine for simple applications, but it's disastrous for servers that need to handle thousands of concurrent connections.

import socket

# Blocking socket (default)
sock = socket.socket()
sock.connect(('example.com', 80))
data = sock.recv(4096)  # This BLOCKS until data arrives
print(data)

To handle multiple connections, you have three main options:

Multi-threading: One thread per connection (expensive, doesn't scale to thousands)
Multi-processing: One process per connection (even more expensive)
Non-blocking I/O with event loops: Handle many connections in one thread (efficient, scalable)

ASGI is built on non-blocking sockets and uses an event loop to efficiently multiplex between many connections.

import socket
import select

# Non-blocking socket
sock = socket.socket()
sock.setblocking(False)  # This is the key!

try:
    sock.connect(('example.com', 80))
except BlockingIOError:
    pass  # Connect is in progress

# Use select/epoll to wait for socket to be ready
select.select([sock], [sock], [], 5.0)
# Now socket is ready for I/O

Conclusion

We've journeyed from the physical layer to the kernel-userspace boundary, witnessing how an HTTP request traverses the operating system's networking stack. From the moment network packets arrive at your NIC, through hardware interrupts and DMA transfers, to TCP/IP processing and socket buffers, every step is orchestrated by the kernel with microsecond precision.

The key insights from this exploration:

Hardware and kernel handle the heavy lifting: Your application never sees individual packets, TCP handshakes, or retransmissions, the kernel manages all of this automatically
Socket buffers are the critical interface: These kernel-space ring buffers decouple network speed from application speed, enabling efficient flow control
System calls are expensive: Every transition between user and kernel space involves context switches, which is why minimizing these calls matters for performance

At this point in our journey, data sits ready in socket receive buffers, waiting for your application to read it. The kernel has done its job ensuring reliable, ordered delivery of bytes. But how does Python efficiently monitor potentially thousands of these sockets without blocking? How does a single thread handle concurrent connections?

In Part 2, we'll explore the application layer—where asyncio's event loop, epoll multiplexing, and the ASGI protocol come together to build the scalable web applications you write every day. We'll see how Python bridges the gap between low-level socket operations and high-level framework code, making concurrent programming both powerful and elegant.

The Journey of an HTTP Request in Python: Part 2

Rafiqul Hasan — Sat, 13 Dec 2025 00:00:00 GMT

In Part 1, we followed an HTTP request from the network interface card through the kernel's TCP/IP stack to socket buffers. We saw how hardware interrupts trigger kernel processing, how TCP ensures reliability, and how socket buffers bridge kernel and user space. But our journey isn't complete. The data is sitting in kernel memory and your Python application still hasn't touched it.

Part 2 picks up where we left off, at the boundary between the operating system and your application. We'll explore how Python's asyncio event loop efficiently monitors thousands of sockets using epoll, how ASGI servers like Uvicorn translate raw bytes into structured messages, and how your FastAPI application processes requests without blocking.

This is where the elegance of ASGI shines. While Part 1 showed us the raw power of the kernel handling packets at microsecond speeds, Part 2 reveals how Python leverages that power to build scalable, concurrent web applications with clean, readable code.

Let's cross the system call boundary and enter the world of async Python.

3. The Event Loop and I/O Multiplexing

The Problem with Blocking I/O

Imagine a web server handling 10,000 concurrent connections. With blocking I/O, you'd need 10,000 threads or processes. Each thread consumes memory (typically 1-8 MB of stack space), and context switching between thousands of threads destroys CPU cache efficiency.

The solution is I/O multiplexing: using a single thread to monitor many file descriptors and only processing them when they're ready.

Enter epoll/kqueue/select

Operating systems provide system calls for efficient I/O multiplexing:

select: The oldest, works on all platforms, limited to ~1024 file descriptors
poll: Similar to select but no hard limit on file descriptors
epoll (Linux): Highly efficient (uses a red–black tree), O(1) performance for ready events
kqueue (BSD/macOS): Similar to epoll

Python's asyncio uses the most efficient mechanism available on your platform. On Linux, that's epoll.

import select
import socket

# Create a listening socket
server = socket.socket()
server.setblocking(False)
server.bind(('0.0.0.0', 8000))
server.listen(128)

# Create epoll object
epoll = select.poll()
epoll.register(server.fileno(), select.POLLIN)

# Event loop
connections = {}
while True:
    # Wait for events (this is a blocking syscall, but efficient!)
    events = epoll.poll()
    
    for fd, event in events:
        if fd == server.fileno():
            # New connection
            client, addr = server.accept()
            client.setblocking(False)
            epoll.register(client.fileno(), select.POLLIN)
            connections[client.fileno()] = client
        else:
            # Data on existing connection
            client = connections[fd]
            data = client.recv(4096)
            print(data.decode())
            client.send(b"HTTP/1.1 200 OK\r\n\r\nHello")
            epoll.unregister(fd)
            client.close()
            del connections[fd]

This pattern register file descriptors with epoll, wait for events, handle ready sockets is the foundation of all async Python frameworks.

Python's asyncio Event Loop

Python's asyncio wraps this low-level epoll/kqueue machinery in a high-level API with coroutines, tasks, and futures. Here's a simplified view of what the event loop does:

sequenceDiagram
    autonumber

    participant Kernel as Kernel (epoll/kqueue)
    participant FD as Socket FD
    participant eLoop as asyncio Event Loop
    participant Task as Coroutine / Future

    Note over eLoop: Event loop initialization
    eLoop->>Kernel: epoll_ctl(ADD, FD)

    Note over eLoop,Kernel: Main event loop cycle
    eLoop->>Kernel: epoll_wait()
    Kernel-->>eLoop: ready FD events

    alt FD readable
        eLoop->>FD: non-blocking recv()
        FD-->>eLoop: data or EAGAIN
        eLoop->>Task: schedule coroutine to handle data
    end

    alt FD writable
        Task->>FD: non-blocking send()
        FD-->>Task: bytes_written or EAGAIN
        Task->>eLoop: yield until FD writable
    end

    Note over eLoop: Loop repeats
    eLoop->>Kernel: epoll_wait()

Here's what this looks like in actual asyncio code:

import asyncio

async def handle_client(reader, writer):
    """Handle a single client connection"""
    # reader.read() doesn't block the thread!
    # It yields control back to the event loop
    data = await reader.read(4096)
    
    # Process request
    response = b"HTTP/1.1 200 OK\r\n\r\nHello World"
    
    # writer.write() is synchronous, but drain() waits for the write to complete
    writer.write(response)
    await writer.drain()
    
    writer.close()
    await writer.wait_closed()

async def main():
    # Start server
    server = await asyncio.start_server(
        handle_client, 
        '0.0.0.0', 
        8000
    )
    
    async with server:
        await server.serve_forever()

# Run the event loop
asyncio.run(main())

When await reader.read(4096) is called:

The asyncio event loop checks if data is available in the kernel socket buffer (epoll_ctl)
If not available, it registers interest in this socket with epoll (epoll_wait)
The coroutine is suspended, event loop continues with other tasks
When data arrives, kernel notifies epoll, event loop resumes the coroutine (performs recv())
Data is read from kernel buffer to user space (via recv()) and returned

When writer.write(response) is called:

The asyncio event loop checks if the socket is writable (if the kernel send buffer has space)
If the send buffer is full, the event loop registers interest in writable events using epoll_wait.
The coroutine is suspended, and the event loop continues running other tasks
When kernel buffer becomes available, kernel notifies epoll and event loop resumes the suspended coroutine (performs send())
Data is copied from user space into the kernel buffer (via send()) and returns once the write is accepted

4. ASGI Protocol

Why ASGI Exists

We've now covered how data gets from the network card to the Python event loop. But there's still a gap: how does the event loop pass HTTP requests to your web application (FastAPI)? This is where ASGI comes in. ASGI is a specification, an agreed-upon interface between web servers (like Uvicorn) and web applications (like FastAPI).

Before ASGI, we had WSGI (Web Server Gateway Interface), which worked perfectly for synchronous Python. But WSGI has a fundamental limitation: it's synchronous and blocking. Every request blocks a worker thread. ASGI solves this by defining an async interface that allows servers and applications to communicate using coroutines.

The ASGI Interface

At its core, ASGI defines two things:

Application: A coroutine that receives events and can send events back
Message format: Standardized dictionaries for communication

Here's the signature of an ASGI application:

async def application(scope, receive, send):
    """
    scope: dict - Information about the connection (HTTP or WebSocket)
    receive: coroutine - Receive messages from the server
    send: coroutine - Send messages to the server
    """
    pass

Let's build a simple ASGI application to see how this works:

async def hello_world_app(scope, receive, send):
    """Simplest possible ASGI application"""
    
    # scope contains connection metadata
    if scope['type'] == 'http':
        # Wait for the HTTP request body (even if empty)
        await receive()
        
        # Send response start (status and headers)
        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                [b'content-type', b'text/plain'],
            ],
        })
        
        # Send response body
        await send({
            'type': 'http.response.body',
            'body': b'Hello, World!',
        })

This looks simple, but notice what's happening:

The application is completely async
It communicates with the server through the receive and send coroutines
Messages are just dictionaries with standardized keys

ASGI Server: Bridging Sockets and Applications

An ASGI server like Uvicorn sits between the socket layer and your application. Its job is to:

Accept connections from clients
Parse HTTP requests from raw bytes
Convert them to ASGI messages
Call your application
Convert ASGI response messages back to HTTP bytes
Send them back through the socket

Here's a simplified view of what Uvicorn does (this is a fully working code, you may run and test it yourself):

import asyncio
import httptools


class ASGIServer:
    def __init__(self, app):
        self.app = app

    async def handle_connection(self, reader, writer):
        parser = httptools.HttpRequestParser(self)
        self.parser = parser  # attached for callbacks
        self.writer = writer
        self.reader = reader
        self.headers = []
        self.body = b""
        self.url = None
        self.method = None
        self.complete = False
        self.upgrade = False

        try:
            while not self.complete:
                data = await reader.read(65536)
                if not data:
                    return  # client disconnected
                parser.feed_data(data)  # may raise HttpParserError → caught below

            # After on_message_complete(), we have a full request → run ASGI app
            await self._run_app()

        except httptools.HttpParserError:
            self._write_response(b"HTTP/1.1 400 Bad Request\r\n\r\n")
        except Exception as e:
            print("Error:", e)
            self._write_response(b"HTTP/1.1 500 Internal Error\r\n\r\n")
        finally:
            writer.close()
            await writer.wait_closed()

    # ─────── httptools callbacks ───────
    def on_url(self, url: bytes):
        self.url = url
        parsed = httptools.parse_url(url)
        self.path = parsed.path.decode() if parsed.path else "/"
        self.query_string = parsed.query or b""

    def on_header(self, name: bytes, value: bytes):
        self.headers.append((name.lower(), value))

    def on_headers_complete(self):
        self.method = self.parser.get_method().decode()

    def on_body(self, body: bytes):
        self.body += body

    def on_message_complete(self):
        self.complete = True

    # ─────── Helper to send raw HTTP response (used only on errors) ───────
    def _write_response(self, data: bytes):
        try:
            self.writer.write(data)
            asyncio.create_task(self.writer.drain())
        except:
            pass

    # ─────── Run the actual ASGI application ───────
    async def _run_app(self):
        scope = {
            "type": "http",
            "asgi": {"version": "3.0", "spec_version": "2.3"},
            "http_version": "1.1",
            "method": self.method,
            "scheme": "http",
            "path": self.path,
            "raw_path": self.url,
            "query_string": self.query_string,
            "headers": self.headers,
            "server": ("127.0.0.1", 8000),
            "client": self.writer.get_extra_info("peername"),
        }

        # receive() – streams body if app asks for it
        async def receive():
            if self.body:
                body, self.body = self.body, b""
                return {"type": "http.request", "body": body, "more_body": False}
            return {"type": "http.request", "body": b"", "more_body": False}

        # send() – converts ASGI messages → raw HTTP via httptools
        async def send(message):
            if message["type"] == "http.response.start":
                status = message["status"]
                headers = message.get("headers", [])

                # Build response line + headers
                out = f"HTTP/1.1 {status} OK\r\n".encode()
                for name, value in headers:
                    out += name + b": " + value + b"\r\n"
                out += b"\r\n"

                self.writer.write(out)
                await self.writer.drain()

            elif message["type"] == "http.response.body":
                body = message.get("body", b"")
                if body:
                    self.writer.write(body)
                    await self.writer.drain()

        # Run the ASGI app
        await self.app(scope, receive, send)

    async def serve(self, host="127.0.0.1", port=8000):
        server = await asyncio.start_server(self.handle_connection, host, port)

        print(f"ASGI server running on http://{host}:{port}")
        async with server:
            await server.serve_forever()


# —————————— Simple application ——————————
async def app(scope, receive, send):

    await send(
        {
            "type": "http.response.start",
            "status": 200,
            "headers": [(b"content-type", b"text/plain")],
        }
    )
    await send({"type": "http.response.body", "body": b"Hello from ASGI server!\n"})


# —————————— Run the server ——————————
if __name__ == "__main__":
    server = ASGIServer(app)
    try:
        asyncio.run(server.serve("127.0.0.1", 8000))
    except KeyboardInterrupt:
        print("\nServer stopped")

The Complete Flow

Let's trace a complete HTTP request through all layers:

sequenceDiagram
    participant Client
    participant NIC
    participant Kernel
    participant EventLoop as asyncio Event Loop
    participant Server as Uvicorn
    participant App as FastAPI App
    
    Client->>NIC: TCP packet with HTTP request
    NIC->>Kernel: Hardware interrupt
    Kernel->>Kernel: TCP/IP processing
    Kernel->>Kernel: Write to socket buffer
    Kernel->>EventLoop: epoll notification
    EventLoop->>Server: Socket is readable
    Server->>Kernel: recv() syscall
    Kernel->>Server: Return HTTP bytes
    Server->>Server: Parse HTTP request
    Server->>App: Call app(scope, receive, send)
    App->>App: Process request
    App->>Server: send(http.response.start)
    App->>Server: send(http.response.body)
    Server->>Server: Build HTTP response bytes
    Server->>Kernel: send() syscall
    Kernel->>Kernel: Write to socket send buffer
    Kernel->>Kernel: TCP/IP processing
    Kernel->>NIC: Schedule packet transmission
    NIC->>Client: TCP packet with HTTP response

Wait! Did we miss something? What about TCP handshake? Well, let's take a look at that briefly.

Three-Way Handshake

When a client connects, the kernel automatically completes a three-step handshake:

Client → Server (SYN): "I want to connect, my sequence number is x"
Server → Client (SYN-ACK): "Acknowledged, my sequence number is y"
Client → Server (ACK): "Acknowledged, connection established"

Your application doesn't see these packets—the kernel handles everything. When you call accept(), you get a fully-established connection:

client, addr = server.accept()  # Returns after handshake completes

Data Transfer

Now HTTP data flows bidirectionally. Each send() and recv() moves data between your application and the kernel's socket buffers:

request = client.recv(4096)      # Read HTTP request
client.send(b"HTTP/1.1 200 OK")  # Send HTTP response

The kernel handles TCP's reliability—retransmitting lost packets, reordering segments, and managing flow control.

Four-Way Teardown

Closing requires four steps because TCP is full-duplex (two independent pipes):

Client sends FIN: "I'm done sending"
Server sends ACK: "Got it"
Server sends FIN: "I'm done too"
Client sends ACK: "Got it, goodbye"

client.close()  # Initiates graceful shutdown

This graceful close ensures no data is lost. After closing, the port enters TIME_WAIT state (60-120 seconds) to handle any delayed packets.

Here's the full trace of a complete HTTP request through all layers:

sequenceDiagram
    participant Client
    participant NIC
    participant Kernel
    participant EventLoop as asyncio Event Loop
    participant Server as Uvicorn
    participant App as FastAPI App
    
    Note over Client,App: TCP 3-Way Handshake
    Client->>NIC: SYN (seq=x)
    NIC->>Kernel: Hardware interrupt
    Kernel->>Kernel: TCP processing
    Kernel->>NIC: SYN-ACK (seq=y, ack=x+1)
    NIC->>Client: SYN-ACK
    Client->>NIC: ACK (ack=y+1)
    NIC->>Kernel: Hardware interrupt
    Kernel->>Kernel: Connection ESTABLISHED
    Kernel->>EventLoop: epoll notification (new connection)
    EventLoop->>Server: accept() ready
    Server->>Kernel: accept() syscall
    Kernel->>Server: Return client socket fd
    
    Note over Client,App: HTTP Request/Response
    Client->>NIC: TCP packet with HTTP request
    NIC->>Kernel: Hardware interrupt
    Kernel->>Kernel: TCP/IP processing
    Kernel->>Kernel: Write to socket buffer
    Kernel->>EventLoop: epoll notification (data ready)
    EventLoop->>Server: Socket is readable
    Server->>Kernel: recv() syscall
    Kernel->>Server: Return HTTP bytes
    Server->>Server: Parse HTTP request
    Server->>App: Call app(scope, receive, send)
    App->>App: Process request
    App->>Server: send(http.response.start)
    App->>Server: send(http.response.body)
    Server->>Server: Build HTTP response bytes
    Server->>Kernel: send() syscall
    Kernel->>Kernel: Write to socket send buffer
    Kernel->>Kernel: TCP/IP processing
    Kernel->>NIC: Schedule packet transmission
    NIC->>Client: TCP packet with HTTP response
    
    Note over Client,App: TCP Connection Close
    Client->>Client: CLOSE call
    Note over Client: State: FIN-WAIT-1
    Client->>NIC: FIN (seq=m)
    NIC->>Kernel: Hardware interrupt
    Kernel->>Kernel: TCP processing
    Note over Kernel: State: CLOSE-WAIT
    Kernel->>EventLoop: epoll notification (FIN received)
    EventLoop->>Server: Socket readable (EOF)
    Server->>Kernel: recv() returns 0
    Kernel->>NIC: ACK (ack=m+1)
    NIC->>Client: ACK
    Note over Client: State: FIN-WAIT-2
    Note over Kernel: Server can still send data
    Server->>Server: CLOSE call
    Note over Kernel: State: LAST-ACK
    Kernel->>NIC: FIN (seq=n)
    NIC->>Client: FIN
    Client->>NIC: ACK (ack=n+1)
    Note over Client: State: TIME-WAIT (2MSL)
    NIC->>Kernel: Hardware interrupt
    Note over Kernel: State: CLOSED
    Note over Client: After 2MSL → CLOSED

Conclusion

We've completed our journey from hardware to handler, connecting the dots between Part 1's kernel-level operations and Part 2's application-layer abstractions. In Part 1, we saw how the kernel handles packets, manages TCP reliability, and fills socket buffers. Now we understand how Python's asyncio efficiently monitors those buffers, how ASGI servers translate bytes into structured messages, and how frameworks route requests to your code.

The complete picture reveals why ASGI-based applications scale:

Efficient delegation: The event loop delegates socket monitoring to the kernel's epoll, avoiding expensive polling
Non-blocking operations: Coroutines yield control instead of blocking threads, enabling massive concurrency
Minimal overhead: ASGI adds almost no latency, the expensive parts remain network transmission and system calls
Clean abstractions: Despite the complexity underneath, you write simple async def handlers

In future posts, we'll use this knowledge to build our own ASGI server from scratch, implementing every layer we've discussed today. But for now, the next time you write @app.get("/"), you'll know the incredible journey that happens when someone visits that endpoint. And that understanding makes you a better developer.