Skip to content

Instantly share code, notes, and snippets.

@marcinjahn
Last active August 30, 2020 19:34
Show Gist options
  • Save marcinjahn/f946301329c2f33783b8cb77daa3404f to your computer and use it in GitHub Desktop.
Save marcinjahn/f946301329c2f33783b8cb77daa3404f to your computer and use it in GitHub Desktop.

Transport Control Protocol (TCP)

Allows 2 endpoints to exchange data reliably ovet the network. It is a Transport (4th) layer of OSI.

Connection

Connection between 2 computers is identified by:

  • source IP
  • source port
  • destination IP
  • destination port

Connection States

TCP has 11 possible connection states:

  • Closed - there's no connection yet
  • Established - connection open with 3-way handshake. We can begin to use it
  • Time Wait - We shut down the connection and we need to wait until we can use it again (?)
  • ...

TCP Handshake

  1. Client sends SYN to the Server. the values being sent:

    • Initial Sequence Number
    • Flags: SYN
    • Window size - max buffer size that the client can receive at once
    • TCP Options:
      • max segment size - MSS - (1460)
      • windows scale - 2^number to multiply the "window size" to get the actual size (0-14)
      • timestamps
      • SACK permitted (Selective ACKnowledgments)
  2. Server sends SYN/ACK back to the Client. Values sent:

    • Flag: SYN and ACK (acknowledgement of Client's SYN)
    • Windows Size - max buffer size that the Server can receive at once
    • TCP Options:
      • max segment size - MSS - (1460)
      • SACK permitted
      • window scale - 2^number to multiply the "window size" to get the actual size (0-14)

    Based on the comparison of TCP Options of Client and Server, the actual options are chosen (support for timestamps, SACK, etc.) so that both parties can handle the communication. Some values can vary, like max segment size.

    Sometimes the network might have further restrictions and, i.e. a router might change the MSS to some lower value.

  3. Client sends ACK to the Server.

Receive Window Size

Both the client and the server send their window sizes, which is an amount of space in the buffer. Based on that the other side might decide how much data to send in a packet. It's not uncommon to see client-side receive window size to be bigger than the server's receive window size. That's because usually clients receive most of the data.

Every TCP connection has a separate receive window buffer. That's why the amount of connections is limited.

Client and server communciate their window sizes in every packet. This number might descrease and increase as the bugger gets smaller or bigger.

Maximum window size is around 1GB.

Zero Window Size

If the receiver of data is not able to keep up with the amount of data it receives, the bugger might be filled up completely. In such case, the receiver would send "0" as its receive window size. The server would wait for the client to report that there is some space. If client doesn't send anything like that, the server can ask about it.

Such situation can happen when the receiver runs out of resources and it cannot efficiently handle the receive buffer.

Ideally, the window size should be set so that the communication does not stop due to lack of buffer space and the client should send ACKs before the server stops transmitting bytes.

Retransmissions

Time-based (Standard Retransmission)

WHen a server transmits a packet of data, it sets a timer. If there is no ACK from the client by the time the timer runs out, the server will retransmit the data.

Fast Retransmission

It requires the SACK option. If the server sees 2-3 duplicate ACKa, it'll do a retransmission. This is caused by the network delay, when packets travel slow.

Spurious Retransmission

Server resends a packet that has already been received. It might happen due to undelivered ACK, so that server thinks that the packed was not acknowledged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment