Connection Oriented Transport: TCP

TCP Flow Control

• sender 가 rcv 에게 자신이 수용할 수 있는 데이터 양을 알려주어, sender 특이 데이터를 조절하는 기능
• 즉, 강제로 송신측의 데이터 전송을 줄이는것

• rwnd: Rcv가 sender에게 전송 가능한 윈도우의 크기를 나타내는 변수
  • rcv가 rwnd를 계산하여 sender에게 알리면 sender는 rwnd 이상의 데이터 전송 x
• Sender: Last-Byte-Sent - Last-Byte-Acked = "In-Flight Data"
• Rcv: Last-Byte-Rcvd - Last-Byte-Read = Data in Receiver Buffer
• RcvBuffer - (Last-Byte-Rcvd - Last-Byte-Read) = rwnd
•  

Sender & Rcv Buffer

• Sender 는 ("In-Flight-Data") 를 rwnd value에 따라 제한한다 --> Flow Control
  • Garantees receive buffer will not overflow

Connection Management

• 데이터를 주고받기 전, sender/receiver는 handshake 과정을 거친다
  • Handshake: 연결 설정 동의
• 2-way handshake
•  
  • 신뢰성을 보장할 수 없다. 
  • 아래 상황은 연결 요청에 대한 2 way handshake 의 문제점이다
  • 딜레이가 너무 많아서 다시 연결 요청을 하는 상황인데, 이 입장에서 서버는 클라이언트가 올바르게 연결 되었는지 알 수 없다.
  •  

2way handshake 문제점

• 3-Way-Handshake
  • Client 가 서버에게 SYN segment 를 보낸다(Syn bit = 1)
  • 서버는 SYN 을 받을시, SYNACK segment를 보낸다
  • Client는 SYNACK 를 받을 시 ACK를 보낸다(Syn bit 다시 0)
  •  

3 way-handshake

• TCP 4-way handshake
  • 연결을 종료할때 사용한다
  • 클라이언트가 서버에게 Fin 신호를 보낸다
  • 서버가 ACK를 클라이언트에게 보낸다
  • 서버는 남은 데이터를 모두 보낸 뒤 FIN 신호를 클라이언트에게 보낸다
  • 클라이언트는 응답으로 ACK 신호를 서버에 보낸다.
  • 여기서 핵심은 FIN 패킷을 보낸 시점부터 더이상 데이터 전송이 불가능하다는 것과 클라이언트가 일정 시간 TIME_WAIT을 두는 것이다. 
    • 패킷 유실로 인한 재전송, 패킷 지연 등 늦게 도착할 것을 염두에 두고.
  •  

4 way handshake

TCP 연결 방법

 

SYN Flood Attack:

    -> Hacker : send many SYN without ACK --> makes server hang

    -> Server Solution: Server postpones resource allocation for SYN until ACK,

                                   Send SYNACK: Serve-Initial-SeqNo

                                   Receive ACK & ACK # = HASH() + 1: allocate resources

                                   Otherwise: Stop to make connection

 

 

Congestion Control

Congestion 이란?

• 너무 많은 source 가 너무 많은 데이터를 보내 network가 처리하지 못하는 상황
• Congestion Scenario 1
  • Two senders, Two receivers
  • One router, infinite buffers
  • Output Link Capacity: R
  • no retransmission
  • 이 경우, 출력 링크 용량이 정해져 있으므로 더많은 데이터가 버퍼에 쌓여 전송 지연, 패킷 손실이 발생할 수 있음

Scenario 1

연결 성능

• 이때, 전송률이 얼마나 늘어나던 처리율은 항상 그대로이다
• 다만 버퍼가 무한대 이기에 데이터가 무한대로 쌓이며 딜레이가 기하급수적으로 늘어나게 된다
• Scenario 2
  • One router, Finite Buffers
  • Sender retransmits timed-out packet
  • 이 경우 application-layer input = application-layer output
  • retransmission 이 있으므로 input이 더 많음
  • Retransmit 된 패킷이 버퍼에 쌓일 경우 다른 패킷들이 블록되는 현상이 발생 --> 패킷들이 버려지는 경우 발생
  • 그러면 sender는 재전송, 재전송 된 패킷이 다시 라우터 버퍼에 쌓이고 더 많은 패킷 손실

Scenario 2

• 이 때 3가지 가정
  • 1) 버퍼가 비어있는지 아닌지를 알고, 버퍼가 비어있을 때만 패킷을 송신
    • Scenario 1과 성능이 같다
  • 2) 호스트는 패킷이 손상된 것을 알았을 때만 재전송
    • 버려진 패킷에 대해서만 재전송을 하고 처리되기에 점차 R/2에 가까워 진다

 

• 3) 유실을 모르고 타임아웃을 통해서만 알게 된다.
  • 불필요한 duplicate 생김 --> 처리량이 줄어든다

• Scenario 3
  
  • Four Senders
  • Multihop Paths
  • Timeout/Retransmit
  •  

•  
  • A -> C, D -> B 로 각각 패킷을 전송 할 때, 서로 겹치는 경로가 존재,,, 둘 다 유실 될 수 있다.

Congestion control을 다룸에 있어 두가지 접근 방안

• end-end congestion control
  • 네트워크로 부터의 피드백이 없다 --> 송신과 수신측 간의 통신을 통해 혼잡 감지
• network-assisted congestion contol
  • 라우터가 직접 end system 에게 피드백
  • congestion을 명시하는 bit 하나
  •