[혼공네트] 4주차_전송 계층

담·2024년 7월 30일
네트워크컴퓨터공학
0

컴퓨터공학

목록 보기
10/12
post-thumbnail

전송 계층 : IP의 한계를 보완

  • 네트워크 계층과 응용 계층 사이에 위치
  • 연결형 통신이 가능한 프로토콜을 제공하여 네트워크 계층의 한계 보완 : 신뢰성/연결성 확립

    네트워크 계층의 IP 특징 : 최선형 전달
    (최선을 다해 보겠지만, 전송 결과에 대해서는 어떠한 보장은 하지않겠다)

    • 비신뢰성 프로토콜(신뢰할 수 없는 통신) : 패킷이 수신까지 제대로 전송되었다는 보장을 하지 않는 통신 특성
    • 비연결형 프로토콜 : 송수신 호스트 간에 사전 연결 수립 작업을 거치지 않는 통신 특성
      • 호스트 간에 연결을 수립하는 작업은 패킷의 빠른 송수신과 배치되는 작업
  • 포트를 통해 응용 계층의 어플리케이션 프로세스 식별함으로써 응용 계층과의 연결 다리 역할 수행

포트 : 응용계층과의 연결 다리

  • 응용 계층의 애플리케이션 프로세스를 식별하는 정보

    • 컴퓨터에 도달한 패킷들이 어떤 프로그램(어플리케이션 프로세스)에까지 전달해야하는가 : 패킷의 최종 수신 대상

      프로세스

      • 실행 중인 프로그램
      • 프로그램은 실행되기 전까지는 기억장치에 저장된 데이터 덩어리일뿐, 실행 되는 순간 프로세스가 메인 메모리에 적재됨

    • 특정 호스트에서 실행 중인 특정 애플리케이션 프로세스를 식별 할 수 있다. - IP 주소:포트 번호 형식

  • 포트 번호를 통해 어플리케이션 식별 : 16비트로 표현 가능 (65536개)
  • 포트 범위 : 0번 ~ 65535번까지
  • 잘 알려진 포트 well known port (0 ~ 1023)

    • 널리 알려진, 유명한포트, 시스템 포트

      포트 번호설명
      20, 21FTP
      22SSH
      25SMTP
      53DNS
      67, 68DHCP
      80HTTP
      443HTTPS
  • 등록된 포트 registered port (1024 ~ 49151)

    • 잘 알려진 포트에 비해서는 덜 범용적이지만 흔히 사용되는 애플리케이션

      포트 번호설명
      1194OpenVPN
      1433Microsoft SQL Server 데이터베이스
      3306MySQL 데이터 베이스
      6379Redis
      8080HTTP 대체
  • 동적 포트 (49152 ~ 655535)
    • 사설 포트, 임시포트
    • 사용자가 자유롭게 할당 가능한 포트
      • 인터넷 할당 번호 관리 기관에 의해 할당된 애플리케이션 프로토콜 없음
      • 특별히 관리되지 않는 포트 번호

서버와 클라이언트

서버 (HTTP 서버)

  • 일반적으로 잘 알려진 포트와 등록된 포트로 동작

클라이언트

  • 일반적으로 동적 포트로 동작
  • 예시) 브라우저 : 웹 브라우저를 통해 특정 웹사이트에 접속하는 상황

포트 기반 NAT

NAT

  • 공인 IP주소와 사설 IP 주소 간의 변환하는 기술
  • 하나의 공인 IP 주소를 여러 사설 IP 주소가 공유 가능 (포트 활용)
  • IP 주소 부족 문제 해결
  • NAT 테이블에서는 변환의 대상이 되는 IP 주소가 일대일로 대응되어 있다.

NAPT (Network Address Port Translate)

  • 포트를 활용해 하나의 공인 IP주소를 여러 사설 IP 주소가 공유
    • IP 주소가 같더라도 포트 번호가 다르면 네트워크 내부의 호스트를 특정할 수 있기 때문
  • NAT 테이블에 변환될 IP주소 쌍과 더불어 포트 번호도 함께 기록하고 변환
  • 공인 IP 주소 수 부족 문제 개선
NATNAPT

포트 포워딩 (Port Fowarding)

네트워크 내 특정 호스트에 IP 주소와 포트 번호를 미리 할당하고, 해당 IP 주소:포트 번호로써 해당 호스트에게 패킷을 전달하는 기능

  • 처음 패킷을 보내는 네트워크 외부 호스트 입장에서는 어떤 IP 주소(및 포트)를 수신지 주소로 삼을지 결정하기 어려울 수 있다.
  • 예시) 하나의 EC2 인스턴스에서 백엔드(80)와 프론트엔드(3000)가 각각의 다른 포트에서 서버가 구동될 때, 사용자가 해당 IP 주소 진입시에 프론트엔드 포트로 포트포워딩 시켜준다. 즉, 기본 포트를 프론트엔드 포트로 설정하고 해당 포트로 리다이렉팅 시켜준다.

    상세 설명

    • 포트 포워딩:
      • 네트워크 라우터나 서버에서 외부에서 들어오는 트래픽을 특정 내부 서버의 프론트엔드 포트로 전달합니다. 예를 들어, 외부에서 80번 포트로 들어오는 요청을 내부 서버의 3000번 포트(프론트엔드 포트)로 포트 포워딩합니다.
    • 리다이렉트 설정:
      • 내부 서버의 프론트엔드 포트(예: 3000번 포트)에서 실행 중인 웹 애플리케이션이 사용자의 요청을 처리할 때, URL에 포트 번호가 포함되지 않도록 리다이렉트 설정을 합니다. 예를 들어, http://example.com:3000으로 들어오는 요청을 http://example.com으로 리다이렉트하여 사용자가 포트 번호를 명시하지 않도록 할 수 있습니다.

ICMP

  • IP 패킷의 전송 과정에 대한 피드백 메시지를 얻기위해 사용하는 프로토콜
  • IP의 비신뢰성과 비연결성을 보완하기 위한 네트워크 계층의 프로토콜
    • 보완하는 도우미일뿐, 신뢰성을 완전히 보장하기 위해서는 전송 계층의 프로토콜 필요
  • 종류
    • 전송 과정에서 발생한 문제 상황에 대한 오류 보고
    • 네트워크에 대한 진단 정보(네트워크상의 정보 제공)

TCP (Transmission Control Protocol)

  • 하나 하나 확실히 보냄
  • 통신(데이터 송수신)하기 전에 연결을 수립하고 통신이 끝나면 연결을 종료

MSS (Maximum Segment Size)

  • TCP 세그먼트로 보낼 수 있는 최대 페이로드 크기 (전송 가능한 최대 페이로드 크기)
  • MSS 크기 고려시에 TCP 헤더는 제외

TCP 세그먼트 구조

  • 송신지 포트 (source port) / 수신지 포트 (destination port)
    • 송신지 / 수신지 애플리케이션을 식별하는 포트 번호가 명시
  • 순서 번호 / 확인 응답 번호
    • TCP 신뢰성을 보장하기 위해 사용되는 필드
    • 순서 번호 (sequence number; 시퀀스 넘버)
      • 송수신되는 세그먼트의 올바른 순서를 보장하기 위해 TCP 세그먼트 데이터 첫 바이트에 부여되는 번호
      1. 처음 연결 수립 : 초기 순서번호
      2. 연결 수립이후 : 초기 순서 번호 + 송신한 바이트 수 (== 초기 순서 번호 + 떨어진 바이트수)
    • 확인 응답 번호 (acknowledgment number; ACK 넘버)
      • 상대 호스트가 보낸 세그먼트에 대한 응답
      • 수신호스트가 다음으로 수신받기 기대하는 순서 번호
      • 일반적으로 ‘수신한 순서 번호 + 1’로 설정됨
  • 제어 비트 (control bits) : 플래그 비트
    • 현재 세그먼트에 대한 부가 정보
    • 기본적으로 8비트로 구성
    • ACK : 세그먼트 승인을 나타내는 비트
    • SYN : 연결 수립을 위한 비트
    • FIN : 연결을 끝내기 위한 비트
    • REST: 연결을 리셋하기 위한 비트
  • 윈도우 (window)
    • 수신지 윈도우 크기
    • 한 번에 수신 받고자 하는 양 (흐름 제어에서 언급)

연결형 프로토콜 ; TCP 연결 수립과 종료

TCP는 쓰리 웨이 핸드셰이크로 연결 수립

  1. 연결 설정 (서버 - 클라이언트)

    1. 액티브 오픈 : 처음 연결을 시작하는 호스트 연결 수립 과정 (클라이언트)
    2. 패시브 오픈 : 연결 요청을 받고 나서 요청에 따라 연결 수립 (서버)

  2. 데이터 송수신

  3. 연결 종료

    1. 액티브 클로즈 : 먼저 연결 종료
    2. 패시브 클로즈 : 연결 종료 요청을 받아들이는 호스트

TCP 상태

  • 스테이트풀 (stateful) 프로토콜 : TCP는 상태를 유지하고 활용하기 때문
  • 현재 연결 상태를 나타내기 위해 다양한 상태(state) 활용

  • 연결 수립되지 않은 상태
    • CLOSED : 아무런 연결이 없는 상태
    • LISTEN : 연결 대기 상태, SYN 세그먼트를 기다리는 상태(서버 호스트) : SYN세그먼트를 받으면 쓰리 웨이 핸드세이크 시작
  • 연결 수립 도중 사용되는 상태
    • SYN-SENT : SYN 세그먼트로 보낸 뒤 응답인 SYN+ACK 세그먼트 대기
    • SYN-RECEIVED : 패시브 오픈 호스트가 SYN+ACK 세그먼트를 보낸 뒤 그에 대한 ACK 세그먼트 대기
    • ESTABLISHED : 연결이 확립되었음을 나타내는 상태
      • Three-way handshake 끝났을 경우
      • 데이터 송수신 가능
  • 연결 헤제시 사용되는 상태 : FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, LAST-ACK, TIME-WAIT
    • 엑티브 클로즈 호스트는 마지막 ACK을 보낸뒤 TIME-WAIT 상태에서 일정 시간을 기다리고 연결 종료
      • 상대 호스트가 받았어야 할 마지막 ACK 세그먼트가 올바르게 전송되지 않았을 수 있기 때문
        • 마지막 ACK 세그먼트의 유실 대비
        • 또 다른 연결 과정에서의 패킷 혼선 방지
  • CLOSING : 상대 FIN 세그 먼트에 ACK세그먼트를 보냈지만, 자신의 FIN 세그먼트에 대한 ACK 세그먼트를 받지 못한 상태

    • 보통 동시에 연결을 종료하려 할 때 발생

    • ACK 세그먼트를 수신한다면 각자 TIME-WAIT 상태로 접어든 뒤 종료

UDP (User Datagram Protocol)

빠르게 마구 던지기 때문에 그 과정에서 패킷이 손실되거나 순서가 바뀔 수도 있다.

  • IP 패킷을 감싸는 껍데기일 뿐
  • 비연결성/비신뢰성 프로토콜
    • 상태를 유지와 활용도 하지않기때문에 스테이트리스 프로토콜의 일종
  • TCP의 재전송/흐름 제어/혼잡 제어 등의 기능이 없음
  • 최근 빠른 성능으로 각광받음
    • HTTP/3, NTP, RIP, DNS, DHCP
  • UTP 데이터 그램 : 송신지 포트와 수신지 포트 , UDP 길이, 체크섬 필드 존재
    • 체크섬 : 신뢰성이랑은 관련 없다.

신뢰성 프로토콜 TCP

  • 무엇인가를 확실히 전송했다는 보장
    • 오류 제어 : 잘못 작성된 경우 재전송
    • 흐름 제어 : 받을 수 있을 만큼만 받기
    • 혼잡 제어 : 보낼 수 있는 상황에서만 보내기
  • 파이프라이닝 전송 : 송수신 입장에서 무엇을 고려해야 할지

오류 제어 : 재전송 기능

  • 무엇인가를 확실히 전송했다는 보장
    1. 송신 호스트가 송신한 세그먼트에 문제가 발생했음을 인지할 수 있어야한다.
    2. 오류를 감지하게 되면 해당 세그먼트를 재전송할 수 있어야한다.
  • TCP가 어떤 상황에서 송신한 세그먼트에 문제 있음을 감지하는가.
    1. 중복된 ACK 세그먼트를 수신했을 때; 일부 누락시 반복해서 전송
    2. 타임아웃이 발생했을 때; TCP 세그먼트를 송신하는 호스트는 모두 재전송 타이머 값 유지, 전송할 때마다 재전송 타이머 시작하며 이 타이머의 카운트 다운이 끝난 상황
  • 흐름 제어 : 받을 수 있는 만큼만 받기
    • 수신자의 처리 속도를 고려하여 전송하는 방식
    • TCP는 슬라이딩 윈도우 사용
  • 혼잡 제어 : 보낼 수 있는 상황에서만 보내기
    • 네트워크 혼잡도를 판단하고 혼잡한 정도에 따라 전송량을 조절하는 방식
    • 느린시작, 혼잡 회피, 빠른 회복 등의 알고리즘 사용 가능

RTT(Round Trip Time)

  • 송신 호스트가 세그먼트를 전송한뒤 그에 대한 답변을 받는 데까지 걸리는 시간

ARQ(Automatic Repeat Request: 자동 재전송 요구) 재전송 기반의 오류 제어 : 잘못 전송된 경우 재전송하는 기법

  • TCP는 재전송 기반의 오류 제어를 수행
  • 수신 호스트의 답변(ACK)과 타임아웃 발생을 토대로 문제 진단 및 문제가 생긴 메시지 재전송함으로써 신뢰성 확보; 재전송을 기반으로 잘못된 전송을 바로잡는 것
    • Stop-and-Wait ARQ
    • Go-Back-N ARQ
    • Selective Repeat ARQ

1. Stop-and-Wait ARQ

  • 가장 단순한 형태
  • 제대로 보냈음을 확인하기 전까지는 보내지 않음
  • 전송 → 확인 → 전송 → 확인…
  • 문제점 : 한 번의 전송에 그에 맞는 확인이 필요하기 때문에, 네트워크 이용 효율이 낮음
  • 해결 방안 : 여러 세그먼트를 한 번에 전송(==파이프라이닝)필요

2. Go-Back-N ARQ

  • Stop-and-Wait ARQ의 문제를 해결 : 각 세그먼트가 도착하기 전이라도 여러 세그먼트를 전송(파이프라이닝)
  • 올바른 세그먼트에 대해서는 확인 응답 보냄
  • 문제점 : 올바르지 않은 세그먼트(e.g. N번 세그먼트)가 수신되면 이후(N+1번 이후) 모든 세그먼트 폐기
    • ACK 세그먼트를 수신받지 못한 n+2번 세그먼트부터 다시 전송
  • 누적 확인 응답 (Cumulative ACK) : ‘n번까지의’확인 응답

빠른 재전송 (fast retransmit)

  • 없는 경우 : 재전송 타이머가 만료되어야 비로소 재전송
  • 있는 경우 : 재전송 타이머가 만료되지 않아도 중복 세그먼트가 수신되면 재전송

3. Selective Repeat ARQ

  • Go-Back-N ARQ의 문제를 해결 : 올바르게 수신받지 못한 ACK 세그먼트가 있을 경우 해당 세그먼트만 재전송
    • 올바른 세그먼트에 대해서만 확인 응답 보냄
    • 각 세그먼트에 대한 확인 응답 : 개별 확인 응답

Selective Repeat ARQ 지원여부는 TCP 세그먼트 헤더의 옵션 필드에 속한 SACK(selective acknowledgment)필드를 통해 알수 있다.

  • 두 호스트가 연결 수립할 때 Selective Repeat ARQ를 사용하지 않을 경우 Go-Back-N ARQ방식으로 동작하게 된다.

흐름 제어 : 슬라이딩 윈도우

호스트가 한 번에 받아서 처리할 수 있는 세그먼트의 양에는 한계가 있기 때문에 흐름 제어를 고려해야한다.

  • 송신 버퍼와 수신버퍼
    • 송신 버퍼 : 어플리케이션 계층에서 전송할 데이터 임시 저장되는 공간
    • 수신 버퍼 : 수신된 세그먼트가 애플리케이션 프로세스에 의해 읽히기 전에 임시로 저장되는 공간
  • 송신 호스트가 수신 호스트가 처리할 수 있는 버퍼보다 더 많은 데이터를 전송하면?
    • 버퍼 오버플로우 : 일부 데이터가 처리되지 않을 수 있다.

파이프라이닝 기반(Go-Back-N ARQ, Selective Repeat ARQ)에서 흐름 제어 필요

  • 송신 호스트가 수신 호스트 처리 속도를 고려하며 송수신 속도를 균일하게 맞추는 것
    • 슬라이딩 윈도우 (sliding window) 사용
    • 윈도우 : 송신 호스트가 파이프라이닝 가능한 순서번호 범위
    • 윈도우 크기 : 확인 응답 받지 않고도 한번에 보낼 수 있는 최대량
  • 흐름 제어의 주체 : 수신 호스트
    • (수신) 윈도우 크기 : TCP 헤더를 통해 송신지에게 알려주는 정보
      • 송신측 윈도우는 TCP 헤더 윈도우 필드를 통해 수신 호스트가 알려주는 수신 측 윈도우를 토대로 알 수 있는 정보다.
  • 수신 호스트
    • 수신 윈도우 = 수신 버퍼 크기 - (마지막으로 수신한 바이트 - 마지막으로 읽어들인 바이트)
  • 송신 호스트
    • 수신 윈도우 ≥ 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트

혼잡 제어

  • 혼잡(congestion) : 많은 트래픽으로 인해 패킷 처리 속도가 느려지거나 유실될 우려가 있는 상황
  • 만약, 혼잡 제어가 이루어지지 않는 다면? ⇒ 혼잡→ 유실 → 재전송 → 혼잡 → 유실 → 재전송 → …
  • 혼잡 제어의 주체 : 송신 호스트
    • 어느 정도의 세그먼트를 전송해야할 지를 직접 계산하여 알아내야 한다.
    • 최소값(수신 윈도우, 혼잡 윈도우) ≥ 마지막으로 송신한 바이트 - 마지막으로 수신 확인된 바이트
  • 혼잡이 생기지 않을 정도로만 조금씩 전송하는 방법
  • 혼잡 윈도우 : 혼잡 없이 전송할 수 있을 법한 양
  • 혼잡 제어 알고리즘의 기본 동작 형태 :
    • AIMD (Additive Increade Multicative Decrease) : 합으로 증가, 곱으로 감소
      • 혼잡 미감지 : 혼잡 윈도우를 RTT 마다 1씩 선형적으로 증가
      • 혼잡 감지 : 혼잡 윈도우를 절반으로 떨어뜨리는 것을 반복

TCP 혼잡 제어 알고리즘

혼잡 제어를 수행하는 알고리즘

혼잡제어

  • 타임아웃 발생 : 혼잡 윈도우 값을 1, 혼잡이 감지되었을 시점의 혼잡 윈도우값을 절반으로 초기화 한후 느린 시작 재개
  • 혼잡 윈도우(CWND) ≥ 느린 시작 임계치(SSTHRESH) : 느린 시작 종료, 혼잡 윈도우를 절반으로 초기화한 뒤 혼잡 회피 수행
  • 세 번의 중복 ACK 발생 : (빠른 재전송 후) 빠른 회복 수행

  1. 느린 시작

    • ACK 세그먼트가 수신될 떄마다 혼잡 윈도우 1 증가 (RTT마다 혼잡 윈도우 2배 증가)

  2. 혼잡 회피

    1. 매 RTT마다 혼잡 윈도우 1MSS씩 증가
    2. 느린 시작 임계치를 넘어선 시점부터 혼잡 발생 우려로, 조심히 혼잡 윈도우 증가

  3. 빠른 회복
    1. 세번의 중복 ACK 세그먼트가 수신되었을 때 느린 시작을 건너뛰고 혼잡 회피를 수행하는 알고리즘
    2. TCP Tahoe (빠른 회복 미수행) vs TCP Reno (빠른 회복 수행)

ECN : 명시적 혼잡 알림

  • 혼잡을 회피하기 위해 네트워크 중간 장치(주로 라우터)의 도움을 받는 방법
    • 이전에는 송신 호스트가 혼잡 윈도우 계산 및 조정
  • ECN은 선택적인 기능이기 때문에 통신을 주고받는 양쪽 호스트가 ECN기능을 지원해야 한다.

4주차

진도: Chapter 03

  • 기본 숙제(필수): Ch.04(04-1) 확인 문제 1번(p.206), (04-2) 확인 문제 2번(p.225) 풀고 설명하기
  • 추가 숙제(선택): 작업 관리자에서 프로세스별 PID 확인해 보기

기본 숙제

Ch.04(04-1) 확인 문제 1번(p.206)

  • 비신뢰성, 비연결형
    • IP는 신뢰할 수 없는 비연결형 전송을 수행한다. 전송 계층은 이를 보완하는 프로토콜(TCP)을 제공한다.

Ch.03(04-2) 확인 문제 2번(p.225)

  • ACK
    • TCP는 SYN , SYN + ACK, ACK 를 주고받는 쓰리 웨이 핸드셰이크를 통해 연결 수립

추가 숙제

작업 관리자에서 프로세스별 PID 확인해 보기

회고

아이고 개인사정때문에 너무 늦게 작성했다.
TCP/IP 내용을 겉핥기로 알고 있긴했는데, 이번 시간에 좀 더 자세하게 알게 되었다.
그런데 알게 되기만하고 내 것으로 만들지는 못했던 것 같다. 그래도 네트워크계층보다는 전송 계층이 더 재밌다.

profile
담
성실하게
이전 포스트

[혼공네트] 3주차_네트워크 계층

다음 포스트

[혼공네트] 5주차_응용 계층

0개의 댓글