Socket

TL;DR

• 소켓은 프로세스 간 통신을 위한 통로이자 커널 자원을 추상화한 파일
• 유닉스 도메인 소켓(UDS)은 로컬에서 빠르게, 네트워크 소켓(TCP/UDP)은 원격까지 연결
• 상황별 소켓 선택 기준과 UDS/TCP 노출 보안 주의사항 정리

소켓 (Socket)이란?

“소켓”은 프로세스 A와 프로세스 B가 데이터를 주고받기 위해 여는 문(통로)
그 문이 파일 시스템 안에 있느냐, IP·포트 주소로 노출되느냐에 따라 두 가지로 나뉨

---

소켓의 본질 — 파일이다

종류를 외우기 전에 본질을 먼저 잡아야 한다. 소켓은 파일이다.

리눅스에서 파일은 디스크에 저장된 데이터 덩어리만 가리키지 않는다. 커널 안의 어떤 자원을 추상화한 인터페이스도 전부 “파일”로 다룬다.
그 자원이 프로토콜 스택(TCP/UDP 등) 중 하나라면, 그 파일을 특별히 소켓이라 부를 뿐이다.
같은 원리로 블루투스 장치를 추상화하면 블루투스 소켓, 적외선 통신(IrDA)을 추상화하면 IrDA 소켓이 된다.

즉 “소켓”은 커널 자원을 파일처럼 다루기 위한 이름표에 가깝다.

이 관점이 중요한 이유는 파일을 다루는 방식을 그대로 소켓에 적용할 수 있기 때문이다.
C에서 콘솔이나 디바이스 파일을 열어 write하면 그 데이터가 화면으로 나가듯, 가리키는 대상이 TCP라면 똑같은 쓰기가 네트워크로 나간다. 대상만 바뀔 뿐 “열고 → 읽고/쓰고 → 닫는” 흐름은 동일하다.

파일 I/O와 소켓의 대응

입출력의 행위 주체는 프로세스다. 프로세스가 파일을 열고 닫으며 읽고 쓰듯, 소켓도 프로세스가 똑같이 다룬다. 대상이 네트워크라 이름만 바뀐다.

동작	일반 파일	소켓
열기	open	socket
쓰기	write	send
읽기	read	recv
닫기	close	close

그래서 소켓 프로그래밍은 결국 “TCP라는 대상을 추상화한 파일에 대한 입출력 방법”을 배우는 것이다. 파일을 fopen → read/write → fclose로 다루듯, 소켓도 socket으로 열고 중간에 프로토콜 특성에 맞는 처리를 끼운 뒤 닫는다.

fd의 정체 — 정수 handle과 그 아래 세 층

open이나 socket이 돌려주는 fd는 파일이나 소켓 그 자체가 아니다. 프로세스가 그 자원을 가리키려고 받는 작은 정수 handle일 뿐이다. 실제로는 세 층으로 나뉜다.

층	정체	무엇을 담나
fd	프로세스별 fd 테이블의 인덱스인 정수	”3번 핸들” 같은 참조
open file description	fd가 가리키는 커널 객체(open마다 하나)	현재 offset, 상태 플래그(O_NONBLOCK 등)
실제 객체	진짜 대상	파일이면 inode, 소켓이면 소켓 구조체, 파이프면 파이프 버퍼

그래서 “소켓은 파일이다”의 정확한 뜻은 소켓·파일·파이프가 전부 같은 fd 인터페이스로 노출돼 같은 syscall로 다뤄진다는 것이다. 아래 실제 객체는 저마다 다르지만, 프로세스가 만지는 창구(fd)가 균일해 read·write·close가 똑같이 통한다. 이 균일한 창구가 곧 유닉스의 “everything is a file”의 실체다.

세 층이 별개라는 건 이런 데서 드러난다. dup(fd)는 fd 두 개가 같은 open file description을 가리키게 하고(offset 공유), 같은 파일을 open으로 두 번 열면 open file description 두 개가 같은 inode를 가리킨다(offset 따로). fd, open file description, 실제 객체가 서로 다른 층이라 “fd = 파일”로 뭉뚱그리면 이 구분이 안 보인다.

스트림, 세그먼트, 패킷

파일 개념에는 스트림이라는 단위가 따라온다. 파일에 데이터를 append하면 뒤로 계속 이어 붙듯, 소켓도 데이터를 네트워크로 연속해서 흘려보낸다. 유저 영역 애플리케이션이 보는 소켓 데이터는 이렇게 끊김 없이 이어진 바이트 흐름, 즉 스트림이다.

이 스트림이 커널로 내려가면 단위가 바뀐다. 전송을 위해 일정 크기로 잘리는데(segmentation), L4(전송 계층)에서 잘린 조각이 세그먼트, L3(네트워크 계층)에서 IP 헤더 등으로 포장된 조각이 패킷이다.

직소 퍼즐 비유

조각 하나가 패킷(또는 세그먼트)이라면, 그 조각들이 빈틈없이 이어 붙어 완성된 그림이 스트림이다. 긴 데이터를 일정 단위로 자르는 것이 세그먼테이션이고, 잘린 조각을 인터넷에서 유통 가능한 형태로 포장한 것이 패킷이다.

---

왜 소켓을 써야 할까?

표준 IPC API

• socket() → bind() → listen() → accept() 호출만 알면 내부·외부 통신을 모두 처리할 수 있음

양방향 스트림

• 한쪽이 send() 하면 상대가 recv()로 바로 읽음. 파이프·메시지 큐보다 유연

언어·플랫폼 독립

• C, Python, Go, Java 등 뭐로 만들어도 서로 붙일 수 있음

---

소켓의 종류

유닉스 도메인 소켓 (UDS, .sock)

특징	설명
주소	파일 경로(AF_UNIX), 예: /var/run/docker.sock
범위	같은 머신
속도	TCP보다 빠름 (커널 내부 복사 한 번)
관리	파일 권한으로 접근 제어
사용처	Docker CLI ↔ dockerd, Nginx ↔ PHP-FPM, MySQL 로컬 접속 등

# Docker 데몬에 직접 REST 요청
curl --unix-socket /var/run/docker.sock http://localhost/containers/json

네트워크 소켓 (TCP/UDP)

특징	설명
주소	IP:포트(AF_INET), 예: 127.0.0.1:8080, 0.0.0.0:443
범위	로컬 ↔ LAN ↔ 인터넷 어디든
프로토콜	TCP(연결 지향), UDP(메시지 지향)
보안	방화벽·TLS·mTLS 필요
사용처	웹 서버, REST API, 게임 서버, IoT

# 파이썬 미니 TCP 서버
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(("0.0.0.0", 8888))
s.listen()
conn, _ = s.accept()
conn.sendall(b"Hello over TCP!\n")

비교

항목	유닉스 도메인 소켓	네트워크 소켓
주소 형태	파일 경로	IP:Port
통신 범위	로컬 머신	로컬 ↔ 원격
오버헤드	낮음	높음
접근 제어	파일 퍼미션	방화벽·TLS
주요 사용처	데몬 ↔ CLI, IPC	HTTP, gRPC, 게임

---

언제 무엇을 쓰면 좋을까?

상황	추천 소켓
같은 서버 안 두 프로세스	UDS
컨테이너 ↔ 호스트 데몬	UDS
다른 머신과 통신	TCP/UDP
모바일·브라우저 접근	TCP/UDP

처음엔 UDS로 개발하고, 배포 단계에서 네트워크 소켓으로 전환하는 패턴도 자주 사용

---

보안 문제

UDS도 “루트 열쇠”가 될 수 있음

• /var/run/docker.sock 쓰기 권한은 도커 데몬 전권을 의미

TCP 2375(무TLS) 노출 금지

• dockerd -H tcp://0.0.0.0:2375 그대로 띄우면 누구나 컨테이너 실행 가능

TLS/mTLS, SSH 터널 필수

• 원격 소켓은 반드시 암호화 + 인증 계층을 얹어야 함

---

마무리

소켓은 “프로세스 간 대화 창구”

• UDS는 같은 서버 에서 빠르고 간단하게,
• TCP/UDP는 세상 어디서나 연결할 수 있음

프로젝트 요구 사항(범위, 성능, 보안)에 맞춰 두 종류를 적절히 선택해야 함

---

관련 노트

• WebSocket 프로토콜 설계의 비밀 - TCP 소켓 위에서 동작하는 WebSocket 프로토콜의 설계 결정