Linux Networking Basics
Q&A: TCP/IP는 정확히 무엇인가?
질문
TCP/IP는 프로토콜이라고 알고 있는데, 매번 정확히 무엇인지 까먹는다.
답변
TCP/IP는 보통 인터넷 통신에 쓰이는 프로토콜 묶음을 가리킨다. 이름에 TCP와 IP가 같이 들어가서 하나의 프로토콜처럼 들리지만, 엄밀히는 여러 프로토콜과 계층을 포함하는 통신 체계다.
핵심 둘은 다음과 같다.
1
2
IP 데이터를 목적지 컴퓨터까지 전달하기 위한 주소 지정과 라우팅
TCP 두 프로그램 사이에서 데이터를 신뢰성 있게 주고받기 위한 전송 방식
예를 들어 웹 요청은 대략 이런 흐름 위에서 움직인다.
1
2
3
4
HTTP 데이터
-> TCP 세그먼트
-> IP 패킷
-> 네트워크
IP는 “어느 호스트로 보낼지”를 다루고, TCP는 “중간에 빠지거나 순서가 바뀐 데이터를 어떻게 신뢰성 있게 전달할지”를 다룬다.
TCP/IP 계열에는 TCP와 IP만 있는 것이 아니다.
1
2
3
HTTP, DNS, SSH 응용 계층에서 자주 만나는 프로토콜
TCP, UDP 전송 계층 프로토콜
IP, ICMP 인터넷 계층 프로토콜
따라서 다음처럼 구분하면 좋다.
1
2
3
TCP/IP = 인터넷 통신 프로토콜 묶음 또는 계층적 통신 모델
TCP = 연결 지향, 신뢰성 있는 전송 프로토콜
IP = 호스트 주소 지정과 패킷 전달을 맡는 프로토콜
한 줄로 말하면, TCP/IP는 “인터넷에서 데이터를 보내기 위해 각 계층이 역할을 나눠 가진 통신 규칙들의 집합”이다.
Q&A: socket은 무엇인가?
질문
socket은 무엇인가? 양방향 전송 기능이고, 채팅 기능에 많이 쓰이는 것으로 알고 있다.
답변
소켓(socket)은 프로그램이 네트워크 통신을 하기 위해 사용하는 통신 끝점(endpoint) 이다. 리눅스에서는 커널이 소켓을 제공하고, 프로그램은 소켓을 통해 데이터를 읽고 쓴다.
TCP 연결에서는 보통 다음 정보가 통신을 구분하는 데 쓰인다.
1
2
3
IP 주소
포트 번호
전송 프로토콜
서버는 특정 포트에서 연결을 기다리고, 클라이언트는 그 주소와 포트로 연결한다.
1
2
서버 소켓 연결 요청을 기다림
연결된 소켓 특정 클라이언트와 데이터 송수신
TCP 소켓 연결은 연결이 맺어진 뒤 양방향으로 데이터를 보낼 수 있다. 그래서 채팅 같은 기능을 만들 때 소켓이 자주 등장한다.
하지만 다음을 구분해야 한다.
1
2
3
socket OS가 제공하는 통신 인터페이스
TCP socket TCP 위에서 통신하는 소켓 사용 방식
WebSocket HTTP로 시작해 양방향 메시지 통신을 유지하는 응용 계층 프로토콜
웹 채팅에서 “소켓을 쓴다”고 말할 때는 실제 TCP 소켓을 직접 다루는 경우도 있고, 브라우저에서는 보통 WebSocket 같은 상위 프로토콜을 말하는 경우도 있다.
정리하면 다음과 같다.
1
2
소켓은 양방향 전송 기능 그 자체라기보다,
프로그램이 네트워크 연결을 통해 데이터를 주고받는 입구다.
Q&A: IP, port, SSH, DNS, 웹서버, 리버스 프록시의 연결
질문
IP와 port에 대해서 알고 싶다. SSH, DNS에서 웹서버까지의 흐름, 리버스 프록시, 포트 관리 주체, socket과의 관련성, localhost와의 연결, 브라우저 접속 흐름까지 함께 알고 싶다.
답변
네트워크에서 먼저 잡아야 할 핵심은 다음 둘이다.
1
2
IP 주소 어느 컴퓨터로 갈 것인가
port 그 컴퓨터 안의 어느 프로그램으로 갈 것인가
예를 들어 다음 주소를 보자.
1
192.168.0.10:22
이것은 대략 다음 뜻이다.
1
2
192.168.0.10 목적지 컴퓨터의 IP 주소
22 그 컴퓨터에서 SSH 서버가 기다리는 포트
즉 IP만으로는 “어느 호스트”인지는 찾을 수 있지만, 그 호스트 안에서 SSH 서버로 갈지 웹 서버로 갈지 DB 서버로 갈지는 port가 구분한다.
1. port는 무엇인가?
port는 네트워크 연결을 특정 프로세스의 통신 입구로 연결하기 위한 번호다.
자주 보는 예시는 다음과 같다.
1
2
3
4
5
22 SSH
80 HTTP
443 HTTPS
5432 PostgreSQL
6379 Redis
포트 번호는 서비스 관례가 있지만, 실제로는 프로그램 설정에 따라 다른 포트를 쓸 수 있다.
1
ssh -p 2222 shin@server.example.com
위 명령은 기본 SSH 포트 22가 아니라 2222 포트로 접속한다.
2. 포트는 누가 관리하는가?
포트 번호 자체는 운영체제 커널이 네트워크 자원으로 관리한다. 프로그램은 커널에게 특정 포트를 쓰고 싶다고 요청한다.
예를 들어 웹 서버가 다음 포트에서 요청을 기다린다고 하자.
1
nginx -> 0.0.0.0:80 에서 listen
이 말은 nginx 프로세스가 커널에게 80번 포트에 바인드(bind)해서 연결 요청을 받겠다고 요청한 것이다.
보통 같은 IP 주소와 같은 전송 프로토콜 조합에서 같은 포트를 두 서버 프로세스가 동시에 listen할 수는 없다.
1
2
3
nginx가 TCP 80 listen 중
다른 웹서버가 같은 TCP 80 listen 시도
-> 충돌 가능
또 외부에서 들어오는 포트는 방화벽, 클라우드 보안 그룹, 리버스 프록시 설정 등의 영향을 함께 받는다.
1
2
3
프로그램 설정 어떤 포트에서 listen할지 결정
커널 포트 바인딩과 연결 분배 관리
방화벽/보안 그룹 외부 접근 허용 여부 결정
3. socket과 IP/port의 관계
socket은 프로그램이 네트워크 통신을 하는 끝점이다. TCP 서버 프로그램은 보통 IP와 port에 바인드된 소켓을 열고 연결을 기다린다.
1
2
3
4
서버 socket
-> 특정 IP:port에 bind
-> listen
-> 클라이언트 연결 accept
예를 들어 SSH 서버는 보통 TCP 22 포트에서 연결을 기다린다.
1
sshd -> TCP socket -> server IP:22
브라우저가 웹 서버에 접속할 때도 결국 클라이언트 측 소켓과 서버 측 소켓 사이의 통신이 일어난다.
1
브라우저 socket -> 서버 IP:443의 socket
정리하면 다음과 같다.
1
2
IP:port 네트워크상 목적지와 프로그램 입구를 지정
socket 그 통신을 실제로 읽고 쓰는 프로그램의 통신 끝점
4. localhost는 무엇인가?
localhost는 보통 자기 자신 컴퓨터를 가리키는 이름이다.
1
localhost -> 127.0.0.1
IPv6 환경에서는 다음 주소도 자주 함께 쓰인다.
1
::1
예를 들어 개발 서버를 8080 포트로 띄웠다면 다음 둘은 같은 컴퓨터 안에서 자기 자신에게 접속하는 흐름이다.
1
2
http://localhost:8080
http://127.0.0.1:8080
이때 서버가 127.0.0.1:8080에만 listen하면 자기 컴퓨터에서는 접속되지만 다른 컴퓨터에서는 접속되지 않는다.
반면 0.0.0.0:8080에 listen하면 여러 네트워크 인터페이스로 들어오는 연결을 받을 수 있다.
1
2
127.0.0.1:8080 로컬 접속만
0.0.0.0:8080 사용 가능한 IPv4 인터페이스들에서 수신
5. SSH 접속 흐름
다음 명령을 보자.
1
ssh shin@server.example.com
흐름은 대략 다음과 같다.
1
2
3
4
5
1. server.example.com을 IP 주소로 해석
2. 내 ssh 클라이언트가 서버 IP의 TCP 22 포트로 연결 시도
3. 원격 서버의 sshd가 22 포트에서 연결을 받음
4. 사용자 인증
5. 원격 셸 세션 시작
즉 SSH도 결국 다음 구조다.
1
도메인 -> IP -> port -> socket -> 원격 프로세스(sshd)
6. 브라우저에서 웹서버까지의 접속 흐름
브라우저에 다음 주소를 입력했다고 하자.
1
https://example.com
흐름은 대략 다음과 같다.
1
2
3
4
5
6
1. 브라우저가 example.com의 IP 주소를 DNS로 조회
2. HTTPS 기본 포트 443을 사용해 서버 IP로 TCP 연결 시도
3. TLS 연결을 맺어 암호화 통신 준비
4. HTTP 요청 전송
5. 서버가 HTTP 응답 반환
6. 브라우저가 HTML/CSS/JS 등을 렌더링
URL에 포트가 생략되면 프로토콜의 기본 포트를 사용한다.
1
2
3
http://example.com -> 기본 80
https://example.com -> 기본 443
http://localhost:8080 -> 명시한 8080
7. DNS와 웹서버의 관계
DNS는 도메인 이름을 IP 주소로 바꾸는 역할을 한다.
1
example.com -> 203.0.113.10
DNS가 웹서버 자체는 아니다. DNS는 “어느 IP로 가야 하는지”를 알려주고, 실제 HTTP 요청은 그 IP의 웹 서버 또는 리버스 프록시가 받는다.
1
2
3
4
브라우저
-> DNS로 IP 조회
-> 서버 IP의 443 포트 접속
-> nginx 같은 리버스 프록시 또는 웹서버가 요청 수신
8. 리버스 프록시는 포트 흐름에서 어디에 있는가?
리버스 프록시는 외부 요청을 먼저 받는 서버다.
1
브라우저 -> nginx:443 -> app:8080
예를 들어 Spring Boot 앱은 내부적으로 8080 포트에서 실행하고, nginx는 외부에서 443 포트를 받을 수 있다.
1
2
3
외부 사용자 example.com:443
nginx 0.0.0.0:443
내부 앱 서버 127.0.0.1:8080
이 구조에서 사용자는 보통 앱 서버의 8080 포트에 직접 접속하지 않는다. nginx가 HTTPS, 요청 라우팅, 정적 파일, 로드 밸런싱 같은 역할을 앞단에서 맡고 내부 앱으로 넘긴다.
1
2
3
DNS는 IP를 알려준다.
리버스 프록시는 그 IP의 공개 포트에서 요청을 받는다.
앱 서버는 내부 포트에서 실제 비즈니스 로직을 처리한다.
9. 웹 접속 전체 그림
브라우저에서 리버스 프록시 뒤의 앱까지 가는 흐름을 한 번에 보면 다음과 같다.
1
2
3
4
5
6
7
8
9
사용자 브라우저
-> URL 입력: https://example.com
-> DNS 조회: example.com -> 서버 IP
-> 서버 IP:443으로 TCP 연결
-> 연결을 받는 socket
-> nginx 리버스 프록시
-> 내부 앱 서버 127.0.0.1:8080 또는 사설 네트워크의 app:8080
-> HTTP 응답
-> 브라우저 렌더링
10. 핵심 정리
1
2
3
4
5
6
7
8
IP 주소 어느 컴퓨터인지 식별
port 그 컴퓨터 안 어느 네트워크 서비스인지 식별
socket 프로그램이 네트워크를 읽고 쓰는 통신 끝점
DNS 도메인 이름을 IP 주소로 해석
SSH 보통 서버 IP의 TCP 22 포트로 접속
웹 접속 보통 HTTP 80, HTTPS 443 포트 사용
localhost 자기 컴퓨터를 가리키는 이름
리버스 프록시 외부 요청을 먼저 받아 내부 앱 서버로 전달
가장 중요한 흐름은 다음 한 줄이다.
1
도메인 이름 -> DNS -> IP 주소 -> port -> socket -> 서버 프로세스
Q&A: nginx architecture는 어떻게 이해하면 되는가?
질문
nginx architecture는 무엇인가?
답변
nginx는 보통 master process와 worker process 구조로 동작한다.
1
2
3
4
nginx master process
├── nginx worker process
├── nginx worker process
└── nginx worker process
master process는 설정 파일을 읽고, worker process를 관리한다. 실제 클라이언트 요청 처리는 주로 worker process가 담당한다.
1
2
master 설정 로드, worker 관리, graceful reload
worker 클라이언트 연결 처리, 요청 처리, upstream 통신
nginx가 많은 연결을 효율적으로 처리할 수 있는 이유는 worker가 이벤트 기반으로 동작하기 때문이다. 연결마다 스레드를 하나씩 만드는 방식이 아니라, epoll 같은 이벤트 I/O를 사용해 많은 socket 이벤트를 처리한다.
1
2
3
많은 클라이언트 socket
-> worker의 이벤트 루프
-> 준비된 요청만 처리
그래서 nginx는 정적 파일 서빙, 리버스 프록시, 로드 밸런싱에 자주 쓰인다.
정리하면 다음과 같다.
1
2
3
nginx master 관리 프로세스
nginx worker 실제 요청 처리 프로세스
event-driven 많은 연결을 효율적으로 다루는 구조
Q&A: reverse proxy 흐름은 어떻게 되는가?
질문
reverse proxy 흐름은 어떻게 되는가?
답변
리버스 프록시는 클라이언트 요청을 실제 애플리케이션 서버 앞에서 먼저 받는 서버다.
1
브라우저 -> nginx -> 애플리케이션 서버
예를 들어 사용자가 다음 주소로 접속한다고 하자.
1
https://example.com
흐름은 대략 다음과 같다.
1
2
3
4
5
6
1. DNS가 example.com을 서버 IP로 해석
2. 브라우저가 서버 IP의 443 포트로 접속
3. nginx가 HTTPS 요청을 받음
4. nginx가 내부 앱 서버로 요청 전달
5. 앱 서버가 응답 생성
6. nginx가 응답을 브라우저에 반환
내부 앱은 다음처럼 외부에 직접 공개되지 않은 포트에서 실행될 수 있다.
1
2
nginx 0.0.0.0:443
app server 127.0.0.1:8080
이 구조의 장점은 다음과 같다.
1
2
3
4
5
6
HTTPS 처리 집중
내부 앱 포트 숨김
여러 앱으로 라우팅
로드 밸런싱
정적 파일 처리
보안 헤더와 rate limit 적용
핵심은 리버스 프록시가 “서버 앞에 서서 서버를 대신해 요청을 받는 중간 서버”라는 점이다.
Q&A: TCP handshake는 무엇인가?
질문
TCP handshake는 무엇인가?
답변
TCP handshake는 TCP 연결을 시작하기 전에 클라이언트와 서버가 서로 통신 준비를 확인하는 절차다. 보통 3-way handshake라고 부른다.
1
2
3
1. 클라이언트 -> 서버: SYN
2. 서버 -> 클라이언트: SYN-ACK
3. 클라이언트 -> 서버: ACK
이 과정을 통해 양쪽은 “서로 데이터를 주고받을 준비가 됐다”고 확인한다.
브라우저가 https://example.com에 접속할 때도 HTTP 요청을 보내기 전에 먼저 서버의 443 포트와 TCP 연결을 맺는다.
1
2
3
4
5
DNS 조회
-> TCP handshake
-> TLS handshake
-> HTTP 요청
-> HTTP 응답
TCP handshake는 HTTP 자체가 아니라 HTTP 아래 계층의 TCP 연결 준비 과정이다.
정리하면 다음과 같다.
1
2
3
4
TCP handshake TCP 연결을 시작하기 위한 준비 절차
SYN 연결 시작 요청
SYN-ACK 요청 수락과 응답
ACK 확인
Q&A: HTTP와 WebSocket은 어떻게 다른가?
질문
HTTP와 WebSocket은 어떻게 다른가?
답변
HTTP와 WebSocket은 둘 다 웹에서 많이 쓰이지만 통신 방식이 다르다.
HTTP는 기본적으로 요청-응답 방식이다.
1
2
브라우저 -> 서버: 요청
서버 -> 브라우저: 응답
예를 들어 페이지를 가져오거나 API를 호출할 때 HTTP를 사용한다.
1
2
GET /users
POST /orders
WebSocket은 처음에는 HTTP 요청으로 시작하지만, 연결을 업그레이드한 뒤 하나의 연결을 유지하면서 양방향 메시지를 주고받는다.
1
2
3
HTTP Upgrade
-> WebSocket 연결 유지
-> 클라이언트와 서버가 서로 메시지 전송
그래서 채팅, 실시간 알림, 게임, 실시간 대시보드처럼 서버가 즉시 메시지를 밀어줘야 하는 기능에서 WebSocket이 자주 쓰인다.
정리하면 다음과 같다.
1
2
HTTP 요청이 있어야 응답하는 방식에 적합
WebSocket 연결을 유지하며 양방향 실시간 메시지에 적합
주의할 점은 WebSocket도 결국 아래에서는 TCP 연결 위에서 동작한다는 것이다. “socket”이라는 이름이 들어가지만 OS의 raw socket 개념과 완전히 같은 말은 아니다.
Q&A: NAT는 무엇인가?
질문
NAT는 무엇인가?
답변
NAT(Network Address Translation)는 네트워크 장비가 패킷의 IP 주소나 포트 정보를 바꿔서 전달하는 기능이다. 보통 사설 네트워크의 여러 기기가 하나의 공인 IP를 공유할 때 많이 쓴다.
집이나 회사 내부의 기기는 보통 사설 IP를 가진다.
1
2
3
192.168.0.10
192.168.0.11
192.168.0.12
이 기기들이 인터넷으로 나갈 때 공유기나 라우터가 외부에는 하나의 공인 IP처럼 보이게 바꿔준다.
1
2
3
내 PC 192.168.0.10:53000
-> 공유기 공인IP:40001
-> 인터넷 서버
응답이 돌아오면 NAT 장비는 포트 매핑 테이블을 보고 원래 내부 기기로 돌려보낸다.
1
2
공인IP:40001로 응답 도착
-> 192.168.0.10:53000으로 전달
그래서 내부에서 외부로 나가는 연결은 자연스럽게 되지만, 외부에서 내부 서버로 직접 들어오려면 포트 포워딩이나 로드 밸런서 설정이 필요할 수 있다.
1
2
3
4
NAT 주소/포트 변환
사설 IP 내부 네트워크에서 쓰는 주소
공인 IP 인터넷에서 라우팅 가능한 주소
포트 포워딩 외부 포트를 내부 IP:port로 전달
여기서 AP, 공유기, 라우터를 구분하면 더 명확하다.
1
2
3
4
AP 무선 기기를 유선 네트워크에 붙여 주는 접속 지점
라우터 서로 다른 네트워크 사이에서 패킷을 전달하는 장비
NAT 장비 사설 IP와 공인 IP 사이의 주소/포트 변환을 수행하는 장비
가정용 공유기 AP + 라우터 + NAT + DHCP + 방화벽 기능이 합쳐진 장비인 경우가 많음
가정에서 쓰는 “공유기”는 보통 여러 역할을 한 장비가 동시에 수행한다.
1
2
3
4
5
6
7
스마트폰/노트북
-> Wi-Fi
-> AP 기능
-> 공유기 내부 스위칭/라우팅
-> NAT
-> 통신사 망
-> 인터넷
AP(Access Point)는 말 그대로 무선 접속 지점이다. 노트북이나 스마트폰이 Wi-Fi로 붙을 수 있게 해준다. AP의 핵심 역할은 무선 구간과 유선 LAN 구간을 이어주는 것이다.
1
스마트폰 --Wi-Fi--> AP --유선 LAN--> 공유기/스위치
단독 AP 장비는 NAT를 하지 않을 수도 있다. 그냥 무선 기기를 같은 내부 네트워크에 붙여 주는 역할만 할 수 있다. 반면 집에서 흔히 말하는 Wi-Fi 공유기는 AP 기능과 NAT 기능을 함께 가진다.
1
2
순수 AP Wi-Fi 접속 제공. NAT는 안 할 수 있음
가정용 공유기 Wi-Fi AP + 라우터 + NAT + DHCP를 함께 수행하는 경우가 많음
DHCP도 함께 알아두면 좋다. 집에서 노트북이 Wi-Fi에 연결되면 보통 공유기가 내부 IP를 자동으로 나눠준다.
1
2
3
노트북이 Wi-Fi 접속
-> 공유기의 DHCP 기능이 192.168.0.23 같은 사설 IP 할당
-> 노트북은 그 IP로 내부 네트워크에 참여
그 다음 인터넷으로 나갈 때 NAT가 동작한다.
1
2
3
4
노트북 192.168.0.23:53000
-> 공유기 NAT
-> 공인IP:40001
-> 인터넷 서버 93.184.216.34:443
응답이 돌아올 때 공유기는 NAT 테이블을 보고 어느 내부 기기로 돌려줘야 하는지 판단한다.
1
2
3
4
인터넷 서버 응답
-> 공유기 공인IP:40001
-> NAT 테이블 조회
-> 192.168.0.23:53000으로 전달
이 때문에 내부에서 먼저 시작한 연결은 자연스럽게 응답을 받을 수 있다. 하지만 외부에서 집 안의 노트북이나 서버로 먼저 들어오려면 공유기가 어느 내부 IP와 포트로 전달해야 할지 알 수 없다.
그래서 포트 포워딩을 설정한다.
1
2
공유기 공인IP:8080
-> 192.168.0.50:80
이 설정은 “외부에서 공유기의 8080 포트로 들어오면 내부의 192.168.0.50 컴퓨터 80 포트로 보내라”는 뜻이다.
기업이나 데이터센터에서는 AP, 라우터, NAT, 방화벽, 로드 밸런서가 별도 장비나 별도 계층으로 나뉘는 경우가 많다.
1
2
3
4
5
6
7
무선 AP
스위치
라우터
방화벽
NAT 게이트웨이
로드 밸런서
서버
반면 가정용 공유기는 이 중 여러 기능을 한 박스에 묶어 제공하므로, 처음 배울 때 역할이 섞여 보인다.
정리하면 NAT는 “내부 네트워크와 외부 인터넷 사이에서 주소와 포트를 변환해 주는 장치 또는 기능”이다.
Q&A: 실제 HTTP 요청 lifecycle은 어떻게 되는가?
질문
실제 HTTP 요청 lifecycle은 어떻게 되는가?
답변
브라우저에서 URL을 입력하고 화면이 뜨기까지는 여러 단계가 이어진다. https://example.com/users에 접속한다고 가정하면 흐름은 대략 다음과 같다.
1
2
3
4
5
6
7
8
9
URL 입력
-> DNS 조회
-> TCP 연결
-> TLS 연결
-> HTTP 요청 전송
-> 리버스 프록시 또는 웹서버 수신
-> 애플리케이션 처리
-> HTTP 응답 반환
-> 브라우저 렌더링
조금 더 풀어보면 다음과 같다.
1
2
3
4
5
6
7
8
9
10
11
1. 브라우저가 URL을 해석한다.
2. example.com의 IP 주소를 DNS로 찾는다.
3. 서버 IP의 443 포트로 TCP 연결을 맺는다.
4. HTTPS라면 TLS handshake로 암호화 통신을 준비한다.
5. 브라우저가 HTTP 요청을 보낸다.
6. nginx 같은 리버스 프록시가 요청을 받을 수 있다.
7. 리버스 프록시가 내부 앱 서버로 요청을 전달한다.
8. 앱 서버가 라우팅, 인증, 비즈니스 로직, DB 조회 등을 처리한다.
9. 앱 서버가 HTTP 응답을 만든다.
10. 응답이 리버스 프록시를 거쳐 브라우저로 돌아간다.
11. 브라우저가 HTML, CSS, JavaScript, 이미지 등을 해석해 화면을 그린다.
HTTP 요청 자체는 보통 이런 구조를 가진다.
1
2
3
4
GET /users HTTP/1.1
Host: example.com
User-Agent: browser
Accept: text/html
서버 응답은 보통 이런 구조다.
1
2
3
4
HTTP/1.1 200 OK
Content-Type: text/html
<html>...</html>
실제 서비스에서는 앞단에 리버스 프록시가 있는 경우가 많다.
1
2
3
4
5
6
7
8
브라우저
-> example.com:443
-> nginx
-> 내부 앱 서버:8080
-> DB 또는 캐시
-> 내부 앱 서버
-> nginx
-> 브라우저
여기서 각 계층의 역할은 다르다.
1
2
3
4
5
6
DNS 도메인을 IP로 바꿈
TCP 연결을 맺고 데이터를 신뢰성 있게 전달
TLS 통신을 암호화하고 서버 신원을 확인
HTTP 요청과 응답의 형식을 정의
nginx 요청을 받고 내부 서버로 전달
app 실제 비즈니스 로직 처리
정리하면 HTTP 요청 lifecycle은 단순히 “브라우저가 서버에 요청한다”가 아니라, DNS, TCP, TLS, HTTP, 리버스 프록시, 앱 서버, DB 처리가 이어지는 전체 흐름이다.
Q&A: SSL, TLS, HTTPS는 무엇인가?
질문
SSL, TLS, HTTPS는 무엇인가?
답변
HTTPS는 HTTP에 암호화 계층을 더한 것이다. 정확히는 HTTP가 TLS 위에서 동작하는 형태라고 보면 된다.
1
2
3
HTTP 암호화 없는 웹 요청/응답 프로토콜
TLS 통신 암호화와 인증을 제공하는 보안 계층
HTTPS HTTP over TLS
SSL이라는 말도 자주 듣지만, 현대적으로는 TLS가 맞는 표현이다. SSL은 오래된 보안 프로토콜이고, 현재는 TLS가 그 역할을 이어받았다. 실무에서는 관성적으로 “SSL 인증서”라고 부르지만 실제로는 TLS 인증서 맥락인 경우가 많다.
HTTPS 접속 흐름은 대략 다음과 같다.
1
2
3
4
5
6
1. 브라우저가 서버의 443 포트로 TCP 연결을 맺는다.
2. TLS handshake를 시작한다.
3. 서버가 인증서를 보낸다.
4. 브라우저가 인증서가 신뢰할 수 있는지 확인한다.
5. 양쪽이 암호화에 사용할 키를 합의한다.
6. 이후 HTTP 요청/응답은 암호화된 통로로 오간다.
TLS가 제공하는 핵심은 세 가지다.
1
2
3
암호화 중간에서 내용을 훔쳐봐도 읽기 어렵게 함
무결성 중간에서 데이터가 바뀌었는지 감지
인증 접속한 서버가 진짜 그 도메인의 서버인지 확인
예를 들어 사용자가 다음 주소에 접속한다고 하자.
1
https://example.com
브라우저는 example.com의 인증서를 확인한다. 인증서에는 이 서버가 example.com 도메인에 대해 신뢰 가능한 인증 기관으로부터 검증받았다는 정보가 들어 있다.
리버스 프록시를 사용하는 서비스에서는 TLS 처리를 nginx 같은 앞단 서버가 맡는 경우가 많다.
1
브라우저 --HTTPS--> nginx --HTTP 또는 내부 HTTPS--> app server
이것을 TLS termination이라고 부르기도 한다. 외부 HTTPS 연결은 nginx에서 끝나고, nginx가 내부 앱 서버로 요청을 넘긴다.
정리하면 다음과 같다.
1
2
3
4
5
SSL 오래된 이름. 지금은 보통 TLS를 의미하는 말로 섞여 쓰임
TLS 현재의 표준적인 암호화 통신 계층
HTTPS HTTP를 TLS로 보호하는 방식
인증서 서버 신원을 확인하기 위한 증명서
443 port HTTPS 기본 포트
가장 중요한 구분은 이것이다.
1
2
3
HTTP는 메시지 형식과 의미를 다룬다.
TLS는 그 메시지가 오가는 통로를 안전하게 만든다.
HTTPS는 HTTP를 TLS 위에서 주고받는 방식이다.
Q&A: 패킷은 무엇이고 물리적인 것인가?
질문
패킷에 대해서 알고 싶다. 네트워크 간 통신 중에 일어나는 데이터 전송은 결국 패킷으로 이루어진다고 알고 있다. 그런데 패킷은 물리적인 것인가? 멀리 떨어진 기계 간 전송이니까 PC -> AP -> 공유기 -> 유선 광통신 -> 통신사 전신주 -> 매립 케이블 -> 해저 케이블 -> 해외 어딘가의 PC 같은 흐름으로 도달하는 것인가?
답변
패킷(packet)은 네트워크에서 데이터를 한 번에 통째로 보내지 않고, 작은 조각으로 나누어 보낼 때의 데이터 단위다.
예를 들어 브라우저가 서버에서 큰 HTML, 이미지, 동영상 데이터를 받는다고 해도 그 데이터가 하나의 거대한 덩어리로 이동하는 것은 아니다. 여러 조각으로 나뉘어 이동한다.
1
2
3
4
5
큰 데이터
-> packet 1
-> packet 2
-> packet 3
-> ...
패킷은 보통 다음처럼 구성된다.
1
2
header 어디서 왔고 어디로 가는지, 어떻게 처리할지에 대한 정보
payload 실제 전달하려는 데이터 조각
예를 들어 IP 패킷의 header에는 출발지 IP, 목적지 IP 같은 정보가 들어가고, payload에는 TCP 조각이나 UDP 데이터가 들어간다.
중요한 질문은 “패킷이 물리적인가?”다.
정확히 말하면 패킷 자체는 논리적인 데이터 구조다. 하지만 그 패킷은 실제 전송될 때 물리 매체 위에서 전기 신호, 전파, 빛 신호 같은 형태로 표현된다.
1
2
패킷 논리적인 데이터 단위
전송 매체 전기 신호, 무선 전파, 광 신호 등으로 패킷을 표현해 이동시킴
즉 패킷이 작은 물건처럼 케이블 속을 굴러가는 것은 아니다. 패킷의 비트들이 물리 계층에서 신호로 바뀌어 이동한다.
1
2
3
4
5
데이터 조각
-> 0과 1의 비트열
-> 전기/전파/빛 신호
-> 반대편 장비에서 다시 비트열로 해석
-> 패킷으로 처리
네가 말한 경로는 현실적으로 꽤 좋은 그림이다. 집에서 해외 서버에 접속한다면 대략 이런 흐름이 될 수 있다.
1
2
3
4
5
6
7
8
9
10
11
내 PC 또는 스마트폰
-> Wi-Fi AP
-> 집 공유기
-> 통신사 장비
-> 지역/국가 백본망
-> 광케이블
-> 해저 케이블
-> 해외 통신망
-> 데이터센터 라우터
-> 로드 밸런서 또는 리버스 프록시
-> 서버
다만 모든 요청이 항상 이 경로를 그대로 거치는 것은 아니다. 실제 경로는 네트워크 사업자, 라우팅 정책, CDN, 캐시, 장애 상황에 따라 달라진다.
예를 들어 example.com에 접속한다고 해도 실제 서버가 해외 원본 서버가 아니라 가까운 CDN edge 서버일 수 있다.
1
2
3
브라우저
-> 가까운 CDN 서버
-> 필요하면 원본 서버
패킷이 이동할 때 중간 장비들은 보통 목적지 IP를 보고 다음 장비로 넘긴다. 이런 장비를 라우터라고 부른다.
1
2
3
4
패킷 도착
-> 목적지 IP 확인
-> 라우팅 테이블 확인
-> 다음 hop으로 전달
여기서 hop은 패킷이 거쳐 가는 중간 네트워크 장비 하나를 뜻한다.
1
PC -> 공유기 -> 통신사 라우터 -> 백본 라우터 -> 데이터센터 라우터 -> 서버
패킷은 목적지까지 가는 동안 항상 같은 경로를 지나야 하는 것은 아니다. 여러 패킷이 서로 다른 경로로 갈 수도 있고, 중간에서 유실될 수도 있다. TCP는 이런 상황에서 순서 재조립, 재전송, 흐름 제어 같은 일을 해준다.
1
2
IP 패킷을 목적지 방향으로 전달하려고 함
TCP 유실, 순서, 재전송 등 신뢰성 처리
계층별로 보면 더 명확하다.
1
2
3
4
5
HTTP 메시지
-> TCP segment
-> IP packet
-> Ethernet frame 또는 Wi-Fi frame
-> 전기/전파/빛 신호
용어를 구분하면 다음과 같다.
1
2
3
4
segment TCP 계층의 데이터 단위
packet IP 계층의 데이터 단위
frame Ethernet/Wi-Fi 같은 링크 계층의 데이터 단위
signal 실제 물리 매체 위의 전기/전파/빛 표현
일상적으로는 이 모든 것을 뭉뚱그려 “패킷”이라고 부르는 경우가 많다. 하지만 정확히는 계층마다 데이터 단위 이름이 다르다.
정리하면 다음과 같다.
1
2
3
4
5
패킷은 논리적인 데이터 조각이다.
패킷은 실제 전송될 때 물리 신호로 변환된다.
멀리 있는 서버까지는 여러 네트워크 장비와 케이블을 거쳐 간다.
라우터는 패킷을 다음 경로로 전달한다.
TCP는 패킷 유실과 순서 문제를 보완해 신뢰성 있는 통신처럼 보이게 한다.
따라서 “패킷은 물리적인가?”에 대한 답은 다음처럼 정리할 수 있다.
1
2
패킷 자체는 논리적인 데이터 구조다.
하지만 패킷의 비트는 실제 세계에서 전기, 전파, 빛 신호로 이동한다.