Yes, the nonce will be used with a counter appended in order to generate the CTR mode keystream.

It will also be used as an input to GHASH: which is a polynomial MAC used to authenticate the data.

The nonce itself does not have to be random, it can be a counter. But it absolutely must be unique for each message encrypted with the same key. Using GCM on two different messages with the same key and nonce basically allows an attacker to decrypt both messages and forge further messages. (There are some limitations, but they aren't significant enough for it not to be devastating to the cryptosystem.)

So you can either have each side keep track of a counter as the nonce, or you can send it in the clear before each message; so long as it's unique.

For an example in a real-world protocol, see the GCM spec for TLS 1.2: https://tools.ietf.org/html/rfc5288#section-3. It concatenates a value from the handshake and a counter to form the nonce.

Yes, the nonce will be used with a counter appended in order to generate the CTR mode keystream.

It will also be used as an input to GHASH: which is a polynomial MAC used to authenticate the data.

The nonce itself does not have to be random, it can be a counter. But it absolutely must be unique for each message encrypted with the same key. Using GCM on two different messages with the same key and nonce basically allows an attacker to decrypt both messages and forge further messages. (There are some limitations, but they aren't significant enough for it not to be devastating to the cryptosystem.)

So you can either have each side keep track of a counter as the nonce, or you can send it in the clear before each message; so long as it's unique.

For an example in a real-world protocol, see the GCM spec for TLS 1.2: https://www.rfc-editor.org/rfc/rfc5288#section-3. It concatenates a value from the handshake and a counter to form the nonce.