2024.10.16(수) { CDN, MIME 타입, Accept 헤더, Vary 헤더, 아파치&톰캣 차이, addInterceptor }

CDN(Content Delivery Network)

CDN(Content Delivery Network)은 웹 개발에서 성능을 최적화하고 사용자 경험을 향상시키는 데 중요한 역할을 하는 기술입니다. 웹 개발자라면 CDN의 개념과 그 이점에 대해 이해하는 것이 좋습니다. 아래에서 CDN이 무엇인지, 웹 개발에서 CDN을 사용하는 이유, 장점, 그리고 CDN이 웹사이트 성능에 미치는 영향을 설명하겠습니다.

1. CDN이란?

CDN(콘텐츠 전송 네트워크)은 글로벌 네트워크에 분산된 서버들로 구성된 시스템으로, 사용자의 위치에 따라 가장 가까운 서버에서 콘텐츠를 제공하여 웹 페이지 로딩 속도를 최적화하는 기술입니다. CDN은 주로 이미지, CSS, JavaScript 파일, HTML, 동영상과 같은 정적 콘텐츠를 캐싱하고, 그 외에도 다양한 동적 콘텐츠 및 API 응답을 가속화할 수 있습니다.

CDN의 주요 목표:

웹 콘텐츠의 전송 속도 개선: 사용자와 가까운 서버에서 콘텐츠를 제공하여 지연 시간(latency)을 줄입니다.
서버 부하 감소: 중앙 서버로의 요청을 분산시키기 때문에 서버의 부하를 줄입니다.
가용성 및 안정성 향상: 여러 서버에 콘텐츠가 분산되므로, 특정 서버가 다운되더라도 다른 서버에서 콘텐츠를 제공할 수 있어 가용성과 안정성이 향상됩니다.

2. CDN이 어떻게 작동하는가?

CDN은 캐싱된 콘텐츠를 여러 지역에 분산된 서버 네트워크에 저장하여 작동합니다. 이를 통해 사용자는 웹사이트의 중앙 서버와의 직접적인 통신 대신, 자신에게 가장 가까운 CDN 서버에서 콘텐츠를 전송받게 됩니다.

CDN의 작동 원리:

사용자 요청: 사용자가 웹 페이지에 접근하면, DNS(Domain Name System) 요청이 발생하고 CDN 네트워크가 이를 처리합니다.
가장 가까운 서버로 라우팅: CDN 네트워크는 사용자의 지리적 위치를 기반으로 가장 가까운 **에지 서버(edge server)**로 사용자의 요청을 라우팅합니다.
캐싱된 콘텐츠 제공: 요청된 콘텐츠가 해당 서버에 이미 캐시되어 있으면, 그 서버에서 즉시 콘텐츠를 사용자에게 전송합니다.
원본 서버로 요청: 만약 캐시된 콘텐츠가 없으면, CDN 서버는 원본 서버에 요청하여 콘텐츠를 가져온 뒤, 이를 캐시하고 사용자에게 전송합니다.

3. 웹 개발에서 CDN 사용의 장점

1. 빠른 콘텐츠 제공

CDN은 사용자가 웹사이트에 요청한 데이터를 지리적으로 가까운 서버에서 제공하기 때문에, 데이터 전송 거리를 단축하여 웹 페이지 로딩 속도를 크게 개선할 수 있습니다.

2. 대역폭 절약

CDN은 웹사이트의 정적 리소스(이미지, CSS, JS 파일 등)를 캐싱하여 동일한 리소스를 여러 번 요청하지 않도록 합니다. 이를 통해 서버 대역폭 사용을 줄이고 트래픽 처리 효율을 높입니다.

3. 서버 부하 감소

CDN은 전 세계에 분산된 여러 서버가 트래픽을 분산 처리하기 때문에, 단일 서버에 대한 과도한 부하를 방지할 수 있습니다. 이는 특히 트래픽이 급증하는 이벤트에서 서버 다운타임을 줄이는 데 도움이 됩니다.

4. 가용성 및 신뢰성 향상

CDN은 여러 서버에 데이터를 복제하여 저장하므로, 한 서버에 문제가 생기더라도 다른 서버가 요청을 처리할 수 있습니다. 이로 인해 웹사이트의 가용성과 신뢰성이 높아집니다.

5. 보안 강화

CDN은 DDoS(Distributed Denial of Service) 공격을 포함한 다양한 사이버 공격에 대한 방어를 강화할 수 있습니다. 또한 SSL 인증서를 사용하여 안전한 HTTPS 통신을 지원하며, 일부 CDN 서비스는 **웹 애플리케이션 방화벽(WAF)**과 같은 보안 기능도 제공합니다.

4. CDN 사용 사례

1. 정적 파일 호스팅

CDN은 이미지, CSS, JavaScript 파일과 같은 정적 콘텐츠를 전 세계의 여러 서버에 캐시합니다. 이를 통해 사용자는 가장 가까운 서버에서 리소스를 가져오므로, 콘텐츠 전송 속도가 빨라집니다.

2. 동영상 스트리밍

동영상 스트리밍과 같은 대용량 파일을 다룰 때 CDN은 네트워크 부하를 분산시키고, 빠르고 안정적인 스트리밍 경험을 제공합니다.

3. 웹 애플리케이션 가속

CDN은 동적 콘텐츠 요청을 가속화하기 위해 사용될 수 있으며, API 호출 및 데이터베이스 쿼리 응답 속도를 향상시키는 데 도움을 줍니다.

4. 다국적 서비스 제공

글로벌 서비스를 제공하는 경우, CDN을 통해 전 세계 사용자에게 빠르고 일관된 경험을 제공할 수 있습니다. 예를 들어, 유럽에 있는 사용자는 유럽에 위치한 CDN 서버에서 데이터를 받는 방식입니다.

5. CDN 제공자 예시

몇몇 대표적인 CDN 서비스 제공자로는 다음이 있습니다:

Cloudflare: 보안과 성능을 모두 제공하는 CDN. 무료 플랜도 지원합니다.
Akamai: 전 세계적으로 가장 큰 CDN 제공자 중 하나로, 고성능 콘텐츠 전송에 특화되어 있습니다.
Amazon CloudFront: AWS에서 제공하는 CDN으로, S3와 EC2와 같은 AWS 서비스와 통합이 쉬운 것이 장점입니다.
Google Cloud CDN: Google의 인프라를 기반으로 제공하는 CDN 서비스입니다.
Fastly: 빠른 콘텐츠 배포와 실시간 로그 및 보안 기능을 제공하는 CDN입니다.

6. CDN 캐싱 전략

CDN 캐싱 전략은 웹 리소스의 TTL(Time to Live) 설정, 캐시 무효화 등의 방법을 통해 리소스가 최신 상태로 유지되면서도 최대한 오랫동안 캐시된 데이터를 제공할 수 있도록 조정합니다. 캐싱 전략을 잘 세우면 사용자 경험을 크게 향상시키고, 서버 부하를 줄일 수 있습니다.

일반적인 CDN 캐싱 전략:

최소한의 갱신이 필요한 정적 리소스(이미지, CSS, JS 등)는 오래 캐시하고, 변화가 자주 일어나는 콘텐츠(예: 동적 데이터)는 짧은 캐시 시간을 설정합니다.
버전 관리된 파일(예: style-v1.css, script-v2.js)을 사용하여 캐싱된 오래된 파일이 아닌 최신 파일을 제공할 수 있습니다.

7. CDN이 웹 개발자에게 중요한 이유

성능 최적화: CDN은 사용자에게 가장 빠른 응답 속도를 제공하기 위해 필수적인 도구입니다. 현대의 웹 애플리케이션은 전 세계 사용자들에게 빠르고 일관된 성능을 제공하는 것이 필수적이기 때문에, CDN은 이러한 목표를 달성하는 데 중요한 역할을 합니다.
확장성: 트래픽이 급증하는 경우에도 서버에 부하를 줄여 원활한 서비스를 제공합니다.
보안: CDN은 보안 서비스와 통합되어 웹사이트의 보안을 강화하고, DDoS 공격 등으로부터 방어하는 데 도움을 줍니다.

요약:

CDN은 콘텐츠를 사용자의 위치에 맞게 전 세계적으로 분산된 서버에서 제공하여 웹사이트 성능을 최적화하는 기술입니다.
웹 개발자는 CDN을 통해 웹사이트 로딩 속도를 개선하고 서버 부하를 줄이며, 글로벌 사용자에게 빠르고 일관된 경험을 제공할 수 있습니다.
정적 파일, 동영상 스트리밍, 다국적 서비스에 특히 효과적이며, Cloudflare, Akamai, AWS CloudFront와 같은 대표적인 CDN 서비스 제공자가 있습니다.

MIME 타입(Multipurpose Internet Mail Extensions)

MIME 타입(Multipurpose Internet Mail Extensions)은 인터넷에서 파일 형식이나 데이터 형식을 나타내기 위해 사용되는 표준입니다. 원래는 이메일의 파일 전송을 위해 개발되었으나, 현재는 HTTP 프로토콜을 포함한 다양한 인터넷 서비스에서 파일이나 콘텐츠의 형식을 나타내기 위해 사용됩니다.

MIME 타입의 구조

MIME 타입은 두 부분으로 구성됩니다:

타입: 콘텐츠의 대분류를 나타냅니다. 예를 들어 text, image, application 등.
하위 타입: 대분류 내의 구체적인 파일 형식 또는 데이터 형식을 나타냅니다. 예를 들어, text/html, image/png, application/json 등이 있습니다.

MIME 타입의 형식은 다음과 같습니다:

타입/하위타입

대표적인 MIME 타입들

다양한 MIME 타입이 존재하며, 자주 사용되는 몇 가지 MIME 타입을 정리하면 다음과 같습니다:

텍스트 형식
- text/plain: 일반 텍스트 파일
- text/html: HTML 파일
- text/css: CSS 파일
- text/javascript: JavaScript 파일 (또는 application/javascript)
이미지 형식
- image/jpeg: JPEG 이미지
- image/png: PNG 이미지
- image/gif: GIF 이미지
- image/svg+xml: SVG 이미지
애플리케이션 형식
- application/json: JSON 데이터
- application/xml: XML 데이터
- application/pdf: PDF 파일
- application/zip: ZIP 압축 파일
- application/octet-stream: 임의의 이진 데이터(파일 다운로드에 자주 사용됨)
오디오 및 비디오 형식
- audio/mpeg: MP3 파일
- audio/ogg: OGG 오디오 파일
- video/mp4: MP4 비디오 파일
- video/webm: WebM 비디오 파일

MIME 타입의 사용 예시

1. HTTP 응답 헤더에서 사용

웹 서버는 클라이언트에게 응답을 보낼 때, Content-Type 헤더를 통해 응답 본문의 MIME 타입을 명시합니다. 이를 통해 브라우저나 클라이언트는 해당 파일이 어떤 형식인지를 인식하고 적절한 방식으로 처리할 수 있습니다.

HTTP 응답 헤더 예시:

HTTP/1.1 200 OK
Content-Type: application/json

위의 경우, 서버는 클라이언트에게 JSON 형식의 데이터를 보낸다는 의미입니다.

2. 폼 데이터에서 사용 (파일 업로드)

HTML 폼에서 파일을 업로드할 때 enctype="multipart/form-data"를 사용하면, 파일의 MIME 타입이 서버로 전송됩니다. 서버는 이 MIME 타입을 확인하여 파일 형식에 따라 처리할 수 있습니다.

HTML 예시:

<form action="/upload" method="post" enctype="multipart/form-data">
    <input type="file" name="file">
    <button type="submit">Upload</button>
</form>

3. 이메일 첨부 파일

이메일을 통해 파일을 전송할 때, 각 파일의 MIME 타입을 명시하여 수신자가 파일 형식을 알 수 있게 합니다. 이때, 파일 확장자뿐만 아니라 MIME 타입을 사용하여 파일의 종류를 식별합니다.

MIME 타입과 브라우저 동작

브라우저는 MIME 타입을 기반으로 파일을 처리합니다. 예를 들어, 브라우저가 응답을 받을 때 Content-Type이 text/html로 설정되어 있으면 해당 파일을 HTML 문서로 해석하고, application/json으로 설정되어 있으면 JSON 데이터로 처리합니다.

잘못된 MIME 타입의 문제점

잘못된 MIME 타입을 사용할 경우 보안 문제나 브라우저의 잘못된 동작을 유발할 수 있습니다. 예를 들어, JavaScript 파일을 text/plain으로 제공할 경우, 브라우저는 해당 파일을 스크립트로 실행하지 않고 단순 텍스트로 처리하게 됩니다. 이는 XSS(크로스 사이트 스크립팅) 같은 보안 문제를 방지하는 데도 유용합니다.

MIME 타입을 확인하는 방법

서버가 특정 파일에 대해 어떤 MIME 타입을 반환하는지 확인하려면 브라우저의 개발자 도구에서 HTTP 응답 헤더를 확인할 수 있습니다.

브라우저에서 웹 페이지를 연다.
개발자 도구(Chrome에서는 F12 또는 우클릭 후 '검사')를 연다.
Network 탭에서 해당 리소스를 선택하여 Headers 섹션을 확인한다.
Content-Type 헤더를 보면 서버가 반환한 MIME 타입을 확인할 수 있다.

요약

MIME 타입은 클라이언트와 서버 간에 데이터 형식을 식별하는 데 사용되는 표준입니다.
형식은 타입/하위타입으로 구성되며, 대표적인 MIME 타입으로는 text/html, application/json, image/jpeg 등이 있습니다.
웹 개발에서 HTTP 응답 헤더의 Content-Type을 설정하거나, 파일 업로드 및 이메일 전송에서 자주 사용됩니다.
MIME 타입을 올바르게 설정하면 브라우저나 클라이언트가 파일 형식을 정확히 인식하고 처리할 수 있습니다.

Accept 헤더와 Vary 헤더는 모두 HTTP 요청 및 응답에서 사용되는 헤더로, 서버와 클라이언트 간의 콘텐츠 협상 및 캐싱 동작에 중요한 역할을 합니다. 각각의 기능을 아래에서 자세히 설명하겠습니다.

1. `Accept` 헤더

Accept 헤더는 클라이언트(브라우저 또는 API 소비자)가 서버에 요청을 보낼 때 받고 싶은 콘텐츠 형식을 명시하는 데 사용됩니다. 즉, 클라이언트가 특정 형식의 응답을 선호한다는 정보를 서버에 전달합니다.

사용 목적:

클라이언트는 여러 종류의 데이터를 요청할 수 있는데, 이 헤더를 통해 JSON, XML, HTML 등 다양한 콘텐츠 형식 중 어느 것을 받을지 결정할 수 있습니다.
콘텐츠 협상을 통해 서버는 클라이언트가 요청한 형식에 따라 가장 적합한 형식으로 응답을 반환합니다.

`Accept` 헤더의 예시:

GET /resource HTTP/1.1
Host: example.com
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8

위의 요청에서 클라이언트는 다음과 같은 형식의 응답을 선호한다는 것을 명시하고 있습니다:

text/html: HTML 콘텐츠를 가장 선호합니다.
application/xhtml+xml: XHTML 콘텐츠도 받을 수 있습니다.
application/xml;q=0.9: XML은 그다음으로 선호하지만, 우선순위가 낮습니다.
*/*;q=0.8: 어떤 콘텐츠든 상관없지만, 가장 낮은 우선순위로 처리됩니다.

q는 품질 인수(quality factor)로, 클라이언트의 선호도를 나타냅니다. q 값이 낮을수록 선호도가 낮다는 뜻입니다(기본값은 q=1).

서버의 동작:

서버는 Accept 헤더의 정보를 기반으로 클라이언트에게 적합한 콘텐츠 형식으로 응답합니다. 만약 서버가 클라이언트가 요구하는 형식을 제공할 수 없다면, 기본 형식으로 응답하거나, 때로는 406 Not Acceptable 상태 코드를 반환할 수 있습니다.

예시: JSON 요청을 하는 클라이언트

GET /data HTTP/1.1
Host: api.example.com
Accept: application/json

서버는 이 요청을 받아들여 JSON 형식의 데이터를 클라이언트에게 응답으로 보냅니다.

2. `Vary` 헤더

Vary 헤더는 서버 응답 헤더로, 클라이언트가 콘텐츠를 요청할 때 캐싱 동작을 제어하는 데 사용됩니다. 특히 클라이언트 요청의 어떤 특정 헤더가 서버의 응답에 영향을 미치는지에 대한 정보를 캐시 서버에게 알려주는 역할을 합니다.

사용 목적:

캐싱 서버(예: 브라우저 또는 CDN)가 서버로부터 받은 응답을 캐시할 때, Vary 헤더는 캐시된 응답을 올바르게 제공하기 위해 어떤 요청 헤더가 달라질 때 새로운 응답을 보내야 하는지를 명시합니다.
즉, Vary 헤더에 명시된 요청 헤더가 변경되면, 캐시는 해당 요청에 맞는 새 응답을 서버로부터 받아와야 합니다.

예시:

Vary: Accept-Encoding, User-Agent

위의 Vary 헤더는 캐시 서버에게 Accept-Encoding과 User-Agent 헤더 값이 변경될 때마다 새로운 캐시를 사용해야 한다는 정보를 제공합니다.

서버의 동작:

예를 들어, 서버가 클라이언트의 Accept-Encoding 헤더를 보고, gzip 또는 deflate 방식으로 데이터를 압축할 수 있습니다. 클라이언트가 요청할 때마다 Accept-Encoding 값이 다르다면, 캐시 서버는 그에 맞는 응답을 새로 받아서 캐싱해야 합니다.
마찬가지로 User-Agent 값에 따라 모바일 또는 데스크탑 버전의 웹 페이지를 반환할 수 있습니다. 이때 Vary 헤더에 User-Agent를 추가하면 캐시 서버는 모바일과 데스크탑 요청을 별도로 처리하게 됩니다.

예시:

GET /home HTTP/1.1
Host: example.com
Accept-Encoding: gzip

HTTP/1.1 200 OK
Content-Encoding: gzip
Vary: Accept-Encoding

위의 경우, 서버는 Accept-Encoding 헤더를 참고하여 gzip 압축된 응답을 클라이언트에 반환하며, 캐시 서버에게 Accept-Encoding 헤더 값이 달라질 때마다 캐시를 구분하여 처리하라는 의미로 Vary: Accept-Encoding 헤더를 포함합니다.

`Accept`와 `Vary`의 차이점:

Accept 헤더는 클라이언트가 요청할 때 서버에 원하는 콘텐츠 형식을 명시하는 데 사용됩니다. 클라이언트는 서버에 자신이 수용할 수 있는 여러 가지 형식을 제시하고, 서버는 그에 맞는 형식으로 응답합니다.
Vary 헤더는 서버가 응답할 때, 캐싱 서버에게 요청 헤더를 기준으로 콘텐츠를 구분하라는 지시를 내리는 데 사용됩니다. 서버는 클라이언트의 요청 헤더가 응답에 영향을 미치는 경우 이 헤더를 통해 캐시 정책을 제어합니다.

요약:

Accept 헤더: 클라이언트가 요청 시 수용할 수 있는 콘텐츠 형식을 서버에 명시하는 헤더.
- 예시: Accept: application/json, text/html
Vary 헤더: 서버가 응답 시 캐시 서버에게 어떤 요청 헤더를 기준으로 캐시를 구분할지를 명시하는 헤더.
- 예시: Vary: Accept-Encoding, User-Agent

이 두 헤더는 콘텐츠 협상과 캐싱 제어에서 중요한 역할을 합니다. Accept는 클라이언트가 선호하는 콘텐츠 형식을 서버에 전달하고, Vary는 서버가 클라이언트의 특정 요청 헤더에 따라 캐시를 다르게 처리하도록 지시합니다.

addInterceptor, LocaleChangeInterceptor, 그리고 ThemeChangeInterceptor는 모두 스프링의 인터셉터 기능과 관련이 있습니다. 스프링의 인터셉터는 HTTP 요청 처리 흐름에 개입하여 요청 전후에 특정 작업을 수행할 수 있는 기능을 제공합니다. 각각의 인터셉터는 특정한 기능을 수행하도록 설계되어 있습니다.

1. addInterceptor()

역할: addInterceptor()는 스프링의 WebMvcConfigurer에서 인터셉터를 등록할 때 사용하는 메서드입니다.
설명: 이 메서드를 통해 스프링 MVC에 다양한 인터셉터를 추가할 수 있으며, 인터셉터가 적용될 URL 패턴을 설정할 수 있습니다.

사용 예시:

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.InterceptorRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new LocaleChangeInterceptor());  // 인터셉터 추가
        registry.addInterceptor(new ThemeChangeInterceptor());   // 인터셉터 추가
        // 다른 인터셉터 추가 가능
    }
}

여기서 addInterceptor()를 사용하여 여러 인터셉터를 등록할 수 있습니다. 등록된 인터셉터는 요청이 들어올 때마다 특정 URL 패턴에 따라 작동하게 됩니다.

2. LocaleChangeInterceptor

역할: LocaleChangeInterceptor는 사용자의 언어 설정(로케일)을 변경할 수 있게 해주는 스프링의 내장 인터셉터입니다.
설명: 이 인터셉터는 요청 파라미터를 통해 로케일(언어 및 지역 정보)을 변경할 수 있도록 지원합니다. 이를 통해 사용자는 브라우저에서 지정된 언어와 관계없이 특정 파라미터를 통해 애플리케이션의 언어를 동적으로 변경할 수 있습니다.

사용 방법:

LocaleChangeInterceptor 등록:
WebMvcConfigurer를 사용하여 인터셉터를 등록할 수 있습니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        LocaleChangeInterceptor localeInterceptor = new LocaleChangeInterceptor();
        localeInterceptor.setParamName("lang");  // URL에서 언어를 변경할 파라미터 이름 설정 (기본값은 'locale')
        registry.addInterceptor(localeInterceptor);
    }
}

URL을 통한 언어 변경:
- 이제 /some-url?lang=ko와 같은 요청을 보내면, 애플리케이션이 한국어로 표시됩니다.
- lang 파라미터를 통해 언어를 변경할 수 있으며, 이 파라미터 이름은 setParamName()을 통해 변경할 수 있습니다.

LocaleResolver 설정:

LocaleChangeInterceptor와 함께 사용하려면 LocaleResolver를 설정해야 합니다.

@Bean
public LocaleResolver localeResolver() {
    SessionLocaleResolver localeResolver = new SessionLocaleResolver();
    localeResolver.setDefaultLocale(Locale.US);  // 기본 로케일 설정
    return localeResolver;
}

3. ThemeChangeInterceptor

역할: ThemeChangeInterceptor는 애플리케이션의 테마를 요청 파라미터를 통해 동적으로 변경할 수 있게 해주는 스프링의 내장 인터셉터입니다.
설명: 사용자가 웹 애플리케이션에서 테마(스타일, UI 등)를 변경할 수 있도록 도와줍니다. 테마는 UI에서의 CSS, 이미지 등을 다르게 적용하는 방법으로 사용됩니다.

사용 방법:

ThemeChangeInterceptor 등록:
WebMvcConfigurer를 사용하여 인터셉터를 등록합니다.

@Configuration
public class WebConfig implements WebMvcConfigurer {

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        ThemeChangeInterceptor themeInterceptor = new ThemeChangeInterceptor();
        themeInterceptor.setParamName("theme");  // URL에서 테마를 변경할 파라미터 이름 설정
        registry.addInterceptor(themeInterceptor);
    }
}

URL을 통한 테마 변경:
- 이제 /some-url?theme=dark와 같이 요청을 보내면, 테마를 변경할 수 있습니다.
- theme 파라미터를 통해 테마를 변경하며, 이 파라미터 이름은 setParamName()을 통해 변경할 수 있습니다.

ThemeResolver 설정:

ThemeChangeInterceptor와 함께 ThemeResolver도 설정해야 합니다.

@Bean
public ThemeResolver themeResolver() {
    SessionThemeResolver themeResolver = new SessionThemeResolver();
    themeResolver.setDefaultThemeName("default");  // 기본 테마 설정
    return themeResolver;
}

4. LocaleChangeInterceptor와 ThemeChangeInterceptor의 공통점

동적 파라미터 변경: 둘 다 URL 파라미터를 통해 동적으로 설정을 변경할 수 있도록 지원합니다.
- LocaleChangeInterceptor: 언어 설정을 변경 (?lang=ko).
- ThemeChangeInterceptor: 테마 설정을 변경 (?theme=dark).
세션 및 요청에 따른 설정 변경: 두 인터셉터 모두 세션을 기반으로 해당 변경 사항을 유지하거나, 한 번의 요청에만 적용할 수 있습니다.

요약

addInterceptor(): 스프링 MVC에서 인터셉터를 등록하는 메서드입니다. 인터셉터를 추가하여 요청 처리 전후에 로직을 실행할 수 있습니다.
LocaleChangeInterceptor: URL 파라미터를 통해 애플리케이션의 언어(로케일)를 변경할 수 있도록 도와주는 인터셉터입니다.
ThemeChangeInterceptor: URL 파라미터를 통해 애플리케이션의 테마(스타일)를 동적으로 변경할 수 있게 해주는 인터셉터입니다.

이 두 인터셉터는 모두 사용자 요청에 따라 애플리케이션의 설정을 동적으로 변경할 수 있도록 해주며, LocaleResolver 및 ThemeResolver와 함께 사용됩니다.

'Everyday Study' 카테고리의 다른 글

2024.10.28(월) { 세션고정, XSS, CSRF, Credential } (0)	2024.10.28
2024.10.21(월) { spring과 node.js, 스프링 MVC와 스프링 부트의 차이, 환경변수는 리눅스에서 나온것 } (0)	2024.10.21
2024.10.15(화) { WebMvcConfigurer, 인터셉터(Interceptor), redirect&forward, 필터체인 } (0)	2024.10.15
2024.10.14(월) { CORS (교차 출처 자원 공유), DTO&DVO, @RequestParam 과 @InitBinder, SimpleDateFormat, @RequestParam } (0)	2024.10.14
2024.10.11(금) { AJAX 비동기, Referer : 이전 웹페이지, URL 템플릿 변수 {} } (0)	2024.10.11

2024.10.16(수) { CDN, MIME 타입, Accept 헤더, Vary 헤더, 아파치&톰캣 차이, addInterceptor }

CDN(Content Delivery Network)

1. CDN이란?

CDN의 주요 목표:

2. CDN이 어떻게 작동하는가?

CDN의 작동 원리:

3. 웹 개발에서 CDN 사용의 장점

1. 빠른 콘텐츠 제공

2. 대역폭 절약

3. 서버 부하 감소

4. 가용성 및 신뢰성 향상

5. 보안 강화

4. CDN 사용 사례

1. 정적 파일 호스팅

2. 동영상 스트리밍

3. 웹 애플리케이션 가속

4. 다국적 서비스 제공

5. CDN 제공자 예시

6. CDN 캐싱 전략

일반적인 CDN 캐싱 전략:

7. CDN이 웹 개발자에게 중요한 이유

요약:

MIME 타입(Multipurpose Internet Mail Extensions)

MIME 타입의 구조

대표적인 MIME 타입들

MIME 타입의 사용 예시

1. HTTP 응답 헤더에서 사용

2. 폼 데이터에서 사용 (파일 업로드)

3. 이메일 첨부 파일

MIME 타입과 브라우저 동작

잘못된 MIME 타입의 문제점

MIME 타입을 확인하는 방법

요약

1. Accept 헤더

사용 목적:

Accept 헤더의 예시:

서버의 동작:

예시: JSON 요청을 하는 클라이언트

2. Vary 헤더

사용 목적:

예시:

서버의 동작:

예시:

Accept와 Vary의 차이점:

요약:

1. addInterceptor()

사용 예시:

2. LocaleChangeInterceptor

사용 방법:

3. ThemeChangeInterceptor

사용 방법:

4. LocaleChangeInterceptor와 ThemeChangeInterceptor의 공통점

요약

'Everyday Study' 카테고리의 다른 글

관련글

티스토리툴바

1. `Accept` 헤더

`Accept` 헤더의 예시:

2. `Vary` 헤더

`Accept`와 `Vary`의 차이점: