728x90
반응형

전송 계층의 개념 및 기본 기능

  • 전송 계층은 프로세스(애플리케이션) 간 통신을 담당
  • 전송 계층의 주요 기능 2가지
    • Multiplexing / Demultiplexing
    • 신뢰성 있는 데이터 전송과 흐름/혼잡 제어

Mutliplexing & Demultiplexing

  • Mutliplexing(다중화): 여러 앱이 데이터를 보낼 때 포트번호로 구분하여 전송
  • Demutliplexing(역다중화):
    • UDP의 경우: 목적지 포트만 사용
      • 같은 포트로 들어오는 요청은 구분 X
    • TCP의 경우: 4-Tuple 사용

UDP(User Datagram Protocol)

  • UDP 특징
    • 비연결형 → 핸드셰이크 X, 지연 적음
    • 비신뢰성 → 유실 & 순서 보장 X
      • 이는 애플리케이션 게층에서 챙겨줌
    • 혼잡 제어 X
    • 간단한 헤더 → 오버헤드 적음
  • 체크섬
    • UDP는 데이터가 전송 중에 손상되지 않았는지 확인하기 위해 체크섬 계산 이용
    • 계산 방법
      1. 헤더와 데이터에 대해 16비트 단위 덧셈
        • pseudo-header 포함
        • carry bit 발생 시, wraparound
      2. 1의 보수 연산
      3. 검증: 송신측 데이터와 수신측 계산 결과를 합해서 1이 되면 에러가 없음
    • 한계
      • 일부 상황에서 여러 비트 플립 발생해도 최종 합계가 동일하게 나오는 경우 존재
      • 체크섬은 어디까지나 옵션임

신뢰성 있는 데이터 전달 프로토콜(Reliable Data Transfer, RDT)

      • 목표: 비신뢰성 채널 위에서 신뢰성 있는 전송 추상화를 구축하기 위함
        • 신뢰성 있는 전송 = 비트 에러 해결 + 순서 오류 해결 + 패킷 유실 해결
      • 주요 함수
        • 송신측: rdt_send(), udt_send()
        • 수신측: rdt_rcv(), deliver_data()
      • rdt1.0: 이상적인 상황을 가정하여, 그냥 데이터 전송만 하는 단순 동작
      • rdt2.0: 체크섬 및 ACK/NAK 도입을 통한 비트 에러 문제 해결
        • 송신측
          • 데이터 전송 후 수신자로부터 ACK/NAK 기다림
            • NAK 수신 시 → 재전송
            • ACK 수신 시 → 다음 데이터 전송
        • 수신측
          • 패킷 수신 시 체크섬 검사
            • 에러 없으면 → ACK 전송
            • 에러 있으면 → NAK 전송
      • rdt2.1: 시퀀스 넘버 도입을 통한 중복 전송 문제 해결
        • 송신측
          • 데이터 전송 시 시퀀스 번호 부여 후 전송
          • 이후, 수신자로부터 패킷 받으면 ACK/NAK 및 시퀀스 번호 확인
            • 올바른 ACK 수신 시 → 다음 데이터 전송
            • 손상되었거나 NAK이면 → 재전송
        • 수신측
          • 패킷 수신 시, 체크섬 검사 + 시퀀스 번호 확인
            • 기대한 번호면 → 애플리케이션에 전달 + ACK + 시퀀스 번호 업데이트
              • ex) 0 기다리는 데 0이 오면, ACK
            • 기대한 번호가 아니면 →ACK 전송
              • ex) 0 기다리는 데 1이 오면, ACK
            • 에러가 있다면 → NAK 전송
      • rdt2.2: NAK-free(= 중복 ACK 기반 처리)를 통한 NAK 손상 문제 해결
        • 송신측
          • 데이터 전송 시 시퀀스 번호 부여 후 전송
          • 이후, 수신자로부터 ACK 받으면 시퀀스 번호 확인
            • 에러가 있거나, 중복 ACK 수신 시 → 재전송
            • 충돌 없고 올바른 ACK 수신 시 → 다음 데이터 전송
        • 수신측
          • 패킷 수신 시, 체크섬 검사 + 시퀀스 번호 확인
            • 에러/중복(기대한 번호가 아님) 발생 → 마지막 ACK 재전송(중복 ACK)
              • ex) 0 기다리는 데 1이 오면, ACK 1
            • 정상이면 → 해당 번호에 대한 ACK 전달
              • ex) 0 기다리는데 0이 오면, ACK 0
모든 오류 처리는 ACK(특히 중복 ACK)를 통해 이루어짐
  • rdt3.0: 타이머 도입을 통한 패킷 유실 해결
    • 송신측
      • 데이터 전송 시, 시퀀스 번호 부여 후 전송 + 타이머 시작
      • 이후, 수신자로부터 ACK 받으면,
        • 에러가 있거나, 중복 ACK 수신 시 → 재전송 없이 타이머가 만료되도록 기다림
        • 충돌 없고 올바른 ACK 수신 시 → 타이머 멈추고, 다음 데이터 전송
      • 타임아웃되면(ACK가 오지 않음 | 중복 ACK 수신 | 에러가 있음) → 재전송
    • 수신측
      • 패킷 수신 시, 체크섬 검사 + 시퀀스 번호 확인
        • 에러/중복(기대한 번호가 아님) 발생 → 마지막 ACK 재전송(중복 ACK)
        • 정상이면 → 해당 번호에 대한 ACK 전달

파이프라이닝 및 슬라이딩 윈도우 기법

  • 기존 Stop-and-Wait 방식의 한계: 한 번에 하나의 패킷만 보내고 ACK를 기다리는 방식이라 RTT(왕복 시간)가 크면 채널 이용률(utilization)이 낮아짐
  • 파이프라이닝(pipelining)
    • 여러 개의 패킷을 한 번에 보내는 방식 ⇒ ACK를 기다리지 않고 여러 패킷을 연속적으로 전송
      • Sender가 여러 개의 “아직 ACK를 받지 않은(in-flight)” 패킷을 전송
      • pipelining에서는 여러 개를 동시에 보내고, 나중에 ACK 수신
    • 장점
      • 네트워크 대역폭 활용률이 크게 향상
        • 각 stage마다 보내는 수만큼 성능이 배로 증가
      • RTT가 긴 환경에서 특히 효율적
    • 구현을 위한 조건
      • sequence number의 범위 확장: 여러 개의 패킷이 동시에 전송되므로 각각을 구분할 수 있는 시퀀스 번호가 필요
        • ex) Stop-and-Wait에서는 0,1만 필요했지만 → 여기선 더 많은 숫자가 필요
      • 송신자와 수신자 쪽 모두 버퍼링이 필요
        • 여러 개 패킷을 동시에 다뤄야 하므로 임시 저장 공간(buffer) 이 필요
        • 수신자도 out-of-order 패킷을 처리하기 위해 버퍼를 활용해야 할 수 있음
        • ⇒ 여기서 버퍼에 슬라이딩 윈도우 기법 사용
  • 2가지 주요 파이프라이닝 기법
    • Go-Back-N(GBN)
      • 송신 측만 슬라이딩 윈도우 유지, 수신 측은 1개만 받음(순서대로만 받음)
      • 동작 방식
        • 송신측
          • 윈도우 내의 패킷들은 "in-flight" 상태로 존재
          • 가장 오래된 in-flight 패킷에 대한 타이머가 존재
            • timeout(n): 패킷 n과 윈도우 내의 n보다 큰 번호의 패킷에 대해 재전송
              • ⇒ 이미 전송되어 수신측에 잘 도착했더라도, 누락된 패킷 이후의 모든 패킷이 재전송되는 것이므로 불필요한 재전송 발생
          • ACK가 수신자로부터 도착했을 때,해당 ACK가 가장 작은 번호의 패킷에 대한 ACK라면 윈도우 전진 후 새로운 패킷 전송
        • 수신측
          • 올바르게 도착한 패킷에 대해 누적(Cumulative) ACK를 보냄
            • ⇒ 내가 지금까지 0 ~ k번까지 모든 패킷을 받았다는 의미의 ACK(k)
          • 만약 특정 패킷이 오류가 있거나, 잘못된 순서라면 → 버리고(= 순서대로만 수신 가능), 누적 ACK만을 보냄
      • 장점
        • 구현이 비교적 단순하며, 순차적인 ACK를 활용해 윈도우 이동을 쉽게 관리
      • 단점
        • 한 패킷의 오류나 손실이 발생하면, 그 이후에 정상적으로 전송된 패킷들까지 모두 재전송하게 되어 효율 저하 및 자원 낭비
    • Selective Repeat(SR)
      • 양쪽 모두 슬라이딩 윈도우 + 버퍼링 필요 → 순서대로 도착하지 않아도 됨
      • 손실된 패킷만 개별적으로 재전송 하기 위해 → 개별 ACK 및 타이머 관리
      • 동작 방식
        • 송신측
          • 윈도우 내의 패킷들은 "in-flight" 상태로 존재
          • 각 패킷들에 대한 타이머가 존재 → 특정 패킷에 대한 타이머가 만료되면, 그 패킷만 선택적으로 재전송 후 타이머 재시작
          • ACK가 도착하면, 그 패킷에 한해서먄 확인처리
            • 만약, 해당 패킷이 윈도우 내의 가장 작은 번호의 패킷일 경우, 윈도우 전진시키고 새로운 패킷 전송
        • 수신측
          • 올바르게 도착한 패킷에 대해 개별 ACK를 보내고, 수신 버퍼(윈도우)에서 관리
            • ⇒ 각 패킷에 대한 타이머 및 ACK를 관리하므로..
            • 수신측에서는 도착한 패킷의 순서를 정렬하여 deliver_data()하기 위해 버퍼를 관리
          • 잘못된 순서라는 개념은 딱히 없음. 수신측 윈도우가 다 차야 deliver_data()가 호출될 것임. 특정 패킷이 유실되었다면 송신측에서 타임아웃이 발생하고 다시 재전송될 것임. 수신측은 이를 받고 정렬하기 위한 윈도우를 유지할 뿐.
      • 시퀀스 번호와 윈도우 크기의 관계
        • 윈도우 크기가 시퀀스 번호 공간의 절반 이하여야 함
        • ⇒ 수신측이 중복 패킷과 새 패킷을 혼동하지 않기 위함
      • 장점
        • 손실된 패킷만 재전송하므로, 불필요한 재전송 감소 → 전송 효율성 증가 + 높은 이용률
      • 단점
        • 송신측과 수신측 모두 개별 패킷에 대해 타이머와 버퍼를 관리해야 함 → 구현 복잡도가 높음
        • 윈도우 크기와 시퀀스 번호 관리가 까다로움

TCP Overview

  • TCP의 특징
    • 연결 지향 ⇒ 3-way handshake
    • 신뢰할 수 있는, 순서 보장 전송 by 재전송, 재정렬
    • Flow Control / Congestion Control
    • Full Duplex: 양방향통신
    • Byte-stream: TCP는 데이터를 바이트 흐름으로 처리해서, 어디까지가 하나의 메시지인지 구분 X
    • MSS(Maximum Segment Size): 한 번에 보낼 수 있는 최대 크기의 데이터
  • TCP Segment Structure
    • Sequence number / Acknowledgement number: 데이터가 어디서부터 시작됐고, 어디까지 받았는지를 알려주는 핵심 필드. TCP는 바이트 단위로 추적.
    • Header length (Data offset): 옵션 필드가 있을 수도 있으니, 데이터가 어디서부터 시작되는지를 알려줘야 함
    • Flags (SYN, ACK, FIN 등): TCP가 상태를 바꾸는 데 사용하는 신호들
      • 연결 설정(SYN), 종료(FIN), 확인(ACK) 등
    • Window size: 흐름 제어를 위한 필드. 수신자가 얼마나 받을 수 있는지 알려줌
    • Checksum: 데이터가 전송 중에 손상됐는지를 검증
  • TCP Sequence Numbers, ACKs
    • 시퀀스 번호 = 내가 보낼 바이트의 첫 번째 번호
      • 연결 시작 시, 시퀀스 넘버는 랜덤하게 초기화됨(보안 및 버퍼 문제)
    • ACK 번호 = 상대방이 다음에 보내야 할 시작 시퀀스 번호
      • ⇒ 송신자의 ACK 넘버에 따라 수신자의 다음 시퀀스 넘버가 정해짐
      • 누적 ACK 방식이라, 중간에 한 세그먼트만 빠져도 그 뒤는 다 무시하고 기다림(Go-Back-N)
      • ex) ACK 10 = “10번 바이트 이전까지 잘 받았으니, 다음에 10 바이트부터 보내줘”

TCP Round Trip Time, Timeout

타임아웃 시간은 어느 정도로, 무엇을 기준으로 잡아야 하는걸까? 너무 짧아도, 너무 길어도 문제다..

  • TCP는 RTT를 지수이동평균(EWMA) 방식으로 예측함
    • EstimatedRTT = (1 – α) * EstimatedRTT + α * SampleRTT
      • SampleRTT: 지금 막 측정한 RTT 값 (재전송된 세그먼트에 대한 ACK는 측정에서 제외)
      • EstimatedRTT: 과거에 측정한 여러 SampleRTT를 바탕으로 만든 예상 RTT
  • Timeout Interval 조정
    • TimeoutInterval = EstimatedRTT + 4*DevRTT
      • DevRTT: SampleRTT의 변동성(편차)을 측정한 값
      • ⇒ RTT가 자주 바뀌는 환경에선 이 마진을 크게 잡아야 안정성이 높아짐

TCP 동작

    • 송신측(Go-Back-N 방식과 유사)
      • 데이터 송신 시: 세그먼트 만들고 타이머 시작
        • 가장 오래된 unACKed 세그먼트를 기준으로 타이머 관리
      • 타임아웃 발생 시: 해당 세그먼트 재전송
        • 이때, 마진을 더 주기위해 TimeoutInterval *= 2
      • ACK 수신 시: 어떤 세그먼트까지 잘 받았는지 확인 → 타이머 갱신 + 윈도우 옮김
    • 수신측
      • 올바른 순서의 세그먼트가 도착한 경우 ⇒ Delay ACK
        • Delay ACK 전략: 다음 세그먼트가 바로 도착할 수도 있으니, 최대 500ms까지 기다림
      • 올바른 순서의 ACK가 도착했는데, 이전에 아직 ACK를 안 보낸게 있는 경우 ⇒ 누적 ACK 전송
        • 사실상 Delay ACK의 연장임. 이 방식으로 ACK의 개수를 줄여 더 빠르게 데이터 송수신 가능
      • 예상보다 높은 순서의 세그먼트 도착(= 중간이 비어있음) ⇒ Duplicate ACK 전송
        • 중간이 비었다는 것은 패킷 손실 가능성이 크다는 것
        • (현재 기다리고 있는 번호에 대해) 중복 ACK를 보내서 송신자에게 인식 시킴
          • 혹은 예상보다 낮은 순서의 세그먼트가 도착해도 Duplicate ACK 응답
        • 이때, 송신자는 중복 ACK를 3번 연속 받을 시 Fast Retransmit 수행
    • 갭(gap)을 채우는 세그먼트 도착 ⇒ 즉시 ACK
      • 비어있던 세그먼트가 도착했음 → 누적 ACK를 업데이트하고, ACK를 즉시 보내자
      • 송신자에게 “이제 그 다음 데이터 보내도 돼!”라고 알려주는 것
  • TCP Fast Retransmit
    • 같은 ACK(Duplicate ACK)를 3번 연속 받으면, 송신자는 유실로 판단하고 타이머 만료를 기다리지 않고 즉시 재전송
    • ⇒ 손실 훨씬 빠르게 반응

TCP Flow Control

  • 들어오는 양 ≥ 나가는 양 → 수신 버퍼가 꽉 차서 데이터 손실 가능
  • rwnd: 수신자가 받을 수 있는 최대 바이트
    • 수신자는 이를 TCP 헤더에 포함하여 전달하고, 송신자는 이를 보고 전송 데이터 양 제한
  • 수신 버퍼 구조
    • RcvBuffer: 수신자의 전체 수신 버퍼
    • rwnd: 현재 비어 있는 공간

TCP Connection Management

  • 2-way Handshake의 문제점: 연결 확인 메시지가 중간에 유실되어 한쪽만 연결이 성립되는 경우가 생길 수도 있음(= Half Open Connection)
  • 3-way Handshake(연결 설정)
    1. Client → Server[SYNSENT]: SYN(x)
      • 클라이언트가 연결 요청 (시퀀스 번호 x 사용)
    2. Server → Client[SYN RCVD]: SYN-ACK(y, x+1)
      • 서버가 수락 의사 표명 + 자신 시퀀스 번호 y 포함
    3. Client → Server[ESTAB]: ACK(x+1, y+1)
      • 클라이언트가 서버의 SYN에 대한 ACK 전송
  • 4-way Handshake(연결 종료)
    1. FIN from client/server: “이제 나 보낼 거 없어.”
    2. ACK from other side: “잘 알았어.”
    3. 나도 FIN: “나도 다 보냈어.”
    4. ACK로 마무리

Principles of Congestion Control

  • 혼잡 발생 시 문제 상황
    • 큐에 패킷이 너무 많이 쌓임 → 지연(delay) 증가
    • 큐가 넘침 → 패킷 유실(loss)
    • ⇒ 네트워크 성능 저하
  • 혼잡 제어: 송신자가 손실이나 지연을 간접적으로 보고 송신 속도를 조절하는 것
  • 혼잡 상황의 원인과 비용
    • throughput은 절대로 capacity를 넘을 수 없음
      • 송신자가 둘이라고 가정하면, 각각 최대 R/2까지만 도달 가능
    • 전송량이 용량에 가까워질수록 지연(delay)은 급격히 증가 by 큐잉 지연
      • 버퍼에 데이터가 쌓이기 시작하면서 큐잉 지연이 늘어나는 모습
      • 처리율은 안정적인데, 지연은 통제 불가능하게 치솟게 됨
    • 손실(loss) 및 재전송(retransmission)은 실질적인 처리율(throughput)을 감소시킴
      • 현실 상황에서는 전송량이 R/2에 가까워질 수록 꺾이는 형태가 발생하는데, 이는 패킷 유실 및 재전송으로 인한 것
      • ⇒ 보내는 양은 많지만, 유효하게 도착하는 양은 줄어든다는 의미
    • 불필요한 중복 전송은 처리율을 추가로 더 떨어뜨림
    • 패킷이 다운스트림(마지막 구간)에서 손실되면 이전 라우터들이 사용한 자원은 전부 낭비됨
      • 혼잡이 마지막 구간에서 일어나면, 전체 경로가 비효율화
  • 혼잡 제어 전략 2가지
    • End-to-End: 송신자가 loss/delay를 기반으로 혼잡을 추측하고 조절
    • Network-assisted: 네트워크(라우터)가 직접 혼잡 상태를 알려줌

TCP Congestion Control

  • AIMD: 혼잡을 간접적으로 추측하면서도 전체 네트워크에 잘 맞게 동작하는 분산 알고리즘
    • 핵심 전략: 조심스럽게 늘리고 급격히 줄여서 안정화
      • Additive Increase: 점점 조금씩 전송 속도 증가(매 RTT마다 +1 MSS)
      • Multiplicative Decrease: 혼잡 발생 시 전송 속도 절반으로 감소(cwnd = cwnd / 2)
    • 혼잡 발생 시 동작 예시
      • 중복 ACK 3번 → cwnd = cwnd / 2 (TCP Reno 방식)
      • 타임아웃 발생 → cwnd = 1 MSS (TCP Tahoe 방식)
  • Slow Start
    • 전이 조건
      • 첫 시작
      • 타임 아웃 발생
    • 동작 방식
      • ssthresh = cwnd / 2 (첫 시작일 경우 X)
      • cwnd = 1 MSS
      • dupACKcount = 0
      • 매 RTT마다 받은 ACK 수만큼 cwnd = cwnd + 1
        • ⇒ 지수 증가(exponentially)
        • ⇒ TCP는 최대한 빨리 네트워크 용량 찾아감
    • Congestion Avoidance
    • 진입 조건
      • cwnd ≥ ssthresh
    • 동작 방식
      • 이때부터는 매 RTT마다 1 MSS씩 증가 (cwnd = cwnd + MSS * (MSS / cwnd))
      • ssthresh는 혼잡 발생 시 동적으로 조정
  • Fast Recovery
    • 전이 조건
      • 중복 ACK 3개를 받으면(dupACKcount == 3), Fast Retransmit 직후에 Fast Recovery 수행
    • 동작 방식
      • ssthresh = cwnd / 2
      • 손실된 세그먼트 재전송
      • cwnd = ssthresh + 3 MSS
      • 중복 ACK 수신하면(dupACKcount > 3) cwnd = cwnd + 1
      • 정상 ACK 수신하면 → cwnd = ssthresh이후 Congestion Avoidance 진입
  • TCP CUBIC
    • 전송 윈도우 크기(cwnd)를 시간에 따라 큐브 함수 형태로 증가
    • 기존 AIMD 방식(TCP Reno)의 단점 ⇒ 느린 복구 속도, RTT 의존성, 효율성 부족
      • ⇒ RTT에 영향을 덜 받고, 빠르게 회복하며, 공정성을 유지할 수 있는 CUBIC 등장
    • 요소
      • W_max: 이전에 도달했던 최대 cwnd
      • K: 혼잡이 발생했던 최대 윈도우까지 도달하는 데 걸리는 시간 (= 변곡점 부분)
    • ⇒ 손실이 났던 시점(W_max, K)를 기억하고, 거기까지는 빠르게 복구하고 넘어가면 조심스럽게
  • Bottleneck Link(병목 링크): 혼잡이 발생한 라우터의 출력 링크
    • 이 병목 링크를 기준으로 가득 채우되 넘치지 앟게 전송 속도를 조절하는 것이 중요
  • Delay-based TCP Congestion Control
    • 네트워크가 혼잡하면 큐잉 지연으로 인해 RTT 증가함을 핵심 아이디어로 함
    • 동작 방식
      • 기본 RTT(RTT_min) 저장(혼잡 X RTT)
      • 현재 RTT를 측정했을 떄, RTT_min보다 크다면 → 큐가 쌓이고 있음(혼잡) → cwnd를 그대로 두거나 감소
    • 장점
      • 혼잡 전에 조절하여 패킷 드롭이 거의 없음
      • RTT 적응성 뛰어남
      • 네트워크 자원 낭비 줄임
    • 단점
      • 정확한 RTT 측정 필요
      • 같은 링크에서 loss-based TCP와 공존 시 손해
  • ECN(Explicit Congestion Notification)
    • 기존 TCP의 문제점: 혼잡 여부를 패킷 손실로 감지 ⇒ 혼잡이 이미 터진 뒤에야 알 수 있음
    • ECN은 패킷 드롭 없이도 라우터가 혼잡하다는 걸 미리 알려줌
    • 동작 방식
      1. 송신자와 수신자가 ECN 사용 가능을 네고(3-way handshake 중에)
      2. 송신자 → 패킷에 ECN=10 설정
      3. 중간 라우터가 혼잡을 감지하면 → ECN=11로 변경
      4. 수신자 → ACK에 ECE=1 설정하여 송신자에게 알림
      5. 송신자는 혼잡을 인식하고 → cwnd 감소
    • 장점: 선제적 혼잡 대응, 네트워크 품질 향상, TCP와 호환
    • 단점: 라우터와 호스트 중 하나라도 지원하지 않으면 사용 불가
  • TCP Fairness
    • 혼잡 제어 알고리즘이 여러 송신자들이 있을 때 얼마나 공정하게 대역폭을 분배하는가
    • AIMD의 공정성: 모두가 같은 방식으로 증가/감소
728x90
반응형

'Network' 카테고리의 다른 글

[컴퓨터 네트워크 수업] Chapter 2. Application Layer 요약  (0) 2025.04.20
[컴퓨터 네트워크 수업] Chapter 1. Introduction  (0) 2025.04.14
[Network] 무선 네트워크 (Wi-Fi)  (1) 2024.11.29
[Network] SSL/TLS, 그리고 HTTPS  (3) 2024.11.28
[Network] PN과 VPN  (1) 2024.11.27

티스토리툴바