Talk:Transmission Control Protocol

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)

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.

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)

Checksum

The TCP checksum -- isn't it more properly referred to as the one's complement of the one's complement sum? In any case, I'm removing the link to one's complement in the article, because that gives a *very* misleading impression of how to calculate the checksum.--Ryan Stone 19:01, 8 Nov 2004 (UTC)

RFC 793 calls it the one's complement of the one's complement sum, so that's what I'm putting in the article.--Ryan Stone 19:08, 8 Nov 2004 (UTC)

Yes, it's the complement of the sum, so that when you receive a packet, you don't have to zero out the checksum field (after first storing the checksum), and then compare the checksums afterwards - you just sum up the packet, with the received checksum in situ, and the resulting sum should be 0 (actually all 1's, which is also zero in one-comp notation - there's no way to add up any sequences of non-zero numbers and get 0 as the result in one's-comp addition, due to the wrap-around add of the carry). I'll add this to the article, along with why we used a ones-comp sum to begin with. Noel (talk) 14:22, 14 Nov 2004 (UTC)

---

Is it really appropriate to have the ellipsis after the Network Layer enumeration of IPv4, IPv6, and ARP? Are there really other network layer protocols?

TCP windows or Windows' TCP

In the paragraph titled TCP window size: "The Windows TCP/IP stack is designed to self-tune itself" - do you mean Microsoft Windows ? (Since "window" generally means something else in this paragraph). If yes, make it explicit. If no, why the word order and capitalization?

This confused me too, so I googled the phrase. It looks like that paragraph was ripped off of [Microsoft] (I really doubt the other way 'round....). Anyway, in the context of the microsoft article, it clearly refers to Microsoft Windows 200x.

Ah, both the Window scaling and the Window size sections are ripped off of that MS article. Probably more.

Jeff 02:11, July 12, 2005 (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)

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)

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,

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?

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)

Poor definition methodology

Just making a simple observation: Several examples in this article casually use the accronym TCP in its own definition, which is generally considered poor practice. E.g. ...Any SYN packet holds Sequence Number. The Sequence Number is a 32-bit field TCP segment header...

In this case it could be considered confusing to the laymen to use the subject of the article in its own definition.

Comment: But does it really matter? Laymen wouldn't understand the details of the protocol anyway...and are probably not interested in try to understand them. —Preceding unsigned comment added by 74.93.1.129 (talk • contribs)

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)

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)

Few responses to above

As someone who originally did much of this article, I'd like to challenge the whole notion of 3-way and 2-way termination handshake. I don't believe that is really any such thing, I think what this is, is some stacks "cheating", but I'll dig into it to verify. And the 2-way handshake, that certainly sounds made up. Going by the state diagram and calling it 2-way or 3-way based on that is a bit misleading I think. In any case, I don't believe anyone ever refers to the connection termination as a handshake and pretty sure never a 3-way or 2-way handshake, but I'm prepared to be proven wrong. ...and we refer IP datagrams, UDP messages and TCP segments, but most people tend to say "packets" and that is generally fine unless one is being particularly pedantic. It looks the article needs some other minor updates since I last looked and I'll try to do my share soon.

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)

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)

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)

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)

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)

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)

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)

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.

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)

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)

This page.

Reading this page just made my brain leak.--163.248.159.162 (talk) 18:32, 3 September 2008 (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)

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)

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)

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)

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...