TCP / UDP

reliable connection https://soheeparklee.github.io/posts/n-reliableconnection/#-reliable-transmission

✅ TCP

Transmission Control Protocol

• reliable
  
• conection-oriented
  

• 👍🏻 assure transmission of data

• exchange data when server is connected

• network congestion avoidance algorithm

• full duplex: 전이중, 전송 양방향으로 동시에
• point-to-point: 각 연결이 정확히 2개의 종단점을 가지고 있음

1️⃣ Reliable

• checksum, retransmission, ACK, timer, sequence number

💡 reliable connection https://soheeparklee.github.io/posts/n-reliableconnection/#-reliable-transmission

2️⃣ Connection Oriented

• before transmission, TCP sets parameters for connection
• Thus, pre-connection process before connection
• called 3-way-handshake

• TCP operates onlt on end systems
• does not function within intermediate network elements

• routers between the ends cannot detect TCP connection
  

• full-duplex

• point-to-point: one sender and one reciever, no multicasting

• to terminate connection, 4-way-handshake

📌 Reliable TCP

• provide reliable data transmission service
• in an unreliable(best-effort) IP environment
  

What is reliable transmission?

a reliable transmission is transmission where…

• data is not corrupted,
  
• in the right order
  

• TCP uses single timer
• (timer per segement would have huge overhead)

🫱🏻 TCP Sender

1. Recieve data from application and send

• TCP recieves data from application
• encapsulate data with segment
• send segment to IP
• If timer is not running, start timer when sending segment to IP

2. Timer

• If timeout, retransmit segment
• and restart timer

3. Recieve ACK from reciever

• compare SendBase and ACK value y
  • SendBase: oldest order number that has not been acknowledged
  • y: value of ACK
• TCP uses sequence numbers
• y checks recievement of bytes before y
• If y > SendBase
  • recievement of packets from SendBase to y-1 that has not recieved ACK has been confirmed
  • Thus, SendBase changes to y+1
  • Sliding window
• If there is unchecked segment, restart timer

📌 Retransmission Scenarios in TCP

• three scenarios might be possible for retransmission

✔️ lost ACK scenario

• Reciever recieved segment 92 successfully
• Reciever send ACK

• ACK was lost
  

• timeout occurs, segment 92 is retransmitted
• Reciever has already recieved 92, thus throw away

✔️ premature timeout

• Sender sends segment 92, segment 100 to reciever
• Reciever recieved both segments successfully

• Reciever sends ACK100, ACK120 accordingly
  

• However, sender recieves ACK100 after timeout
• Sender retransmits segment 92
• Sender recieve ACK120 before timeout
• Sender does not retransmit segment 100

✔️ cumulative ACK

• Sender sends segment 92, segment 100 to reciever
• Reciever recieved, sends ACK100, ACK120 accordingly
• However, ACK100 was lost
  
• Sender recieves only ACK120
• Sender can assume until segment 100 was successfully recieved
• Thus, retransmission does not occur

⏳ When timeout, timeout ✖️ 2

• When timeout occurs, TCP retransmits the segment with smallest order from segements that have not recieved ACK
• Thus, when timeout occurs, TCP makes timeout period * 2
• To reduce network congestion
• This is called congestion control

🚀 TCP fast retransmit

• 👎🏻 Problem of retransmitting according to timeout:

  • retransmission according to timeout has problems too
  • when timeout period is too long

• Sender can realize packet corruption after duplicate ACKs
• When Reciever recieves segment in wrong order, sends the last correct ACK to sender
• If sender recieves triple dublicate ACKs
• sender can realize packet has been lost for that ACK
• sender can retransmit

• Sender does not wait for timeout,
• thus this is fast retransmit

TCP 🆚 GBN, SR

Is TCP GBN, or SR?

• TCP is simmilar to GBN
• Like GBN, TCP sender has to keep track of
  • SendBase(smallest order num without ACK)
  • NextSeqnum(next number segment to be transmitted)

• TCP is different from GBN
• If window size is 5, sent data 1, 2, 3, 4, 5 and ACK for packet 2 is lost
• GBN would retransmit all 1, 2, 3, 4, 5
• TCP would retransmit only 2
• or, if sender recieves ACK 3/4/5(later than 2) before timeout, does not retransmit anything
• bc TCP uses cumulative ACK

• TCP is similar to SR
• that it only retransmits the lost segment(selective)

• TCP is different from SR
• However, SR uses timer for each segment
• TCP uses only one timer for the oldest segment that did not recieve ACK
• SR does not use cumulative ACK

• TCP uses cumulative ACK

• ⭐️ conclusion: TCP is similar to GBN and SR, but is distinctive
• TCP is more like a hybrid GBN, SR

☑️ 3 way handshake

PAR

Positive Acknowledgement with Re-transmission
TCP provides reliable connection with PAR
device using PAR resend the data until it recieves acknowledgement

✔️ SYN:

• synchronize
• client sends SYN(Synchronize Sequence Number) to server
• SYN bit = 1

• send Sequence Number with random num
  

• Result SYN:
• client: port CLOSED ➡️ SYN_SENT
• server: LISTEN(port open, ready for communication), Wait for client

✔️ SYN+ACK:

• synchronize acknowledge
• server ACK client request, request client to open port as well
• server responds to client with SYN+ACK signals bit set
• SYN bit = 1
• Acknowledgement Number: Sequence Number + 1

• client checks that server state is alive with server ACK message
  

• Result SYN+ACK:
• client: SYN_SENT
• server: LISTEN ➡️ SYN_RCVD(SYN recieved)

✔️ ACK:

• acknowledge
• client acknowledges the response of server
• client sends server ACK message so that server can check client and connect
• establish reliable connection
• can start exchanging data

• server checks that client state is alive with client ACK message
  

• Result ACK:
• client: ESTABLISHED(port connected)
• server: ESTABLISHED

☑️ 4 way handshake

terminate connection

✔️ FIN:

• client sends FIN to server

• Fin bit = 1

• Result
• client: FIN_WAIT_1
• server: CLOSE_WAIT

✔️ ACK:

• when server revieves FIN, sends ACK message to client

• to send all data, server is in CLOSE_WAIT status

• when client recieves ACK, change port status to FIN_WAIT_2

• client waits for server FIN

• Result
• client: FIN_WAIT_2
• server: CLOSE_WAIT

✔️ FIN:

• server tells client “I finished sending data”
• if all data is sent, server send FIN to client

• FIN bit = 1

• Result
• client: TIME_WAIT
• server: LAST_ACK

✔️ ACK:

• client recieves FIN, sends ACK message to server
• server closes after getting final ACK

• client closes after TIME_WAIT

• Result
• client: CLOSED
• server: CLOSED

❓ Two way handshake?

Why not use two-way-handshake? What are the problems of two-way-handshake

• Two scenarios of two-way-handshake
• 1️⃣ Client request server for connection

• 2️⃣ Server replies ACK, connection created

• However, following situations should not be connected
• 👎🏻 Client request that came to server is a retransmission request due to timeout

• 👎🏻 When client and server TCP communication is over

• Thus, server has to check client state before connecting to client request
• need to check if client state is alive
• client has to tell server that its state is alive and possible for connection

✅ Problems of TCP

• packet loss
  
• packet order miss
  
• congestion
  
• reciever overloaded
  

☑️ Flow Control in TCP

• ⚠️ sender speed > reciever speed
  
• reciever recieve too much segments even before sending read data to TCP socket

• reciever buffer overflow ➡️ cannot recieve more packet

• 💊 configure data sending speed according to reciever
  
• configure sender’s window size
• ensure reciever Free Buffer Space(rwnd) is not overflowed
• need to ensure reciever doesnt recieve too much packets
  

• prevent reciever overflow

• reciever sends feedback of state to sender
  
• reciever send ACK with TCP header rwnd
• with information about its Free Buffer Space(rwnd)

💊 Solution

💊 Stop and Wait

• only send next packet when recieved message

💊 Sliding window

• only can packet size according to reciever
• packet on air = sliding window
  • sliding window= last sent byte - last checked byte

☑️ Congestion Control in TCP

• prevent that number of packet in network do not overexceed
• configure window size to reduce network congestion
• configure host, router to prevent congestion

What happens when network is congested?

• more latency
  
• packet loss
  

💊 Solution

💊 AIMD

Additive Increase/Multiplicative Decrease

• Additive increase: send n packet, if arrives successfully, send n+1
• AIMD will, for every RTT, increase cwnd for 1
• Multiplicative decrease: if fail, packet send speed /2

💊 Slow Start

• For each RTT, send n packet, if arrives successfully, send n*2
• double cwnd
• If cwnd > ssthresh(OS threshold)
• then for each RTT, increase cwnd for 1
• this moment is called the slow start phrase
• if packet loss, make ssthresh = current cwnd/2
• packet loss can be detected with 3 duplicate ACK or timeout

✔️ Fast Retransmit

• if reciever recieves the wrong packet, send ACK
• but in this ACK, send the number of packet that reciever missed to recieve
• sender will acknowledge he didnt sent this packet, and send.
• if repeated w same number packet more than three times, reduce window size

💊 TCP Tahoe

• If packet loss is detected, make cwnd to 1

💊 TCP RENO

• If packet loss is detected, make cwnd to cwnd/2(half)
• widely used method

Flow control 🆚 Congestion control

✔️ Flow control:

• control traffic from sender to reciever
• protect reciever overflow
• usually data link layer

✔️ Congestion control:

• control congestion on network
• prevent network from congestion
• usually network, transport layer

✅ UDP

User Datagram Protocol
manage data in datagram unit

• conectionless
  
• NOT reliable (transmission not granted)
  

• 👍🏻 speed

• data might arrive in different order from sent order
• does not check if data was recieved
• no flow control
• no logical connection between client and server(no handshake)

• packets are independent

• 1:1
• 1:N
• N:N

👍🏻 Why use UDP?

Faster than TCP UDP header is simple too used for for real time services

Why does Domain Name Service use UDP?

• DNS: application layer protocol
• DNS request is small ➡️ small enough to be stored inside UDP segment
• do not need 3 way handshake(TCP overhead > UDP overhead)
• loss for request will be configured by application layer

When does DNS have to use TCP?

zone transfer(request between DNS servers) if data is bigger than 512 bytes

1️⃣ Not reliable

• data can be lost
• data can be revieced in different order
• can check data integrity: with checksum header
• if reliability is needed, compliment reliability in application level
  

⭐️ UDP checksum header

• purpose: verify data integrity
• divide UDP data segment into word(16bit)
• add each word, add 1, create checksum
• send segment with UDP checksum header

• recipient recieve segment, create checksum on recieved segemnt
• check if recieved checksum matches
• if matches, the segment has not been altered

2️⃣ Connectionless

• no pre-connection process, no handshake
• faster

3️⃣ faster speed, less overhead

• no reliability, no connection ➡️ fast

• less overhead

  • TCP: 20byte overhead
  • UDP: 8byte overhead
    
• used in DNS, SNMP, streaming service
• DNS:
  • purpose is to get IP address to domain name
  • use UDP for speed
  • and UDP less overhead
• SNMP:
  • simple network management protocol
  • network device can be numerous
  • UDP is more adequate, less overhead and faster speed
• internet calls, streaming service:
  • minimum transmission guaranteed
  • allow little data loss
  • thus, UDP is adequate

TCP 🆚 UDP

• 공통점:
• way to establish connection
• unit of transport layer: segment

☑️ TCP: Transmission Control Protocol

• 예의바른 프로토콜
  
• “데이터 전송해도 될까요?” 물어보고 문제 없다고 하면 그제야 보냄.
  

• 보낸 후 “감사합니다” 인사까지 하고 물러간다.
  

• 연결 지향형 프로토콜
  
• 데이터 안정성을 위해 신뢰성/흐름을 제어하는 전송 계층 프로토콜
  
• UDP에 비해서는 느림
  
• 정확성 필요하면 TCP
  

💡 연결과정 3-way-handshake

1. SYN: 나 데이터 보내도 돼?
   
2. SYN/ACK: 응 보내
   
3. ACK: 그제야 데이터 보낸다.
   

💡 데이터 송수진 시 동작

1. 데이터(패킷) 순서 보장
   
2. 데이터 흐름 제어
   
3. 데이터 신뢰성 보장(재전송)
   

💡 연결 해제 과정 4-way-handshake

1. FIN
   
2. ACK
   
3. FIN
   
4. ACK 하고 나서야 연결 해제
   

☑️ UDP: User Datagram Protocol

막무가내 프로토콜
그냥 일단 데이터 보냄.
받으면 받는거고 안 받으면 안 받는겨~

데이터 신뢰성보다는 속도와 간단한 통신을 중시하는 전송계층 프로토콜
속도 중요하면 UDP

• 연결과정 3-way-handㅜshake 생략
  
• 데이터(패킷) 순서 보장 ❌
  
• 데이터 흐름 제어 ❌
  
• 데이터 신뢰성 낮음
  
• 연결 해제 과정 4-way-handshake 생략