Index
1. 웹서버
1.1. 커넥션 수락
•
새 커넥션 생성
•
역방향 DNS (reverse DNS)
◦
클라이언트 IP → 클라언트 호스트 명으로 변환
◦
hostname lookup은 time consuming
◦
필요이유
▪
호스트명을 구체적인 접근 제어와 로깅을 위해 사용할 수 있음
•
ident 프로토콜을 통해 어떤 사용자가 HTTP 커넥션 초기화 했는지 확인 가능
1.2. 요청 메세지 수신
•
네트워크 커넥션에서 데이터 읽고 파싱 후 요청 메세지 구성
•
네트워크 커넥션은 언제든 무효화 가능
•
파싱 후 이해가 가능한 수준의 양 확보될 때까지 메시지 일부분을 메모리에 저장
•
요청 메세지 쉽게 다루기 위해 내부의 자료 구조 저장
•
커넥션 입/출력 처리 아키텍처
◦
단일 스레드 아키텍처
◦
멀티 프로세스와 멀티 스레드 아키텍처
◦
다중 I/O 아키텍처
◦
다중 멀티스레드 I/O 아키텍처
1.3. 요청 처리
•
메서드, 리소스, 헤더, 본문 얻어 처리
1.4. 리소스 맵핑 및 접근
•
docroot
◦
문서 루트
◦
특정 폴더를 웹 컨텍츠를 위해 예약
◦
특정 파일을 해당 폴더에 저장하여 리소스 맵핑 및 접근
•
directoryIndex
◦
디렉토리 URL에 대한 요청 처리
•
동적 컨텐츠 리소스 맵핑
•
SSI (서버사이드 인클루드)
1.5. 응답 생성
•
응답 엔티티
◦
Content-Type
▪
응답 본문의 MIME 타입 서술
▪
예) image/gif
◦
Content-Length
▪
응답 본문의 길이
▪
예) 8572
◦
실제 응답 본문 내용
•
리다이렉션
◦
3XX 응답
1.6. 응답 전송
•
지속적으로 커넥션 상태 추적 및 관리 필요
2. 프록시
2.1. 프록시 서버
•
서버와 클라이언트 사이 트랜잭션 수행 중개인
2.2. 프록시 서버 사용 예시
•
실용적이고 유용한 일들 수행
◦
보안 개선, 성능 향상, 비용 절약
•
필터링 프록시
◦
예) 성인 컨텐츠 차단
•
중앙 접근 제어 프록시
◦
문서 접근 제어
◦
클라이언트에 따라 접근 제어 가능
•
방화벽 프록시
◦
필터링 라우터 사이의 방화벽 프록시 사용
•
프록시 캐시
◦
웹 캐시
•
대리 프록시 (Surrogate)
◦
서버 가속기
◦
공용 컨텐츠에 대한 느린 웹서버 성능 개선을 위해 사용
◦
CDN?
•
컨텐츠 라우터
◦
트래픽 조건과 컨텐츠 종류에 따라 요청을 특정 웹서버로 유도
•
트랜스코더
◦
컨텐츠를클라이언트에 전달하기 전에 본문 포맷 수정
◦
데이터 표현 방식 변환
•
익명화 프록시 (Anonymizer)
◦
HTTP 신원 식별 가능한 특성드을 적극적으로 제거
▪
클라이언트 IP 주소, From 헤더, Refer 헤더, 쿠키, URL 세션 아이디
2.3. 프록시 서버 배치
•
출구(Egress) 프록시
◦
로컬 네트워크와 인터넷 사이에 오가는 트래픽 제어
◦
로컬 네트워크 출구에 프록시 위치
◦
용도
▪
회사 밖 해커 방화병 제공
▪
인터넷 요금 절약 및 인터넷 트래픽 성능 개선
•
접근(입구) 프록시
◦
ISP 접근 지점에 위치
◦
사용자들의 다운로드 속도 개선
◦
인터넷 대역폭 비용 절감
•
대리(리버스) 프록시
◦
네트워크 가장 끝에 있는 웹서버 바로 앞에 위치
◦
웹서버로 향하는 모든 요청을 처리하고 필요할때만 웹서버에 자원 요청
◦
보안 기능 추가, 성능 개선 가능
•
네트워크 교환 프록시
◦
네트워크 사이의 인터넷 피어링 교환 지점에 위치
◦
인터넷 교차로 혼잡 완화, 트래픽 흐름 감시
2.4. 프록시 계층
•
클라이언트와 웹서버 사이에 여러 프록시가 있는 경우 계층이라고 함
•
프록시들은 부모 자식 관계를 가짐
•
인바운드 프록시
◦
서버에 가까운 프록시
◦
부모 프록시
•
아웃바운드 프록시
◦
클라이언트에 가까운 프록시
◦
자식 프록시
•
프록시 계층의 종류
◦
정적 계층
◦
동적 계층 (동적 부모 선택)
▪
부하 균형
•
자식 프록시가 부하 분산을 위해 부모들의 작업량 수준에 근거해서 부모 프록시 선택
▪
지리적 인접성에 근거한 라우팅
•
자식프록시가 원 서버의 지역을 담당하는 부모 선택
▪
프로토콜/타입 라우팅
•
URI에 근거하여 다른 부모나 원서버로 라우팅
2.5. 프록시 트래픽 처리 방법
웹 요청을 프록시로 보내는 방법 (클라이언트 트래픽 → 프록시)
•
클라이언트 수정
◦
수동 설정
◦
브라우저 기본 설정
◦
PAC 파일 (프록시 자동 설정 파일)
▪
자바스크립트 함수로 적절한 프록시 서버 선택
▪
자바스크립트 PAC 파일의 URI를 브라우저에 설정 필요
◦
WPAD (웹 프록시 자동 발견 프로토콜)
▪
브라우저에 맞는 PAC 파일을 자동으로 찾아주는 알고리즘
•
네트워크 수정
◦
트래픽을 가로채어 프록시로 리다이렉트
◦
스위칭 장치, 라우팅 장치 사용
◦
인터셉터 프록시
•
DNS 이름 공간 수정 (대리 프록시)
◦
웹 서버의 이름 및 IP 주소를 프록시가 직접 사용
◦
DNS 이름 테이블 수동 편집 또는 동적 DNS 서버를 이용해 조정 가능
•
웹서버 수정
◦
HTTP 리다이렉션
◦
서버 → 클라이언트 → 프록시로 디이렉트
2.6 .프록시 요청 특징
•
프록시 URI는 서버 URI랑 다름
◦
클라이언트가 서버 대신 프록시로 보낼 때 요청 URI가 달라짐
◦
to 웹서버
▪
부분 URI 사용
▪
스킴, 호스트, 포트 번호가 없어도 전송 가능
◦
to 프록시서버
▪
완전한 URI 사용
•
가상 호스팅
◦
가상 호스팅 웹서버는 여러 웹서버가 물리적 웹서버 공유
◦
따라서 접근하고자 하는 웹사이트의 호스트명을 알 필요가 있음
◦
해결 방법
1.
명시적 프록시 사용
2.
호스트와 포트 정보가 담긴 Host 헤더를 웹서버가 요구
•
명시적 프록시
◦
완전한 URI 받음
•
리버스 프록시 (대리 프록시)
◦
원 서버의 호스트명, IP 주소를 사용해 원 서버를 대신하는 프록시 서버
◦
부분 URI를 받음
•
인터셉터 프록시
◦
네트워크 흐름에서 클라이언트 → 서버 트래픽을 가로채 캐시된 응답을 돌려주는 등의 역할을 수행
◦
부분 URI를 받음
•
완전 URI와 부분 URI 사용 규칙
◦
완전 URI → 프록시가 사용
◦
부분 URI + Host 헤더 → Host 헤더를 이용해 원서버 이름과 포트 넘버 탐색
◦
부분 URI + Host 헤더(x) →
▪
대리 프록시 → 프록시에 실제 서버 주소 및 포트 넘버 설정 되어 있을 수 있음
▪
인터셉터 프록시로 부터 온 트래픽 & 인터셉터 프록시에 실제 서버 주소 및 포트 넘버 사용가능하게 설정 → IP 주소 및 포트 번호 사용 가능
◦
위의 사용 규칙 모두 실패 → 에러 메세지 반환
•
전송중 URI 변경
◦
요청 URI 변경에 주의해야 함
•
URI 클라이언트 자동확장 및 호스트명 분석(Hostname Resolution)
◦
프록시 존재 여부에 따라 요청 URI 다르게 분석 진행
◦
프록시 없는 경우
▪
사용자가 입력한 URI로 IP 주소 찾음.
▪
호스트가 발견되면 그에 대응하는 IP 주소 연결 성공까지 시도
▪
호스트가 발견 되지 않으면, 호스트명 확장 제공을 위해 몇가지 시도 진행
2.7. 메세지 추적
•
프록시가 흔해지면서 프록시를 넘나드는 메시지 흐름을 추적하는 니즈가 발생
•
Via 헤더
◦
중간 노드 정보 나열
◦
예) Via: 1.1 proxy-62.xxx.net, 1.0 cache.joe-hardware.com
•
TRACE 메서드 (TRACE 요청)
◦
어던 프록시를 진가고 어떻게 각 프록시가 요청 메세지를 수정하는지 관찰 추적 가능
◦
프록시 흐름 디버깅에 유용
◦
TRACE 요청 시, 전체 요청 메세지를 HTTP 응답 메세지 본문에 포함시켜 송신자에게 그대로 전달