Talk:Transmission Control Protocol/Archive 1

Archive 1

NPOV?

Forgive me if I'm incorrect, I'm a newb at wikipedia. Doesn't this bit go against the whole "neutral point of view" philosophy?

"A better solution..."

It almost sounds like whoever put that bit in was just trying to advertise "NTA"

That paragraph seemed to be simply an advertisement. That's not just an "NPOV" violation, it's spam. (To the person who added it -- please learn how not to be a spammer.) Deleted. --FOo 14:32, 1 August 2005 (UTC)

State diagram

The german article is a featured article so when I checked it out I noticed that it had a state diagram: de:Bild:Tcp verbindung.png. If anyone feels like doing a little editting to change the german to english...that'd be spiffy. Cburnett 06:16, 22 February 2006 (UTC)

Done. Raul654 07:03, 22 February 2006 (UTC)

"Active Open" / "Passive Open" in connection terminating state box, should be "Active Close" / "Passive Close" respectively?

iTCP

I'm in two minds about whether this should be here as this is more about research than TCP. What are others thoughts? In the meantime I'm fixing the grammar and links up a little... --Imcdnzl 00:21, 16 May 2006 (UTC)

I've asked Oldiowl to tone this down a bit as it sounds like an advertisment for iTCP at the moment. --Imcdnzl 03:45, 16 May 2006 (UTC)

Thanks for your comments. I have toned it down. See if it reads better?

Just a note.. iTCP also has FreeBSD impelementation. It is just new. Note many others linked/explained/pointed variants of TCP are also predominantly research system. Fast TCP, TCP Hybla, H-TCP, are in this class. Many even have no record of implementation. However, it is possibly Ok to list such research grade systems for discussions of current transport protocols.

I tried to follow TCP Hybla pointer but it does not seem to point to a page with obvious connection to a TCP protocol description. Does anyone know about this link?

thanks, Oldiowl

OK. I'm editing this after reading about iTCP some more. It is actually quite interesting and relevant to my research but the edits on this page are inaccurate and do not need the prominence that they have been given.--Imcdnzl 21:10, 18 May 2006 (UTC)

History

There's no mention of who developed TCP, or how it came to be. —Preceding unsigned comment added by 62.79.44.136 (talk • contribs)

Thank you for your suggestion! When you feel an article needs improvement, please feel free to make those changes. Wikipedia is a wiki, so anyone can edit almost any article by simply following the Edit this page link at the top. You don't even need to log in (although there are many reasons why you might want to). The Wikipedia community encourages you to be bold in updating pages. Don't worry too much about making honest mistakes — they're likely to be found and corrected quickly. If you're not sure how editing works, check out how to edit a page, or use the sandbox to try out your editing skills. New contributors are always welcome. --FOo 07:51, 15 August 2006 (UTC)

There is a good history at Internet protocol suite which contains TCP within it, so if you wanted more, also consider putting it there instead. — RevRagnarok ^{Talk Contrib} 10:45, 15 August 2006 (UTC)

"TCP Reno"

To the best of my knowledge, "TCP Reno" is a name invented by Larry Peterson, and not used by many other researchers. At the time Van Jacobson was developing the original congestion mitigation algorithms, it was expected that they would be released in 4.4BSD. Development of 4.4 took much longer than anticipated, and an interim release, 4.3BSD-Reno (successor to 4.3BSD-Tahoe), was made to get the code out into the hands of ISVs. It was published in the "Networking 1" release about the same time. 18.26.0.5 22:25, 11 September 2006 (UTC)

TCP is not a virtual circuit protocol

TCP is not a virtual circuit because the connection state resides only on the two send systems. Any intermediate nodes are not aware of any of the TCP parameters. Fisherisland14 19:27, 25 September 2006 (UTC)

TCP is a virtual circuit protocol because the connection state resides. Intermediate nodes need not be aware of any parameters for a protocol to establish a virtual circuit. Here are two external definitions:

• [1]: A connection between communicating computers that provides the computers with what appears to be a direct link but can actually involve routing data over a defined, but longer path. - no mentions of necessity of intermediate nodes being aware of anything.
• [2]: A defined connection between two end-points in a packetized network. While the two ends of the virtual circuit are defined, the path used by the network to connect the two end-points is not necessarily predetermined. - explicitly said that intermediate nodes not important. Nikola 15:07, 13 October 2006 (UTC)

Application/transport dependency misnomer

From the article:

"Common applications that use TCP include HTTP/HTTPS (World Wide Web), SMTP/POP3/IMAP (e-mail) and FTP (file transfer)."

The phrasing in the article tacitly implies that as part of their specification application layer protcols must use TCP. This is not entirely accurate. From RFC 2616:

HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being 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; the mapping of the HTTP/1.1 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.

—Super j dynamite 04:56, 19 September 2006 (UTC)

That may be true in a pedantic sense but the reality is that http is used either directly with TCP or with SSL over TCP. Are there even any standard url schemes that can specify a http connection over something other than TCP or SSL over TCP? Plugwash 11:01, 22 October 2006 (UTC)

SYN Merge

Not enough info on SYN for a good article, and ACK already redirects here. --Ortzinator 15:18, 27 October 2006 (UTC)

Sounds like a good idea to me: One specific packet type of a protocol is probably a little over-specific. DStaal 18:27, 27 October 2006 (UTC)

Merge, such as it was, done. Guy Harris 00:25, 22 November 2006 (UTC)

over time diagram?

What do you think of adding that kind of diagram to the article? I personally find them simpler to understand than the state diagram. I'll try to do a draft tonight (EST). -- lucasbfr ^talk 14:15, 11 October 2006 (UTC)

what do you think? -- lucasbfr ^talk 00:38, 17 October 2006 (UTC)

The visual quality doesn't match what is already present in the article. Additionally, it is confusing where the actual data communication occurs - you seem to be showing a very limited one-shot request, like HTTP or something. I think I'd prefer to break it into two images with "setting up" and "taking down" separated. — RevRagnarok ^{Talk Contrib} 10:55, 17 October 2006 (UTC)

Thanks for your input. As I said, that's a draft more than anything else. I'll see if I come with something else. -- lucasbfr ^talk 13:27, 17 October 2006 (UTC)

I was actually looking for a diagram like this in the main article! May be a trace screenshot from WireShark would suffice. 21 November 2006

This type of diagram is often used to simplify the explanation of state machines; I frequently use them in teaching. When I don't have time to tell students how to read a state machine, I give them call flows like this instead. I vote use these with a sentence or two of explanation in place of state machine diagramswhich require about 30 minutes of lecture to get a student up to speed in reading one. I have mixed feelings, however, because the state machine on this page is a work of art. Ngriffeth 14:04, 3 July 2007 (UTC)

Remarks

Someone should change sentences like "TCP is optimized for ...". TCP is developed for wired networks, but not optimized for such scenarios. Mathematicians can optimize something, engineers improve something! And have a look outside the USA. Good ideas how to improve TCP are not restricted to USA researchers. Therefore, I have added a link to my two-year old (!) dissertation. —The preceding unsigned comment was added by 217.247.67.233 (talk) 03:03, 9 December 2006 (UTC).

To the best of my knowledge, the problems with TCP over wireless haven't been solved, they've merely been ameliorated somewhat. The problem is that TCP assumes that dropped packets mean congestion, because that's almost always the case in current highly reliable wireline networks. Obviously, wireless networks drop packets for many reasons. Ngriffeth 14:07, 3 July 2007 (UTC)

Software limitations -- totally unreliable claims

From the article:

Networking speed gradually increased over the years. What started as a protocol built for unreliable low speed networks (few Kbytes per second) is now required to run at 1 Gigabit per second. The TCP software implementations on host systems require extensive computing power. Gigabit TCP communication, alone, eats up 100% of a 2.4 GHz Pentium 4 processor.

The latter point is totally uncited, and omits several facts that are essential to judge the statement. For instance, TCP implementations vary widely, as to OS responses to high load, particularly I/O load. What operating system was this metered on? What kind of load was used? I would expect, for instance, that a 2.4GHz Pentium 4 being used as an Ethernet bridge in Linux, using zero-copy forwarding, would have very different performance characteristics from one being used as an FTP server in Windows.

These claims need to be cited with details, or else they should be deleted. --FOo 02:34, 27 Jun 2005 (UTC)

Agreed. My 2.0 GHz 2400+ XP Athlon w/ 512 MB ram running 2.6 gentoo linux sees hardly any CPU time for my gigabit card. Cburnett 04:15, Jun 27, 2005 (UTC)

Almost ALL GOC ( Gigabit over copper ) cards today, have CPUs on the cards, that with the use of jumbo frames reduces CPU utilization. [3]

The reduction in CPU utilization is achieved primarily by allowing the host to transmit large frames (frames larger than the links Maximum Transmission Unit or MTU) to the NIC which are subsequently carved up into smaller, MTU-sized frames by the NIC, before transmission on the wire. Thus instead of processing many small MTU-sized frames during transmit, the host sends fewer larger VMTU (Virtual MTU) sized frames thereby increasing the efficiency of the data transfer in the host. The VMTU is typically much larger than the links MTU; for example, on a typical Ethernet card, the link MTU is 1500 bytes while a VMTU could be as large as 64Kbytes. Greater than 50% reduction in CPU utilization has been observed on some FTP workloads.

—Preceding unsigned comment added by 67.174.157.126 (talk) 22:18, 5 May 2008 (UTC)

Removed since I think it's sufficiently wrong to merit proof for inclusion. Cburnett June 28, 2005 07:58 (UTC)

Would like to add that the statement "Linux kernels (from 2.6.8) have enabled TCP Window Scaling ..." is out of place. If we are going to include various OS and OS version specific comments, the list would be huge, and absolutely unmanageble.Libertate 16:37, 2 February 2007 (UTC)

Datagram

What is a datagram, and does TCP count as a Datagram? Mathiastck 21:25, 13 July 2006 (UTC)

What I have been told at university is that "Datagram" is the name of the PDU for UDP, while "Segment" is the name of the PDU for TCP. El pak

It would improve this article greatly to respond to questions with adding simple explanations to the article, and not left as an excercise for the reader. —Preceding unsigned comment added by 67.174.157.126 (talk) 22:22, 5 May 2008 (UTC)

what is tcp actually for?

what does this do?

Read the TCP article ;) Burningmace 20:22, 23 July 2007 (UTC)

It's used to clean bathtubs, so I hear.

Nah. TCP is an internet protocol. It's well known for its use in HTTP communication (between a web browser and a web server), but it can be used for other things too, such as online games. Comparing it with UDP might help put it in context. — xDanielx ^T/_C 00:11, 16 August 2007 (UTC)

TCP is Great for cleaning tubs, but in this context, it is a method or proticall, much like the proticall Bocce, it is great for negotiating the transfer of binay and ascii data in short bursts or long transfers, for HTTP transmissions or FTP transmissions. ( Jumbo packets are best for faster connectsions ). —Preceding unsigned comment added by 67.174.157.126 (talk) 02:45, 6 May 2008 (UTC)

Established connection sockets

I always wonder what happens to the listening socket after establishing a connection with it? Lets say there is a software server (Svr) listening at port x, then a client C connects (handshakes and all). Now we know that a connection is established between Svr & C on port x, yet, the server is still listening for new connections on port x. So how can the same port be used by an established connection and for listening to new connections at the same time?

In other words: How does a server like a web server, for example, handles multiple connections simultaneously on the same port number?

Thanks

Ai.unit (talk) 21:37, 18 November 2007 (UTC)

I think that's generally the point of sockets being a combination of port and IP, the server obviously can't get a new connection from the same IP on the same port as it would have no way to identify which was which (except maybe the window but that's far from reliable). The way I'm doing at the minute for my embedded stack is to have the port and socket info slightly separate. If a connection comes in on a port from an IP not associated with the port it sets up a new connection as it's obviously very simple to distinguish, while existing connections on the port may not be listening. Basically the port is in perpetual listen but a socket on that port may not be. I don't know if that's exactly how it's meant to be done but seems the most sensible way to me. - Y_Less 15:58, 23 November 2007 (GMT)

OK you can get multiple connections from the same IP on the same port as it uses remote port too which is essentially random, i.e. a http connection will connect to port 80 but connect from any port which the server can use to reply - Y Less (talk) 11:34, 27 November 2007 (UTC)

Good question Ai! I came to this page looking for exactly the answer to this question (which was just troubling me generally). I read the whole article to look for the answer, before reading the talk page. I think the talk page should be the place to look for improvements to the article, but not for relevant questions on the subject. I vote that this information be moved to the main page. --Dmg46664 (talk) 21:56, 1 May 2008 (UTC)

Hint: Look at the header of a TCP Packet. 67.174.157.126 (talk) 02:47, 6 May 2008 (UTC)

A TCP connection is actually identified by both of its endpoints, not just one. So a connection is the combined information of the local IP address, the local TCP port, the remote IP address and the remote TCP port. So, obviously there aren't any problems with several connections to the same local IP address and TCP port, as long as the remote ends differ. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)

The TCP state diagram is inaccurate

The boxes for the closing procedures are incorrectly explaining them as active/passive opens. —Preceding unsigned comment added by 212.146.94.66 (talk) 12:01, 15 September 2008 (UTC)

I corrected the problem. --Sergiodc2 (talk) 10:35, 16 October 2008 (UTC)

Termination,

can anyone comment about the following quote: "Finally, 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."

I think this is impossible... and anyway (see the discussion about termination below) it's the number of state changes that matters and not the number of packets.

I think this sentence should be removed.

Achituv 14:50, 19 April 2007 (UTC)

It's possible. What they are talking about is if both sides decide, simultainiously, to close the connection. (So they both request it.) Depending on how you look at it, it even results in one less state change: Both sides change state on their own to 'ready to end', and the other side would then reply that it is also ready. (Instead of one side triggering the state change in the other.)

It is somewhat confusing as a sentance however. (Though I'm obviously not sure how to clean it up.) DStaal 15:12, 20 April 2007 (UTC)

It this Correct, I beleave that it is the direction that is closed, not the end. If I close for send I can still receive. (it would also be good to see mapping between BSD API and protocal.)

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 or receive any data from the connection, but the other side can (but generally if it tries, this should result in no acknowledgment and therefore a timeout, or else result in a positive RST, and either way thereby the destruction of the half-open socket). —Preceding unsigned comment added by 204.193.45.69 (talk) 11:23, 12 March 2009 (UTC)

TCP segment structure

Anybody got the RFC that explicitly backs up the segment structure displayed? I know its implied in the RFC's but I cannot find an RFC that backs this version up, and it is distictly different from http://tools.ietf.org/html/rfc793#page-15

--Whisper555 07:31, 3 July 2007 (UTC)

I hate to say this because these are nice diagrams, illustrate the headers nicely and in the appropriate way, and they're almost entirely accurate (more accurate would be more confusing anyway). However...

The inclusion of two diagrams, the first diagram combining the IPv4 header with the TCP header and the second diagram combining the IPv6 header with the TCP header is extremely confusing. The only reason I was able to decode this is because I'm used to network layering, know the IP headers by heart, and I just finished writing a program to dissect network headers based on a new definition language for them (I used the language definitions to check the fields in the TCP segment header - they're essentially correct - and I also am actively using the language definitions to dissect TCP segments, so these headers do correspond to what's in use in the Internet - but for the record, we must also consult the IETF documents).

Anyway, this seems like waaaaaay too much information for anyone - if I want the official version of TCP headers, I'll go to the IETF site anyway, so having them here means wikipedia has to keep tracking what's going on at IETF to keep them up to date, and anyone who really needs this level of info is going to go to IETF to get the official version

I'm tempted to just delete this, but first, could someone explain what the purpose of including it was so we can consider whether there's a better way to communicate the ideas? Ngriffeth 14:28, 3 July 2007 (UTC)

Come now. The TCP headers don't change that much, that often. :) The point I was making is that the current diagram & subsequent explanations do not match RFC 793. I personally know why they don't, but that doesn't mean everybody else will, and it is confusing if you do look at half the resources on the Internet & in books which match the RFC 793 and the other half do not, and in Wikipedias case, without explanation or citation. I am not going to commit suicide if it is not changed, but this is my simple suggestion to hopefully create a better, more authoritative article. --Whisper555 03:29, 4 July 2007 (UTC)

Sorry, I was just threatening to be aggressive (isn't that recommended by the Wikipedia guidelines? :-)) I compared the wikipedia diagram with the RFC793 diagram in section 3, page 14. I see two differences that are completely inconsequential as far as correctness and a third that is indeed interesting but only to people who really care: (1) the spacing on the wikipedia diagram gives the visual impression that the first 16 bits of each word are longer than the last 16 bits, which is obviously not true and I assume not intended, and redrawing the diagram to fix that would definitely be good and (2) the padding field that's included in the RFC is missing here (the padding field documents the fact that if the options don't end on a word boundary, then padding is inserted - seems likely to be confusing to lay reader since padding is likely not to be there in any given packet). The other difference is that two flag bits have been added to the flags field, using a couple of the reserved bits. Let me congratulate you, picking up these two bits takes incredibly careful reading!! Because it incorporates these bits, the wikipedia diagram is more up-to-date than 793 (as is to be expected, since 793 is really old and has been updated by several subsequent rfc's). Take a look at RFC 3168, The Addition of Explicit Congestion Notification (ECN) to IP. Omigod that's mean - the title really doesn't give you a clue about the change to TCP. You should be able to find this kind of change by following the "updated by" links in the index to RFC's. But then again, if you do this and look at the title.... you probably just keep looking. As to textbooks, some are more up-to-date than others; also, I don't think 3168 is a standard yet, it's just an RFC. And versions of TCP that incorporate ECN should be backwards compatible anyway. And not all versions of TCP will incorporate it even after it's a standard. Sigh, life is so complicated. Ngriffeth 19:32, 11 July 2007 (UTC)

The above discussion actually supports my argument. It's hard to track the changes to RFC's, and it's an unnecessary burden in maintaining a wikipedia article, which (correct me if I'm wrong) is intended for a layperson, not an expert. Only an expert needs the level of detail we just got into. Also, back to my biggest concern, even if the diagrams are appropriate it's a bad idea to confound the IP and TCP headers this way. Convinced yet? (Excuse my verbosity, I'm just excited to talk to someone who cares about this stuff :-). ) And I'm definitely open to leaving it if there's a chance it could be more useful than a link to the IETF. Ngriffeth 19:32, 11 July 2007 (UTC)

I tried to clarify as best I could by adding headers to the TCP header tables, and breaking them into sections. --Unixguy 15:01, 13 July 2007 (UTC)

Yes, that helps. I'm gong to put in a pointer to RFC 3168 for the flag fields. Ngriffeth 17:15, 13 July 2007 (UTC)

1. Great work. 2. I'm so evil. :) There are so many threads on forums around the world, you all have probably been involved yourselves at some point, where people either complain about their high speed broadband not downloading at the speeds they expect, OR their little Gigabit home networks fail to run at true Gigabit speeds and they don't know why. The explanation for how Windowing for high speed high latency (in relative terms) as set out in http://tools.ietf.org/html/rfc1323 leaves a bit to be desired, especially in reagards to what gets changed in the TCP Segment when rfc1323 is implemented at both ends. Surely it must be possible to provide a decent explanation in more or less the same amount of words / space as is currently alloted to http://en.wikipedia.org/wiki/SYN_Packet#TCP_window_size . This article is marked as confusing or unclear for some readers before I showed up, so lets see what we can do, hey? That is to say, I have some technical knowledge about TCP-IP and I will try to bring to your attention sections that make me feel I know less than I did, before I read that section, that is to say, if somebody who supposedly has idea of what something is, is confused, hows your regular wikipedia reader going to fair?. :) --Whisper555 18:23, 31 July 2007 (UTC)

I tried to address the problem with the field sizes appearing wrong, by making each bit the same size. Someone decided that stacking the bit numbers vertically was confusing, so I used <tt> (and &nbsp; for 1-9) to get consistent sizing back. I'm not sure I like that as well as I did the stacked numbers. Sample:

                  1 1 1 1 1 1 1 1 1 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9

Is this really that hard to understand? The Monster (talk) 23:37, 18 September 2009 (UTC)

acknowledgemnts

The sender keeps a record of each packet it sends, and waits for acknowledgment before sending the next packet.

This sentence is misleading. Modern TCP implementations will send multiple packets before waiting for an acknowledgment. --Jeoth (talk) 04:18, 19 December 2009 (UTC)

UDP checksum is required in IPv6

Section 4.3 says that UDP checksums are optional. This is true for IPv4, but not for IPv6. 130.221.224.7 (talk) 02:51, 11 March 2011 (UTC)

I removed the UDP comparison. It didn't seem necessary. Correcting it would have brought us even further off point. --Kvng (talk) 02:45, 13 March 2011 (UTC)

IP component to complemet IP

I read right in the beginning: "TCP is one of the two original components of the suite, complementing the Internet Protocol (IP), and therefore the entire suite is commonly referred to as TCP/IP." Are you ok? Somebody is loosing fuck*** ground here. --Javalenok (talk) 12:59, 28 April 2011 (UTC)

Unclear section 4.10 Connection Termination

Whoever added the last part in Connection Termination, can you please add some more details. I have a graduate degree in CS, but I still did not clearly understand this part: "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." The example code is showing how NOT to do it, can you also post how to DO it? Also more clarification needed here: "For a usual program flow like above, a TCP/IP stack like that described above does not guarantee that all the data arrives to the other application." Thanks. — Preceding unsigned comment added by 64.134.66.244 (talk) 00:14, 12 July 2011 (UTC)

TCP is used in internet radio, but not always for multi room audio

Just to document edit. Internet radio uses TCP. Most internet radio stations are played with a delay, thus TCP packet recovery can be used. For Multi room audio (such as in Sonos, Streamium, Apple Airtunes) UDP makes for a simpler implementation. However some systems will still use a TCP implementation since it reduces the implementation overhead. For this you need to synch clocks — Preceding unsigned comment added by Ursushoribilis (talk • contribs) 09:10, 21 August 2011 (UTC)

"TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another"

This is wrong and need to be corrected. http://www.stratus.com/blog/openvos/?p=749 --Frederico1234 (talk) 13:58, 1 September 2011 (UTC)

Category for discussion: Category:TCP/IP -> TCP / Transmission Control Protocol

Everyone kindly is invited to take part in the discussion to rename Category:TCP/IP, please see: Wikipedia:Categories for discussion/Log/2012_August_9#Category:TCP/IP. -- intgr [talk] 16:07, 13 August 2012 (UTC)

Error on Nagle

This article states that Nagle is an algorithm for avoiding the silly window syndrome. That is just plain wrong, and should also be obvious if you follow the link to the Nagle algorithm, which describes it. Nagle is for avoiding silly small packets, not silly small windows. There is a very important difference between these, as they occur for very different reasons. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)

You're right. I've removed this erroneous comment. — Preceding unsigned comment added by 2001:468:C80:4391:B565:DD4A:186C:BBFC (talk) 16:08, 23 April 2013 (UTC)

Sequence number - in bytes?

Why does the sequence number label bytes of a packet, rather than each packet as a whole? When would that complication ever be useful? I've looked all over for the answer to this and I haven't found it. The only thing I can think of is if an end system received *part* of a packet, a part that had the full header and only some of the data. Then the receiving party could send back a sequence number that was supposed to be in the middle of a packet. However, this seems like something that probably isn't done in reality. Anyone with some ideas? Fresheneesz 20:06, 8 November 2007 (UTC)

RFC 3168 suggests it helps with spoof prevention. It also helps simplify the receiver since when packets arrive out of order, it doesn't have to queue and map them into the destination message: it can simply use a (validated) sequence number for the location within the message buffer. That simplifies SACK as well. —EncMstr 20:46, 8 November 2007 (UTC)

The reason that TCP sequence numbers are in bytes is that you don't have a proper mapping between packets and bytes. Consider a scenario where you send a packet containing 10 bytes. That packet is lost. After a while retransmission occurs. But, by now you have an additional 10 bytes to send. This means that the retransmission will hold 20 bytes, and not the 10 of the first transmission. Which sequence number should you use for this retransmission? The same as the original packet? If so, then the ACK that comes back might be for either only 10 bytes, or possibly for 20.

While I like the argument here; as I understand it, this is not how TCP works according to the original RFC. Segments are put on a retransmission queue, and when the timer goes off, the segment is retransmitted exactly as it was sent out in the first place. Is the behaviour you describe here specified somewhere else as an extension to the protocol? Or is it an optimisation used only in (certain) implementations? I'm interested to know so if anybody has a word on this, please contact me. — Preceding unsigned comment added by Lars nl 1 (talk • contribs) 12:55, 30 May 2013 (UTC)

If, on the other hand you use a new sequence number, how would the receiver then know that we skipped a sequence number in the packets?

In short, if you were to use sequence numbers on packets, then you would severly reduce the flexibility and the performance of TCP. (bqt@softjar.se) --213.65.173.92 (talk) 11:13, 7 September 2008 (UTC)

Labeling the bytes is also nicely consistent with TCP's providing a byte stream rather than a message stream. And while almost nothing ever uses it, labeling the bytes probably also helped simplify Out Of Band data processing. Perfgeek (talk) 00:07, 10 August 2009 (UTC)

Octets vs. bytes

This article uses both terms. Should we choose one or the other. Please discuss at Wikipedia_talk:WikiProject_Computing/Computer_networking_task_force#Octets_vs._bytes. ~KvnG 14:20, 16 August 2013 (UTC)

Choice of diagrams

There are two versions of the TCP state diagram in this article, File:Tcp state diagram fixed.svg (currently used) and File:Tcp state diagram fixed new.svg (currently up for deletion). For those who cannot see the difference, the second has an ACK/- on the transition between Closing and Time/Wait on the "Active Close" path. I'm not really much of an expert, but I think that is the correct version - with my opinion influenced by de:Transmission Control Protocol, which uses File:Tcp_verbindung.png, which has the ACK/- in question. Can we get a consensus on which of the images to use? --Stephan Schulz (talk) 11:27, 4 January 2014 (UTC)

The new diagram is correct. The non-bold "ACK/-" means that an ACK message is received, and that no message is sent; it is the receipt of an ACK that causes the transition from CLOSING to TIME WAIT. The source is RFC 793 (hard-to-read ASCII art), and a clearer diagram (which a quick look makes me think is correct) is here. Johnuniq (talk) 00:09, 5 January 2014 (UTC)

Misleading coloring of checksum

The use of the same color of the IP pseudo header and the TCP checksum is very misleading. The checksum must have a different color than the IP pseudo headers. --178.197.225.145 (talk) 13:44, 14 January 2014 (UTC)

Color changed, however the text describing the calculation of the TCP checksum is still not clear. I needed to do an intrernet search to find out how it really works, I found this useful site: http://www.daemon.org/tcp.html

There it says: "checksum (16 bits) A sixteen bit checksum on the tcp header (including, of course, any tcp options that are present), data, and a 96 bit pseudo header made up of..." which sounds a lot more clear to me than : "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 octetispaddedon the right with zeros to form a 16-bit word for checksum purposes. [...]" I mean, what the heck is "text"?!?! --178.197.225.145 (talk) 13:57, 14 January 2014 (UTC)

This page.

Reading this page just made my brain leak.--163.248.159.162 (talk) 18:32, 3 September 2008 (UTC)

Yeah, it' unfortunately bad written. --178.197.225.145 (talk) 14:05, 14 January 2014 (UTC)

uhhh. what?

"If the SYN flag is clear (0), that a packet with Congestion Experienced flag in IP header set is received during normal transmission (added to header by RFC 3168)."

This sentence makes no sense... — Preceding unsigned comment added by 24.246.4.28 (talk) 14:04, 24 September 2011 (UTC)

Many sentences in this article make no sense whatsoever. I don't want to offend anybody, but some things should be rewritten for that at least English speaking tech (!) people can understand it. --178.197.225.145 (talk) 14:08, 14 January 2014 (UTC)

Orphaned article about to be deleted

Dear editors, there is an orphaned article called TO-TCP (terminal originated TCP) that has been marked for deletion. Do any of you see any reason to rescue it? Thanks in advance. TheAMmollusc (talk) 11:54, 15 May 2014 (UTC)

Broken link in "Other"

The link to visualland.net seems to be broken, which is a shame as animations are always useful. We should consider removing the link. Kthelgason 22:44, 18 September 2014 (UTC)

sequence number

Today Sequence number redirects here to Transmission Control Protocol.

Is there a more general article that discusses sequence numbers, that would be more appropriate for sequence number to redirect to? While the most common sequence numbers may be TCP sequence numbers, I see that many other Wikipedia articles mention sequence numbers of various sizes -- alternating bit protocol, B protocol, High-Level Data Link Control, etc. -- none of which are TCP sequence numbers.

My understanding is that many of those protocols are examples of a sliding window protocol.

A few Wikipedia articles mention sequence numbers that are used in things that don't seem to be a sliding window protocol, such as YAFFS and Common Log File System.

Is TCP a sliding window protocol? (One commenter at talk: sliding window protocol seems to think it is not).

Is there a more general article that would be better for sequence number to redirect to, perhaps an article that discusses a more general category of things that use sequence numbers? --DavidCary (talk) 18:39, 4 February 2015 (UTC)

Perhaps it should be a disambiguation page instead? Or at least start it that way, to see what different kinds of sequence numbers show up and if a general article on the topic even makes sense. -- intgr [talk] 19:12, 4 February 2015 (UTC)

Agreed. @DavidCary: Hope you don't mind but I edited your comment to use {{no redirect}}. Yes, TCP uses a sliding window and it is quite likely that a technical person wanting information about "sequence number" on the Internet is thinking of its use in TCP. However, as you say, there are lots of other topics. A dab page to start would be best. Johnuniq (talk) 09:02, 5 February 2015 (UTC)

Denial of service

I think the phrase "purposely assembled SYN packets" should be replaced with "degenerate SYN packets" in this section as this would more accurately convey that the such packets are malicious and not conformant to the relevant standard semantics. — Preceding unsigned comment added by JimD (talk • contribs) 00:48, 20 June 2015 (UTC)

TCP ports

Regarding

Port numbers are categorized into three basic categories: well-known, registered, and dynamic/private.

It seems like it might make sense to link to Portmap and possibly even the "little used" TCP Port Service Multiplexer pages as examples of dynamic port usage (with liaison on a well-known port). JimD (talk) 00:56, 20 June 2015 (UTC)

TCP v4 ?

The article refers to RFC 793 as "TCP v4" in two places. Why? I've heard TCPv4 used, rarely, to mean "TCP on top of IPv4", as opposed to "on top of IPv6", but I'm not sure that's what the article is aiming for. It's not particularly interesting either. The RFC itself doesn't mention "v4" or "version 4". And it sure doesn't claim there were ever any TCP v1, v2, or v3.

JöG (talk) 20:53, 12 November 2008 (UTC)

TCP v2 and TCP v3 are defined in the IEN (internet experiment note) series which has quite a bit detail about the early evolution of TCP. 85.212.91.129 (talk) 13:06, 29 November 2015 (UTC)

Maximum Segment Size

When you read this section "Furthermore, TCP senders can use path MTU discovery to infer the minimum MTU along the network path between the sender and receiver, and use this to dynamically adjust the MSS to avoid IP fragmentation within the network.", you can say it implies that:
1. MSS can be derived from the Path MTU 2. MSS can be adjusted after it is sent to the other end.
MSS can be calculated based on the MTU of the locally attached network, and not the minimum MTU along the path (PMTU). MSS can not be adjusted after it is sent (only) in the [SYN] packets during the three-way handshake. So better to change the lines or the wordings. — Preceding unsigned comment added by WikiJackool (talk • contribs) 05:01, 16 January 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Transmission Control Protocol. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive http://web.archive.org/web/20110312114242/http://www.ilmondodelletelecomunicazioni.it:80/english/telematics/protocols.html to http://www.ilmondodelletelecomunicazioni.it/english/telematics/protocols.html

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 14:52, 27 February 2016 (UTC)

Termination: a three- or four-way handshakes

There was a point of contention regarding the number for describing the handshake process in the connection termination. Someone recently reverted an edit to say it is four, not three.

The teardown seems to be very similar to the setup: Each side sends a FIN and responds with an ACK, making the process:

1. Side A sends a FIN packet 2. Side B responds with an ACK/FIN 3. Side A responds with an ACK

This seems the most likely way most teardowns operate. A half-open connection where B acknowledges without sending the FIN could cause it to be four-way, of course, but this seems rather rare. Perhaps it could be:

"three- or four-way depending on the first response."

--Kevin L'Huillier 02:41, 10 March 2006 (UTC)

It's a 3 way handshake. Every scintilla of literature on the subject refers to it as a 3-way handshake. Raul654 02:48, 10 March 2006 (UTC)

Okay. I will revert the revert, but also add that it could take four steps if it is intentionally left half-open. --Kevin L'Huillier 04:47, 10 March 2006 (UTC)

Yes, it's commonly a 3-way handshake by combining the FIN & ACK together. However, the process is really a 4-way (FIN1, ACK1, FIN2, ACK2) and the 3-way is merely an "optimization".

To me, a "way" in handshake is an agreement of the state of a channel. Prior to closing either end the channel is open. The first FIN indicates the sender has closed its end. The corresponding ACK acknowledges the state (2 ways). At this point the state is agreed to be half-open. The non-initiator can optionally bundle its FIN with the ACK if it has nothing to send (why would you send 2 packets when you can send one???). Finally the initiator ACKs the non-initiators close. So, in all, it is a 4-way handshake — there are four steps to completely close a connection.

On a related tangent, an ACK is a 2-way handshake. The sender's data is acknowledged thus "stating" that the data has been received. The ACK is usually bundled with other data because there's no reason to transmit a separate packet for a flag and a few bytes. The 3-way handshake is the exact same scenario: just bundling an ACK on some sender's data (a FIN).

Raul, every scintilla? You might try the TCP/IP Protocol Suite by Forouzan (ISBN 0-07-246060-1) on page 328 (2nd ed). It describes it as a four-way handshake.

Regardless, I believe my version is down the correct road. Explain it all sufficiently so the reader understands it and can take it as they please. Saying it's a 4-way because that's what it is, and adding that there are common optimizations is the best approach. Cburnett 01:12, 11 March 2006 (UTC)

Additionally, Raul, look at the very RFC that defines TCP: RFC 793. Page 23 shows the state diagram for TCP. There are two paths:

• 3 transitions and 4 states: ESTABLISHED -> FINWAIT-1 -> FINWAIT-2 -> TIME WAIT
• 3 transitions and 4 states: ESTABLISHED -> FINWAIT-1 -> CLOSING -> TIME WAIT

The first path is the non-initiator closing after the initiator closes. The second path is the case when both ends close simultaneously (both receive the FIN before receiving their ACK). So it's clearly a 4-way: the reception of an ACK is distinct from receiving the FIN. Cburnett 01:28, 11 March 2006 (UTC)

Even-more-additionally: The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference by Charles Kozierok (ISBN 159327047X) describes it as a pair of two-way handshakes. Cburnett 04:37, 12 March 2006 (UTC)

Everyone has made good points.

A related question is: Why is the establishment considered three-way? It is conducted in a very similar manner ie. it could be SYN, ACK, SYN, ACK instead of the usual SYN, SYN/ACK, ACK. Should it be considered a pair of two-way handshakes, and therefore four-way as well?

--Kevin L'Huillier 03:01, 28 March 2006 (UTC)

I guess I'd have to wager it's not a 4-way because whether or not the SYN/ACK is split up the connection cannot continue. If A SYNs and B ACKs then A cannot send data because it hasn't ACK'ed B's SYN. Regardless, one or two packets for the SYN/ACK doesn't change the connection state: A cannot send until it's ACK'ed B's SYN.

This contrasts highly with termination where B can still send data to A until B sends a FIN to A. There is clearly a state change (A can no longer send data) that doesn't exist in connection establishment.

I have also never seen the connection be referred to a 4-way. Not wanting to fall into the argumentative trap Raul fell in, I'll point out tha if connection were considered a 4-way then I'd beleve that would come from the same sources that say termination is a 4-way handshake but they don't. They all say 3-way.

So it's not the number of packets or flags sent, but the number of state changes that matter. Cburnett 04:16, 28 March 2006 (UTC)

Ah, that makes perfect sense. Thank you. --Kevin L'Huillier 18:14, 29 March 2006 (UTC)

I believe the answer to these questions are as follows:

• A connection is 3-way. There is no implementation of a 4-way handshake for connection establishment and that would most probably be wrong. Nodes A and B sending pure SYN packets would indicate the initiation of two connections (with the same port pair). Only one of them will succeed. A responding SYN *must* have the ACK bit set and the proper ACK# in the segment to indicate and prove that it is a response to the initial SYN. A responding SYN without the ACK cannot prove that is a response to the initial SYN (as the ACK# would be ignored without the ACK bit).
• A termination is a 4-way process that under certain conditions can be compressed to 3 packets. Termination is a two-way process as already mentioned above: One end indicates that they have nothing else to transmit and the other acknowledges that, indicating that it received all data, including the FIN. The receiving end of the first FIN *may* indicate a termination on their side too by adding the FIN to the ACK, but that situational. I believe that this can be caused only by delayed ACKs and retransmissions. E.g. when the ACK to a FIN is delayed enough so that a FIN also becomes available (but I guess that's implementation specific). To fully understand this you need to understand how the FINs originate: FINs are sent when an application calls shutdown() for their transmitting side (or close() on the socket). Now picture two applications working over the Internet: It is not practically possible for them to simultaneously close the connection, meaning that one will close first. In all such cases, where delayed ACKs and lost packets don't come into play, there will be 4 packets transmitted.

Sharhalakis (talk) 00:06, 24 March 2016 (UTC)

Confusing table

That table showing tcp content is confusing. It is using octets, bits and offsets but you can figure out which is which. Colums and rows are impossible to follow and read corectly. — Preceding unsigned comment added by 86.123.128.88 (talk) 13:00, 13 April 2016 (UTC)

If you're talking about Transmission Control Protocol#TCP segment structure, I think it's fairly clear. Each row is 32 bits (4 octets) and the columns refer to bits or fields within each 32-bit unit. This is also the same format how the RFC specifies the TCP header. If you have suggestions for improving it, go ahead. -- intgr [talk] 11:49, 14 April 2016 (UTC)

Forcing data delivery section is wrong

There's no 200ms delay on send. That's the "delayed ACK" timer, which is at the receive end. TCP does not have an accumulation timer, like an X.25 PAD does. This only affects special situations where the sender sends multiple small packets which don't generate responses. It doesn't affect bulk file transfers. John Nagle (talk) 23:29, 18 August 2016 (UTC)

It's possible to meet very informed people at Wikipedia! I once had a reasonable grasp of Nagle's algorithm but that was years ago, and only as a user of TCP/IP. I see that the wording is wrong—I guess the point they attempted to make is that if a process at A sends 1 byte to TCP for delivery to B, then B will wait for 200 ms before replying with an ACK (assuming no data from B to A is sent). Meanwhile, assuming the process at A sends more, the TCP at A will wait for the ACK before sending the additional data. So, after the first byte, there is a delay before another byte is sent, and the delay may be up to 200 ms plus round-trip time. Any chance of some suggested wording to fix the section? Johnuniq (talk) 11:17, 19 August 2016 (UTC)

Right. But that delay only applies to packets smaller than the maximum packet size. If there's enough data to fill a packet, it goes out anyway. This is done to prevent sending lots of tiny packets instead of one big one. John Nagle (talk) 06:41, 20 August 2016 (UTC)

Understood—it's hard making a simple statement about TCP that covers all cases! Johnuniq (talk) 07:01, 20 August 2016 (UTC)

Resource usage

" [...]the client must allocate a random port before sending the first SYN to the server. This port remains allocated during the whole conversation, and effectively limits the number of outgoing connections from each of the client's IP addresses. If an application fails to properly close unrequired connections, a client can run out of resources and become unable to establish new TCP connections, even from other applications."

This part is not clear -- how is the fact that the client allocates a port upon connection "effectively limits the number of outgoing connections from each of the client's IP address"? Is it because there is a "limited number of ports"? What limit is refereed to here? YuvalAloni (talk) 17:44, 20 December 2016 (UTC)

It's a long time since I thought much about TCP but I think the text is based on the premise that a server is probably running a small number of well-designed applications where things that are opened are eventually closed, so the server is good. However, anyone can write code for a typical client, and bad code might not close connections. The port is specified with a 16-bit number, so 65536 ports are available for TCP at a server and at a client. That is the limit, and really broken software could use all the ports which would prevent further connections. The same consideration applies at the server which generally listens on port 0. However, the server will establish a TCP connection on a randomly chosen port so there is no difference between the server and client. Johnuniq (talk) 03:29, 21 December 2016 (UTC)

Protocol Operation

Could someone please tell why only TIME_WAIT is marked "either server or client"? Is there any problem if we state "both server and client" for this one too? --Kuratowski (talk | contribs) 11:10, 3 October 2017 (UTC)

TCP state diagram be useful?

After pondering this for a while, I'd say "no", because I think it would be too detailed for Wikipedia. We're not supposed to be an expert-level reference work - that's what "Further reading" and "External links" are for. I mean, do we really want to get into "Fin-Wait-1" and such things here? I think not... Noel 13:01, 4 Oct 2004 (UTC)

I think the answer is YES! A diagram would be the most concise and useful expression which shows how TCP really works. By your arguement, the whole listing of the states in TCP in words should be deleted. I feel that Wikipedia readers that come to the very detailed page, should get a proper diagram of the TCP state machine. Note also that the graphic in RFC 793 is text-based and very hard to read. Wikipedians deserve a really nicely drawn one. Mike 4 Jan 2005

I agree that the state diagram is useful. However it only includes the set up and tear down phases of TCP - it doesn't expand on the "data transfer" state, which should have data ACK and ACK states showing the data flow. 22 Nov 2006

This is an issue. The so called state diagram popularized in network books are highly simplified view- though none of the books makes it aware to their readers and propagate the myth that this diagram is actually the TCP state diagram. Indeed, all it illustrates are the connection establishment and connection closing part of TCP and leaves out all states. The states pertaining to its real run time operation has been lumped in just one box - ESTABLISHED. But it has been taken care of. In 2005 a detailed state diagram has been created from the original RFC and drawn using formal EFSM language. A pointer to it exists in the external reference section. Thanks. JIK 2007.

NB - That EFSM document is pretty rubbish, it contains dozens of errors. The connection establishment flow doesn't work because the flow diagrams don't check that the outstanding SYN has been acknowledged before transitioning to ESTABLISHED; the closing handshake doesn't work because the FIN packets omit ACK, which would cause them to be dropped by the receiver... it's a real mess, I don't know how the authors arrived at it, but it clearly wasn't double-checked against a working/functional TCP implementation. We should remove the links to it I think, it's misleading. 2A02:390:A001:192:D6BE:D9FF:FE9C:1892 (talk) 16:51, 29 April 2019 (UTC)

IMHO the simplified state machine is useful, but it lacks a transition: from the LAST ACK state to the CLOSING state, the endpoint has to receive an ACK segment in order to change its state. Andrea Spadaccini, 2008. —Preceding unsigned comment added by 151.97.6.24 (talk) 09:52, 27 August 2008 (UTC)

Paragraph "Data Transfer" is duplicated

The paragraph "Data Transfer" appears twice in the article, once in its own paragraph and once under Connection Termination further down,

I have checked this item and I propose mark it as

Resolved

.--Jimmy Olano (talk) 18:49, 4 August 2019 (UTC)

Adequate summary

Problem:

I propose translate from the french Wikipedia Transmission Control Protocol (according to the licensing rules):

Transmission Control Protocol (TCP)is a reliable, connected-mode transport protocol documented in IETF, RFC 7931.

In the Internet model, also known as the TCP / IP model, TCP is located above IP. In the OSI model, it corresponds to the transport layer, intermediate of the network layer and the session layer. Applications transmit streams of data over a network connection. TCP breaks the octets stream into segments whose size depends on the MTU of the underlying network (data link layer).

TCP was developed in 1973 and then adopted for ARPANET in 1983, replacing NCP (RFC 8012).

Plase consider it, thanks! --Jimmy Olano (talk) 18:41, 4 August 2019 (UTC)

I don't think we would improve things by replacing the current lead with what you propose. Maybe we could merge the two together. The real problem here is that, while what we have is a competent high-level description of TCP, we're missing a summary a lot of the content in the body of the article. ~Kvng (talk) 13:31, 7 August 2019 (UTC)

You are right: I want substitute the summary, I am using only the WP:TECHNICAL style. Let's wait and think better, meanwhile others wikipedians may contribute too; have a nice day!--Jimmy Olano (talk) 14:03, 7 August 2019 (UTC)

Do the changes since this post constitute a good enough summary to remove the tag? Rauisuchian (talk) 00:47, 27 December 2019 (UTC)

I think it's good and removed the tag, thanks. Johnuniq (talk) 02:51, 27 December 2019 (UTC)

"TCPSTACK" listed at Redirects for discussion

An editor has asked for a discussion to address the redirect TCPSTACK. Please participate in the redirect discussion if you wish to do so. Steel1943 (talk) 07:23, 26 January 2020 (UTC)

Possible reverse copyvio

This page by Vskills seem to derive from the Connection establishment to the Connection termination sections, without crediting the editors of those sections or linking to this article. Major contributors to those sections, as well as the uploader of File:TCP CLOSE.svg might want to talk to the website's admin about it. pandakekok9 (talk) 11:42, 23 July 2021 (UTC)

What about time arrows on sequence diagram?

Is it possible to add arrow heads and labels (t for time) at bottom of the Connection termination figure, which is a sequence diagram? This would help clarity. — Preceding unsigned comment added by Brutzman (talk • contribs) 15:49, 6 August 2021 (UTC)

@Brutzman: Time increases in the down direction in these diagrams but not necessarily in proportion to distance. It is describing a sequence of events one following another as per the indicated arrows. If we turned it upside down or sideways, it would still make sense without labeling time. ~Kvng (talk) 18:00, 13 August 2021 (UTC)