Serva Supported Protocols

HTTP (TCP, port 80)


Hypertext Transfer Protocol (HTTP) is an Application Layer protocol for distributed, collaborative, hypermedia information systems.

HTTP is a request-response standard typical of client-server computing. In HTTP, web browsers typically act as clients, while an application running on the computer hosting the web site acts as a server. The client, which submits HTTP requests, is also referred as the user agent. The responding server, which stores or dynamically creates resources such as HTML files and images, may be called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels.
An HTTP session is a sequence of network request-response transactions. An HTTP client initiates a request. It establishes a Transmission Control Protocol (TCP) connection to a particular port on a host (typically port 80). An HTTP server listening on that port waits for a client's request message. Upon receiving the request, the server sends back a status line, such as "HTTP/1.1 200 OK", and a message of its own, the body of which is perhaps the requested resource, an error message, or some other information.
Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs)—or, more specifically, Uniform Resource Locators (URLs)—using the http or https URI schemes.Its use for retrieving inter-linked resources, called hypertext documents, led to the establishment of the World Wide Web in 1990.
The original version of HTTP, designated HTTP/1.0, was revised in HTTP/1.1. One of the characteristics in HTTP/1.0 was that it uses a separate connection to the same server for every document, while HTTP/1.1 can reuse the same connection to download, for instance, images for the just served page. Hence HTTP/1.1 may be faster as it takes time to set up such connections.

FTP (TCP, ports 21,20)


File Transfer Protocol (FTP) is a standard network protocol used to copy a file from one host to another over a TCP/IP-based network.

FTP is built on a client-server architecture and utilizes separate control and data connections between the client and server applications which solves the problem of different end host configurations (i.e. Operating System, file names). FTP is used with user-based password authentication or with anonymous user access.
An FTP client makes a connection to the server on TCP port 21. This connection, called the control connection, remains open for the duration of the session, with a second connection, called the data connection, on port 20 opened as required to transfer file data. The control connection is used to send administrative data (i.e. commands, identification, passwords). Commands are sent by the client over the control connection in ASCII and terminated by a carriage return and line feed. For example "RETR filename" would transfer the specified file from the server to the client. Due to this two port structure, FTP is considered out-of-band, as opposed to an in-band protocol such as HTTP.
The FTP server responds on the control connection with three digit status codes in ASCII with an optional text message, for example "200" (or "200 OK.") means that the last command was successful. The numbers represent the code number and the optional text represent explanations (i.e. <OK>) or needed parameters (i.e. <Need account for storing file>). A file transfer in progress over the data connection can be aborted using an interrupt message sent over the control connection.
FTP can be run in active mode or passive mode, which control how the second connection is opened. In active mode the client sends the server the IP address port number that the client will use for the data connection, and the server opens the connection. Passive mode was devised for use where the client is behind a firewall and unable to accept incoming TCP connections. The server sends the client an IP address and port number and the client opens the connection to the server. Both modes were updated in September 1998 to add support for IPv6 and made some other changes to passive mode, making it extended passive mode.

TFTP (UDP, port 69)


Trivial File Transfer Protocol (TFTP) is a protocol for transferring files. It is a very basic form of FTP (File Transfer Protocol).

Due to its simple design, TFTP could be implemented using a very small amount of memory. It was therefore useful for booting computers such as routers which used to have not any local data storage. It is still used today for transferring small amounts of data between hosts on a network, such as IP phone firmware or operating system images when a remote X Window System terminal or any other thin client boots up from a network host or server. The initial stages of some network based installation systems (such as Solaris Jumpstart, Red Hat Kickstart, Debian and Ubuntu network install, Symantec Ghost and Windows NT's Remote Installation Services) use TFTP to load a basic kernel that performs the actual installation.
TFTP is implemented on top of the UDP (User Datagram Protocol) using port number 69. For being designed to be small and easy to implement it lacks most of the features of a regular FTP like directory browsing or user authentication. TFTP only reads and writes files (or mail) from/to a remote server. The Preboot eXecution Environment (PXE) which is a standardized set of protocols to boot computers from a network relies on TFTP.
In TFTP, any transfer begins with a request to read or write a file, which also serves to request a connection. If the server grants the request, the connection is opened and the file is sent in fixed length blocks of 512 bytes. Each data packet contains one block of data, and must be acknowledged by an acknowledgment packet before the next packet can be sent. A data packet of less than 512 bytes signals termination of a transfer. If a packet gets lost in the network, the intended recipient will timeout and may retransmit his last packet (which may be data or an acknowledgment), thus causing the sender of the lost packet to retransmit that lost packet. The sender has to keep just one packet on hand for retransmission, since the lock step acknowledgment guarantees that all older packets have been received. Notice that both machines involved in a transfer are considered senders and receivers. One sends data and receives acknowledgments, the other sends acknowledgments and receives data.

DHCP (UDP, port 67,68)


Dynamic Host Configuration Protocol (DHCP) is a computer networking protocol used by hosts (DHCP clients) to retrieve IP address assignments and other configuration information. DHCP uses a client-server architecture.

When a DHCP-configured client (a computer or any other network-aware device) connects to a network, the DHCP client sends a broadcast query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and information about client configuration parameters such as default gateway, domain name, the DNS servers, other servers such as time servers, and so forth. On receiving a valid request, the server assigns the computer an IP address, a lease (length of time the allocation is valid), and other IP configuration parameters, such as the subnet mask and the default gateway. The query is typically initiated immediately after booting, and must complete before the client can initiate IP-based communication with other hosts.

Depending on implementation, the DHCP server may have three methods of allocating IP-addresses:


proxyDHCP (UDP, port 67,68,4011)


A proxyDHCP server is required when deploying a PXE environment on a network that already has an un-modifiable DHCP strategy. The proxyDHCP (or PXE Service) as defined by the PXE Specification 2.1, behaves much like a DHCP server by listening for ordinary DHCP client traffic and responding to certain client requests. However, unlike the DHCP server, the proxyDHCP server does not administer/provides network IP addresses, and it only responds to clients that identify themselves as PXE clients. The responses given by the proxyDHCP contain the mechanism by which the client will be able to locate the boot servers. Using a proxyDHCP server in addition to a regular DHCP server provides a key feature; it separates the administration of network addresses from the administration of boot images. By using two separate processes, you can configure the boot information managed by the proxyDHCP server without disturbing or requiring access to the (probably un-modifiable) DHCP server configuration.

DNS (UDP, port 53)


The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource connected to the Internet or a private network.

It associates various information with domain names assigned to each of the participants. Most importantly, it translates domain names meaningful to humans into the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide. An often-used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer host names into IP addresses.
The Domain Name System makes it possible to assign domain names to groups of Internet users in a meaningful way, independent of each user's physical location. Because of this, World Wide Web (WWW) hyperlinks and Internet contact information can remain consistent and constant even if the current Internet routing arrangements change or the participant uses a mobile device. The Internet maintains two principal namespaces, the domain name hierarchy and the Internet Protocol (IP) address system. The Domain Name System maintains the domain namespace and provides translation services between these two namespaces.
The Domain Name System distributes the responsibility of assigning domain names and mapping those names to IP addresses by designating authoritative name servers for each domain. Authoritative name servers are assigned to be responsible for their particular domains, and in turn can assign other authoritative name servers for their sub-domains. This mechanism has made the DNS distributed and fault tolerant and has helped avoid the need for a single central register to be continually consulted and updated.
DNS primarily uses User Datagram Protocol (UDP) on port number 53 to serve requests. DNS queries consist of a single UDP request from the client followed by a single UDP reply from the server. The Transmission Control Protocol (TCP) is used when the response data size exceeds 512 bytes, or for tasks such as zone transfers.

SNTP (UDP, port 123)


Simple Network Time Protocol (SNTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks.

Basically an SNTP server makes its own time available as reference for SNTP clients. SNTP is a less complex implementation (on its server side) of NTP (Network Time Protocol). It uses the same communication protocol (identical network-packet format) but simpler algorithms for time determination. SNTP is best suited when it comes to synchronize computers at the extremities of a computer network. It is also ideal for less powerful processors, such as micro-controllers and embedded systems, which do not require the accuracy of NTP.
A unicast SNTP client sends a request to a designated SNTP server at its unicast address and expects a reply from which it can determine the time and, optionally, the round trip delay and local clock offset relative to the server. SNTP uses UDP port 123.

SYSLOG (UDP, port 514)


Syslog is a standardized (within the Syslog working group of the IETF) protocol for logging program messages.

It allows separation of the software that generates messages from the system that stores them and the software that reports and analyzes them. It also provides devices, which would otherwise be unable to communicate, a means to notify administrators of problems or performance.
Syslog is supported by a wide variety of devices (like printers and routers) and receivers across multiple platforms. Because of this, syslog can be used to integrate log data from many different types of systems into a central repository.
Syslog messages are received on UDP port 514. Syslog message text is generally no more than 1024 bytes in length. Since the UDP type of communication is connectionless, the sending or receiving host has no knowledge receipt for retransmission. If an UDP packet gets lost due to congestion on the network or due to resource unavailability, it will simply get lost. Messages refer to a facility (auth, authpriv, daemon, cron, ftp, lpr, kern, mail, news, syslog, user, uucp, local0, ... , local7 ) and are assigned a priority/level (Emergency, Alert, Critical, Error, Warning, Notice, Info or Debug) by the sender of the message. Configuration allows directing messages to various local devices (console), files (/var/log/) or remote syslog daemons. Care must be taken when updating the configuration as omitting or misdirecting message facility level can cause important messages to be ignored by syslog or overlooked by the administrator.
"logger" is a Unix/Linux command line utility that can send messages to the syslog.

PXE (extended DHCP+TFTP)


The Preboot eXecution Environment (PXE, pronounced pixie) was introduced as part of the Wired for Management framework by Intel and is described in the specification (version 2.1) published by Intel and Systemsoft on September 20, 1999.
PXE is an environment to boot computers using a network interface independently of available data storage devices (like hard disks) or installed operating systems.

The term PXE client only refers to the role that the machine takes in the PXE boot process. A PXE client can be a booting server, desktop, laptop, router, embedded device or any other machine that is equipped with PXE boot code.
The PXE protocol is approximately a combination of DHCP and TFTP, albeit with subtle modifications to both. DHCP is used to initially assign client's IP and to communicate the appropriate boot server IP address and the name of the boot file. TFTP is used to transfer the initial bootstrap program and some additional files.

To initiate a PXE bootstrap session the PXE firmware broadcasts a DHCPDISCOVER packet extended with PXE-specific options (extended DHCPDISCOVER) to port 67/UDP (DHCP server port). The PXE options identify the firmware as capable of PXE, but they will be ignored by standard DHCP servers. If the firmware receives DHCPOFFERs from such servers, it may configure itself by requesting one of the offered configurations. Installing high-end OSs using PXE will usually require the complementary use of FTP, HTTP, or SMB/CIFS services.

BINL (UDP, port 4011)

The Boot Information Negotiation Layer (BINL) service is a key component of Microsoft's RIS and WDS remote OS install strategies. It includes certain preparation/maintenance processes and a network protocol that could be somehow considered a Microsoft crafted DHCP extension.
The BINL network protocol handles a number of client initiated request/response transactions where the clients ask for vital information to complete their remote OS install actions. i.e. BINL identifies and supplies the correct driver binary for the client PC's network card on the text phase of a RIS install scenario.