[네트워크] TCP의 혼잡 제어

https://app.notion.com/p/3-2-TCP-34ee2a9f37498095b5c5d5cf6789c76d?source=copy_link#34fe2a9f3749805abb2cea06746fd38e

3장 2, 연결지향형 TCP, 혼잡 제어 | Notion

 

TCP의 혼잡 제어

전통적인 방식의 혼잡 제어 = 종단 간의 혼잡 제어

(한번에 보낼 수 있는 양 = 윈도우)

• 고려해야 할 점

1. TCP 송신자는 송신자 전송 트래픽 전송률을 어떻게 제한하는가? - 혼잡 윈도우
   • LastByteSent - LastByteAcked ≤ min{cwnd, rwnd}
   • rwnd가 아주 크다면 → cwnd가 혼잡 제어 (네트워크로 트래픽을 전송할 수 있는 속도에 제약)
   • rwnd/RTT = 전송률 제한
2. TCP 송신자는 자신과 목적지 사이 경로(네트워크)의 혼잡을 어떻게 감지하는가?
   1. 손실 이벤트가 발생했을 때의 혼잡 검출
      • 타임아웃
      • 3개의 중복된 ACK
   2. 손실 이벤트 X
      • TCP 자체 클로킹(self-clocking) (확인응답을 받는 속도를 이용하여 혼잡 윈도우 크기를 빠르게 혹은 느리게 증가할 지 확인한다)
        • 혼잡 윈도 크기를 증가하게 만드는 trigger, clock
        • 속도 빠르면 혼잡 윈도는 더 빠르게 증가
3. 어떻게 TCP 송신자가 자신이 송신할 속도를 결정?
   • = 송신자는 혼잡을 감지하고 송신율을 변화시키기 위해 어떤 알고리즘을 사용하는가?
   • 고려할 사항들
     • 손실된 세그먼트 = 혼잡 ⇒ 손실 이벤트 발생 시 TCP 전송률을 줄여야 한다
     • 확인 응답 받지 않았던 이전 세그먼트가 확인 응답
       → 혼잡 윈도우 증가(송신자의 전송률 증가)
       • 송신자에서 확인응답된 세그먼트 = 송신자 → 수신자 세그먼트 잘 전송된다
     • 대역폭 탐색 (= 혼잡 지점 확인하며 전송률 늘리기)
       • 전송률을 높이면서 어디까지 쓸 수 있는지 확인.
       • 혼잡 지점 확인
   ⇒ 혼잡 제어 알고리즘

혼잡 제어 알고리즘

• 슬로우 스타트, 혼잡 회피 = TCP 필수 요소
• 빠른 회복 = TCP 권고
• 슬로우 스타트(Slow Start)

 

1. cwnd = 1 MSS
   • 전송률 = MSS/RTT
   • → 송신자 가용 대역폭 훨씬 크다
2. ‘각 세그먼트가’ 확인 응답 받을 때마다
   1 MSS만큼 혼잡 윈도우 증가
   1. 1개 MSS
   2. 2개 MSS
   3. 4개 MSS

• 지수적 증가
• 끝나는 경우
  1. 타임아웃 (< 손실 이벤트 = 혼잡)
     1. cwnd 1 설정 후 새롭게 슬로 스타트
     2. ssthresh(slow start threshold) = cwnd/2
        (혼잡 검출 되었을 때의 cwnd의 반)
  2. cwnd = ssthresh
     1. 혼잡 회피 가동

 

• 혼잡 회피
• cwnd = ssthresh (대략 cwnd/2)
• RTT마다 cwnd + 하나의 MSS
• 예시 MSS = 1460, cwnd = 14600바이트
  1. 10개의 세그먼트 송신 in 1 RTT
  2. ACK 받았을 때 1/10 MSS(146) 만큼 cwnd 증가
  3. 10개의 세그먼트 확인응답 수신
     = 송신 전 cwnd + MSS(1460)
• 종료 조건
  1. 타임아웃
     • cwnd = 1 MSS
     • ssthresh = 혼잡 cwnd/2
  2. 중복 ACK 3개 (<손실 이벤트) (빠른 회복)
     • 송신자는 수신자한테 계속 전달하는 중
     • (타임아웃보다는 괜찮다. 일부만 유실)
     • cwnd = 혼잡 cwnd/2 (+ 3 MSS(이전에 중복 ACK 3개 온 경우에만))
     • ssrhresh = 혼잡 cwnd/2
     • → 빠른 회복
     • 빠른 회복 이후에 다시 혼잡 회피로 들어온다면
       • cwnd = 혼잡 cwnd / 2
       • RFC 5681, Deflate라 부른다
• TCP 분할 (TCP 스플리팅)
  • 초기 시작은 무조건 슬로우 스타트
  • 거리가 길면 RTT도 증가
  • 초기 3개의 데이터를 보낸다고 가정한다면 = 4RTT
    • TCP 연결 1 RTT
    • 데이터 1 , 2개 송신하고 받는 과정 3 RTT
    • 데이터 센터 처리 시간
  • → 너무 느려
  1. 프록시 서버(프론트엔드 서버) 사용자에 가까이 구축
  2. TCP 분할 ( 프록시 서버(프론트엔드 서버)에서 TCP 연결 나눔)
     ⇒ 프록시 서버(프론트엔드 서버)는 항상 켜져 있다
     = 혼잡 윈도우가 ‘충분히’ 크다
  • 응답 시간 = 4 RTT(FE) + 1 RTT(BE) + 처리 시간
    • RTT(FE) = 클라이언트, 프록시 서버(프론트엔드 서버)
    • RTT(BE) = 프록시 서버(프론트엔드 서버), 데이터 센터
    • RTT(FE)의 거리를 줄이면
      → 응답 시간 = 1 RTT(BE) + 처리 시간
  • 접속 네트워크(Access Network, 와이파이 4G/5G)에서 손실로 인한 TCP 재전송 지연도 줄여준다
    • 참고와이파이, 셀룰러 데이터 등의 접속 네트워크는 손실이 많다.→ RTT(FE)가 짧으므로 지연이 줄어든다.
    • (feat. 끝나지 않은 CDN)
    • → TCP 재전송이 많이 일어난다.
    • 유선 네트워크는 손실이 적다.
• 빠른 회복

 

• 수신된 모든 중복된 ACK에 대해 1 MSS만큼 증가
  • 예시 cwnd = 16에서 중복 ACK 5개 발생
  1. cwnd = 8 + 3(빠른 회복 초기값)
  2. cwnd = 11 + 1 (4번째 중복 ACK)
  3. cwnd = 12 + 1(5번째 중복 ACK)
  4. → 혼잡 회피 이동 (cwnd > ssthresh)
• TCP 타호 X
• TCP 리노 채택
• 타임 아웃
  • cwnd = 1 MSS
  • ssthresh = 혼잡 cwnd / 2
  • → 슬로 스타트

 

 

• 사용 예시1 : TCP 리노의 AIMD(additive-increase, mliplicative decrease, 가법적 증가 승법적 감소) (요약본)
• 가정 : 손실 = 3개의 중복 ACK (타임아웃 X)
• RTT마다 1 MSS 증가
• 3개의 중복 ACK → 혼잡 cwnd/2

• 사용 예시2 : TCP 큐빅
• TCP 리노의 단점 : 전송 속도를 절반으로 줄인 다음에 너무 천천히 증가시키는 것 아닐까?
  • 패킷 손실이 발생한 혼잡 링크의 상태가 비슷하다는 가정
  • → 더 빠르게 높여서 혼잡 전송 속도에 도달한 다음에 천천히 조사하자!
• TCP 리노와 달리 “혼잡 회피”만 수정
  • Wmax = 손실이 마지막으로 감지되었을 때의 혼잡 윈도우 크기
  • 해당 시점에서 손실이 없다고 가정할 때 Wmax로 도달하는 미래 시점 = K
  • 현재 시각 t
  • (K-t 거리)^3으로 혼잡 윈도우를 증가
  • t < K 인 경우
    1. t 가 K에 비해 많이 먼 경우 → 빠르게 증가
    2. t와 K가 가까운 경우 → 천천히 증가
  • t > K 인 경우
    1. t와 K가 가까운 경우 → 천천히 증가 (혼잡 수준이 이전과 비슷한 경우 좋다)
    2. t 가 K에 비해 많이 먼 경우 → 빠르게 증가 ⇒ 혼잡 윈도우 빠르게 찾을 수 있다
  $W_{cubic}(t) = C(t - K)^3 + W_{max}$

• 위의 그래프
  • 0 ~ t0 : 슬로스타트
  • t0 ~ t3 : TCP 리노보다 빠르게 증가 = 더 많은 전체 처리량
  • t3 ~ : 혼잡 수준 변경 ⇒ 혼잡 윈도우 모두 빠르게 증가
• 참고
  • [Yang 2014] 5000개의 웹 서버에서 거의 50%가 TCP 큐빅 활용
  • 리눅스 운영체제의 TCP 기본 버전
  • 현재도 표준!
• 참고 : TCP 리노 처리율 - 평균 처리율?
  • 가정 : 슬로 스타트 무시(지수적 증가)
    • 윈도우 크기 w 바이트
    • 왕복 시간 RTT
    • 손실 이벤트가 발생하는 시점의 w = W
    • RTT와 W가 링크 동안 일정 (네트워크 환경이 안정적. = 혼잡 발생하는 구간이 일정)
  • TCP 전송률
    • W/(2RTT) ~ W/RTT
      • W/(2RTT)는 손실 직후 감소한 혼잡 윈도우
    • → 산술 평균을 이용해 연결의 평균 처리율을 구하면
    • ⇒ $\text{Average Throughput} = \frac{3W}{4 \cdot RTT} = \mathbf{0.75 \cdot \frac{W}{RTT}}$