Nonce has a specialized usage within network protocols, specifically cryptographic ones. It has the same meaning as in normal usage, something which is used one time, or a 'single occasion' as Webster puts it. It has also been backronymed to "Number used ONCE"; for a long time I actually thought this was actually the origin of the word. The word is probably more commonly known, and most certainly more commonly used, among computer scientists and cryptographers than among the general populace.
The general incarnation of a nonce is a random bit string, usually between 32 and 256 bits. The only real requirement is that, with high probability, the nonce will never repeat. It is often preferable that the nonce is also unpredictable, but this only matters in some contexts. For this reason, in some cases a simple counter can make a perfectly good nonce. However, this requires keeping long-term state (so if your server restarts or crashes, you don't repeat nonces), which is why most nonces are generated using a cryptographically secure random number generator instead. Due to the birthday paradox, if you expect to generate about 2N random nonces over the lifetime of the system, you'll want to make sure the nonce is at least 2*N bits long.
The general idea of a nonce is to tie a specific set of interactions to a specific time. Synchronization is typically quite difficult in computer systems, especially if clocks are not set correctly (not everyone uses NTP), and nonces are a good way to get around this. A classic protocol using a nonce is a challenge response authentication system. This protocol has two parties; one party wishes to prove its identity to the other on the basis of a shared secret. For simplicity, we'll call the party who wishes to prove its identity the client, and the other party (which verifies the identity) the server. I'll use the classical protocol notation to describe this, but with additional text to make it clear what's going on.
- C->S: C
The client sends its name (which might be a login name, an IP, or whatever). It's just a unique identifier.
- S->C: N
The server sends a nonce, which may or may not be random.
- C->S: C, N, H(C||N||secret)
The client responds with its name, the nonce sent in the last message, and a hash of its name, the nonce, and the secret string. In theory the client wouldn't need to send its name or the nonce again, but it makes things very simple for reasons I'll explain later on. The server computes the hash again, based on what it thinks the secret is, and compares to the two. If they match, then at that means C is authenticated. Keep in mind that this does not mean that the entity claiming to be C necessarily is; it just means that this entity both claims to be C, and knows a secret which (supposedly) only C and the server know.
By hashing the name as well as the nonce and the secret, we can even get away with repeating nonces, as long as we never repeat a nonce for any particular user. This would be a poor thing to rely on, but it does give an extra margin of safety.
Now, why would you want to send the name and the nonce again? The nice thing about doing this is that the server can potentially be made stateless. If the client did not reflect the name and the nonce back at the server again, the server would have to keep track of which nonces were handed out to which clients. This could allow for trivial denial of service attacks, for example, by connecting millions of times, sending random client names, and then just leaving the connection open. The server would have to keep track of all of them, and while it could get around part of the problem by deleting half-open sessions after a few seconds, the state management is somewhat nontrivial. In contrast, with this method the server could derive the nonce from the client's name and a secret known only to the server. Then, later on, it could see the nonce again and verify that it was one that it had, in fact, recently created. In essence, the server uses the network and the RAM of clients that connect to it to keep state for it. A related technique is used in SYN cookies. There are actually some intricacies which make this protocol, as presented, insecure, but it seemed preferable to keep the protocol simple and easy to understand for educational purposes.
Now, for the real question is, why use a nonce at all? In this case, observe that if the nonce wasn't used, the client would probably just send a hash of its name and the secret. But in that case, someone else could sniff this exchange off the wire and replay it against the server. Adding a nonce which was generated by the server ensures that, as long as the server never hands out the same nonce twice, nobody can perform such a replay attack.
Nonces are also sometimes termed salt, session randomness, or related names. They are related to initialization vectors, but have a slightly different meaning. Nonces are used pervasively in authentication and cryptographic systems, including VNC, SSL, SSH, and Kerberos v5, and are a fundamental cryptographic technique.
Given the other meaning of the word, described in wertperch's writeup below, one should probably be careful when having discussions of cryptography in public in the UK.