NAT (Network Address Translation) Router, How does it work?

NAT (Network Address Translation) is a process by which private network devices can reach out to the devices on the Internet and receive responses. In a normal or usual scenario every household has a public address and this address is used by multiple devices internally (private devices). Without NAT, there would have been only one internal or private device accessing the Internet. Also NAT is required as it works as a gate way between the private network (for example network 192.169.x.x) and the public network (for example 203.246.x.x). By default and in real world the private devices are not accessible to the public network directly. They have to be accessed through the NAT router.

The process of making a private device available or able to access the internet is as follows:

1.      Local machine attempts to access www.google.com (74.125.229.34)

2.      NAT router creates a new entry in the lookup table associated with the local machine’s private network address and the internal source port.

3.      NAT router rewrites the machine’s IP address to that of the NAT’s public IP and open up a new source port and rewrites the original port number with the new one.

4.      The new combination of public IP and new source port number are recorded alongside the private source IP and original port number in the lookup table.

5.      The NAT router also adjusts the checksums so that it would reflect the changes that were made.

6.      The packet is forwarded to www.google.com (74.125.229.34)

When the response is received, the NAT router checks its lookup table for any entries whose public source port corresponds to the destination port of the inbound packet and whose destination IP corresponds to the source IP of the inbound packet. Once this is determined, the NAT router rewrites the IP header of the inbound packet according to the lookup table and forwards it to the correct private machine.

This process continues and runs successfully in the same manner, no matter how many devices are in the private network. 

Why should audio and video streams should typically transmitted over UDP instead of TCP?

To better answer this question we need to understand the working of TCP and UDP individually. TCP (Transmission Control Protocol) is a communication protocol on the internet, which routes packets between machines in a best effort fashion. It creates a protocol that guarantees or assures the sender that the packets or in broader view a message will be received by the specified receiver. TCP does this by a process called as TCP sessions. It has three basic components, namely,

1.      Initial SYN request (Handshake)

2.      Reception of SYN-ACK request

3.      Acknowledgement response

This process is also accompanied by sequence numbers that ensure that the packets are received in order and also used to check for completeness of messages.

On the other hand, UDP (User Datagram Protocol) does not have a lot of features as the TCP has. UDP does not make a guarantee that the packets or messages will be received in order and also does not check for correctness or completeness. It also does not have initial handshake as TCP has.

As we can infer from the above descriptions, TCP takes longer time than UDP does. Also in TCP if we are transmitting voice or audio and due to some issue a packet is lost. The receiver would stop accepting any more packets until the missing packets is received which will add latency to the communication and hence will disturb a real time communication. Whereas for the UDP based audio or video communication, even if a packet is lost, we humans are able to fill in the void by pattern recognition or by anticipating the voice and hence communication can occur. Even though there maybe packet loss in UDP communication, it is a more efficient and effective protocol for time-sensitive applications such as voice and audio.