ISP Services
Once the connection is made to the ISP, the business or customer must decide which services they would need from the ISP.
ISPs serve several markets. Individuals in homes make up the consumer market. Large, multi-national companies make up the Enterprise market. In between are smaller markets, such as small to medium-sized businesses, or larger non-profit organizations. Each of these customers have different service requirements.
Escalating customer expectations and increasingly competitive markets are forcing service providers to offer new services. These services enable the ISPs to increase revenue and to differentiate themselves from their competitors.
Email, web hosting, media streaming, IP telephony, and file transfer are key services that ISPs can provide to all customers. These services are important for the ISP consumer market and for the small to medium-sized business that does not have the expertise to maintain their own services.
Many organizations, both large and small, find it expensive to keep up with new technologies, or they simply prefer to devote resources to other parts of the business. ISPs offer managed services that enable these organizations to have access to the leading network technologies and applications without having to make large investments in equipment and support.
When a company subscribes to a managed service, the service provider manages the network equipment and applications according to the terms of a service level agreement (SLA). Some managed services are also hosted, meaning that the service provider hosts the applications in its facility instead of at the customer site.
The following are three scenarios that describe different ISP customer relationships:
Scenario 1: The customer owns and manages all of their own network equipment and services. These customers only need reliable Internet connectivity from the ISP.
Scenario 2: The ISP provides Internet connectivity to the customer, but in this scenario, the ISP also owns and manages the network equipment installed at the customer site. Service provider responsibilities include setting up, maintaining, and administering the equipment for the customer. The customer is responsible for monitoring the status of the network and the applications, and receives regular reports on the performance of the network.
Scenario 3: The customer owns the network equipment, but the applications that the business relies on are hosted by the ISP. In this scenario, the actual servers that run the applications are located at the ISP facility. These servers may be owned by the customer or the ISP, although the ISP maintains both the servers and the applications. Servers are normally kept in server farms in the ISP network operations center (NOC), and will be connected to the ISPs network with a high-speed switch.
Reliability And Availability
Creating new services can be challenging. Not only must ISPs have a strong understanding of what their end customers want, but they must have the ability and the resources to provide them. As business and Internet applications become more complex, an increasing number of ISP customers rely on the services provided or managed by the ISP.
ISPs provide services to customers for a fee and guarantee a level of service in the SLA. To meet this expectation, ISPs service offerings have to be reliable and available.
Reliability
Reliability can be thought of in terms of two measures: mean time between failure (MTBF) and mean time to repair (MTTR). Equipment manufacturers specify MTBF from tests they perform as part of manufacturing. The measure of equipment robustness is fault tolerance, the longer the MTBF, the greater the fault tolerance. The time to repair is established by warranty or service agreements.
When there is an equipment failure, and the network or service becomes unavailable, it impacts the ability of the ISP to meet the terms of the SLA. To prevent this, an ISP may purchase expensive service agreements for critical hardware to ensure rapid manufacturer or vendor response. An ISP may also choose to purchase redundant hardware and keep spare parts onsite.
Availability
Availability is normally measured in the percentage of time that a resource is accessible. A perfect availability percentage would be 100%, meaning that the system is never down or unreachable. Traditionally, telephone services are expected to be available 99.999% of the time. This is called the five-9’s standard of availability. With this standard, only a very small percentage, .001%, of downtime is acceptable. As ISPs offer more critical business services, such as IP telephony, or high volume retail sale transactions, ISP services must meet the higher expectations of their customers. ISPs ensure accessibility by doubling up on network devices and servers using technologies designed for high availability. In redundant configurations, if one device fails, the other one can take over the functions automatically.
Review Of TCP/IP Protocols
Today, ISP customers are using mobile phones as televisions, PCs as telephones, and televisions as interactive gaming stations with a host of different entertainment options. As network services become more advanced, ISPs must accommodate these customer preferences. The development of converged IP networks enables all of these services to be delivered over a common network.
To provide support for the multiple end-user applications that rely on TCP/IP for delivery, it is important for the ISP support personnel to be familiar with the operation of the TCP/IP protocols.
ISP servers need to be able to support multiple applications for many different customers. In order to do this, they must use functions provided by the two TCP/IP transport protocols, TCP and UDP. Common hosted applications, like web serving and email accounts, also depend on underlying TCP/IP protocols to ensure their reliable delivery. In addition, all of the IP services rely on domain name servers, hosted by the ISPs, to provide the link between the IP addressing structure and the URLs that customers used to access them.
Clients and servers use specific IP protocols and standards in the process of exchanging information. The TCP/IP protocols can be represented using a four-layer model. Many of the key services provided to ISP customers depend on protocols that reside at the Application and Transport Layers of the TCP/IP model.
Application Protocols
Application Layer protocols specify the format and control information necessary for many of the common Internet communication functions. Among these TCP/IP protocols are:
Domain Name Service Protocol (DNS) is used to resolve Internet names to IP addresses.
Hypertext Transfer Protocol (HTTP) is used to transfer files that make up the Web pages of the World Wide Web.
Simple Mail Transfer Protocol (SMTP) is used for the transfer of mail messages and attachments.
Telnet, a terminal emulation protocol, is used to provide remote access to servers and networking devices.
File Transfer Protocol (FTP) is used for interactive file transfer between systems.
Transport Layer Protocols
Different types of data can have unique requirements. For some applications, communication segments must arrive in a very specific sequence in order to be processed successfully. In other cases, all of the data must be received for any of it to be of use. Sometimes, an application can tolerate the loss of a small amount of data during transmission over the network.
In today’s converged networks, applications with very different transport needs may be communicating on the same network. Different Transport Layer protocols have different rules to enable devices to handle these diverse data requirements.
Additionally, the lower layers are not aware that there are multiple applications sending data on the network. Their responsibility is to get the data to the device. It is the job of the Transport Layer to deliver the data to the appropriate application.
The two primary Transport Layer protocols are TCP and UDP.
The TCP/IP model and the OSI model have many similarities and differences.
Similarities
Use of layers to visualize the interaction of protocols and services
Comparable Transport and Network Layers
Used in the networking field when referring to protocol interaction
Differences
OSI model breaks the function of the TCP/IP Application Layer into separate distinct layers. The upper three layers of the OSI model specify the same functionality as the Application Layer of the TCP/IP model.
The TCP/IP protocol suite does not specify protocols for the physical network interconnection. The two lower layers of the OSI model are concerned with access to the physical network and the delivery of bits between hosts on a local network.
TCP/IP model is based on actual protocols and standards developed, whereas the OSI model is a theoretical guide for how protocols interact.
TCP
Different applications have different transport needs. There are two TCP/IP protocols at the transport layer, TCP and UDP.
TCP
TCP is a reliable, guaranteed-delivery protocol. TCP specifies the methods hosts use to acknowledge the receipt of packets, and requires the source host to resend packets that are not acknowledged. TCP protocols also govern the exchange of messages between the source and destination hosts to create a communication session. TCP is often compared to a pipeline, or a persistent connection, between hosts. Because of this, TCP is referred to as a connection-oriented protocol.
TCP requires overhead to keep track of the individual conversations between source and destination hosts and to process acknowledgements and retransmissions. In some cases, the delays caused by this overhead cannot be tolerated by the application. These applications are better suited to UDP.
UDP
UDP is a very simple, connectionless protocol. It has the advantage of providing for low overhead data delivery. Because UDP is a “best effort” Transport Layer protocol, UDP datagrams may arrive at the destination out of order, or may even be lost all together. UDP does not provide guaranteed data delivery or flow control. Applications that use UDP can tolerate small amounts of missing data. An example of a UDP application is Internet radio. If a piece of data is not delivered, there may only be a minor effect on the quality of the broadcast.
Applications, such as databases, web pages, and email, need to have all data arrive at the destination in its original condition, in order for the data to be useful. Any missing data can cause the messages to be corrupt or unreadable. These applications are designed to use a Transport Layer protocol that implements reliability. The additional network overhead required to provide this reliability is considered a reasonable cost for successful communication.
The Transport Layer protocol is determined based on the type of application data being sent. For example, an email message requires acknowledged delivery and therefore would use TCP. An email client, using SMTP, sends an email message as a stream of bytes to the Transport Layer. At the Transport Layer, the TCP functionality divides the stream into segments.
Within each segment TCP identifies each byte, or octet, with a sequence number. These segments are passed to the Internetwork Protocol Layer, which places each segment in a packet for transmission. This process is known as encapsulation. At the destination, the process is reversed and the packets are de-encapsulated. The enclosed segments are sent through the TCP process, which converts the segments back to a stream of bytes to be passed to the email server application.
Before a TCP session can be used, the source and destination hosts exchange messages to set up the connection over which data segments can be sent. To do this, the two hosts use a three step process.
In the first step, the source host sends a type of message called a SYN, to begin the TCP session establishment process. The message serves two purposes:
Indicates the intention of the source host to establish a connection with the destination host over which to send the data.
Synchronizes the TCP sequence numbers between the two hosts, so each host can keep track of the segments sent and received during the conversation.
For the second step, the destination host replies to a SYN message with a synchronization acknowledgement, or SYN-ACK message.
In the last step, the sending host receives the SYN-ACK, and it sends an ACK message back to complete the connection setup. Data segments can now be reliably sent.
This SYN, SYN-ACK, ACK activity between the TCP processes on the two hosts is called a three-way handshake.
When a host sends message segments to a destination host using TCP, the TCP process on the source host starts a timer. The timer allows sufficient time for the message to reach the destination host and for an acknowledgement to be returned. If the source host does not receive an acknowledgement from the destination within the allotted time, the timer expires and the source assumes the message is lost. The portion of the message that was not acknowledged is then re-sent.
In addition to acknowledgement and retransmission, TCP also specifies how messages are reassembled at the destination host. Each TCP segment contains a sequence number. At the destination host, the TCP process stores received segments in a TCP buffer. By evaluating the segment sequence numbers, the TCP process can confirm there are no gaps in the received data. When data is received out of order it can also reorder the segments as necessary.
Differences Between TCP And UDP
UDP is a very simple protocol. Because it is not connection-oriented and does not provide the sophisticated retransmission, sequencing, and flow control mechanisms of TCP, UDP has a much lower overhead.
UDP is often referred to as an unreliable delivery protocol; because there is no guarantee that a message has been received by the destination host. This does not mean that applications that use UDP are unreliable. It simply means that these functions are not provided by the Transport Layer protocol and must be implemented elsewhere if required.
Although the total amount of UDP traffic found on a typical network is often relatively low, key Application Layer protocols that use UDP include:
Domain Name System (DNS)
Simple Network Management Protocol (SNMP)
Dynamic Host Configuration Protocol (DHCP)
Routing Information Protocol (RIP)
Trivial File Transfer Protocol (TFTP)
Online games
Supporting Multiple Service
The task of managing multiple simultaneous communication processes is done by the Transport Layer. The TCP and UDP services keep track of the various applications that are communicating over the network. To differentiate the segments and datagrams for each application, both TCP and UDP have header fields that can uniquely identify these applications for data communications purposes.
In the header of each segment or datagram, there is a source and destination port. Port numbers are assigned in various ways, depending on whether the message is a request or a response. When a client application sends a request to a server application, the destination port contained in the header is the port number that is assigned to the application running on the server. For example, when a web browser application makes a request to a web server, the browser uses TCP and port number 80. This is because TCP port 80 is the default port assigned to web-serving applications. Many common applications have default port assignments. Email servers, using SMTP, are usually assigned to TCP port 25.
As segments are received for a specific port, TCP or UDP places the incoming segments in the appropriate queue. For instance, if the application request is for HTTP, the TCP process running on a web server places incoming segments in the web server queue. These segments are then passed up to the HTTP application as quickly as HTTP can accept them.
Segments with port 25 specified will be placed in a separate queue that is directed toward email services. In this manner, Transport Layer protocols enable servers at the ISP to host many different applications and services simultaneously.
In any Internet transaction, there is a source host and a destination host, normally a client and a server. The TCP processes on the sending and receiving hosts are slightly different. Clients are active and request connections, while servers are passive, and listen for and accept connections.
Server processes are usually statically assigned well-known port numbers from 0 to 1023. Well-known port numbers enable a client application to assign the correct destination port when generating a request for services.
Clients also require port numbers to identify the requesting client application. Source ports are dynamically assigned from the port range 1024 to 65535. This port assignment acts like a return address for the requesting application. The Transport Layer keeps track of the source port and the application that initiated the request, so that when a response is returned, it can be forwarded to the correct application.
The combination of the Transport Layer port number and the host’s Network Layer IP address uniquely identifies a particular application process running on an individual host device. This combination is called a socket. A socket pair, consisting of the source and destination IP addresses and port numbers, is also unique and identifies the specific conversation between the two hosts.
A client socket might look like this, with 7151 representing the source port number:
192.168.1.1:7151
The socket on a web server socket might be:
10.10.10.101:80.
Together these two sockets combine to form a socket pair:
192.168.1.1:7151, 10.10.10.101:80.
With the creation of sockets, communication endpoints are known so that data can move from an application on one host to an application on another. Sockets enable multiple processes running on a client to distinguish themselves from each other, and also multiple connections to a server process to be distinguished from each other.
TCP/IP Host Name
Communication between source and destination hosts over the Internet requires a valid IP address for each host. However, numeric IP addresses, especially the hundreds of thousands of addresses assigned to servers available over the Internet, are difficult for humans to remember. Human-readable domain names, like cisco.com, are easier for people to use. Network naming systems are designed to translate human-readable names into the machine-readable IP addresses that can be used to communicate over the network.
Humans use network naming systems every day when surfing the web or sending email messages, and may not even realize it. Naming systems work as a hidden but integral part of network communication. For example, to browse to the Cisco Systems, Inc. website, open a browser and enter http://www.cisco.com in the address field. The www.cisco.com is a network name that is associated with a specific IP address. Typing the server IP address into the browser brings up the same web page.
Network naming systems are a human convenience to help users reach the resource they need without having to remember the complex IP address.
In the early days of the Internet, host names and IP addresses of computers on the network were managed through the use of a single HOSTS file located on a centrally administered server.
The central HOSTS file contained the mapping of host name and IP address for every device connected to the early Internet. Each site could download the HOSTS file and use it to resolve host names on the network. When a hostname was entered, the sending host would check the downloaded HOSTS file to obtain the IP address of the destination device.
At first, the HOSTS file was acceptable for the limited number of computer systems participating in the Internet. As the network grew, so did the number of hosts needing name-to-IP translations. It became impossible to keep the HOSTS files up-to-date. As a result, a new method to resolve host names to IP addresses was developed. The Domain Name System (DNS) was created for domain name to address resolution. DNS uses a distributed set of servers to resolve the names associated with these numbered addresses. The single, centrally administered HOSTS file is no longer needed.
However, the HOSTS file is still used by virtually all computer systems. A local HOSTS file is created when TCP/IP is loaded on a host device. As part of the name resolution process on a computer system, the HOSTS file is scanned even before the more robust DNS service is queried. A local HOSTS file can be used for troubleshooting or to override records found in a DNS server.
DNS
Domain Name Service (DNS) is a hostname resolution system that solves the shortcomings of the HOSTS file. The structure of DNS is hierarchical, with a distributed database of hostname to IP mappings spread across many DNS servers all over the world. This is unlike the HOSTS files, which required all mappings to be maintained on one server.
DNS uses domain names to form the hierarchy. The naming structure is broken down into small, manageable zones. Each DNS server maintains a specific zone database file and is only responsible for managing name-to-IP mappings for that small portion of the entire DNS structure. When a DNS server receives a requests for a name translation that is not within that DNS zone, the DNS server can forwarded the request to another DNS server within the proper zone for translation.
The ability for resolution of the hosts names to be spread across multiple servers makes the DNS system very scalable.
The domain naming system is made up of three components:
Resource Records and Domain Namespace
A resource record is a data record in the DNS zone database file. It is used to identify a type of host, a host’s IP address, or a parameter of the DNS database. The domain namespace refers to the hierarchical naming structure for organizing resource records. The domain namespace is made up of various domains, or groups, and the resource records within each group.
Domain Name Servers
These servers maintain the databases that store resource records and information about the domain namespace structure. DNS servers attempt to resolve client queries using the domain namespace and resource records it maintains in its zone database files. If the name server does not have the requested information in its DNS zone database, the name server uses additional predefined name servers to help resolve the name-to-IP query.
Resolvers
Resolvers are applications or operating system functions that run on DNS clients and DNS servers. When a domain name is used, the Resolver queries the DNS server to translate that name to an IP address. A resolver is loaded on a DNS client, and is used to create the DNS name query that is sent to a DNS server. Resolvers are also loaded on DNS servers. If the DNS server does not have the name-to-IP mapping requested, it will use the resolver to forward the request to another DNS servers.
The Domain Name System uses a hierarchical system to provide name resolution. The hierarchy looks like an inverted tree with the root at the top and branches below.
At the top of the hierarchy, the root servers maintain records about how to reach the top-level domain servers, which in turn have records that point to the secondary level domain servers.
The different top-level domains represent either the type of organization or the country or origin. Examples of top-level domains are:
.au – Australia
.co – Colombia
.com – a business or industry
.jp – Japan
.org – a non-profit organization
After top-level domains are second-level domain names, and below them are other lower-level domains.
The root DNS server may not know exactly where the host H1.cisco.com is located, but it does have a record for the .com top level domain. Likewise, the servers within the .com domain may not have a record for H1.cisco.com either, but they do have a record for the cisco.com domain. The DNS servers within the cisco.com domain do have the record for H1.cisco.com and can resolve the address.
The Domain Name System relies on this hierarchy of decentralized servers to store and maintain these resource records. The resource records contain domain names that the server can resolve, and alternative servers that can also process requests.
The name H1.cisco.com is referred to as a fully qualified domain name (FQDN) or DNS name, because it defines the exact location of the computer within the hierarchical DNS namespace.
DNS Name Resolution
When a host needs to resolve a DNS name, it uses the resolver to contact a DNS server within its domain. The resolver knows the IP address of the DNS server to contact because it is preconfigured as part of the host’s IP configuration.
When the DNS server receives the request from the client resolver, it first checks the local DNS records it has cached in its memory. If it is unable to resolve the IP address locally, the server uses its resolver to forward the request to another preconfigured DNS server. This process continues until the IP address is resolved. The name resolution information is sent back to the original DNS server, which uses the information to respond to the initial query.
During the process of resolving a DNS name, each DNS server caches, or stores, the information it receives as replies to the queries. The cached information enables the DNS server to reply more quickly to subsequent resolver requests because the server first checks the cache records, before querying other DNS servers.
DNS servers only cache information for a limited amount of time. DNS servers should not cache information for too long since hostname records do periodically change. If a DNS server had old information cached, it may give out the wrong IP address for a computer.
In the early implementations of DNS, resource records for hosts were all added and updated manually. However, as networks grew and the number of host records needing to be managed increased, it became very inefficient to maintain the resource records manually. ‘Furthermore, when DHCP is used, the resource records within the DNS zone have to be updated even more frequently. To make updating the DNS zone information easier, the DNS protocol was changed to allow computer systems to update their own record in the DNS zone through dynamic updates.
Dynamic Updates enable DNS client computers to register and dynamically update their resource records with a DNS server whenever changes occur. In order to use dynamic update, the DNS server and the DNS clients, or DHCP server, must support the dynamic update feature. Dynamic updates on the DNS served are not enabled by default, and must be explicitly enabled. Most current operating systems support the use of dynamic updates.
DNS servers maintain the zone database for a given portion of the overall DNS hierarchy. Resource records are stored within that DNS zone.
DNS zones can be either Forward lookup, or Reverse lookup zones. They can also be either a primary or a secondary forward or reverse lookup zone. Each zone type has a specific role within the overall DNS infrastructure.
Forward Lookup Zones
A forward lookup zone is a standard DNS zone that resolves fully qualified domain names to IP addresses. This is the zone type that is most commonly found when surfing the Internet. When typing a web site address, such as www.cisco.com, a recursive query is sent to the local DNS server to resolve that name to an IP address so as to connect to the remote web server.
Reverse Lookup Zones
A reverse lookup zone is a special zone type that allows you to resolve an IP address to a fully qualified domain name. Some applications use reverse lookups to identify computer systems who are actively communicating with them. There is an entire reverse lookup DNS hierarchy on the Internet that will enable any publicly registered IP address to be resolved. Many private networks choose to implement their own local reverse lookup zones to help identify computer systems within their network. Reverse lookups on IP addresses can be found using the ping -a <ip address> command.
Provisioning DNS Server
There are several ways to implement DNS solutions.
Using ISP DNS servers
ISPs typically maintain caching-only DNS servers. These servers are configured to forward all name resolution requests to the root servers on the Internet. Results are cached and used to reply to any future requests. Since ISPs typically have many customers, the number of cached DNS lookups is high. The large cache reduces network bandwidth by reducing the frequency that DNS queries that are forwarded to the root servers. Caching-only servers do not maintain any authoritative zone information, meaning that they do not store any name-to-IP mappings directly within their database.
Using Local DNS servers
A business may run its own DNS server. The client computers on that network will be configured to point to the local DNS server rather than the ISP DNS server. The local DNS server may maintain some authoritative entries for that zone, so will have name-to-IP mappings of any host within the zone. Requests that the DNS server receives that it cannot resolve will be forwarded. The cache required on a local server is relatively small, compared to the ISP DNS server, due to the smaller number of requests hitting the local DNS server.
It is possible to configure local DNS servers to forward requests directly to the root DNS server. However, some administrators configure local DNS servers to forward all DNS requests to an upstream DNS server, such as the ISP’s DNS server. That way the local DNS server benefits from the large number of cached DNS entries of the ISP, rather than having to go through the entire lookup process starting from the root server.
Losing access to DNS servers affects the visibility of public resources. If a user types in a domain name that cannot be resolved, they cannot access the resource. For this reason, when an organization registers a domain name on the Internet, a minimum of two DNS servers must be provided with the registration. These servers are the ones that will hold the DNS zone database. Redundant DNS servers ensure that if one fails, the other will still be available for name resolution. This practice provides fault tolerance. While two are required, if hardware resources permit, even more DNS servers within a zone can provide additional protection and organization.
It is also a good idea to make sure that multiple DNS servers that host the zone information are located on different physical networks. For example, the primary DNS zone information can be stored on a DNS server on the local business premises. Usually a customer’s ISP hosts an additional secondary DNS server to ensure fault tolerance.
DNS is a critical network service. As such, DNS servers must be protected through the use of firewalls and other security measures. If DNS fails, other web services are not accessible.
Services
In addition to providing private and business customers with connectivity and DNS services, ISPs provide many business-oriented services to customers. These services are enabled by software installed on servers. Among the different services provided by ISPs are:
email hosting
web site hosting
e-commerce sites
file storage and transfer
message boards and blogs
streaming video and audio services
TCP/IP Application Layer protocols enable many of these ISP services and applications. The most common TCP/IP Application Layer protocols are HTTP, FTP, SMTP, POP3, and IMAP4.
Some customers have greater concern about security, so these Application Layer protocols also include secure versions such as FTPS and HTTPS.
Supporting Http And Https
The Hypertext Transfer Protocol (HTTP), one of the protocols in the TCP/IP suite, was originally developed to enable the retrieval of HTML formatted web pages. It is now used for distributed, collaborative information sharing. The HTTP protocol has evolved through multiple versions. The version currently used by most ISPs to provide web-hosting services is HTTP version 1.1. Unlike earlier versions, this version enables a single web server to host multiple web sites. It also permits persistent connections, so that multiple request and response messages can use the same connection, reducing the time it takes to initiate new TCP sessions.
HTTP specifies a request/response protocol. When a client, typically a web browser, sends a request message to a server, the HTTP protocol defines the message types the client uses to request the web page. The HTTP protocol also defines the message types the server uses to respond.
Although it is remarkably flexible, HTTP is not a secure protocol. The request messages send information to the server in plain text that can be intercepted and read. Similarly, the server responses, typically HTML pages, are also sent unencrypted.
For secure communication across the Internet, the Secure HTTP (HTTPS) protocol is used for accessing or posting web server information. HTTPS can use authentication and encryption to secure data as it travels between the client and server. HTTPS specifies additional rules for passing data between the Application Layer and the Transport Layer.
When contacting an HTTP server to download a web page, a uniform resource locator (URL) is used to locate the server and a specific resource. The URL identifies:
Protocol being used
Domain name of the server needing to be accessed
Location of the resource on the server, such as http://example.com/example1/index.htm
Many web server applications are available that allow for short URLs. Short URLs are popular because they are easier to write down, remember, or share. With a short URL, a default resource page is assumed when a specific URL is typed. When a user types in a shortened URL, like http://example.com, the default page that is sent to the user is actually the http://example.com/example1/index.htm web page.
HTTP supports proxy services. A proxy server allows clients to make indirect network connections to other network services. A proxy is a device in the communications stream that acts as a server to the client and as a client to a server.
The client connects to the proxy server and requests from the proxy a resource on a different server. The proxy connects to the specified server and retrieves the requested resource. It then forwards the resource back to the client.
The proxy server can cache the resulting page or resource for a configurable amount of time. This enables future clients to access the web page quickly, without having to access the actual server where the page is stored. Proxies are used for three reasons:
Speed – caching allows resources requested by one user to be available to subsequent users without having to access the actual server where the page is stored.
Security – proxy servers can be used to intercept computer viruses and other malicious content and prevent them from being forwarded onto clients.
Filtering – proxy servers can view incoming HTTP messages and filter unsuitable and offensive web content.
HTTP sends clear text messages back and forth between a client and a server. These text messages can be easily intercepted and read by unauthorized users. To safeguard data, especially confidential information, some ISPs provide secure web services. To support secure web services ISPs use HTTPS (HTTP over secure sockets layer (SSL)). HTTPS uses the same client request-server response process as HTTP, but the data stream is encrypted with SSL before being transported across the network.
When the HTTP data stream arrives at the server, the TCP layer passes it up to SSL in the server’s Application Layer, where it is decrypted.
The maximum number of simultaneous connections that a server can support for HTTPS is less than that for HTTP. HTTPS creates additional load and processing time on the server due to the encryption and decryption of traffic. To keep server performance up, HTTPS should only be used when necessary, such as when exchanging confidential information.
Supporting FTP
FTP is a connection-oriented protocol that uses TCP to communicate between a client FTP process and an FTP process on a server. FTP implementations include the functions of a protocol interpreter (PI) and a data transfer process (DTP). PI and DTP define two separate processes that work together to transfer files. As a result, FTP requires two connections to exist between the client and server, one to send control information and commands, and a second one for the actual file data transfer.
Protocol Interpreter (PI)
The PI function is the main control connection between the FTP client and the FTP server. It establishes the TCP connection and passes control information to the server. Control information includes things such as commands to navigate through a file hierarchy, as well as renaming or moving files. The control connection, or control stream, stays open until closed by the user. When a user wants to connect to an FTP server:
1. The user-PI sends a connection request to the server-PI on well-known port 21.
2. The server-PI replies and the connection is established.
3. With the TCP control connection open, the server-PI process begins the login sequence.
4. The user enters credentials through the user interface and completes authentication.
5. Now the data transfer process can begin.
Data Transfer Process (DTP)
DTP is a separate data transfer function. This function is enabled only when the user wants to actually transfer files to or from the FTP server. Unlike the PI connection, which remains open, the DTP connection closes automatically when the file transfer is complete.
The two types of data transfer connections supported by FTP are active data connections and passive data connections.
Active Data Connections
In an active data connection, a client initiates a request to the server and opens a port for the expected data. The server then connects to the client on that port and the data transfer begins.
Passive Data Connections
In this instance, the FTP Server opens a random source port (greater than 1023). The server forwards its IP address and this random port to the FTP client over the control stream. The server then waits for a connection from the FTP client in order to begin the data file transfer.
ISPs typically support passive data connections to their FTP servers. Firewalls often do not permit active FTP connections to hosts located on the inside network.
Supproting SMTP, POP3, And IMAP
One of the primary services offered by an ISP is email hosting. Email is a store and forward method of sending, storing, and retrieving electronic messages across a network. Email messages are stored in databases on mail servers. ISPs often maintain mail servers that support many different customer accounts.
Email clients communicate with mail servers in order to send and receive email. Mail servers communicate with other mail servers to transport messages from one domain to another. In other words, an email client does not communicate directly with another email client when sending email. Both clients must rely upon the mail server for transport of the messages. This is true even when both users are in the same domain.
Email clients send messages to the email server configured in the application settings. When the server receives the message, it checks to see if the recipient domain is located on its local database. If it is not, it sends a DNS request to determine the mail server for the destination domain. Once the IP address of the destination mail server is known, the email is sent to the appropriate server.
Email supports three separate protocols for operation: SMTP, POP3, and IMAP4. The Application Layer process that sends mail, either from a client to a server or between servers, implements the SMTP protocol. A client retrieves email using one of two application layer protocols: POP3 or IMAP.
The functions specified by the Simple Mail Transfer Protocol (SMTP) enable the transfer of mail reliably and efficiently. For SMTP applications to do this, two conditions must be met:
The mail message must be formatted properly
SMTP processes must be running on both client and server
SMTP message formats require a message header and a message body. While the message body can contain any amount of text, the message header must have a properly formatted recipient email address and a sender address. Any other header information is optional.
When a client sends email, the client SMTP process connects with a server SMTP process on well-known port 25. Once the connection is made, the client attempts to send mail to the server across the connection. Once the server receives the message, it either places the message in a local account or forwards the message using the same SMTP connection process to another mail server.
The destination email server may not be online, or may be busy, when email messages are sent. Therefore, SMTP provides for the spooling of messages to be sent at a later time. Periodically, the server checks the queue for messages and attempts to send them again. After a predetermined expiration time, if the message is still undelivered, it will be returned to the sender as undeliverable.
One of the required fields in an email message header is the recipient email address. The structure of an email address includes the email account name or an alias, as well as the domain name of the mail server. An example of an email address:
recipient@cisco.com.
The @ symbol separates the account and the domain name of the server.
When a message is sent to recipient@cisco.com, the domain name is sent to the DNS server in order to obtain the IP address of the domain mail server. Mail servers are identified in DNS by an MX record indicator. When the destination mail server receives the message, it stores the message in the appropriate mailbox. The mailbox location is determined based on the account specified in the first part of the email address, in this case, the recipient account. The message will remain in the mailbox until the recipient connects to the server to retrieve the email.
If the mail server receives an email message that references an account that does not exist, the email is returned to the sender as undeliverable.
The Post Office Protocol – Version 3 (POP3) is used to enable a workstation to retrieve mail from a mail server. With POP3, mail is downloaded from the server to the client and then deleted on the server.
The server starts the POP3 service by passively listening on TCP port 110 for client connection requests. When a client wishes to make use of the service, it sends a request to establish a TCP connection with the server. Once the connection is established, the POP3 server sends a greeting. The client and POP3 server then exchange commands and responses until the connection is closed or aborted.
Since email messages are downloaded to the client and removed from the server, this means that there is not a centralized location where email messages are kept. This makes the POP3 protocol undesirable in a centralized backup solution for a small business.
The POP3 protocol is desirable for an ISP since it alleviates the ISP’s responsibility of managing large amounts of storage for their email servers.
Internet Message Access Protocol (IMAP4) is another protocol that describes a method to retrieve email messages. However, unlike POP3, when the user connects to an IMAP-capable server, copies of the messages are downloaded to the client application. The original messages are kept on the server until manually deleted. Users view copies of the messages in their email client software.
Users can create a file hierarchy on the server to organize and store mail. That file structure is duplicated on the email client as well. When a user decides to delete a message, the server synchronizes that action and deletes the message from the server.
For small to medium-sized businesses, there are many advantages to the IMAP protocol. IMAP can lead to long-term storage of email messages on mail servers and allow for centralized backup. It also enables employees to access email messages from multiple locations, using different devices or client software. The mailbox folder structure that a user is used to seeing is available for viewing regardless of how the user accesses the mailbox.
For an ISP, IMAP may not be the protocol of choice. It can be expensive to purchase and maintain the disk space to support the large number of stored emails. Additionally, if customers expect their mailboxes to be backed up routinely, that can further increase the costs to the ISP.