reason for the last ACK in the 3 way handshake. - TCP-IP

This is a discussion on reason for the last ACK in the 3 way handshake. - TCP-IP ; what is the reason for the last ACK in the 3 way handshake? or the other words, what is the reason for the 3rd handshake, why is it not enough for the client to send SYN and the server to ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: reason for the last ACK in the 3 way handshake.

  1. reason for the last ACK in the 3 way handshake.

    what is the reason for the last ACK in the 3 way handshake? or the
    other words, what is the reason for the 3rd handshake, why is it not
    enough for the client to send SYN and the server to replay with SYN/
    ACK?

    thanks
    amir

  2. Re: reason for the last ACK in the 3 way handshake.

    amitm02 wrote:
    > what is the reason for the last ACK in the 3 way handshake? or the
    > other words, what is the reason for the 3rd handshake, why is it not
    > enough for the client to send SYN and the server to replay with SYN/
    > ACK?
    >
    > thanks
    > amir


    The goal is to synchronize sequence numbers.

    The client's SYN packet sets its SEQ number to "0", BUT there is no ACK
    number in this packet (no prior segment bytes to acknowledge).

    The servers SYN/ACK sets its SEQ number to "0", and acknowledges the
    client's SEQ number with an ACK of "1" (next expected SEQ number).

    The client's ACK increments it's SEQ number to "1", and now contains an
    ACK of "1", which confirms receipt of the server's SYN/ACK, by stating
    the next expected SEQ from the server will be "1".

    Best Regards,
    News Reader

  3. Re: reason for the last ACK in the 3 way handshake.

    On May 1, 9:49 am, amitm02 wrote:

    > what is the reason for the last ACK in the 3 way handshake? or the
    > other words, what is the reason for the 3rd handshake, why is it not
    > enough for the client to send SYN and the server to replay with SYN/
    > ACK?


    A 2-way handshake is impossible because of two requirements:

    1) At the end of the handshake, both sides must know that the link is
    up.

    2) Neither side may conclude that the link is up until it knows the
    other side has received at least one packet it has sent.

    If A sends a packet and B replies, B has no way to know whether A got
    that packet. Thus B cannot assume that he can send packets to A at
    all. By 2, he cannot conclude the link is up. By 1, this means the
    handshake is not finished.

    DS

+ Reply to Thread