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

- 서버는 동시에 복수의 클라이언트와 통신동작을 실행하지만, 하나의 프로그램으로 여러 클라이언트 들의 상대를 처리하기는 어려움 → 클라이언트가 접속할 때마다 새로 서버 프로그램을 작동하여 서버 애플리케이션이 클라이언트와 1 대 1로 대화함
- 서버 프로그램을 만듬 - 아래와 같이 둘로 나누어 만듬
- 접속을 기다리는 부분
- 클라이언트와 대화하는 부분 — multiprocessing, multithreading
- 이 방법은 클라이언트가 접속했을 때 새로 프로그램을 기동하는 것이 다소 시간이 걸리고, 응답 시간이 추가로 소요된다는 단점이 있음
- 미리 클라이언트와 대화하는 몇 개의 부분을 작동시켜 두고(ThreadPool, ProcessPool) 클라이언트가 접속 시 비어있는 것을 찾아 여기에 접속한 소켓을 건네주어 통신하게 할 수도 있음
동작 순서
- 서버 프로그램을 작동해서 설정 파일 읽기 등의 초기화 동작
- 접속을 기다리는 부분 실행
- 소켓을 작성하고, 소켓을 클라이언트에서의 접속 동작을 기다리는 상태로 만든 채 쉬는 상태가 됨
- 클라이언트가 접속을 하게 되면 클라이언트와 대화하는 부분을 작동시켜, 그곳에 접속이 끝난 소켓을 건네줌
- 여기에서 멀티프로세싱 or 멀티쓰레딩의 개념이 이용됨
- 패킷을 주고 받은 후, 연결을 끊고 이 부분(클라이언트와 대화하는 부분) 종료함
서버 애플리케이션 Socket 라이브러리 호출 개요
클라이언트 Socket 라이브러리 호출 순서
- 소켓 작성
- 서버측의 소켓과 파이프로 연결(접속 단계)
- 데이터를 송.수신함(송.수신 단계)
- 파이프를 분리하고 소켓을 말소(연결 끊기 단계)
서버 측 Socket 라이브러리 호출 순서
- 소켓 작성 — socket
- 접속을 기다리는 형태
- 소켓을 접속 대기 상태로 만듬(접속 대기 상태)
- 접속을 접수합니다(접속 접수 단계)
- 데이터를 송.수신 (송.수신 단계)
- 파이프를 분리하고 소켓을 말소(연결 끊기 단계)

- socket 호출하여 소켓 만듬
- 소켓을 만드는 동작이 프로토콜 스택에 메모리를 확보하는 것
- 프로토콜 스택에 소켓 일람표 정보가 있음
- bind 를 호출하여 포트 번호를 기록함
- 포트 번호 기록 후 listen을 호출하여 소켓에 접속하기를 기다리는 상태라는 제어 정보를 기록함
- accept를 실행하여 접속을 접수동작을 실행함(패킷이 도착하지 않았는데도 그냥 서버 애플리케이션이 기동된 후 바로 실행함)
- 이 상태에서 애플리케이션에서 접속 패킷이 도착하면 응답 패킷을 반송하여 접속 접수 동작을 실행함
⇒ accept 를 실행한 시점에서 보통 서버측은 패킷의 도착을 기다리는 상태가 되고, 애플리케이션은 쉬는 상태가 됨
accept 동작에서 소켓 관리

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