네트워크에서 Sever 와 Client의 관계 (Initiator & Listener) 정리

서버와 클라이언트를 구분하는 기준

네트워크에서 서버(Server) 와 클라이언트(Client) 는
연결(Connection)을 누가 먼저 시작(Initiate)했는가에 따라 결정된다.

 

연결을 시작/요청한 주체는 클라이언트가 되고
반대로 그 연결을 수락/응답하는 대상이 서버가 되는 셈이다. 

 

 

예를 들어 A와 B가 HTTP 연결을 맺는다고 하자.

• A가 B에게 연결을 요청했다면 → A는 클라이언트 (Initiator)
• 그 요청을 받는 B는 → 서버 (Listener)

이처럼 서버와 클라이언트의 역할은 고정된 것이 아니라, 연결 관계에 따라 유동적으로 바뀐다.
즉, A가 항상 클라이언트이고 B가 항상 서버인 것은 아니다.

---

사용자와 브라우저

사람(사용자)은 화면을 바라보지만 네트워크 연결을 직접 시작하지 않는다.

• 사용자 관점 → 요청을 시작하는 주체이므로 ‘클라이언트’라 할 수 있다.
• 네트워크 관점 → 실제 연결을 시작하지 않으므로 ‘클라이언트’가 아니다.

네트워크에서의 클라이언트는 웹 브라우저와 그 안의 화면이다.
왜냐하면 HTML, CSS, JS 등 브라우저 리소스들이 서버로 HTTP나 웹소켓 연결을 요청하기 때문이다.

---

WEB – Middleware – WAS 구조

일반적인 구조는 다음과 같다.

 

USER → WEB(브라우저) → Middleware(Nginx) → WAS(백엔드 서버)

Nginx(미들웨어)의 역할

• Reverse Proxy (리버스 프록시)
  클라이언트 요청을 대신 받아 실제 WAS로 전달하고, 응답을 다시 클라이언트에 돌려준다.
  클라이언트는 직접 WAS를 알 필요 없이 Nginx만 알면 된다.
• Load Balancer (로드 밸런서)
  여러 대의 WAS가 있을 때 트래픽을 분산시켜 성능과 안정성을 높인다.
• 그 외 장점
  SSL 처리, 보안 강화 등.

Nginx는 서버인가, 클라이언트인가?

• Frontend 입장 → Nginx는 연결을 받는 쪽이므로 서버
• WAS 입장 → Nginx가 연결을 시작하므로 클라이언트

따라서 Nginx는 서버이자 클라이언트이다.

---

WAS와 BG(백그라운드) 서버

WAS 뒤에 BG 서버가 있고 웹소켓을 통해 연결을 한다고 가정해보자.

• WAS ↔ BG
  • WAS가 BG에 연결을 시작 → WAS는 클라이언트, BG는 서버
• BG ↔ 장비(기계)
  • 장비가 BG에 연결 요청 → 장비는 클라이언트, BG는 서버

---

WAS와 DB

DB는 보통 수동적으로 연결을 받는 쪽이다.

• WAS나 BG가 DB에 연결 요청을 시작 → DB는 서버
• DB가 직접 연결을 시작하는 경우는 거의 없다.

데이터가 양방향으로 오가더라도, 누가 연결을 시작했는지가 서버/클라이언트를 가르는 기준이다.

---

WAS와 Web Push Server

만약 WAS에 별도의 Web Push Server가 붙어 있다면,

• WAS ↔ Web Push Server
  • Push Server는 요청을 받아들이므로 서버
  • WAS는 연결을 시작했으므로 클라이언트
• BG ↔ Web Push Server
  • BG가 연결을 시작 → BG는 클라이언트, Push Server는 서버
  • 이후 Push Server는 BG의 알림(Notification)을 받아 WAS에 브로드캐스트한다.

---

핵심 정리

1. 서버/클라이언트 구분 기준 = 연결을 누가 시작했는가
2. 역할은 고정적이지 않고 상황에 따라 변한다.
3. Nginx, WAS, BG, DB, Push Server 모두 맥락에 따라 서버이자 클라이언트가 될 수 있다.