Data Encapsulation
Here are a few screenshots, showing how data is encapsulated. This is a supporting page for the article on data transmission across the Internet, which is available here. This page shows an actual example of encapsulation, showing how data is packaged for transmission across the Internet.
The software used was Wireshark, a free packet sniffer available for download here.
The picture above shows the basic Wireshark screen after a capture. It has 3 main sections. The top sections shows actual packets captured, one per line. These include both packets sent and packets received. The middle section shows details of whatever packet is highlighted in the top section. The lowest section shows the actual data contained in whatever part of a packet is highlighted in the middle section.
We'll use a couple of the packets from the list shown above to examine in more detail. The packets we'll used are marked by red arrows in the picture above. They represent a standard query and response for a DNS request. This is a very common type of activity on the Internet. When you type in a logical address in your web browser bar, for example, the addresses needs to be translated to a real IP address before the page can be fetched.
In this example, I typed in the web site "tools.ietf.org" (IETF is the Internet Engineering Task Force). This is a logical address, and needs to be converted to an IP address before the page can be contacted. In order to get the IP address, the web browser sends a DNS (Domain Name Service) request to a DNS server. DNS servers are machines that contain databases of IP addresses.
Here is the format of the request sent to the DNS server.
The picture above shows the query sent by my computer to the DNS server. Note how Wireshark breaks apart the packet to show the nested frames. In this case, the line:
[Protocols in frame: eth:ip:udp:dns]
shows the nesting. The DNS query (Application Layer, generated by the web browser), is encoded into a UDP packet (Transport Layer), which is in turn encoded into an IP packet (Network Layer), which is finally encoded into an Ethernet frame (Link Layer). Each of the layers is then shown separately.
The frame itself contains timing information, which is important for resolving conflicts when sorting packets. Usually, packets contain information which indicate the order in which they should be re-assembled. However, if this information is ambiguous, the timing information can be used to resolve conflicts.
The layers have been expanded in the above screenshot (except the ethernet layer, for lack of space) to show the different fields in their headers. Note that each layer's header contains information pertinent to that header. So for example, the transport layer (UDP) header contains port information, while the network layer (IP) header contains IP addresses.
Here is the response from the DNS server to the above request.
As seen in the screenshot above, the DNS server returned a response in the same format, that is ethernet » IP » UDP » DNS. This is expected, since the return pathway is the same, and DNS information is routinely carried in UDP packets from your local DNS server. Most Internet Service Providers, like cable companies or phone companies provide you with a list of DNS servers you can use. Since these servers are owned and maintained by your service provider, and are on their own network, they have chosen to package the DNS information in a UDP packet. You may recall from the article that UDP has offers no delivery guarantee, but is a data-dense protocol. Since the whole network up to this point, including the DNS server and your own cable or DSL modem belong to the same company, they can control congestion and reliability on this part of the network, and can be sure that UDP is a suitable protocol to send such messages. If you used an open DNS server that did not belong to your cable or phone company, it might well choose to package the DNS data in a TCP packet instead of a UDP packet. Recall that TCP tries to guarantee delivery, and will resend information if it think the packet may have been lost. DNS itself is agnostic to the packaging, and doesn't care if the information is sent via UDP or TCP.
Also note that in this case, the DNS query resulted in 3 different IP addresses. This shows that it's very likely that none of them is the IP address of the web server that actually contains the web page which the browser needed. Instead, these addresses are probably those of name servers, separate machines owned by ietf.org, and the actual web server lies somewhere behind these machines. This is quite common on the Internet, where a certain domain may not expose the machines inside it to the Internet. Your request for the web page therefore goes to the IETF name server, which then forwards it to the appropriate machine inside their network.
Return to the article on Data Transmission across the Internet, or return to the section on Data Encapsulation.