[1%의 네트워크 원리] 6장 : 웹 서버에 도착하여 응답 데이터가 웹 브라우저로 돌아간다

STORY 1. 서버의 개요

1. 클라이언트와 서버의 차이점

• 서버 머신은 하드웨어나 OS 부분에서 클라이언트와 다를 수 있다
• 그러나 LAN 어댑터, 프로토콜 스택, socket 라이브러리 등은 전혀 다르지 않음
• 하지만 사용법은 조금 다를 수 있음

2. 서버 애플리케이션의 구조

• 하나의 프로그램으로 여러 클라이언트와 소통하기는 어려움
• 그래서 서버 프로그램으로의 접속을 기다리는 부분, 클라이언트와 소통하는 부분 두 부분으로 나눔
• 클라이언트가 접속 요청 시 접속 기다리는 부분에서 소통하는 부분으로 소켓을 넘겨줌
• 클라이언트는 결과적으로 하나의 태스트/스레드와 1대1로 소통하게 됨

3. 서버측의 소켓과 포트 번호

• 데이터를 송수신하는 입장에서는 클라이언트, 서버 개념이 없을 수도 있지만, 접속 동작을 수행할 때는 좌우 대칭으로 만들 수 없음 → 반드시 누군가는 접속을 기다려야 하고, 누군가는 접속을 해야함
  • 여기서 기다리는 입장이 서버, 연결하는 입장이 클라이언트
• 클라이언트 접속 동작
  1. 소켓 작성
  2. 서버측 소켓과 파이프로 연결
  3. 데이터 송수신
  4. 파이프 분리 및 소켓 말소
• 서버 접속 동작
  1. 소켓 작성
  2. 소켓 접속 대기 상태로 만들고 접속 접수
  3. 데이터 송수신
  4. 파이프 분리 및 소켓 말소
• 접속을 기다리는 부분 (서버)
  • socket → 소켓 작성
  • bind → 소켓에 포트 번호 기록 → HTTP 의 경우 80번
  • listen → 소켓 접속 대기 상태로 만듦
  • accept → 접속 접수
  • 클라이언트 접속을 접수하면 태스크, 스레드를 새로 생성하여 클라이언트와 대화하는 부분을 생성하고 accept 단계로 돌아감
• 문제 발생
  • 포트 번호는 본래 소켓을 식별하기 위한 것임 → 근데 80번 포트로 이미 접속 접수 소켓을 사용하는데, 대화 부분의 소켓 또한 반드시 80번으로 해야 문제가 발생하지 않음 → 소켓 식별 불가
    • 클라이언트 IP 주소, 클라이언트 측 포트 번호, 서버측 IP 주소, 서버 측 포트 번호 4가지 정보를 활용하면 가능
    • 그렇다면 이 방식을 쓰면 디스크립터가 필요없는데?
      • 소켓을 만든 직후에는 이 네가지 정보가 없기 때문에 사용 불가능
      • 그래서 디스크립터로 소켓 식별함

STORY 2. 서버의 수신 동작

1. LAN 어댑터에서 수신 신호를 디지털 데이터로 변환한다

생략

2. IP 담당 부분의 수신 동작

• IP 헤더를 점검
• 자신이 대상인지 판단함
• 조각 나누기로 분할된 패킷인지 확인 → 분할된거면 메모리에 임시 저장 후 전부 도착하면 합침
• IP 헤더의 프로토콜 번호 항목을 조사한 후 해당 프로토콜 담당으로 보내줌

3. TCP 담당 부분이 접속 패킷을 수신했을 때의 동작

• SYN 플래그가 1일 때 동작
• SYN 컨트롤 비트 확인
• 수신처 포트 번호 확인
• 해당 접속 대기 소켓을 복사하여 새 소켓 작성
• 송신처의 IP 주소나 포트 번호 등 기록

4. TCP 담당 부분이 데이터 패킷을 수신했을 때의 동작

• 도착한 패킷의 송신처 IP, 송신처 포트, 수신처 IP, 수신처 포트로부터 해당 소켓을 판단
• 데이터 조각을 연결해서 수신 버퍼에 보관
• 클라이언트에 ACK 보냄

5. TCP 담당 부분의 연결 끊기 동작

• HTTP 1.0인 경우 서버에서 연결 끊기
• HTTP 1.1일 경우 클라이언트에서도 연결 끊기 가능 → 이 경우 서버에서 연결 끊은 경우와 정확히 반대 방향

STORY 3. 웹 서버 소프트웨어가 리퀘스트 메시지의 의미를 해석하여 요구에 응한다

1. 조회의 URI를 실제 파일명으로 변환한다

• URI에 있는 대로 읽어오면 디스크의 파일에 전부 액세스 가능해짐 → 가상의 디렉토리 구조를 만들고 이에 해당하는 실제 디렉토리의 경로명으로 변환한 후 파일 찾음

2. CGI 프로그램을 작동하는 경우

• 프로그램 파일 이름을 URI에 쓸 수 있음 → 이 경우 프로그램을 작동시켜 해당 프로그램이 출력하는 데이터를 클라이언트에 반송
• GET : URI 뒤에 입력 데이터를 내장 (쿼리 파라미터) / POST : 리퀘스트 메시지 바디에 데이터 내장해서 서버에 보냄

3. 웹 서버로 수행하는 액세스 제어

• 클라이언트 주소, 도메인명, 사용자명과 패스워드 3가지 조건으로 엑세스 제어
• 클라이언트의 도메인명으로 조건을 설정했을 떄는 DNS 서버에 IP 주소를 주고 도메인 명을 받아옴
  • DNS 서버는 도메인명 → IP 뿐만 아니라 IP → 도메인명 도 수행
  • 이를 체크하여 액세스 제어

STORY 4. 웹 브라우저가 응답 메시지를 받아 화면에 표시한다

1. 응답 데이터의 형식을 보고 본질을 판단한다

• Content-Type 헤더를 보고 데이터의 타입을 판단함

2. 브라우저 화면에 웹 페이지를 표시하여 액세스를 완료한다

• 생략

 

 

https://product.kyobobook.co.kr/detail/S000000559964