일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- httpasswd
- 에이전트 유형
- kubernetes
- assumerole
- docker
- 추가 보안 그룹
- 클러스터 보안 그룹
- helm_release
- aws-loadbalacner-controller
- Pipeline
- NAT
- fruition
- 코드커버리지
- Amazon CloudWatch
- ingestion
- s3
- aws ses #aws lambda
- Service Account
- jenkins
- instances failed to join cluster
- Gateway
- saa-c03 #saa #aws certified solutions architect - associate
- 에이전트 구성
- 테라폼
- route53
- IRSA
- node group
- clusterrolebinding
- Docker0
- Terraform
- Today
- Total
cloudwithbass
[Network] TCP/IP 소켓 통신과 Docker Socket 본문
네트워크를 공부한지 오래되었고, 명확하지 않은 느낌이 자주 들어서 더욱 자세하게 공부하려고 합니다.
가장 먼저 공부할 개념은 어디선가 많이 들어본 소켓입니다.
목차
소켓이란?
소켓은 네트워크에서 실행되는 두 프로그램의 양방향 통신에 사용되는 하나의 엔드포인트입니다.
소켓에는 포트 번호가 바운드되어 있으므로 데이터를 전달할 목적지를 식별할 수 있습니다.
TCP/UDP 프로토콜을 사용하므로 소켓은 OSI 7 Layers의 4계층(Transfer Layer)에서 사용됩니다.
일반적으로 서버는 특정 포트 번호가 바운드된 소켓을 갖고 실행됩니다.
서버는 연결 요청을 보내는 클라이언트의 소켓을 리스닝하며 기다릴 뿐이죠.
클라이언트는 호스트 이름(IP address)과 포트 번호를 알고 있습니다. 이 두가지 정보를 이용해 클라이언트는 서버에 연결을 시도합니다.
연결이 이루어지면
서버 측:
소켓 소개에서 서버는 소켓을 갖고 실행된다고 했습니다.
클라이언트와 연결되면 서버는 동일한 로컬 포트에 새로운 소켓을 바인딩하고, 그 소켓의 원격 엔드포인트를 클라이언트의 ip와 port로 설정합니다.
여기서 '새로운' 소켓을 바인딩한다는 게 중요한데, 이것은 클라이언트와의 요청을 지속하면서 동시에 기존 소켓에선 다른 요청들도 처리해야 하기 때문입니다.
클라이언트 측:
소켓이 성공적으로 생성되며, 이제 소켓을 이용해 서버와 통신할 수 있습니다.
소켓은 서버와 클라이언트의 양방향 통신을 가능하게 해주는 엔드포인트입니다.
따라서 서버와 클라이언트는 소켓을 읽고, 소켓에 쓰며 서로 통신합니다.
Docker의 소켓도 같은 의미일까?
이전에 젠킨스가 도커 명령을 정상적으로 수행하지 못하는 문제가 있었습니다.
이 문제는 젠킨스 에이전트에게 도커 소켓에 대한 권한을 부여함으로써 해결했습니다.
(여기서 도커 소켓이란 /var/run/docker.sock에 위치한 파일을 의미합니다.)
위 도커 아키텍처에서 보이듯 도커 명령은 Client와 Docker daemon의 통신에 의해 이루어집니다.
이때 Client가 Dokcker daemon에게 명령을 보낼 때 사용하는 것이 도커 API와 도커 소켓입니다.
TCP/IP 소켓의 소개에서 서버는 소켓을 리스닝하며 실행된다고 했는데요, 도커 데몬은 기본적으로 /var/run/docker.sock을 리스닝합니다.
/var/run/docker.sock은 Unix 도메인 소켓입니다. 이는 로컬 시스템 내에서 프로세스 간 통신(IPC, Inter-Process Communication)에 사용되는 소켓 중 하나입니다.
도커 API란 REST API 기반의 인터페이스입니다.
예를 들어 클라이언트가 docker ps 명령을 실행하면 이 명령은 GET /containers/json이라는 API 호출로 변환되어, /var/run/docker.sock을 통해 도커 데몬에 전달됩니다.
따라서 도커 API는 클라이언트와 서버 간 통신에 사용된다는 점에선 같지만, HTTP 기반의 Restful API를 사용하고 프로세스 간 통신에 사용되므로 TCP/IP 소켓과 차이점이 있습니다.
소켓 통신의 장단점
장점
클라이언트와 서버가 양방향으로 통신할 수 있다.
연결을 유지하므로 연결을 등록하고 해제하는 오버헤드가 적다.
단점
연결을 유지하는 비용을 사용해야 한다.
따라서 양방향 통신할 일이 적은 경우엔 TCP/IP 소켓 통신 보단 HTTP 통신이 유리합니다.
다음 포스팅에선 HTTP 통신에 대해 알아보겠습니다.
참고 문서
Docker Tips: /var/run/dockker.sock에 대하여
'Network' 카테고리의 다른 글
[Network] 스위치와 라우터 (5) | 2024.10.20 |
---|---|
[Network] HTTP 통신 (5) | 2024.10.19 |