하루_한개_코딩

캐시(cache)란 ?

캐시는 컴퓨터 시스템의 성능을 향상시키고 데이터 접근 속도를 개선하기 위해 사용되는 중간 저장소입니다. 캐시는 이전에 접근한 데이터나 결과를 임시로 저장하여 동일한 데이터에 대한 다시 접근 시 원본 데이터를 다시 가져오지 않고 캐시에서 빠르게 반환함으로써 시스템 성능을 향상시킵니다.

캐시의 기본 동작은 다음과 같습니다:

1. 요청된 데이터 접근 : 클라이언트나 애플리케이션에서 어떤 데이터를 요청합니다.
2. 캐시 검사 : 요청된 데이터가 캐시에 이미 저장되어 있는지 확인합니다.
3. 캐시에 데이터가 있을 경우: 요청된 데이터가 캐시에 저장되어 있으면, 원본 데이터를 다시 가져오지 않고 캐시에서 데이터를 반환합니다. 이로 인해 데이터 접근 속도가 빨라집니다.
4. 캐시에 데이터가 없을 경우: 요청된 데이터가 캐시에 저장되어 있지 않으면, 원본 데이터를 가져와서 캐시에 저장한 후에 클라이언트에 반환합니다. 이후 동일한 데이터에 대한 요청이 들어오면 캐시에서 데이터를 반환하게 됩니다.
   
   

요청 메세지를 보낼 때, cache-control : max-age=60으로 60초의 시간동안은 요청 받았던 파일이나 이미지 등을 브라우저 캐시에 보관합니다. 이 후, 같은 파일의 요청메세지가 GET메서드로 오면, 캐시에 저장해두었던 응답결과로 반환합니다. 캐시 유효 시간이 초과했는데, 동일한 데이터를 요청한다면 서버를 통해 데이터를 다시 조회하고 캐시를 갱신합니다. 이 때, 다시 네트워크 다운로드가 발생하는 비효율 적인 상황이 발생합니다.

📋 검증 헤더와 조건부 요청

해당 사항을 해결할 수 있는 방법이 검증 헤더 , 조건부 요청 입니다. 

검증 헤더와 조건부 요청은 HTTP 요청과 응답에 사용되는 기능으로, 웹 서버와 클라이언트 간의 효율적인 통신을 도와줍니다. 이를 통해 불필요한 데이터 전송을 줄이고 네트워크 부하를 감소시킬 수 있습니다.

1. 검증 헤더(Validation Headers) : 검증 헤더는 서버가 리소스(예: 웹 페이지, 이미지, 동영상 등)의 변경 여부를 클라이언트에게 알려주는 역할을 합니다. 클라이언트는 이 헤더를 통해 리소스를 캐시하고, 이후 동일한 리소스에 대한 요청 시 서버로부터 리소스의 변경 여부를 확인합니다.동작 원리는 다음과 같습니다
   
   주요 검증 헤더
   👉 Last-Modified : HTTP 응답 헤더 중 하나로, 웹 서버가 특정 리소스의 최종 수정 시간을 클라이언트에게 알려주는 역할을 합니다. 이 헤더는 클라이언트가 해당 리소스를 다시 요청할 때, 서버가 리소스의 변경 여부를 확인하는 데 사용됩니다.
   
   
   1. 웹 서버는 특정 리소스에 대한 요청이 들어올 때, 해당 리소스의 최종 수정 시간을 계산합니다.
   2. Last-Modified 헤더에 이 최종 수정 시간을 포맷에 맞추어 기록하여 HTTP 응답으로 클라이언트에게 전달합니다.
   3. 클라이언트는 해당 리소스를 다시 요청할 때, If-Modified-Since 헤더를 함께 보내서 서버에게 해당 리소스의 변경 여부를 질의합니다.
   4. 서버는 If-Modified-Since 헤더에 포함된 시간과 리소스의 최종 수정 시간을 비교하여 리소스의 변경 여부를 판단합니다.
      
      • If-Modified-Since의 시간보다 최종 수정 시간이 이후라면, 리소스가 변경되었다는 의미로 200 OK 응답과 함께 실제 데이터를 보냅니다.
      • If-Modified-Since의 시간과 최종 수정 시간이 동일하거나 이전이라면, 리소스가 변경되지 않았다는 의미로 304 Not Modified 응답 헤더만을 반환하고, 실제 데이터 Body에 포함하지 않습니다.
        
        
   네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드가 되며, 클라이언트는 캐시에 저장되어 있는 데이터를 재활용 할 수 있습니다. 브라우저에서 파일 1개를 클릭한 후 , 해당 브라우저에서 아무런 실행 없이 새로고침을 해보면 status가 304임을 확인할 수 있습니다.
   
   

304로 응답이 왔다는 것은 요청 메세지 Request 시 if-modified-since 을 작성해서 보낸 것을 의미합니다. 해당 시간이 적힌 이후로의 데이터변경이 없음을 의미하므로 요청한 데이터와 동일한 데이터가 쿠키에 있기 때문에 새로이 응답 메세지를 보낸 것이 아니라 캐시에 보관되어 있던 응답 메세지를 보낸 것입니다.

👉 ETag (Entity Tag) : 리소스의 고유한 식별자를 나타내는 문자열로, 리소스가 변경되면 변경된 ETag 값을 반환합니다. 이 식별자는 해당 리소스의 내용이 변경되었는지를 클라이언트가 확인하는 데 사용됩니다.

동작 원리는 다음과 같습니다:

1. 웹 서버는 특정 리소스의 데이터를 해시 함수 등을 사용하여 유일한 식별자를 생성합니다.
2. ETag 헤더에 이 식별자를 포맷에 맞추어 기록하여 HTTP 응답으로 클라이언트에게 전달합니다.
3. 클라이언트는 해당 리소스를 다시 요청할 때, If-None-Match 헤더를 함께 보내서 서버에게 해당 리소스의 변경 여부를 질의합니다.
4. 서버는 If-None-Match 헤더에 포함된 식별자와 현재 리소스의 식별자를 비교하여 리소스의 변경 여부를 판단합니다.
   • If-None-Match의 식별자와 현재 리소스의 식별자가 일치하지 않으면, 리소스가 변경되었다는 의미로 200 OK 응답과 함께 실제 데이터를 보냅니다.
   • If-None-Match의 식별자와 현재 리소스의 식별자가 동일하면, 리소스가 변경되지 않았다는 의미로 304 Not Modified 응답을 반환하고, 실제 데이터를 포함하지 않습니다.

캐시는 주로 웹 브라우저, 웹 서버, 프록시 서버 등에서 사용되며, 웹 페이지의 이미지, 스타일 시트, 스크립트 파일 등을 캐시하여 사용자에게 빠른 웹 페이지 로딩 속도를 제공하는 데 활용됩니다. 또한, 데이터베이스 쿼리 결과나 API 응답 결과 등을 캐시하여 데이터 접근 속도를 개선하는 데에도 활용됩니다.

캐시 제어 (cache-control)이란?

캐시 제어 헤더는 HTTP 응답과 요청에 포함되어 캐시 동작을 제어하는데 사용되는 헤더들을 말합니다. 이러한 헤더들을 이용하여 클라이언트와 서버 간의 캐시 동작을 조정하고, 캐시의 적용 범위와 지속 시간 등을 설정할 수 있습니다.

1. Cache-Control: 캐시 동작을 설정합니다. 주요 지시자로는 public, private, no-cache, max-age, s-maxage 등이 있습니다.
   Cache-control : max-age → 캐시가 어느 기간동안 유효한지를 입력합니다. 단위는 초 단위 입니다.
   Cache-control : no-cache → 캐시를 사용하지 않도록 지시하는 지시자 입니다. HTTP 응답의 Cache-Control 헤더에서 사용되며, 이 지시자가 포함된 경우 클라이언트와 중개 서버는 응답을 캐시하지 않고 매번 원본 서버에 검증하여 새로운 응답을 가져옵니다.
   Cache-control : no-store → 캐시를 완전히 비활성화하는 캐시 제어 지시자 no-store 지시자가 포함된 응답은 민감한 정보나 개인 정보와 같이 보안상 민감한 데이터를 포함하는 경우 사용됩니다. 따라서 no-store 지시자는 이러한 상황에서 캐시를 사용하지 않도록 지시하여 보안을 강화합니다.
   Cache-control : must-revalidate → 캐시된 데이터가 유효한지 원본 서버와 검증을 수행해야 합니다. 원 서버 접근 실패 시 반드시 오류가 발생해야 합니다. (504-Gateway Timeout) 캐시된 데이터를 사용하기 전에 원본 서버와 검증을 거쳐야 하며, 만료된 후 최초 조회 시 반드시 원본 서버에 검증 후 새로운 데이터를 가져와서 사용합니다.
2. Pragma: 캐시 동작을 설정하는데 사용되지만, 일반적으로 사용되지 않으며 Cache-Control 헤더를 대신 사용합니다.
3. Expires (하위 호환) : 캐시 만료 시간을 설정합니다. 정확한 날짜로 지정해야 하고, max-age와 expires가 같이 쓰이면 expires는 무시됩니다. 응답이 해당 시간 이후에는 더 이상 캐시를 사용하지 않고 서버에 재요청합니다. 하지만 이 헤더는 오래된 방식이므로 Cache-Control의 max-age를 더 권장합니다.

프록시 캐시란?

프록시 캐시는 클라이언트와 서버 사이에 위치하여 클라이언트의 요청을 대신 받아서 서버로 전달하고, 서버의 응답을 클라이언트에게 전달하는 역할을 하는 중개 서버입니다. 이러한 프록시 서버는 원격 서버와 클라이언트 간의 통신을 중개하며, 캐시를 사용하여 네트워크 트래픽을 줄이고 응답 속도를 향상시킵니다.

프록시 캐시는 서버로부터 받은 응답을 캐시에 저장하여 동일한 요청이 들어올 경우 새로운 요청을 서버로 전달하지 않고 캐시된 응답을 클라이언트에게 바로 제공합니다. 이렇게 함으로써 원격 서버에 불필요한 요청을 줄이고, 클라이언트의 요청에 더 빠르게 응답할 수 있습니다.

이렇게 함으로써, 동일한 요청이 반복되거나 여러 클라이언트가 동일한 리소스를 요청할 경우, 프록시 서버는 원격 서버에 대한 중복 요청을 줄여 네트워크 트래픽을 최소화하고 응답 속도를 향상시킵니다. 또한 프록시 캐시는 웹 서버의 부하를 감소시키고 클라이언트에게 빠른 응답을 제공하여 사용자 경험을 향상시킵니다.

여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기에 빠른 속도로 자료를 가져올 수 있습니다. 이는 같은 국내에 있기에 원서버에 접근하는 것보다 훨씬 빠른 속도에 자료를 가져올 수 있기 때문입니다. 이 때 클라이언트에서 사용하고 저장하는 캐시를 private 캐시라 하며 프록시 캐시 서버의 캐시를 public 캐시라 합니다.

💥 캐시 무효화

캐시 무효화(Cache Invalidation)란, 캐시에 저장된 데이터가 유효하지 않아서 더 이상 사용해서는 안 된다는 표시를 내리는 과정을 말합니다. 캐시는 원본 서버의 데이터를 저장하여 클라이언트에게 빠르게 응답을 제공하는데 사용되지만, 원본 데이터가 변경되거나 삭제되었을 때 캐시에 저장된 데이터가 더 이상 유효하지 않게 될 수 있습니다. 이때 캐시 무효화를 통해 클라이언트가 더 이상 캐시된 데이터를 사용하지 않도록 하고, 새로운 데이터를 다시 원본 서버에서 가져와서 캐시를 업데이트하는 작업이 필요합니다.

✍️ HTTP 헤더의 일반 정보

• Referer는 HTTP 요청 헤더의 하나로, 웹 브라우저가 현재 요청을 보내는 페이지의 이전 페이지(리퍼러)의 URL을 나타냅니다. 현재 요청된 페이지의 이전 웹페이지 주소를 의미합니다.
  이 헤더는 웹 서버에게 클라이언트가 어떤 페이지에서 링크를 클릭하거나 리소스를 요청하는지를 알려주는 역할을 합니다. ex) 구글에서 검색 후, 1개의 게시글을 클릭한 후 http 메서드를 확인하게 되면 Referer에 이전 페이지 URL이 뜨는 것을 확인할 수 있습니다

이렇게 Referer 정보를 서버에 전달함으로써 웹 서버는 사용자의 행동에 대한 정보를 얻을 수 있고, 특정 페이지로부터의 유입 경로나 링크 클릭 등을 추적할 수 있습니다. Referer 헤더는 일부 보안 및 개인 정보 보호 문제를 야기할 수 있으며, 때로는 보안 상의 이유로 사용하지 않을 수도 있습니다. 웹 개발자가 웹 사이트의 보안을 강화하거나 사용자의 개인 정보를 보호해야 할 때는 Referer 헤더를 사용하지 않도록 설정할 수 있습니다. 이렇게 하면 Referer 헤더가 요청에 포함되지 않거나 빈 값을 가지게 됩니다.

• User-Agent는 유저 에이전트 애플리케이션 정보로 HTTP 요청 헤더 중 하나로, 웹 브라우저나 클라이언트 애플리케이션이 서버에게 자신의 소프트웨어와 버전, 운영체제 등의 정보를 전달하는 역할을 합니다. 이 정보를 통해 서버는 요청을 보낸 클라이언트의 특성과 기능을 파악하여 적절한 응답을 제공할 수 있습니다.

    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
    (KHTML, like Gecko) Chrome/94.0.4606.61 Safari/537.36

위 예시에서 "Mozilla/5.0"은 클라이언트가 Mozilla 기반의 웹 브라우저를 사용한다는 것을 나타내며, "Windows NT 10.0; Win64; x64"는 사용자의 운영체제 정보입니다. "AppleWebKit/537.36"은 웹 킷 엔진의 버전을 의미하고, "Chrome/94.0.4606.61"은 브라우저의 버전을 나타냅니다. "Safari/537.36"은 브라우저가 Safari 엔진도 사용한다는 것을 의미합니다.

User-Agent 정보를 이용하여 서버는 클라이언트의 특성에 맞는 콘텐츠를 제공하거나, 웹 사이트의 호환성을 유지하기 위해 필요한 처리를 할 수 있습니다. 또한 이 정보를 이용하여 사용자의 기기나 브라우저 등을 파악하여 통계를 수집하거나 분석하는 용도로도 활용될 수 있습니다. 하지만 사용자의 개인정보 보호를 위해 브라우저는 사용자 에이전트 문자열을 사용자가 컨트롤할 수 있도록 하여 원치 않는 추적을 방지할 수 있게끔 설계되어 있습니다.

• Host : 요청하는 호스트(도메인)의 이름을 나타냅니다. 하나의 웹 서버가 여러 도메인에 대해 서비스하는 경우 유용하게 사용됩니다. HOST 헤더는 요청에서 사용되는 필수적입니다. 하나의 서버에서 여러 개의 웹 사이트를 호스팅하는 경우, Host 헤더를 사용하여 클라이언트가 어떤 도메인으로 요청을 보내는지를 구분할 수 있습니다. 서버는 이를 통해 요청을 받은 후 해당 도메인에 맞는 웹 사이트의 콘텐츠를 반환할 수 있습니다.
  
  
• Location : HTTP 응답 헤더 중 하나로, 클라이언트가 요청한 리소스가 다른 위치에 있을 경우 리다이렉션(다른 곳으로 이동)을 알려주는데 사용됩니다. 즉, 서버가 클라이언트에게 요청한 리소스의 위치를 새로운 URL로 바꿔서 제공할 때 Location 헤더를 사용합니다.예를 들어, 클라이언트가 *http://example.com/old-page를 요청했지만 이 페이지가 http://example.com/new-page로 이동되었다면, 서버는 다음과 같은 응답을 반환할 수 있습니다.
  
  
• 보통 Location 헤더는 HTTP 상태 코드 3xx (리다이렉션)와 함께 사용되며, 클라이언트는 이 헤더를 확인하여 새로운 URL로 다시 요청을 보내게 됩니다. 리다이렉션은 클라이언트가 원래 요청한 리소스의 위치가 변경되었거나, 보안 등의 이유로 다른 URL로 이동해야 할 때 사용됩니다.

Header filed 작성 문법
📋 field-name(아래에서는 Host) ” : “ OWS field-value OWS (ows : 띄어쓰기 허용)

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담고있습니다.
ex) 메세지 바디의 내용, 메세지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등

대표적인 용도는 아래와 같습니다.

1. 컨텐츠 관련 헤더: 컨텐츠 유형(Content-Type), 컨텐츠 길이(Content-Length) 등의 정보를 포함합니다.
   
   
2. 캐시 관련 헤더: 캐시의 동작을 제어하는 헤더로, 캐시 지시자(Cache-Control), 만료 날짜(Expires) 등을 포함합니다.
   
   
3. 인증과 보안 관련 헤더: 사용자 인증과 보안에 관련된 정보를 담고 있으며, Authorization, Set-Cookie 등이 있습니다.
   
   
4. 요청과 응답 관련 헤더: 요청과 응답의 상태와 메타 정보를 포함합니다. 예를 들어, Accept-Language, User-Agent 등이 있습니다.
   
   
5. 리다이렉션 관련 헤더: 리다이렉션 정보를 제공하는 헤더로, Location, Refresh 등이 있습니다.
   
   
6. 요청 조건 관련 헤더: 서버에게 요청에 대한 조건을 지정하는 헤더로, If-Modified-Since, If-None-Match 등이 있습니다.
   
   
7. 프록시 관련 헤더: 프록시 서버 동작을 제어하는 헤더로, Via, Proxy-Authenticate 등이 있습니다.
   
   
   

메세지 본문 (message Body)을 통해 표현 데이터를 전달합니다. 표현은 요청이나 응답에서 전달할 실제 데이터이며, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공합니다. (데이터 유형(html, json), 데이터 길이, 압축 정보 등) / 표현 헤더는 전송, 응답 둘 다에서 사용이 가능합니다.

📋 HTTP 헤더의 종류 1. 표현 헤더 & 표현 데이터

표현 헤더(Representation Header)는 HTTP 응답 메시지의 헤더 부분에 포함되는 정보로, 서버가 클라이언트에게 제공하는 리소스(Representation)의 특성을 설명합니다. 표현 헤더는 리소스 자체의 특성이나 리소스와 관련된 메타데이터 등을 포함하며, 클라이언트는 이를 통해 리소스를 적절하게 해석하고 처리할 수 있습니다.

• Content-Type : 응답 본문(페이로드)의 미디어 타입을 지정합니다. 이 헤더는 서버가 클라이언트에게 전달하는 컨텐츠의 종류를 나타냅니다. 예를 들어, "Content-Type: application/json"은 응답 본문이 JSON 형식임을 나타냅니다.
  
  
• Content-Length : 응답 본문의 길이를 바이트 단위로 지정합니다. 이 헤더는 클라이언트가 응답 본문의 크기를 미리 알 수 있도록 합니다.
  
  
• Content-Encoding : 응답 본문의 압축 방식을 지정합니다. 클라이언트는 이 헤더를 통해 응답 본문이 압축되어 있다면 이를 해제하여 사용할 수 있습니다. 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제합니다. ex) gzip , deflate, identity
  
  
• Content-Language : 응답 본문의 언어를 지정합니다. 클라이언트는 이 헤더를 통해 응답 본문의 언어를 인식하여 적절히 표시할 수 있습니다. 표현 데이터의 자연언어를 표현합니다. ex) ko, en, en-US 국가별 공식 사이트에 접속하면 자기한테 맞는 언어로 변경 시에 확인할 수 있습니다.

표현 헤더는 클라이언트와 서버 간의 컨텐츠 교환에 중요한 역할을 수행하며, 클라이언트는 이러한 헤더를 이해하고 적절히 활용하여 리소스를 처리합니다.

📋 HTTP 헤더의 종류 2. 협상 헤더 (Content Negotitation)

협상 헤더(Content Negotiation) 는 클라이언트와 서버 간에 어떤 컨텐츠 타입(미디어 타입)을 사용할 것인지 협상하기 위해 사용되는 HTTP 헤더입니다. 클라이언트가 요청한 리소스에 대해 서버가 여러 형식의 컨텐츠를 가지고 있을 때, 클라이언트가 선호하는 컨텐츠 타입을 알려주고 서버는 해당 요청에 가장 적합한 컨텐츠 타입을 선택하여 응답합니다.

• Accept: 클라이언트가 선호하는 컨텐츠 타입을 지정합니다. 예를 들어, "Accept: application/json"은 클라이언트가 JSON 형식의 컨텐츠를 선호한다는 것을 의미합니다.
  
  
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩을 지정합니다.
  
  
• Accept-Language: 클라이언트가 선호하는 언어를 지정합니다. 서버는 이를 참고하여 적절한 언어로 된 컨텐츠를 선택하여 응답합니다. Quality Values 또는 Q-values는 HTTP 요청 및 응답 헤더에서 사용되는 매개변수로, 클라이언트가 선호하는 콘텐츠 유형 또는 언어를 표현하는 데 사용됩니다.
  Quality Value는 0과 1 사이의 실수 값으로 표현되며, 1에 가까울수록 클라이언트가 해당 미디어 타입을 더 선호한다는 것을 나타냅니다. 예를 들어, Accept: application/json;q=0.8, text/html;q=0.9 는 클라이언트가 JSON을 0.8의 우선 순위로, HTML을 0.9의 우선 순위(더 높은 우선순위)로 선호한다는 것을 나타냅니다.
  
  
• Accept-Encoding: 클라이언트가 선호하는 컨텐츠 압축 방식을 지정합니다. 서버가 지원하는 압축 방식 중에서 클라이언트가 선호하는 방식을 선택하여 압축된 컨텐츠를 제공할 수 있습니다.

협상 헤더를 사용하면 클라이언트는 자신이 원하는 컨텐츠 타입이나 언어 등을 명시하여 서버에 전달할 수 있습니다. 서버는 클라이언트의 요청을 기반으로 적절한 형식의 컨텐츠를 선택하여 응답하므로, 클라이언트와 서버 간의 상호작용이 더 유연해집니다. 이를 통해 다국어 지원, 다양한 미디어 타입 지원 등을 할 수 있습니다.

✍️ HTTP 전송 방식

1. 압축 전송(Compression Transfer) : 압축 전송은 HTTP 메시지를 클라이언트와 서버 간에 압축하여 전송하는 방식입니다. 이를 통해 데이터의 크기를 줄이고 전송 시간과 대역폭을 절약할 수 있습니다. 일반적으로 클라이언트가 요청 헤더에 “Content-Encoding"을 지정하여 어떤 압축 알고리즘을 지원하는지 서버에 알려주고, 서버는 해당 알고리즘 중에서 선택하여 압축하여 응답을 전송합니다. 대표적으로 gzip과 deflate 압축 알고리즘이 사용됩니다.
   
   
2. 분할 전송(Chunked Transfer) : 분할 전송은 큰 크기의 데이터를 여러 개의 작은 조각(Chunk)으로 나누어 전송하는 방식입니다. 이를 통해 데이터가 일부분만 도착해도 빠르게 전송되어 사용자 경험을 향상시킬 수 있습니다. 일반적으로 서버가 요청 헤더에 "Transfer-Encoding: chunked"를 포함하여 응답을 분할 전송한다고 알려주며, 클라이언트는 이를 확인하고 조각별로 데이터를 수신합니다.
   
   
3. 단순 전송(Simple Transfer) : 단순 전송은 HTTP 메시지를 그대로 전송하는 방식입니다. 압축이나 분할 없이 요청과 응답을 전체적으로 그대로 전송합니다. 일반적으로 압축이나 분할이 필요하지 않을 경우에 사용됩니다.
   
   
4. 범위 전송(Range Request) : HTTP 요청에서 클라이언트가 서버로부터 원하는 리소스의 특정 범위만을 요청하는 기능입니다. 클라이언트가 요청 헤더에 "Range"를 지정하여 원하는 범위를 표시하고, 서버는 해당 범위만을 응답으로 보내주는 방식으로 동작합니다.

HTTP 상태 코드는 클라이언트가 서버에 HTTP 요청을 보내고, 서버가 해당 요청을 처리한 결과를 클라이언트에게 반환할 때 사용되는 3자리 숫자로 이루어진 코드입니다. 각 상태 코드는 요청의 성공, 실패 또는 처리 상태를 나타내는 역할을 합니다.

1xx (Informational) : 요청이 받아들여지고 처리 중임을 나타냅니다. (거의 사용 X)
2xx (Success) : 요청이 성공적으로 처리되었음을 나타냅니다.
3xx (Redirection) : 요청을 완료하기 위해 추가 작업이 필요함을 나타냅니다.
4xx (Client Errors) : 클라이언트의 요청에 오류가 있음을 나타냅니다.
5xx (Server Errors) : 서버가 요청을 처리하는 동안 오류가 발생했음을 나타냅니다.

만약 모르는 상태 코드가 나타난다면 클라이언트는 상위 상태코드로 해석해서 처리해줍니다.
예를 들어 299 ??? → 2XX로 해석하여 (Successful)을 의미한다고 생각하면 됩니다.

1. 2xx (Success) : 성공 (클라이언트의 요청을 성공적으로 처리)
   200 OK: 요청이 성공적으로 처리되었음을 나타냅니다.
   201 Created : 요청에 의해 새로운 리소스가 생성되었음을 나타냅니다. 자원생성, Location 헤더 有 204 No Content: 요청은 성공적으로 처리되었지만, 응답으로 반환할 내용이 없음을 나타냅니다.
   204 No Content ex) 웹 브라우저에서 웹 문서 편집기를 사용할 때 저장을 하게 되면 데이터가 POST를 통해 서버로 전달되었지만 , 응답할 본문을 받을 필요는 없기 때문에 결과 내용은 없이 204 메세지만으로 성공인식이 가능
   
   
2. 3xx (Redirection) : 리다이렉션 (요청을 완료하기 위해 추가 조치를 요청)
   웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 , Location 위치로 자동 이동합니다.
   
   301 Moved Permanently : 요청한 리소스의 URI가 영구적으로 새로운 URI로 변경되었음을 나타냅니다. 클라이언트는 새로운 URI를 사용하여 요청을 다시 시도해야 합니다.
   302 Found: 요청한 리소스의 URI가 일시적으로 새로운 URI로 변경되었음을 나타냅니다. 클라이언트는 새로운 URI를 사용하여 요청을 다시 시도해야 합니다. (주로 리다이렉트에 사용)
   303 See Other : 서버가 클라이언트의 요청을 완료하였으며, 리소스가 다른 URI에 있을 때 사용됩니다. 주로 POST 요청의 결과를 리다이렉트할 때 사용됩니다.
   304 Not Modified : 클라이언트가 이전에 이미 요청한 리소스가 변경되지 않았음을 서버가 알고 있을 때 사용됩니다. 클라이언트가 캐시된 버전을 사용하여 리소스를 가져오도록 유도합니다. 이 때, 서버는 실제 리소스의 내용을 응답으로 보내지 않고, ‘ETag’ 또는 ‘Last-Modified’ 헤더 등을 사용하여 클라이언트의 캐시를 업데이트 할 수 있습니다.
   307 TemporaryRedirect : 클라이언트의 POST 요청은 리다이렉트된 URI로 재전송되지만, 메서드는 변경되지 않습니다. 즉, 클라이언트의 POST 요청은 리다이렉트된 URI에서도 POST로 처리됩니다.
   308 Permanent Redirect : 301 Moved Permanently와 비슷하지만, POST 요청에서의 처리 방식이 다릅니다.클라이언트의 POST 요청은 리다이렉트된 URI로 재전송되며, 메서드도 변경됩니다. 즉, 클라이언트의 POST 요청은 리다이렉트된 URI에서는 GET으로 처리됩니다.
   
   - 영구 리다이렉션(301, 308) : 특정 리소스의 URI가 영구적으로 이동 ex) /event → /new-event
   리소스의 URI가 영구적으로 이동한 경우, 원래의 URL을 사용하지 않아 검색 엔진 등에서도 변경을 인지합니다. 301 리다이렉트시 요청 메서드가 GET으로 변하고 , 본문이 제거될 수 있습니다. 308의 기능은 301과 동일하지만, 308은 요청 메서드와 본문을 똑같이 유치하고, 처음 POST로 보내면 리다이렉트도 동일합니다.
   
   - 일시 리다이렉션(302, 303, 307) : 웹 서버가 클라이언트의 요청을 일시적으로 다른 URI로 리다이렉트하는 것
   검색 엔진 등에서 URL을 변경하면 안됩니다. 302, 303, 307의 기능은 거의 동일하지만, 302는 본문이 제거될 수 있다는 점, 303은 요청메서드가 GET으로 변경되는 점, 307은 요청 메서드와 본문을 유지(요청 메서드를 변경하면 안됨)하는 차이점 등이 있습니다.
   
   PRG : Post / Redirect / Get
   ex ) POST로 주문 후에 웹 브라우저를 새로고침 하면 새로고침은 다시 요청되나 , 중복으로 주문 될 수 있습니다.  
   
   PRG는 Post-Redirect-Get의 약자로, 웹 애플리케이션에서 폼 데이터를 안전하게 제출하는 방법 중 하나입니다. 이러한 방식은 사용자 경험을 향상시키고 중복 폼 제출로 인한 문제를 방지하는 데 도움이 됩니다.
   
   Post (제출) : 사용자가 폼을 작성하고 제출합니다. 이 때, HTTP POST 메서드를 사용하여 데이터를 서버로 보냅니다.
   Redirect (리다이렉트) : 서버는 폼 데이터를 처리한 후, 적절한 결과 페이지로 리다이렉트(이동)합니다. 이때, HTTP 상태 코드 303 See Other 또는 307 Temporary Redirect를 사용하여 리다이렉트합니다.
   Get (얻기) : 리다이렉트된 결과 페이지를 사용자에게 보여줍니다. 이때, HTTP GET 메서드를 사용하여 페이지를 요청합니다.
   
   PRG 패턴을 사용하면 사용자가 새로 고침 또는 뒤로 가기를 눌렀을 때 중복 제출을 방지할 수 있습니다. 폼 데이터가 POST로 제출되기 때문에 브라우저에서 다시 로드할 경우 폼 데이터를 다시 제출하는 것을 방지합니다. 대신 리다이렉트를 통해 결과 페이지로 이동하여 사용자에게 정상적인 사용자 경험을 제공합니다.
   
   PRG 패턴은 웹 애플리케이션에서 폼 처리와 리다이렉트를 결합하여 사용자가 의도하지 않은 작업의 반복을 방지하고 사용성을 향상시키는 데에 널리 사용되는 패턴 중 하나입니다.

📋 기타 리다이렉션 304 Not Modified : 클라이언트가 이전에 이미 요청한 리소스가 변경되지 않았음을 서버가 알고 있을 때 사용합니다. 클라이언트에게 리소스가 수정되지 않았음을 알려주기 때문에 클라이언트는 로컬 PC에 저장된 캐시를 재사용 할 수 있습니다. 304 응답은 응답에 메세지 바디를 포함하면 안됩니다

특수 리다이렉션 : 결과 대신 캐시를 사용

3. 4xx (Client Error) : 클라이언트 오류 ( 오류의 원인이 클라이언트)
400대 오류는 클라이언트의 요청이 이미 잘못되어있기 때문에 똑같은 재시도가 계속 실패 클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 상태입니다.

400 Bad Request : 클라이언트의 요청이 잘못되었거나 서버가 요청을 이해할 수 없는 경우를 나타냅니다. 요청 구문, 주고받는 메세지에서의 오류가 발생했을 때이고 클라이언트는 요청 내용을 다시 검토하고 보내야 합니다. (ex . 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때 )

401 Unauthorized : 인증되지 않은 사용자가 보호된 리소스에 접근하려고 시도한 경우를 나타냅니다. 401 오류 발생 시 클라이언트는 응답에 WWW-Authenticate 헤더와 함께 인증 정보를 제공해야 합니다. 

Authentication(인증) : 본인이 누구인지 확인 ( 로그인 )
Authorization(인가) : 권한 부여 ( Admin 권한 처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)

403 Forbidden : 인증된 사용자라도 해당 리소스에 접근 권한이 없는 경우를 나타냅니다. 접근이 거부됩니다.

404 Not Found : 요청한 리소스를 찾을 수 없음을 나타냅니다. 요청한 URI가 서버에 존재하지 않거나 라우팅되지 않았을 때 발생합니다. 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을때 발생합니다.

4. 5xx (Server Error) : 서버 오류 (서버문제로 오류 발생)

500 Internal Server Error : 서버 내부에서 오류가 발생한 경우(대부분)를 나타냅니다. 서버에 오류가 발생하여 요청을 처리할 수 없는 상태입니다.

503 Service Unavailable : 서버가 현재 요청을 처리할 수 없는 상태이거나 유지보수 중인 경우를 나타냅니다. 잠시 후에 다시 시도하라는 의미를 갖습니다. 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리 할 수 없는 상황입니다.서버에 문제가 있기 때문에 재시도하면 성공할 수도 있습니다 (복구가 되는 상황)

HTTP 메서드의 속성은 다음과 같습니다.

안전(Safe Methods), 멱등(Idempotent Methods), 캐시가능(Cacheable Methods)

1. 안전(Safe): 안전한 메서드는 서버의 상태를 변경하지 않고 읽기 작업만 수행하는 메서드입니다. GET 메서드가 단순한 조회만 하기 때문에 가장 일반적인 안전한 메서드입니다. 안전한 메서드는 동일한 요청을 여러 번 보내더라도 서버의 상태나 데이터를 변경하지 않으므로, 캐싱이나 프록시 서버에 의해 재사용될 수 있습니다.
   
   만약 계속 호출이 되어서 로그같은게 쌓인다면 장애가 발생할 수 있는데, 안전이라는 점은 해당 리소스의 상태변화에 대해서만 고려하기때문에 장애가 발생할 경우는 고려하지 않습니다.
   
   
2. 멱등(Idempotent): 멱등한 메서드는 같은 요청을 여러 번 보내더라도 항상 동일한 결과를 얻을 수 있는 메서드입니다. GET, HEAD, PUT, DELETE 메서드는 멱등한 메서드입니다. 예를 들어, 같은 DELETE 요청을 여러 번 보내도 리소스는 한 번만 삭제됩니다. 이러한 특성은 재시도 등에 유용하며, 네트워크 문제 등으로 인해 중복 요청이 발생해도 안전하게 처리할 수 있습니다.
   GET : 한번 조회하든, 두 번 조회하든 같은 결과가 조회됩니다 PUT : 전달받은 결과를 대체하기 때문에 같은 요청을 여러번 해도 최종 결과는 같습니다. POST : 멱등이 아닙니다. 두 번 호출하면 같은 결제가 중복해서 발생할 수 있습니다.멱등은 자동 복구 메커니즘에 사용이 가능합니다. 그러나 외부 요인(다른사용자가 데이터를 변경한 후 PUT 한 경우)으로 중간에 리소스가 변경되는 것까지는 고려하지 않습니다.
   
   
3. 캐시 가능(Cacheable): 캐시 가능한 메서드는 응답 결과를 클라이언트나 중간 프록시 서버에 캐시할 수 있는 메서드입니다. GET, HEAD 메서드는 일반적으로 캐시 가능한 메서드입니다. 캐시 가능한 메서드는 동일한 요청에 대한 응답을 캐시에서 가져와 처리할 수 있으므로, 네트워크 대역폭을 줄이고 응답 속도를 향상시킬 수 있습니다. 응답 결과를 캐시에서 사용할 수 있는가!
   
   
4. 적절한 요청 본문(Well-Defined Request Body): 일부 메서드는 요청 본문에 데이터를 포함하여 서버에 전송할 수 있습니다. POST, PUT, PATCH 메서드는 요청 본문에 데이터를 포함할 수 있는 메서드입니다. 요청 본문은 클라이언트가 서버에 데이터를 제공하거나 업데이트할 때 사용됩니다.
   
   
5. 안전하지 않음(Unsafe): 안전하지 않은 메서드는 서버의 상태나 데이터를 변경할 수 있는 메서드입니다. POST, PUT, PATCH, DELETE 메서드는 안전하지 않은 메서드입니다. 이러한 메서드를 사용할 때는 주의해야 하며, 적절한 권한과 인증을 통해 보안을 유지해야 합니다.

🎈HTTP 메서드 활용

✅ 클라이언트에서 서버로 데이터 전송

• 쿼리 파라미터를 통한 데이터 전송
  쿼리 파라미터를 통한 데이터 전송은 간편하고 일반적으로 많이 사용되는 방식입니다. GET 에서 많이 사용하고 정렬 필터(검색어)를 사용할 때 사용합니다.하지만 보안에 민감한 정보(예: 비밀번호)는 URL에 노출되므로 주의해야 합니다. 민감한 정보를 전달해야 하는 경우에는 요청 본문이나 다른 전송 방식을 사용하는 것이 좋습니다.
  
  쿼리 파라미터(Query Parameters)를 통한 데이터 전송은 URL에 데이터를 포함하여 서버로 전달하는 방식입니다. 클라이언트는 URL의 끝에 ?를 추가하고, key=value 형식으로 데이터를 전달합니다. 여러 개의 쿼리 파라미터를 전달할 때는 &로 구분합니다.
  
  
• 메세지 바디를 통한 데이터 전송
  데이터를 HTTP 요청의 본문에 담아서 전달하는 방식입니다. 주로 POST, PUT, PATCH 메서드에서 사용됩니다. 클라이언트는 요청 본문에 데이터를 포함하고, 콘텐트 유형(Content-Type) 헤더를 통해 데이터의 형식(MIME 타입)을 지정합니다. 서버는 요청 본문을 읽어서 처리할 수 있습니다. 데이터의 형식에는 JSON, XML, 폼 데이터 등이 있습니다.
  
  클라이언트에서 서버로 데이터를 전송하는 4가지 상황
  1. 정적 데이터 조회 (쿼리 파라미터 미사용) : resource/path를 통해 전달 이미지나 정적 텍스트 문서를 전달할 때 주로 사용되며 , 일반적으로 쿼리 파라미터 없이 리소스 경로로 단순하게 조회가 가능합니다.
     
     
  2. 동적 데이터 조회( 쿼리파라미터 사용) : 주로 검색 or 게시판 목록에서 정렬 필터 (검색어) 추가 데이터들이 파라미터로 넘어갑니다. 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용합니다. 조회는 GET을 사용하며, GET은 쿼리 파라미터를 사용해서 데이터를 전달합니다.
     
     
  3. HTML 폼 데이터(Form Data): HTML 폼의 입력 필드에서 제출된 데이터를 전송하는 방식입니다. 폼 데이터는 application/x-www-form-urlencoded content-Type으로 전송됩니다. 클라이언트는 key=value 형식으로 데이터를 인코딩하여 요청 HTTP BODY(본문)에 포함시킵니다. 서버는 이러한 폼 데이터를 읽어서 처리할 수 있습니다. GET, POST만 지원합니다. 다른 Content-Type으로는 multipart/form-data 파일 업로드와 같은 바이너리 데이터 전송시 사용되며, 다른 종류의 여러 파일과 폼의 내용을 함께 전송이 가능합니다.
     
     
  4. HTML API 전송요청 본문에 데이터를 전송하는 경우에는 데이터의 형식에 따라 적절한 Content-Type 헤더를 설정해야 합니다. 일반적으로 JSON 데이터를 전송할 때는 Content-Type: application/json 헤더를 설정하고, 폼 데이터를 전송할 때는 Content-Type: application/x-www-form-urlencoded 헤더를 설정합니다.
     
     또한, HTTP API에서는 주로 JSON 형식으로 데이터를 주고받는 RESTful API가 많이 사용됩니다. JSON 형식은 데이터를 가볍고 구조화된 방식으로 전송할 수 있으며, 대부분의 프로그래밍 언어에서 JSON을 쉽게 처리할 수 있습니다.서버 to 서버로 데이터가 전송될 때 많이 사용되며 , 백엔드 시스템 통신의 경우입니다.
     
     앱 클라이언트 인 아이폰, 안드로이드에서 전송할 때도 사용합니다. 웹 클라이언트에서도 사용되는데, HTML에서 Form 전송 대신 자바 스크립트를 통한 통신에 사용됩니다. (AJAX) ex. React, VueJs 같은 웹 클라이언트와 API 통신을 합니다.
     
     

          
          <h3>로그인 : 아이디 비밀번호 입력</h3>
                <form method="post" action = "/save">
                    <!-- 입력된 userId를 저장할 수 있도록 하는 HTML FROM DATA 전송기법 -->
                    <label for = "userid"> 아이디 : </label>
                    <input type = "text" name = "id" id="userid"><br>
                </form> <br>

            ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
            웹 브라우저가 요청한 HTTP 메세지
            POST/save HTTP1/1.1
            Host: localhost:8080
            Content-Type : application/x-www.form-urlencoded

            userid=kim

1. 원격 프로그램 실행

브라우저와 원격프로그램을 실행하기 위한 (WAS) 브라우저에서 URL을 입력 후(ip주소) 호출을 한다면 해당 요청을 톰캣이 받아서 8080포트를 실행합니다.

2 . @Controller와 @RequestMapping이란 ?

@Controller와 @RequestMapping은 스프링 프레임워크에서 웹 애플리케이션의 컨트롤러를 정의하고 요청 매핑을 처리하는 데 사용되는 어노테이션입니다.

1. Controller : @Contoller 어노테이션은 클래스 레벨에 적용되며, 해당 클래스가 스프링 MVC의 컨트롤러임을 나타냅니다.
   스프링은 이 클래스를 컨트롤러로 인식하고 요청을 처리하는 데 필요한 기능을 제공합니다.
   
   
2. RequestMapping (/hello) : @RequestMapping 어노테이션은 메서드 레벨에 적용되며, 해당 메서드가 특정 요청 경로와 연결되는 것을 나타냅니다.
   즉, 클라이언트의 요청이 특정 URL 경로로 들어오면 해당 메서드가 실행되어 요청을 처리하게 됩니다.@RequestMapping 어노테이션은 여러 가지 속성을 가지고 있어서 경로 매칭, HTTP 메서드 제한, 요청 헤더나 파라미터 검증 등 다양한 기능을 설정할 수 있습니다.

            package com.fastcampus.ch2;

            import java.util.Calendar;


            //년 월 일을 입력하면 요일을 알려주는 프로그램
            public class YoilTeller {

                public static void main(String[] args) {
                
                    //1. 입력
                    String year = args[0];
                    String month = args[1];
                    String day = args[2];


                    //문자열이니깐 숫자로 형변환을 함
                    int yyyy = Integer.parseInt(year);
                    int mm = Integer.parseInt(month);
                    int dd = Integer.parseInt(day);
                    

                    //2. 작업
                    Calendar cal = Calendar.getInstance();
                    cal.set(yyyy,mm-1, dd);
                    

                    //요일을 알아낼 수 있는데 1.일요일, 2. 월요일 ..
                    int dayOfweek = cal.get(Calendar.DAY_OF_WEEK);
                    char yoil = "일월화수목금토".charAt(dayOfweek);
                    

                    //3.출력
                    System.out.println(year + "년" + month + "월" + day + "일은");
                    System.out.println(yoil + "요일입니다.");
                }

            }

java 인터프리터가 YoilTeller안의 메인 클래스를 호출하면 이후에 입력된 2022 12 2 값들을 가지고 배열을 만듭니다. String 배열이고 args[0] = 2022 , args[1] = 12 , args[2] = 2 로 담기면서 main 메서드 안에서 해당 배열이 사용이 가능합니다.

원격 프로그램을 브라우저로 URL을 입력하면 톰캣이 HttpServletRequest 객체를 만든 후 요청한 정보를 담습니다. HttpServeletRequest 변수(객체가 담긴 변수) 담은 후 매개변수로 메인메서드에 전달해줍니다.

3. HttpServeletRequest란 ❓

HttpServletRequest는 서블릿 컨테이너에서 HTTP 요청을 처리하기 위한 객체입니다.
이 객체를 통해 클라이언트로부터 온 HTTP 요청의 정보를 얻을 수 있습니다. HttpServletRequest는 javax.servlet.http 패키지에 포함되어 있습니다.

HttpServletRequest 객체는 클라이언트의 IP 주소, 쿠키 정보, 인증과 관련된 정보 등 다양한 HTTP 요청의 속성과 값을 얻을 수 있도록 메서드와 속성을 제공합니다.
이를 통해 서블릿에서 클라이언트의 요청을 분석하고 처리할 수 있습니다.

HttpServletRequest 객체는 HTTP 요청에 관련된 여러 가지 정보를 제공합니다. 몇 가지 중요한 메서드와 속성은 다음과 같습니다:

getScheme() : HttpServletRequest 인터페이스의 메서드로, 클라이언트의 요청에 사용된 프로토콜 스키마를 반환합니다. 프로토콜 스키마는 요청 URL의 앞부분에 위치한 프로토콜의 이름을 나타냅니다. 보통 http를 출력해줍니다.

getMethod() : HTTP 요청의 메서드를 반환합니다. 예를 들어, "GET", "POST", "PUT", "DELETE" 등의 값을 반환할 수 있습니다.
getRequestURL() : 클라이언트가 보낸 요청의 URL을 반환합니다.
getProtocol() : HTTP 프로토콜의 버전을 반환합니다. 예를 들어, "HTTP/1.1"과 같은 값을 반환할 수 있습니다.
getParameter(String name) : 지정된 이름의 요청 매개변수 값을 반환합니다. HTTP 요청의 쿼리 문자열이나 폼 데이터에서 해당 이름을 가진 매개변수 값을 얻을 수 있습니다.
getHeader(String name) : 지정된 이름의 HTTP 헤더 값을 반환합니다. 예를 들어, "User-Agent", "Content-Type" 등의 값을 얻을 수 있습니다.
getSession() : 요청과 관련된 세션 객체를 반환합니다. 세션을 사용할 수 있는 경우 세션 객체를 반환하고, 세션을 사용할 수 없는 경우 null을 반환합니다.

getQueryString() 메서드는 HttpServletRequest 인터페이스의 메서드로, 요청 URL의 쿼리 문자열을 반환합니다. 쿼리 문자열은 URL의 물음표(?) 뒷부분에 위치하며, key=value 형식으로 매개변수와 값이 쌍으로 구성되어 있습니다.

예를 들어, http://example.com/search?q=keyword&page=1와 같은 URL이 있다면, getQueryString() 메서드는 "q=keyword&page=1"을 반환합니다. 이 메서드는 쿼리 문자열이 없는 경우 null을 반환합니다.

getQueryString() 메서드를 사용하여 클라이언트가 전송한 요청의 쿼리 문자열을 분석하고 필요한 매개변수를 추출하는 등의 작업을 수행할 수 있습니다.

💡 동적 리소스 vs 정적 리소스

서버가 제공하는 리소스에는 크게 2가지가 있습니다. 동적 리소스(Dynamic Resources)와 정적 리소스(Static Resources)는 웹 개발에서 사용되는 개념입니다.

1. 동적 리소스(Dynamic Resources)
   동적 리소스는 클라이언트의 요청에 따라 서버에서 동적으로 생성되는 리소스를 말합니다. 서버 측 코드(예: PHP, Java, Python)를 사용하여 요청을 처리하고, 그에 따라 동적으로 HTML, 데이터베이스 쿼리 결과, API 응답 등을 생성합니다. 동적 리소스는 실행 할 때마다 결과가 변하며, 클라이언트의 요청에 따라 다양한 데이터를 가공하거나 개인화된 콘텐츠를 제공하는 데 사용됩니다. 예를 들어, 사용자가 로그인한 후에만 볼 수 있는 사용자 정보나 , 스트리밍 등이 동적으로 생성되는 웹 페이지가 동적 리소스에 해당합니다.
   
   
2. 정적 리소스(Static Resources)
   정적 리소스는 서버에 이미 저장되어 있는 파일이며, 서버에서 그대로 클라이언트에게 제공됩니다. 정적 리소스는 서버 측 코드의 개입 없이 클라이언트에게 제공되므로 속도가 빠르고 캐싱이 가능합니다. 주로 HTML, CSS, JavaScript, 이미지, 비디오, 오디오 파일 등이 정적 리소스에 해당합니다. 정적 리소스는 서버에 저장된 그대로의 내용을 클라이언트에 전달하므로, 클라이언트의 요청에 따라 동적으로 변하지 않습니다.
   
   일반적으로 동적 리소스는 서버에서 동적으로 처리되어야 하는 데이터를 다루고, 정적 리소스는 클라이언트에게 제공되는 파일들을 나타냅니다. 동적 리소스는 서버의 로직에 의해 동적으로 생성되므로 처리 비용이 더 많이 소요되지만, 유연성과 개인화된 콘텐츠 제공이 가능합니다. 정적 리소스는 캐싱과 같은 기술을 활용하여 빠른 응답과 성능 향상을 도모할 수 있습니다.
   
   
3. 클라이언트와 서버

클라이언트(Client)와 서버(Server)는 네트워크 환경에서 상호작용하는 컴퓨터 시스템입니다.

1. 클라이언트(Client) 클라이언트는 사용자가 직접 사용하는 컴퓨터나 디바이스를 말합니다. 일반적으로 웹 브라우저(예: Chrome, Firefox)가 클라이언트의 역할을 수행합니다. 클라이언트는 사용자의 요청을 생성하고 서버로 전송합니다. 사용자는 클라이언트를 통해 서버에 요청을 보내고, 서버로부터 응답을 받아 화면에 결과를 표시합니다. 클라이언트는 사용자 인터페이스를 제공하며, 서버와의 통신을 위한 요청을 생성하고 응답을 받는 역할을 수행합니다.
   
   
2. 서버(Server) 서버는 클라이언트의 요청을 받아 처리하고, 필요한 데이터나 리소스를 제공하는 컴퓨터나 시스템입니다. 서버는 클라이언트의 요청을 받아들여 해당 요청을 처리한 후, 클라이언트에게 응답을 보냅니다. 서버는 데이터베이스, 파일, 웹 페이지, 애플리케이션, API 등을 호스팅하고 관리하는 역할을 수행합니다. 서버는 네트워크를 통해 클라이언트와 통신하며, 클라이언트의 요청에 따라 동적으로 데이터를 생성하거나 처리할 수 있습니다.
   
   
3. 클라이언트와 서버는 클라이언트-서버 아키텍처를 구성하는 두 가지 주요 구성 요소입니다. 클라이언트는 사용자와 상호작용하며 사용자 인터페이스를 통해 요청을 생성하고 응답을 표시합니다. 서버는 클라이언트의 요청을 받아 처리하고 필요한 데이터나 서비스를 제공하여 클라이언트에게 응답합니다. 이렇게 클라이언트와 서버가 함께 동작하여 웹 애플리케이션, 웹 서비스, 모바일 애플리케이션 등 다양한 네트워크 기반의 애플리케이션을 구현할 수 있습니다.

• 서버의 종류 ( 어떤 서비스를 제공하냐에 따라 달라집니다. Email server / File server / Web server
  
  
• 1대의 PC에 다양한 서버가 사용되고 있을 때, 클라이언트가 전송한 IP주소로는 어떤 서버에 요청한건 지 구분할 수 없기때문에 IP주소 뒤에 꼭 포트번호를 기입하여 구분합니다. 예를 들면 대표전화번호랑 비슷한 개념입니다. (ex) 1588-8888 → 내선번호(담당자 별로 내선번호를 갖고 있게 되는 경우) ip:port# / 웹 서버는 기본으로 : 80을 사용하기 때문에 기본적으로는 생략이 가능합니다.
  
  
• 서버가 포트와 연결(바인딩) 되어 있어야만 소통이 가능합니다 . 서버가 포트를 리스닝하고 있다고도 표현합니다. 포트번호는 0 ~ 1023까지는 전부 예약되어 있기 때문에 쓸 수 없지만 그 이후의 번호는 그 이후의 6만개정도를 사용 가능합니다.

웹 애플리케이션 서버 (WAS) 란?

Web Application Server (WAS)는 웹 애플리케이션을 실행하고 관리하는 서버 소프트웨어입니다. 웹 애플리케이션은 클라이언트(웹 브라우저)에서 서버로 요청을 보내고, 서버에서는 해당 요청에 대한 처리를 수행하여 결과를 클라이언트에게 제공합니다. 이러한 웹 애플리케이션을 실행하기 위해 Web Application Server가 필요합니다.

1. 웹 애플리케이션 실행 환경 제공: Web Application Server는 웹 애플리케이션을 실행하기 위한 실행 환경을 제공합니다. 이 환경에는 필요한 라이브러리, 컴포넌트, 설정 파일 등이 포함됩니다. 또한, 다양한 프로그래밍 언어와 기술을 지원하여 개발자가 웹 애플리케이션을 개발할 수 있도록 합니다.
   
   
2. 요청 처리 및 분배: Web Application Server는 클라이언트로부터 받은 요청을 처리하고, 애플리케이션으로 전달합니다. 요청에 따라 적절한 애플리케이션 컴포넌트(서블릿, JSP 등)를 호출하고, 처리 결과를 다시 클라이언트에게 반환합니다. 또한, 부하 분산을 위해 여러 웹 애플리케이션 인스턴스 간에 요청을 분배할 수 있습니다.
   
   
3. 세션 및 상태 관리: 웹 애플리케이션은 클라이언트와 상호작용하면서 세션과 같은 상태 정보를 유지해야 할 수 있습니다. Web Application Server는 세션 관리를 지원하여 세션 데이터를 저장하고 관리합니다. 이를 통해 클라이언트와의 상태 유지 및 다중 서버 환경에서의 세션 공유가 가능해집니다.
   
   
4. 데이터베이스 연동: 대부분의 웹 애플리케이션은 데이터베이스와 연동하여 데이터를 저장하고 조회합니다. Web Application Server는 데이터베이스와의 연결 관리를 수행하고, SQL 문 실행 및 결과 처리를 지원합니다. 이를 통해 웹 애플리케이션은 데이터베이스와 손쉽게 상호작용할 수 있습니다.
   
   
5. 보안 및 인증: 웹 애플리케이션은 보안과 인증이 중요한 요소입니다. Web Application Server는 사용자 인증, 권한 관리, 데이터 암호화 등의 보안 기능을 제공합니다. 또한, 웹 애플리케이션의 취약점을 탐지하고 방어하기 위한 보안 설정을 제공합니다.
   
   
6. 확장성과 가용성: Web Application Server는 대량의 요청을 처리하고, 다중 서버 구성을 통해 확장성과 가용성을 제공합니다. 여러 대의 서버를 클러스터로 구성하거나 로드 밸런서를 사용하여 부하를 분산할 수 있습니다. 이를 통해 웹 애플리케이션의 성능과 신뢰성을 향상시킬 수 있습니다.
   
   

주요한 Web Application Server로는 Apache Tomcat, Jetty, IBM WebSphere, Oracle WebLogic, JBoss 등이 있습니다. 이러한 서버는 다양한 웹 애플리케이션 프레임워크(예: Java Servlet, JavaServer Pages, Ruby on Rails, Django 등)와 함께 사용되어 웹 애플리케이션을 실행하고 관리합니다.