서버 성능 개선에 대한 개념들을 그림과 함께 간략히 설명한 자료입니다.

1. 서버 성능 개선
NHN NEXT 류우림

2. • 성능
- N계층 서버의 성능은 클라이언트를 제외한 서버군 전체가 상호작용하며,
클라이언트의 요청을 처리하는 능력이다.
- 서버의 성능이 전체 서비스의 품질 및 가용성을 좌우한다.
- 다양한 소프트웨어들이 인터넷을 통해 구동된다.
서버가 정상적으로 응답하지 못하면, 사용자의 어플리케이션도 사용불가.
• 어떤 성능을 측정하는가?
- 일반적으로 클라이언트 사용자 입장에서 서버에 대해 느끼는 성능이라하면, 속도와 응답시간.
- 서버 측 설계자 및 운영 담당자 입장에서는 얼마나 많은 사용자를 담당할 수 있는가? 라는
수용량에 대해 더 큰 관심을 가진다.
서버 ‘성능’ 이란

3. 1 웹서비스 요청에 대한 평균 응답 시간
2 단위 시간 당 로그인한 사용자 수
3 동시 사용자수
4 특정 시점에 실행 중인 서비스(요청) 개수
5 단위 시간당 처리 가능 요청 건수
웹서비스 성능 지표
웹 서비스의 성능은 응답 속도만을 판단해서는 안되며,
단위 시간 당 처리량을 중요한 지표로 판단해야 한다.
핵심 성능 지표
!
- 사용자에게 최적화된 서비스를 위해 ‘짧은 응답 시간’
- 서버의 안정적인 운영을 위한 ‘적절한 처리량’

4. Bandwidth Latency
대역폭과 대기시간
- 네트워크에서의 Latency 는 delay 와 비슷한 말로서,
하나의 데이터 패킷을 한 지점에서 다른 지점으로 보내는데 소요되는
시간을 표현한 것이다.
- 일부에서는, 패킷 하나를 보내고 그것이 송신자에게 되돌아올 때까지
의 왕복에 걸리는 시간을 latency라고 부르기도 한다.
- latency는 한 지점에서 다른 지점 사이에 (지연시간이 전혀 없이) 데
이터가 즉시 전송되어야만 하는 것으로 가정한다.
!
네트워크에서 Latency 를 일으키는 요인들!
- 전달 지연, 전송 지연, 라우터 및 기타 처리 지연, 다른 컴퓨터 및 저장
장치 지연
지연, 대기 시간대역폭!
- 통신에서 정보를 전송할 수 있는 능력, 최대전송속도.
- 인터넷의 접속 속도는 단위시간 당 송신량이 얼마나 되느냐에 따라
결정되기 때문에 인터넷 접속 속도라고도 볼 수 있다.
- 대역폭이 높으면 더 많은 사용자를 수용할 수 있고 사용자는
더 많은 데이터를 송수신할 수 있습니다.
- 대역폭 서비스를 이용하면 많은 트래픽이 발생하더라도
차단되지 않는 장점이 있다.
대역폭 계산방법!
- 멀티미디어 파일의 인코딩 비트레이트에 멀티미디어 파일을 볼 고객,
즉, 동시접속자 수를 곱한다.
인코딩 비트레이트 x 동시접속자 수 = 대역폭

5. 웹 클라이언트
서버 간 성능 개선
웹 자원 캐시
HTTP 압축
브라우저의 웹 자원 요청 방식
HTTP Connection
서버 요청 수 줄이기
CSS, Javascript 최소화
CSS, JS 파일 위치에 따른 성능 개선

6. 웹 자원 캐시
응답 상태 코드
!
!
304 code
수정 되지 않음.
- 마지막 요청 후, 요청한 페이지는 수정되지 않았다.
- 브라우저의 캐시에 들어있는 문서가 최신 문서이니 그대로 사용하라는 뜻이다.
- 클라이언트가 조건적 GET 요구를 실행했고 접근할 수 있으나,
문서가 변경되지 않았으면 서버는 이 상태 코드로 응답해야 한다.
- 이 응답은 Message-Body 를 포함해서는 안된다.
!
!
200 code
성공.
- 클라이언트의 요청이 성공적이었으며, 서버는 요청한 데이터를 포함하여 응답한다.
- 응답과 함께 리턴되는 정보는 요구에 사용된 method 에 달려있다.
!
GET 요구한 자원에 상응하는 엔티티는 응답에 포함되어 발송된다.
HEAD 요구한 자원에 상응하는 Entity-Header 필드는 Message-Body 없이 응답에 포함되어 발송된다.
POST 처리 결과를 설명 또는 포함하는 엔티티.
TRACE 수신 서버가 수신한 요구 메세지를 포함하고 있는 엔터티.
응답 상태 코드 목록
!
1xx - 조건부 응답
2xx - 성공
3xx - 리다이렉션 완료
4xx - 요청 오류
5xx - 서버 오류

7. 웹 자원 캐시
HTTP Request Header
If-Modified-Since
- 조건부로 만들 메소드와 함께 사용된다.
- 이 필드에 지정된 시간 이후에 요청된 변형이 수정되지 않은 경우,
서버에서 엔티티가 리턴되지 않고 대신 304(수정되지 않음) 응답이 message-body 없이 리턴됩니다.
- 형식은 HTTP-date입니다.
HTTP Response Header
Cache-Control, Age, Expires
http.Age
- 원본 서버에서 응답(및 해당 유효성 재검증)이 생성된 이후 경과된 송신자의 예상 시간을 전달합니다.
서버는 Expires header 또는 Cache-Control header의 max-age 지시자를 사용하여 만기일을 선정한다.
- Expires header나 Cache-Control header에 지정값이 없으면 Heuristic Expiration을 사용한다.
- Heuristic expiration time (자동설정 만기시간)
- Expires Header : 헤당 오브젝트가 얼마동안 유효한지를 표시해주는 항목
HTTP Header
ETag, If-None-Match
- 브라우저가 파일이 예전과 같은지 체크할 수 있도록 문자열을 제공하는 방법이다.
- ETag 헤더에서 문자열은 자원의 최신 여부를 식별할 수 있는 유일한 값이다.
(파일 버전이나 콘텐트 해시가 일반적.)
- If-none-match : 조건부로 만들 메소드와 함께 사용됩니다.
이전에 자원에서 하나 이상의 엔티티를 획득한 클라이언트는 If-None-Match 헤더 필드에 연관된
엔티티 태그의 목록을 포함하여,해당 엔티티 중 최신인 엔티티가 없는지 확인할 수 있다.

8. 웹 자원 캐시
HTTP 압축
Accept-Encoding
Content-Encoding
헤더 값 의미 :
gzip 그리고 deflate 인코딩 (압축 알고리즘)을 이해하므로 ,
웹 서버가 HTTP Response 메시지를 이들 알고리즘 중 하나로 압축해서 보내도 된다.
Accept-Encoding 은 클라이언트가 웹 서버에게 보내는 HTTP Request 메시지에 명세 하는 값으로서,
클라이언트가 이 헤더에 명시된 인코딩(압축)을 이해하고 디코딩(압축 해제)을 수행할 수 있다는 것을 서버에 알리는데 사용한다.
- 즉, 클라이언트가 압축된 컨텐츠를 받아 압축을 해제할 수 있는 압축 알고리즘을 서버에 알리는 용도로 Accept-Encoding 헤더가 사용된다.
- 웹 서버는 Accept-Encoding의 값을 살펴보고 필요에 따라서 HTTP Response(HTML, CSS, 이미지 등의 결과물)를 압축 할 수 있다.
- 웹 서버가 HTTP Response를 압축했다면,
서버는 결과가 어떤 알고리즘에 의해 인코딩(압축) 되었는가를 Content-Encoding 헤더를 통해 명시한다.
구글에서 반환한 HTTP Response 헤더의 내용이다.
!
구글은 Content-Encoding 헤더 값에 gzip에 명시하여,
컨텐츠가 gzip 알고리즘에 의해 압축되었음을 브라우저에게 알리고 있다.
- HTTP 압축은 두개의 http 헤더 필드에 의해 작동한다.
- Accept-Encoding 헤더와 Content-Encoding 헤더.
- 이 두개의 http 헤더 값을 통해 클라이언트(웹 브라우저)와 서버(웹 서버)의 압축 여부 및 압축에 사용되는 알고리즘을 판단.

9. HTTP 압축
이점
1. 응용 프로그램 응답을 제공하는데 필요한 대역폭을 줄이는 가장 효과적인 방법 중 하나는 HTTP 압축을 사용하는 것.
HTTP 압축을 통해 네트워크 대역폭을 절약할 수 있고, 절약한 네트워크 대역폭 만큼 더 많은 사용자를 수용할 수 있다.
또한, 서버 측 네트워크 대역폭을 늘리기 위한 투자 비용 역시 줄일 수 있다.
!
2. 응답의 크기를 상당히 줄일 수 있다.
HTML 과 같이 압축이 용이한 텍스트 콘텐츠에 적용하는 경우, 10분의 1 까지 압축 가능하다.
3. 거의 모든 브라우저에서 압축을 지원하고,
데스크탑 하드웨어에서 압축 해제를 수행하기 위한 비용은 데이터를 적게 전송하여 얻는 대기 시간 감소와 비교하면 사소한 수준.
압축은 HTTP 1.1 프로토콜에 정의된 콘텐츠-인코딩 협상에 기반을 두므로,
압축을 지원하지 않는 클라이언트에서도 안전하게 이 기능을 사용할 수 있다.
이러한 클라이언트는 단순히 콘텐츠의 압축되지 않은 버전을 수신한다.

10. 어떤 것을 압축할까
- HTTP 압축이 항상 좋기만 한 것은 아니다.
- 해당 웹 어플리케이션을 사용하는 모든 클라이언트가 100Mbps의 충분한 대역폭을 갖는다고 한다면,
HTTP 압축은 추가적인 오버헤드만을 발생할 뿐 이득을 얻을 수 없다.
하지만 클라이언트의 네트워크 대역폭이 10Mbps 이하가 된다면,
HTTP 압축은 거의 항상 최종 사용자에게 응답 속도가 향상되었다는 느낌을 갖도록 할 수 있다.
!
- HTTP 압축을 사용하겠다고 결정을 했다면, 어떤 컨텐츠를 압축할 것인가 신중해야 한다.
!
- 일반적으로 GIF, JPG 등의 이미지 파일은 압축하지 않는 것이 좋다.
- 너무도 당연한 것이 이들 이미지 포맷은 이미 압축이 되어 있기 때문에 실제 압축 해봤자 압축율이 90%를 육박한다.
- 따라서 이들을 압축했을 때는 오버헤드만이 증가되고 네트워크 속도에서 얻을 이익이 없다.
- 일반적으로 HTML 컨텐츠(정적 htm 파일 이건 asp/aspx에 의해 동적으로 생성되었건), XML 컨텐츠, 커다란 스크립트(.js 파일) 파일 등
텍스트 컨텐츠에 대해 압축을 수행하는 것이 일반적이라 할 수 있다.
HTTP 압축

11. 브라우저 종류 인터넷 익스플로러, 파이어폭스, 사파리, 크롬, 오페라
주요 기능
- 브라우저의 주요 기능은 사용자가 선택한 자원을 서버에 요청하고 브라우저에 표시하는 것이다.
- 자원은 보통 HTML 문서지만 PDF나 이미지 또는 다른 형태일 수 있다.
- 자원의 주소는 URI(Uniform Resource Identifier)에 의해 정해진다.
구성 요소
브라우저의 웹 자원 요청 방식
브라우저에 대하여
사용자 인터페이스
브라우저 엔진
렌더링 엔진
통신
자바스크립트 해석기
UI 백엔드
자료 저장소

12. 브라우저의 웹 자원 요청 방식
클라이언트 프로그램(웹 브라우저)은 URI를 이용하여 자원의 위치를 찾는다.
!
- URI는 HTTP와는 독립된 다른 체계다.
- HTTP는 전송 프로토콜이고, URI는 자원의 위치를 알려주기 위한 프로토콜이다.
- Uniform Resource Identifiers 의 줄임로, World Wide Web 상에서 접근하고자 하는 자원의 위치를 나타내기 위해서 사용한다.
- 자원은 "문서", "이미지", "동영상", "프로그램", "이메일"등 모든 것이 될 수 있다.
- - "프로토콜", "위치", "자원명"으로 (인터넷 상에서) 어디에 있던지 자원에 접근할 수 있다.
URI
index.php !
요청할 자원의 이름이다.
http !
자원에 접근하기 위해서 http 프로토콜을 사용한다.
자원의 인터넷 상에서의 위치는 www.joinc.co.kr이다.
도메인은 ip 주소로 변환되므로, ip 주소로 서버의 위치를 찾을 수 있다.
http://www.joinc.co.kr/index.php

13. 브라우저의 웹 자원 요청 방식
Method
메서드는 요청의 종류를 서버에게 알려주기 위해서 사용한다.
!
요청에 사용할 수 있는 메서드
!
GET : 정보를 요청하기 위해서 사용한다. (SELECT)
POST : 정보를 밀어넣기 위해서 사용한다. (INSERT)
PUT : 정보를 업데이트하기 위해서 사용한다. (UPDATE)
DELETE : 정보를 삭제하기 위해서 사용한다. (DELETE)
HEAD : (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다.
OPTIONS : 웹서버가 지원하는 메서드의 종류를 요청한다.
TRACE : 클라이언트의 요청을 그대로 반환한다. echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다.
!
!
보통 웹 서비스들은 GET과 POST만을 이용해서 개발한다.
DELETE나 PUT등이 필요한 요청에도 GET과 POST를 사용하는데, 예를들어 게시판에서 특정 레코드를 삭제 할때도 GET 으로 표현한다.
-> http://www.sample.com/bbs?id=1234&action=delete
!

14. 브라우저의 웹 자원 요청 방식
요청 데이터 포맷
- 웹 브라우저는 웹 서버에 데이터를 "요청"하는 "클라이언트 프로그램" 이다.
- 요청은 서버가 인식할 수 있는 약속된 형식(HTTP 형식)을 따라야 한다.
!
요청 데이터는 "HEADER"와 "BODY"로 구성된다.
헤더에는 요청과 요청 데이터에 대한 메타정보들이 들어있다.
HTTP 헤더는 라인피드와 캐리지 리턴(/r/n)을 함께 사용한다.
HTTP 헤더를 파싱할 때 주의해야 한다.
필수 요소로 요청의 제일 처음에 와야 한다.
3개의 필드로 이뤄져 있다.
!
1 요청 메서드 : GET, PUT, POST, PUSH, OPTIONS 등의 요청 방식.
2 요청 URI : 요청하는 자원의 위치를 명시.
3 HTTP 프로토콜 버전 : 웹 브라우저가 사용하는 프로토콜 버전.

15. HTTP Connection
병렬, 지속, 파이프라인
병렬 연결 Parallel Connections
HTTP 는 클라이언트가 여러개의 커넥션을 오픈하게하고,
여러개의 HTTP 트랜잭션을 병렬로 수행하게 한다.
병렬 연결은 페이지 로드를 빠르게한다.
!
HTML 페이지가 첫번째로 로드되고,
나머지 세개의 트랜잭션이 각각의 커넥션과 함께 동시에 진행된다.

16. HTTP Connection
병렬, 지속, 파이프라인
HTTP 연결 방법은 두가지이다.
비지속연결
지속연결
지속 연결은 하나의 TCP Connection을 생성하고 그 연결을 통해 모든 요청을 처리하는 것이다.
기본적으로 하나의 Connection을 통해 여러개의 요청을 파이프라이닝 기법을 활용하여 전송하게 된다.
HTTP 1.0 기준으로 클라이언트에서 지속연결을 원할 때, Keep-Alive를 헤더에 담아서 요청을 보낸다.
서버는 요청을 받고 역시 헤더에 담아서 응답한다. 이 TCP 커넥션을 통해 다른 요청을 보낼 수 있다.
서버나 클라이언트 측에서 더이상 연결이 필요없다고 판단할 경우 연결을 종료한다.
!
HTTP 1.1 기준으로 달리 명시되 있지 않으면 모든 연결은 지속연결로 간주된다.
하지만 각 서버마다 타임아웃(TIEMOUT)이 존재한다.
!
비지속 연결은 매번 자원을 요청할때 새로운 TCP Connection을 생성하는 것을 뜻한다.

17. HTTP Connection
병렬, 지속, 파이프라인
응답 메시지가 도착하지 않은 상태에서 연속적인 요구 메시지를 서버에 전달
이때 서버는 요구메시지를 수신한 순서대로 응답메시지를 클라이언트에 전달
이점!
연결과 종료횟수를 줄임으로서 네트워크 자원의 절약
발생하는 패킷의 숫자를 감소, 네트워크 트래픽 감소
파이프라이닝 Pipe Lining

18. HTTP Connection
keep-alive
HTTP는 connection less 방식으로 연결을 매번 끊고 새로 생성하는 구조이다.
이는 network 비용측면에서 많은 비용을 소비하는 구조이다.
그래서 HTTP 1.1부터는 Keep-Alive라는 기능을 지원한다.
뜻) 디바이스간의 데이터 링크가 잘 동작하고 있는지 확인하거나,
이 데이터 링크가 끊어지는 것을 방지하기 위해서 디바이스 간에 서로 주고받는 메시지
!
HTTP Keep Alive란?!
HTTP 프로토콜의 클라이언트와 서버간에 연결을 유지시키주는 명시적인 수단을 지원한다.
이 기능은 HTTP 1.0 에서 "Connection:Keep-alive" 헤더를 사용해서 추가되었고 HTTP 1.1 에서는 기본 기능이 되었다.
연결된 socket에 IN/OUT의 access가 마지막으로 종료된 시점부터 정의된 시간까지 access가 없더라도 대기하는 구조이다.
즉, 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있다는 것이다.
HTTP는 connection less방식이라 매번 socket(port)를 열어야 하고 이는 비용적인 측면에서 비효율적인 구조이다.
keep Alive time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라,
이미 열려 있는 socket(port)에 전송하는 구조가 된다.

19. 어떻게 사용하는가?!
1. client(browser)는 http 1.1을 준수하고 이해가능하다고 request에 Connection: Keep-Alive를 넣어서 Server에 전송.
(즉, client는 http 1.1 spec을 구현)
2. server도 http 1.1 spec을 구현, keep alive 기능을 활성화하고 keep alive time out을 설정.
HTTP Connection
keep-alive

20. 서버 요청 수 줄이기
CSS sprite
아이콘이나 버튼과 같은 독립된 여러 그림을 하나의 그림으로 합치고,
CSS의 background-position을 나타낼 요소에 따라 바꾸어 표시하는 기법.
이점) 서버로의 요청 횟수 감소, 사이트 로딩 속도 빨라짐,
내려받는 이미지의 크기줄어듦 효과.
구현 방법!
unordered li들로 구성된 메뉴들의 각 li에 특정 id 값을 지정해 주고, a 태그 속에 있는 text node를 <span> 태그로 감싸고 난 후,
여기에 background image의 좌표값을 표시될 해당 위치에 맞게 지정해 주면 끝난다.
+ Website Performance | CSS Sprite Generator
여러 개의 그림을 하나의 이미지로 합치고 CSS 적용을 위한 그림의 좌표값을 얻는 작업 자동화 도구.

21. 서버 요청 수 줄이기
Javascript 최소화
최소화
코드의 불필요한 문자를 줄인다 -> 파일 크기를 줄인다 -> 로딩시간 개선
모든 주석 뿐만 아니라 필요없는 공백 (스페이스/개행/탭)이 제거된다.
다운로드되는 파일의 용량이 줄어들기 때문에, 응답 시간이 빨라진다.
난독화
주석과 공백 뿐만 아니라 코드 또한 변경하여 알아보기 힘들게 만든다.
소스코드에 적용되는 최소화의 대안적인 기술.
코드변경은 함수와 변수 이름을 더욱 짧게 만들기 때문에,
성능에는 도움이 되지만, 읽기 힘들고 버그 발생률을 높인다.
인라인스크립트 최소화
외부 자바스크립트 파일 뿐만 아니라, 인라인스크립트까지 최소화하기.
!
Gzip 적용
JSMin, Dojo Compressor 이후, Gzip 을 적용하면 큰 효과를 볼 수 있다.
최소화만으로도 파일 크기의 절감의 효율성을 확인할 수 있다.
!
CSS 최소화
동일한 클래스는 합치고, 사용하지 않는 것은 삭제한다.
단축을 이용하고 불필요한 문자를 제거한다.
(#660066 -> #606 / 0px -> 0 )

22. CSS/JS 파일 위치에 따른 성능 개선
스타일시트(CSS)는 HTML의 헤드(Head)태그의 최상단에 위치하는 것이 성능향상에 도움된다.
<head>!
<link rel="stylesheet" type="text/css" href="mystyle.css">!
</head>
CSS 위치
위치 별 !
문제 및 성능
1. CSS 를 하단에 위치 : blank white screen 문제가 발생한다.
하단에 위치한 스타일시트가 다운로드 될때까지 페이지는 완전히 비어있다.
브라우저는 스타일시트가 모두 로드될 때까지 기다리고있는데, 페이지에는 아무것도 렌더링되지 않는다.
2. CSS 호출에 @import 사용 : blank white screen 문제와 FUOC(Flash of Unstyled Content) 문제가 발생한다.
(FOUC : 외부의 CSS가 불러오기 전에 잠시 스타일이 적용되지 않은 웹 페이지가 나타나는 현상
이 현상은 스타일이 적용되지 않은 웹 페이지가 스타일이 적용된 웹 페이지로 변화하는 것이다.)
3. CSS 를 헤드태그 최상단에 위치 : 위 같은 문제가 발생하지 않으며, 페이지 렌더가 제일 빠르다.

23. CSS/JS 파일 위치에 따른 성능 개선
Javascript 위치
스크립트 파일들은 바디(Body)태그에서 호출하는 것으로 성능을 높일 수 있다.
1. 스크립트를 중앙에서 호출
- 스크립트 아래에 있는 것들 모두 스크립트 로드가 완료될 때까지 렌더되지 못한다.
- 스크립트 아래에 있는 요소들 모두 스크립트가 끝나기 전까지는 다운로드 되지 못한다.
2. 스크립트 호출 위치의 상단과 하단 비교
상단에서 호출 : Head 에 있는 script 태그 때문에, 전체 페이지 렌더링이 연기된다.
하단에서 호출 : blocking problems 을 피할 수 있기에, 로드 및 렌더가 더 빠르다.
3. 스크립트를 상단에서 호출
- 위와 같이, 스크립트 밑에 위치하는 모든 것들이 스크립트 완료 전까지
다운로드 되지 못하기 때문에, 페이지 렌더가 연기된다.
4. 스크립트를 하단에서 호출
- blocking problems 을 피할 수 있기에, 로드 및 렌더가 더 빠르다.
5. 스크립트가 다운로드를 방해하는 사용
- hostname과 상관없이, 스크립트가 모두 로드되기 전까지는,
스크립트 아래의 요소들은 다운로드를 시작할 수 없다.
6. 로딩을 연장시키는 스크립트 사용
- defer 속성이 위 이슈를 해결해주진 못한다.
(defer 속성은 페이지 파싱이 완료된 후에 스크립트를 실행한다)
위치 별 문제점 및 성능 측면

24. Back-end
성능 개선
Cache
각 언어별 cache 적용

25. Cache
브라우저 캐시!
이미지, 사운드, 다운로드 등 컴퓨터에 단기간 동안 파일로 저장되는 인터넷 활동에 대한 임시 기록.
모든 브라우저에서 일관되게 캐시의 장점을 활용하려면,
서버 쪽에서 캐시 기간을 명확히 설정하고, 이를 적용할 수 있는 모든 자원에 적용하면 좋다.
* 캐시를 적용할 자원 : JS/CSS 파일, 이미지 파일, 바이너리 파일(미디어 파일, PDF들, 플래시 파일 등등)
웹 캐싱!
인터넷 게이트웨이 가까이에 설치되어 다른 사용자가 방문했던 사이트의 경우 원 서버에 요청하지 않고 캐시 서버에서 응답해주는 방식

26. Cache
페이지 교체 알고리즘 - LRU
Least Recently Used
- 교체 전략 중의 하나로 최근 사용이 가장 적은 것부터 버리는 방식이다.
- 페이지 교체 알고리즘 중 하나로서, 기억장치 바깥으로 내보낼 페이지를 선정할 때,
최근에 다른 어떤 페이지보다도 적게 사용된 페이지를 고르는 알고리즘.
- 일반적으로 가장 오랫동안 액세스되지 않았던 페이지는,
조만간에도 액세스되지 않을 확률이 가장 크다는 시간적 집약성에 기반을 둔다.
!

27. Cache
페이지 교체 알고리즘 - LFU
Least Frequently Used
- 사용 빈도가 가장 적은 페이지를 교체하는 방식이다.
- 활발하게 사용되는 페이지는 사용횟수가 많아 교체되지 않고 사용된다.
- 프로그램 실행 초기에 많이 사용된 페이지가 그 후로 사용되지 않을 경우에도,
프레임을 계속 차지할 수 있다.
부재발생 = 5!
1. 참조페이지를 각 페이지 프레임에 차례로 적재시키되 이미 적재된 페이지는 해당 위치의 페이지 프레임을 사용한다.!
2. 사용할 페이지 프레임이 없을 경우 사용 빈도가 가장 적은 페이지 4를 제거한 후 5를 적재한다.

28. Cache
페이지 교체 알고리즘 - FIFO
First-in First-out Page Replacement
- 메모리에 올라온지 가장 오래된 페이지를 교체하는 방식이다.
- 가장 간단한 교체 알고리즘이다.
- 가장 오래된 페이지가 초기화 모듈이라면 성능이 저하될 수 있다.
- Belady 의 모순 발생 :
프로세스에게 프레임을 더 줬는데도 오히려 프레임 부재율이 증가.

29. • 웹 자원 캐시 : http://www.simpleisbest.net/archive/2005/07/18/185.aspx
• HTTP 압축 : http://www.taeyo.pe.kr/Lecture/ProfessionalSecrets/5.asp
• HTTP 압축 : http://d2.naver.com/helloworld/59361
• 웹브라우저 : http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Network_Programing/AdvancedComm/HTTP
• http connection : http://llniceqll.tistory.com/204
http://boanin.tistory.com/101
• css sprite : http://appletree.or.kr/blog/web-development/
• consistent connection : http://qwefgh90.github.io/network/network_http.html
https://www.safaribooksonline.com/library/view/http-the-definitive/1565925092/ch04s04.html
• keep alive : http://pungjoo.tistory.com/2
https://ko.wikipedia.org/wiki/%ED%82%B5%EC%96%BC%EB%9D%BC%EC%9D%B4%EB%B8%8C
http://humaniverse.tistory.com/archive/201305
• 최소화 : http://joochang.tistory.com/34
http://firejune.com/1302/YDN%EC%9D%B4+%EA%B6%8C%EC%9E%A5%ED%95%98%EB%8A%94+%EC%9B
%B9%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98+%EC%84%B1%EB%8A%A5+%EC%B5%9C%EC
%A0%81%ED%99%94+%EC%A7%80%EC%B9%A8+15%EA%B3%84%EB%AA%85
• FOUC : https://ko.wikipedia.org/wiki/FOUC
• 대역폭 : https://linkfile.co.kr/board/board.htm?w=v&bm_id=5&si_id=91&sel=&s=&op=&page=1
출처