How the Client Connects

Streaming API uses the HTTP/1.1 request-response model and the Bayeux protocol (CometD implementation). A Bayeux client connects to Streaming API in multiple stages.

Sends a handshake request.
Sends a subscription request to a channel.
Connects using long polling.

The maximum size of the HTTP request post body that the server can accept from the client is 32,768 bytes, for example, when you call the CometD subscribe or connect methods. If the request message exceeds this size, the following error is returned in the response: 413 Maximum Request Size Exceeded. To keep requests within the size limit, avoid sending multiple messages in a single request.

The client receives events from the server while it maintains a long-lived connection.

If the client receives events, it should reconnect immediately to receive the next set of events. If the reconnection doesn't occur within 40 seconds, the server expires the subscription and the connection closes. The client must start over with a handshake and subscribe again.
If no events are generated and the client is waiting and the server closes the connection, after two minutes the client should reconnect immediately.

If a long-lived connection is lost due to unexpected network disruption, CometD will automatically attempt to reconnect. If this reconnection is successful, clients must re-subscribe, since this new connection has gone through a re-handshake that removes previous subscribers. Clients can listen to the meta/handshake meta channel to receive notifications when a connection is lost and re-established.

For details about these steps, see Bayeux Protocol, CometD, and Long Polling.

Force.com Streaming API Developer Guide

How the Client Connects