NATS

NATS uses a plain-text protocol over TCP. Each message is a verb, optional arguments, and a CRLF; payloads follow their header line and are themselves CRLF-terminated.

Protocol Operations

Operation	Sent By	Format	Purpose
INFO	Server	INFO {json}\r\n	Server details, sent on connect
CONNECT	Client	CONNECT {json}\r\n	Client options and credentials
PUB	Client	PUB <subject> [reply-to] <size>\r\n<payload>\r\n	Publish a message
HPUB	Client	HPUB <subject> [reply-to] <hdr-size> <total-size>\r\n<headers>\r\n<payload>\r\n	Publish with headers
SUB	Client	SUB <subject> [queue-group] <sid>\r\n	Subscribe to a subject
UNSUB	Client	UNSUB <sid> [max-msgs]\r\n	Unsubscribe, optionally after a count
MSG	Server	MSG <subject> <sid> [reply-to] <size>\r\n<payload>\r\n	Deliver a message
HMSG	Server	HMSG <subject> <sid> [reply-to] <hdr-size> <total-size>\r\n<headers>\r\n<payload>\r\n	Deliver with headers
PING	Both	PING\r\n	Keepalive request
PONG	Both	PONG\r\n	Keepalive response
+OK	Server	+OK\r\n	Acknowledgment, when verbose is set
-ERR	Server	-ERR <reason>\r\n	Protocol error. The server closes the connection after most of these

Subjects and Wildcards

Subjects are dot-separated tokens. Two wildcards are available when subscribing:

Wildcard	Matches	Example
*	Exactly one token	logs.*.error matches logs.auth.error
>	One or more tokens, and only as the final token	logs.> matches logs.auth and logs.auth.error

The optional queue-group argument on SUB places subscribers into a group, and the server delivers each message to only one member—this is how load is distributed across consumers.

The CONNECT Message

Credentials travel in the JSON payload of CONNECT, which is why the wire carries no distinct authentication verb.

Field	Description
user, pass	Username and password
auth_token	Token authentication
jwt	User JWT for account-scoped authentication
sig	Signature over the server's nonce, for NKey and JWT authentication
nkey	The NKey public key
name	Client name
headers	Whether the client understands HPUB and HMSG
verbose	Whether the server should send +OK

JetStream

JetStream is the persistence layer, and it is not a separate protocol. Its operations are ordinary request-reply exchanges over core NATS: a client publishes a JSON request to a subject under $JS.API.> and receives a JSON reply on an inbox subject. Message acknowledgment likewise publishes to the reply subject carried on the delivery.

This matters when reading the operations table above: a JetStream consumer still uses PUB, SUB and MSG on the wire.