TELNET (TELecommunication NETwork) is a network protocol used on the Internet or local area network (LAN) connections. It was developed in 1969 beginning with RFC 15 and standardized as IETF STD 8, one of the first Internet standards. The term telnet also refers to software which implements the client part of the protocol. TELNET clients have been available on most Unix systems for many years and are available for virtually all platforms. Most network equipment and OSs with a TCP/IP stack support some kind of TELNET service server for their remote configuration (including ones based on Windows NT). Recently, Secure Shell has begun to dominate remote access for Unix-based machines. "To telnet" is also used as a verb meaning to establish or use a TELNET or other interactive TCP connection, as in, "To change your password, telnet to the server and run the passwd command". Most often, a user will be telneting to a Unix-like server system or a simple network device such as a switch. For example, a user might "telnet in from home to check his mail at school". In doing so, he would be using a telnet client to connect from his computer to one of his servers. Once the connection is established, he would then log in with his account information and execute operating system commands remotely on that computer, such as ls or cd. On many systems, the client may also be used to make interactive raw-TCP sessions, even when that option is not available, telnet sessions are equivalent to raw TCP as long as byte 255 never appears in the data. Protocol details TELNET is a client-server protocol, based on a reliable connection-oriented transport. Typically this is TCP port 23, although TELNET predates TCP/IP and was originally run on NCP. The protocol has many extensions, some of which have been adopted as Internet standards. IETF standards STD 27 through STD 32 define various extensions, most of which are extremely common. Other extensions are on the IETF standards track as proposed standards. Security When TELNET was initially developed in 1969, most users of networked computers were in the computer departments of academic institutions, or at large private and government research facilities. In this environment, security was not nearly as much of a concern as it became after the bandwidth explosion of the 1990s. The rise in the number of people with access to the Internet, and by extension, the number of people attempting to crack other people's servers made encrypted alternatives much more necessary. Experts in computer security, such as SANS Institute, and the members of the comp.os.linux.security newsgroup recommend that the use of TELNET for remote logins should be discontinued under all normal circumstances, for the following reasons: TELNET, by default, does not encrypt any data sent over the connection (including passwords), and so it is often practical to eavesdrop on the communications and use the password later for malicious purposes; anybody who has access to a router, switch, or gateway located on the network between the two hosts where TELNET is being used can intercept the packets passing by and obtain login and password information (and whatever else is typed) with any of several common utilities like tcpdump and Wireshark. Most implementations of TELNET lack an authentication scheme that makes it possible to ensure that communication is carried out between the two desired hosts, and not intercepted in the middle. Commonly used TELNET daemons have several vulnerabilities discovered over the years. These security-related shortcomings have seen the usage of the TELNET protocol drop rapidly, especially on the public Internet, in favor of a the ssh protocol, first released in 1995. SSH provides much functionality of telnet, with the addition of strong encryption to prevent sensitive data such as passwords from being intercepted, and public key authentication, to ensure that the remote computer is actually who it claims to be. As has happened with other early Internet protocols, extensions to the TELNET protocol provide TLS security and SASL authentication that address the above issues. However, most TELNET implementations do not support these extensions; and there has been relatively little interest in implementing these as SSH is adequate for most purposes. The main advantage of TLS-TELNET would be the ability to use certificate-authority signed server certificates to authenticate a server host to a client that does not yet have the server key stored. In SSH, there is a weakness in that the user must trust the first session to a host when it has not yet acquired the server key. Clients and servers designed to pass IBM 5250 data streams over Telnet generally do support SSL encryption, as SSH does not include 5250 emulation. Under OS/400, Port 992 is the default port for Secured Telnet. Current status As of the mid-2000s, while the TELNET protocol itself has been mostly superseded, TELNET clients are still used, often when diagnosing problems, to manually "talk" to other services without specialized client software. For example, it is sometimes used in debugging network services such as an SMTP, IRC or HTTP server, by serving as a simple way to send commands to the server and examine the responses. However, other software such as nc (netcat) or socat on Unix (or PuTTY on Windows) are finding greater favor with some system administrators for testing purposes, as they can be called with arguments to not send any terminal control handshaking data. Also netcat does not distort the \377 octet, which allows raw access to TCP socket, unlike any standard-compliant TELNET software. TELNET is still very popular in enterprise networks to access host applications, e.g. on IBM Mainframes. TELNET is still widely used for administration of network elements, e.g., in commissioning, integration and maintenance of core network elements in mobile communication networks. TELNET is also heavily used for MUD games played over the Internet, as well as talkers, MUSHes, MUCKs, MOOes, and the resurgent BBS community. In the 2007 Microsoft Windows release, Windows Vista, Telnet.exe is no longer installed by default, but is still included as an installable feature.
Thursday, October 11, 2007
FTP and NAT devices
The representation of the IPs and ports in the PORT command and PASV reply poses another challenge for NAT devices in handling FTP. The NAT device must alter these values, so that they contain the IP of the NAT-ed client, and a port chosen by the NAT device for the data connection. The new IP and port will probably differ in length in their decimal representation from the original IP and port. This means that altering the values on the control connection by the NAT device must be done carefully, changing the TCP Sequence and Acknowledgment fields for all subsequent packets. For example: A client with an IP of 192.168.0.1, starting an active mode transfer on port 1025, will send the string "PORT 192,168,0,1,4,1". A NAT device masquerading this client with an IP of 192.168.15.5, with a chosen port of 2000 for the data connection, will need to replace the above string with "PORT 192,168,15,5,7,208". The new string is 23 characters long, compared to 20 characters in the original packet. The Acknowledgment field by the server to this packet will need to be decreased by 3 bytes by the NAT device for the client to correctly understand that the PORT command has arrived to the server. If the NAT device is not capable of correcting the Sequence and Acknowledgement fields, it will not be possible to use active mode FTP. Passive mode FTP will work in this case, because the information about the IP and port for the data connection is sent by the server, which doesn't need to be NATed. If NAT is performed on the server by the NAT device, then the exact opposite will happen. Active mode will work, but passive mode will fail. It should be noted that many NAT devices perform this protocol inspection and modify the PORT command without being explicitly told to do so by the user. This can lead to several problems. First of all, there is no guarantee that the used protocol really is FTP, or it might use some extension not understood by the NAT device. One example would be an SSL secured FTP connection. Due to the encryption, the NAT device will be unable to modify the address. As result, active mode transfers will fail only if encryption is used, much to the confusion of the user. The proper way to solve this is to tell the client which IP address and ports to use for active mode. Furthermore, the NAT device has to be configured to forward the selected range of ports to the client's machine. FTP over SSH FTP over SSH refers to the practice of tunneling a normal FTP session over an SSH connection. Because FTP uses multiple TCP connections (unusual for a TCP/IP protocol that is still in use), it is particularly difficult to tunnel over SSH. With many SSH clients, attempting to set up a tunnel for the control channel (the initial client-to-server connection on port 21) will protect only that channel; when data is transferred, the FTP software at either end will set up new TCP connections (data channels) which will bypass the SSH connection, and thus have no confidentiality, integrity protection, etc. If the FTP client is configured to use passive mode and to connect to a SOCKS server interface that many SSH clients can present for tunneling, it is possible to run all the FTP channels over the SSH connection. Otherwise, it is necessary for the SSH client software to have specific knowledge of the FTP protocol, and monitor and rewrite FTP control channel messages and autonomously open new forwardings for FTP data channels. Version 3 of SSH Communications Security's software suite, and the GPL licensed FONC are two software packages that support this mode. FTP over SSH is sometimes referred to as secure FTP; this should not be confused with other methods of securing FTP, such as with SSL/TLS (FTPS). Other methods of transferring files using SSH that are not related to FTP include SFTP and SCP; in each of these, the entire conversation (credentials and data) is always protected by the SSH protocol.
File Transfer Protocol
FTP or File Transfer Protocol is used to transfer data from one computer to another over the Internet, or through a network.
Specifically, FTP is a commonly used protocol for exchanging files over any network that supports the TCP/IP protocol (such as the Internet or an intranet). There are two computers involved in an FTP transfer: a server and a client. The FTP server, running FTP server software, listens on the network for connection requests from other computers. The client computer, running FTP client software, initiates a connection to the server. Once connected, the client can do a number of file manipulation operations such as uploading files to the server, download files from the server, rename or delete files on the server and so on. Any software company or individual programmer is able to create FTP server or client software because the protocol is an open standard. Virtually every computer platform supports the FTP protocol. This allows any computer connected to a TCP/IP based network to manipulate files on another computer on that network regardless of which operating systems are involved (if the computers permit FTP access). There are many existing FTP client and server programs. FTP servers can be set up anywhere between game servers, voice servers, internet hosts, and other physical servers.
Connection Methods
FTP runs exclusively over TCP. FTP servers by default listen on port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from the FTP client and on occasion from the FTP server to the FTP client. For the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different.
In active mode, the FTP client opens a random port (> 1023), sends the FTP server the random port number on which it is listening over the control stream and waits for a connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 21 on the FTP server.
In order to use active mode, the client sends a PORT command, with the IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2". Each field is a decimal representation of 8 bits of the host IP, followed by the chosen data port. For example, a client with an IP of 192.168.0.1, listening on port 1025 for the data connection will send the command "PORT 192,168,0,1,4,1". The port fields should be interpreted as p1×256 + p2 = port, or, in this example, 4×256 + 1 = 1025.
In passive mode, the FTP server opens a random port (> 1023), sends the FTP client the server's IP address to connect to and the port on which it is listening (a 16 bit value broken into a high and low byte, like explained before) over the control stream and waits for a connection from the FTP client. In this case the FTP client binds the source port of the connection to a random port greater than 1023.
To use passive mode, the client sends the PASV command to which the server would reply with something similar to "227 Entering Passive Mode (127,0,0,1,78,52)". The syntax of the IP address and port are the same as for the argument to the PORT command.
In extended passive mode, the FTP server operates exactly the same as passive mode, however it only transmits the port number (not broken into high and low bytes) and the client is to assume that it connects to the same IP address that was originally connected to. Extended passive mode was added by RFC 2428 in September 1998.
While data is being transferred via the data stream, the control stream sits idle. This can cause problems with large data transfers through firewalls which time out sessions after lengthy periods of idleness. While the file may well be successfully transferred, the control session can be disconnected by the firewall, causing an error to be generated.
The FTP protocol supports resuming of interrupted downloads using the REST command. The client passes the number of bytes it has already received as argument to the REST command and restarts the transfer. In some commandline clients for example, there is an often-ignored but valuable command, "reget" (meaning "get again") that will cause an interrupted "get" command to be continued, hopefully to completion, after a communications interruption.
Resuming uploads is not as easy. Although the FTP protocol supports the APPE command to append data to a file on the server, the client does not know the exact position at which a transfer got interrupted. It has to obtain the size of the file some other way, for example over a directory listing or using the SIZE command.
In ASCII mode (see below), resuming transfers can be troublesome if client and server use different end of line characters.
The objectives of FTP, as outlined by its RFC, are:
To promote sharing of files (computer programs and/or data).
To encourage indirect or implicit use of remote computers.
To shield a user from variations in file storage systems among different hosts.
To transfer data reliably, and efficiently.
Criticisms of FTP
Passwords and file contents are sent in clear text, which can be intercepted by eavesdroppers. There are protocol enhancements that circumvent this, for instance by using SSL or TLS.
Multiple TCP/IP connections are used, one for the control connection, and one for each download, upload, or directory listing. Firewalls may need additional logic and or configuration changes to account for these connections.
It is hard to filter active mode FTP traffic on the client side by using a firewall, since the client must open an arbitrary port in order to receive the connection. This problem is largely resolved by using passive mode FTP.
It is possible to abuse the protocol's built-in proxy features to tell a server to send data to an arbitrary port of a third computer; see FXP.
FTP is a high latency protocol due to the number of commands needed to initiate a transfer.
No integrity check on the receiver side. If a transfer is interrupted, the receiver has no way to know if the received file is complete or not. Some servers support extensions to calculate for example a file's MD5 sum (e.g. using the SITE MD5 command) or CRC checksum, however even then the client has to make explicit use of them. In the absence of such extensions, integrity checks have to be managed externally.
No date/timestamp attribute transfer. Uploaded files are given a new current timestamp, unlike other file transfer protocols such as SFTP, which allow attributes to be included. There is no way in the standard FTP protocol to set the time-last-modified (or time-created) datestamp that most modern filesystems preserve. There is a draft of a proposed extension that adds new commands for this, but as of yet, most of the popular FTP servers do not support it.
Security problems
The original FTP specification is an inherently insecure method of transferring files because there is no method specified for transferring data in an encrypted fashion. This means that under most network configurations, user names, passwords, FTP commands and transferred files can be "sniffed" or viewed by anyone on the same network using a packet sniffer. This is a problem common to many Internet protocol specifications written prior to the creation of SSL such as HTTP, SMTP and Telnet. The common solution to this problem is to use either SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP as specified in RFC 4217.
FTP return codes
FTP server return codes indicate their status by the digits within them. A brief explanation of various digits' meanings are given below:
1xx: Positive Preliminary reply. The action requested is being initiated but there will be another reply before it begins.
2xx: Positive Completion reply. The action requested has been completed. The client may now issue a new command.
3xx: Positive Intermediate reply. The command was successful, but a further command is required before the server can act upon the request.
4xx: Transient Negative Completion reply. The command was not successful, but the client is free to try the command again as the failure is only temporary.
5xx: Permanent Negative Completion reply. The command was not successful and the client should not attempt to repeat it again.
x0x: The failure was due to a syntax error.
x1x: This response is a reply to a request for information.
x2x: This response is a reply relating to connection information.
x3x: This response is a reply relating to accounting and authorization.
x4x: Unspecified as yet
x5x: These responses indicate the status of the Server file system vis-a-vis the requested transfer or other file system action
Anonymous FTP
Many sites that run FTP servers enable anonymous ftp. Under this arrangement, users do not need an account on the server. The user name for anonymous access is typically 'anonymous'. This account does not need a password. Although users are commonly asked to send their email addresses as their passwords for authentication, usually there is trivial or no verification, depending on the FTP server and its configuration. As modern FTP clients hide the login process from the user and usually don't know the user's email address, they supply dummy passwords, for example:
Mozilla Firefox (2.0) — mozilla@example.com
KDE Konqueror (3.5) — anonymous@
wget (1.10.2) — -wget@
lftp (3.4.4) — lftp@
Internet Gopher has been suggested as an alternative to anonymous FTP, as well as Trivial File Transfer Protocol and File Service Protocol.
Data format
While transferring data over the network, several data representations can be used. The two most common transfer modes are:
ASCII mode
Binary mode: In "Binary mode", the sending machine sends each file bit for bit and as such the recipient stores the bitstream as it receives it.
In "ASCII mode", any form of data that is not plain text will be corrupted. When a file is sent using an ASCII-type transfer, the individual letters, numbers, and characters are sent using their ASCII character codes. The receiving machine saves these in a text file in the appropriate format (for example, a Unix machine saves it in a Unix format, a Windows machine saves it in a Windows format). Hence if an ASCII transfer is used it can be assumed plain text is sent, which is stored by the receiving computer in its own format. Translating between text formats entails substituting the end of line and end of file characters used on the source platform with those on the destination platform, e.g. a Windows machine receiving a file from a Unix machine will replace the line feeds with carriage return-line feed pairs.
By default, most FTP clients use ASCII mode. Some clients try to determine the required transfer-mode by inspecting the file's name or contents.
The FTP specifications also list the following transfer modes:
EBCDIC mode
Local mode
In practice, these additional transfer modes are rarely used. They are however still used by some legacy mainframe systems.
FTP and web browsers
Most recent web browsers and file managers can connect to FTP servers, although they may lack the support for protocol extensions such as FTPS. This allows manipulation of remote files over FTP through an interface similar to that used for local files. This is done via an FTP URL, which takes the form ftp(s):// (e.g., [1]). A password can optionally be given in the URL, e.g.: ftp(s)://:@:. Most web-browsers require the use of passive mode FTP, which not all FTP servers are capable of handling. Some browsers allow only the downloading of files, but offer no way to upload files to the server.
Specifically, FTP is a commonly used protocol for exchanging files over any network that supports the TCP/IP protocol (such as the Internet or an intranet). There are two computers involved in an FTP transfer: a server and a client. The FTP server, running FTP server software, listens on the network for connection requests from other computers. The client computer, running FTP client software, initiates a connection to the server. Once connected, the client can do a number of file manipulation operations such as uploading files to the server, download files from the server, rename or delete files on the server and so on. Any software company or individual programmer is able to create FTP server or client software because the protocol is an open standard. Virtually every computer platform supports the FTP protocol. This allows any computer connected to a TCP/IP based network to manipulate files on another computer on that network regardless of which operating systems are involved (if the computers permit FTP access). There are many existing FTP client and server programs. FTP servers can be set up anywhere between game servers, voice servers, internet hosts, and other physical servers.
Connection Methods
FTP runs exclusively over TCP. FTP servers by default listen on port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from the FTP client and on occasion from the FTP server to the FTP client. For the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different.
In active mode, the FTP client opens a random port (> 1023), sends the FTP server the random port number on which it is listening over the control stream and waits for a connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 21 on the FTP server.
In order to use active mode, the client sends a PORT command, with the IP and port as argument. The format for the IP and port is "h1,h2,h3,h4,p1,p2". Each field is a decimal representation of 8 bits of the host IP, followed by the chosen data port. For example, a client with an IP of 192.168.0.1, listening on port 1025 for the data connection will send the command "PORT 192,168,0,1,4,1". The port fields should be interpreted as p1×256 + p2 = port, or, in this example, 4×256 + 1 = 1025.
In passive mode, the FTP server opens a random port (> 1023), sends the FTP client the server's IP address to connect to and the port on which it is listening (a 16 bit value broken into a high and low byte, like explained before) over the control stream and waits for a connection from the FTP client. In this case the FTP client binds the source port of the connection to a random port greater than 1023.
To use passive mode, the client sends the PASV command to which the server would reply with something similar to "227 Entering Passive Mode (127,0,0,1,78,52)". The syntax of the IP address and port are the same as for the argument to the PORT command.
In extended passive mode, the FTP server operates exactly the same as passive mode, however it only transmits the port number (not broken into high and low bytes) and the client is to assume that it connects to the same IP address that was originally connected to. Extended passive mode was added by RFC 2428 in September 1998.
While data is being transferred via the data stream, the control stream sits idle. This can cause problems with large data transfers through firewalls which time out sessions after lengthy periods of idleness. While the file may well be successfully transferred, the control session can be disconnected by the firewall, causing an error to be generated.
The FTP protocol supports resuming of interrupted downloads using the REST command. The client passes the number of bytes it has already received as argument to the REST command and restarts the transfer. In some commandline clients for example, there is an often-ignored but valuable command, "reget" (meaning "get again") that will cause an interrupted "get" command to be continued, hopefully to completion, after a communications interruption.
Resuming uploads is not as easy. Although the FTP protocol supports the APPE command to append data to a file on the server, the client does not know the exact position at which a transfer got interrupted. It has to obtain the size of the file some other way, for example over a directory listing or using the SIZE command.
In ASCII mode (see below), resuming transfers can be troublesome if client and server use different end of line characters.
The objectives of FTP, as outlined by its RFC, are:
To promote sharing of files (computer programs and/or data).
To encourage indirect or implicit use of remote computers.
To shield a user from variations in file storage systems among different hosts.
To transfer data reliably, and efficiently.
Criticisms of FTP
Passwords and file contents are sent in clear text, which can be intercepted by eavesdroppers. There are protocol enhancements that circumvent this, for instance by using SSL or TLS.
Multiple TCP/IP connections are used, one for the control connection, and one for each download, upload, or directory listing. Firewalls may need additional logic and or configuration changes to account for these connections.
It is hard to filter active mode FTP traffic on the client side by using a firewall, since the client must open an arbitrary port in order to receive the connection. This problem is largely resolved by using passive mode FTP.
It is possible to abuse the protocol's built-in proxy features to tell a server to send data to an arbitrary port of a third computer; see FXP.
FTP is a high latency protocol due to the number of commands needed to initiate a transfer.
No integrity check on the receiver side. If a transfer is interrupted, the receiver has no way to know if the received file is complete or not. Some servers support extensions to calculate for example a file's MD5 sum (e.g. using the SITE MD5 command) or CRC checksum, however even then the client has to make explicit use of them. In the absence of such extensions, integrity checks have to be managed externally.
No date/timestamp attribute transfer. Uploaded files are given a new current timestamp, unlike other file transfer protocols such as SFTP, which allow attributes to be included. There is no way in the standard FTP protocol to set the time-last-modified (or time-created) datestamp that most modern filesystems preserve. There is a draft of a proposed extension that adds new commands for this, but as of yet, most of the popular FTP servers do not support it.
Security problems
The original FTP specification is an inherently insecure method of transferring files because there is no method specified for transferring data in an encrypted fashion. This means that under most network configurations, user names, passwords, FTP commands and transferred files can be "sniffed" or viewed by anyone on the same network using a packet sniffer. This is a problem common to many Internet protocol specifications written prior to the creation of SSL such as HTTP, SMTP and Telnet. The common solution to this problem is to use either SFTP (SSH File Transfer Protocol), or FTPS (FTP over SSL), which adds SSL or TLS encryption to FTP as specified in RFC 4217.
FTP return codes
FTP server return codes indicate their status by the digits within them. A brief explanation of various digits' meanings are given below:
1xx: Positive Preliminary reply. The action requested is being initiated but there will be another reply before it begins.
2xx: Positive Completion reply. The action requested has been completed. The client may now issue a new command.
3xx: Positive Intermediate reply. The command was successful, but a further command is required before the server can act upon the request.
4xx: Transient Negative Completion reply. The command was not successful, but the client is free to try the command again as the failure is only temporary.
5xx: Permanent Negative Completion reply. The command was not successful and the client should not attempt to repeat it again.
x0x: The failure was due to a syntax error.
x1x: This response is a reply to a request for information.
x2x: This response is a reply relating to connection information.
x3x: This response is a reply relating to accounting and authorization.
x4x: Unspecified as yet
x5x: These responses indicate the status of the Server file system vis-a-vis the requested transfer or other file system action
Anonymous FTP
Many sites that run FTP servers enable anonymous ftp. Under this arrangement, users do not need an account on the server. The user name for anonymous access is typically 'anonymous'. This account does not need a password. Although users are commonly asked to send their email addresses as their passwords for authentication, usually there is trivial or no verification, depending on the FTP server and its configuration. As modern FTP clients hide the login process from the user and usually don't know the user's email address, they supply dummy passwords, for example:
Mozilla Firefox (2.0) — mozilla@example.com
KDE Konqueror (3.5) — anonymous@
wget (1.10.2) — -wget@
lftp (3.4.4) — lftp@
Internet Gopher has been suggested as an alternative to anonymous FTP, as well as Trivial File Transfer Protocol and File Service Protocol.
Data format
While transferring data over the network, several data representations can be used. The two most common transfer modes are:
ASCII mode
Binary mode: In "Binary mode", the sending machine sends each file bit for bit and as such the recipient stores the bitstream as it receives it.
In "ASCII mode", any form of data that is not plain text will be corrupted. When a file is sent using an ASCII-type transfer, the individual letters, numbers, and characters are sent using their ASCII character codes. The receiving machine saves these in a text file in the appropriate format (for example, a Unix machine saves it in a Unix format, a Windows machine saves it in a Windows format). Hence if an ASCII transfer is used it can be assumed plain text is sent, which is stored by the receiving computer in its own format. Translating between text formats entails substituting the end of line and end of file characters used on the source platform with those on the destination platform, e.g. a Windows machine receiving a file from a Unix machine will replace the line feeds with carriage return-line feed pairs.
By default, most FTP clients use ASCII mode. Some clients try to determine the required transfer-mode by inspecting the file's name or contents.
The FTP specifications also list the following transfer modes:
EBCDIC mode
Local mode
In practice, these additional transfer modes are rarely used. They are however still used by some legacy mainframe systems.
FTP and web browsers
Most recent web browsers and file managers can connect to FTP servers, although they may lack the support for protocol extensions such as FTPS. This allows manipulation of remote files over FTP through an interface similar to that used for local files. This is done via an FTP URL, which takes the form ftp(s)://
Hypertext Transfer Protocol
Hypertext Transfer Protocol (HTTP) is a communications protocol used to transfer or convey information on the World Wide Web. Its original purpose was to provide a way to publish and retrieve HTML hypertext pages. Development of HTTP was coordinated by the W3C (World Wide Web Consortium) and the IETF (Internet Engineering Task Force), culminating in the publication of a series of RFCs, most notably RFC 2616 (June 1999), which defines HTTP/1.1, the version of HTTP in common use today.
HTTP is a request/response protocol between clients and servers. The client making an HTTP request - such as a web browser, spider, or other end-user tool - is referred to as the user agent. The responding server - which stores or creates resources such as HTML files and images - is called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels. It is useful to remember that HTTP does not need to use TCP/IP or its supporting layers. Indeed HTTP can be "implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used."
An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a host (port 80 by default; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for the client to send a 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 file, an error message, or some other information.
Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs) (or, more specifically, URLs) using the http: or https URI schemes.
Request message
The request message consists of the following:
Request line, such as GET /images/logo.gif HTTP/1.1, which requests the file logo.gif from the /images directory
Headers, such as Accept-Language: en
An empty line
An optional message body
The request line and headers must all end with CRLF (that is, a carriage return followed by a line feed). The empty line must consist of only CRLF and no other whitespace. In the HTTP/1.1 protocol, all headers except Host are optional.
Request methods
HTTP defines eight methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource.
HEAD
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
GET
Requests a representation of the specified resource. By far the most common method used on the Web today. Should not be used for operations that cause side-effects (using it for actions in web applications is a common misuse). See 'safe methods' below.
POST
Submits data to be processed (e.g. from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
PUT
Uploads a representation of the specified resource.
DELETE
Deletes the specified resource.
TRACE
Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request.
OPTIONS
Returns the HTTP methods that the server supports. This can be used to check the functionality of a web server.
CONNECT
Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.[1]
HTTP servers are supposed to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.
Safe methods
Some methods (e.g. HEAD or GET) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server (in other words, they should not have side effects). Unsafe methods (such as POST, PUT and DELETE) should be displayed to the user in a special way, typically as buttons rather than links, thus making the user aware of possible obligations (such as a button that causes a financial transaction).
Despite the required safety of GET requests, in practice they can cause changes on the server. For example, a Web server may use the retrieval through a simple hyperlink to initiate deletion of a domain database record, thus causing a change of the server's state as a side-effect of a GET request. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server. Another case is that a GET request may cause the server to create a cache space.
Idempotent methods and Web Applications
Methods GET, HEAD, PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods OPTIONS and TRACE, being safe, are inherently idempotent.
The RFC allows a user-agent, such as a browser to assume that any idempotent request can be retried without informing the user. This is done to improve the user experience when connecting to unresponsive or heavily-loaded web servers.
However, note that the idempotence is not assured by the protocol or web server. It is perfectly possible to write a web application in which (eg) a database insert or update is triggered by a GET request - this would be a very normal example of what the spec refers to as "a change in server state".
This misuse of GET can combine with the retry behaviour above to produce erroneous transactions - and for this reason GET should be avoided for anything transactional - and used, as intended, for document retrieval only.
HTTP versions
HTTP has evolved into multiple, mostly backwards-compatible protocol versions. RFC 2145 describes the use of HTTP version numbers. The client tells in the beginning of the request the version it uses, and the server uses the same or earlier version in the response.
0.9
Deprecated. Supports only one command, GET — which does not specify the HTTP version. Does not support headers. Since this version does not support POST, the client can't pass much information to the server.
HTTP/1.0 (May 1996)
This is the first protocol revision to specify its version in communications and is still in wide use, especially by proxy servers.
HTTP/1.1 (June 1999)[2][3]
Current version; persistent connections enabled by default and works well with proxies. Also supports request pipelining, allowing multiple requests to be sent at the same time, allowing the server to prepare for the workload and potentially transfer the requested resources more quickly to the client.
HTTP/1.2
The initial 1995 working drafts of the document PEP — an Extension Mechanism for HTTP (which proposed the Protocol Extension Protocol, abbreviated PEP) were prepared by the World Wide Web Consortium and submitted to the Internet Engineering Task Force. PEP was originally intended to become a distinguishing feature of HTTP/1.2.[4] In later PEP working drafts, however, the reference to HTTP/1.2 was removed. The experimental RFC 2774, HTTP Extension Framework, largely subsumed PEP. It was published in February 2000.
Status codes
In HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as "404") and a textual reason phrase (such as "Not Found"). The way the user agent handles the response primarily depends on the code and secondarily on the response headers. Custom status codes can be used since, if the user agent encounters a code it does not recognize, it can use the first digit of the code to determine the general class of the response.[5]
Also, the standard reason phrases are only recommendations and can be replaced with "local equivalents" at the web developer's discretion. If the status code indicated a problem, the user agent might display the reason phrase to the user to provide further information about the nature of the problem. The standard also allows the user agent to attempt to interpret the reason phrase, though this might be unwise since the standard explicitly specifies that status codes are machine-readable and reason phrases are human-readable.
Persistent connections
In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request.
Such persistent connections reduce lag perceptibly, because the client does not need to re-negotiate the TCP connection after the first request has been sent.
Version 1.1 of the protocol also introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered, and HTTP pipelining, which allows clients to send some types of requests before the previous response has been received, further reducing lag.
HTTP session state
HTTP can occasionally pose problems for Web developers (Web Applications), because HTTP is stateless. The advantage of a stateless protocol is that hosts do not need to retain information about users between requests, but this forces the use of alternative methods for maintaining users' state, for example, when a host would like to customize content for a user who has visited before. The common method for solving this problem involves the use of sending and requesting cookies. Other methods include server side sessions, hidden variables (when current page is a form), and URL encoded parameters (such as /index.php?userid=3).
Secure HTTP
There are currently two methods of establishing a secure HTTP connection: the https URI scheme and the HTTP 1.1 Upgrade header, introduced by RFC 2817. Browser support for the Upgrade header is, however, nearly non-existent, hence the https URI scheme is still the dominant method of establishing a secure HTTP connection.
https URI scheme
https: is a URI scheme syntactically identical to the http: scheme used for normal HTTP connections, but which signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is especially suited for HTTP since it can provide some protection even if only one side of the communication is authenticated. In the case of HTTP transactions over the Internet, typically, only the server side is authenticated.
HTTP 1.1 Upgrade header
HTTP 1.1 introduced support for the Upgrade header. In the exchange, the client begins by making a clear-text request, which is later upgraded to TLS. Either the client or the server may request (or demand) that the connection be upgraded. The most common usage is a clear-text request by the client followed by a server demand to upgrade the connection, which looks like this:
Client:GET /encrypted-area HTTP/1.1Host: www.example.com
Server:HTTP/1.1 426 Upgrade RequiredUpgrade: TLS/1.0, HTTP/1.1Connection: Upgrade
The server returns a 426 status-code because 400 level codes indicate a client failure (see List of HTTP status codes), which correctly alerts legacy clients that the failure was client-related.
The benefits of using this method for establishing a secure connection are:
that it removes messy and problematic redirection and URL rewriting on the server side,
it allows virtual hosting (single IP, multiple domain-names) of secured websites, and
it reduces user confusion by providing a single way to access a particular resource.
A weakness with this method is that the requirement for secure HTTP cannot be specified in the URI. In practice, the (untrusted) server will thus be responsible for enabling secure HTTP, not the (trusted) client.
Sample
Below is a sample conversation between an HTTP client and an HTTP server running on http://en.wikipedia.org/wiki/Example.com, port 80.
Client request (followed by a blank line, so that request ends with a double newline, each in the form of a carriage return followed by a line feed): GET /index.html HTTP/1.1 Host: www.example.com
The "Host" header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
Server response (followed by a blank line and text of the requested page): HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8
The ETag (entity tag) header is used to determine if the URL cached is identical to the requested URL on the server. Content-Type specifies the Internet media type of the data conveyed by the http message, while Content-Length indicates its length in bytes. The webserver publishes its ability to respond to requests for certain byte ranges of the document by setting the header Accept-Ranges: bytes. This is useful if the connection was interrupted before the data was completely transferred to the client.[6] With Connection: close it is stated, that the webserver will close the TCP connection immediately after the transfer of this package.
HTTP is a request/response protocol between clients and servers. The client making an HTTP request - such as a web browser, spider, or other end-user tool - is referred to as the user agent. The responding server - which stores or creates resources such as HTML files and images - is called the origin server. In between the user agent and origin server may be several intermediaries, such as proxies, gateways, and tunnels. It is useful to remember that HTTP does not need to use TCP/IP or its supporting layers. Indeed HTTP can be "implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used."
An HTTP client initiates a request by establishing a Transmission Control Protocol (TCP) connection to a particular port on a host (port 80 by default; see List of TCP and UDP port numbers). An HTTP server listening on that port waits for the client to send a 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 file, an error message, or some other information.
Resources to be accessed by HTTP are identified using Uniform Resource Identifiers (URIs) (or, more specifically, URLs) using the http: or https URI schemes.
Request message
The request message consists of the following:
Request line, such as GET /images/logo.gif HTTP/1.1, which requests the file logo.gif from the /images directory
Headers, such as Accept-Language: en
An empty line
An optional message body
The request line and headers must all end with CRLF (that is, a carriage return followed by a line feed). The empty line must consist of only CRLF and no other whitespace. In the HTTP/1.1 protocol, all headers except Host are optional.
Request methods
HTTP defines eight methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource.
HEAD
Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content.
GET
Requests a representation of the specified resource. By far the most common method used on the Web today. Should not be used for operations that cause side-effects (using it for actions in web applications is a common misuse). See 'safe methods' below.
POST
Submits data to be processed (e.g. from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both.
PUT
Uploads a representation of the specified resource.
DELETE
Deletes the specified resource.
TRACE
Echoes back the received request, so that a client can see what intermediate servers are adding or changing in the request.
OPTIONS
Returns the HTTP methods that the server supports. This can be used to check the functionality of a web server.
CONNECT
Converts the request connection to a transparent TCP/IP tunnel, usually to facilitate SSL-encrypted communication (HTTPS) through an unencrypted HTTP proxy.[1]
HTTP servers are supposed to implement at least the GET and HEAD methods and, whenever possible, also the OPTIONS method.
Safe methods
Some methods (e.g. HEAD or GET) are defined as safe, which means they are intended only for information retrieval and should not change the state of the server (in other words, they should not have side effects). Unsafe methods (such as POST, PUT and DELETE) should be displayed to the user in a special way, typically as buttons rather than links, thus making the user aware of possible obligations (such as a button that causes a financial transaction).
Despite the required safety of GET requests, in practice they can cause changes on the server. For example, a Web server may use the retrieval through a simple hyperlink to initiate deletion of a domain database record, thus causing a change of the server's state as a side-effect of a GET request. This is discouraged, because it can cause problems for Web caching, search engines and other automated agents, which can make unintended changes on the server. Another case is that a GET request may cause the server to create a cache space.
Idempotent methods and Web Applications
Methods GET, HEAD, PUT and DELETE are defined to be idempotent, meaning that multiple identical requests should have the same effect as a single request. Methods OPTIONS and TRACE, being safe, are inherently idempotent.
The RFC allows a user-agent, such as a browser to assume that any idempotent request can be retried without informing the user. This is done to improve the user experience when connecting to unresponsive or heavily-loaded web servers.
However, note that the idempotence is not assured by the protocol or web server. It is perfectly possible to write a web application in which (eg) a database insert or update is triggered by a GET request - this would be a very normal example of what the spec refers to as "a change in server state".
This misuse of GET can combine with the retry behaviour above to produce erroneous transactions - and for this reason GET should be avoided for anything transactional - and used, as intended, for document retrieval only.
HTTP versions
HTTP has evolved into multiple, mostly backwards-compatible protocol versions. RFC 2145 describes the use of HTTP version numbers. The client tells in the beginning of the request the version it uses, and the server uses the same or earlier version in the response.
0.9
Deprecated. Supports only one command, GET — which does not specify the HTTP version. Does not support headers. Since this version does not support POST, the client can't pass much information to the server.
HTTP/1.0 (May 1996)
This is the first protocol revision to specify its version in communications and is still in wide use, especially by proxy servers.
HTTP/1.1 (June 1999)[2][3]
Current version; persistent connections enabled by default and works well with proxies. Also supports request pipelining, allowing multiple requests to be sent at the same time, allowing the server to prepare for the workload and potentially transfer the requested resources more quickly to the client.
HTTP/1.2
The initial 1995 working drafts of the document PEP — an Extension Mechanism for HTTP (which proposed the Protocol Extension Protocol, abbreviated PEP) were prepared by the World Wide Web Consortium and submitted to the Internet Engineering Task Force. PEP was originally intended to become a distinguishing feature of HTTP/1.2.[4] In later PEP working drafts, however, the reference to HTTP/1.2 was removed. The experimental RFC 2774, HTTP Extension Framework, largely subsumed PEP. It was published in February 2000.
Status codes
In HTTP/1.0 and since, the first line of the HTTP response is called the status line and includes a numeric status code (such as "404") and a textual reason phrase (such as "Not Found"). The way the user agent handles the response primarily depends on the code and secondarily on the response headers. Custom status codes can be used since, if the user agent encounters a code it does not recognize, it can use the first digit of the code to determine the general class of the response.[5]
Also, the standard reason phrases are only recommendations and can be replaced with "local equivalents" at the web developer's discretion. If the status code indicated a problem, the user agent might display the reason phrase to the user to provide further information about the nature of the problem. The standard also allows the user agent to attempt to interpret the reason phrase, though this might be unwise since the standard explicitly specifies that status codes are machine-readable and reason phrases are human-readable.
Persistent connections
In HTTP/0.9 and 1.0, the connection is closed after a single request/response pair. In HTTP/1.1 a keep-alive-mechanism was introduced, where a connection could be reused for more than one request.
Such persistent connections reduce lag perceptibly, because the client does not need to re-negotiate the TCP connection after the first request has been sent.
Version 1.1 of the protocol also introduced chunked transfer encoding to allow content on persistent connections to be streamed, rather than buffered, and HTTP pipelining, which allows clients to send some types of requests before the previous response has been received, further reducing lag.
HTTP session state
HTTP can occasionally pose problems for Web developers (Web Applications), because HTTP is stateless. The advantage of a stateless protocol is that hosts do not need to retain information about users between requests, but this forces the use of alternative methods for maintaining users' state, for example, when a host would like to customize content for a user who has visited before. The common method for solving this problem involves the use of sending and requesting cookies. Other methods include server side sessions, hidden variables (when current page is a form), and URL encoded parameters (such as /index.php?userid=3).
Secure HTTP
There are currently two methods of establishing a secure HTTP connection: the https URI scheme and the HTTP 1.1 Upgrade header, introduced by RFC 2817. Browser support for the Upgrade header is, however, nearly non-existent, hence the https URI scheme is still the dominant method of establishing a secure HTTP connection.
https URI scheme
https: is a URI scheme syntactically identical to the http: scheme used for normal HTTP connections, but which signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is especially suited for HTTP since it can provide some protection even if only one side of the communication is authenticated. In the case of HTTP transactions over the Internet, typically, only the server side is authenticated.
HTTP 1.1 Upgrade header
HTTP 1.1 introduced support for the Upgrade header. In the exchange, the client begins by making a clear-text request, which is later upgraded to TLS. Either the client or the server may request (or demand) that the connection be upgraded. The most common usage is a clear-text request by the client followed by a server demand to upgrade the connection, which looks like this:
Client:GET /encrypted-area HTTP/1.1Host: www.example.com
Server:HTTP/1.1 426 Upgrade RequiredUpgrade: TLS/1.0, HTTP/1.1Connection: Upgrade
The server returns a 426 status-code because 400 level codes indicate a client failure (see List of HTTP status codes), which correctly alerts legacy clients that the failure was client-related.
The benefits of using this method for establishing a secure connection are:
that it removes messy and problematic redirection and URL rewriting on the server side,
it allows virtual hosting (single IP, multiple domain-names) of secured websites, and
it reduces user confusion by providing a single way to access a particular resource.
A weakness with this method is that the requirement for secure HTTP cannot be specified in the URI. In practice, the (untrusted) server will thus be responsible for enabling secure HTTP, not the (trusted) client.
Sample
Below is a sample conversation between an HTTP client and an HTTP server running on http://en.wikipedia.org/wiki/Example.com, port 80.
Client request (followed by a blank line, so that request ends with a double newline, each in the form of a carriage return followed by a line feed): GET /index.html HTTP/1.1 Host: www.example.com
The "Host" header distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
Server response (followed by a blank line and text of the requested page): HTTP/1.1 200 OK Date: Mon, 23 May 2005 22:38:34 GMT Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT Etag: "3f80f-1b6-3e1cb03b" Accept-Ranges: bytes Content-Length: 438 Connection: close Content-Type: text/html; charset=UTF-8
The ETag (entity tag) header is used to determine if the URL cached is identical to the requested URL on the server. Content-Type specifies the Internet media type of the data conveyed by the http message, while Content-Length indicates its length in bytes. The webserver publishes its ability to respond to requests for certain byte ranges of the document by setting the header Accept-Ranges: bytes. This is useful if the connection was interrupted before the data was completely transferred to the client.[6] With Connection: close it is stated, that the webserver will close the TCP connection immediately after the transfer of this package.
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol (DHCP) is a protocol used by networked computers (clients) to obtain IP addresses and other parameters such as the default gateway, subnet mask, and IP addresses of DNS servers from a DHCP server. The DHCP server ensures that all IP addresses are unique, e.g., no IP address is assigned to a second client while the first client's assignment is valid (its lease has not expired). Thus IP address pool management is done by the server and not by a human network administrator.
DHCP emerged as a standard protocol in October 1993. DHCP is a successor to the older BOOTP protocol, whose leases were given for infinite time and did not support options. Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP. As of 2006, RFC 2131 (dated March 1997) provides the latest DHCP definition. As of 2004, the latest non-standard of the protocol is RFC 3315 (dated July 2003), which describes DHCPv6 (DHCP in an IPv6 environment).
Overview
The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default gateway, and other IP parameters.[1] When a DHCP-configured machine boots up or regains connectivity after a network outage, its DHCP client sends a query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and also has information about client configuration parameters such as the default gateway, the domain name, the DNS servers, other servers such as time servers, and so forth. The query is typically initiated immediately after booting up and must be completed before the client can initiate IP-based communication with other hosts. The DHCP server replies to the client with an IP address, subnet mask, default gateway, and other requested information such as DNS server, etc.
DHCP provides three modes for allocating IP addresses. The best-known mode is dynamic, in which the client is provided a "lease" on an IP address for a period of time. Depending on the stability of the network, this could range from hours (a wireless network at an airport) to months (for desktops in a wire line lab). At any time before the lease expires, the DHCP client can request renewal of the lease on the current IP address. A properly-functioning client will use the renewal mechanism to maintain the same IP address throughout its connection to a single network. Maintaining the same IP address is important to correct functioning of higher-layer protocols. However, if the lease actually expires, the client must initiate a new negotiation of an IP address from the server's pool of addresses. As part of the negotiation, it can request its expired IP address, but there is no guarantee that it will get it.
The two other modes for allocation of IP addresses are automatic (also known as DHCP Reservation), in which the address is permanently assigned to a client, and manual, in which the address is selected at the client (manually by the user or any other means) and the DHCP protocol messages are used to inform the server that the address has been allocated.
Configuring firewall rules to accommodate access from machines who receive their IP addresses via dynamic DHCP is problematic because the IP address can vary over time. If fine-grained control of access to an IP address is required, the automatic or manual mode should be used for allocating the address.
The negotiation for an address is initiated by a client broadcast. If the DHCP server is not on the local area network and the router is not specially configured, the DHCP server will not receive the broadcast message because routers do not forward broadcasts. However, most routers can be configured as relay agents to forward messages to the DHCP server and to return the server replies to the client. This mode of operation occurs in large organizations using a single DHCP server to supply client configuration to many different networks. Home users should never need this functionality.
Extent of DHCP usage
Most home routers and firewalls are configured in the factory to be DHCP servers for a home network. An alternative to a home router is to use a computer as a DHCP server. Releases of Linux usually include a DHCP server and the Internet Software Consortium provides free DHCP servers and clients that run on a variety of Unix-based systems.
Service providers, as well as large enterprise networks, may link DHCP to a dynamic DNS server, so a given user or access port can be associated with a more human-friendly name using RFC2136 conventions [2]. When DHCP is linked to dynamic DNS, operations staff can ping a name, rather than laboriously look up a dynamically assigned address, to check connectivity.
ISPs cable internet and with broadband access generally use DHCP to assign customers individual IP addresses. Alternatively, especially for dialup, they may assign the address using the IP Control Protocol function in PPP. The PPP server may have a proxy relationship to dynamic DNS.
In the UK many broad-band ISP networks use DHCP, but xDSL providers make extensive use of "infinite lease", which amounts to assigning semi-static IPs.
Gateway devices provide DHCP support for networks running many computers being assigned private IP addresses.
Network administrators that are responsible for large networks involving many clients and many subnetworks also use DHCP to minimize manual configuration and avoid mistakes in configuring multiple clients. For example, most large organizations use DHCP for configuring desktop and laptop computers.
Network routers and often multilayer switches employ a DHCP relay agent, which relays DHCP "Discover" broadcasts from a LAN which does not include a DHCP server to a network which does have one. These devices may sometimes be configured to append information about the port from which a DHCP request originates (also known as option 82). One example of such a relay agent is the UDP Helper Address command employed by Cisco routers.
Security
Since DHCP servers provide IP addresses and thus network connectivity to anyone who has physical network access, DHCP simplifies network intrusion. While seasoned attackers will have no trouble finding usable IP addresses and other settings manually, amateur intruders may be grateful for the service.
If DHCP is used on an unprotected wireless LAN, anyone within range has access to the network, including use of internet connectivity and potentially access to data not otherwise protected. On a wired LAN, an attacker will need a physical connection which is more difficult to establish unnoticed.
When DHCP and DNS are interconnected with Dynamic DNS, there are several methods of cryptographic authentication of the DNS update. Should a miscreant be trying to defeat security on DHCP, there will either be an authentication error if he tries to update DNS, or there will be a DHCP database entry matched by no DNS entry.
IP address allocation
Depending on implementation, the DHCP server has three methods of allocating IP-addresses:
manual allocation, where the DHCP server performs the allocation based on a table with MAC address - IP address pairs manually filled by the server administrator. Only requesting clients with a MAC address listed in this table get the IP address according to the table.
automatic allocation, where the DHCP server permanently assigns to a requesting client a free IP-address from a range given by the administrator.
dynamic allocation, the only method which provides dynamic re-use of IP addresses. A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN has its TCP/IP software configured to request an IP address from the DHCP server when that client computer's network interface card starts up. The request-and-grant process uses a lease concept with a controllable time period. This eases the network installation procedure on the client computer side considerably.
This decision remains transparent to clients.
Some DHCP server implementations can update the DNS name associated with the client hosts to reflect the new IP address. They make use of the DNS update protocol established with RFC 2136.
DHCP and firewalls
Firewalls usually have to permit DHCP traffic explicitly. Specification of the DHCP client-server protocol describes several cases when packets must have the source address of 0x00000000 or the destination address of 0xffffffff. Anti-spoofing policy rules and tight inclusive firewalls often stop such packets. Multi-homed DHCP servers require special consideration and further complicate configuration.
To allow DHCP, network administrators need to allow several types of packets through the server-side firewall. All DHCP packets travel as UDP datagrams; all client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68. For example, a server-side firewall should allow the following types of packets:
Incoming packets from 0.0.0.0 or dhcp-pool to dhcp-ip
Incoming packets from any address to 255.255.255.255
Outgoing packets from dhcp-ip to dhcp-pool or 255.255.255.255
where dhcp-ip represents any address configured on a DHCP server host and dhcp-pool stands for the pool from which a DHCP server assigns addresses to clients
Example in ipfw firewall
To give an idea of how a configuration would look in production, the following rules for a server-side ipfirewall to allow DHCP traffic through. Dhcpd operates on interface rl0 and assigns addresses from 192.168.0.0/24 :pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0pass udp from any 68 to 255.255.255.255 67 in recv rl0pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0
Example in Cisco IOS Extended ACL
The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The ACL is applied to a routed interface, 10.32.73.129, on input. The subnet is 10.32.73.128/26.10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps30 permit udp any eq bootpc host 255.255.255.255 eq bootps
Technical details
Schema of a typical DHCP session
DHCP uses the same two IANA assigned ports as BOOTP: 67/udp for the server side, and 68/udp for the client side.
DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement.
After the client obtained an IP address, the client may start an address resolution query to prevent IP conflicts caused by address poll overlapping of DHCP servers.
DHCP discovery
The client broadcasts on the physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a UDP packet with the broadcast destination of 255.255.255.255 or subnet broadcast address.
A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation dependent time out for the client to give up on the request and ask for a new IP.
DHCP offers
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
DHCP requests
When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card.
DHCP acknowledgement
When the DHCP server receives the DHCPREQUEST message from the client, it initiates the final phase of the configuration process. This acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the TCP/IP configuration process is complete.
The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options.
DHCP information
The client sends a request to the DHCP server: either to request more information than the server sent with the original DHCPACK; or to repeat data for a particular application - for example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
DHCP releasing
The client sends a request to the DHCP server to release the DHCP and the client unconfigures its IP address. As clients usually do not know when users may unplug them from the network, the protocol does not define the sending of DHCP Release as mandatory.
DHCP emerged as a standard protocol in October 1993. DHCP is a successor to the older BOOTP protocol, whose leases were given for infinite time and did not support options. Due to the backward-compatibility of DHCP, very few networks continue to use pure BOOTP. As of 2006, RFC 2131 (dated March 1997) provides the latest DHCP definition. As of 2004, the latest non-standard of the protocol is RFC 3315 (dated July 2003), which describes DHCPv6 (DHCP in an IPv6 environment).
Overview
The Dynamic Host Configuration Protocol (DHCP) automates the assignment of IP addresses, subnet masks, default gateway, and other IP parameters.[1] When a DHCP-configured machine boots up or regains connectivity after a network outage, its DHCP client sends a query requesting necessary information from a DHCP server. The DHCP server manages a pool of IP addresses and also has information about client configuration parameters such as the default gateway, the domain name, the DNS servers, other servers such as time servers, and so forth. The query is typically initiated immediately after booting up and must be completed before the client can initiate IP-based communication with other hosts. The DHCP server replies to the client with an IP address, subnet mask, default gateway, and other requested information such as DNS server, etc.
DHCP provides three modes for allocating IP addresses. The best-known mode is dynamic, in which the client is provided a "lease" on an IP address for a period of time. Depending on the stability of the network, this could range from hours (a wireless network at an airport) to months (for desktops in a wire line lab). At any time before the lease expires, the DHCP client can request renewal of the lease on the current IP address. A properly-functioning client will use the renewal mechanism to maintain the same IP address throughout its connection to a single network. Maintaining the same IP address is important to correct functioning of higher-layer protocols. However, if the lease actually expires, the client must initiate a new negotiation of an IP address from the server's pool of addresses. As part of the negotiation, it can request its expired IP address, but there is no guarantee that it will get it.
The two other modes for allocation of IP addresses are automatic (also known as DHCP Reservation), in which the address is permanently assigned to a client, and manual, in which the address is selected at the client (manually by the user or any other means) and the DHCP protocol messages are used to inform the server that the address has been allocated.
Configuring firewall rules to accommodate access from machines who receive their IP addresses via dynamic DHCP is problematic because the IP address can vary over time. If fine-grained control of access to an IP address is required, the automatic or manual mode should be used for allocating the address.
The negotiation for an address is initiated by a client broadcast. If the DHCP server is not on the local area network and the router is not specially configured, the DHCP server will not receive the broadcast message because routers do not forward broadcasts. However, most routers can be configured as relay agents to forward messages to the DHCP server and to return the server replies to the client. This mode of operation occurs in large organizations using a single DHCP server to supply client configuration to many different networks. Home users should never need this functionality.
Extent of DHCP usage
Most home routers and firewalls are configured in the factory to be DHCP servers for a home network. An alternative to a home router is to use a computer as a DHCP server. Releases of Linux usually include a DHCP server and the Internet Software Consortium provides free DHCP servers and clients that run on a variety of Unix-based systems.
Service providers, as well as large enterprise networks, may link DHCP to a dynamic DNS server, so a given user or access port can be associated with a more human-friendly name using RFC2136 conventions [2]. When DHCP is linked to dynamic DNS, operations staff can ping a name, rather than laboriously look up a dynamically assigned address, to check connectivity.
ISPs cable internet and with broadband access generally use DHCP to assign customers individual IP addresses. Alternatively, especially for dialup, they may assign the address using the IP Control Protocol function in PPP. The PPP server may have a proxy relationship to dynamic DNS.
In the UK many broad-band ISP networks use DHCP, but xDSL providers make extensive use of "infinite lease", which amounts to assigning semi-static IPs.
Gateway devices provide DHCP support for networks running many computers being assigned private IP addresses.
Network administrators that are responsible for large networks involving many clients and many subnetworks also use DHCP to minimize manual configuration and avoid mistakes in configuring multiple clients. For example, most large organizations use DHCP for configuring desktop and laptop computers.
Network routers and often multilayer switches employ a DHCP relay agent, which relays DHCP "Discover" broadcasts from a LAN which does not include a DHCP server to a network which does have one. These devices may sometimes be configured to append information about the port from which a DHCP request originates (also known as option 82). One example of such a relay agent is the UDP Helper Address command employed by Cisco routers.
Security
Since DHCP servers provide IP addresses and thus network connectivity to anyone who has physical network access, DHCP simplifies network intrusion. While seasoned attackers will have no trouble finding usable IP addresses and other settings manually, amateur intruders may be grateful for the service.
If DHCP is used on an unprotected wireless LAN, anyone within range has access to the network, including use of internet connectivity and potentially access to data not otherwise protected. On a wired LAN, an attacker will need a physical connection which is more difficult to establish unnoticed.
When DHCP and DNS are interconnected with Dynamic DNS, there are several methods of cryptographic authentication of the DNS update. Should a miscreant be trying to defeat security on DHCP, there will either be an authentication error if he tries to update DNS, or there will be a DHCP database entry matched by no DNS entry.
IP address allocation
Depending on implementation, the DHCP server has three methods of allocating IP-addresses:
manual allocation, where the DHCP server performs the allocation based on a table with MAC address - IP address pairs manually filled by the server administrator. Only requesting clients with a MAC address listed in this table get the IP address according to the table.
automatic allocation, where the DHCP server permanently assigns to a requesting client a free IP-address from a range given by the administrator.
dynamic allocation, the only method which provides dynamic re-use of IP addresses. A network administrator assigns a range of IP addresses to DHCP, and each client computer on the LAN has its TCP/IP software configured to request an IP address from the DHCP server when that client computer's network interface card starts up. The request-and-grant process uses a lease concept with a controllable time period. This eases the network installation procedure on the client computer side considerably.
This decision remains transparent to clients.
Some DHCP server implementations can update the DNS name associated with the client hosts to reflect the new IP address. They make use of the DNS update protocol established with RFC 2136.
DHCP and firewalls
Firewalls usually have to permit DHCP traffic explicitly. Specification of the DHCP client-server protocol describes several cases when packets must have the source address of 0x00000000 or the destination address of 0xffffffff. Anti-spoofing policy rules and tight inclusive firewalls often stop such packets. Multi-homed DHCP servers require special consideration and further complicate configuration.
To allow DHCP, network administrators need to allow several types of packets through the server-side firewall. All DHCP packets travel as UDP datagrams; all client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68. For example, a server-side firewall should allow the following types of packets:
Incoming packets from 0.0.0.0 or dhcp-pool to dhcp-ip
Incoming packets from any address to 255.255.255.255
Outgoing packets from dhcp-ip to dhcp-pool or 255.255.255.255
where dhcp-ip represents any address configured on a DHCP server host and dhcp-pool stands for the pool from which a DHCP server assigns addresses to clients
Example in ipfw firewall
To give an idea of how a configuration would look in production, the following rules for a server-side ipfirewall to allow DHCP traffic through. Dhcpd operates on interface rl0 and assigns addresses from 192.168.0.0/24 :pass udp from 0.0.0.0,192.168.0.0/24 68 to me 67 in recv rl0pass udp from any 68 to 255.255.255.255 67 in recv rl0pass udp from me 67 to 192.168.0.0/24,255.255.255.255 68 out xmit rl0
Example in Cisco IOS Extended ACL
The following entries are valid on a Cisco 3560 switch with enabled DHCP service. The ACL is applied to a routed interface, 10.32.73.129, on input. The subnet is 10.32.73.128/26.10 permit udp host 0.0.0.0 eq bootpc host 10.32.73.129 eq bootps20 permit udp 10.32.73.128 0.0.0.63 eq bootpc host 10.32.73.129 eq bootps30 permit udp any eq bootpc host 255.255.255.255 eq bootps
Technical details
Schema of a typical DHCP session
DHCP uses the same two IANA assigned ports as BOOTP: 67/udp for the server side, and 68/udp for the client side.
DHCP operations fall into four basic phases. These phases are IP lease request, IP lease offer, IP lease selection, and IP lease acknowledgement.
After the client obtained an IP address, the client may start an address resolution query to prevent IP conflicts caused by address poll overlapping of DHCP servers.
DHCP discovery
The client broadcasts on the physical subnet to find available servers. Network administrators can configure a local router to forward DHCP packets to a DHCP server on a different subnet. This client-implementation creates a UDP packet with the broadcast destination of 255.255.255.255 or subnet broadcast address.
A client can also request its last-known IP address (in the example below, 192.168.1.100). If the client is still in a network where this IP is valid, the server might grant the request. Otherwise, it depends whether the server is set up as authoritative or not. An authoritative server will deny the request, making the client ask for a new IP immediately. A non-authoritative server simply ignores the request, leading to an implementation dependent time out for the client to give up on the request and ask for a new IP.
DHCP offers
When a DHCP server receives an IP lease request from a client, it extends an IP lease offer. This is done by reserving an IP address for the client and sending a DHCPOFFER message across the network to the client. This message contains the client's MAC address, followed by the IP address that the server is offering, the subnet mask, the lease duration, and the IP address of the DHCP server making the offer.
The server determines the configuration, based on the client's hardware address as specified in the CHADDR field. Here the server, 192.168.1.1, specifies the IP address in the YIADDR field.
DHCP requests
When the client PC receives an IP lease offer, it must tell all the other DHCP servers that it has accepted an offer. To do this, the client broadcasts a DHCPREQUEST message containing the IP address of the server that made the offer. When the other DHCP servers receive this message, they withdraw any offers that they might have made to the client. They then return the address that they had reserved for the client back to the pool of valid addresses that they can offer to another computer. Any number of DHCP servers can respond to an IP lease request, but the client can only accept one offer per network interface card.
DHCP acknowledgement
When the DHCP server receives the DHCPREQUEST message from the client, it initiates the final phase of the configuration process. This acknowledgement phase involves sending a DHCPACK packet to the client. This packet includes the lease duration and any other configuration information that the client might have requested. At this point, the TCP/IP configuration process is complete.
The server acknowledges the request and sends the acknowledgement to the client. The system as a whole expects the client to configure its network interface with the supplied options.
DHCP information
The client sends a request to the DHCP server: either to request more information than the server sent with the original DHCPACK; or to repeat data for a particular application - for example, browsers use DHCP Inform to obtain web proxy settings via WPAD. Such queries do not cause the DHCP server to refresh the IP expiry time in its database.
DHCP releasing
The client sends a request to the DHCP server to release the DHCP and the client unconfigures its IP address. As clients usually do not know when users may unplug them from the network, the protocol does not define the sending of DHCP Release as mandatory.
Hardware TCP implementations
One way to overcome the processing power requirements of TCP is building hardware implementations of it, widely known as TCP Offload Engines (TOE). The main problem of TOEs is that they are hard to integrate into computing systems, requiring extensive changes in the operating system of the computer or device. The first company to develop such a device was Alacritech.
Debugging TCP
A packet sniffer, which intercepts TCP traffic on a network link, can be useful in debugging networks, network stacks and applications which use TCP by showing the user what packets are passing through a link. Some networking stacks support the SO_DEBUG socket option, which can be enabled on the socket using setsockopt. That option dumps all the packets, TCP states and events on that socket which will be helpful in debugging. netstat is another utility that can be used for debugging.
Alternatives to TCP
For many applications TCP is not appropriate. One big problem (at least with normal implementations) is that the application cannot get at the packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications such as streaming multimedia (such as Internet radio), real-time multiplayer games and voice over IP (VoIP) where it is sometimes more useful to get most of the data in a timely fashion than it is to get all of the data in order.
Also for embedded systems, network booting and servers that serve simple requests from huge numbers of clients (e.g. DNS servers) the complexity of TCP can be a problem. Finally some tricks such as transmitting data between two hosts that are both behind NAT (using STUN or similar systems) are far simpler without a relatively complex protocol like TCP in the way.
Generally where TCP is unsuitable the User Datagram Protocol (UDP) is used. This provides the application multiplexing and checksums that TCP does, but does not handle building streams or retransmission giving the application developer the ability to code those in a way suitable for the situation and/or to replace them with other methods like forward error correction or interpolation.
SCTP is another IP protocol that provides reliable stream oriented services not so dissimilar from TCP. It is newer and considerably more complex than TCP so has not yet seen widespread deployment, however it is especially designed to be used in situations where reliability and near-real-time considerations are important.
Venturi Transport Protocol (VTP) is a patented proprietary protocol that is designed to replace TCP transparently in order to overcome perceived inefficiencies related to wireless data transport.
TCP also has some issues in high bandwidth utilization environments. The TCP congestion avoidance algorithm works very well for ad-hoc environments where it is not known who will be sending data, but if the environment is predictable, a timing based protocol such as ATM can avoid the overhead of the retransmits that TCP needs.
TCP segment structure
A TCP segment consists of two sections:
header
data
The header consists of 11 fields, of which only 10 are required. The eleventh field is optional (pink background in table) and aptly named: options.
TCP Header
Source port – identifies the sending port
Destination port – identifies the receiving port
Sequence number – has a dual role
If the SYN flag is present then this is the initial sequence number and the first data byte is the sequence number plus 1
if the SYN flag is not present then the first data byte is the sequence number
Acknowledgment number – if the ACK flag is set then the value of this field is the sequence number that the sender of the acknowledgment expects next.
Data offset – specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes. This field gets its name from the fact that it is also the offset from the start of the TCP packet to the data.
Reserved – for future use and should be set to zero
Flags (aka Control bits) – contains 8 bit flags
CWR – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set (added to header by RFC 3168).
ECE (ECN-Echo) – indicate that the TCP peer is ECN capable during 3-way handshake (added to header by RFC 3168).
URG – indicates that the URGent pointer field is significant
ACK – indicates that the ACKnowledgment field is significant
PSH – Push function
RST – Reset the connection
SYN – Synchronize sequence numbers
FIN – No more data from sender
Window – the number of bytes that may be received on the receiving side before being halted from sliding any further and receiving any more bytes as a result of a packet at the beginning of the sliding window not having been acknowledged or received. Starts at acknowledgement field.
Checksum – The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer – if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
Options – the total length of the option field must be a multiple of a 32-bit word and the data offset field adjusted appropriately
Fields used to compute the checksum
TCP checksum using IPv4
When TCP runs over IPv4, the method used to compute the checksum is defined in RFC 793:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.
In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented. This final value is then inserted as the checksum field. Algorithmically speaking, this is the same as for IPv6. The difference is in the data used to make the checksum. When computing the checksum, a pseudo-header that mimics the IPv4 header is shown in the table below.
The source and destination addresses are those in the IPv4 header. The protocol is that for TCP (see List of IPv4 protocol numbers): 6. The TCP length field is the length of the TCP header and data.
TCP checksum using IPv6
When TCP runs over IPv6, the method used to compute the checksum is changed, as per RFC 2460:
Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.
Source address – the one in the IPv6 header
Destination address – the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header, otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header.
TCP length – the length of the TCP header and data;
Next Header – the protocol value for TCP
Data
The last field is not a part of the header. The contents of this field are whatever the upper layer protocol wants but this protocol is not set in the header and is presumed based on the port selection.
Debugging TCP
A packet sniffer, which intercepts TCP traffic on a network link, can be useful in debugging networks, network stacks and applications which use TCP by showing the user what packets are passing through a link. Some networking stacks support the SO_DEBUG socket option, which can be enabled on the socket using setsockopt. That option dumps all the packets, TCP states and events on that socket which will be helpful in debugging. netstat is another utility that can be used for debugging.
Alternatives to TCP
For many applications TCP is not appropriate. One big problem (at least with normal implementations) is that the application cannot get at the packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications such as streaming multimedia (such as Internet radio), real-time multiplayer games and voice over IP (VoIP) where it is sometimes more useful to get most of the data in a timely fashion than it is to get all of the data in order.
Also for embedded systems, network booting and servers that serve simple requests from huge numbers of clients (e.g. DNS servers) the complexity of TCP can be a problem. Finally some tricks such as transmitting data between two hosts that are both behind NAT (using STUN or similar systems) are far simpler without a relatively complex protocol like TCP in the way.
Generally where TCP is unsuitable the User Datagram Protocol (UDP) is used. This provides the application multiplexing and checksums that TCP does, but does not handle building streams or retransmission giving the application developer the ability to code those in a way suitable for the situation and/or to replace them with other methods like forward error correction or interpolation.
SCTP is another IP protocol that provides reliable stream oriented services not so dissimilar from TCP. It is newer and considerably more complex than TCP so has not yet seen widespread deployment, however it is especially designed to be used in situations where reliability and near-real-time considerations are important.
Venturi Transport Protocol (VTP) is a patented proprietary protocol that is designed to replace TCP transparently in order to overcome perceived inefficiencies related to wireless data transport.
TCP also has some issues in high bandwidth utilization environments. The TCP congestion avoidance algorithm works very well for ad-hoc environments where it is not known who will be sending data, but if the environment is predictable, a timing based protocol such as ATM can avoid the overhead of the retransmits that TCP needs.
TCP segment structure
A TCP segment consists of two sections:
header
data
The header consists of 11 fields, of which only 10 are required. The eleventh field is optional (pink background in table) and aptly named: options.
TCP Header
Source port – identifies the sending port
Destination port – identifies the receiving port
Sequence number – has a dual role
If the SYN flag is present then this is the initial sequence number and the first data byte is the sequence number plus 1
if the SYN flag is not present then the first data byte is the sequence number
Acknowledgment number – if the ACK flag is set then the value of this field is the sequence number that the sender of the acknowledgment expects next.
Data offset – specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes. This field gets its name from the fact that it is also the offset from the start of the TCP packet to the data.
Reserved – for future use and should be set to zero
Flags (aka Control bits) – contains 8 bit flags
CWR – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set (added to header by RFC 3168).
ECE (ECN-Echo) – indicate that the TCP peer is ECN capable during 3-way handshake (added to header by RFC 3168).
URG – indicates that the URGent pointer field is significant
ACK – indicates that the ACKnowledgment field is significant
PSH – Push function
RST – Reset the connection
SYN – Synchronize sequence numbers
FIN – No more data from sender
Window – the number of bytes that may be received on the receiving side before being halted from sliding any further and receiving any more bytes as a result of a packet at the beginning of the sliding window not having been acknowledged or received. Starts at acknowledgement field.
Checksum – The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer – if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
Options – the total length of the option field must be a multiple of a 32-bit word and the data offset field adjusted appropriately
Fields used to compute the checksum
TCP checksum using IPv4
When TCP runs over IPv4, the method used to compute the checksum is defined in RFC 793:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.
In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented. This final value is then inserted as the checksum field. Algorithmically speaking, this is the same as for IPv6. The difference is in the data used to make the checksum. When computing the checksum, a pseudo-header that mimics the IPv4 header is shown in the table below.
The source and destination addresses are those in the IPv4 header. The protocol is that for TCP (see List of IPv4 protocol numbers): 6. The TCP length field is the length of the TCP header and data.
TCP checksum using IPv6
When TCP runs over IPv6, the method used to compute the checksum is changed, as per RFC 2460:
Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.
Source address – the one in the IPv6 header
Destination address – the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header, otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header.
TCP length – the length of the TCP header and data;
Next Header – the protocol value for TCP
Data
The last field is not a part of the header. The contents of this field are whatever the upper layer protocol wants but this protocol is not set in the header and is presumed based on the port selection.
Hardware TCP implementations
One way to overcome the processing power requirements of TCP is building hardware implementations of it, widely known as TCP Offload Engines (TOE). The main problem of TOEs is that they are hard to integrate into computing systems, requiring extensive changes in the operating system of the computer or device. The first company to develop such a device was Alacritech.
Debugging TCP
A packet sniffer, which intercepts TCP traffic on a network link, can be useful in debugging networks, network stacks and applications which use TCP by showing the user what packets are passing through a link. Some networking stacks support the SO_DEBUG socket option, which can be enabled on the socket using setsockopt. That option dumps all the packets, TCP states and events on that socket which will be helpful in debugging. netstat is another utility that can be used for debugging.
Alternatives to TCP
For many applications TCP is not appropriate. One big problem (at least with normal implementations) is that the application cannot get at the packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications such as streaming multimedia (such as Internet radio), real-time multiplayer games and voice over IP (VoIP) where it is sometimes more useful to get most of the data in a timely fashion than it is to get all of the data in order.
Also for embedded systems, network booting and servers that serve simple requests from huge numbers of clients (e.g. DNS servers) the complexity of TCP can be a problem. Finally some tricks such as transmitting data between two hosts that are both behind NAT (using STUN or similar systems) are far simpler without a relatively complex protocol like TCP in the way.
Generally where TCP is unsuitable the User Datagram Protocol (UDP) is used. This provides the application multiplexing and checksums that TCP does, but does not handle building streams or retransmission giving the application developer the ability to code those in a way suitable for the situation and/or to replace them with other methods like forward error correction or interpolation.
SCTP is another IP protocol that provides reliable stream oriented services not so dissimilar from TCP. It is newer and considerably more complex than TCP so has not yet seen widespread deployment, however it is especially designed to be used in situations where reliability and near-real-time considerations are important.
Venturi Transport Protocol (VTP) is a patented proprietary protocol that is designed to replace TCP transparently in order to overcome perceived inefficiencies related to wireless data transport.
TCP also has some issues in high bandwidth utilization environments. The TCP congestion avoidance algorithm works very well for ad-hoc environments where it is not known who will be sending data, but if the environment is predictable, a timing based protocol such as ATM can avoid the overhead of the retransmits that TCP needs.
TCP segment structure
A TCP segment consists of two sections:
header
data
The header consists of 11 fields, of which only 10 are required. The eleventh field is optional (pink background in table) and aptly named: options.
TCP Header
Source port – identifies the sending port
Destination port – identifies the receiving port
Sequence number – has a dual role
If the SYN flag is present then this is the initial sequence number and the first data byte is the sequence number plus 1
if the SYN flag is not present then the first data byte is the sequence number
Acknowledgment number – if the ACK flag is set then the value of this field is the sequence number that the sender of the acknowledgment expects next.
Data offset – specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes. This field gets its name from the fact that it is also the offset from the start of the TCP packet to the data.
Reserved – for future use and should be set to zero
Flags (aka Control bits) – contains 8 bit flags
CWR – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set (added to header by RFC 3168).
ECE (ECN-Echo) – indicate that the TCP peer is ECN capable during 3-way handshake (added to header by RFC 3168).
URG – indicates that the URGent pointer field is significant
ACK – indicates that the ACKnowledgment field is significant
PSH – Push function
RST – Reset the connection
SYN – Synchronize sequence numbers
FIN – No more data from sender
Window – the number of bytes that may be received on the receiving side before being halted from sliding any further and receiving any more bytes as a result of a packet at the beginning of the sliding window not having been acknowledged or received. Starts at acknowledgement field.
Checksum – The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer – if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
Options – the total length of the option field must be a multiple of a 32-bit word and the data offset field adjusted appropriately
Fields used to compute the checksum
TCP checksum using IPv4
When TCP runs over IPv4, the method used to compute the checksum is defined in RFC 793:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.
In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented. This final value is then inserted as the checksum field. Algorithmically speaking, this is the same as for IPv6. The difference is in the data used to make the checksum. When computing the checksum, a pseudo-header that mimics the IPv4 header is shown in the table below.
The source and destination addresses are those in the IPv4 header. The protocol is that for TCP (see List of IPv4 protocol numbers): 6. The TCP length field is the length of the TCP header and data.
TCP checksum using IPv6
When TCP runs over IPv6, the method used to compute the checksum is changed, as per RFC 2460:
Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.
Source address – the one in the IPv6 header
Destination address – the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header, otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header.
TCP length – the length of the TCP header and data;
Next Header – the protocol value for TCP
Data
The last field is not a part of the header. The contents of this field are whatever the upper layer protocol wants but this protocol is not set in the header and is presumed based on the port selection.
Debugging TCP
A packet sniffer, which intercepts TCP traffic on a network link, can be useful in debugging networks, network stacks and applications which use TCP by showing the user what packets are passing through a link. Some networking stacks support the SO_DEBUG socket option, which can be enabled on the socket using setsockopt. That option dumps all the packets, TCP states and events on that socket which will be helpful in debugging. netstat is another utility that can be used for debugging.
Alternatives to TCP
For many applications TCP is not appropriate. One big problem (at least with normal implementations) is that the application cannot get at the packets coming after a lost packet until the retransmitted copy of the lost packet is received. This causes problems for real-time applications such as streaming multimedia (such as Internet radio), real-time multiplayer games and voice over IP (VoIP) where it is sometimes more useful to get most of the data in a timely fashion than it is to get all of the data in order.
Also for embedded systems, network booting and servers that serve simple requests from huge numbers of clients (e.g. DNS servers) the complexity of TCP can be a problem. Finally some tricks such as transmitting data between two hosts that are both behind NAT (using STUN or similar systems) are far simpler without a relatively complex protocol like TCP in the way.
Generally where TCP is unsuitable the User Datagram Protocol (UDP) is used. This provides the application multiplexing and checksums that TCP does, but does not handle building streams or retransmission giving the application developer the ability to code those in a way suitable for the situation and/or to replace them with other methods like forward error correction or interpolation.
SCTP is another IP protocol that provides reliable stream oriented services not so dissimilar from TCP. It is newer and considerably more complex than TCP so has not yet seen widespread deployment, however it is especially designed to be used in situations where reliability and near-real-time considerations are important.
Venturi Transport Protocol (VTP) is a patented proprietary protocol that is designed to replace TCP transparently in order to overcome perceived inefficiencies related to wireless data transport.
TCP also has some issues in high bandwidth utilization environments. The TCP congestion avoidance algorithm works very well for ad-hoc environments where it is not known who will be sending data, but if the environment is predictable, a timing based protocol such as ATM can avoid the overhead of the retransmits that TCP needs.
TCP segment structure
A TCP segment consists of two sections:
header
data
The header consists of 11 fields, of which only 10 are required. The eleventh field is optional (pink background in table) and aptly named: options.
TCP Header
Source port – identifies the sending port
Destination port – identifies the receiving port
Sequence number – has a dual role
If the SYN flag is present then this is the initial sequence number and the first data byte is the sequence number plus 1
if the SYN flag is not present then the first data byte is the sequence number
Acknowledgment number – if the ACK flag is set then the value of this field is the sequence number that the sender of the acknowledgment expects next.
Data offset – specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes. This field gets its name from the fact that it is also the offset from the start of the TCP packet to the data.
Reserved – for future use and should be set to zero
Flags (aka Control bits) – contains 8 bit flags
CWR – Congestion Window Reduced (CWR) flag is set by the sending host to indicate that it received a TCP segment with the ECE flag set (added to header by RFC 3168).
ECE (ECN-Echo) – indicate that the TCP peer is ECN capable during 3-way handshake (added to header by RFC 3168).
URG – indicates that the URGent pointer field is significant
ACK – indicates that the ACKnowledgment field is significant
PSH – Push function
RST – Reset the connection
SYN – Synchronize sequence numbers
FIN – No more data from sender
Window – the number of bytes that may be received on the receiving side before being halted from sliding any further and receiving any more bytes as a result of a packet at the beginning of the sliding window not having been acknowledged or received. Starts at acknowledgement field.
Checksum – The 16-bit checksum field is used for error-checking of the header and data
Urgent pointer – if the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte
Options – the total length of the option field must be a multiple of a 32-bit word and the data offset field adjusted appropriately
Fields used to compute the checksum
TCP checksum using IPv4
When TCP runs over IPv4, the method used to compute the checksum is defined in RFC 793:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16-bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is replaced with zeros.
In other words, all 16-bit words are summed together using one's complement (with the checksum field set to zero). The sum is then one's complemented. This final value is then inserted as the checksum field. Algorithmically speaking, this is the same as for IPv6. The difference is in the data used to make the checksum. When computing the checksum, a pseudo-header that mimics the IPv4 header is shown in the table below.
The source and destination addresses are those in the IPv4 header. The protocol is that for TCP (see List of IPv4 protocol numbers): 6. The TCP length field is the length of the TCP header and data.
TCP checksum using IPv6
When TCP runs over IPv6, the method used to compute the checksum is changed, as per RFC 2460:
Any transport or other upper-layer protocol that includes the addresses from the IP header in its checksum computation must be modified for use over IPv6, to include the 128-bit IPv6 addresses instead of 32-bit IPv4 addresses.
Source address – the one in the IPv6 header
Destination address – the final destination; if the IPv6 packet doesn't contain a Routing header, that will be the destination address in the IPv6 header, otherwise, at the originating node, it will be the address in the last element of the Routing header, and, at the receiving node, it will be the destination address in the IPv6 header.
TCP length – the length of the TCP header and data;
Next Header – the protocol value for TCP
Data
The last field is not a part of the header. The contents of this field are whatever the upper layer protocol wants but this protocol is not set in the header and is presumed based on the port selection.
Error-free data transfer
Sequence numbers and acknowledgments cover discarding duplicate packets, retransmission of lost packets, and ordered-data transfer. To assure correctness a checksum field is included (see TCP segment structure for details on checksumming).
The TCP checksum is a quite weak check by modern standards. Data Link Layers with a high probability of bit error rates may require additional link error correction/detection capabilities. If TCP were to be redesigned today, it would most probably have a 32-bit cyclic redundancy check specified as an error check instead of the current checksum. The weak checksum is partially compensated for by the common use of a CRC or better integrity check at layer 2, below both TCP and IP, such as is used in PPP or the Ethernet frame. However, this does not mean that the 16-bit TCP checksum is redundant: remarkably, surveys of Internet traffic have shown that software and hardware errors that introduce errors in packets between CRC-protected hops are common, and that the end-to-end 16-bit TCP checksum catches most of these simple errors. This is the end-to-end principle at work.
Congestion control
The final part to TCP is congestion control. TCP uses a number of mechanisms to achieve high performance and avoid 'congestion collapse', where network performance can fall by several orders of magnitude. These mechanisms control the rate of data entering the network, keeping the data flow below a rate that would trigger collapse.
Acknowledgments for data sent, or lack of acknowledgments, are used by senders to implicitly interpret network conditions between the TCP sender and receiver. Coupled with timers, TCP senders and receivers can alter the behavior of the flow of data. This is more generally referred to as flow control, congestion control and/or network congestion avoidance.
Modern implementations of TCP contain four intertwined algorithms: Slow-start, congestion avoidance, fast retransmit, and fast recovery (RFC2581).
Enhancing TCP to reliably handle loss, minimize errors, manage congestion and go fast in very high-speed environments are ongoing areas of research and standards development.
TCP window size
TCP sequence numbers and windows behave very much like a clock. The window, whose width (in bytes) is defined by the receiving host, shifts each time it receives and acks a segment of data. Once it runs out of sequence numbers, it loops back to 0.
The TCP receive window size is the amount of received data (in bytes) that can be buffered during a connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host. When a receiver advertises the window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from the dead lock situation. The dead lock situation could be when the new window size update from the receiver is lost and the receiver has no more data to send while the sender is waiting for the new window size update. When the persist timer expires the TCP sender sends a small packet so that the receivers ACKs the packet with the new window size and TCP can recover from such situations.
Window scaling
For more efficient use of high bandwidth networks, a larger TCP window size may be used. The TCP window size field controls the flow of data and is limited to between 2 and 65,535 bytes.
Since the size field cannot be expanded, a scaling factor is used. The TCP window scale option, as defined in RFC 1323, is an option used to increase the maximum window size from 65,535 bytes to 1 Gigabyte. Scaling up to larger window sizes is a part of what is necessary for TCP Tuning.
The window scale option is used only during the TCP 3-way handshake. The window scale value represents the number of bits to left-shift the 16-bit window size field. The window scale value can be set from 0 (no shift) to 14.
Many routers and packet firewalls rewrite the window scaling factor during a transmission. This causes sending and receiving sides to assume different TCP window sizes. The result is non-stable traffic that is very slow. The problem is visible on some sending and receiving sites which are behind the path of broken routers.
For more information on problems that may be caused, especially with Linux and Vista systems, please see main topic TCP window scale option.
Connection termination
The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear down requires a pair of FIN and ACK segments from each TCP endpoint.
A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can.
It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method.
It is possible for both hosts to send FINs simultaneously then both just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done in parallel for both directions.
Some host TCP stacks may implement a "half-duplex" close sequence, as Linux or HP-UX do. If such a host actively closes a connection but still has not read all the incoming data the stack already received from the link, this host will send a RST instead of a FIN (Section 4.2.2.13 in RFC 1122). This allows a TCP application to be sure that the remote application has read all the data the former sent - waiting the FIN from the remote side when it will actively close the connection. Unfortunatelly, the remote TCP stack cannot distinguish between a Connection Aborting RST and this Data Loss RST - both will make the remote stack to throw away all the data it received, but the application still didn't read.
Some application protocols may violate the OSI model layers, using the TCP open/close handshaking for the application protocol open/close handshaking - these may find the RST problem on active close. As an example:s = connect(remote);send(s, data);close(s);
For a usual program flow like above, a TCP/IP stack like that described above does not guarantee that all the data will arrive to the other application unless the programmer is sure that the remote side will not send anything.
TCP ports
TCP uses the notion of port numbers to identify sending and receiving application end-points on a host, or Internet sockets. Each side of a TCP connection has an associated 16-bit unsigned port number (1-65535) reserved by the sending or receiving application. Arriving TCP data packets are identified as belonging to a specific TCP connection by its sockets, that is, the combination of source host address, source port, destination host address, and destination port. This means that a server computer can provide several clients with several services simultaneously, as long as a client takes care of initiating any simultaneous connections to one destination port from different source ports.
Port numbers are categorized into three basic categories: well-known, registered, and dynamic/private. The well-known ports are assigned by the Internet Assigned Numbers Authority (IANA) and are typically used by system-level or root processes. Well-known applications running as servers and passively listening for connections typically use these ports. Some examples include: FTP (21), ssh (22), TELNET (23), SMTP (25) and HTTP (80). Registered ports are typically used by end user applications as ephemeral source ports when contacting servers, but they can also identify named services that have been registered by a third party. Dynamic/private ports can also be used by end user applications, but are less commonly so. Dynamic/private ports do not contain any meaning outside of any particular TCP connection.
Development of TCP
TCP is a complex and evolving protocol. However, while significant enhancements have been made and proposed over the years, its most basic operation has not changed significantly since its first specification RFC 675 in 1974, and the v4 specification RFC 793, published in September 1981.[1] RFC 1122, Host Requirements for Internet Hosts, clarified a number of TCP protocol implementation requirements. RFC 2581, TCP Congestion Control, one of the most important TCP related RFCs in recent years, describes updated algorithms to be used in order to avoid undue congestion. In 2001, RFC 3168 was written to describe explicit congestion notification (ECN), a congestion avoidance signalling mechanism. Common applications that use TCP include HTTP (World Wide Web), SMTP (e-mail) and FTP (file transfer).
The original TCP congestion control was called TCP Tahoe, several alternative congestion control algorithms have been proposed:
BIC TCP by Lisong Xu, Khaled Harfoush, and Injong Rhee at North Carolina State University
Compound TCP by K. Tan, J. Song, Q. Zhang, and M. Sridharan at Microsoft Research
CUBIC by Injong Rhee, and Lisong Xu
Fast TCP by Cheng Jin, David X. Wei and Steven H. Low. at Caltech.
H-TCP by D. Leithi, and R. Shorten at Hamilton Institute
High Speed TCP proposed by S. Floyd in RFC 3649
HSTCP-LP by A. Kuzmanovic, E. W. Knightly, and R. Les Cottrell
NewReno, proposed by S. Floyd, T. Henderson and A. Gurtov in RFC 3782
Scalable TCP by Tom Kelly
TCP Hybla by Carlo Caini and Rosario Firrincieli at University of Bologna
TCP-Illinois by Shao Liu, Tamer Basar and R. Srikant
TCP-LP by Aleksandar Kuzmanovic
TCP Reno by BSD 4.3BSD
TCP SACK
TCP Vegas by Lawrence S. Brakmo and Larry L. Peterson at University of Arizona
TCP Veno by C. P. Fu, S. C. Liew
TCP Westwood by Saverio Mascolo, Claudio Casetti, Mario Gerla, M. Y. Sanadidi, and Ren Wang
TCP Westwood+ by A. Dell’Aera, L. A. Grieco, S. Mascolo
XCP by Aaron Falk, Dina Katabi
YeAH-TCP by Andrea Baiocchi, Angelo P. Castellani and Francesco Vacirca.
Ensemble Flow Congestion Management (EFCM), Fuzzy Explicit Window Adaptation (FEWA), Enhanced TCP (ETCP)[2]
An extension mechanism TCP Interactive (iTCP) allows applications to subscribe to TCP events and respond accordingly enabling various functional extensions to TCP including application assisted congestion control.
TCP over wireless
TCP has been optimized for wired networks. Any packet loss is considered to be the result of congestion and the window size is reduced dramatically as a precaution. However, wireless links are known to experience sporadic and usually temporary losses due to fading, shadowing, hand off, etc. that cannot be considered congestion. Erroneous back-off of the window size due to wireless packet loss is followed by a congestion avoidance phase with a conservative decrease in window size which causes the radio link to be underutilized. Extensive research has been done on this subject on how to combat these harmful effects. Suggested solutions can be categorized as end-to-end solutions (which require modifications at the client and/or server), link layer solutions (such as RLP in CDMA2000), or proxy based solutions (which require some changes in the network without modifying end nodes).
The TCP checksum is a quite weak check by modern standards. Data Link Layers with a high probability of bit error rates may require additional link error correction/detection capabilities. If TCP were to be redesigned today, it would most probably have a 32-bit cyclic redundancy check specified as an error check instead of the current checksum. The weak checksum is partially compensated for by the common use of a CRC or better integrity check at layer 2, below both TCP and IP, such as is used in PPP or the Ethernet frame. However, this does not mean that the 16-bit TCP checksum is redundant: remarkably, surveys of Internet traffic have shown that software and hardware errors that introduce errors in packets between CRC-protected hops are common, and that the end-to-end 16-bit TCP checksum catches most of these simple errors. This is the end-to-end principle at work.
Congestion control
The final part to TCP is congestion control. TCP uses a number of mechanisms to achieve high performance and avoid 'congestion collapse', where network performance can fall by several orders of magnitude. These mechanisms control the rate of data entering the network, keeping the data flow below a rate that would trigger collapse.
Acknowledgments for data sent, or lack of acknowledgments, are used by senders to implicitly interpret network conditions between the TCP sender and receiver. Coupled with timers, TCP senders and receivers can alter the behavior of the flow of data. This is more generally referred to as flow control, congestion control and/or network congestion avoidance.
Modern implementations of TCP contain four intertwined algorithms: Slow-start, congestion avoidance, fast retransmit, and fast recovery (RFC2581).
Enhancing TCP to reliably handle loss, minimize errors, manage congestion and go fast in very high-speed environments are ongoing areas of research and standards development.
TCP window size
TCP sequence numbers and windows behave very much like a clock. The window, whose width (in bytes) is defined by the receiving host, shifts each time it receives and acks a segment of data. Once it runs out of sequence numbers, it loops back to 0.
The TCP receive window size is the amount of received data (in bytes) that can be buffered during a connection. The sending host can send only up to that amount of data before it must wait for an acknowledgment and window update from the receiving host. When a receiver advertises the window size of 0, the sender stops sending data and starts the persist timer. The persist timer is used to protect TCP from the dead lock situation. The dead lock situation could be when the new window size update from the receiver is lost and the receiver has no more data to send while the sender is waiting for the new window size update. When the persist timer expires the TCP sender sends a small packet so that the receivers ACKs the packet with the new window size and TCP can recover from such situations.
Window scaling
For more efficient use of high bandwidth networks, a larger TCP window size may be used. The TCP window size field controls the flow of data and is limited to between 2 and 65,535 bytes.
Since the size field cannot be expanded, a scaling factor is used. The TCP window scale option, as defined in RFC 1323, is an option used to increase the maximum window size from 65,535 bytes to 1 Gigabyte. Scaling up to larger window sizes is a part of what is necessary for TCP Tuning.
The window scale option is used only during the TCP 3-way handshake. The window scale value represents the number of bits to left-shift the 16-bit window size field. The window scale value can be set from 0 (no shift) to 14.
Many routers and packet firewalls rewrite the window scaling factor during a transmission. This causes sending and receiving sides to assume different TCP window sizes. The result is non-stable traffic that is very slow. The problem is visible on some sending and receiving sites which are behind the path of broken routers.
For more information on problems that may be caused, especially with Linux and Vista systems, please see main topic TCP window scale option.
Connection termination
The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear down requires a pair of FIN and ACK segments from each TCP endpoint.
A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can.
It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method.
It is possible for both hosts to send FINs simultaneously then both just have to ACK. This could possibly be considered a 2-way handshake since the FIN/ACK sequence is done in parallel for both directions.
Some host TCP stacks may implement a "half-duplex" close sequence, as Linux or HP-UX do. If such a host actively closes a connection but still has not read all the incoming data the stack already received from the link, this host will send a RST instead of a FIN (Section 4.2.2.13 in RFC 1122). This allows a TCP application to be sure that the remote application has read all the data the former sent - waiting the FIN from the remote side when it will actively close the connection. Unfortunatelly, the remote TCP stack cannot distinguish between a Connection Aborting RST and this Data Loss RST - both will make the remote stack to throw away all the data it received, but the application still didn't read.
Some application protocols may violate the OSI model layers, using the TCP open/close handshaking for the application protocol open/close handshaking - these may find the RST problem on active close. As an example:s = connect(remote);send(s, data);close(s);
For a usual program flow like above, a TCP/IP stack like that described above does not guarantee that all the data will arrive to the other application unless the programmer is sure that the remote side will not send anything.
TCP ports
TCP uses the notion of port numbers to identify sending and receiving application end-points on a host, or Internet sockets. Each side of a TCP connection has an associated 16-bit unsigned port number (1-65535) reserved by the sending or receiving application. Arriving TCP data packets are identified as belonging to a specific TCP connection by its sockets, that is, the combination of source host address, source port, destination host address, and destination port. This means that a server computer can provide several clients with several services simultaneously, as long as a client takes care of initiating any simultaneous connections to one destination port from different source ports.
Port numbers are categorized into three basic categories: well-known, registered, and dynamic/private. The well-known ports are assigned by the Internet Assigned Numbers Authority (IANA) and are typically used by system-level or root processes. Well-known applications running as servers and passively listening for connections typically use these ports. Some examples include: FTP (21), ssh (22), TELNET (23), SMTP (25) and HTTP (80). Registered ports are typically used by end user applications as ephemeral source ports when contacting servers, but they can also identify named services that have been registered by a third party. Dynamic/private ports can also be used by end user applications, but are less commonly so. Dynamic/private ports do not contain any meaning outside of any particular TCP connection.
Development of TCP
TCP is a complex and evolving protocol. However, while significant enhancements have been made and proposed over the years, its most basic operation has not changed significantly since its first specification RFC 675 in 1974, and the v4 specification RFC 793, published in September 1981.[1] RFC 1122, Host Requirements for Internet Hosts, clarified a number of TCP protocol implementation requirements. RFC 2581, TCP Congestion Control, one of the most important TCP related RFCs in recent years, describes updated algorithms to be used in order to avoid undue congestion. In 2001, RFC 3168 was written to describe explicit congestion notification (ECN), a congestion avoidance signalling mechanism. Common applications that use TCP include HTTP (World Wide Web), SMTP (e-mail) and FTP (file transfer).
The original TCP congestion control was called TCP Tahoe, several alternative congestion control algorithms have been proposed:
BIC TCP by Lisong Xu, Khaled Harfoush, and Injong Rhee at North Carolina State University
Compound TCP by K. Tan, J. Song, Q. Zhang, and M. Sridharan at Microsoft Research
CUBIC by Injong Rhee, and Lisong Xu
Fast TCP by Cheng Jin, David X. Wei and Steven H. Low. at Caltech.
H-TCP by D. Leithi, and R. Shorten at Hamilton Institute
High Speed TCP proposed by S. Floyd in RFC 3649
HSTCP-LP by A. Kuzmanovic, E. W. Knightly, and R. Les Cottrell
NewReno, proposed by S. Floyd, T. Henderson and A. Gurtov in RFC 3782
Scalable TCP by Tom Kelly
TCP Hybla by Carlo Caini and Rosario Firrincieli at University of Bologna
TCP-Illinois by Shao Liu, Tamer Basar and R. Srikant
TCP-LP by Aleksandar Kuzmanovic
TCP Reno by BSD 4.3BSD
TCP SACK
TCP Vegas by Lawrence S. Brakmo and Larry L. Peterson at University of Arizona
TCP Veno by C. P. Fu, S. C. Liew
TCP Westwood by Saverio Mascolo, Claudio Casetti, Mario Gerla, M. Y. Sanadidi, and Ren Wang
TCP Westwood+ by A. Dell’Aera, L. A. Grieco, S. Mascolo
XCP by Aaron Falk, Dina Katabi
YeAH-TCP by Andrea Baiocchi, Angelo P. Castellani and Francesco Vacirca.
Ensemble Flow Congestion Management (EFCM), Fuzzy Explicit Window Adaptation (FEWA), Enhanced TCP (ETCP)[2]
An extension mechanism TCP Interactive (iTCP) allows applications to subscribe to TCP events and respond accordingly enabling various functional extensions to TCP including application assisted congestion control.
TCP over wireless
TCP has been optimized for wired networks. Any packet loss is considered to be the result of congestion and the window size is reduced dramatically as a precaution. However, wireless links are known to experience sporadic and usually temporary losses due to fading, shadowing, hand off, etc. that cannot be considered congestion. Erroneous back-off of the window size due to wireless packet loss is followed by a congestion avoidance phase with a conservative decrease in window size which causes the radio link to be underutilized. Extensive research has been done on this subject on how to combat these harmful effects. Suggested solutions can be categorized as end-to-end solutions (which require modifications at the client and/or server), link layer solutions (such as RLP in CDMA2000), or proxy based solutions (which require some changes in the network without modifying end nodes).
Subscribe to:
Posts (Atom)