POSIX

Portable Operating System Interface

• portable : 이식 가능한
• Operationg System : 운영 체제
• Interface : 인터페이스
• X : POSIX 전체 이름에서 유닉스(UNIX) 계열임을 암시하는 관습적 접미사

서로 다른 UNIX 계열 운영체제 간의 애플리케이션 호환성을 높이기 위해

IEEE가 책정한 유닉스 기반의 표준 API 규격으로 ‘X’는 UNIX(유닉스) 호환 운영체제를 의미하는 관습

1. 이름의 탄생 비화 (리처드 스톨먼,  Richard Stallman의 제안)

https://en.wikipedia.org/wiki/POSIX

• 원래 이름
  IEEE 내부에서는 원래 ‘IEEE-IX’라고 부르려고 했습니다.
• 스톨먼의 개입
  자유 소프트웨어 재단(FSF)의 리처드 스톨먼이 “IEEE-IX는 발음하기 너무 어렵다”며,
  ‘Portable Operating System’의 약자에 유닉스 느낌의 ‘IX’를 붙인 POSIX(포직스)를 제안했습니다.
• 채택 이유
  이 이름이 훨씬 부르기 쉽고 기억에 잘 남는다는 이유로 위원회에서 즉시 채택되었습니다.

2. 구체적으로 무엇을 정의하는가?

단순히 API 함수 이름만 정하는 것이 아니라 다음 세 가지 핵심 요소를 모두 포함합니다.

• C 언어 API
  open(), read(), write() 같은 시스템 콜의 함수 이름, 인자, 반환 값, 오류 처리 방식까지 동작 전반을 규정합니다.
• 셸(Shell) 및 유틸리티
  ls, grep, cd 같은 기본 명령어들이 어떤 옵션을 지원하고 어떤 결과를 출력해야 하는지 정의합니다.
• 파일 시스템 및 프로세스
  /usr, /tmp 같은 파일 경로 구조와 프로세스 생성(fork)·종료 방식 등 OS의 근간이 되는 동작 방식을 표준화 합니다.

3. 실무에서의 의미: “한 번 짜서 어디든 돌린다”

• 개발 효율성
  POSIX 표준을 준수하여 프로그램을 만들면, 코드를 거의 수정하지 않고도 Linux, macOS, BSD 등 다양한 운영체제에서 바로 컴파일하여 실행할 수 있습니다.
• 호환성 확인
  어떤 시스템이 “POSIX 준수(Compliant)”라고 하면, 개발자는 “내 프로그램이 이 OS에서도 문제없이 돌아가겠구나”라고 신뢰할 수 있게 됩니다.
• 호환성의 한계
  다만 Windows는 기본적으로 POSIX를 준수하지 않습니다.
  WSL(Windows Subsystem for Linux)을 통해 부분적으로 지원하지만,
  네이티브 Windows 환경에서는 동일한 코드가 동작하지 않을 수 있다는 점을 염두에 두어야 합니다.

The post POSIX(Portable Operating System Interface) appeared first on 어제와 내일의 나 그 사이의 이야기.

HBA (Host Bus Adapter) ?

호스트 버스 어댑터

• Host → 호스트(서버)
• Bus → 버스(시스템 내부 데이터 통로)
• Adapter → 어댑터

서버와 스토리지 네트워크(Fibre Channel SAN)를 연결해주는 인터페이스 카드입니다.

일반적인 이더넷 네트워크에서 사용하는 NIC(Network Interface Card)가 LAN 연결용이라면,

HBA는 스토리지 네트워크 연결을 담당하는 장치라고 보면 됩니다.

즉, 서버가 Storage Array의 LUN에 접근할 수 있도록 통로 역할을 합니다.

기본 개념

서버 내부에는 CPU, 메모리, 디스크 외에도 확장 슬롯(PCIe)이 존재합니다.

이 슬롯에 HBA 카드를 장착하면 서버는 Fibre Channel Fabric에 연결됩니다.

Server
 └─ HBA 카드
     └─ FC 케이블
         └─ FC Switch
             └─ Storage Array

이 구조를 통해 서버는 원격 스토리지를 로컬 디스크처럼 사용할 수 있습니다.

HBA의 역할

스토리지 연결 제공

서버와 SAN(Storage Area Network)을 물리적으로 연결합니다.

프로토콜 처리

SCSI 명령을 Fibre Channel 프레임으로 변환하여 전달합니다.

SCSI(Small Computer System Interface) 명령은 컴퓨터와 스토리지 장치(HDD, SSD, 테이프 등) 간에 데이터 입출력을 제어하기 위한 표준화된 명령어 세트)

WWN 제공

각 HBA 포트는 고유한 WWN(World Wide Name)을 가지며 이를 통해 스위치 Zoning 및 LUN 매핑이 이루어집니다.

데이터 전송 최적화

DMA 등의 기능을 사용하여 CPU 부담을 줄이고 I/O 성능을 향상시킵니다.

HBA 동작 흐름

Application 
 → File System 
 → OS Block Layer 
 → HBA 
 → FC Switch 
 → Storage Array 
 → LUN

사용자는 로컬 디스크처럼 사용하지만 실제 데이터는 SAN을 통해 전송됩니다.

HBA의 특징

서버 입장에서는 일반 디스크 인터페이스처럼 보입니다.

Linux에서는 다음과 같이 확인 가능합니다:

lspci | grep Fibre
systool -c fc_host -v

AIX에서는:

lsdev -Cc adapter

각 포트는 WWN을 가지며 스토리지 접근 제어의 기준이 됩니다.

구성 예시

이중화 구성(일반적인 환경):

Server
 ├─ HBA Port 1 ─ Switch A
 └─ HBA Port 2 ─ Switch B

목적:

• 경로 장애 대비
• 성능 분산
• Multipath 구성

HBA와 Multipath의 관계

서버에 여러 HBA 경로가 존재할 경우 동일한 LUN이 여러 경로로 인식됩니다.

Multipath는 이를 하나의 디스크로 통합하여 관리합니다.

장점:

• 장애 시 자동 경로 전환
• 성능 향상
• 안정성 확보

Linux 예시:

multipath -ll

이는 SAN 환경에서 거의 필수 구성입니다.

은행, 공공기관, 데이터센터 등 엔터프라이즈 환경에서는 대부분의 서버가 HBA를 통해 SAN에 연결되어 있으며

이를 기반으로 데이터베이스, 가상화, 백업 시스템이 운영됩니다.

The post HBA (Host Bus Adapter) – Network appeared first on 어제와 내일의 나 그 사이의 이야기.

• ESXi(VMware 가상화 서버) 여러 개가 각각 다른 LUN에 접근
• VMFS(Virtual Machine File System)라는 파일시스템으로 LUN을 포맷
  (포맷 = 형식을 정한다, 하드드라이브나 저장 장치를 사용 가능한 상태로 준비하는 과정, 즉, “이 공간을 어떤 파일시스템으로 사용할 것인가”를 정하는 작업)

LUN (Logical Unit Number) ?

논리적 저장장치 식별 번호

 스토리지 어레이(Storage Array)  내에서 논리적으로 구분된 저장 공간입니다.

물리적 디스크를 여러 개의 논리적 단위로 나누어 각 서버에 할당하는 개념입니다.

기본 개념

실제 디스크 어레이에는 여러 개의 물리 디스크(Physical Disk)가 있습니다.

이 물리 디스크들을 RAID로 구성하여 보호한 후, 그 위에 논리적으로 공간을 나누어 LUN을 만듭니다.

각 서버는 자신에게 할당된 LUN을 마치 자신의 로컬 디스크처럼 접근합니다.

LUN의 특징

서버 입장에서는 LUN을 로컬 하드드라이브처럼 인식합니다.

예를 들어 Windows 서버에서는 D드라이브, E드라이브처럼 보입니다.

각 LUN은 고유한 번호(0, 1, 2, 3 …)로 식별되며, 이를 통해 서버는 어떤 저장 공간에 접근할지 구분합니다.

LUN 할당의 예시

Disk Array (물리 용량: 10TB)
│
├─ LUN 0 (2TB) → Server Node 1 에 할당
├─ LUN 1 (2TB) → Server Node 2 에 할당
├─ LUN 2 (3TB) → Server Node 3 에 할당
└─ LUN 3 (3TB) → 백업 시스템에 할당

LUN의 장점

여러 서버가 같은 물리 디스크를 공유하면서도 각자 독립적인 저장 공간을 가질 수 있습니다.

Storage Array에서 한 서버의 LUN을 다른 서버에 재할당할 수 있어 유연한 리소스 관리가 가능합니다.

또한 각 LUN별로 스냅샷, 복제, 백업 등을 독립적으로 관리할 수 있습니다.

중요한 제약사항

여러 서버가 같은 LUN을 공유하면 안됨

만약 Server 1과 Server 2가 같은 LUN에 동시에 쓰기 작업을 하면 데이터가 손상됩니다.

따라서 일반적으로 각 LUN은 하나의 서버에만 할당됩니다.

다만, 예외가 있습니다.

Cluster 환경이나 Shared Disk File System(예: VMFS, GFS)을 사용하면 여러 서버가 같은 LUN을 공유할 수 있습니다.

이 경우 운영체제나 특수 소프트웨어가 동시 접근을 제어합니다.

LUN과 Zoning의 관계

LUN 할당만으로는 보안이 완벽하지 않습니다.

Zoning은 Fibre Channel 스위치 레벨에서 특정 서버가 특정 스토리지만 접근하도록 제한합니다.

(TCP/IP 계층의 레벨이 아님 – TCP/IP 스택을 쓰지 않음 ㅋㅋ)

만약, Server 1은 LUN 0에만 접근 가능하도록 Zoning을 설정하면, 실수로 LUN 1에 접근하려고 해도 FC 스위치가 차단합니다.

은행의 데이터베이스 서버는 LUN 0(금융거래 DB용), 웹 서버는 LUN 1(웹 콘텐츠용)을 할당받습니다. 
각 LUN은 독립적으로 백업되고 관리됩니다. 
만약 웹 서버가 추가되면, Storage Array에서 기존 LUN 2의 일부를 새 LUN으로 생성하여 할당할 수 있습니다.

The post LUN (Logical Unit Number) – Network appeared first on 어제와 내일의 나 그 사이의 이야기.

• EOS Linux: “스토리지 어레이를 운영하기 위한” 전문화된 OS

• Server Node 계층 – 데이터를 요청하는 호스트 서버들
• Fabric Switch 계층 – 서버와 스토리지를 연결하는 FC 스위치
• Storage Array 계층 – 실제 데이터를 저장하는 디스크 어레이

SAN (Storage Area Network) ?

SAN은 스토리지 장치들을 고속 네트워크로 연결하여 서버들이 마치 로컬 디스크처럼 접근할 수 있도록 하는 네트워크 환경을 말합니다.

주로 파이버 채널(FC) 또는 iSCSI 기술을 활용하여 높은 대역폭, 짧은 대기 시간, 우수한 안정성을 제공하며,

엔터프라이즈 환경에서 데이터베이스 및 가상화 시스템의 핵심 데이터를 공유·저장하는 데 사용됩니다.

서버와 스토리지 간의 데이터 전송을 LAN과 분리된 전용 네트워크에서 처리하므로 네트워크 트래픽을 효율적으로 관리할 수 있습니다.

기본 개념

기존의 NAS(Network Attached Storage)는 파일 단위로 접근하는 방식이라면, SAN은 블록(Block) 단위로 스토리지에 직접 접근합니다.

마치 내부 하드드라이브에 접근하는 것처럼 동작하므로 고속 데이터 전송이 가능합니다.

SAN의 구성요소

SAN은 크게 세 가지 계층으로 이루어집니다.

첫째, 서버 계층으로 데이터 요청을 하는 호스트 서버들입니다.

둘째, 스토리지 계층으로 실제 데이터를 저장하는 스토리지 어레이(Storage Array)입니다.

셋째, 네트워크 계층으로 서버와 스토리지를 연결하는 고속 네트워크입니다.

네트워크 계층에는 주로 Fibre Channel 스위치가 사용되며, HBA(Host Bus Adapter)는 서버가 SAN에 접속하기 위한 어댑터 역할을 합니다.

SAN의 장점

스토리지를 중앙 집중식으로 관리할 수 있어 관리 효율성이 높습니다.

스냅샷, 스냅샷 복제, RAID 등 고급 기능을 활용한 데이터 보호가 가능하며, 여러 서버가 같은 스토리지를 공유하므로 리소스 활용도가 높습니다.

또한 원거리 스토리지 연결이나 재해복구를 쉽게 구현할 수 있습니다.

SAN의 단점

Fibre Channel 스위치, HBA, 고가의 스토리지 어레이 등이 필요하여 초기 구축 비용이 매우 높습니다.

또한 설계, 설치, 운영이 복잡하며 전문 인력이 필요합니다.

네트워크 구성에 따라 병목 현상이 발생할 수 있으며, 장애 발생 시 많은 서버에 영향을 미칠 수 있습니다.

SAN의 주요 용도

데이터베이스 서버의 고가용성(HA) 구현, 서버 클러스터링, 가상화 환경에서의 스토리지 공유, 백업 및 재해복구 시스템 구축에 주로 사용

NAS와 SAN 차이

참고

Fibre Channel Switch

• Fibre Channel 프로토콜만 사용하는 스위치
• FC 환경 전용

SAN Switch

• SAN 환경에서 사용되는 모든 스위치를 통칭
• Fibre Channel Switch, iSCSI Switch, FCoE Switch 등 모두 포함

SAN Switch (큰 개념)
  ├─ Fibre Channel Switch (FC 스위치)
  ├─ iSCSI Switch (이더넷 기반)
  ├─ FCoE Switch (Fibre Channel over Ethernet)
  └─ 기타 SAN 스위치

The post SAN (Storage Area Network) – Network appeared first on 어제와 내일의 나 그 사이의 이야기.

FCIP (Fibre Channel over IP) ?

FCIP는 Fibre Channel 프로토콜을 IP 네트워크를 통해 전송하는 기술로

원거리에 있는 스토리지 시스템을 연결하거나 재해 복구(Disaster Recovery, DR) 목적으로 자주 사용합니다.

기본 개념

FCIP는 Fibre Channel 프레임을 TCP/IP 기반 네트워크에서 캡슐화하여 전송합니다.

이를 통해 기존의 고가의 Fibre Channel 인프라에 의존하지 않고도 표준 IP 네트워크(이더넷)를 활용할 수 있습니다.

FC-2 Frame Format은 SOF(Start of Frame)에서 시작하여 Extended Header, Frame Header, Data Field, CRC, EOF(End of Frame) 순서로 구성

• Extended Header (확장 헤더) : 프레임의 기본 정보 외에 추가적인 제어 정보가 필요할 때 사용
• Frame Header (프레임 헤더) : 프레임의 기본 정보를 담고 있는 24바이트 크기의 필수 영역
• Data Field (데이터 필드) : 실제 전송되는 데이터가 들어가는 영역
• CRC (Cyclic Redundancy Check, 순환 중복 검사) : 4바이트 크기의 오류 검사 코드
• EOF(End of Frame) : 프레임의 끝을 알리는 4바이트 신호

Data Field는 최대 2112Byte(약 2 KB)까지 담을 수 있으며, 이러한 Fibre Channel 프레임 전체가 IP 패킷에 캡슐화되어 네트워크를 통해 전송

주요 특징

장점

• 기존 IP 네트워크 활용으로 구축 비용을 절감.
• 원거리 백업 및 재해복구가 용이함.
• Fibre Channel의 성능을 유지하면서 확장성을 높일 수 있음.

단점

• WAN 대역폭에 의존하므로 대역폭 제약으로 네트워크 지연(latency)이 발생할 수 있음.
• IP 네트워크의 신뢰성에 영향을 받음.
• 초기 설정과 트러블슈팅이 복잡함.

주요 용도

원격지의 스토리지 시스템을 동기화하는 동기식 복제와 원거리 백업 및 재해복구 목적의 비동기식 복제에 주로 사용

The post FCIP (Fibre Channel over IP) – Network appeared first on 어제와 내일의 나 그 사이의 이야기.

문제 상황

Unity 에디터의 Package Manager에서 Services Core 패키지가 빨간색 경고와 함께 “Invalid Signature” 표시

광고 초기화 실패(Gateway communication failure) 등의 문제가 발생

이는 패키지 자체의 손상이 아니라 Package Manager의 서명 검증 시스템 오류

오류의 의미와 영향

Package Manager의 서명 검증 실패

Unity Package Manager는 모든 패키지의 디지털 서명을 확인하는 검증 메커니즘을 가지고 있

“Invalid Signature”는 Package Manager의 서명 검증 로직이 정상적인 패키지를 잘못 거부하는 버그

실제 패키지는 정상이지만, Package Manager가 잘못된 판단을 내리고 있는 상태로 생각됨

Unity Ads 초기화 실패와의 연결

Services Core는 단순한 라이브러리가 아니라 Unity Ads를 포함한 모든 유니티 서비스의 핵심 패키지입니다.

이 패키지가 손상되면:

• Unity Ads 초기화 실패 Gateway communication failure 오류 발생 광고 로드 및 표시 불가 기타 Unity Services(Analytics, Crash Reporting 등) 동작 불능

해결 방법 (개인적인)

Package Manager 캐시 삭제

로컬에 저장된 손상된 패키지 캐시를 강제로 삭제

Unity 에디터를 완전히 종료합니다 다음 폴더로 이동:

• Windows: %AppData%/Local/Unity/cache/upm
• Mac: ~/Library/Caches/Unity/upm
• Linux: ~/.cache/unity/upm

upm 폴더 전체를 삭제합니다

Unity 에디터를 다시 열면 Package Manager가 서버에서 패키지를 새로 다운로드하고 서명을 다시 검증

주의: 이 작업은 안전하며, 폴더를 다시 열면 필요한 캐시가 자동으로 재생성됩니다.

Reset Packages to Defaults (마지막 수단)

프로젝트의 패키지 설정이 꼬인 경우 초기화가 필요합니다.

Unity 상단 메뉴: Help > Reset Packages to defaults 선택

확인 대화상자에서 “Yes” 클릭

프로젝트의 manifest.json이 기본값으로 되돌려집니다

주의: 이 작업은 프로젝트의 패키지 설정을 초기화하므로:

수동으로 추가했던 다른 패키지가 있다면 다시 설치해야 합니다

Packages/manifest.json 파일이 변경됩니다

The post Unity Package Manager “Invalid Signature” appeared first on 어제와 내일의 나 그 사이의 이야기.

1. 모든 데이터베이스별 총 용량 확인

현재 서버에 있는 모든 DB의 크기를 한눈에 비교하고 싶을 때 사용합니다.

용량이 큰 순서대로 정렬되어 출력됩니다.

SELECT 
    table_schema AS 'Database Name',
    ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)',
    ROUND(SUM(data_free) / 1024 / 1024, 2) AS 'Free Space (MB)'
FROM 
    information_schema.tables
GROUP BY 
    table_schema
ORDER BY 
    (SUM(data_length + index_length)) DESC;

2. 특정 데이터베이스 내의 테이블별 용량 상세 확인

“어떤 테이블이 용량을 다 잡아먹고 있지?”라는 궁금증이 생겼을 때 사용합니다.

데이터 크기와 인덱스 크기를 구분해서 보여줍니다.

데이터 크기와 인덱스 크기를 구분

SELECT 
    table_name AS 'Table Name',
    table_rows AS 'Total Rows',
    ROUND(data_length / 1024 / 1024, 2) AS 'Data Size (MB)',
    ROUND(index_length / 1024 / 1024, 2) AS 'Index Size (MB)',
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS 'Total Size (MB)'
FROM 
    information_schema.tables
WHERE 
    table_schema = '데이터베이스명' -- 여기에 DB 이름 입력
ORDER BY 
    (data_length + index_length) DESC;

3. 전체 서버의 총 합계 용량 확인

서버 전체에서 MySQL이 사용하는 총 디스크 용량만 깔끔하게 보고 싶을 때 유용합니다.

SELECT 
    ROUND(SUM(data_length + index_length) / 1024 / 1024 / 1024, 2) AS 'Total Global Size (GB)'
FROM 
    information_schema.tables;

4. 참고

• data_length: 실제 데이터가 들어있는 물리적 크기입니다.
• index_length: 인덱스(색인)가 차지하는 크기입니다. 데이터는 적은데 인덱스가 너무 크면 최적화(OPTIMIZE TABLE)를 고려해야 합니다.
• data_free: DELETE 등으로 삭제된 행이 차지하던 ‘비어있는 공간’입니다. 이 값이 너무 크면 디스크 공간 낭비가 심하다는 뜻입니다.

The post MySQL 데이터베이스 & 테이블 용량 확인 appeared first on 어제와 내일의 나 그 사이의 이야기.

JWT(Json Web Token) 정리

https://www.jwt.io/introduction#how-json-web-tokens-work

1⃣ 개요

JWT(Json Web Token) 는 클라이언트와 서버 간에 정보를 안전하게 전달하기 위한 토큰 기반 인증 방식입니다.

이는 RFC 7519 에 정의된 개방형 표준(Open Standard) 입니다.

JWT는 JSON 형식의 데이터를 Base64URL로 인코딩하고, 디지털 서명(Signature) 을 통해 위변조를 방지합니다.

2⃣ JWT의 구조

JWT는 .(점) 으로 구분된 3개의 부분으로 구성됩니다.

xxxxx.yyyyy.zzzzz

예시

// Header (헤더)
Header: 
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload (페이로드) - 클레임(Claim)
Payload:
{
  "sub": "1234567890",      // 주제 (Subject)
  "name": "John Doe",       // 사용자 이름
  "admin": true,            // 역할
  "iat": 1516239022,        // 발행 시간 (Issued At)
  "exp": 1516242622         // 만료 시간 (Expiration)
}

// Signature (서명)
Signature:
HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  secret
)

결과

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

3⃣ JWT의 동작 방식

1. 사용자가 로그인 요청을 전송

2. 서버는 사용자의 인증 정보(아이디, 비밀번호 등)를 검증

3. 인증에 성공하면 JWT 토큰을 생성하여 클라이언트에게 발급

4. 클라이언트는 이후 요청마다 Authorization 헤더에 토큰을 포함

Authorization: Bearer <JWT_TOKEN>

## 예시
Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJuYW1laWQiOiIxIiwidW5pcXVlX25hbWUiOiJhZG1pbiIsImVtYWlsIjoiYWRtaW5AZGVtby5jb20iLCJMb2dpblRpbWUiOiIyMDI1LTEwLTEyVDIyOjEwOjMwLjY3NDg3ODVaIiwicm9sZSI6WyJBZG1pbiIsIlVzZXIiXSwibmJmIjoxNzYwMzA3MDMwLCJleHAiOjE3NjAzMTA2MzAsImlhdCI6MTc2MDMwNzAzMCwiaXNzIjoibHljb3M3NTYwLmNvbSIsImF1ZCI6Ik15QXVkaWVuY2UifQ.Vo2eV6JLLJLg_qBvfalPZI87n8UVQRCn5mAAhRjDnuU

5. 서버는 요청을 받을 때마다 JWT 토큰의 유효성(Signature 및 만료 시간) 을 검증

6. 유효한 경우 요청을 처리하고, 그렇지 않으면 401 Unauthorized 응

4⃣ JWT의 장점과 단점

장점	설명
확장성	세션을 서버 메모리에 저장하지 않아도 되므로, 서버 확장에 유리
무상태성	서버가 사용자 상태를 기억하지 않아도 됨 (Stateless)
범용성	웹, 모바일, API 등 다양한 환경에서 동일한 인증 방식 사용 가능

단점	설명
토큰 무효화 어려움	만료 전까지 유효 → 즉시 로그아웃 구현 어려움
보안 주의 필요	비밀키 유출 시 전체 시스템 위험, XSS/CSRF 취약
크기 문제	세션 ID보다 커서 네트워크 트래픽 증가 가능, 매 요청마다 JWT 토큰 전송 → 트래픽 증가

5⃣ JWT의 주요 Claim

6⃣ Refresh Token 전략

Access Token의 수명이 짧기 때문에, Refresh Token을 사용해 재발급하는 구조가 일반적입니다.

1. 로그인 시 Access Token + Refresh Token 발급

2. Access Token 만료 시 Refresh Token으로 갱신 요청

3. 서버는 Refresh Token 검증 후 새로운 Access Token 발급

4. Refresh Token 탈취 시 위험하므로 DB나 Redis에 저장해 관리
Refresh Token 탈취 시 장기 인증이 노출될 수 있으므로, IP / User-Agent 기반 검증 또는 토큰 회전(Token Rotation) 권장

7⃣ JWT 사용 시 보안 주의사항

HTTPS 필수 사용 (평문 노출 방지)

Authorization 헤더 사용 (쿠키보다 안전)

짧은 만료 시간 + Refresh Token 병행

민감정보(비밀번호 등)는 Payload에 절대 포함 금지

IP, User-Agent 등 부가 정보 검증 가능

HttpOnly Cookie + Secure 옵션으로 XSS 방지

서명키(secret) 는 .env 또는 KeyVault 등 안전한 저장소 사용

결론

JWT는 확장성과 무상태성을 제공하는 강력한 인증 수단이지만, 보안 관리(비밀키, 만료, 저장 위치 등) 가 핵심입니다.

실제 운영환경에서는 Access/Refresh Token 분리 + HTTPS + 짧은 만료를 조합해 안전하고 효율적인 인증 시스템을 구축해야 합니다.

The post JWT(Json Web Token) 정리 appeared first on 어제와 내일의 나 그 사이의 이야기.

OSI 7 계층

OSI 7계층은 국제 표준화 기구(ISO)에서 네트워크 통신 과정을 7개의 논리적인 계층으로 나눈 참조 모델로

복잡한 네트워크 통신을 계층별로 나누어 표준화 함으로써,

서로 다른 하드웨어 및 소프트웨어 간의 호환성을 높이고, 문제 발생 시 해당 계층에 쉽게 문제를 파악하고 해결할 수 있도록 돕는 역할을 합니다.

각 계층은 독립적인 기능을 수행하며, 하위 계층에 서비스를 제공하고 상위 계층으로부터 서비스를 받습니다.

데이터는 송신 측에서 7계층부터 1계층으로 내려가면서 각 계층의 헤더(Header)가 추가되어(캡슐화) 전송되고,

수신 측에서는 1계층부터 7계층으로 올라오면서 각 계층의 헤더가 제거되어(역캡슐화) 최종적으로 데이터에 접근하게 됩니다.

각 계층은

1. 물리 계층 (Physical Layer)
2. 데이터 링크 계층 (Data Link Layer)
3. 네트워크 계층 (Network Layer)
4. 전송 계층 (Transport Layer)
5. 세션 계층 (Session Layer)
6. 표현 계층 (Presentation Layer)
7. 응용 계층 (Application Layer)

으로 이루어져 있습니다.

1. 물리 계층 (Physical Layer)

역할

네트워크 통신의 가장 기초적인 단계로, 데이터를 물리적인 매체(케이블, 무선 신호 등)를 통해 비트(0과 1) 단위의 전기적 신호로 전송하고 수신하는 계층입니다.

주요 기능

전기적 신호의 전압 레벨, 신호 타이밍, 물리적 연결(커넥터 규격), 전송 매체(UTP, 광섬유 등)의 특성 등을 정의합니다.

단순히 0과 1의 비트 정보만 전달할 뿐 데이터의 의미는 해석하지 않습니다.

데이터 단위

비트 (Bit)

관련 장비

허브(Hub), 리피터(Repeater), 모뎀, 케이블, 커넥터

프로토콜 예시

이더넷(Ethernet)의 물리적 규격, RS-232C

2. 데이터 링크 계층 (Data Link Layer)

역할

물리 계층을 통해 전송되는 비트 스트림을 프레임(Frame)이라는 논리적인 단위로 묶고, 인접한 두 장치(노드) 간의 신뢰성 있는 데이터 전송을 보장합니다.

주요 기능

MAC 주소(물리 주소)를 이용한 장치 식별 및 주소 지정, 프레임 구성(시작/끝 비트, 헤더, 데이터, 트레일러), 오류 감지 및 수정, 흐름 제어, 매체 접근 제어(CSMA/CD, 토큰 링 등)를 수행합니다.

데이터 단위

프레임 (Frame)

관련 장비

스위치(Switch), 브리지(Bridge)

프로토콜 예시

이더넷(Ethernet), Wi-Fi, PPP(Point-to-Point Protocol), HDLC

3. 네트워크 계층 (Network Layer)

역할

여러 개의 독립적인 네트워크를 통해 목적지까지 패킷(Packet)을 가장 효율적인 경로로 전송하는 라우팅(Routing) 기능을 수행합니다.

논리적 주소인 IP 주소를 사용하여 장치를 식별하고 경로를 결정합니다.

주요 기능

IP 주소를 이용한 종단 간(End-to-End) 패킷 전송, 최적의 경로 선택(라우팅), 패킷 포워딩(다른 네트워크로 패킷 전달), 네트워크 혼잡 제어를 담당합니다.

데이터 단위

패킷 (Packet)

관련 장비

라우터(Router), L3 스위치

프로토콜 예시

IP(Internet Protocol – IPv4/IPv6), ICMP(Internet Control Message Protocol), ARP(Address Resolution Protocol), RIP(Routing Information Protocol), OSPF(Open Shortest Path First)

4. 전송 계층 (Transport Layer)

역할

송신자와 수신자 간의 신뢰할 수 있는 종단 간 데이터 전송을 보장하며, 응용 프로그램(프로세스)을 식별하기 위해 포트 번호를 사용합니다.

주요 기능

연결 설정 및 해제(TCP의 3-Way Handshake), 오류 복구(재전송), 흐름 제어(버퍼링), 데이터 분할 및 재조립(세그먼트화), 포트 번호를 이용한 프로세스 간 통신(Multiplexing/Demultiplexing)을 제공합니다.

데이터 단위

세그먼트 (Segment – TCP), 데이터그램 (Datagram – UDP)

관련 장비

게이트웨이(일부 기능), 방화벽(일부 기능)

프로토콜 예시

TCP(Transmission Control Protocol), UDP(User Datagram Protocol)

5. 세션 계층 (Session Layer)

역할

통신하는 두 응용 프로그램(또는 프로세스) 간의 대화(세션)를 설정, 유지, 동기화 및 종료하는 기능을 담당합니다.

주요 기능

세션 설정 및 해제, 데이터 교환 방식(전이중, 반이중, 단방향) 제어, 동기점(Synchronization Point) 설정을 통해

통신 중 오류 발생 시 처음부터 다시 시작하지 않고 동기점부터 재개할 수 있도록 복구 기능을 제공합니다.

데이터 단위

메시지 (Message) 또는 데이터 (Data)

프로토콜 예시

NetBIOS, RPC(Remote Procedure Call), SQL 세션

6. 표현 계층 (Presentation Layer)

역할

응용 계층의 데이터를 시스템 간에 서로 이해할 수 있는 공통된 형식으로 변환하는 계층입니다.

데이터 표현의 독립성을 제공합니다.

주요 기능

데이터 포맷 변환(예: ASCII EBCDIC), 데이터 암호화 및 복호화, 데이터 압축 및 압축 해제 등을 수행하여

응용 계층에서 사용하는 데이터를 네트워크 전송에 적합한 형태로 변환합니다.

데이터 단위

메시지 (Message) 또는 데이터 (Data)

프로토콜 예시

JPEG, MPEG, GIF, ASCII, EBCDIC, SSL/TLS(일부 보안 및 암호화 기능)

7. 응용 계층 (Application Layer)

역할

최종 사용자(End User)가 네트워크 서비스에 직접 접근할 수 있도록 응용 프로그램에 특화된 서비스를 제공하는 최상위 계층입니다.

사용자와 가장 가까운 계층이며, 다양한 네트워크 애플리케이션 프로토콜이 정의됩니다.

주요 기능

사용자 인터페이스 제공, 이메일, 파일 전송, 웹 브라우징 등 특정 애플리케이션 서비스를 제공합니다.

실제 사용자가 이용하는 웹 브라우저, 이메일 클라이언트, 파일 전송 프로그램 등이 이 계층의 프로토콜을 활용합니다.

데이터 단위

메시지 (Message) 또는 데이터 (Data)

프로토콜 예시

HTTP/HTTPS(웹 브라우징), FTP(파일 전송), SMTP/POP3/IMAP(이메일), DNS(도메인 이름 해석), DHCP(IP 주소 할당), SNMP(네트워크 관리)

The post OSI 7 계층 (Open Systems Interconnection 7 Layers) appeared first on 어제와 내일의 나 그 사이의 이야기.

API

https://docs.unity3d.com/Packages/com.unity.transport@2.5/api/index.html

Unity Transport?

Unity Transport 2.5.1

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/index.html

Unity Transport는 멀티플레이어 게임 개발을 위한 저수준 네트워킹 라이브러리입니다.

Unity의 두 가지 Netcode 솔루션인 Netcode for GameObjects(NFG)와 Netcode for Entities(NFE)의 기반으로 사용됩니다.

또한 사용자가 직접 만든 커스텀 네트워크 솔루션과 함께 사용할 수 있습니다.

Unity 엔진에서 지원하는 모든 플랫폼은 UDP 소켓 또는 WebSocket을 통해 제공되는 연결 기반 추상화 계층(내장 네트워크 드라이버) 덕분에 Unity Transport에서 원활하게 지원됩니다.

둘 다 암호화 유무에 따라 설정할 수 있으며, 위 블록 다이어그램에서 닫힌 자물쇠와 열린 자물쇠로 표시됩니다.

특히 파이프라인은 안정성, 패킷 순서 지정 및 패킷 조각화와 같은 추가적인 선택적 기능들을 제공합니다.

요구 사항

Unity Transport는 Unity 엔진이 지원하는 모든 플랫폼을 지원합니다.

WebGL의 경우, 클라이언트 모드에서 WebSocket 연결만 지원되며, Unity Relay를 사용하는 경우에는 호스팅도 가능합니다.

현재 문서는 Unity Transport 2.X 버전에 대한 설명이며, 이는 Unity Editor 2022.3 이상에서만 호환됩니다.

구 버전의 에디터는 Transport 1.X에서 지원됩니다. 아래는 호환성 표를 참고하세요.

참고사항

이 패키지는 Netcode for GameObjects의 NetworkTransport 추상화 계층과 혼동하면 안됩니다.

더 자세한 내용은 해당  transports section of its documentation을 참고하세요.

Sample Project

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/samples-usage.html

Unity Transport 패키지에는 Samples 폴더가 포함되어 있으며, 이 폴더에는 라이브러리의 기본적인 개념을 설명하는 간단한 어셈블리 정의와 관련된 씬들이 들어 있습니다.

이 샘플들은 패키지 매니저 창에서 Unity Transport 패키지를 선택했을 때 가져올 수 있습니다.

• Cross-play Example : MultiNetworkDriver를 사용하여 UDP와 WebSocket 연결을 모두 허용하는 서버를 만드는 방법의 예입니다.
• Jobified Client and Server : 작업을 사용하는 매우 간단한 클라이언트 및 서버 구현. 패키지 문서와 연계되도록 설계되었습니다.
• Ping Sample : 클라이언트와 서버 간 왕복 시간(핑)을 계산하는 소규모 애플리케이션입니다.
• Relay Sample(with Relay) : 유니티 릴레이를 사용하여 클라이언트와 호스트 간의 왕복 시간(핑)을 계산하는 작은 애플리케이션
• SimpleClientServer : 가장 간단한 클라이언트 및 서버 구현. 패키지 문서와 연계되도록 설계되었습니다.

간단한 클라이언트 서버

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/client-server-simple.html

이 예제는 Unity Transport 패키지의 모든 주요 기능을 다루며, 다음과 같은 API 사용법을 보여주는 샘플 프로젝트를 만드는 데 도움을 줍니다:

• 전송 구성 (Configure the transport)
• 연결 수립 (Establish a connection)
• 데이터 전송 (Send data)
• 데이터 수신 (Receive data)
• 연결 종료 (Close a connection)

1⃣ 서버 생성

서버는 들어오는 연결 요청을 듣고 메시지를 주고받는 엔드포인트를 생성합니다.

ServerBehaviour.cs

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ServerBehaviour : MonoBehaviour {

    // Use this for initialization
    void Start () {

    }

    // Update is called once per frame
    void Update () {

    }
}

2⃣ 보일러플레이트 코드 (Boilerplate Code)

반복되는 작업이나 패턴에 대한 일종의 표준화된 코드인 Boilerplate를 생성합니다.

이 패키지는 완전한 제어권을 가지도록 선택한 아키텍처 설계로 저수준 API만 제공합니다.

따라서 약간의 Boilerplate 코드를 설정해야합니다.

1. NetworkDriver 선언 – Server

ServerBehaviour.cs

using UnityEngine;
using Unity.Collections;
using Unity.Networking.Transport;

public class ServerBehaviour : MonoBehaviour 
{
    NetworkDriver m_Driver;
    NativeList<NetworkConnection> m_Connections;
}

• NetworkDriver: Unity Transport 패키지의 핵심 API로, 네트워크 통신을 제어합니다.
• NativeList: 서버에 연결된 클라이언트들의 연결 정보를 저장하는 컨테이너 (Unmanaged Memory 사용).

2. 서버 초기화 (Start) – Server

void Start()
{
    m_Driver = NetworkDriver.Create();
    m_Connections = new NativeList<NetworkConnection>(16, Allocator.Persistent);

    var endpoint = NetworkEndpoint.AnyIpv4.WithPort(7777);
    if (m_Driver.Bind(endpoint) != 0)
    {
        Debug.LogError("Failed to bind to port 7777.");
        return;
    }
    m_Driver.Listen();
}

1. 드라이버 생성 → 연결 리스트 초기화 (최대 16개 연결 수용)
2. 모든 IPv4 주소(AnyIpv4)에서 7777 포트로 바인딩 시도
3. 성공 시 Listen()으로 클라이언트 연결 대기 시작.

3. 리소스 정리 (OnDestroy) – Server

void OnDestroy() 
{
    if (m_Driver.IsCreated) {
        m_Driver.Dispose();
        m_Connections.Dispose();
    }
}

• Unmanaged Memory를 직접 해제해야 메모리 누수 방지
• IsCreated로 할당 여부 확인 후 해제

4. 서버 업데이트 루프 (Update) – Server

void Update() 
{
    m_Driver.ScheduleUpdate().Complete();

    // 1. 오래된 연결 정리
    for (int i = 0; i < m_Connections.Length; i++) {
        if (!m_Connections[i].IsCreated) {
            m_Connections.RemoveAtSwapBack(i);
            i--;
        }
    }

    // 2. 새 연결 수락
    NetworkConnection c;
    while ((c = m_Driver.Accept()) != default) {
        m_Connections.Add(c);
        Debug.Log("클라이언트 연결 수락");
    }

    // 3. 연결별 이벤트 처리
    for (int i = 0; i < m_Connections.Length; i++) {
        DataStreamReader stream;
        NetworkEvent.Type cmd;
        while ((cmd = m_Driver.PopEventForConnection(m_Connections[i], out stream)) 
               != NetworkEvent.Type.Empty) {
            
            if (cmd == NetworkEvent.Type.Data) {
                uint number = stream.ReadUInt();
                Debug.Log($"클라이언트로부터 {number} 수신, +2 처리");

                number += 2;
                m_Driver.BeginSend(NetworkPipeline.Null, m_Connections[i], out var writer);
                writer.WriteUInt(number);
                m_Driver.EndSend(writer);
            }
            else if (cmd == NetworkEvent.Type.Disconnect) {
                Debug.Log("클라이언트 연결 종료");
                m_Connections[i] = default;
            }
        }
    }
}

• 데이터 수신: 클라이언트가 보낸 숫자를 읽어 +2 후 재전송.
• 연결 종료: Disconnect 이벤트 시 연결 리셋.

3⃣ 클라이언트 구현 (차이점 중심) – Client

ClientBehaviour.cs

public class ClientBehaviour : MonoBehaviour {
    NetworkDriver m_Driver;
    NetworkConnection m_Connection; // 단일 연결만 관리

    void Start() {
        m_Driver = NetworkDriver.Create();
        m_Connection = m_Driver.Connect(NetworkEndpoint.LoopbackIpv4.WithPort(7777));
    }

    void Update() {
        m_Driver.ScheduleUpdate().Complete();

        if (!m_Connection.IsCreated) return;

        DataStreamReader stream;
        NetworkEvent.Type cmd;
        while ((cmd = m_Connection.PopEvent(m_Driver, out stream)) 
               != NetworkEvent.Type.Empty) {
            
            if (cmd == NetworkEvent.Type.Connect) {
                Debug.Log("서버 연결 성공");
                uint value = 1;
                m_Driver.BeginSend(m_Connection, out var writer);
                writer.WriteUInt(value);
                m_Driver.EndSend(writer);
            }
            else if (cmd == NetworkEvent.Type.Data) {
                uint value = stream.ReadUInt();
                Debug.Log($"서버로부터 값 수신: {value}");
                m_Connection.Disconnect(m_Driver);
                m_Connection = default;
            }
            else if (cmd == NetworkEvent.Type.Disconnect) {
                Debug.Log("서버와 연결 종료");
                m_Connection = default;
            }
        }
    }
}

클라이언트 특이사항:

• 단일 연결: NetworkConnection 하나만 관리.
• Connect 이벤트: 연결 성공 시 서버로 숫자 1 전송.
• 데이터 처리: 서버 응답 후 즉시 연결 종료.

 중요:

모든 네트워크 작업은 비동기 Job 시스템 기반으로 동작하지만, 이 예제에서는 Complete()로 강제 동기화하여 간단히 구현했습니다.

실제 프로젝트에서는 Job 체인을 활용한 최적화가 필요합니다.

ServerBehaviour.cs

using Unity.Collections;
using Unity.Networking.Transport;
using UnityEngine;

namespace UnityNetworkingTransportSimpleTest
{
    public class ServerBehaviour : MonoBehaviour
    {

        NetworkDriver m_Driver;
        NativeList<NetworkConnection> m_Connections; // 연결된 클라이언트 목록

        private void Start()
        {
            m_Driver = NetworkDriver.Create(); // NetworkDriver 생성
            m_Connections = new NativeList<NetworkConnection>(16, Allocator.Persistent); // 최대 16개의 연결을 허용하는 NativeList 생성 (영구 할당)

            var endpoint = NetworkEndpoint.AnyIpv4.WithPort(7777); // 모든 IPv4 주소의 7777 포트에서 수신 대기
            if (m_Driver.Bind(endpoint) != 0)
            {
                Debug.LogError("포트 7777 바인딩 실패"); // 포트 바인딩 실패 시 에러 로그 출력
                return;
            }
            m_Driver.Listen(); // 들어오는 연결 요청 수신 시작
        }

        private void Update()
        {
            m_Driver.ScheduleUpdate().Complete(); // 네트워크 업데이트 스케줄링 및 완료

            // 1. 오래된 연결 정리
            for (int i = 0; i < m_Connections.Length; i++)
            {
                if (!m_Connections[i].IsCreated) { // 연결이 끊어진 클라이언트 정리
                    m_Connections.RemoveAtSwapBack(i); // 연결 리스트에서 제거
                    i--; // 인덱스 조정
                }
            }

            // 2. 새 연결 수락
            NetworkConnection newNetworkConnection;
            while ((newNetworkConnection = m_Driver.Accept()) != default)
            {
                m_Connections.Add(newNetworkConnection); // 새로운 연결을 연결 리스트에 추가
                Debug.Log("클라이언트 연결 수락"); // 클라이언트 연결 수락 시 로그 출력
            }

            // 3. 연결별 이벤트 처리
            for (int i = 0; i < m_Connections.Length; i++)
            {
                DataStreamReader stream;
                NetworkEvent.Type cmd;
                while ((cmd = m_Driver.PopEventForConnection(m_Connections[i], out stream)) != NetworkEvent.Type.Empty)
                {

                    if (cmd == NetworkEvent.Type.Data)
                    {
                        uint number = stream.ReadUInt(); // 수신된 데이터에서 unsigned integer 값 읽기
                        Debug.Log($"클라이언트로부터 {number} 수신, +2 처리"); // 클라이언트로부터 받은 값 로그 출력 및 처리 내용 설명

                        number += 2; // 받은 값에 2를 더함
                        m_Driver.BeginSend(NetworkPipeline.Null, m_Connections[i], out var writer); // 클라이언트에게 메시지 전송 시작 (신뢰성 없는 파이프라인 사용)
                        writer.WriteUInt(number); // 처리된 unsigned integer 값 쓰기
                        m_Driver.EndSend(writer); // 메시지 전송 완료
                    }
                    else if (cmd == NetworkEvent.Type.Disconnect)
                    {
                        Debug.Log("클라이언트 연결 종료"); // 클라이언트 연결이 종료되었을 때 로그 출력
                        m_Connections[i] = default; // 연결 상태 초기화
                    }
                }
            }
        }

        private void OnDestroy()
        {
            if (m_Driver.IsCreated)
            {
                m_Driver.Dispose(); // NetworkDriver 자원 해제
                m_Connections.Dispose(); // 연결 리스트 자원 해제
            }
        }
    }
}

ClientBehaviour.cs

using Unity.Collections;
using Unity.Networking.Transport;
using UnityEngine;

namespace UnityNetworkingTransportSimpleTest
{
    public class ClientBehaviour : MonoBehaviour
    {
        NetworkDriver m_Driver;
        NetworkConnection m_Connection; // 클라이언트는 단일 연결만 관리

        private void Start()
        {
            m_Driver = NetworkDriver.Create(); // NetworkDriver 생성
            m_Connection = m_Driver.Connect(NetworkEndpoint.LoopbackIpv4.WithPort(7777)); // 루프백 주소의 7777 포트로 서버에 연결 시도
        }

        private void Update()
        {
            m_Driver.ScheduleUpdate().Complete(); // 네트워크 업데이트 스케줄링 및 완료

            if (!m_Connection.IsCreated) return; // 연결이 생성되지 않았으면 더 이상 진행하지 않음

            DataStreamReader stream;
            NetworkEvent.Type cmd;
            while ((cmd = m_Connection.PopEvent(m_Driver, out stream)) != NetworkEvent.Type.Empty) { // 연결에서 발생한 네트워크 이벤트 처리

                if (cmd == NetworkEvent.Type.Connect)
                {
                    Debug.Log("서버 연결 성공"); // 서버 연결 성공 시 로그 출력
                    uint value = 1;
                    m_Driver.BeginSend(m_Connection, out var writer); // 메시지 전송 시작
                    writer.WriteUInt(value); // unsigned integer 값 쓰기
                    m_Driver.EndSend(writer); // 메시지 전송 완료
                }
                else if (cmd == NetworkEvent.Type.Data)
                {
                    uint value = stream.ReadUInt(); // 수신된 데이터에서 unsigned integer 값 읽기
                    Debug.Log($"서버로부터 값 수신: {value}"); // 서버로부터 받은 값 로그 출력
                    m_Connection.Disconnect(m_Driver); // 서버와 연결 종료
                    m_Connection = default; // 연결 상태 초기화
                }
                else if (cmd == NetworkEvent.Type.Disconnect)
                {
                    Debug.Log("서버와 연결 종료"); // 서버와 연결이 종료되었을 때 로그 출력
                    m_Connection = default; // 연결 상태 초기화
                }
            }
        }
    }
}

사용 모범 사례

1⃣ 파이프라인 사용 (Using pipelines)

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/pipelines-usage.html

파이프라인(Pipelines)은 Unity Transport의 핵심 기능으로, 기본 제공되는 비신뢰성 데이터그램(unreliable datagrams) 위에 선택적 기능 계층을 추가할 수 있게 해줍니다.

주요 적용 기능: 순서 보장(sequencing), 신뢰성(reliability), 패킷 분할(fragmentation) 등.

작동 원리 (How it Works)

파이프라인은 하나 이상의 스테이지로 구성된 순서로 정의됩니다.

메시지가 파이프라인을 통해 전송되면 스테이지를 순서대로 거치며, 첫 번째 스테이지의 출력이 두 번째 스테이지로 파이프됩니다.

따라서 첫 번째 스테이지에서 패킷에 헤더를 추가하면 두 번째 스테이지는 이 헤더를 포함한 전체 패킷을 처리합니다.

메시지가 수신되면 스테이지 체인을 역순으로 거칩니다.

예를 들어 FragmentationPipelineStage는 큰 메시지를 더 작은 조각으로 나누는 것을 가능하게 하고,

ReliableSequencedPipelineStage는 메시지를 순서와 전달을 보장하며 전송하는 것을 가능하게 합니다.

두 기능 모두를 제공하는 파이프라인을 만들고 싶다면 다음과 같이 만들 수 있습니다.

// In initialization code, before any connections are made.
var myPipeline = driver.CreatePipeline(typeof(FragmentationPipelineStage), typeof(ReliableSequencedPipelineStage));

이렇게 하면 메시지를 먼저 패킷에 맞게 더 작은 조각으로 분할한 다음, 각 조각이 신뢰성 있게 그리고 올바른 순서대로 전달되는 파이프라인이 생성됩니다.

이 과정은 아래 그림과 같이 설명됩니다. 조각에 있는 작은 주황색 부분은 순서 번호와 신뢰성 단계에서 추가된 기타 정보를 나타냅니다.

단계의 순서가 중요하다는 점에 유의하세요.

만약 단계를 거꾸로 구성했다면, 신뢰성 정보는 분할되지 않은 큰 메시지에만 추가되었을 것입니다.

이 경우, 조각 중 하나라도 손실되면 전체 메시지를 다시 전송해야 하므로 대역폭 효율이 떨어집니다.

하지만 신뢰성 단계(reliable stage)를 분할 단계(fragmentation) 이후에 배치하면, 조각 하나가 손실되더라도 그 조각만 다시 전송하면 되므로 더 효율적입니다.

새로운 파이프라인에서 메시지를 전송하려면

BeginSend를 사용할 수 있습니다:

driver.BeginSend(myPipeline, connection, out var writer);

메시지를 어느 파이프라인으로 받았는지 확인하려면

PopEvent 또는 PopEventForConnection의 마지막 인자를 사용하세요:

var eventType = driver.PopEvent(out _, out _, out var receivePipeline);
if (eventType == NetworkEvent.Type.Data)
{
    // 데이터 메시지는 receivePipeline 파이프라인에서 수신되었습니다.
}

주의

파이프라인은 서버와 클라이언트에서 항상 같은 방식으로 구성되어야 합니다.

즉, CreatePipeline 호출과 그 순서는 양쪽에서 동일해야 합니다.

Unity Transport는 이러한 불일치를 자동으로 막아주지 않으므로, 파이프라인 생성 코드는 서버와 클라이언트 간에 공유하는 것을 권장합니다.

Fragmentation 파이프라인 단계

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/pipelines-usage.html

기본적으로 Unity Transport는 MTU(약 1400바이트) 안에 들어가는 크기의 메시지만 전송할 수 있습니다.

더 큰 메시지를 보내기 위해서는 이를 더 작은 조각으로 분할해야 하며, 이를 메시지 분할(Fragmentation) 이라고 합니다.

FragmentationPipelineStage가 포함된 파이프라인을 구성하면, 메시지를 자동으로 분할해 줍니다.

분할 전 최대 페이로드 크기는 NetworkDriver를 생성할 때 설정할 수 있습니다:

var settings = new NetworkSettings();
settings.WithFragmentationStageParameters(payloadCapacity: 10000);

var driver = NetworkDriver.Create(settings);
var fragmentedPipeline = driver.CreatePipeline(typeof(FragmentationPipelineStage));

설정 가능한 최대 값은 약 20MB이지만, 이 파이프라인 단계는 수 킬로바이트 크기의 페이로드에 최적화되어 있습니다.

기본값은 4096바이트이며, 이보다 훨씬 큰 메시지는 초기화 시점에 한 번 보내는 정도로만 사용하는 것을 권장합니다.

참고:

여러 파이프라인 단계를 조합할 경우, FragmentationPipelineStage는 일반적으로 가장 먼저 배치되어야 합니다.

대부분의 파이프라인 단계는 MTU보다 큰 패킷을 지원하지 않기 때문입니다.

The reliable 파이프라인 단계

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/pipelines-usage.html

ReliableSequencedPipelineStage를 사용한 파이프라인은 TCP처럼 패킷의 순서 보장과 안정적인 전송을 보장합니다.

• 패킷은 시퀀스 번호로 태그되며, 상대는 이 번호의 수신을 확인합니다.
• 수신 확인이 되지 않으면 패킷은 재전송됩니다.
• 순서가 어긋난 패킷은 버퍼에 저장되고, 이전 패킷이 도착할 때까지 대기합니다.

이 기능은 유용하지만, 멀티플레이어 게임에서는 과도하게 사용하면 성능에 악영향을 줄 수 있습니다.

신뢰성 있는 데이터 스트림은 헤드 오브 라인 블로킹(Head-of-line blocking) 으로 인해 지연이 발생할 수 있습니다.

따라서 정말 중요한 데이터 (예: RPC 호출, 캐릭터 동작 등)에만 이 단계를 사용하는 것을 권장합니다.

동시 전송 가능한 패킷 수 제한

Reliable 단계는 동시에 전송 가능한 패킷 수가 제한됩니다.

기본값은 32개, 최대 64개까지 늘릴 수 있습니다.

이 제한은 연결별, 파이프라인별로 적용되며, 공유되지 않습니다.

팁: 가능한 한 신뢰성 있는 메시지를 배치(Batching) 하세요. 예: 20바이트짜리 메시지 2개를 따로 보내는 대신 40바이트로 묶어 한 번에 전송.

만약 이미 32개의 패킷이 전송 대기 중인 상황에서 또 보내려고 하면, EndSend는 NetworkSendQueueFull (값: -5)을 반환합니다.

이 경우 메시지를 큐에 저장하고 나중에 재전송하세요:

driver.BeginSend(myReliablePipeline, connection, out var writer);
// 메시지 작성
if (driver.EndSend(writer) == (int)Error.StatusCode.NetworkSendQueueFull)
{
    // 메시지를 큐에 저장 후 나중에 재전송
}

// 제한 늘리기

var settings = new NetworkSettings();
settings.WithReliableStageParameters(windowSize: 64);


var driver = NetworkDriver.Create(settings);
var reliablePipeline = driver.CreatePipeline(typeof(ReliableSequencedPipelineStage));

// 기본값은 32, 최대는 64입니다.
// 32보다 큰 값을 사용할 경우 헤더 크기가 약간 증가(4바이트) 하며, 실제 데이터 공간은 그만큼 줄어듭니다.

The reliable 파이프라인 단계

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/pipelines-usage.html

SimulatorPipelineStage는 앱 테스트용으로 사용되며, 패킷 손실, 지연, 지터 등의 다양한 네트워크 조건을 시뮬레이션할 수 있습니다.

var settings = new NetworkSettings();
settings.WithSimulatorStageParameters(
    maxPacketCount: 100,
    mode: ApplyMode.AllPackets,
    packetDelayMs: 50);

var driver = NetworkDriver.Create(settings);
var simulatorPipeline = driver.CreatePipeline(typeof(SimulatorPipelineStage));


// maxPacketCount: 지연 가능한 최대 패킷 수. 이 수를 초과하면 지연 없이 전달됩니다.
// mode: 어떤 방향에 시뮬레이션을 적용할지 설정 (보내기, 받기, 또는 모두).
// packetDelayMs: 적용할 지연 시간 (ms). 일반 브로드밴드는 20ms, 열악한 모바일은 최대 200ms.
// packetJitterMs: 지연의 편차. 일반적으로 지연의 절반 이하가 적당합니다.
// packetDropPercentage: 손실할 패킷의 비율 (%). 나쁜 모바일 환경에서도 보통 3%를 넘지 않습니다.

참고:

여러 단계로 구성된 파이프라인에서 SimulatorPipelineStage는 가장 마지막에 배치해야 합니다.

그렇지 않으면 다른 단계에서 처리되기 전에 패킷이 손실되어 의미가 없어질 수 있습니다 (예: Reliable 단계와 함께 사용할 경우).

2⃣ Jobified 클라이언트 및 서버

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/client-server-jobs.html

Client 코드 (JobifiedClientBehaviour.cs)

using UnityEngine;
using Unity.Jobs;
using Unity.Collections;
using Unity.Networking.Transport;

namespace Unity.Networking.Transport.Samples
{
    public class JobifiedClientBehaviour : MonoBehaviour
    {
        NetworkDriver m_Driver;
        NativeArray<NetworkConnection> m_Connection;

        JobHandle m_ClientJobHandle;

        void Start()
        {
            // 네트워크 드라이버 생성 및 초기화
            m_Driver = NetworkDriver.Create();
            m_Connection = new NativeArray<NetworkConnection>(1, Allocator.Persistent);

            // 로컬 호스트(127.0.0.1)의 포트 7777에 연결 시도
            var endpoint = NetworkEndpoint.LoopbackIpv4.WithPort(7777);
            m_Connection[0] = m_Driver.Connect(endpoint);
        }

        void OnDestroy()
        {
            // 이전 프레임의 잡이 모두 완료되도록 대기 후, 네이티브 리소스 해제
            m_ClientJobHandle.Complete();
            m_Driver.Dispose();
            m_Connection.Dispose();
        }

        void Update()
        {
            // 이전 프레임에서 스케줄된 작업 완료 대기
            m_ClientJobHandle.Complete();

            // 클라이언트 업데이트 작업 생성 및 설정
            var job = new ClientUpdateJob
            {
                Driver = m_Driver,
                Connection = m_Connection,
            };

            // 네트워크 드라이버 업데이트 스케줄링
            m_ClientJobHandle = m_Driver.ScheduleUpdate();

            // 클라이언트 작업 스케줄링 (드라이버 업데이트 이후 실행되도록 설정)
            m_ClientJobHandle = job.Schedule(m_ClientJobHandle);
        }

        // 클라이언트 상태를 업데이트하는 IJob 기반 작업
        struct ClientUpdateJob : IJob
        {
            public NetworkDriver Driver;
            public NativeArray<NetworkConnection> Connection;

            public void Execute()
            {
                // 연결이 유효하지 않으면 조기 종료
                if (!Connection[0].IsCreated)
                {
                    return;
                }

                DataStreamReader stream;
                NetworkEvent.Type cmd;

                // 이벤트 루프를 통해 네트워크 이벤트 처리
                while ((cmd = Connection[0].PopEvent(Driver, out stream)) != NetworkEvent.Type.Empty)
                {
                    if (cmd == NetworkEvent.Type.Connect)
                    {
                        Debug.Log("서버에 연결됨.");

                        // 서버에 uint 값 1을 전송
                        uint value = 1;
                        Driver.BeginSend(Connection[0], out var writer);
                        writer.WriteUInt(value);
                        Driver.EndSend(writer);
                    }
                    else if (cmd == NetworkEvent.Type.Data)
                    {
                        // 서버로부터 데이터를 수신하고 출력
                        uint value = stream.ReadUInt();
                        Debug.Log($"서버로부터 받은 값: {value}");

                        // 데이터 수신 후 연결 종료
                        Driver.Disconnect(Connection[0]);
                        Connection[0] = default;
                    }
                    else if (cmd == NetworkEvent.Type.Disconnect)
                    {
                        // 서버에서 연결이 종료되었음을 로그에 기록하고 상태 초기화
                        Debug.Log("서버와의 연결이 종료됨.");
                        Connection[0] = default;
                    }
                }
            }
        }
    }
}

Server 코드 (JobifiedServerBehaviour.cs)

using UnityEngine;
using Unity.Jobs;
using Unity.Collections;
using Unity.Networking.Transport;

namespace Unity.Networking.Transport.Samples
{
    public class JobifiedServerBehaviour : MonoBehaviour
    {
        NetworkDriver m_Driver;
        NativeList<NetworkConnection> m_Connections;

        JobHandle m_ServerJobHandle;

        void Start()
        {
            // 네트워크 드라이버 생성 및 초기화
            m_Driver = NetworkDriver.Create();
            m_Connections = new NativeList<NetworkConnection>(16, Allocator.Persistent);

            // 포트 7777에 바인딩 시도
            var endpoint = NetworkEndpoint.AnyIpv4.WithPort(7777);
            if (m_Driver.Bind(endpoint) != 0)
            {
                Debug.LogError("포트 7777 바인딩 실패.");
                return;
            }

            // 클라이언트 연결 대기 시작
            m_Driver.Listen();
        }

        void OnDestroy()
        {
            if (m_Driver.IsCreated)
            {
                // 모든 잡 완료 후 리소스 해제
                m_ServerJobHandle.Complete();
                m_Driver.Dispose();
                m_Connections.Dispose();
            }
        }

        void Update()
        {
            // 이전 프레임의 잡 완료 대기
            m_ServerJobHandle.Complete();

            // 끊긴 연결 제거 및 새 연결 수락을 처리하는 잡 생성
            var connectionJob = new ServerUpdateConnectionsJob
            {
                Driver = m_Driver,
                Connections = m_Connections
            };

            // 클라이언트별로 데이터 수신 및 응답을 처리하는 병렬 잡 생성
            var serverUpdateJob = new ServerUpdateJob
            {
                Driver = m_Driver.ToConcurrent(),
                Connections = m_Connections.AsDeferredJobArray()
            };

            // 드라이버 업데이트 → 연결 처리 → 데이터 처리 순으로 잡 체인 스케줄링
            m_ServerJobHandle = m_Driver.ScheduleUpdate();
            m_ServerJobHandle = connectionJob.Schedule(m_ServerJobHandle);
            m_ServerJobHandle = serverUpdateJob.Schedule(m_Connections, 1, m_ServerJobHandle);
        }

        // 끊긴 연결을 정리하고 새 연결을 수락하는 작업
        struct ServerUpdateConnectionsJob : IJob
        {
            public NetworkDriver Driver;
            public NativeList<NetworkConnection> Connections;

            public void Execute()
            {
                // 유효하지 않은 연결 제거
                for (int i = 0; i < Connections.Length; i++)
                {
                    if (!Connections[i].IsCreated)
                    {
                        Connections.RemoveAtSwapBack(i);
                        i--;
                    }
                }

                // 새 클라이언트 연결 수락
                NetworkConnection c;
                while ((c = Driver.Accept()) != default)
                {
                    Connections.Add(c);
                    Debug.Log("클라이언트 연결 수락됨.");
                }
            }
        }

        // 각 연결로부터 데이터를 수신하고 처리하는 병렬 작업
        struct ServerUpdateJob : IJobParallelForDefer
        {
            public NetworkDriver.Concurrent Driver;
            public NativeArray<NetworkConnection> Connections;

            public void Execute(int i)
            {
                DataStreamReader stream;
                NetworkEvent.Type cmd;

                // 클라이언트 이벤트 루프
                while ((cmd = Driver.PopEventForConnection(Connections[i], out stream)) != NetworkEvent.Type.Empty)
                {
                    if (cmd == NetworkEvent.Type.Data)
                    {
                        // 숫자 수신 후 2를 더해 응답
                        uint number = stream.ReadUInt();
                        Debug.Log($"클라이언트로부터 {number} 수신. 2를 더해 전송.");

                        number += 2;

                        Driver.BeginSend(Connections[i], out var writer);
                        writer.WriteUInt(number);
                        Driver.EndSend(writer);
                    }
                    else if (cmd == NetworkEvent.Type.Disconnect)
                    {
                        // 연결 해제 처리
                        Debug.Log("클라이언트 연결 해제됨.");
                        Connections[i] = default;
                    }
                }
            }
        }
    }
}

3⃣ 암호화된 통신 Encrypted communications

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/client-server-secure.html

Unity Transport 패키지는 서버/클라이언트의 신뢰성을 보장하는 동시에 서버와 클라이언트 간의 연결을 암호화하도록 구성할 수 있습니다.

4⃣ Unity.Logging와 통합

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/logging.html

Unity Transport는 Unity Logging 패키지( )와의 선택적 통합을 제공합니다.

com.unity.logging package. 이 패키지는 기존 Unity 로깅 메커니즘에 대한 유연한 대안으로, 특히 프로덕션 서버에 유용합니다.

일반적으로 로그 메시지는 모두 를 거쳐 전송되지만 UnityEngine.Debug.Log, 로깅 패키지가 프로젝트에 포함되면 Unity Transport는 자동으로 Unity.Logging기본 로거 설정을 사용합니다.

특정 로그 설정을 조정하는 방법에 대한 자세한 내용은 로깅 패키지 설명서 사이트를 확인하세요.

Cross-play support

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/cross-play.html

WebGL support

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/websockets.html

FAQ

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/faq.html

Cross-play support

https://docs.unity3d.com/Packages/com.unity.transport@2.5/manual/migration.html

The post Unity Transport 2.5.1 Docs appeared first on 어제와 내일의 나 그 사이의 이야기.