풀소유

[Linux] 네트워크 인터페이스와 Docker 네트워크 트래픽 구조 분석

Docker에서 발생하는 트래픽 흐름을 분석하려면 리눅스의 네트워크 인터페이스(NIC) 구조를 먼저 이해해야 합니다. 이 글은 리눅스 NIC 종류 설명, Docker 네트워크 구성, 그리고 컨테이너 간 트래픽 경로 분석까지 모두 담은 실무 중심 가이드입니다.리눅스 네트워크 인터페이스 종류 정리 (NIC 종류)인터페이스설명활용ens3, eth0, enp0s3시스템이 부팅될 때 자동으로 할당되는 물리 네트워크 카드 또는 클라우드 환경의 가상 NIC. ens3처럼 Predictable Naming 방식이 주로 사용됨.외부 통신의 입구이자 출구. 실제 인터넷, 사내망, VPN 연결. 보안 설정, 방화벽, 라우팅 테이블의 핵심 대상.lo (Loopback)자기 자신과 통신하는 전용 가상 인터페이스. 항상 127...

X 윈도우는 왜 "서버-클라이언트" 구조일까?X 윈도우에서 서버는 내 컴퓨터입니다. 반대로, 내가 실행한 GUI 앱(firefox, gedit 등)은 클라이언트입니다.X 서버: 화면, 마우스, 키보드 등 입력·출력 장치를 가진 쪽. 즉, 내 컴퓨터가 X 서버입니다.X 클라이언트: 창을 띄우고 싶어하는 프로그램. X 서버에게 그려달라고 요청함즉, 프로그램은 직접 화면에 그림을 그리는 것이 아니라, X 서버에게 요청합니다. 이 구조 덕분에 GUI 프로그램은 로컬에서도, 네트워크를 통해서도 화면을 띄울 수 있습니다.X 윈도우의 구성 요소구성 요소역할 설명X Server화면에 실제로 그리는 주체. 마우스, 키보드 이벤트도 여기서 처리X Client창을 띄우고 싶어하는 프로그램. X 서버에게 그려달라고 요청함X ..

운영자는 장애 상황에서 즉시 근본 원인(root cause)을 찾을 수 있어야 한다.전통적으로 top, ps, journalctl 등을 사용해 프로세스의 상태를 점검했지만, systemd 기반 시스템에서는 이런 접근법으로는 명확한 원인을 찾기 어렵다.systemd는 모든 서비스를 유닛으로 추상화하여 관리하며, 프로세스와 자원을 CGroup(Control Group)이라는 커널 메커니즘을 통해 관리한다. 따라서 systemd 시스템을 다룰 때는 이 구조를 이해하고 활용해야 한다.systemctl서비스의 상태를 확인할 수 있는 도구다.실패한 서비스 전체 조회$ systemctl --failedUNIT LOAD ACTIVE SUB DESCRIPTIONdocker.service..

1. Standalone 방식Standalone 방식은 가장 보편적이며, 데몬 자체가 독립적으로 시스템 부팅 시부터 항상 실행 상태를 유지하는 방식이다.특징시스템 부팅 시 자동으로 실행 (systemd service)지속적으로 포트를 점유하고 클라이언트의 요청을 직접 처리예시: docker.service# docker.service 예시[Unit]Description=Docker Application Container EngineAfter=network-online.target firewalld.serviceWants=network-online.target[Service]ExecStart=/usr/bin/dockerdExecReload=/bin/kill -s HUP $MAINPIDTimeoutSec=0R..

셸에서 사용하는 파이프(|)와 리다이렉션(>, ) 은 일반적인 시스템 콜이나 바이너리 실행의 일부가 아니라, 셸이 제공하는 특별한 문법(syntax)이다. 운영체제 커널은 이런 문법을 직접적으로 이해하지 못하며, 오직 셸만이 이를 처리할 수 있다.때문에 파이프와 리다이렉션을 포함한 명령어는 반드시 셸 프로세스를 거쳐 실행된다.파이프(Pipe) 동작의 원리예를 들어 다음 명령을 보자. 셸은 이를 다음 단계로 처리한다.ls -al | grep ".txt" 1. 자식 프로세스 생성 (fork)부모 셸은 우선 하나의 자식 프로세스를 생성한다. 이 자식 프로세스는 exec를 통해 셸 프로세스(/bin/sh)로 변경된다.2. 자식 셸 프로세스에서 다시 두 개의 프로세스 생성 (fork)자식 셸이 다시 두 개의 프로..

Java에서는 클래스에서 정의한 필드(변수)와 메서드(함수)에 접근할 때 서로 다른 원칙을 따릅니다. 메서드는 객체의 실제 타입(런타임 타입)을 따르고, 필드는 선언된 타입(컴파일 시점)을 따라갑니다. 🔍 예제 코드 분석class Parent { String str = "Parent"; String getStr() { return str; }}class Child extends Parent { String str = "Child"; String getStr() { return str; }}public class Main { public static void main(String[] args) { Parent parent = ne..

Java에서 흔히 사용하는 제네릭과 오버로딩은 각각 명확한 규칙을 가지고 있지만, 함께 사용할 때는 가끔 예상과 다른 결과가 발생합니다. 이번 글에서는 왜 이런 일이 발생하는지, Java 컴파일러의 동작 원리까지 함께 살펴보겠습니다.예제 코드 분석class Display { void show(String s) { System.out.println("String: " + s); } void show(Object o) { System.out.println("Object: " + o); }}public class GenericExample { public static void main(String[] args) { Holder holder = n..

✅ 문제 배경Spring 서버가 자체 서명된(Self-signed) SSL 인증서를 사용하는 서버와 HTTPS 통신을 시도할 때 다음과 같은 SSL 오류가 발생합니다.javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: unable to find valid certification path to requested target ✅ 직접 생성한 인증서라면🚩 1단계: OpenSSL과 CNF 파일로 인증서 생성CNF 파일이란?OpenSSL 인증서 생성 시 사용하는 설정파일로, 인증서에 포함될 정보를 정의합니다. 특히 subjectAlt..

✅ 문제 배경회사 내부 시스템이나 개발 환경에서는 종종 Let's Encrypt 같은 인증기관(CA)을 거치지 않고, OpenSSL 등으로 만든 자체 서명된 인증서(Self-signed certificate) 를 사용하는 경우가 많습니다. 예를 들면, 다음과 같은 시스템에 자체 인증서가 사용될 수 있습니다:내부 로그인 서버 (예: Keycloak)내부 파일 저장 서버 (예: MinIO)API 서버 (직접 만든 HTTPS 서버)이때 이들 서버와 Node.js 기반 서버(Next.js, NestJS 등) 가 통신하려고 하면, 아래와 같은 에러가 발생할 수 있습니다:Error: self signed certificateUNABLE_TO_VERIFY_LEAF_SIGNATURE🧨 왜 이런 문제가 생기나요?📌 ..

문제 상황Nuxt3와 Next-Auth를 함께 사용할 때, 서버 사이드 렌더링(SSR) 과정에서 useAuth().getSession()을 호출하면 매번 새로운 set-cookie 헤더가 응답에 추가됩니다. 특히 아래와 같은 상황에서 문제가 심각해집니다:다수의 API 호출: SSR 중 여러 컴포넌트가 각각 getSession()을 호출하는 경우헤더 크기 제한 초과: HTTP 쿠키 헤더 전체 크기가 일반적으로 4KB를 넘으면 브라우저가 쿠키를 거부하거나 잘라냅니다.중복 세션 쿠키: 동일한 세션 쿠키가 반복 삽입되어, 실제 필요한 쿠키 외에 불필요한 메타 정보가 헤더에 포함됩니다.결과적으로 SSR 중 렌더링이 실패하거나, 클라이언트에 쿠키가 제대로 전달되지 않는 현상이 발생할 수 있습니다.원인 분석클라이언트..