[CSAPP 11장 완전 정복] 11.4(Part 1) 소켓 함수 흐름 완전정복, 클라이언트-서버 연결의 모든 것

소켓 함수 흐름 완전정복, 클라이언트-서버 연결의 모든 것

이번 포스트에서는 소켓 프로그래밍의 핵심 흐름인 socket() → connect()/bind() → listen() → accept() 과정을 전체적으로 잡고 가려고 하는데요. 이 흐름이 머릿속에 들어오면, 이후 나올 Tiny Web Server의 코드가 '왜 이렇게 구성되었는지'가 명확히 보이게 됩니다.

 

 

클라이언트 vs 서버, 연결 흐름의 차이

클라이언트 측

1. socket(): 통신의 엔드포인트 소켓 생성
2. connect(): 서버 IP와 포트를 지정해 연결 요청

연결이 성공되면 이 소켓은 이제 데이터를 주고받을 수 있게 됩니다.

 

서버 측

1. socket(): 통신의 엔드포인트 소켓 생성
2. bind(): 해당 소켓을 포트에 바인딩 (IP + Port)
3. listen(): 연결 요청을 받을 준비
4. accept(): 클라이언트가 들어오면 연결을 수락하고, 새로운 소켓 생성

서버는 이 과정을 반복하면서 여러 클라이언트를 처리하게 됩니다.

 

 

소켓 함수 하나하나, 어떤 역할을 할까?

• socket(): 통신을 위한 기본 소켓 핸들 생성. 아직 연결이 안 된 상태
• connect(): 클라이언트 → 서버로 연결 시도 (blocking, )
• bind(): OS에게 "이 포트로 오는 요청 내가 받을게요"라고 알림
• listen(): 서버로서 연결 요청 대기 모드로 전환
• accept(): 실제 연결 수락. 새로운 통신 소켓을 반환함

이 함수들의 호출 순서와 개념을 명확히 이해하는 것이 매우 중요합니다.

 

 

CSAPP이 제공하는 예제 함수들, open_clientfd() & open_listenfd()

open_clientfd()

• getaddrinfo()로 받은 주소 리스트를 순회하며 connect()가 성공할 때까지 시도
• clientfd는 성공한 연결 소켓을 반환하며, 실패 시 -1을 리턴

 

open_listenfd()

• 서버 포트를 listen 모드로 열어두고, bind()/listen()이 성공할 때까지 시도
• listenfd는 연결 요청을 받을 수 있는 서버 소켓을 반환

이외에도 setsockopt()으로 포트 재사용을 허용하는 것 등도 놓치면 안될 요소 중 하나입니다.

 

 

accept(), 진짜 통신이 시작되는 지점

accept()는 blocking 함수 중 하나인데요. 누군가 연결 요청을 하기 전까치 대기하다가 요청이 들어오면 그제서야 리턴되며, 이때 새로운 connfd를 생성합니다. 즉, listen 소켓은 계속 유지되고, 매 연결마다 새로운 소켓이 만들어지는 구조이지요.

 

 

다중 클라이언트 처리 전략

CSAPP에서는 서버의 클라이언트 처리 방식으로 네 가지 모델을 소개하고 있습니다.

• 반복 루프: 순차적으로 하나씩 처리. 구현은 간단하지만 병렬 처리 불가
• fork(): 각 연결마다 프로세스 생성 (멀티프로세싱)
• pthread_create(): 각 연결마다 스레드 생성 (멀티스레딩)
• select(): 이벤트 기반 I/O 멀티플렉싱

 

마치며

이번 포스트에서는 소켓 프로그래밍의 기본 흐름을 잡아보았는데요. 클라이언트가 어떻게 연결을 요청하고, 서버가 이를 수락하는지를 이해하면, 다음 포스트에서 다룰 struct sockaddr_in, getaddrinfo() 같은 구조체들이 어떤 역할을 하는지 훨씬 빠르게 체감할 수 있을 것이라 생각합니다.

 

다음 편에서는 주소 정보 구조체와 도메인/IP 변환, 그리고 네트워크 주소 체계를 다뤄볼 예정입니다. 감사합니다!