웹 캐시는 자주 쓰이는 문서의 사본을 자동으로 보관하는 HTTP 장치다. 웹 요청이 캐시에 도착했을 때, 캐시된 로컬 사본이 존재한다면, 그 문서는 원 서버가 아니라 그 캐시로부터 제공된다.
캐시는 불필요한 데이터 전송을 줄여서, 네트워크 요금으로 인한 비용을 줄여준다.
캐시는 네트워크 병목을 줄여준다. 대역폭을 늘리지 않고도 페이지를 빨리 불러 올 수 있게 된다.
캐시는 원 서버에 대한 요청을 줄여준다. 서버는 부하를 줄일 수 있으며 더 빨리 응답할 수 있게 된다.
페이지를 먼 곳에서 불러올수록 시간이 많이 걸리는데, 캐시는 거리로 인한 지연을 줄여준다.
대역폭 병목
캐시는 또한 네트워크 병목을 줄여준다. 많은 네트워크가 원격 서버보다 로컬 네트워크 클라이언트에 더 넓은 대역폭을 제공한다. 클라이언트들이 서버에 접근할 때의 속도는, 그 경로에 있는 가장 느린 네트워크의 속도와 같다. 만약 클라이언트가 빠른 LAN에 있는 캐시로부터 사본을 가져온다면, 캐싱은 성능을 대폭 개선할 수 있을 것이다(특히 큰 문서들에 대해).
캐시는 대역폭으로 인한 병목을 개선할 수 있다.
위 그림처럼 애틀란타 본사로부터 5MB 크기의 물품 목록 파일을 받는데 30초가 걸릴 수 있다. 만약 문서가 샌프란시스코의 사무실에 캐시되어 있다면, 로컬 사용자는 같은 문서를 이더넷 접속을 통해 1초 미만의 시간에 가져올 수 있다. 대역폭은 큰 문서에 대해 현저한 지연을 일으키며, 속도는 네트워크 종류의 차이에 따라 극적으로 달라진다.
갑작스런 요청 쇄도(Flash Crowds)
캐싱은 갑작스런 요청 쇄도에 대처하기 위해 특히 중요하다. 갑작스런 사건으로 인해 많은 사람이 거의 동시에 웹 문서에 접근할 때 이런 일이 발생한다. 이 결과로 초래된 불필요한 트래픽 급증은 네트워크와 웹 서버의 심각한 장애를 일으킬 수 있다.
웹 서버는 매일 수십억 개의 웹페이지를 쏟아 낸다. 웹서버는 당신에게 날씨를 알려주고, 온라인 쇼핑 카트에 물건을 싣고, 오랫동안 만나지 못했던 고등학교 친구를 찾을 수 있게 해준다. 웹 서버는 월드 와이드 웹의 일꾼이다.
웹 서버가 하는 일
커넥션을 맺는다 -- 클라이언트의 접속을 받아들이거나, 원치 않는 클라이언트라면 닫는다.
요청을 받는다 -- HTTP 요청 메시지를 네트워크로부터 읽어 들인다.
요청을 처리한다 -- 요청 메시지를 해석하고 행동을 취한다.
리소스에 접근한다 -- 메시지에서 지정한 리소스에 접근한다.
응답을 만든다 -- 올바른 헤더를 포함한 HTTP 응답 메시지를 생성한다.
응답을 보낸다 -- 응답을 클라이언트에게 돌려준다.
트랜잭션을 로그로 남긴다 -- 로그파일에 트랜잭션 완료에 대한 기록을 남긴다.
기본 웹 서버 요청의 단계
단계 1 : 클라이언트 커넥션 수락
클라이언트가 이미 서버에 대해 열려있는 지속적 커넥션을 갖고 있다면, 클라이언트는 요청을 보내기 위해 그 커넥션을 사용할 수 있다. 그렇디 않다면, 클라이언트는 서버에 대한 새 커넥션을 열 필요가 있다.
클라이언트가 웹 서버에 TCP 커넥션을 요청하면, 웹 서버는 그 커넥션을 맺고 TCP 커넥션에서 IP 주소를 추출하여 커넥션 맞은편에 어떤 클라이언트가 있는지 확인한다.
웹 서버는 어떤 커넥션이든 마음대로 거절하거나 즉시 닫을 수 있다.
단계 2 : 요청 메시지 수신
커넥션에 데이터가 도착하면, 웹 서버는 네트워크 커넥션에서 그 데이터를 읽어 들이고 파싱하여 요청 메시지를 구성한다.
요청 메시지를 파싱할 때, 웹 서버는 다음과 같은 일을 한다.
요청줄을 파싱하여 요청 메서드, 지정된 리소스의 식별자(URI), 버전 번호를 찾는다.
메시지 헤더들을 읽는다. 각 메시지 헤더는 CRLF로 끝난다.
헤더의 끝을 의미하는 CRLF로 끝나는 빈 줄을 찾아낸다.
요청 본문이 있다면, 읽어 들인다.
요청 메시지를 파싱할 때, 웹 서버는 입력 데이터를 네트워크로부터 불규칙적으로 받는다.
단계 3 : 요청 처리
웹 서버가 요청을 받으면, 서버는 요청으로부터 메서드, 리소스, 헤더, 본문을 얻어내어 처리한다.
단계 4 : 리소스의 매핑과 접근
웹 서버는 리소스 서버다. HTML 페이지나 JPEG 이미지 같은 미리 만들어진 콘텐츠를 제공하며, 마찬가지로 서버 위에서 동작하는 리소스 생성 애플리케이션을 통해 만들어진 동적 콘텐츠도 제공한다.
웹 서버가 클라이언트에 콘텐츠를 전달하려면, 그전에 요청 메시지의 URI에 대응하는 알맞은 콘텐츠나 콘텐츠 생성기를 웹 서버에서 찾아서 그 콘텐츠의 원천을 식별해야 한다.
요청 URI를 local 웹 서버 리소스에 매핑
단계 5 : 응답 만들기
한번 서버가 리소스를 식별하면, 서버는 요청 메서드로 서술되는 동작을 수행한 뒤 응답 메시지를 반환한다. 응답 메시지는 응답 상태 코드, 응답 헤더, 그리고 응답 본문을 포함한다. 응답 메시지는 주로 다음을 포함한다.
응답 본문의 MIME 타임을 서술하는 Content-Type 헤더
응답 본문의 길이를 서술하는 Content-Length 헤더
실제 응답 본문의 내용
MIME 타입 목록 파일
단계 6 : 응답 보내기
서버는 여러 클라이언트에 대한 많은 커넥션을 가질 수 있다. 그들 중 일부는 아무것도 안하고 있는 상태고, 일부는 서버로 데이터를 보내고 있으며, 또 다른 일부는 클라이언트로 돌려줄 응답 데이터를 실어 나르고 있을 것이다. 서버는 커넥션 상태를 추적해야 하며 지속적인 커넥션은 특별히 주의해서 다룰 필요가 있다. 비지속적인 커넥션이라면, 서버는 모든 메시지를 전송했을 때 자신쪽의 커넥션을 닫을 것이다
단계 7 : 로깅
트랜잭션이 완료되었을 때 웹 서버는 트랜잭션이 어떻게 수행되었는지에 대한 로그를 로그파일에 기록한다. 대부분의 웹 서버는 로깅에 대한 여러 가지 설정 양식을 제공한다.
