[네트워크] TCP 흐름 제어 서비스

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

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

 

흐름 제어 서비스

• Q1: 신뢰적인 데이터 전송 vs 흐름 제어
  • 신뢰적인 데이터 전송 = 순서 O, 손실/중복 X, 손상 X
  • 흐름 제어 = 수신자 버퍼에서 애플리케이션이 데이터를 읽는 속도, 수신자 버퍼로 데이터 올리는 속도 동기화
• Q2: 흐름 제어 vs 혼잡 제어
  • 흐름 제어 ⇒ 애플리케이션이 수신자 버퍼에서 데이터 읽는 속도, 네트워크 계층에서 전송 계층으로 데이터 전송하는 속도를 제어 by 수신자 윈도우 rwnd
  • 혼잡 제어 ⇒ 네트워크 제어 by 혼잡 윈도우 cwnd

수신자의 애플리케이션 계층이 버퍼에서 데이터를 읽어가는 속도 < 네트워크 계층이 데이터를 더 빨리 전달할 경우 ⇒ 오버플로우가 발생할 수 O.

• 흐름 제어는 송신자가 너무 많거나 빠른 속도로 데이터를 전송하여 수신자의 버퍼를 넘치게 하지 않도록 제어하는 기능.
• 수신 윈도우는 송신자 수신자 각각 다르다
• 변수
  • RcvBuffer : 할당된 수신 버퍼의 크기
  • LastByteRead : 애플리케이션 프로세스에 의해 버퍼로부터 읽힌 데이터 스트림의 마지막 바이트의 번호
  • LastByteRcvd : 네트워크로부터 도착하여 수신 버퍼에 저장된 데이터 스트림의 마지막 바이트의 번호
• 동작 원리:
  • TCP 수신자는 TCP 헤더의 rwnd(수신 윈도우) 필드에 현재 남은 여유 버퍼 공간을 알린다.
  1. 수신자 기준
     • LastByteRcvd - LastByteRead ≤ RcvBuffer
     • ⇒ rwnd = RcvBuffer - [LastByteRcvd - LastByteRead]
  2. 송신자 기준
     • LastByteSent - LastByteAcked (전송 확인 응답이 안된 데이터) ≤ rwnd
     • 송신자는 아직 확인응답(ACK)을 받지 못한 "in-flight" 데이터의 양을 수신된 rwnd 크기 이내로 제한.
       = 수신 버퍼가 넘치지 않음을 보장.
• 참고 rwnd=0 인 경우
  • 1바이트 데이터로 세그먼트를 계속해서 전송 → 수신자 긍정확인 응답 → rwnd ≥ 0 으로 갱신
    • 얼마나 자주? RTO → 지수 백오프로 2배씩 증가
      • 출처 : https://datatracker.ietf.org/doc/html/rfc9293#name-zero-window-probing
      • The transmitting host SHOULD send the first zero-window probe when a zero window has existed for the retransmission timeout period (SHLD-29) (Section 3.8.1), and SHOULD increase exponentially the interval between successive probes (SHLD-30).
• 그래서 UDP는?
  • 흐름 제어 X
  • 버퍼 차면 그냥 세그먼트 버린다.

TCP 연결과 해제

• 이제 확인 응답번호, 순서번호 등을 알았으므로 TCP 연결과 해제를 알아보자

1. TCP 연결 : 3-way handshake

 

• 자원 할당(데이터 버퍼, 변수)
• 클라이언트 애플리케이션 프로세스가 TCP에 알림

1. 클라이언트 → 서버 세그먼트
   • 데이터 포함 X (Payload X)
   • SYN 플래그 = 1
   • 최초의 TCP SYN 순서번호 =
     최초의 순서번호 (임의 선택)
     • 최초의 순서 번호 (보안 주의)
       • 7장에서 계속
2. TCP 버퍼와 변수 할당

• TCP SYNACK 세그먼트 송신
  (서버 → 클라이언트)
  • 버퍼와 변수 할당 → 보안 주의(SYN Flood에서 더 자세히)
  • SYN = 1
  • 확인응답 필드 = client_ist+1
  • TCP 순서번호 필드
    = 최초의 순서 번호

1. 클라이언트 버퍼와 변수 할당

• 클라이언트 → 서버 세그먼트
  • SYN = 0
    • 왜 0
      • 연결 설정(동기화) 요청이 이미 끝났기 때문
      • 연결 요청일 때만 SYN=1
      • https://datatracker.ietf.org/doc/html/rfc9293#name-half-open-connections-and-o
  • 확인응답 필드 = server_isn+1
  • Payload 운반 O

• 참고
  • 데이터를 주고 받는 경우
    SYN 플래그 = 0

2. TCP 해제: 4-way handshake

• 자원 회수(데이터 버퍼, 변수)
• 클라이언트 애플리케이션 프로세스가 TCP에 종료 명령을 내림

1. 클라이언트 → 서버 세그먼트
   • FIN 비트 = 1
2. 서버 → 클라이언트
   • 확인응답 세그먼트
3. 서버 → 클라이언트
   • FIN 비트 = 1
4. 클라이언트 → 서버
   • FIN 비트가 1인 세그먼트에 확인응답

 

상태 정리 (왼쪽 : 클라이언트, 오른쪽 : 서버)

• TIME_WAIT 시간
  • 대체로 30초/1분/2분
• CLOSED = 자원 해체
• SYN_SENT = 연결 시도를 위한 자원 할당 (TCB, ISN, 상태 변수)
  • TCB, ISN
    • TCB(Transmission Control Block)
    • ISN(Initial Sequence Number)
• ESTABLISHED = 데이터 송수신을 위한 자원 할당 (송신 버퍼, 초기 윈도우 크기 확정)