소켓 통신

왜 배우는가: 소켓 통신은 클라이언트-서버 구조, 실시간 웹 서비스, 네트워크 프로그래밍의 기반이다. 실무에서 채팅·알림·시세 서비스를 설계할 때 HTTP와 무엇을 쓸지 판단하는 근거가 된다. 기출에서 정의, 유형, HTTP 비교가 함께 묻는 문항으로 반복 출제되었다.

출제 이력: 제131회 2교시 5번, 제116회 3교시 6번

1. 한 줄 정의와 핵심 키워드

소켓 통신은 IP 주소와 포트 번호로 식별되는 소켓을 통해 프로세스 간에 데이터를 주고받는 통신 방식이다

• 소켓(Socket): 네트워크 통신의 종단점으로, 응용 프로그램이 프로토콜 스택을 사용하는 인터페이스다.
• 종단점(Endpoint): 통신 양쪽 끝에 각각 하나씩 존재하는 소켓 자체를 가리킨다.
• 소켓 주소: 로컬 IP 주소와 포트 번호의 조합이다.
• 클라이언트-서버 모델: 서버가 리스닝 소켓으로 요청을 기다리고, 클라이언트가 연결을 청하는 구조다.
• 전이중(Full-duplex) 통신: 양방향으로 동시에 데이터를 주고받는 방식이다.
• 소켓 API: 프로그램이 프로토콜 스택과 통신할 때 호출하는 응용 프로그램 인터페이스다.
• 버클리 소켓(Berkeley Sockets): 인터넷 소켓 API가 대체로 따르는 표준이다.
• TCP 소켓: 연결지향으로 신뢰성 있는 전송을 제공하는 소켓이다.

2. 개념 풀이

쉬운 말로 설명하면 소켓 통신은 전화 통화와 같다. 전화 번호에 해당하는 것이 IP 주소이고, 내선 번호에 해당하는 것이 포트 번호다. 두 사람이 번호로 연결되어 말을 주고받듯이, 두 프로세스가 소켓 주소로 연결되어 데이터를 주고받는다.

정식 정의는 다음과 같다. 소켓은 네트워크 프로토콜 스택이 제공하는 종단점이다. 응용 프로그램은 소켓 API를 호출하여 소켓을 생성하고, 연결하고, 데이터를 송수신한다. 인터넷 소켓은 로컬 IP 주소와 포트 번호로 특징지어지며, 운영체제는 이 소켓 주소를 기준으로 들어온 패킷을 해당 응용 프로세스에 전달한다.

핵심 용어는 세 가지다. 소켓 API는 프로그램과 프로토콜 스택 사이의 인터페이스이며, 이를 사용해 응용 프로그램을 작성하는 일을 소켓 프로그래밍이라고 부른다. 전이중 통신은 양방향 동시 전송을 뜻한다. 한 번 설정된 연결 위에서 양쪽이 언제든 보낼 수 있다. 셋째, 소켓은 유닉스의 ‘모든 것은 파일이다’ 철학에 따라 파일 서술자의 한 형태로 구현된다. 읽기·쓰기·열기·닫기 기능을 가진다는 점은 파일과 같지만, 송신과 수신에 별도 함수(send, receive)를 쓰는 점이 다르다.

연결 상태도 중요하다. TCP 서버는 리스닝 소켓으로 연결을 받은 뒤, 클라이언트마다 고유한 소켓을 새로 만들어 여러 클라이언트를 동시에 처리한다. 반면 UDP 소켓은 연결을 설정하지 않으므로 상태를 가지지 않고, 하나의 소켓으로 여러 클라이언트의 데이터그램을 차례로 받는다.

3. 등장 배경과 필요성

HTTP는 요청과 응답이 한 번씩 오가는 구조다. 클라이언트가 먼저 요청하지 않으면 서버는 데이터를 보낼 수 없다. 초기 웹 문서 조회에는 충분했지만, 실시간 데이터가 늘면서 여러 한계가 드러났다.

첫째는 반이중 통신 문제다. HTTP는 한 번에 한 방향으로만 통신하는 반이중(half-duplex) 방식이며, 서버가 먼저 데이터를 보낼 수 없다. 이를 우회하려고 클라이언트가 주기적으로 서버에 묻는 폴링(polling) 방식을 썼다. 폴링은 요청 횟수만큼 연결과 헤더가 반복되어 부하와 지연을 키운다.

둘째는 연결 비용이다. 요청이 올 때마다 새 연결이 만들어지므로 수백 번의 요청이 반복되는 환경에서는 지연 시간이 커진다. 일반 웹 조회에는 지속 연결이 필요 없어 HTTP가 적합하지만, 짧은 메시지가 자주 오가는 경우에는 비효율이 뚜렷하다.

셋째는 헤더 오버헤드다. HTTP는 매 요청마다 헤더를 실어 보내므로, 메시지가 작을수록 헤더가 차지하는 비중이 커진다. 채팅이나 주식 시세처럼 짧은 데이터가 빈번히 오가는 서비스에서 낭비가 크다.