HomeAboutMeBlogGuest
© 2025 Sejin Cha. All rights reserved.
Built with Next.js, deployed on Vercel
📖
공부한 책
/
1%의 네트워크 원리
1%의 네트워크 원리
/6장 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아 간다/
서버의 개요

서버의 개요

서버 애플리케이션의 구조동작 순서서버 애플리케이션 Socket 라이브러리 호출 개요클라이언트 Socket 라이브러리 호출 순서서버 측 Socket 라이브러리 호출 순서accept 동작에서 소켓 관리

서버 애플리케이션의 구조

notion image
  • 서버는 동시에 복수의 클라이언트와 통신동작을 실행하지만, 하나의 프로그램으로 여러 클라이언트 들의 상대를 처리하기는 어려움 → 클라이언트가 접속할 때마다 새로 서버 프로그램을 작동하여 서버 애플리케이션이 클라이언트와 1 대 1로 대화함
  • 서버 프로그램을 만듬 - 아래와 같이 둘로 나누어 만듬
    • 접속을 기다리는 부분
    • 클라이언트와 대화하는 부분 — multiprocessing, multithreading
  • 이 방법은 클라이언트가 접속했을 때 새로 프로그램을 기동하는 것이 다소 시간이 걸리고, 응답 시간이 추가로 소요된다는 단점이 있음
    • 미리 클라이언트와 대화하는 몇 개의 부분을 작동시켜 두고(ThreadPool, ProcessPool) 클라이언트가 접속 시 비어있는 것을 찾아 여기에 접속한 소켓을 건네주어 통신하게 할 수도 있음

동작 순서

  1. 서버 프로그램을 작동해서 설정 파일 읽기 등의 초기화 동작
  1. 접속을 기다리는 부분 실행
      • 소켓을 작성하고, 소켓을 클라이언트에서의 접속 동작을 기다리는 상태로 만든 채 쉬는 상태가 됨
  1. 클라이언트가 접속을 하게 되면 클라이언트와 대화하는 부분을 작동시켜, 그곳에 접속이 끝난 소켓을 건네줌
      • 여기에서 멀티프로세싱 or 멀티쓰레딩의 개념이 이용됨
  1. 패킷을 주고 받은 후, 연결을 끊고 이 부분(클라이언트와 대화하는 부분) 종료함

서버 애플리케이션 Socket 라이브러리 호출 개요

클라이언트 Socket 라이브러리 호출 순서

  1. 소켓 작성
  1. 서버측의 소켓과 파이프로 연결(접속 단계)
  1. 데이터를 송.수신함(송.수신 단계)
  1. 파이프를 분리하고 소켓을 말소(연결 끊기 단계)

서버 측 Socket 라이브러리 호출 순서

  1. 소켓 작성 — socket
  1. 접속을 기다리는 형태
    1. 소켓을 접속 대기 상태로 만듬(접속 대기 상태)
    2. 접속을 접수합니다(접속 접수 단계)
  1. 데이터를 송.수신 (송.수신 단계)
  1. 파이프를 분리하고 소켓을 말소(연결 끊기 단계)
notion image
  1. socket 호출하여 소켓 만듬
      • 소켓을 만드는 동작이 프로토콜 스택에 메모리를 확보하는 것
      • 프로토콜 스택에 소켓 일람표 정보가 있음
  1. bind 를 호출하여 포트 번호를 기록함
  1. 포트 번호 기록 후 listen을 호출하여 소켓에 접속하기를 기다리는 상태라는 제어 정보를 기록함
  1. accept를 실행하여 접속을 접수동작을 실행함(패킷이 도착하지 않았는데도 그냥 서버 애플리케이션이 기동된 후 바로 실행함)
    1. ⇒ accept 를 실행한 시점에서 보통 서버측은 패킷의 도착을 기다리는 상태가 되고, 애플리케이션은 쉬는 상태가 됨
      • 이 상태에서 애플리케이션에서 접속 패킷이 도착하면 응답 패킷을 반송하여 접속 접수 동작을 실행함

accept 동작에서 소켓 관리

notion image
  • 접속 대기의 소켓을 복사하여 새로운 소켓을 만들고, 접속 상대의 정보를 비롯한 제어 정보를 새 소켓에 기록
  • 클라이언트 측과 대화하는 소켓은 복사되어 만들어진 새로운 소켓이므로 걔는 대화가 끝나면 없어지지만, 접속 대기 상태의 소켓은 계속 접속 대기상태임
    • 그래서 다시 accept를 호출하면 접속 대기 상태의 소켓을 복사하여 새 소켓을 만들고 얘를 클라이언트 측의 소켓과 접속. 원래 소켓은 그대로 접속 대기 상태인 채로 둠
    • 이렇게 잇달아 복사하여 새 소켓을 만드는 부분이 요점임
  • 새 소켓을 만들 때 포트 번호도 요점인 것이, 다 똑같은 포트 번호로 새 소켓이 복사되어 만들어진다면, 포트 번호 만으로는 소켓을 지정할 수가 없게 된다는 점
    • 따라서 소켓을 지정할 때 네가지 정보를 사용함
      • 클라이언트 측의 IP 주소
      • 클라이언트 측의 포트 번호
      • 서버 측의 IP 주소
      • 서버 측의 포트 번호
    • 위 4가지 정보를 활용하면 다른 클라이언트가 같은 포트 번호를 사용하더라도 클라이언트 IP 주소를 통해서 식별이 가능하고, 단 하나의 소켓을 특정할 수 있게 됨
    • 이 4가지 정보를 디스크립터 대신 사용할 수 있을까? NO. 접속 대기 상태인 소켓은 클라이언트 측의 IP 주소와 포트번호를 알 수 없기 때문에
    • 💡
      소켓을 식별하기 위해 디스크립터를 사용하는 이유 - 접속 대기의 소켓에는 클라이언트 측의 IP 주소와 포트 번호가 기록되어 있지 않기 때문 - 디스크립터라는 한 개의 정보로 식별하는 쪽이 간단하기 때문