Transmission Control Protocol (TCP) provides a connection-based, reliable byte-stream service to applications. Microsoft networking relies upon TCP for logon services, file and print sharing, replication of information between domain controllers, transfer of browse lists, and other common functions. TCP can be used only for one-to-one communications. The following sections describe some implementation details of the Windows Transmission Control Protocol/Internet Protocol (TCP/IP) stack.

Offloading TCP/IP Checksums

One focus of the Windows implementation of TCP/IP is performance. TCP uses a checksum on both the TCP header and payload of each segment to reduce the chance of network corruption going undetected. Network Driver Interface Specification (NDIS) 5.1 provides support for task offloading, and in Windows Server 2003 TCP/IP takes advantage of this by allowing the network interface card (NIC) to perform the TCP checksum calculations if the NIC driver supports this function. Offloading the checksum calculations to hardware can result in performance improvements in very high-throughput environments.

Generating TCP/IP Initial Sequence Numbers

RFC 1948 recommends that the initial sequence number (ISN) of a TCP session be randomized to make sequence number–based attacks on network communication more difficult. In Windows Server 2003, the TCP/IP ISN generation algorithm has been modified so that ISNs increase in random increments, using an RC4-based random number generator initialized with a 2048-bit random key upon system startup. For more information, see RFC 1948: Defending Against Sequence Number Attacks.

Working with TCP Selective Acknowledgment

Selective acknowledgment (SACK) is used for connections with large TCP window sizes. It is enabled by default in Windows Server 2003. When SACK is enabled, if a packet or series of packets is dropped the receiver can inform the sender of exactly which data has been received and where the holes in the data are. The sender can then selectively retransmit the missing data without needing to retransmit blocks of data that have already been received successfully. Prior to SACK, which was added to the Windows TCP/IP stack in Windows 2000, a receiver could only acknowledge the latest sequence number of contiguous data that had been received, or the left edge of the receive window.

When SACK is enabled, the receiver uses the acknowledgment (ACK) number to acknowledge the left edge of the receive window, as was standard before SACK came into use. However, the receiver can also acknowledge other noncontiguous blocks of received data individually. SACK uses two different TCP header options:

• The SACK option. This option conveys extended acknowledgment information from the receiver to the sender over an established TCP connection. Within the SACK option are up to four pairs of TCP sequence numbers acknowledging up to four noncontiguous blocks of data. Each TCP sequence pair contains the left and right edges of the block being acknowledged. The left edge is the sequence number of the first byte in the block, and the right edge is the sequence number of the byte immediately following the last byte in the block.
• The SACK-Permitted option. This option indicates that the sender can receive and interpret the SACK option. This option is sent at the beginning of a TCP connection in TCP segments in which the SYN flag is set.

SACK is controlled by the SackOpts registry value and is enabled by default. For more information about SACK, see RFC 2018.

Working with TCP Time Stamps

Windows Server 2003 TCP/IP supports TCP time stamps, as described in RFC 1323. Like SACK, time stamps are important for connections using large window sizes. Time stamps assist TCP in accurately measuring round-trip time (RTT) to adjust retransmission time-outs.

The TCP header option Timestamps carries two 4-byte time stamp fields. The Timestamp Value field (TSval) contains the current value of the time stamp clock of the TCP peer sending the option. The Timestamp Echo Reply field (TSecr) is only valid if the ACK flag is set in the TCP header. If the TSecr field is valid, it contains a time stamp value that was sent by the remote TCP peer in the TSval field of a Timestamps option. If TSecr is not valid, its value must be zero. The TSecr value generally comes from the most recent Timestamps option that was received, except if the most recent Timestamps option occurs in an initial SYN segment, as described following.

To indicate use of the Timestamps option, the default behavior is for a TCP peer to send the Timestamps option (TSopt) in an initial SYN segment (that is, in a segment containing a SYN flag and no ACK flag). A TCP peer can send TSopt in later segments only if it received TSopt in the initial SYN segment for the connection. This default behavior can be modified with the Tcp1323Opts registry value.

For more information about the Timestamps option, see RFC 1323: TCP Extensions for High Performance.

Other Implementation Details

For additional information on working with TCP in Microsoft networking, see the topics listed in the following table:

See Also

Host-to-Host Transport Layer