[network] 3. Transport Layer

Jimin·2022년 4월 19일
네트워크
0

3. Transport Layer

Transport services and protocols

  • Logical communication (논리적 통신) 제공 → 서로 다른 host에서 작동 중인 application process
  • 종단 시스템 (end system)에서 동작
    • sender: message를 segment 단위로 쪼개고 header 붙임 (캡슐화), network layer로 전달, IP로 segment 보냄
    • receiver: IP로부터 segment받음, header 확인 후 application layer 메시지 추출, 소켓을 통해 application 으로 message를 역다중화

다중화와 역다중화

  1. 송신 호스트 다중화: 소켓들로부터 데이터를 모으고, 트랜스포트 헤더를 추가
  2. 수신 호스트 역다중화: 헤더 정보를 사용해 수신된 세그먼트들을 올바른 소켓에 전달

역다중화 동작

  1. 비연결형 역다중화
    • UDP 소켓은 두 요소로 구분 (목적지 IP 주소, 목적지 포트번호)
    • 호스트가 UDP 세그먼트 수신 시 세그먼트 내의 목적지 포트번호를 조사, 해당 포트번호를 갖는 소켓에 UDP 세그먼트 전달
    • IP datagram들의 출발지 IP주소 또는 출발지 포트번호가 다르더라도 모두 동일한 목적지 IP주소와 목적지 포트번호를 가지면 같은 소켓에 전달
  2. 연결지향형 역다중화
    • TCP는 4개 요소로 구분 (출발지 IP주소, 출발지 포트번호, 목적지 IP주소, 목적지 포트번호)
    • 수신측 호스트는 4개의 값을 사용해 해당 소케으로 세그먼트를 전달
    • 서버 호스트는 동시에 많은 TCP 소켓들을 지원할 수 있음(각 소켓들은 자신의 4개 요소로 구분)
    • 웹 서버는 연결되는 각 클라이언트마다 다른 소켓들을 가짐(비지속 HTTP는 각 요청에 대해서 다른 소켓을 가짐)

UDP (User Datagram Protocol)

  1. IP에 최소 기능만 추가

    1. 다중화/역다중화
    2. 오류 검사

  2. 최선형(best effort) 서비스의 UDP 세그먼트

    1. 손실 발생
    2. 순서에 어긋나게 애플리케이션에게 전달

  3. 비연결형

    1. UDP 송수신 측 간 연결을 위해 핸드쉐이크를 사용하지 않음
    2. UDP 세그먼트들은 서로 무관하게 독립적으로 다루어짐

  4. 사용

    1. 스트리밍 멀티미디어 응용 (손실 감내, 속도(전송률) 민감)
    2. DNS
    3. SNMP (Simple Network Management Protocol)

  5. UDP 상에서 신뢰적인 전송

    1. application 계층에서 신뢰성 추가
    2. application 의존 에러 복구

  6. UDP segment header

  7. UDP 사용하는 이유

    1. 지연을 유발하는 연결 설정이 없음
    2. 단순하여 송수신 측에서 연결상태가 없음
    3. 간단한 세그먼트 헤더로 인한 작은 패킷 오버헤드
    4. 혼잡제어를 하지 않아서 원하는 만큼 빠르게 전달 가능

  8. UDP 체크섬 (checkSum)

    1. 송신 측

      • 헤더를 포함한 세그먼트의 값을 16비트 정수의 열로 간주
      • 체크섬: 세그먼트 값들을 더한 값의 1의 보수
      • 체크섬 값을 UDP체크섬 필드에 삽입

    2. 수신 측

      • 수신된 세그먼트의 체크섬 값을 계산
      • 계산된 체크섬 값이 체크섬 필드 값과 같은지를 비교, 같으면 에러 없음. 다르면 에러

      → 정수 값 덧셈 시 1의 보수 덧셈은 최상위 비스에서 캐리가 발생하면 결과값에 더해줌

신뢰성있는 데이터 전송의 원리

  1. 파이프라인 프로토콜
    a. 송신자가 ACK 응답을 기다리지 않고 여러 패킷을 전송
    b. 순서 번호의 범위는 증가하여 전송 중인 패킷은 유일한 순서번호를 가짐
    c. 송신 측과 수신 측이 패킷을 버퍼링해야함


  2. 파이프라이닝 프로토콜 개요
    a. GBN(Go-Back-N)프로토콜 → 단순, 불필요한 전송
    - 송신자는 파이프라인에서 최대 N개의 ACK 없이 패킷 전송 허용
    - 수신자는 누적된 ACK (cumulative ACK, 누적 확인 응답)만을 전송, 수신된 패킷들의 순서번호에 갭이 있으면 ACK 응답x
    - 송신자는 가장 오래된, 전송되었지만 ACK 응답 없는 패킷에 대한 타이머를 가짐. 타이머가 완료되면 ACK응답 없는 모든 패킷들을 재전송

b. SR(Selective Repeat, 선택적 반복)
: 동일한 상황에서 sender과 receiver의 입장이 다를 수 있음

  • 송신자는 파이프라인에서 최대 N개의 ACK없이 패킷 전송 허용

  • 수신자는 개별 패킷들에 대해 ACK응답

  • 송신자는 전송되었지만 ACK응답이 없는 패킷들 각각에 대해 개별 타이머를 관리함. 타이머 만료 시 ACK 응답없는 패킷만 재전송

  • sender: data from above → timeout(n) → ACK(n)

  • 만약 window의 최저 seq #이 도착했다면 윈도우 이동

  • receiver: packet n in [rcvbqase, rcvbase + N - 1] 윈도우 안에 패킷이 들어온 경우

  • n번 패킷에 대한 ACK전송, 정상적인 순서로 데이터가 오면 윈도우를 이동

  • out-of-order 패킷을 버퍼링해두고 윈도우 안에 들어오면 그때 함께 application으로 올려줌

    → packet n in [rcvbase-N, rcvbase - 1] //ACK(n)
    → otherwise: ignore

    • rcvbase이하까지는 모두 ACK를 보내줘야함 (재전송 때문에)
      → N보다 큰 범위에서 전송 불가능

    ✅ window size ≤ 1/2 seq #

    window size: seg # 비트수 결정
    size가 너무 크면 packet drop or 충돌 문제 발생
    → rdt 2.1: sender, handling corrupted ACK/NAKs

  • Sequence Number: 4개의 상태 → 1bit (stop and wait)
  1. seq # 0번 추가, 다음 state에서 대기 → ACK/NAK 도착
  2. 만약 패킷에 문제가 있거나 NAK이 도착하면 패킷 재전송
  3. 만약 아무 문제 없고 ACK가 잘 도착했으면 seq # 1번 추가, 다음 state 대기 → 이전 과정 반복

→ rdt 2.1: receiver, handling corrupted ACK/NAKs

  1. 왼쪽 state에서 0번이 왔는지 확인/ 오른쪽 state에서 1번이 왔는지 확인

  2. 패킷에 문제가 없고 seq # 0번이 잘 도착했으면 패킷에서 데이터를 추출하고 ACK와 체크섬을 함께 전달해줌

    3-1. 패킷에 문제가 발생하거나 NAK을 받으면 패킷 재전송

    3-2. 패킷에 문제 없고 seq # 0도착하면 패킷 전송

  3. 2번과 동일 (seq # 1번 도착)

    5-1. 패킷에 문제가 발생하거나 NAK을 받으면 패킷 재전송

    5-2. 패킷에 문제 없고 seq #1 도착하면 패킷 전송

→ rdt 3.0 : channels with errors and loss

  • 패킷 loss 발생할 수 있음 (data/ACKs)
  • new channel assumption :
    1. chcksum
      a. sequence number
      b. ACKs
      c. retransmissions
      → not enough
      d. timer
  • sender는 어느 정도 ACK 기다리고 시간이 지나도 안 오면 패킷을 재전송함.
  • 만약 패킷이 그냥 느리게 간 경우 (no loss) 재전송이 중복되지만 seq #s가 이미 처리함 (not duplicate)

TCP (Transmission Control Protocol)

  1. 전이중 데이터 (full duplex data)
    a. 같은 연결 상에서 양방향 데이터 흐름
    b. 최대 세그먼트 크기 (MSS: Maximum Segment Size)

  2. 연결 지향형

    • 데이터 교환 전에 송신자, 수신자의 상태를 초기화하는 핸드쉐이킹 (제어 메시지들의 교환)

  3. 흐름 제어 (Flow control)

    • 송신자는 수신 한계를 넘어서는 송신을 하지 않음

  4. TCP segment 구조
    a. 순서번호 (Sequence Number): 세그먼트에서 첫 번째 바이트의 바이트 스트림 번호. 시작 순서 번호는 임의로 선택
    b. ACK: 상대방으로부터 기대하는 다음 바이트 순서번호 (누적 ACK)

  1. TCP 왕복 시간과 타임아웃 (TCP RTT와 Timeout)
    a. TCP는 손실 세그먼트 발견을 위해 타임 아웃/재전동 매커니즘 사용
    b. 타임 아웃 주기
    1. 왕복 시간 (RTT)보다 커야함
    2. 너무 짧은 타임 아웃 = 불필요한 재전송 발생
    3. 너무 긴 타임 아웃 = 세그먼트 손실에 대한 대응이 느려짐

신뢰적 데이터 전달

  1. TCP 신뢰적 데이터 전달
    a. 비신뢰적인 인터넷 네트워크 계층 (IP 서비스) 상위 계층에서 신뢰적인 데이터 전달 서비스를 제공함
    - 파이프 라인 되는 segment
    - 누적 ACKs
    - 단일 재전송 타이머
    b. 재전송 점
    - 타임 아웃 이벤트
    - 중복 ACKs
    c. 간소화 TCP 송신자
    - 중복 ACKs 무시
    - 흐름제어 , 혼잡제어 무시

  2. TCP 송신자 이벤트
    a. 전송/재전송과 관련된 TCP 송신자의 이벤트
    - 상위 애플리케이션으로부터 수신된 데이터
    - 타이머 타임아웃
    - ACK 수신
    b. 상위 애플리케이션으로부터 수신된 데이터 이벤트
    - 순서번호를 포함한 세그먼트 생성
    - 순서번호는 세그먼트에서 첫번째 바이트의 바이트 스트림 번호
    - 타이머가 이미 동작 중에 있지 않으면 타이머 시작
    - 타이머의 만료 주기: TimeoutInterval
    c. ACK수신 이벤트
    - 이전에 응답 받지 못한 세그먼트의 확인 응답(ACK)이면, 해당 세그먼트를 ACK 응답된 세그먼트로 표시. 아직 ACK 응답을 받지 못한 세그먼트들이 존재하면 타이머를 시작
    d. 타이머 타임아웃 이벤트
    - 타임아웃을 유발한 세그먼트 재전송
    - 타이머를 다시 시작
    e. 빠른 재전송
    - 타임아웃 주기가 상대적으로 길어질 수 있음 (손실된 패킷을 다시 보내기 전까지 오래 기다림)
    - 중복 ACK를 사용하여 손실된 패킷들을 감지. 송신자는 종종 많은 개수의 세그먼트들을 연속적으로 보내기 때문에 세그먼트가 손실되면 많은 중복 ACK 발생
    - 송신자가 같은 데이터에 대해 3개의 중복 ACK를 수신하게 되면 ACK 응답된 세그먼트의 다음 세그먼트가 손실되었다고 가정. 타이머가 만료되기 전에 재전송

    흐름제어 (Flow Control)

    : 송신자가 너무 많은 데이터를 너무 빠르게 전송하여 수신자의 버퍼를 오버플로우 시키는 것을 방지하는 서비스

    연결관리

    1. TCP 연결 관리

      • TCP 송신자/수신자는 데이터 교환 전에 핸드쉐이크
      • 연결을 설정(서로 연결할 의사가 있음을 확인)
      • 연결 파라미터 값들 합의

    2. TCP 3-way handshake
      a. 클라이언트는 서버에 SYN 세그먼트 송신
      - 세그먼트 헤더의 SYN 비트 플래그 세트
      - 최초의 순서번호를 기술
      - 데이터 없음
      b. 서버는 SYN을 받고, SYNACK 세그먼트를 응답
      - 서버는 TCP 버퍼와 변수를 할당
      - 서버의 최초 순서번호를 기술
      c. 클라이언트는 SYNACK를 받고, ACK 응답
      - 클라이언트는 TCP 버퍼와 변수를 할당
      - ACK 응답에 데이터 (segment payload)가 포함될 수 있음

    3. TCP 연결 종료
      a. 클라이언트는 서버에 FIN 세그먼트를 송신
      - 세그먼트 헤더의 FIN 비트 플래그 세트
      b. 서버는 FIN을 받고, ACK 세그먼트를 응답, FIN 세그먼트를 송신
      c. 클라이언트는 FIN을 받고, ACK 세그먼트를 응답
      - 대기 시간 (timed wait)동안 기다린 후 연결 종료됨
      d. 서버는 ACK를 받고, 연결을 종료함

    혼잡 제어의 원리

    1. 혼잡 제어의 원리
      a. 혼잡 (Congestion)
      - “네트워크가 감당할 수 없을 정도로 너무 많은 출발지(source)에서 너무 많은 데이터를 너무 빨리 송신”하는 것이 원인
      - 혼잡 원인을 처리하기 위해선 혼잡을 일으키는 송신자들을 억제하는 매터니즘이 필요함
      - 혼잡 제어 ≠ 흐름제어
      b. 네트워크 혼잡의 결과
      - 패킷 손실(라우터의 버퍼 오버플로우)
      - 긴 패킷 지연 (라우터 버퍼에서 큐잉)
      c. 혼잡제어는 네트워킹의 기본적인 중요한 문제의 상위 10개 목록 (top 10)에 포함

    2. 혼잡의 원인과 비용
      a. 시나리오 1
      - 두 송신자, 두 수신자, 송수신 속도 (전송률) λin, λout, 링크 처리량 R(또는 라우터 용량 C)
      - 무한 크기의 버퍼를 갖는 한 개의 라우터
      - 재전송 없음
      - 혼잡 시 큰 지연
      - 최대 처리량: R/2

      b. 시나리오 2
      - 유한 버퍼를 가진 하나의 라우터
      - 송신자는 손실된 (타임아웃)) 패킷을 재전송
      - 애플리케이션 계층 입력 = 애플리케이션 계충 출력 λin = λout
      - 트랜스포트 계층 입력은 재전송된 데이터 포함 λ in ≥ λout

      c. 시나리오 2.1
      - 송신자는 패킷이 손실된 경우에만 재전송을 하는 경우 가정 (손실 없음)

      d. 시나리오 2.2
      - 송신자는 패킷이 손실된 경우에만 재전송하는 경우 가정 (R/2에서 일부 패킷들은 재전송되지만 점진적로 R/2에 도달)

      e. 시나리오 2.3

      • 라우터 버퍼가 차 있는 경우 패킷 손실(실제)
      • 송신자가 너무 일찍 타임아웃되어 두차의 복사본을 전송 (R/2에서 중복된 것들을 포함해 일부 패킷들을 재전송)
      • 혼잡의 비용: 손실된 패킷들을 재전송. 큰 지연으로 인한 불필요한 재전송 (라우터가 패킷의 불필요한 복사본을 전할하는데 링크 대역폰 사용)

      f. 시나리오3

      • 네개의 송신자
      • 멀티홉 경로
      • 타임아웃/재전송 매커니즘
      • λ in, λ’ in이 큰 경우에는?
        • λ’ in이 증가함에 따라, 라우터의 패킷들이 손실
        • 또 다른 혼잡 비용: 패킷이 경로 상에서 버려질 때, 버려지는 지점까지 패킷을 전송하는데 사용된 사위 라우터에서 사용된 전송 용량은 낭비!
profile
Jimin
이전 포스트

[network] 2. Application Layer

다음 포스트

[PL] 매개변수 구현 방법

0개의 댓글