An attacker who is able to eavesdrop a TCP session and redirect packets can hijack a TCP connection. To do so, the attacker learns the sequence number from the ongoing communication and forges a false segment that looks like the next segment in the stream. Such a simple hijack can result in one packet being erroneously accepted at one end. When the receiving host acknowledges the extra segment to the other side of the connection, synchronization is lost. Hijacking might be combined with Address Resolution Protocol ("ARP) or routing attacks that allow taking control of the packet flow, so as to get permanent control of the hijacked TCP connection.
Impersonating a different IP address was not difficult prior to RFC 1948, when the initial sequence number was easily guessable. That allowed an attacker to blindly send a sequence of packets that the receiver would believe to come from a different IP address, without the need to deploy ARP or routing attacks: it is enough to ensure that the legitimate host of the impersonated IP address is down, or bring it to that condition using "denial-of-service attacks. This is why the initial sequence number is now chosen at random.
An attacker who can eavesdrop and predict the size of the next packet to be sent can cause the receiver to accept a malicious payload without disrupting the existing connection. The attacker injects a malicious packet with the sequence number and a payload size of the next expected packet. When the legitimate packet is ultimately received, it is found to have the same sequence number and length as a packet already received and is silently dropped as a normal duplicate packet—the legitimate packet is "vetoed" by the malicious packet. Unlike in connection hijacking, the connection is never desynchronized and communication continues as normal after the malicious payload is accepted. TCP veto gives the attacker less control over the communication, but makes the attack particularly resistant to detection. The large increase in network traffic from the ACK storm is avoided. The only evidence to the receiver that something is amiss is a single duplicate packet, a normal occurrence in an IP network. The sender of the vetoed packet never sees any evidence of an attack.
Another vulnerability is "TCP reset attack.
TCP and UDP use "port numbers to identify sending and receiving application end-points on a host, often called "Internet sockets. Each side of a TCP connection has an associated 16-bit unsigned port number (0-65535) reserved by the sending or receiving application. Arriving TCP 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 (20 and 21), "SSH (22), "TELNET (23), "SMTP (25), "HTTP over SSL/TLS (443), 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.
"Network Address Translation (NAT), typically uses dynamic port numbers, on the ("Internet-facing") public side, to "disambiguate the flow of traffic that is passing between a public network and a private "subnetwork, thereby allowing many IP addresses (and their ports) on the subnet to be serviced by a single public-facing address.
TCP is a complex 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. RFC 1122, Host Requirements for Internet Hosts, clarified a number of TCP protocol implementation requirements. A list of the 8 required specifications and over 20 strongly encouraged enhancements is available in RFC 7414. Among this list is RFC 2581, TCP Congestion Control, one of the most important TCP-related RFCs in recent years, describes updated algorithms that avoid undue congestion. In 2001, RFC 3168 was written to describe Explicit Congestion Notification ("ECN), a congestion avoidance signaling mechanism.
The original "TCP congestion avoidance algorithm was known as "TCP Tahoe", but many alternative algorithms have since been proposed (including "TCP Reno, "TCP Vegas, "FAST TCP, "TCP New Reno, and "TCP Hybla).
TCP Interactive (iTCP)  is a research effort into TCP extensions that allows applications to subscribe to TCP events and register handler components that can launch applications for various purposes, including application-assisted congestion control.
"Multipath TCP (MPTCP)  is an ongoing effort within the IETF that aims at allowing a TCP connection to use multiple paths to maximize resource usage and increase redundancy. The redundancy offered by Multipath TCP in the context of wireless networks enables the simultaneous utilisation of different networks, which brings higher throughput and better handover capabilities. Multipath TCP also brings performance benefits in datacenter environments. The reference implementation of Multipath TCP is being developed in the Linux kernel. "Multipath TCP is used to support the Siri voice recognition application on iPhones, iPads and Macs 
"TCP Cookie Transactions (TCPCT) is an extension proposed in December 2009 to secure servers against denial-of-service attacks. Unlike SYN cookies, TCPCT does not conflict with other TCP extensions such as "window scaling. TCPCT was designed due to necessities of "DNSSEC, where servers have to handle large numbers of short-lived TCP connections.
"tcpcrypt is an extension proposed in July 2010 to provide transport-level encryption directly in TCP itself. It is designed to work transparently and not require any configuration. Unlike "TLS (SSL), tcpcrypt itself does not provide authentication, but provides simple primitives down to the application to do that. As of 2010[update], the first tcpcrypt IETF draft has been published and implementations exist for several major platforms.
"TCP Fast Open is an extension to speed up the opening of successive TCP connections between two endpoints. It works by skipping the three-way handshake using a cryptographic "cookie". It is similar to an earlier proposal called "T/TCP, which was not widely adopted due to security issues. As of July 2012[update], it is an IETF Internet draft.
Proposed in May 2013, Proportional Rate Reduction (PRR) is a TCP extension developed by "Google engineers. PRR ensures that the TCP window size after recovery is as close to the "Slow-start threshold as possible. The algorithm is designed to improve the speed of recovery and is the default congestion control algorithm in Linux 3.2+ kernels.
TCP over wireless networks
TCP was originally designed for wired networks. Packet loss is considered to be the result of "network congestion and the congestion 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, "interference, and other radio effects, that are not strictly congestion. After the (erroneous) back-off of the congestion window size, due to wireless packet loss, there may be a congestion avoidance phase with a conservative decrease in window size. This causes the radio link to be underutilized. Extensive research on combating these harmful effects has been conducted. Suggested solutions can be categorized as end-to-end solutions, which require modifications at the client or server, link layer solutions, such as Radio Link Protocol ("RLP) in cellular networks, or proxy-based solutions which require some changes in the network without modifying end nodes.
A number of alternative congestion control algorithms, such as "Vegas, "Westwood, Veno, and Santa Cruz, have been proposed to help solve the wireless problem.["citation needed]
One way to overcome the processing power requirements of TCP is to build 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. One company to develop such a device was "Alacritech.
A "packet sniffer, which intercepts TCP traffic on a network link, can be useful in debugging networks, network stacks, and applications that 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 is helpful in debugging. "Netstat is another utility that can be used for debugging.
For many applications TCP is not appropriate. One problem (at least with normal implementations) is that the application cannot access 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 media, real-time multiplayer games and "voice over IP (VoIP) where it is generally more useful to get most of the data in a timely fashion than it is to get all of the data in order.
For historical and performance reasons, most "storage area networks (SANs) use "Fibre Channel Protocol (FCP) over "Fibre Channel connections.
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 streams or retransmission, giving the application developer the ability to code them in a way suitable for the situation, or to replace them with other methods like "forward error correction or "interpolation.
"Stream Control Transmission Protocol (SCTP) is another protocol that provides reliable stream oriented services similar to TCP. It is newer and considerably more complex than TCP, and 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 to overcome perceived inefficiencies related to wireless data transport.
TCP also has issues in high-bandwidth environments. The "TCP congestion avoidance algorithm works very well for ad-hoc environments where the data sender is not known in advance. If the environment is predictable, a timing based protocol such as "Asynchronous Transfer Mode (ATM) can avoid TCP's retransmits overhead.
"UDP-based Data Transfer Protocol (UDT) has better efficiency and fairness than TCP in networks that have high "bandwidth-delay product.
"Multipurpose Transaction Protocol (MTP/IP) is patented proprietary software that is designed to adaptively achieve high throughput and transaction performance in a wide variety of network conditions, particularly those where TCP is perceived to be inefficient.
TCP checksum for 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, after appropriate padding, all 16-bit words are added using "one's complement arithmetic. The sum is then bitwise complemented and inserted as the checksum field. A pseudo-header that mimics the IPv4 packet header used in the checksum computation is shown in the table below.
|96||Source port||Destination port|
The source and destination addresses are those of the IPv4 header. The protocol value is 6 for TCP (cf. "List of IP protocol numbers). The TCP length field is the length of the TCP header and data (measured in octets).
TCP checksum for 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.
A pseudo-header that mimics the IPv6 header for computation of the checksum is shown below.
|320||Source port||Destination port|
- Source address: the one in the IPv6 header
- Destination address: the final destination; if the IPv6 packet doesn't contain a Routing header, TCP uses the destination address in the IPv6 header, otherwise, at the originating node, it uses the address in the last element of the Routing header, and, at the receiving node, it uses the destination address in the IPv6 header.
- TCP length: the length of the TCP header and data
- Next Header: the protocol value for TCP
Checksum offload 
Many TCP/IP software stack implementations provide options to use hardware assistance to automatically compute the checksum in the "network adapter prior to transmission onto the network or upon reception from the network for validation. This may relieve the OS from using precious CPU cycles calculating the checksum. Hence, overall network performance is increased.
This feature may cause "packet analyzers that are unaware or uncertain about the use of checksum offload to report invalid checksums in outbound packets that have not yet reached the network adapter. This will only occur for packets that are intercepted before being being transmitted by the network adapter; all packets transmitted by the network adaptor on the wire will have valid checksums. This issue can also occur when monitoring packets being transmitted between virtual machines on the same host, where a virtual device driver may omit the checksum calculation (as an optimisation), knowing that the checksum will be calculated later by the VM host kernel or its physical hardware.
- "Connection-oriented communication
- "Karn's algorithm
- "List of TCP and UDP port numbers (a long list of ports and services)
- "Maximum segment lifetime
- "Maximum transmission unit
- "Micro-bursting (networking)
- "Nagle's algorithm
- "Port (computer networking)
- "T/TCP variant of TCP
- "TCP congestion avoidance algorithms
- "TCP global synchronization
- "TCP pacing
- "TCP segment
- "TCP sequence prediction attack
- "TCP tuning for high performance networks
- "WTCP a proxy-based modification of TCP for wireless networks
- "Transport Layer § Comparison of transport layer protocols
- Vinton G. Cerf; Robert E. Kahn (May 1974). "A Protocol for Packet Network Intercommunication" (PDF). IEEE Transactions on Communications. 22 (5): 637–648. "doi:10.1109/tcom.1974.1092259. Archived from the original (PDF) on March 4, 2016.
- "Comer, Douglas E. (2006). Internetworking with TCP/IP:Principles, Protocols, and Architecture. 1 (5th ed.). Prentice Hall. "ISBN "0-13-187671-6.
- "TCP (Linktionary term)".
- "RFC 791 – section 2.1".
- "RFC 793".
- "RFC 1323, TCP Extensions for High Performance, Section 2.2".
- "RFC 2018, TCP Selective Acknowledgement Options, Section 2".
- "RFC 2018, TCP Selective Acknowledgement Options, Section 3".
- "RFC 1323, TCP Extensions for High Performance, Section 3.2".
- RFC 793 section 3.1
- RFC 793 Section 3.2
- "Tanenbaum, Andrew S. (2003-03-17). Computer Networks (Fourth ed.). Prentice Hall. "ISBN "0-13-066102-3.
- "TCP Definition". Retrieved 2011-03-12.
- Mathis; Mathew; Semke; Mahdavi; Ott (1997). "The macroscopic behavior of the TCP congestion avoidance algorithm". ACM SIGCOMM Computer Communication Review. 27.3: 67–82.
- Paxson, V.; Allman, M.; Chu, J.; Sargent, M. (June 2011). "The Basic Algorithm". Computing TCP's Retransmission Timer. "IETF. p. 2. sec. 2. RFC 6298. https://tools.ietf.org/html/rfc6298#section-2. Retrieved October 24, 2015.
- Stone; Partridge (2000). "When The CRC and TCP Checksum Disagree". Sigcomm.
- "RFC 879".
- "TCP window scaling and broken routers [LWN.net]".
- Gont, Fernando (November 2008). "On the implementation of TCP urgent data". 73rd IETF meeting. Retrieved 2009-01-04.
- Peterson, Larry (2003). Computer Networks. Morgan Kaufmann. p. 401. "ISBN "1-55860-832-X.
- Richard W. Stevens (2006). November 2011 TCP/IP Illustrated. Vol. 1, The protocols Check
|url=value ("help). Addison-Wesley. pp. Chapter 20. "ISBN "978-0-201-63346-7.
- Security Assessment of the Transmission Control Protocol (TCP) at the "Wayback Machine (archived March 6, 2009)
- Security Assessment of the Transmission Control Protocol (TCP)
- Jakob Lell. "Quick Blind TCP Connection Spoofing with SYN Cookies". Retrieved 2014-02-05.
- Some insights about the recent TCP DoS (Denial of Service) vulnerabilities
- "Exploiting TCP and the Persist Timer Infiniteness".
- "Laurent Joncheray, Simple Active Attack Against TCP, 1995".
- John T. Hagen; Barry E. Mullins (2013). "TCP veto: A novel network attack and its application to SCADA protocols". Innovative Smart Grid Technologies (ISGT), 2013 IEEE PES.
- TCP Interactive (iTCP)
- RFC 6182
- RFC 6824
- Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). "Improving datacenter performance and robustness with multipath TCP". Sigcomm.
- "MultiPath TCP - Linux Kernel implementation".
- Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". USENIX NSDI.
- Bonaventure; Seo (2016). "Multipath TCP Deployments". IETF Journal.
- Michael Kerrisk (2012-08-01). "TCP Fast Open: expediting web services". "LWN.net.
- Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain (2012-07-16). TCP Fast Open. "IETF. I-D draft-ietf-tcpm-fastopen-01. https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-01.
- "RFC 6937 - Proportional Rate Reduction for TCP". http://tools.ietf.org/html/rfc6937. External link in
- Grigorik, Ilya (2013). High-performance browser networking (1. ed.). Beijing: O'Reilly. "ISBN "1449344763.
- "TCP performance over CDMA2000 RLP". Retrieved 2010-08-30
- Muhammad Adeel & Ahmad Ali Iqbal (2004). "TCP Congestion Window Optimization for CDMA2000 Packet Data Networks". International Conference on Information Technology (ITNG'07): 31–35. "doi:10.1109/ITNG.2007.190. "ISBN "978-0-7695-2776-5.
- Yunhong Gu, Xinwei Hong, and Robert L. Grossman. "An Analysis of AIMD Algorithm with Decreasing Increases". 2004.
- "Wireshark: Offloading".
Wireshark captures packets before they are sent to the network adapter. It won't see the correct checksum because it has not been calculated yet. Even worse, most OSes don't bother initialize this data so you're probably seeing little chunks of memory that you shouldn't. New installations of Wireshark 1.2 and above disable IP, TCP, and UDP checksum validation by default. You can disable checksum validation in each of those dissectors by hand if needed.
- "Wireshark: Checksums".
Checksum offloading often causes confusion as the network packets to be transmitted are handed over to Wireshark before the checksums are actually calculated. Wireshark gets these “empty” checksums and displays them as invalid, even though the packets will contain valid checksums when they leave the network hardware later.
- "Stevens, W. Richard. TCP/IP Illustrated, Volume 1: The Protocols. "ISBN "0-201-63346-9.
- Stevens, W. Richard; Wright, Gary R. TCP/IP Illustrated, Volume 2: The Implementation. "ISBN "0-201-63354-X.
- Stevens, W. Richard. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. "ISBN "0-201-63495-3.**
|""||Wikiversity has learning resources about Transmission Control Protocol|
|""||Wikimedia Commons has media related to Transmission Control Protocol.|
- RFC 675 – Specification of Internet Transmission Control Program, December 1974 Version
- RFC 793 – TCP v4
- RFC 1122 – includes some error corrections for TCP
- RFC 1323 – TCP Extensions for High Performance [Obsoleted by RFC 7323]
- RFC 1379 – Extending TCP for Transactions—Concepts [Obsoleted by RFC 6247]
- RFC 1948 – Defending Against Sequence Number Attacks
- RFC 2018 – TCP Selective Acknowledgment Options
- RFC 5681 – TCP Congestion Control
- RFC 6247 – Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status
- RFC 6298 – Computing TCP's Retransmission Timer
- RFC 6824 – TCP Extensions for Multipath Operation with Multiple Addresses
- RFC 7323 – TCP Extensions for High Performance
- RFC 7414 – A Roadmap for TCP Specification Documents
- Oral history interview with Robert E. Kahn, "Charles Babbage Institute, University of Minnesota, Minneapolis. Focuses on Kahn's role in the development of computer networking from 1967 through the early 1980s. Beginning with his work at "Bolt Beranek and Newman (BBN), Kahn discusses his involvement as the "ARPANET proposal was being written, his decision to become active in its implementation, and his role in the public demonstration of the ARPANET. The interview continues into Kahn's involvement with networking when he moves to IPTO in 1972, where he was responsible for the administrative and technical evolution of the ARPANET, including programs in packet radio, the development of a new network protocol (TCP/IP), and the switch to TCP/IP to connect multiple networks.
- IANA Port Assignments
- John Kristoff's Overview of TCP (Fundamental concepts behind TCP and how it is used to transport data between two endpoints)
- TCP fast retransmit simulation animated: slow start, sliding window, duplicated Ack, congestion window
- TCP, Transmission Control Protocol
- Checksum example
- Engineer Francesco Buffa's page about Transmission Control Protocol
- TCP tutorial
- Linktionary on TCP segments
- TCP Sliding Window simulation animated (ns2)
- Multipath TCP
- TCP Technology and Testing methodologies