185

The TCP 3-way handshake works like this:

Client ------SYN-----> Server
Client <---ACK/SYN---- Server
Client ------ACK-----> Server

Why not just this?

Client ------SYN-----> Server
Client <-----ACK------ Server
Ron Maupin
  • 99,565
  • 26
  • 120
  • 195
smwikipedia
  • 1,963
  • 3
  • 13
  • 9
  • 39
    Why do we even need a handshake? Why can't the message be sent with the first packet? – user541686 Nov 04 '15 at 20:50
  • 6
    If you want to skip the handshake you could use UDP instead. – OzNetNerd Nov 04 '15 at 22:26
  • 6
    @Mehrdad, if you have a question of your own, please use the Ask Question link at the top of the page to post your own. – YLearn Nov 04 '15 at 23:12
  • 50
    @YLearn: Sorry, it's not really a question of my own, but rather it was to motivate readers to give answers that dig a little deeper than what is literally stated in the question. – user541686 Nov 05 '15 at 00:03
  • 6
    Don't forget about TCP Fast Open (RFC 7413) – Alnitak Nov 06 '15 at 23:25
  • QUIC https://en.m.wikipedia.org/wiki/QUIC – kmiklas Mar 05 '18 at 23:16
  • Although the 3-way-handshake might be a waste, I think that it does not matter if the client starts to send data. Think of a simple HTTP request: The client can start to send payload immediately after the ack package without waiting for yet another server response. The bloated HTTP headers might be a much larger waste. – Mike76 Oct 03 '18 at 22:05
  • Better question is to ask why not 4-way handshake? – generalnetworkerror Jul 21 '21 at 01:32

9 Answers9

238

Break down the handshake into what it is really doing.

In TCP, the two parties keep track of what they have sent by using a Sequence number. Effectively it ends up being a running byte count of everything that was sent. The receiving party can use the opposite speaker's sequence number to acknowledge what it has received.

But the sequence number doesn't start at 0. It starts at the ISN (Initial Sequence Number), which is a randomly chosen value. And since TCP is a bi-directional communication, both parties can "speak", and therefore both must randomly generate an ISN as their starting Sequence Number. Which in turn means, both parties need to notify the other party of their starting ISN.

So you end up with this sequence of events for a start of a TCP conversation between Alice and Bob:

Alice ---> Bob    SYNchronize with my Initial Sequence Number of X
Alice <--- Bob    I received your syn, I ACKnowledge that I am ready for [X+1]
Alice <--- Bob    SYNchronize with my Initial Sequence Number of Y
Alice ---> Bob    I received your syn, I ACKnowledge that I am ready for [Y+1]

Notice, four events are occurring:

  1. Alice picks an ISN and SYNchronizes it with Bob.
  2. Bob ACKnowledges the ISN.
  3. Bob picks an ISN and SYNchronizes it with Alice.
  4. Alice ACKnowledges the ISN.

In actuality though, the middle two events (#2 and #3) happen in the same packet. What makes a packet a SYN or ACK is simply a binary flag turned on or off inside each TCP header, so there is nothing preventing both of these flags from being enabled on the same packet. So the three-way handshake ends up being:

Bob <--- Alice         SYN
Bob ---> Alice     SYN ACK 
Bob <--- Alice     ACK

Notice the two instances of "SYN" and "ACK", one of each, in both directions.

So to come back to your question, why not just use a two-way handshake? The short answer is because a two way handshake would only allow one party to establish an ISN, and the other party to acknowledge it. Which means only one party can send data.

But TCP is a bi-directional communication protocol, which means either end ought to be able to send data reliably. Both parties need to establish an ISN, and both parties need to acknowledge the other's ISN.

So in effect, what you have is exactly your description of the two-way handshake, but in each direction. Hence, four events occurring. And again, the middle two flags happen in the same packet. As such three packets are involved in a full TCP connection initiation process.

Xavi
  • 103
  • 4
Eddie
  • 15,026
  • 6
  • 44
  • 84
  • 9
    Why do we need ISNs at all? Humans don't need it, why do computers? Is there a proof of this, or do we just have them because they're convenient? – user541686 Nov 04 '15 at 20:52
  • 36
    @Mehrdad: You need sequence numbers for retransmissions to work properly (or indeed at all). The ISN can't just be zero because of sequence prediction attacks. – Kevin Nov 04 '15 at 21:04
  • 2
    @Mehrdad Two humans talking have non-verbal and visual queues to indicate reception of a message. Nodding, or affirming, or even sometimes repeating what the speaker said. Where as two computers talking are like two humans with no functioning senses except for hearing. Think of the theory of it, how would you devise a set of rules which both speakers and receiver could follow, that would guarantee the reception of each message, in the right order, and re-transmit as necessary when something didn't get through. You'll find you end up at a solution that will work just like Sequence numbers. – Eddie Nov 04 '15 at 21:37
  • 1
    @Eddie: But: "that would guarantee the reception of each message"... that's not something you can ever guarantee with an algorithm either, so that's a moot point. Furthermore, are you telling me that you can't tcommunicate purely verbally with those around you without a SYN-ACK-SYNACK sequence? Like, when someone asks you a question from a nearby cubicle, you don't understand what they're saying unless they say "hello" and you say "hi" back first? – user541686 Nov 04 '15 at 21:40
  • @Mehrdad Maybe guarantee the reception isn't the right phrase, but guarantee the awareness that the message has either been received, or not received, and react appropriately. Either way, you're asking great questions, but the comments might not be the ideal way to talk through them. Shall we continue the discussion in chat? – Eddie Nov 04 '15 at 22:07
  • 1
    @Eddie: I'm too busy for real-time chat unfortunately. I intended these to be somewhat rhetorical question -- I wasn't so much expecting a response to myself, but rather trying to point out that the question deserves a deeper answer than just "because X needs it", since it's not fulfilling if the natural question of "why do we need X?" is left unanswered. – user541686 Nov 04 '15 at 22:13
  • 5
    @Mehrdad The chat room doesn't necessarily have to be 'real time', we can leave messages for each other. The reason I thought to direct it elsewhere is because you are now asking a different question. The OP asked "why is it a 3 way handshake instead of 2", but now you questioning "why do we need Sequence numbers at all", which is different. Rather than derail this thread, I thought we should discuss the other question in chat. Alternatively, you can post a new question, I'm sure it will net some good answers. – Eddie Nov 04 '15 at 22:19
  • @Eddie I just realized that besides the need for sync sequence numbers of each party, there's some logical/psychological reason as well. Only after the active sender got the acknowledgement from the target receiver, can the sender be sure that the message he sent is actually well received by the receiver. So both parties of the communication need to be the active sender for at least one time, respectively. – smwikipedia Nov 05 '15 at 05:09
  • 2
    @smwikipedia Yup, exactly. That is why the ACKnowledgmenet step is to acknowledge with [X+1], or [Y+1]. It proves X and Y were received, confirming to the active sender (as you put it) that full 2-way communication is working. – Eddie Nov 05 '15 at 07:17
  • 5
    Great, concise answer. Reading "ACK SYN" feels fundamentally wrong but you even explained that so +1. – Lilienthal Nov 05 '15 at 12:52
  • @Mehrdad sequence numbers are essential to any stream of data that could arrive out of order, or be re-ordered for efficiency. IP packets are not guaranteed to arrive in-order. SAS/SATA requests are also reordered by drives/controllers and have command numbers for a similar reason. – mikebabcock Nov 05 '15 at 14:28
  • 8
    According to RFC 793, Transmission Control Protocol: "The principle reason for the three-way handshake is to prevent old duplicate connection initiations from causing confusion." – Ron Maupin Nov 05 '15 at 18:05
  • @Mehrdad - people do need sequence numbers (or at least synchronization). Have you never been in the middle of a conversation and someone comes in the middle and says something like "Wait, so he did that thing before she did this other thing or was it the other way around? Most of the time ordering is obvious from contex (and because out of order transmission is rare in spoken conversation), but sometimes resynchronization is necessary. – Johnny Nov 05 '15 at 23:09
  • @Johnny: My point was that it's not necessary to initiate a conversation in many cases. My point was not that there exists no situation in which it's necessary. – user541686 Nov 05 '15 at 23:45
  • @Mehrdad I still think you should ask your questions as their own questions ;), it would bring about some fantastic responses. Even though I know you were only asking to spur depth in answering this question (which honestly, I don't think we quite answered to that level of depth). The attention your questions have gotten definitely deserve their own thread ;). – Eddie Nov 06 '15 at 00:02
  • 1
    @Eddie: Did you consider switching the position of Alice and Bob so that SYN ACK will be in the right order? e.g.: http://paste.ubuntu.com/13124370/ – Paul Nov 06 '15 at 14:24
  • 2
    @Mehrdad Saw this in Hot Questions and wanted to point out: We do have such a feature. In linguistics, one of the purposes of common greetings ("Hi", "Hello", etc) is to acclimate the other person to your voice. – Izkata Nov 06 '15 at 15:00
  • @Paul Brilliant! Took your suggestion. Great call! – Eddie Nov 06 '15 at 17:20
  • 1
    This is not a very good answer. One could easily imagine another reliable-delivery transport protocol wherein both parties start on a common ISN - for example, zero. The OP was asking fundamentally why a three way handshake is desirable, not requesting a rote regurgitation of the particulars of TCP. – Rag Nov 07 '15 at 02:46
  • 1
    @Mehrdad Yes, you can have network communication that works like you think. It's called UDP and it's great for things like streaming video. It occasionaly drops packets, but most of the message gets through most of the time. If you're transfering things that need perfectly accurate transcription, however, (code, finance, documents...) then you need a rigorous protocol. I challenge you to remember your last conversation - word for word, every expression, timing, and piece of body language - and guarantee that you didn't make even the slightest mistake. TCP can do that. ISN is part of how. – J... Nov 07 '15 at 11:08
  • @BrianGordon Well said. It is amazing how people can be experts on a protocol without thinking about why the protocol exists. Se my answer below. – Tuntable May 23 '16 at 02:03
  • This is not an accurate answer. One can develop a protocol that works with a 2-way handshake. Basically, if the SYN/ACK from the Server to the Client is lost, yes, the Client will not know the Server's ISN. But the client can always retransmit its SYN in response to receiving data (ACK packets) from the Server and get a retransmitted SYN/ACK back. No problem here.

    The real reason for the 3rd packet (the ACK from the client to the server) is a proof of IP address ownership. It proves that client has received Server's ISN and the SYN was not a spoofed packet, a part of some DoS attack.

     – igorlord Oct 30 '20 at 16:28
  • @igorlord What if the client means to send data first? It will never get the "first data packet" from the server to prompt a retransmit of the initial SYN. In the end, there are probably multiple reasons for a three-way handshake. My answer outlined (at least) one of them : proves two-way reachability between Client/Server). Proving the client owns an IP address is a perfectly valid reason as well (possibly it is included in the reason I provided). However; I can agree with you on this point: I need to edit this answer to more explicitly highlight the two-way reachability reason. – Eddie Oct 30 '20 at 19:52
  • @Kevin ISN's randomness is not to prevent sequence prediction attacks as you have suggested but to prevent the "same sequence numbers [which] may still be present in the network from an earlier incarnation". See https://retrocomputing.stackexchange.com/a/8610/643 – Bora M. Alper Feb 17 '21 at 11:25
  • @BoraM.Alper the answer you link clarifies the original reason is what you state, but later it was realized they need to pick the ISN more carefully to stop attacks (cryptographically secure randomness). So Kevin was right; he didn't say security was the only reason, only highlighted it as an important reason. – Chan-Ho Suh Aug 20 '23 at 14:48
  • woah. mindblown. i always thought SYN ACK is acknowledging the SYN request and not SYN + ACK commands – ProgramCpp Sep 22 '23 at 14:49
  • @Chan-HoSuh Any source? afaik TCP does not care about security. Security is done at upper layers like TLS – Steve Z Mar 10 '24 at 20:41
28

The three-way handshake is necessary because both parties need to synchronize their segment sequence numbers used during their transmission. For this, each of them sends (in turn) a SYN segment with a sequence number set to a random value n, which then is acknowledged by the other party via a ACK segment with a sequence number set to n+1.

dr_
  • 1,299
  • 1
  • 11
  • 18
26

In order for the connection to work, each side needs to verify that it can send packets to the other side. The only way to be sure that you got a packet to the other side is by getting a packet from them that, by definition, would not have been sent unless the packet you sent got through. TCP essentially uses two kinds of messages for this: SYN (to request proof that this packet got through) and ACK (which only gets sent after a SYN gets through, to prove that the SYN got through). There's actually a third kind of message, but we'll get to that in a moment.

Before the connection starts, neither side really knows anything about the other. The client sends a SYN packet to the server, to request proof that its messages can get through. That doesn't tell either person anything, but it's the first step of the handshake.

If the SYN gets through, then the server knows that the client can send packets to it, because, well, it just happened. But that doesn't prove that the server can send packets back: clients can send SYNs for lots of reasons. So the server needs to send two messages back to the client: an ACK (to prove that the SYN got through) and a SYN (to request an ACK of its own). TCP combines these two messages into one -a SYN-ACK message, if you will- to reduce network traffic. This is the second step of the handshake.

Because a SYN-ACK is an ACK, the client now knows for sure that it can send packets to the server. And because a SYN-ACK is a SYN, it also knows that the server wants proof that this message got through. So it sends back an ACK: just a plain ACK this time, because it doesn't need proof anymore that its packets can get through. This is the final step of the handshake: the client now knows that packets can go both ways, and that the server is just about to figure this out (because it knows the ACK will go through).

Once that ACK gets through, now the server knows that it can send packets to the client. It also knows that the client knows this, so it can start sending data right away. The handshake is complete. We have a good channel.

Well, strictly speaking, we can't be certain we have a good channel. Just because this sequence of packets got through does not strictly guarantee that others will. We can't prove that without sending an infinite number of SYNs and ACKs, and then nothing else would ever get done, so that's not really a practical option. But in practice, three steps turns out to be good enough for most purposes.

The Spooniest
  • 361
  • 2
  • 3
  • This is untrue: "an ACK (which only gets sent in response to SYNs, and thus proves that the SYN got through)."

    Only the first packet sent from each end has the SYN flag set, and all packets other than the very first packet of the 3-way handshake have the ACK flag set. The first packet can't ACK because the second party hasn't SYNed yet, but every packet after the first must ACK whatever has already been received from the other end, whether any data be sent back or not.

     – Monty Harder Oct 31 '16 at 14:43
  • Thanks. Rewording: ACKs get sent once a SYN gets through, rather than only being sent in response to SYNs. – The Spooniest Oct 31 '16 at 15:53
  • 1
    This is the best answer which can explain logically why we even need the third message. Thanks, Spooniest. – Parth Patel Mar 10 '19 at 18:55
8

Actually, a 3-way handshake isn't the only means of establishing a TCP connection. Simultaneous SYN exchange is also allowed: http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-4.htm

That could be seen as a sort of double 2-way handshake.

Lexelby
  • 81
  • 1
  • 1
    Good point, however this is very rare as both devices will have to be using the same source/destination port and both devices will need to send a SYN before the other receives the SYN. Even when it does occur, it involves four packets being sent, which is more than the three packets required by the traditional 3-way handshake; ultimately only the possibility of being slightly faster to set up in terms of overall time at the cost of less overall efficiency (requires 33% more packets to be transmitted). – YLearn Nov 05 '15 at 16:39
8

TCP connection is bidirectional. What this means is that it actually is a pair of one-way connections. The initiator sends SYN, the responder sends ACK: one simplex connection begins. "Then" the responder sends SYN, the initiator sends ACK: another simplex connection begins. Two simplex connections form one duplex TCP session, agree? So logically there are four steps involved; but because SYN and ACK flags are different "fields" of TCP header, they can be set simultaneously - the second and the third steps (of the four) are combined, so technically there are three packet exchanges. Each simplex (half-)connection uses 2-way exchange, as you proposed.

Sergio
  • 146
  • 3
4

If Server and Client want to create a connection, they need confirm four things:

  1. Server need to confirm he can receive packet from Client

  2. Client need to confirm he can receive packet from Server

  3. Client need to confirm a thing: Server can receive packet from Client

  4. Server need to confirm a thing: Client can receive packet from Server

After Client ------SYN-----> Server, rule 1 is confirmed.

After Client <---ACK/SYN---- Server, rule 2 and 3 is confirmed.

So, there need a third packet to confirm rule 4.

Shuai Li
  • 261
  • 1
  • 2
  • 7
2

Simple answer:

Both client and server need to know that they can be connected.

For client: actually a two-way handshake is enough because it sends to server and server sends back.

For server: three-way handshake is needed since the server needs to know the message it sends back to client (second message) is successful. The third message from client proves that the server's message (second message) is successful so the third message is needed.

Banghua Zhao
  • 322
  • 4
  • 14
  • TCP doesn't have a server/client concept which is rooted in the application layer. It's possible that the application server connects to the application client (as seen in active FTP). – Zac67 Feb 09 '20 at 08:57
1

It is not necessary at all. It is obvious that a short message should only require one packet to the server which includes the start + message, and one packet back acknowledging it.

The previous answers just describe the system without discussing the need for random sequence numbers etc. in the first place. The original question was about the design of TCP itself -- obviously if you use the TCP protocol then you need three messages because that is the protocol. But why was TCP designed that way in the first place?

I believe the original idea was that there was no distinction between clients and servers. Both knew the other's ports in a bidirectional manner, and either could start the conversation. And that required Syns etc.

But this is not, of course, how it is used today. The server listens on a well known port and does and "accept", the client port number is ephemeral. I do not even think it is possible for a server waiting on an "accept" to send a request to another on the same client port number in normal operating systems.

(Note that this is about bidirectional initiation of the connection, which is never done today. That is quite different from sending bidirectional messages down a connection once established.)

To work around the TCP inefficiency, we use protocols like HTTP 1.1 which can reuse the same connection for multiple requests, and thus avoid the TCP handshake which was not necessary in the first place.

But Http 1.1 is relatively new. And SSL/TLS needed a way to reuse session from the beginning due to the cost of the PKI algorithms. So that protocol includes its own session reuse mechanism which runs on top of Http 1.1 which runs on top of TCP.

Such is the way with software. Fudges on kludges which when combined, produce an acceptable result.

Tuntable
  • 119
  • 2
  • Anything above OSI layer-4 (e.g. HTTP, FTP, etc.) is explicitly off-topic here. In layers 1 to 4, there is no such thing as client/server. TCP is a connection between peers. Yes, upper layer protocols create a client/server relationship, but that is off-topic here. – Ron Maupin May 23 '16 at 02:10
  • 1
    By the way, HTTP uses TCP, so the TCP handshake is still necessary. Read RFC 793 TRANSMISSION CONTROL PROTOCOL to undestand why. Protocols like HTTP require the application to do the multiplexing that TCP would normally do for the application. – Ron Maupin May 23 '16 at 02:18
  • @RonMaupin The original question was why? And the answer is to support a use case that is never used by the upper level layers in practice. So, seems pretty relevant. – Tuntable May 23 '16 at 02:18
  • @RonMaupin Yes, HTTP uses TCP. Which I have clarified, thanks. But that does not make the TCP handshake necessary in any deep sense. – Tuntable May 23 '16 at 02:20
  • 1
    The applications and application-layer protocols are explicitly off-topic here. @Eddie answered the question, and if you read and understand the TCP RFC, you will get why the handshake is necessary. I don't think it adds anything for you to claim, without any support, that the handshake is not necessary, when it clearly is. – Ron Maupin May 23 '16 at 02:21
  • @RonMaupin Eddie and the others describe why the double handshake is needed to establish Syn and the bidirectional establish. But they do not mention that nobody actually uses bidirectional establishment today, and therefor at more meaningful level the handshake is unnecessary because it supports a non-existent use case. – Tuntable May 23 '16 at 02:26
  • You are completely incorrect about that. TCP has a separate connection for each browser client to the HTTP server. The same thing happens for things like FTP. From the perspective of the network (what is actually on-topic here) The three-way handshake is used, and it is necessary. – Ron Maupin May 23 '16 at 02:30
  • @RonMaupin IP connections are identified by both server port and (ephemeral) client port. That is why they do not get mixed up. Nothing to do with the handshake. – Tuntable May 23 '16 at 07:38
  • IP knows nothing about ports. That is a layer-4 (TCP, UDP, etc.) address. You don't seem to understand the different network layers. Ethernet, and some other layer-2 protocols, use MAC addresses, IP uses IP addresses, TCP and UDP use ports as addresses, and some layer-4 protocols don't even have addressing. You cannot attribute ports to IP, since IP knows nothing about ports. – Ron Maupin May 23 '16 at 14:10
  • You're correct in saying that the top accepted answer doesn't offer any reason why a three-way handshake is better than a two-way handshake. However, you're wrong in saying that there is no reason. The reason you're looking for is in @TheSpooniest 's answer. – Rag May 23 '16 at 21:09
  • Thanks @Tuntable, you provided me the real answer I wanted to the actual question "why a sync/handshake is needed in the first place ?". The most satisfying answer (which you gave) is for me : to avoid both machines to start conversations simultaneously. With handshake, they first agree on who will be the initiator of the conversation so that there is at most one conversation at any given time. – Ismael EL ATIFI Nov 03 '18 at 10:43
1

After reading answer of Eddie (accepted as correct), there are still question why 1st host can not assign both ISN's with random numbers and 2nd just accept it. Real reason of using 3-way handshake is to avoid half-connections. Half connection scenario in 2-way handshake:
1) Client ---SYN--> Server
2) Client changes his mind and doesn't want to connect anymore
3) Client <-X-ACK-- Server //ACK was lost
Server doesn't see resent SYN, so he thinks that client got his ACK and connection is established. As a result Server has connection that will never be closed

Sanzhar Yeleuov
  • 11
  • 3
  • Actually, if a host (clients and servers are an application concept about which TCP knows nothing) receives an ACK or any traffic on a non-existent connection (step 3 in your scenario), it will send a RST, not ignore the received segment. – Ron Maupin May 15 '18 at 14:42
  • @RonMaupin Then let's assume situation when ACK packet was lost. – Sanzhar Yeleuov May 15 '18 at 16:34
  • If the ACK is lost, then the initiated connection in step 1 will time out. RFC 793 has a full explanation of all types of scenarios, including diagrams. – Ron Maupin May 15 '18 at 16:38
  • @RonMaupin I mean if scenario from my post remain same, only thing that changed, that ACK was lost. – Sanzhar Yeleuov May 15 '18 at 16:43
  • It's all in the RFC. Until a connection is open, any traffic received will result in a RST. The three-way handshake negotiates the connection parameters, so the "server" cannot send anything back to the "client" but it's SYN/ACK until it receives an ACK from the "client". If the "server" SYN/ACK back to the "client" is lost, the "server" will try again. The RFC explains all this. – Ron Maupin May 15 '18 at 16:49
  • @RonMaupin Please re-read my answer again, I mean that accepted answer doesn't answer the question totally. I wanted to show that 2-way handshake may lead to half-connection, what is not good for server. – Sanzhar Yeleuov May 15 '18 at 16:55
  • There is no two-way handshake. You cannot negotiate the parameters in a two-way handshake, and any traffic received until the three-way handshake is complete will result in a RST. "Server doesn't see resent SYN, so he thinks that client got his ACK and connection is established." No, it doesn't because it has a timer waiting for an ACK back from its SYN/ACK. It's not very complicated. – Ron Maupin May 15 '18 at 17:02
  • @RonMaupin you are not even trying to understand what I meaning with my post. Be patient and re-read. In question there are asking why we do not use 2-way handshake (right under "Why not just this?" ). I gave a scenario in my answer (btw i modified it) when 2-way handshake may lead to a problem called half-connection. And to avoid such situations we use 3-way handshake – Sanzhar Yeleuov May 15 '18 at 17:10
  • I understand what you are trying to say, but you don't seem to understand what I am trying to say. I think part of it is that you are stuck on client/server, which TCP doesn't do. TCP is peer-to-peer, and there must be a negotiation for each peer. In client/server, one side can dictate, but TCP knows nothing about clients or servers, which is an application concept. Each TCP peer is equal, and each can both send and receive, so each has a two-way handshake that gets compressed to a three-way handshake. – Ron Maupin May 15 '18 at 17:17
  • @RonMaupin stop trying to apply TCP to my scenario. In my scenario there is a protocol that uses 2-way handshake to make a connection. Both sides can send SYN to request for connection, and both sides if got a SYN and agree to make connection, reply with ACK and think that connection is established. And after getting ACK also think that connection is established – Sanzhar Yeleuov May 15 '18 at 17:32
  • "stop trying to apply TCP to my scenario." The question is specifically about TCP. Answering for another, hypothetical protocol is gratuitous. – Ron Maupin May 15 '18 at 17:36
  • @RonMaupin question is not about TCP, it is about why TCP was developed in that way – Sanzhar Yeleuov May 15 '18 at 17:37
  • "question is not about TCP, it is about why TCP was developed in that way _" That makes no sense. A question about how/why TCP was developed _is a question about TCP. Your hypothetical, client/server protocol has nothing to do with the TCP peer-to-peer model. In client/server, one side is in charge, but in peer-to-peer, each side is equal. – Ron Maupin May 15 '18 at 17:43
  • @RonMaupin but my protocol is peer-to-peer, not client/server please read carefully. It is just names for example. You could change direction of arrows if you want. – Sanzhar Yeleuov May 15 '18 at 17:53
  • In peer-to-peer, like TCP, each side must negotiate the connection. Your example only has only one side negotiating the connection. That is why TCP must have a three-way (really a compressed four-way) handshake. There must be a SYN from each side that is ACKed by the other side to negotiate the two-way connection. – Ron Maupin May 15 '18 at 17:58
  • When one peer sends a SYN, it says, "I want to talk, and these are my capabilities." The ACK from the other side says, "OK. I can send that way." Then the other side sends a SYN that says, "I want to talk, and these are my capabilities," and the other side sends a SYN saying, "OK. I can send that way." That is peer-to-peer. When only one side send a SYN, then it is dictating the terms for one-way traffic, but TCP is two-way traffic. – Ron Maupin May 15 '18 at 18:08