09/28 - 네트워크 기초이론
본문 로딩 중...
네트워크로 데이터를 보내면 상대에게 도착하기까지 지연(latency)이 생긴다. 물리적인 거리, 중간 장비, 네트워크 혼잡, 상대 프로그램의 처리 시간 등이 영향을 준다. 네트워크 프로그래밍은 이 지연을 없애는 일이 아니라, 지연이 있다는 전제에서 무엇을 언제 어떻게 보낼지 설계하는 일이다.
핑(ping)은 보낸 요청에 대한 응답이 돌아오는 데 걸린 왕복 시간(RTT)을 확인하는 도구이자, 일상적으로 그 왕복 지연 시간을 가리키는 말이다. 초당 얼마나 많은 데이터를 보낼 수 있는지 나타내는 전송 속도(대역폭)와는 다르다.
게임에서는 플레이어의 입력과 서버의 처리 결과가 각 화면에 도착하는 시점이 다르다. 동기화는 이런 차이가 있어도 필요한 게임 상태를 각 참여자가 일관되게 다루도록 하는 일이다. 모든 데이터를 매 순간 똑같이 만드는 것만을 뜻하지 않는다. 예를 들어 중요한 결과는 확인해서 전달하고, 자주 바뀌는 위치는 최신 상태를 우선할 수 있다.
| 개념 | 핵심 역할 | 이해할 점 |
|---|---|---|
| TCP | 연결을 맺고, 수신 확인과 재전송을 사용해 데이터를 순서대로 읽을 수 있는 바이트 흐름을 제공한다. | 손실이 생기면 복구를 시도하지만 지연이 늘 수 있다. 상대 응용 프로그램이 내용을 처리했다는 보장까지 제공하지는 않는다. |
| UDP | 독립적인 데이터그램을 보낸다. | UDP 자체는 도착, 순서, 재전송을 보장하지 않는다. 필요한 보장은 응용 프로그램에서 구현할 수 있다. |
| P2P(Peer to Peer) | 참여자끼리 직접 통신하는 연결 구조다. | TCP·UDP 중 무엇을 사용할지와는 별개의 선택이다. |
| RPC(Remote Procedure Call) | 다른 프로세스나 컴퓨터의 기능을 호출하는 것처럼 요청하는 방식이다. | 실제로는 요청을 보내고 응답을 기다리는 네트워크 통신이므로 지연과 실패 가능성을 고려해야 한다. |
TCP를 단순히 ‘느리고 안전한 방식’, UDP를 ‘빠르지만 위험한 방식’으로 외우면 부족하다. UDP는 절차가 단순하지만 언제나 더 빠른 것은 아니며, TCP도 통신 장애가 계속되면 전달에 실패할 수 있다. 데이터의 중요도, 순서 필요성, 늦게 도착한 데이터의 가치에 따라 방식을 고른다.
네트워크 계층 모델은 데이터를 만들고 전달하는 일을 역할별로 나누어 이해하기 위한 틀이다. 모델이 각 단계의 데이터 형식을 자동으로 정하는 것은 아니다. 실제 데이터 형식과 통신 규칙은 HTTP, TCP, IP, 이더넷 같은 프로토콜이 정한다. 보내는 쪽은 상위 계층의 데이터를 아래 계층으로 넘기며 전달 정보를 덧붙이고, 받는 쪽은 이를 확인하며 위로 올린다.
| 계층 | 역할과 예시 |
|---|---|
| 7. 응용(Application) | 응용 프로그램이 네트워크 서비스를 사용하는 규칙을 다룬다. HTTP, SMTP, FTP 등이 예다. 게임에서는 채팅·입력 등 무엇을 주고받을지 정한다. 사용자 화면 자체와 같은 뜻은 아니다. |
| 6. 표현(Presentation) | 데이터 표현과 변환을 다룬다. 문자 인코딩, 압축, 암호화가 설명에 쓰이는 예다. 이런 기능이 실제 구현에서 반드시 별도 계층으로 분리되는 것은 아니다. |
| 5. 세션(Session) | 통신의 대화 상태와 세션 관리 기능을 설명한다. 실제 프로토콜에서는 이 기능이 응용 프로그램이나 다른 계층에 나뉘어 구현될 수 있다. 데이터 파싱 자체를 뜻하지 않는다. |
| 4. 전송(Transport) | 두 프로그램 사이의 전달 방식을 다룬다. TCP·UDP와 포트 번호가 여기에 속한다. TCP는 순서와 재전송을 제공하고, UDP는 그런 보장을 기본 제공하지 않는다. |
| 3. 네트워크(Network) | IP 주소로 목적지 네트워크를 나타내고 라우팅한다. 라우터가 다음 경로를 선택한다. |
| 2. 데이터 링크(Data Link) | 현재 연결 구간에서 프레임을 다음 장치로 전달한다. 이더넷의 MAC 주소와 스위치가 대표적인 예다. |
| 1. 물리(Physical) | 비트를 전기·빛·무선 신호로 전달한다. 케이블과 물리 신호가 여기에 해당한다. |
IP 주소는 최종 목적지를 찾는 데 쓰이고, 이더넷의 MAC 주소는 현재 구간에서 다음 장치로 전달하는 데 쓰인다. MAC 주소는 네트워크 인터페이스에 할당되는 주소지만 설정으로 바뀔 수 있으므로 절대 변하지 않는 하드웨어 고유값으로 이해하지 않는다.
포트 번호는 같은 컴퓨터에서 어떤 통신 프로그램에 데이터를 전달할지 구별한다. 포트 포워딩은 보통 라우터의 NAT 설정으로 외부에서 온 통신을 내부 장치로 넘기는 기능이다. 전송 계층 자체의 기능으로 분류하지 않는다. 특정 서비스에 접속하려면 서버가 해당 포트에서 요청을 받을 준비가 되어 있어야 하며, 방화벽이나 라우터 설정도 통신에 영향을 준다.
TCP/IP 모델은 인터넷에서 실제로 쓰는 프로토콜 묶음을 설명할 때 흔히 쓰는 네 계층 구분이다.
| TCP/IP 4계층 | 대응하는 OSI 계층 | 주요 예 |
|---|---|---|
| 응용(Application) | 7. 응용 + 6. 표현 + 5. 세션 | HTTP, DNS, SMTP, 게임 프로토콜 |
| 전송(Transport) | 4. 전송 | TCP, UDP |
| 인터넷(Internet) | 3. 네트워크 | IP, ICMP |
| 링크(Link) | 2. 데이터 링크 + 1. 물리 | 이더넷, Wi-Fi, 물리 매체 |
두 모델은 계층을 나누는 관점과 세분화 정도가 다르다. OSI는 통신 기능을 일곱 부분으로 자세히 설명하고, TCP/IP는 인터넷 프로토콜의 실제 구성을 네 부분으로 묶어 설명한다. TCP/IP의 응용 계층에는 OSI의 표현·세션 기능이 필요에 따라 포함되고, 링크 계층에는 데이터 링크·물리 기능이 함께 포함된다.
ARP는 IPv4 주소에 대응하는 같은 링크 구간의 MAC 주소를 알아낼 때 사용한다. 계층 경계에 걸친 역할이 있어 교재마다 링크 계층 또는 인터넷 계층과 연관 지어 설명하므로, TCP/IP 인터넷 계층의 대표 프로토콜로만 고정해 외우지 않는다.
게임 클라이언트가 입력 데이터를 보낼 때, 응용 계층에서 보낼 내용과 형식을 정한다. 전송 계층은 TCP나 UDP 및 포트 번호를 사용하고, 인터넷 계층은 목적지 IP 주소를 사용한다. 링크 계층은 현재 연결 구간에서 필요한 주소와 신호로 데이터를 보낸다. 받는 쪽은 반대 방향으로 처리해 프로그램에 전달한다. P2P인지 서버 중심 구조인지는 누구와 연결하는지의 문제이고, RPC를 사용하는지는 어떤 방식으로 원격 기능을 요청하는지의 문제다.
응용 프로그램이 만든 데이터는 TCP/IP 계층을 거치며 전송에 필요한 정보가 붙고 네트워크로 전달된다. 패킷은 네트워크에서 전달되는 데이터 단위를 넓게 부르는 말이다. 모든 데이터를 미리 동일한 크기로 나눠 보내는 것은 아니다.
TCP는 응용 프로그램의 바이트 흐름을 전송에 알맞은 단위로 나누어 보낸다. 받는 쪽 TCP는 이를 순서대로 처리해 바이트 흐름으로 제공한다. 반면 UDP는 응용 프로그램이 보낸 데이터그램의 경계를 유지한다. TCP를 사용할 때는 받는 프로그램이 바이트 흐름에서 채팅 메시지처럼 개별 메시지의 시작과 끝을 구별하는 방법도 정해야 한다.
앞에서 본 IP 주소는 IP 네트워크에서 목적지를 찾아 데이터를 전달할 때 사용하는 논리적 주소다. 주소 체계에는 IPv4와 IPv6가 있다.
도메인 이름은 example.com처럼 사람이 사용하기 쉬운 이름이다. DNS는 도메인 이름에 대응하는 IP 주소 등 필요한 정보를 조회하는 시스템이다. 웹사이트뿐 아니라 여러 인터넷 서비스에서 사용한다. 프로그램은 조회한 IP 주소를 이용해 목적지와 통신할 수 있다.
앞에서 다룬 포트 번호는 한 장치에서 통신할 프로그램이나 서비스를 구별한다. 소켓 통신에서는 IP 주소와 포트 번호뿐 아니라 TCP·UDP 중 어떤 프로토콜을 사용하는지도 중요하다. 프로토콜은 통신하는 양쪽이 따르는 규칙이다. 데이터 형식, 주고받는 절차, 오류나 손실에 대응하는 방법 등은 프로토콜에 따라 달라진다. 모든 프로토콜이 같은 방식으로 수신 확인이나 흐름 제어를 제공하는 것은 아니다.
TCP는 수신 확인과 재전송으로 손실된 데이터를 복구하려고 하며, 흐름 제어와 혼잡 제어도 수행한다. 채팅 메시지, 로그인 요청, 랭킹 저장처럼 누락되거나 순서가 바뀌면 곤란한 데이터에 사용할 수 있다. UDP는 순서와 재전송을 기본 제공하지 않으므로, 오래된 위치 정보보다 최신 위치 정보가 중요한 게임 동기화에 사용할 수 있다. 어느 방식이 적합한지는 데이터의 성격에 달려 있다.
Head-of-Line(HOL) 블로킹은 앞선 데이터의 처리가 지연되어 뒤의 데이터도 기다리는 현상이다. TCP에서는 손실된 부분을 복구하기 전까지 그 뒤의 바이트를 응용 프로그램에 순서대로 전달할 수 없다. 따라서 게임에서는 늦더라도 반드시 받아야 하는 데이터인지, 늦게 받을 바에는 다음 최신 값을 받는 편이 나은 데이터인지 구별해야 한다.
3-way handshake(3단계 연결 수립)는 TCP에서 통신을 시작하기 전에 양쪽이 연결을 맺는 절차다. 클라이언트가 SYN(연결 요청)을 보내고, 서버가 SYN + ACK(연결 요청과 수신 확인)로 응답한 뒤, 클라이언트가 ACK(수신 확인)를 보내는 세 단계로 진행된다. 이 과정에서 서로의 송수신 준비 상태를 확인하고, 데이터 순서를 관리할 초기 순서 번호를 주고받는다. 매번 데이터를 보낼 때가 아니라 TCP 연결을 처음 맺을 때 수행한다.
TCP와 연결해서 설명하면, TCP는 3-way handshake로 연결을 맺은 뒤 데이터를 순서대로 전달하며, 앞선 데이터가 손실되면 뒤의 데이터도 기다리는 HOL 블로킹이 발생할 수 있다. 즉, 3-way handshake는 연결을 시작하는 절차, HOL 블로킹은 순서대로 전달하는 과정에서 생기는 대기 현상이다. 둘을 모두 데이터 전송 방식이라고 부르지는 않는다. HOL 블로킹은 TCP 외에서도 발생할 수 있지만, 여기서는 TCP의 순서 보장과 연결해서 이해하면 된다.
| 용어 | 뜻 |
|---|---|
| 지연 시간(Latency) | 데이터가 이동하고 처리되는 데 걸리는 시간. 게임에서는 입력 후 결과가 화면에 반영되기까지의 체감 지연도 가리킨다. |
| RTT(Round Trip Time) | 요청이 상대에게 갔다가 응답이 돌아오는 왕복 시간. 앞에서 설명한 핑과 관련된다. |
| 패킷 손실(Packet Loss) | 보낸 패킷이 목적지에 도착하지 않는 현상. |
이런 현상 때문에 플레이어마다 같은 사건을 서로 다른 시점에 볼 수 있다. 게임 네트워크는 실시간 반응, 상태 동기화, 보안, 불안정한 연결에 대한 대응, 서로 다른 플랫폼 간의 호환성을 함께 고려해야 한다.
게임 서버 모델을 정할 때는 다음 질문을 구별한다.
| 구조 | 작동 방식 | 장점과 고려할 점 |
|---|---|---|
| 전용 서버(Dedicated Server) | 플레이어와 별도로 실행되는 서버에 클라이언트들이 연결한다. | 서버가 공통 상태와 판정을 관리하기 좋지만 구축·운영 비용이 든다. 서버를 사용한다고 공정성이 자동으로 확보되는 것은 아니며 판정 규칙을 어떻게 구현하는지도 중요하다. |
| 리슨 서버(Listen Server) | 한 플레이어의 컴퓨터가 클라이언트이면서 다른 플레이어를 위한 서버 역할도 한다. | 별도 서버 운영 부담이 적지만 호스트의 연결 상태와 성능에 영향을 받는다. 호스트가 나가면 중단될 수 있으며, 이를 막으려면 호스트 이전 기능이 필요하다. |
| P2P(Peer to Peer) | 플레이어들이 서로 직접 연결한다. | 중앙 서버의 부담을 줄일 수 있지만 참여자가 많아질수록 연결·동기화·보안 관리가 복잡해질 수 있다. 중계 서버나 매칭 서버가 필요할 수 있으므로 서버 비용이 반드시 0인 것은 아니다. |
P2P는 연결 구조를 뜻하므로 ‘P2P 서버’보다는 P2P 방식이라고 부르는 편이 정확하다. 연결 구조와 판정 권한은 별개의 선택이다. 예를 들어 리슨 서버에서는 호스트에게 최종 판정권을 줄 수 있다.
| 판정 권한 | 방식 | 주요 특징 |
|---|---|---|
| 클라이언트 권한 | 각 클라이언트가 자신의 행동이나 상태를 판정한다. | 화면에 빠르게 반영할 수 있지만 다른 참여자가 그 결과를 얼마나 신뢰할지 정해야 한다. 조작에 취약할 수 있다. |
| 전용 서버 권한 | 별도 서버가 결과를 최종 판정한다. | 공통 규칙을 적용하고 검증하기 좋다. 클라이언트는 서버의 응답을 기다려야 할 수 있다. |
| 호스트 권한 | 리슨 서버의 호스트 플레이어가 최종 판정한다. | 한곳에서 상태를 관리할 수 있지만 호스트의 지연·접속 종료·조작 가능성을 고려해야 한다. |
| P2P에서 분산된 권한 | 각 참여자가 맡은 상태를 판정하거나 합의한다. | 단일 판정 지점이 없으므로 충돌 해결과 신뢰 규칙이 더 중요해진다. P2P라고 해서 반드시 이 방식이어야 하는 것은 아니다. |
아래 방법들은 서로 배타적인 서버 모델이 아니다. 한 게임에서 함께 사용할 수 있다.
| 방법 | 무엇을 하는가 | 예 |
|---|---|---|
| 상태 동기화(State Sync) | 변하는 상태 값을 다른 참여자에게 전달한다. | 위치, 체력, 점수 |
| RPC | 사건이 발생했을 때 다른 참여자에게 실행할 동작을 요청한다. | 공격 효과, 문 열기 |
| 스냅샷(Snapshot) | 특정 시점의 필요한 게임 상태를 묶어 기록하거나 전송한다. | 상태 복원, 리플레이, 롤백 |
| 예측(Prediction) | 권한 있는 쪽의 응답을 받기 전에 결과를 먼저 화면에 반영한다. | 이동 입력을 즉시 표시한 뒤 서버 결과에 맞춰 보정 |
예를 들어 이동 게임에서는 클라이언트가 예측으로 캐릭터를 즉시 움직이고, 서버가 판정한 상태를 받은 뒤 차이가 있으면 보정할 수 있다. 공격이 발생했다는 사건은 RPC 형태로 알리고, 필요한 시점의 스냅샷을 보관해 상태를 복원할 수도 있다. 무엇을 얼마나 자주 보낼지는 데이터의 중요도와 허용할 수 있는 지연에 따라 결정한다.
새 글이 올라오면 Develog 알림으로 알려드려요
댓글을 작성하려면 로그인이 필요합니다.
Develog는 단순히 글을 쓰는 공간이 아닙니다. 성장의 과정을 기록하고, 그 기록으로 나를 증명하며 원하는 기회를 얻는 곳이길 바랐습니다. 누군가의 꿈으로 향하는 중간다리가 되는 것, 그것이 Develog를 만든 이유입니다.
게임업계 취업을 준비하다 보면 조금 불편한 현실을 마주하게 됩니다. 게임회사에 들어가고 싶은 사람은 많습니다. 특히 신입 채용은 더 그렇습니다. 공고 하나에 많은 지원자가 몰리고, 회사 입장에서는 비슷한 조건의 지원자 가운데 사람을 선택할 수 있습니다. 그래서 다른 산업에서 흔히 이야기하는 “처음부터 연봉을 낮춰 부르지 마세요.” “적극적으로 협상하세요.”
우리들의 게임 발매 이야기
Develog는 단순히 글을 쓰는 공간이 아닙니다. 성장의 과정을 기록하고, 그 기록으로 나를 증명하며 원하는 기회를 얻는 곳이길 바랐습니다. 누군가의 꿈으로 향하는 중간다리가 되는 것, 그것이 Develog를 만든 이유입니다.
게임업계 취업을 준비하다 보면 조금 불편한 현실을 마주하게 됩니다. 게임회사에 들어가고 싶은 사람은 많습니다. 특히 신입 채용은 더 그렇습니다. 공고 하나에 많은 지원자가 몰리고, 회사 입장에서는 비슷한 조건의 지원자 가운데 사람을 선택할 수 있습니다. 그래서 다른 산업에서 흔히 이야기하는 “처음부터 연봉을 낮춰 부르지 마세요.” “적극적으로 협상하세요.”
알쏭달쏭 디지털 세상... 저도 공부할때 도움 많이 되었던 링크 공유드립니다! 여기 설명 정말 잘해주어서 한번 보시면 도움 많이 되실겁니다! https://youtu.be/1pfTxp25MA8?si=qDl4Pl4qadbYeYt4 이후 고급편으로는.. https://www.youtube.com/watch?v=k1gyh9BlOT8&list=PLXvgR_grOs1BFH-TuqFsfHqbh-gpMbFoy 여기 추천드립니다..
감사합니다! 공부하면서 같이 보겠습니다!