728x90
반응형
728x90

 

 

 

 

서블릿이란 ❓

서블릿(Servlet)자바를 사용하여 웹 애플리케이션을 개발하기 위한 기술로, 웹 서버와 상호작용하여 동적인 웹 페이지를 생성하고 처리하는 자바 클래스입니다. 서블릿은 웹 서버에서 실행되며, 클라이언트의 요청에 따라 동적인 컨텐츠를 생성하여 응답으로 제공하는 역할을 수행합니다.

 

 

해당 버전과 종속성들을 추가한 후 프로젝트 파일을 생성 후 실행합니다. 내부의 톰캣 서버와 외부에서 불러온 서버를 실행할 수 있도록 패키지 생성은 War로 선택한 후 생성하면 됩니다.

Dependcy들이 설치된 사항을 볼 수 있는 build.gradle로 접속하여 plugins항목에 war로 생성이 잘 진행되었는지 확인해주세요

 

 

 

📋HTTPServletRequest

HttpServletRequest는 Java Servlet에서 HTTP 요청 정보를 담고 있는 객체입니다. 클라이언트가 서버로 HTTP 요청을 보낼 때, 이 HttpServletRequest 객체를 통해 요청의 다양한 정보를 서블릿에 전달합니다.

📋 HttpServletResponse

Java Servlet에서 HTTP 응답을 다루는 객체입니다. 클라이언트에게 서버로부터 전달되는 HTTP 응답을 생성하고 제공하는데 사용됩니다. 서블릿은 클라이언트의 요청을 받아 처리한 후, 이 HttpServletResponse 객체를 사용하여 적절한 응답을 생성하고 클라이언트에게 반환합니다.


HTTP 요청 메세지 전달 방법 - HttpServletRequest 기본 사용법


  1. GET - 쿼리 파라미터
    • 쿼리 파라미터는 URL에 다음과 같이 ? 를 시작으로 보낼 수 있습니다.
    • 여러 개의 파라미터를 전달할 경우 & 기호로 구분합니다. 검색,필터,페이징에서 많이 사용
    • 예: http://example.com/api/data?key1=value1&key2=value2

 

        /**
         * 1. 파라미터 전송 기능
         * http://localhost:8080/request-param?username=hello&age=20*/

        @WebServlet(name="requestParamServlet", urlPatterns = "/request-param")
        public class RequestParamServlet extends HttpServlet {

            @Override
            protected void service(HttpServletRequest req, HttpServletResponse resp) 
            throws ServletException, IOException {

                System.out.println("[전체 파라미터 조회] ----- start");
                req.getParameterNames().asIterator().forEachRemaining(paramName -> System.out.println(paramName + " = " + req.getParameter(paramName)));
                System.out.println("[전체 파라미터 조회] ----- end");
                System.out.println();


                System.out.println("[단일 파라미터 조회] ----- start");
                String username = req.getParameter("username");
                String age = req.getParameter("age");

                System.out.println("username = " + username);
                System.out.println("age = " + age);

                System.out.println("[단일 파라미터 조회] ----- end");
                System.out.println();


                System.out.println("[이름이 동일한 파라미터의 조회 ex) username이 여러개가 쿼리스트링으로 전달되는 경우] 배열로 만들어주며, 한번에 다 출력됨");
                String[] usernames = req.getParameterValues("username");
                for (String name : usernames) {
                    System.out.println("username = " + name);
                }

 

 

2. POST - HTML Form

  • HTML Form 을 사용해서 클라이언트에서 서버로 데이터 전송이 가능합니다.
  • contenty-type : application/x-www.form-urlencoded
  • 메세지 바디에 쿼리 파라미터 형식으로 전달 username=hello&age=20 예) 회원 가입, 상품 주문, HTML Form 사용

 

GET 방식일 때 사용했던 쿼리파라미터 형식이랑 HTML Form 방식은 유사합니다. Content-type이 적히는 것의 차이만 있지 형식이 같기 때문에 request.getParameter로 HTML Form 방식으로 전송된 데이터 조회 메서드를 그대로 사용하는 것이 가합니다.

클라이언트(웹 브라우저) 입장에서는 두 방식에 차이가 있지만, 서버 입장에서는 둘의 형식이 동일하므로, request.getParameter() 로 편리하게 구분없이 조회할 수 있습니다.

 

3. HTTP message body에 데이터를 직접 담아서 요청 (API 메세지 바디)

  • HTTP API에서 주로 사용하며, HTTP POST, PUT, PATCH 등의 요청 메서드를 사용하여 요청 본문에 데이터를 포함하여 전달합니다.
  • 주로 JSON 또는 XML 형식으로 데이터를 포함합니다.
  • 가장 먼저 단순한 텍스트 메세지를 HTTP 메세지 바디에 담아서 전송하고 읽어보겠습니다. HTTP 메세지 바디의 데이터를 InputStream을 사용해서 직접 읽을 수 있습니다.

👉 JSON 형식으로 데이터를 주고받는 방법 (HTTP API 에서 주로 사용)

JSON 형식으로 데이터를 주고받으려면 우선 JSON 형식으로 변경할 수 있는 객체를 하나 생성하겠습니다. 새로운 클래스파일을 하나 만든 후 멤버변수를 작성해주고, Lombok을 이용해 Getter와 Setter를 생성해줍니다.

 

        /**
         * http://localhost:8080/request-body-json
         *
         * JSON 형식 전송
         * content-type: application/json
         * message body: {"username": "hello", "age": 20}
         *
         */
        @WebServlet(name = "requestBodyJsonServlet", urlPatterns = "/request-body-json")
        public class RequestBodyJsonServlet extends HttpServlet {

            private ObjectMapper objectMapper = new ObjectMapper();

            @Override
            protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
                ServletInputStream inputStream = request.getInputStream();
                
                String messageBody = StreamUtils.copyToString(inputStream,
                        StandardCharsets.UTF_8);
                System.out.println("messageBody = " + messageBody);

                HelloData helloData = objectMapper.readValue(messageBody,HelloData.class);
                System.out.println("helloData.username = " + helloData.getUsername());
                System.out.println("helloData.age = " + helloData.getAge());

                response.getWriter().write("ok");
            }
        }

 

728x90
반응형
728x90

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

728x90
반응형

'[HTTP]' 카테고리의 다른 글

[HTTP] HTTP 헤더 정보  (0) 2023.07.30
[HTTP] HTTP 헤더  (0) 2023.07.27
[HTTP] HTTP 상태 코드  (0) 2023.07.26
[HTTP] HTTP 메서드의 속성  (0) 2023.07.15
[HTTP] Resource & HTTP 메서드  (0) 2023.07.07
728x90

🎈 Web Application

웹서버라는것은 HTTP 프로토콜을 기반으로 소통하고 , 데이터를 주고받을 수 있습니다. 대부분의 현태의 데이터 전송이 가능하고, 서버 간의 데이터를 주고받을 때도 대부분 HTTP를 사용합니다.

웹 서버(Web Server)클라이언트로부터 HTTP 요청을 받아들이고, HTTP 프로토콜을 기반으로 웹 페이지와 다른 리소스를 제공하는 소프트웨어입니다. 웹 서버는 웹 브라우저와 같은 클라이언트가 요청하는 정적인(HTML, CSS, 이미지 등) 웹 페이지를 처리하고 전송하는 역할을 담당합니다.

일반적으로 웹 서버는 HTTP 요청을 받아들이는 기능과 요청에 대한 적절한 응답을 제공하는 기능을 갖추고 있습니다. 웹 서버는 클라이언트와의 통신을 위해 HTTP 프로토콜을 사용하며, HTTP 요청에 대한 처리 결과를 HTTP 응답으로 반환합니다.

웹 애플리케이션 서버(Web Application Server, WAS)동적인 웹 애플리케이션을 실행하고 관리하는 미들웨어 소프트웨어입니다. WAS는 웹 서버의 역할뿐만 아니라 애플리케이션 실행 환경과 데이터베이스와의 통신 등을 담당하여 웹 애플리케이션을 실행하는 데 필요한 여러 기능을 제공합니다.

프로그램 코드를 실행해서 애플리케이션 로직을 수행하기 때문에 동적 HTML 및 HTTP API(REST API)등이 WAS를 통해 제공이 됩니다. (ex. 아파치 톰캣)

  1. 애플리케이션 실행 환경 제공: WAS는 자체적으로 자바 애플리케이션의 실행 환경을 갖추고 있으며, 웹 애플리케이션의 실행과 관리를 담당합니다. 웹 애플리케이션을 실행하기 위해 자바 서블릿과 JSP(JavaServer Pages)와 같은 컴포넌트를 지원합니다.

  2. 스레드 관리 및 트랜잭션 처리: WAS는 여러 클라이언트의 요청을 동시에 처리하기 위해 스레드 풀을 사용하여 스레드를 관리합니다. 또한, 트랜잭션 처리와 같은 다중 작업을 원활하게 수행하도록 지원합니다.

  3. 데이터베이스와의 연동: 웹 애플리케이션은 데이터베이스와의 상호작용이 필요한 경우가 많습니다. WAS는 데이터베이스와의 통신을 지원하여 데이터의 조회, 저장, 갱신 등을 처리할 수 있도록 합니다.

  4. 세션 관리: 웹 애플리케이션은 세션 관리를 통해 사용자의 로그인 상태와 상호작용을 유지합니다. WAS는 세션 관리 기능을 제공하여 사용자의 세션 상태를 효율적으로 관리합니다.

  5. 클러스터링: 대규모 웹 애플리케이션에서는 여러 WAS 인스턴스를 클러스터로 구성하여 부하 분산과 고가용성을 제공할 수 있습니다.

웹 시스템은 WAS - DB만으로도 간단하게 시스템 구성이 가능합니다. WAS는 정적 리소스와 애플리케이션 로직 모두 제공이 가능하기 때문입니다. 하지만, 1개의 WAS를 가지고만 운영을 하게되면
역할이 커지게 되며 서버 과부하의 우려가 있으며, 중요도가 낮은 정적 리소스 때문에 중요한 애플리케이션 로직의 수행이 어려울 수 있습니다.

정적 리소스만 제공하는 웹 서버는 다운이 잘 안되지만 애플리케이션 로직이 동작하는 WAS 서버는 잘 다운됩니다.
WAS나 DB에서 장애가 발생했을 시 WEB 서버가 오류 화면을 제공해줄 수 있습니다.

 


 

📋 서버에서 처리해야 하는 업무

웹 애플리케이션 서버를 직접 구현 시 웹 브라우저가 생성한 요청 HTTP 메세지를 분석합니다. 요청 메세지가 어떠한 형태로 보내졌는지 확인 후 비즈니스 로직 실행을 통해 데이터 베이스에 저장을 요청합니다. 이 후 HTTP 응답 메세지를 시작라인 생성, Header 생성, 메세지 바디에 HTML을 생성한 응답메세지를 만든 후 TCP/IP에 응답메세지를 전달한 후 소켓을 종료합니다.

이러한 많은 과정들을 축약하기 위해 서블릿의 개념이 등장하였습니다. 서블릿을 지원하는 WAS를 사용함으로서 HTTP 요청 메세지를 읽는 과정부터 응답 메세지의 생성까지 전부 진행해줍니다.

 

 

 

 

             
             @WebServlet(name="helloServlet", urlPatterns = "/hello")
                -> urlPatterns(/hello)의 URL이 호출되면 서블릿 코드가 실행됩니다.
                public class HelloServlet extends HttpServlet { -> httpServlet을 상속받습니다.

                    @Override
                    protected void service(HttpServletRequest request, 
						HttpServletResponse response) throws ServletException, IOException {
                        System.out.println("HelloServlet.service");
                                //애플리케이션 로직을 작성합니다.
                }

                **HTTP 요청 정보를 편리하게 사용 할 수 있는 HttpServletRequest
                **HTTP 응답 정보를 편리하게 사용할 수 있는 HttpServletResponse 들을 객체 생성하여 편리하게 사용이 가능합니다.

 

HTTP 요청이 오면 WAS 는 Request, Response 객체를 새로 만들어서 서블릿 객체를 호출해주어 개발자는 Request 객체에서는 HTTP 요청 정보를 편리하게 꺼내서 사용, Response 객체에 담겨있는 HTTP 응답 정보를 편리하게 입력할 수 있게 됩니다. WAS는 Response 객체에 담겨있는 내용을 바탕으로 HTTP 응답 메세지를 생성 후 전달합니다.

서블릿 컨테이너


서블릿 컨테이너(Servlet Container)
웹 애플리케이션 서버(또는 웹 컨테이너)의 일부로서, 서블릿의 생명주기를 관리하고 서블릿을 실행하는 환경을 제공하는 소프트웨어입니다. 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 합니다. 서블릿 컨테이너는 클라이언트의 요청에 대해 적절한 서블릿을 생성, 호출,관리하고 서블릿이 요청을 처리한 결과를 클라이언트에게 반환합니다.

서블릿 객체는 싱글톤으로 관리 (객체 한개 생성 후 객체 공유) 클라이언트의 요청이 올 때마다 객체를 생성하는것은 비효율 적이기 때문에 , 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재사용이 가능하도록 하는 것이 좋습니다. 모든 클라이언트의 요청은 동일한 서블릿 객체 인스턴스에 접근할 수 있으며, 서블릿 컨테이너가 종료 될 때 함께 종료됩니다. (💥 공유 (멤버변수) 변수를 사용할 때 굉장히 주의가 필요)

 


 

동시 요청 - 멀티 쓰레드✍️💡

클라이언트가 요청을 하면 WAS에 요청이 전달되면 TCP/IP 커넥션으로 연결이 되며 서블릿을 호출하게되며 응답을 줄 수 있습니다. 여기서 서블릿 객체를 호출하는 당사자가 굉장히 중요합니다. 바로 쓰레드가 서블릿을 호출하게 됩니다.

 

쓰레드란 ?

쓰레드(Thread)프로세스 내에서 실행되는 실행 단위로, 프로세스의 자원을 공유하면서 동시에 여러 작업을 처리할 수 있도록 해주는 기본적인 실행 단위입니다. 애플리케이션 코드를 하나 하나 순차적으로 실행해주며, 자바 메인 메서드를 처음 실행하면 main 이라는 이름의 쓰레드가 실행되는 것 입니다.

일반적으로 하나의 프로세스는 하나의 메인 쓰레드를 가지고 있고, 이 메인 쓰레드에서 프로그램의 주요 로직이 실행됩니다. 쓰레드가 없다면 자바 애플리케이션 실행이 불가능하며, 쓰레드는 한번에 하나의 코드라인만 수행합니다. 그러나 프로그램이 다중 작업을 동시에 처리해야 할 경우가 있습니다. 이때 추가적인 쓰레드를 생성하여 각 작업을 병렬적으로 처리할 수 있습니다.

 

📋 쓰레드의 단일 요청

단일 쓰레드 모델에서는 프로그램의 모든 작업이 메인 쓰레드에서 순차적으로 실행됩니다. 요청이 오면 1개의 쓰레드를 할당한 후 서블릿 객체를 호출한 후 응답을 전달하고 휴식을 합니다. 한 번에 하나의 작업만 처리할 수 있으며, 다음 작업은 이전 작업이 완료된 후에 실행됩니다. 이러한 실행 모델은 단순하고 직관적이지만, 작업을 순차적으로 처리하기 때문에 성능이 저하될 수 있습니다.

만약 다중 요청 시 쓰레드를 하나만 사용하는데 그 하나의 쓰레드에 장애가 발생하여 처리가 지연되면, 두번째로 들어오는 요청이 대기하게되며 1번째의 요청과 2번째의 요청 모두 장애가 발생하게 될 수 있습니다. 이러한 상황을 해결하기 위해서 요청 마다 쓰레드를 생성하는 방법이 있습니다. (신규 쓰레드 생성)

💥 요청이 올때마다 쓰레드를 생성하는 경우, 동시 요청 처리가 가능하고 리소스 (CPU, 메모리)가 허용될 때까지 처리가 가능합니다. 그리고 하나의 쓰레드가 지연되어도 나머지 쓰레든느 정상 동작하는 장점이 있습니다.

하지만, 쓰레드 생성비용은 비싼편이고, 요청 마다 쓰레드를 생성하면 응답 속도가 늦어집니다. 쓰레드 생성에는 제한이 없기 때문에 고객요청이 너무 많이오면(수강신청 시) , CPU와 메모리가 버티지 못하 임계점을 넘어서 서버가 죽을 수도 있습니다.

 

📋 쓰레드 풀

쓰레드 풀(Thread Pool)쓰레드를 미리 생성하여 풀(pool)에 보관해두고, 필요할 때마다 풀에서 쓰레드를 가져와 작업을 처리하는 기법입니다. 쓰레드 풀은 다수의 클라이언트 요청을 동시에 처리해야 하는 서버 애플리케이션에서 쓰레드의 생성과 소멸에 따른 오버헤드를 줄이고 성능을 향상시키기 위해 사용됩니다.

내부에 쓰레드들을 미리 생성하여 보관하고 있다가 요청이 오게되면 쓰레드 풀로 요청을 받게되고, 풀 내부에 있던 쓰레드들을 사용하여 서블릿 객체를 호출하여 쓸 수 있습니다. 쓰레드의 사용이 다 끝나면 쓰레드 풀에 반납이 가능합니다.

  1. 쓰레드 재사용: 쓰레드 풀은 미리 생성된 쓰레드를 재사용하여 작업을 처리합니다. 작업이 완료되면 해당 쓰레드는 다음 작업을 처리하기 위해 풀에 반환됩니다. 이렇게 함으로써 쓰레드의 생성과 소멸에 따른 오버헤드를 줄이고, 쓰레드를 재사용함으로써 시스템의 부하를 줄일 수 있습니다.
  2. 제한된 쓰레드 수: 쓰레드 풀은 미리 설정된 쓰레드 개수를 가지고 있으며, 이 개수를 초과하여 쓰레드가 생성되지 않도록 관리합니다. 이를 통해 쓰레드 개수를 제한함으로써 서버의 과도한 부하를 방지하고 안정적인 성능을 유지할 수 있습니다.
  3. 쓰레드 생성 비용 절감: 쓰레드 풀은 미리 쓰레드를 생성하여 보관하고 있기 때문에, 새로운 작업이 들어올 때마다 쓰레드를 새로 생성하는 비용을 절감할 수 있습니다. 이는 많은 수의 작업을 처리해야 하는 경우에 특히 효과적입니다.
  4. 작업 대기 처리: 쓰레드 풀에 모든 쓰레드가 사용 중인 경우, 새로운 작업이 들어올 때까지 대기하게 됩니다. 이를 통해 서버의 과부하를 방지하고 안정적인 처리를 유지할 수 있습니다. (톰캣은 최대 200개 기본 설정)

쓰레드가 미리 생성되 어 있으므로, 쓰래드를 생성하고 종료하는 비용(CPU)가 절약되고 , 응답시간이 빠릅니다. 생성 가능한 쓰레드의 최대치가 있으므로 너무 많은 요청이 들어와도 기존 요청은 안전하게 처리할 수 있는 장점이 있습니다.

👉 WAS는 다수의 클라이언트로부터 동시에 여러 요청을 받을 수 있어야 하며, 이러한 요청을 동시에 처리하기 위해 멀티쓰레드를 활용할 수 있습니다. 개발자는 멀티쓰레드 관련 코드를 신경 쓰지 않아도 되고, 싱글 쓰레드 프로그래밍을 하듯이 편리하게 소스코드를 개발할 수 있습니다.
멀티 쓰레드 환경이므로 싱글톤 객체(서블릿, 스프링 빈)을 주의해서 사용해야 합니다.


 

📘 HTML, HTTP API, CSR, SSR이란 ?

백엔드 개발자가 서비스를 제공할 때 고려해야할 3가지 방식

  1. 정적 리소스 - 고정된 HTML 파일 , CSS , JS , 이미지, 영상등을 제공합니다. 주로 웹 브라우저에서 요청을 합니다. 요청이 /hello.html로 요청이 온다면, 이미 생성된 리소스 파일을 전달해줍니다.

  2. HTML 페이지 - WAS가 웹 브라우저에서 요청을 받으면, DB를 통해서 데이터를 조회한 후 동적으로 HTML을 생성 VIEW 템플릿인 JSP나 Thymeleaf등을 이용해서 DB에서 조회된 데이터와 프로그램 코드를 넣어서 HTML 코드를 동적으로 생성한 후 브라우저에게 전달해줍니다.

  3. HTTP API - DB의 데이터를 조회한 후 JSON형식의 데이터를 (KEY:VALUE) 형태의 정보를 전달하게 됩니다. 그럼 브라우저에서 해석이 바로 되진 않기때문에 브라우저에 보여주기 위해 쓰는 것이 아니라, 데이터만 주고 받는 상황에만 주로 사용됩니다.

SSR(서버 사이드 렌더링)CSR(클라이언트 사이드 렌더링)은 웹 애플리케이션의 렌더링 방식을 나타내는 용어입니다. 이 두 가지 방식은 웹 페이지의 내용을 브라우저에 보여주는 방식에 차이가 있습니다.

  1. 서버 사이드 렌더링 (SSR) → JSP , 타임리프 백엔드 개발자
    서버에서 최종 HTML을 생성한 후 클라이언트에게 전달합니다. HTML을 만드는 과정을 전부 서버에서 종료 후 브라우저에 전달합니다. 서버 사이드 렌더링은 웹 서버에서 페이지의 내용을 모두 구성한 후, 클라이언트(브라우저)에게 완전히 렌더링된 HTML을 보내주는 방식입니다. 클라이언트는 렌더링된 HTML을 받아서 바로 화면에 표시할 수 있습니다. 이후에는 필요한 데이터를 요청하고 받아오는 AJAX 방식으로 동작합니다.

    단점 : 서버 부하가 증가할 수 있습니다. 많은 요청을 처리해야 하므로 서버에 부담이 갈 수 있습니다. 페이지 전환이 있을 때마다 서버로부터 새로운 HTML을 받아와야 하므로 네트워크 비용이 증가할 수 있습니다

    장점 : 초기 렌더링 속도가 빠르고, 첫 페이지 로딩이 빠릅니다. SEO(Search Engine Optimization)에 유리하며, 검색 엔진에서 페이지를 크롤링하기 쉽습니다.

  2. 클라이언트 사이드 렌더링 (CSR) → React , Vue.js 프론트엔드 개발자 ****HTML결과를 자바스크립트를 사용해 웹 브라우저에서 동적으로 생성해서 적용합니다. 주로, 동적인 화면에 사용, 웹 환경을 마치 앱처럼 필요한 부분부분을 변경할 수 있습니다. 클라이언트 사이드 렌더링은 초기에 서버로부터 HTML과 필요한 JS, CSS 등의 정적 파일을 받아온 후, 클라이언트(브라우저)에서 JavaScript를 이용하여 동적으로 페이지를 구성하는 방식입니다. 클라이언트가 빈 HTML을 받아오고, 데이터를 요청한 뒤 JavaScript가 데이터를 받아와서 브라우저에 렌더링하는 방식입니다.

    단점 : 초기 렌더링 속도가 느리며, 첫 페이지 로딩이 오래 걸립니다. SEO에 불리하며, 검색 엔진이 페이지를 크롤링하는 데 어려움이 있습니다.

    장점 : 필요한 데이터만 요청하고 받아오므로, 서버 부하가 적습니다. 사용자 경험(UX)이 좋고, 사용자와 상호작용이 많은 웹 애플리케이션에 적합합니다.

 

728x90
반응형
728x90

 

✍️ HTTP 헤더의 일반 정보

  • RefererHTTP 요청 헤더의 하나로, 웹 브라우저가 현재 요청을 보내는 페이지의 이전 페이지(리퍼러)의 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로 이동해야 할 때 사용됩니다.
728x90
반응형

'[HTTP]' 카테고리의 다른 글

[HTTP] HTTP 헤더 2 - 캐시와 조건부 요청  (0) 2023.08.01
[HTTP] HTTP 헤더  (0) 2023.07.27
[HTTP] HTTP 상태 코드  (0) 2023.07.26
[HTTP] HTTP 메서드의 속성  (0) 2023.07.15
[HTTP] Resource & HTTP 메서드  (0) 2023.07.07
728x90

 

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"를 지정하여 원하는 범위를 표시하고, 서버는 해당 범위만을 응답으로 보내주는 방식으로 동작합니다.
728x90
반응형

'[HTTP]' 카테고리의 다른 글

[HTTP] HTTP 헤더 2 - 캐시와 조건부 요청  (0) 2023.08.01
[HTTP] HTTP 헤더 정보  (0) 2023.07.30
[HTTP] HTTP 상태 코드  (0) 2023.07.26
[HTTP] HTTP 메서드의 속성  (0) 2023.07.15
[HTTP] Resource & HTTP 메서드  (0) 2023.07.07
728x90

 

http://blog.plura.io/?p=14782

 

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

728x90
반응형

'[HTTP]' 카테고리의 다른 글

[HTTP] HTTP 헤더 정보  (0) 2023.07.30
[HTTP] HTTP 헤더  (0) 2023.07.27
[HTTP] HTTP 메서드의 속성  (0) 2023.07.15
[HTTP] Resource & HTTP 메서드  (0) 2023.07.07
[HTTP] URI와 웹 브라우저 요청 흐름 (URL, HTTP)  (0) 2023.06.28

+ Recent posts