Applications Can Access Transportation Services
Let us now look at the transport services that are available to network applications. We weren’t completely honest when we said we didn’t need to know about the Transport Layer. You must know and understand what transport services are available to network applications.
The Transport Layer resides between the Application Layer and the Network Layer. In layered network architecture the Transport Layer is a central piece. It is the Transport Layer that provides communication services directly to the application processes running on different devices. In this tutorial our primary concern is the relationship between the Transport Layer and the Application Layer.
Recall that a Socket is the interface between the application process and the transport-layer protocol. Messages are sent through the Socket by the process on the sending side. The Transport Layer protocol is in charge of getting messages to the receiving process’s Socket on the other side of the socket.
A Transport Layer protocol allows application processes running on different hosts to communicate logically. By logical communication, we mean that from the perspective of an application, the hosts running the processes appear to be directly connected. In reality, the hosts may be on opposite sides of the world, connected via numerous routers and a variety of link types. Application processes send messages to each other using the logical communication provided by the Transport Layer, free of concern about the physical infrastructure used to carry these messages.
Keep in mind that end systems implement Transport Layer protocols, not the network routers. The Transport Layer on the sending side converts Application Layer messages received from a sending application process into Transport Layer packets, known as transport-layer segments in Internet terminology.
The Transport Layer segment is created by (possibly) breaking the application messages into smaller chunks and adding a Transport Layer header to each chunk. The segment is then passed from the Transport Layer to the Network Layer at the sending end system, where it is encapsulated within a Network Layer packet (a datagram) and sent to the destination.
It is important to note that network routers only act on the datagram’s Network Layer fields; they do not examine the fields of the Transport Layer segment encapsulated with the datagram. The Network Layer extracts the Transport Layer segment from the datagram and passes it up to the Transport Layer on the receiving side. The received segment is then processed by the Transport Layer, making the data in the segment available to the receiving application.
Many networks, including the Internet, support multiple Transport Layer protocols. When creating an application, you must select one of the Transport Layer protocols available. What factors may influence your decision? How would you select the Transport Layer Protocol for your network application?
First, you would investigate the services provided by the available Transport Layer protocols before selecting the protocol with the services that best meet the needs of your application. The situation is analogous to deciding between taking the train or flying between two cities. You must choose one or the other, and each mode of transportation provides different services. (For example, the train provides downtown pickup and drop-off, whereas the plane travels faster).
What services can a Transport Layer protocol provide to applications that use it? The possible services can be broadly classified along four dimensions: reliable data transfer, throughput, timing, and security.
You may go ahead and buy a Networking reference book, or search with your favorite search engine to learn how a computer network implements these four dimensions to provide network services in general. Our main concern in this series is the transport services provided by the Internet.
In an Internet context, we refer to the Transport Layer packet as a segment to simplify terminology. However, we should note that in Internet literature (for example, RFCs), the Transport Layer packet for TCP is also referred to as a segment, whereas the packet for UDP is frequently referred to as a datagram. However, the same Internet literature refers to Network Layer packets as datagrams! In this course, to avoid confusion we refer to both TCP and UDP packets as segments and reserve the term datagram for the Network Layer packet.
The Internet (and, more broadly, TCP/IP networks) provide two transport protocols to applications: UDP and TCP. One of the first decisions you have to make as an application developer, when developing a new network application for the Internet, is whether to use UDP or TCP. Each of these protocols provides a unique set of services to the applications that invoke it. When creating sockets, the application developer selects between UDP and TCP.
Before exploring Transport Layer Protocol, let us briefly discuss the Network Layer. We learnt about the Network Layer in the Networking Fundamentals. The network Layer protocol for the Internet is known as Internet Protocol or IP. Logical communication between end devices is provided by IP. The IP service model is a “best-effort” delivery service. What it means is that IP tries its best to deliver segments(Transport Layer packets) between hosts. Despite its best effort it is not guaranteed by IP that the packets will be delivered from one host to another.
To be more exact, IP does not guarantee the followings:
- The segments will be delivered from one host to another
- If the segments are delivered they will arrive in the same order in the receiving host as they were sent from the sending host.
- The integrity of the data segments will be maintained.
That’s why IP is considered as an unreliable service.
That’s enough Networking Layer for now. You have to remember just one other thing. Every end device has at least one Network Layer Address, known as a IP Address. We have discussed IP Address in great detail in a earlier tutorial.
Transport Layer services extend IP’s delivery services between two end devices to provide a delivery service between two processes running on the end devices. This is another benefit of using layered network architecture. We can implement services that a layer may provide extending the services provided by another layer. Extending Host-to-Host delivery to process to process delivery is known as Transport Layer Multiplexing and Demultiplexing. We will be discussing the role of Transport Layer multiplexing and demultiplexing and how we implement it in the host in the next tutorial. In this tutorial let us focus our attention at Transport Service provided by the Internet.
TCP service model offers two main services – a connection-oriented service and a reliable data transfer service. When you choose TCP as your application’s transport protocol, TCP provides both of these services to the application. We want to inform you beforehand that we will not go into details about how these services are implemented. We will only give you an overview of services offered by the TCP so that you can make an informed decision while selecting a Transport Layer Protocol. The same thing goes for the UDP.
Connection-Oriented Service: In connection oriented service a dedicated connection has to be established between two devices before any data can be exchange. To establish a connection between two hosts, a connection-oriented service typically follows a three-step process.
When you get to Web Programming, we will show you how we can achieve these using Java. For now that’s all that you have to know as a network application developer to create a killer network application.
Reliable Data Transfer Service: TCP guarantees that when a process sends data, the same data will be received by the receiving process. The data will arrive in the correct order as it was sent from the sending process and without any error. TCP is a stream-oriented protocol. One side of the application(the sending process) sends a stream of bytes to a Socket. TCP can be relied on that the same stream of bytes will be reached to the receiving Socket without any missing or duplicate bytes.
Let us give you some insight about why reliable data transfer is important. Assume you’ve created a file-sharing application. It has become a huge hit. But the application has one big issue. You have chosen UDP as the underlying Transport protocol to provide transport services to your application. UDP does not guarantee any reliable data transfer service. But you are not concerned! It works perfectly.
This all changes one fateful day. Your class arranged a drama last year. Your best friend Rachel landed the lead role. She calls you one day.
But after a few minutes she calls you again. “Sorry to bother you”, she says, “But the file you sent me isn’t opening on my PC. I think some of the data packets are lost or corrupted during the transfer. Can you send me the script again, please?”. So you send her the script again. This happened because you did not choose a Transport Protocol that provides reliable data transfer.
TCP also includes a congestion-control mechanism, which serves the overall benefit of the Internet rather than the direct benefit of the communicating processes. When the network between sender and receiver is congested, the TCP congestion-control mechanism throttles a sending process (client or server). TCP congestion control attempts to limit each TCP connection to its fair share of network bandwidth as well.
UDP stands for User Datagram Protocol. It is a type of computer networking protocol that allows computer programs to send messages, also known as datagrams, to other programs with a minimum of protocol overhead. Unlike TCP (Transmission Control Protocol), which establishes a reliable connection before sending data, UDP simply sends packets of data, called datagrams, to the recipient. This makes it faster but less reliable than TCP.
Because UDP lacks a congestion-control mechanism, the sending side of UDP can send data at any rate it wants into the layer below (the network layer). However, due to the limited transmission capacity of intervening links or congestion, the actual end-to-end throughput may be less than this rate
That’s all there is to Transport Protocols. You don’t need to know the low-level details of how TCP and UDP are implemented as the Transfer Protocol, as a network application developer. All you need to know is what services these protocols provide and how you can use them in your application to transfer data over a network. TCP is reliable, but it comes at the expense of slowness. UDP is less reliable, but it is faster. As a network application developer, it is critical to understand the trade-offs between reliability and speed. Based on this trade-off, you will use the appropriate protocol in your specific scenario. These protocols are generally implemented by the OS or the network library. As a consequence, you are not required to know all the low-level networking details.
And you also have to have some idea of the Transport Services not provided by the Internet Transport Protocols.
Services Internet Transport Protocols Do Not Provide
We’ve divided transport protocol services into four categories: reliable data transfer, throughput, timing, and security. TCP and UDP provide which of these services? As previously stated, TCP provides reliable end-to-end data transfer. TCP can be easily enhanced at the application layer to provide security services using SSL.
However, there was no mention of throughput or timing guarantees in our brief description of TCP and UDP—services that today’s Internet transport protocols do not provide. Is this to say that time-sensitive applications like Internet telephony cannot run on today’s Internet? The answer is unequivocally no—the Internet has long hosted time-sensitive applications.
These applications frequently work fairly well because they were designed to deal with this lack of guarantee to the greatest extent possible. However, when the delay is excessive or the end-to-end throughput is limited, clever design has its limitations. To summarize, today’s Internet can frequently provide satisfactory service to time-sensitive applications, but it cannot guarantee timing or throughput.
|Application||Application-Layer Protocol||Underlying Transport Protocol|
|Electronic Mail||SMTP [RFC 5321]||TCP|
|Web||HTTP [RFC 2616]||TCP|
|File Transfer||FTP [RFC 959]||TCP|
|Internet Telephony||SIP [RFC 3261], RTP [RFC 3550], or proprietary UDP or TCP(e.g., Skype)||UDP or TCP|
|Streaming multimedia||HTTP (e.g., YouTube)||UDP|
|Remote Terminal Access||Telnet [RFC 854]||TCP|
The diagram above depicts the transport protocols used by some popular Internet applications. TCP is used in e-mail, remote terminal access, the Web, and file transfer. TCP was chosen by these applications primarily because it provides reliable data transfer, ensuring that all data reaches its destination.
Because Internet telephony applications (such as Skype) can often tolerate some loss but require a low rate to function properly, developers of Internet telephony applications typically prefer to run their applications over UDP, avoiding TCP’s congestion control mechanism and packet overheads. However, because many firewalls are set up to block (most types of) UDP traffic, Internet telephony applications are frequently designed to use TCP as a backup in the event that UDP communication fails.
That’s all you need to know about TCP and UDP to make a killer network application.
Application Layer Protocols
Protocols are the backbone of networking, as we learned in our Fundamentals of Networking course. There are numerous protocols that dictate how each layer of the OSI model or TCP/IP model should work. So you can see that there are protocols in the Application Layer as well.
We’ve just learned that network processes communicate by sending messages into sockets. But, how are these messages structured? What do the different fields in the messages mean? When the processes send these messages? These inquiries lead us to the topic of application-layer protocols.
An application-layer protocol specifies how processes running on different end systems communicate with one another. An application-layer protocol, in particular, defines:
- Message types exchanged, such as request messages and response messages
- The syntax of the various message types, such as the message’s fields and how they are delineated
Some examples of common application layer protocols include:
- HTTP (Hypertext Transfer Protocol): used for transmitting data over the World Wide Web
- HTTPS (HTTP Secure): an extension of HTTP that provides secure communication by encrypting the data being transmitted
- FTP (File Transfer Protocol): used for transferring files over a network
- SMTP (Simple Mail Transfer Protocol): used for sending and receiving email
- DNS (Domain Name System): used for resolving domain names to IP addresses
- SSH (Secure Shell): a secure network protocol used to remotely access and manage network devices
These protocols define the format of the data being exchanged, the way that data is requested, and the way that data is returned. They provide the means for applications to communicate with one another, regardless of the underlying network and transport protocols being used.
It’s critical to understand the difference between network applications and application-layer protocols. An application-layer protocol is only one component of a network application (albeit a critical component in our opinion!).
Consider the following example. The Web is a client-server application that allows users to request documents from Web servers. The Web application is made up of several components, including a document format standard (HTML), Web browsers (such as Firefox and Microsoft Internet Explorer), Web servers (such as Apache and Microsoft servers), and an application-layer protocol.
HTTP, the Web’s Application Layer Protocol, specifies the format and sequence of messages sent between a browser and a Web server. As a consequence, HTTP is only one component (albeit an important component) of the Web application.
The following tutorial will go over Web applications. We begin with the Web, not only because it is a hugely popular application, but also because its Application Layer protocol, HTTP, is simple and easy to grasp.