Network
목차
네트워크가 해결하는 문제
네트워크는 떨어져 있는 컴퓨터들이 데이터를 주고받게 해주는 체계다. 핵심 문제는 “어떻게 목적지를 찾고, 데이터를 나누어 보내고, 중간 장비를 거쳐, 다시 의미 있는 데이터로 조립할 것인가”다.
1
2
3
4
5
6
내 컴퓨터
-> 공유기
-> 통신사 네트워크
-> 인터넷 백본
-> 데이터센터
-> 서버
네트워크는 계층으로 나누어 이해하면 좋다. 각 계층은 자기 역할에 집중하고, 위아래 계층과 약속된 인터페이스로 연결된다.
1
2
3
4
5
HTTP 애플리케이션 메시지
TCP/UDP 전송 방식
IP 목적지 주소와 라우팅
Ethernet/Wi-Fi 같은 링크 계층
전기/전파/빛 물리 신호
이렇게 나누면 브라우저 접속, SSH, API 호출, 채팅 같은 서로 다른 기능도 공통 구조로 설명할 수 있다.
IP와 포트
IP 주소는 네트워크에서 어느 컴퓨터로 갈지 식별한다. 포트는 그 컴퓨터 안에서 어느 프로그램으로 갈지 식별한다.
1
2
IP 주소 = 목적지 호스트
port = 목적지 프로세스의 네트워크 입구
예를 들어 다음 주소는 서버 컴퓨터의 SSH 서비스로 접속하겠다는 의미다.
1
203.0.113.10:22
1
2
203.0.113.10 서버의 IP 주소
22 SSH 서버가 기다리는 포트
IP만 있으면 컴퓨터는 찾을 수 있지만, 그 컴퓨터에서 웹 서버로 갈지 SSH 서버로 갈지 알 수 없다. 그래서 포트가 필요하다.
1
2
3
4
22 SSH
80 HTTP
443 HTTPS
5432 PostgreSQL
단, 포트 번호는 관례일 뿐이다. 설정에 따라 SSH도 2222 같은 다른 포트를 사용할 수 있다.
TCP와 UDP
TCP와 UDP는 전송 계층 프로토콜이다. 둘 다 IP 위에서 동작하지만 성격이 다르다.
TCP는 연결 기반이고 신뢰성을 제공한다. 데이터를 순서대로 전달하려고 하고, 유실되면 재전송하며, 흐름 제어와 혼잡 제어를 수행한다.
1
2
3
4
5
TCP
-> 3-way handshake
-> 데이터 전송
-> 순서 보장
-> 유실 시 재전송
TCP가 handshake를 하는 이유는 양쪽이 통신 준비가 되었는지 확인하고, 연결 상태를 만들기 위해서다.
1
2
3
SYN
SYN-ACK
ACK
UDP는 연결을 만들지 않고 데이터를 보낸다. 그래서 TCP보다 가볍고 빠를 수 있지만, 순서 보장이나 재전송을 기본으로 제공하지 않는다.
1
2
3
4
5
UDP
-> 연결 설정 없음
-> 낮은 오버헤드
-> 유실 가능
-> 순서 바뀔 수 있음
UDP가 신뢰성을 포기하는 이유는 모든 상황에서 신뢰성보다 빠른 전달과 낮은 지연이 더 중요할 수 있기 때문이다. 게임, 실시간 음성/영상, DNS 질의처럼 일부 유실을 감수하거나 애플리케이션이 직접 보완하는 경우에 유용하다.
DNS
DNS는 도메인 이름을 IP 주소로 바꿔주는 시스템이다.
1
example.com -> 93.184.216.34
DNS는 웹 서버가 아니다. DNS는 어디로 가야 하는지 주소를 알려주는 역할이고, 실제 HTTP 요청은 그 IP에 있는 웹 서버나 리버스 프록시가 받는다.
1
2
3
4
브라우저
-> DNS 조회
-> IP 주소 획득
-> 해당 IP의 443 포트로 접속
도메인 이름을 쓰는 이유는 사람이 IP 주소를 외우기 어렵고, 서버의 실제 IP가 바뀌어도 도메인 이름은 유지할 수 있기 때문이다.
HTTP와 HTTPS
HTTP는 웹에서 요청과 응답을 주고받는 애플리케이션 계층 프로토콜이다.
1
2
client -> HTTP request -> server
client <- HTTP response <- server
예를 들어 브라우저가 사용자 목록을 요청하면 다음 같은 HTTP 요청을 보낼 수 있다.
1
2
GET /users HTTP/1.1
Host: example.com
HTTPS는 HTTP를 TLS로 보호하는 방식이다. HTTP 메시지의 형식이 바뀌는 것이 아니라, HTTP가 암호화된 통로 위에서 오간다.
1
2
3
HTTP 요청/응답 의미와 형식
TLS 암호화, 무결성, 서버 인증
HTTPS HTTP over TLS
HTTP와 WebSocket도 구분해야 한다. HTTP는 기본적으로 요청-응답 모델이고, WebSocket은 연결을 유지하며 양방향 메시지를 주고받는 모델이다.
1
2
HTTP 요청이 있어야 응답
WebSocket 연결 유지 후 양방향 메시지
채팅이나 실시간 알림은 WebSocket이 잘 맞고, 일반 페이지 로딩이나 REST API 호출은 HTTP가 잘 맞는다.
라우팅과 NAT
라우팅은 패킷을 목적지 방향으로 보내기 위해 다음 경로를 결정하는 과정이다. 인터넷의 라우터들은 목적지 IP를 보고 다음 hop으로 패킷을 전달한다.
1
2
3
4
패킷 도착
-> 목적지 IP 확인
-> 라우팅 테이블 확인
-> 다음 장비로 전달
NAT는 IP 주소나 포트 정보를 바꿔서 전달하는 기능이다. 보통 사설 네트워크의 여러 기기가 하나의 공인 IP를 공유할 때 사용한다.
1
2
3
내 PC 192.168.0.10:53000
-> 공유기 공인IP:40001
-> 인터넷 서버
응답이 돌아오면 NAT 장비는 매핑 테이블을 보고 원래 내부 기기로 돌려보낸다.
1
2
공인IP:40001
-> 192.168.0.10:53000
NAT가 필요한 이유는 IPv4 공인 주소가 제한적이고, 내부 네트워크 구조를 외부에 그대로 노출하지 않으면서 인터넷 접속을 가능하게 하기 위해서다. 외부에서 내부 서버로 들어오게 하려면 포트 포워딩이나 로드 밸런서 설정이 필요할 수 있다.
소켓과 서버
소켓은 프로그램이 네트워크 통신을 하기 위해 사용하는 통신 끝점이다. 서버 프로그램은 특정 IP와 포트에 소켓을 열고 연결을 기다린다.
1
2
3
4
5
socket
-> bind IP:port
-> listen
-> accept connection
-> read/write
프로그램 입장에서 socket은 네트워크를 파일처럼 읽고 쓰게 해주는 인터페이스에 가깝다.
1
클라이언트 socket <-> 서버 socket
웹 서버는 보통 80 또는 443 포트에서 요청을 기다리고, SSH 서버는 보통 22 포트에서 기다린다.
1
2
nginx -> 0.0.0.0:443 listen
sshd -> 0.0.0.0:22 listen
서버를 이해할 때는 “프로세스가 socket을 열고, 커널이 들어오는 패킷을 해당 socket에 연결한다”는 그림이 중요하다.
지연 시간, 대역폭, 처리량
지연 시간(latency)은 요청을 보내고 응답을 받기까지 걸리는 시간이다. 대역폭(bandwidth)은 이론적으로 한 번에 보낼 수 있는 데이터 통로의 크기다. 처리량(throughput)은 실제로 단위 시간에 처리된 데이터 양이다.
1
2
3
latency 얼마나 빨리 첫 응답이 오는가
bandwidth 통로가 얼마나 넓은가
throughput 실제로 얼마나 많이 처리되는가
예를 들어 해외 서버에 접속하면 대역폭이 충분해도 왕복 거리가 멀어 latency가 커질 수 있다. 반대로 가까운 서버라도 사용자가 몰리면 처리량이 떨어질 수 있다.
1
2
3
화상회의 latency 중요
파일 다운로드 bandwidth와 throughput 중요
API 서버 latency와 throughput 모두 중요
성능을 볼 때 하나의 숫자만 보면 안 된다. 평균 latency가 낮아도 99번째 percentile이 높으면 일부 사용자는 느린 경험을 한다.