CH4-08. TCP의 혼잡 제어와 흐름 제어
파이프 라이닝 전송에서 송수신 입장에서는 무엇을 고려해야 할까?
TCP 흐름 제어
- 송신 버퍼와 수신 버퍼
- 송신 버퍼 : 애플리케이션 계층에서 전송할 데이터 임시 저장되는 공간
- 수신 버퍼 : 네트워크 계층에서 수신할 데이터 임시 저장되는 공간
보낼 수 있는 양과 받을 수 있는 양은 한번에 한계가 있다, 보낼 것은 송신 버퍼에 담겨서 수신 버퍼로 간다.
- 송신 호스트가 수신 호스트가 처리할 수 잇는 수신 버퍼보다 더 많은 데이터를 전송하면?
→ 버퍼 오버플로우 : 일부 데이터가 처리 되지 않을 수 있다.
TCP 흐름 제어
- 송신 호스트가 수신 호스트 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 것
- 오늘날 TCP 에서의 흐름 제어 → 슬라이딩 윈도우(sliding window) 기법
- 수신 호스트 입장에서 생각해서 송신 호스트가 속도를 고려하여 균일하게 맞춘다.
- 윈도우 : 파이프 라이닝(한 번에 보낼 수 있는 만큼 보내는 기법) 가능한 순서 번호 범위
- 윈도우 크기 : 확인 응답(ACK) 받지 않고도 한 번에 보낼 수 있는 최대 양
- 슬라이딩 윈도우 : ACK 신호를 받았으면 받은 세그먼트 다음 세그먼트로 윈도우가 옮겨 가는 기법
- (수신) 윈도우 크기 : TCP 헤더를 통해 송신지에게 알려주는 정보
수신 호스트
- 수신 윈도우 = 수신 버퍼 크기 - [마지막으로 수신한 바이트 - 마지막으로 읽어들인 바이트]
- 수신 호스트는 윈도우를 통해서 송신 호스트에게 전달한다.
송신 호스트
- 수신 윈도우 크기 ≥ 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트
- 수신 윈도우 크기가 넘지않게 흐름제어
TCP 혼잡 제어
- 혼잡
- 많은 트래픽으로 인해 패킷 처리 속도가 느려지거나 유실될(TIME OUT) 우려가 있는 상황
- 혼잡 제어가 이루어지지 않는 다면? → 혼잡 → 유실 → 재전송 → 혼잡 *** 반복 → (혼잡 붕괴 현상 발생)
- 혼잡이 생기지 않을 정도로만 조금씩 전송하는 방법
- 혼잡 윈도우 : 혼잡 없이 전송할 수 있을 법한 양, TCP 헤더에는 포함되어 있지 않다, 수신지에게 알려 줄 필요 없기 때문에
- 송신 호스트(혼잡 주체)
- 최소값(수신 윈도우, 혼잡 윈도우) ≥ 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트
- 혼잡을 줄 수 있을 양을 넘지 않는 값의 최소값(혼잡 제어까지 송신 호스트가 고려 했을 경우 보낼 수 있는 양
- 흐름 제어는 수신지 입장이기 때문에 TCP 헤더에 포함
- 기본 동작 형태 : AIMD → 선형적으로 증가하다가 혼잡이 검출 되면 지속적으로 감소 시킨다.
- 혼잡 제어를 수행하는 알고리즘
- 느린 시작
- 혼잡 회피
- 빠른 회복
배경 지식 : RTT → 메세지를 전송한 뒤 그에 대한 답변을 받는 시간
느린 시작 : ACK 세그먼트가 수신 될 때 마다 혼잡 윈도우 1 증가(RTT마다 혼잡 윈도우 2배 증가)
→ 초기 전송 속도를 빠르게 확보 → 혼잡 윈도우를 증가 시켜서
→ 특정 임계치값과 같아지면 혼잡 회피 수행(미리 정한 값)
→ 혼잡 회피 : 매 RTT마다 혼잡 윈도우 1씩 증가 → 세 번의 중복 세그먼트가 발생(빠른 재전송)했을 경우 빠른 회복 수행
- 빠른 회복 : 세 번의 중복 ACK 세그먼트가 수신되었을 때 느린 시작을 건너 뛰고 혼잡 회피를 수행하는 알고리즘
- TCP Tahoe(빠른 회복 미수행) vs TCP Reno(빠른 회복 수행) Reno가 회복이 더 빠르다. → 절반만 떨어뜨리고 선형적으로 회복하기 때문에
'개발 > Network' 카테고리의 다른 글
자원과 자원의 식별 (0) | 2024.01.31 |
---|---|
DNS (0) | 2024.01.30 |
TCP 재전송 기능 (0) | 2024.01.30 |
TCP 상태 (0) | 2024.01.30 |
TCP 연결 (0) | 2024.01.30 |