WebSockets in PHP — Stop Zombie Connections in Ratchet

WebSocket connections are supposed to be persistent. But in production, half-open connections silently accumulate—clients disconnect without closing the handshake, and the server holds stale sockets forever. Each zombie eats a port, a file descriptor, and a chunk of memory. You don't notice until your Ratchet server runs out of FDs at 3 AM. That's the real cost of skipping proper handshake validation. This article shows how to detect and close those zombies at the protocol level, not just at the application layer.

What is WebSockets in PHP?

WebSockets let you maintain a persistent, bidirectional communication channel between a client and server. In PHP, Ratchet is the most mature library, built on top of ReactPHP's event loop. Unlike traditional HTTP—which dies after each request—a WebSocket connection stays open after the upgrade handshake. That handshake is where most zombie problems start: if the server doesn't properly validate the client's Sec-WebSocket-Key and Sec-WebSocket-Version, it can end up with a half-baked connection that never sends or receives properly.

<?php

namespace io\thecodeforge\websocket;

use Ratchet\MessageComponentInterface;
use Ratchet\ConnectionInterface;

class ZombieKiller implements MessageComponentInterface
{
    public function onOpen(ConnectionInterface $conn)
    {
        // Validate handshake manually if needed
        // Ratchet does basic validation, but we can check origin, etc.
        echo "New connection: {$conn->resourceId}\n";
    }

    public function onMessage(ConnectionInterface $from, $msg)
    {
        // Handle incoming message
        echo "Received: $msg\n";
    }

    public function onClose(ConnectionInterface $conn)
    {
        // Clean up resources
        echo "Connection {$conn->resourceId} closed\n";
    }

    public function onError(ConnectionInterface $conn, \Exception $e)
    {
        // Log and close
        echo "Error on {$conn->resourceId}: {$e->getMessage()}\n";
        $conn->close();
    }
}

Handshake Validation & Upgrade

The WebSocket handshake is an HTTP upgrade request. The client sends GET /chat HTTP/1.1 with headers Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key: base64-encoded 16 bytes, Sec-WebSocket-Version: 13. The server MUST respond with 101 Switching Protocols and a Sec-WebSocket-Accept header computed from the key. If any header is missing or the version isn't 13, the connection should be rejected immediately. Ratchet does this automatically, but you can intercept the handshake via middleware to add origin validation or rate limiting.

<?php

namespace io\thecodeforge\websocket;

use GuzzleHttp\Psr7\Response;
use Psr\Http\Message\RequestInterface;
use Ratchet\Http\HttpServerInterface;

class HandshakeValidator implements HttpServerInterface
{
    public function onOpen($conn, RequestInterface $request = null)
    {
        $origin = $request->getHeaderLine('Origin');
        if (!in_array($origin, ['https://myapp.com'])) {
            $conn->send(new Response(403, [], 'Forbidden'));
            $conn->close();
            return;
        }
        // Continue with Ratchet's default onOpen
    }
}

Managing Connections and Rooms

In production, you need to group connections into rooms or channels for broadcasting. Ratchet provides a Topic abstraction in Ratchet\Wamp\WampServerInterface, but for raw WebSockets you'll manage your own data structure. A SplObjectStorage keyed by room name works, but be careful: removing dead connections is manual. Every onClose must remove the connection from all rooms it belongs to. Failure to do so leaks references, and the garbage collector won't save you—the SplObjectStorage holds a strong reference.

<?php

namespace io\thecodeforge\websocket;

use Ratchet\ConnectionInterface;

class RoomManager
{
    private $rooms = [];

    public function add(ConnectionInterface $conn, string $room): void
    {
        $this->rooms[$room][spl_object_id($conn)] = $conn;
    }

    public function remove(ConnectionInterface $conn): void
    {
        foreach ($this->rooms as &$connections) {
            unset($connections[spl_object_id($conn)]);
        }
    }

    public function broadcast(string $room, $message): void
    {
        if (!isset($this->rooms[$room])) return;
        foreach ($this->rooms[$room] as $conn) {
            $conn->send($message);
        }
    }
}

// In onClose:
// $roomManager->remove($conn);

Why Your First WebSocket Server Will Leak Memory (and How to Fix It)

Every connection consumes resources. PHP's shared-nothing architecture means each WebSocket client holds memory until explicitly freed. The trap: forgetting to close connections after disconnect events. When a client drops (network timeout, tab close, crash), your server won't know until the next read attempt. That zombie connection keeps its buffer, socket, and room membership alive. The fix: implement a heartbeat ping-pong every 30 seconds. On missing two consecutive pongs, forcefully close the socket. Use

if ($lastPong < time() - 60) { $conn->close(); }

Also register a 'close' handler that immediately decrements room counters and frees any per-connection state. Test this with 100 concurrent clients and compare memory before/after. You'll see the difference in the first minute.

// io.thecodeforge
class Connection {
    public function __construct(
        private Socket $socket,
        private string $id,
    ) {
        $this->lastPong = time();
    }

    public function pongReceived(): void {
        $this->lastPong = time();
    }

    public function shouldClose(): bool {
        return $this->lastPong < time() - 60;
    }
}

class HeartbeatLoop {
    public function check(
        ConnectionRepo $repo
    ): void {
        foreach ($repo->all() as $conn) {
            if ($conn->shouldClose()) {
                $conn->close();
                $repo->remove($conn->id);
                EventBus::emit('connection.closed', $conn->id);
            }
        }
    }
}

Broadcast to Rooms Without Blocking Your Event Loop

When you broadcast a message to 1000 clients in a room, don't loop sequentially. Each fwrite() call blocks until the write buffer is full or the socket is ready. One slow client (e.g., mobile on 3G) holds up everyone behind it. Solution: use non-blocking writes with a write queue. Push messages into a per-connection buffer, then process them in batches during your main loop's write phase. PHP 8.x's Swoole or ReactPHP handle this natively, but with raw sockets you must do it manually. Track each connection's write buffer size; if it exceeds 64KB, close the connection before it balloons into an OOM. Use socket_set_nonblock() and socket_write() with a return check. This pattern turns a O(n) broadcast into O(1) per client.

// io.thecodeforge
class Room {
    public function __construct(private array $members = []) {}

    public function broadcast(string $message): void {
        $frame = $this->encode($message);
        foreach ($this->members as $conn) {
            $conn->writeQueue[] = $frame;
        }
    }

    public function flush(): void {
        foreach ($this->members as $conn) {
            $buffer = '';
            while ($buffer = array_shift($conn->writeQueue)) {
                $written = @socket_write($conn->socket, $buffer);
                if ($written === false || strlen($buffer) > 65536) {
                    $conn->close();
                    $this->remove($conn->id);
                    break;
                }
            }
        }
    }
}

Laravel Reverb: First-Party WebSocket Server

Laravel Reverb is a first-party WebSocket server introduced in Laravel 11, designed to provide real-time communication with minimal configuration. Unlike Ratchet, which requires manual event loop management, Reverb integrates seamlessly with Laravel's broadcasting system and uses Laravel Echo on the frontend. It supports scaling via Redis and can handle thousands of concurrent connections without memory leaks. To use Reverb, install it via Composer: composer require laravel/reverb. Then publish the config and start the server: php artisan reverb:start. Reverb automatically handles connection upgrades, room broadcasting, and event loop management, making it ideal for Laravel applications. Below is a basic example of broadcasting an event to a room using Reverb and Laravel Echo.

use App\Events\MessageSent;
use Illuminate\Support\Facades\Broadcast;

Broadcast::channel('chat.{roomId}', function ($user, $roomId) {
    return $user->id; // Authorize user
});

// In a controller:
event(new MessageSent('Hello, world!', $roomId));

FrankenPHP Server Push and Server-Sent Events

FrankenPHP is a modern PHP application server that supports Server Push and Server-Sent Events (SSE) natively, offering an alternative to WebSockets for real-time updates. Unlike WebSockets, SSE is unidirectional (server to client) and works over standard HTTP, making it simpler to implement and more firewall-friendly. FrankenPHP uses a Go-based worker to handle concurrent requests efficiently. To use SSE, create a PHP script that streams events using header('Content-Type: text/event-stream') and `echo "data: ...

";`. FrankenPHP automatically handles connection persistence and can push updates without blocking. Below is an example of an SSE endpoint that sends a timestamp every second.

<?php
header('Content-Type: text/event-stream');
header('Cache-Control: no-cache');
header('X-Accel-Buffering: no');

while (true) {
    echo "data: " . json_encode(['time' => time()]) . "\n\n";
    ob_flush();
    flush();
    sleep(1);
}

Ratchet vs ReactPHP vs Reverb

Choosing the right WebSocket library depends on your project's needs. Ratchet is a mature PHP WebSocket library that provides a simple API for building real-time applications. It runs on top of ReactPHP's event loop but requires manual memory management to avoid zombie connections. ReactPHP is a low-level event-driven framework that can be used to build custom WebSocket servers, offering maximum flexibility but requiring more boilerplate. Laravel Reverb is a high-level, opinionated solution for Laravel apps, abstracting away the event loop and providing seamless integration with Laravel's broadcasting system. Below is a comparison of key features: Ratchet is best for standalone PHP WebSocket apps, ReactPHP for custom event-driven architectures, and Reverb for Laravel ecosystems. Memory management is critical in Ratchet and ReactPHP; Reverb handles it automatically.

use Ratchet\Server\IoServer;
use Ratchet\Http\HttpServer;
use Ratchet\WebSocket\WsServer;
use MyApp\Chat;

$server = IoServer::factory(
    new HttpServer(
        new WsServer(
            new Chat()
        )
    ),
    8080
);
$server->run();