Port 564 is where Plan 9's vision of distributed computing lives. Every file server, every remote resource, every network service speaking through this port follows one simple idea: everything is a file, even when it's on another machine.
What Runs on Port 564
The 9P protocol (also called the Plan 9 Filesystem Protocol or Styx) runs on port 564 for both TCP and UDP. It's the network protocol that connects all the pieces of a Plan 9 system—and increasingly, other systems that adopted its elegant simplicity.1
In a standard Plan 9 setup, file servers listen on port 564. When you connect to port 564, you're speaking 9P—a conversation where clients send T-messages (requests) and servers respond with R-messages (replies).2
The Bell Labs Vision
Plan 9 came from the same Bell Labs Computing Science Research Center that created Unix. Ken Thompson, Rob Pike, Dave Presotto, and Phil Winterbottom designed it in the mid-1980s, building on Unix concepts but pushing further: what if distribution was fundamental, not bolted on?3
Unix said "everything is a file." Plan 9 said "everything is a file, everywhere." Your CPU might live on one machine, your display on another, your filesystem on a third. The 9P protocol makes them all look local. You don't make RPC calls or REST requests—you just read and write files.4
The first edition shipped in 1992. By the third edition, they'd refined the protocol into 9P2000, removing length restrictions, adding metadata, batching operations, and moving authentication details out of the core protocol.5
How It Works
9P is beautifully simple: 14 message types, all following the same pattern. A client wants something, it sends a T-message. The server responds with an R-message. That's it.
Want to read a file? Send a Tread message. Want to create something? Send a Tcreate. Want to walk through a directory hierarchy? Send a Twalk, and the server batches the entire walk into one response.
Every resource that wants to be accessible speaks this same protocol. No custom APIs per service. No negotiating formats. Everything that can be represented as files uses the same 9P conversation.6
The protocol is medium-agnostic and byte-oriented. It doesn't care if you're on a local network or across the Internet. The messages are simple enough that implementations stay small and debuggable.
Where It Lives Today
Plan 9 never conquered the server room, but its ideas escaped anyway.
Linux adopted 9P through the v9fs filesystem. You can mount a 9P filesystem in Linux and access remote resources as if they were local.7 Windows Subsystem for Linux uses 9P—Windows acts as the client, WSL as the server, all through port 564.8
QEMU and other virtualization systems use 9P for sharing filesystems between host and guest. The protocol's simplicity makes it perfect for that boundary.9
Security Considerations
Standard 9P on port 564 is not encrypted by default.10 The protocol itself doesn't mandate encryption—that's left to the transport layer or external mechanisms.
If you're running 9P across untrusted networks, wrap it in something that provides encryption. SSH tunneling is common. TLS wrapping works. But naked 9P on port 564 sends everything in the clear.
Plan 9 introduced authentication files as a mechanism for handling auth outside the protocol proper, but encryption still requires additional layers.
Related Ports
- Port 17010: Often used for 9P in alternative configurations
- Port 17019: 9P over TLS in some implementations
Why Port 564 Matters
Port 564 carries an idea that keeps refusing to die: distributed systems work better when they look simple. Instead of inventing new protocols for every service, just mount it as a filesystem and use the tools you already know.
The Internet went a different direction—REST APIs, microservices, RPC frameworks stacked on RPC frameworks. But every few years, someone rediscovers 9P and thinks: wait, what if we just made everything a file again?
Bell Labs asked that question in the 1980s. Port 564 is still carrying the answer.
Frequently Asked Questions
Cette page vous a-t-elle été utile ?