728x90
반응형

🔷 Forward 방식이란?

Web Container 내부에서 요청을 다음 페이지로 전달하는 방식

  • 브라우저는 이동했음을 인지하지 못함
  • URL은 바뀌지 않음
  • Request와 Response 객체를 공유
  • 서버 내부에서 페이지 이동만 발생
  • 대표 사용 예: 글 목록, 검색 결과 등 조회용 요청

📌 예시 상황

게시글 작성 완료 후 forward로 응답 페이지를 호출했을 때, 새로고침 시 동일 게시물이 여러 번 등록될 수 있음.
➡️ 왜냐하면 이전 요청 정보가 그대로 유지되기 때문!


🔷 Redirect 방식이란?

서버가 브라우저에게 다른 URL로 이동하라고 지시하는 방식

  • 브라우저가 새로운 URL로 이동
  • Request/Response 객체는 새로 생성
  • URL이 변경됨
  • 다른 서버나 컨텍스트로도 이동 가능
  • 대표 사용 예: 회원가입, 게시글 등록 등 데이터 변경 요청

📌 예시 상황

게시글 등록 후 redirect를 사용하면, 새로고침해도 중복 등록이 발생하지 않음.
➡️ 왜냐하면 이전 요청 정보가 사라지기 때문!


🔷 Forward vs Redirect 비교 정리

항목ForwardRedirect
URL 변경 ❌ 변경 없음 ✅ 변경됨
브라우저 인식 ❌ 이동 모름 ✅ 이동함
Request 공유 ✅ 동일 객체 ❌ 새 객체
사용 위치 조회 등록/삭제
새로고침 시 요청 유지 요청 초기화
 

🔷 Spring에서 Redirect 사용 예시

@Controller
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @GetMapping("/signup")
    public String joinForm() {
        return "users/createMember";
    }

    @PostMapping("/signup")
    public String joinForm(@ModelAttribute UserDto.Request userDto) {
        userService.saveUser(userDto);
        return "redirect:/"; // 리다이렉트 처리
    }
}

✅ 마무리

  • 단순 조회는 Forward
  • DB에 변화를 주는 요청은 Redirect

이 원칙만 기억하면 안정적인 웹 흐름을 구성할 수 있습니다!

728x90
반응형
728x90
반응형

📋 본문

오늘은 많은 백엔드/프론트엔드 개발자분들이 헷갈려하는 개념, StatefulStateless의 차이점에 대해 설명드리려 합니다.
서버 아키텍처를 설계할 때 정말 자주 나오는 주제이니, 끝까지 읽어보시면 많은 도움이 되실 거예요!


✅ 1. 정의부터 확실하게!

구분StatefulStateless
의미 서버가 클라이언트 상태(Session, Cookie 등)을 기억함 서버가 클라이언트 상태를 기억하지 않음
연결 방식 지속적인 연결 유지 요청마다 연결 후 즉시 종료
정보 유지 이전 요청 상태 저장 매 요청 시 모든 정보를 포함해야 함
 

✅ 2. 장단점 비교

🔹 Stateful

  • 장점:
    • 로그인 상태 유지 등 기능 구현이 쉬움
    • MMORPG 같은 실시간 상호작용 서비스에 유리
  • 단점:
    • 서버에 리소스 부담
    • 서버 간 세션 공유 어려움 → Scale-out 불리

🔹 Stateless

  • 장점:
    • 서버 확장, 로드밸런싱, 캐시 활용 용이
    • REST API, 클라우드 환경에 적합
  • 단점:
    • 매 요청 시 상태 정보 포함 → 네트워크 자원 사용 ↑
    • 클라이언트 측 부담 ↑

✅ 3. 서비스 예시로 이해하기

서비스 예시적합한 방식
MMORPG 게임 서버 ✅ Stateful
REST API 기반 웹 서비스 ✅ Stateless
IoT 실시간 데이터 수신 서버 ✅ Stateful
블로그, 커머스 등 일반 웹 서버 ✅ Stateless
 

✅ 4. 기술적 이슈 요약

이슈설명
Scale-out Stateful은 세션 동기화 어려움
CSRF 세션 인증 방식의 보안 취약점
CORS 도메인 간 요청 제약 발생 가능
REST API Stateless 원칙 준수 필요
 

✅ 5. 마무리 요약

  • Stateful: 기능 구현은 쉽지만 서버에 부담, 확장성 떨어짐
  • Stateless: 구현 복잡하지만 성능, 확장성, 클라우드에 유리
  • 선택 기준: 서비스의 실시간성/확장성/안정성에 따라 결정!
728x90
반응형
728x90
반응형

📖 본문

1. URL 입력 후 서버로 요청이 가는 과정

브라우저 주소창에 URL을 입력하면, 사실 단순히 “주소”만 보낸 게 아니라 서버에 HTTP Method라는 방식으로 요청을 보낸 것입니다.
HTTP Method는 여러 종류가 있지만, 가장 기본이자 많이 쓰이는 건 GETPOST입니다.


2. GET 방식 — "책 빌려오는 방법"

📌 개념
필요한 정보를 가져오기 위한 요청 방식입니다.
마치 도서관에서 책을 빌려오는 것과 비슷하죠.

📝 특징

  • URL에 데이터가 포함됩니다.
https://example.com/login?id=abcd&pw=kor
  • → ? 뒤의 id와 pw가 서버로 전달됩니다.
  • 데이터가 Header에 포함되어 전송됩니다.
  • URL에 데이터가 노출 → 보안에 취약
  • 캐싱 가능 (속도 향상, 즐겨찾기 가능)
  • 데이터 전송 길이 제한 존재 (브라우저 제한)
  • 바디(Body)는 보통 비어 있음

⚠️ 주의
아이디나 비밀번호 같이 민감한 정보는 절대 GET으로 보내면 안 됩니다.


3. POST 방식 — "편지 봉투 전달하기"

📌 개념
데이터를 서버로 제출하여 추가, 수정하는 방식입니다.

📝 특징

  • 데이터는 Body에 포함되어 전송 → URL에 안 보임
  • 기본적으로 보안이 GET보다 나음 (하지만 암호화 필요)
  • 캐싱 불가
  • 길이 제한 없음 (하지만 Time Out 존재)
  • Content-Type 헤더로 데이터 형식 명시 필요
  • 쿼리스트링 뿐 아니라 폼 데이터, 파일 전송 가능

💡 예시
로그인 폼, 회원가입, 게시글 작성 같은 데이터 입력 기능


4. 캐싱(Caching)이란?

한 번 불러온 데이터를 임시 저장해 두었다가, 다시 요청할 때 더 빠르게 가져오는 기술입니다.
예: 이미지, CSS, JS 파일을 캐싱하면 페이지 로딩 속도가 빨라집니다.


📌 정리 표

구분                                                                        GET                                                             POST
데이터 위치 URL Body
보안성 낮음 높음(기본)
캐싱 가능 불가능
전송 길이 제한 있음 제한 없음
사용 예시 검색, 조회 로그인, 등록, 수정
 

 

728x90
반응형
728x90
반응형

인터넷 주소에 대해 공부하다 보면 꼭 마주치는 개념이 있죠. 바로 URI와 URL입니다. 두 개념은 비슷하면서도 엄연히 다릅니다. 이번 글에서는 이 둘의 차이를 명확하게 정리해드립니다.


🔍 URI란?

  • URI (Uniform Resource Identifier) 는 말 그대로 ‘통합 자원 식별자’입니다.
  • 인터넷상의 특정 리소스(자원)를 식별할 수 있는 문자열을 뜻합니다.
  • 예) https://www.example.com/news/123 → 이 전체가 URI

🌐 URL이란?

  • URL (Uniform Resource Locator) 은 우리가 흔히 말하는 웹 주소입니다.
  • URL은 리소스의 ‘위치’를 알려주는 방식입니다.
  • 즉, URI의 서브셋(하위 개념)입니다.

✅ URL과 URI의 차이 정리

예시 URL인가? URI인가? 설명
https://www.google.co.kr 서버의 위치를 가리킴
https://www.google.co.kr/news 뉴스라는 리소스 위치를 가리킴
https://www.google.co.kr/news/abc.html HTML 파일의 구체적 경로
https://www.google.co.kr/123 식별자가 추가된 URI
https://www.google.co.kr/news?id=123 쿼리 스트링은 리소스 식별용

✨ 쉽게 말하면?

  • 모든 URL은 URI입니다.
  • 하지만 모든 URI가 URL은 아닙니다.
  • URI = 식별, URL = 위치 라고 기억하세요!

📌 마무리

웹 개발, 백엔드, API 작업 시 이 개념을 잘 알고 있으면 요청 경로 설계 시 큰 도움이 됩니다.
이제 URI와 URL 구분, 더 이상 헷갈리지 않겠죠?

728x90
반응형
728x90
반응형

✍️ 서론 개요 (도입부)

웹 시스템을 처음 배우는 사람부터 실무자까지 혼동하기 쉬운 개념이 바로 웹 서버(Web Server) 와 **WAS(Web Application Server)**입니다.
두 용어는 유사하게 들리지만, 역할과 목적은 분명히 다릅니다.

이 글에서는:

  • 웹 서버의 정의와 역할
  • WAS의 구조 및 동작 과정
  • 웹 서비스 아키텍처 흐름
  • 왜 Web Server와 WAS를 분리해서 써야 하는지

를 실제 흐름도와 함께 명확하게 정리합니다.


📌 핵심 내용 정리

✅ 웹 서버(Web Server)

  • HTTP 요청을 받아 HTML, CSS, JS, 이미지 등의 정적 콘텐츠를 즉시 제공
  • 동적 요청은 WAS로 전달하고 결과를 중계
  • 대표 소프트웨어: Apache, Nginx

✅ WAS (Web Application Server)

  • Servlet, JSP 등의 동적 콘텐츠를 처리하는 미들웨어
  • DB 연동, 비즈니스 로직 처리 등 핵심 로직 담당
  • 대표 소프트웨어: Tomcat, WebLogic, JBoss

✅ 웹 서비스 아키텍처 구조

구조설명
클라이언트 → Web Server → DB 정적 요청에 적합
클라이언트 → WAS → DB 단독 구조지만 부하 위험
클라이언트 → Web Server → WAS → DB 실무에서 가장 효율적인 분리 방식
 

✅ 클라이언트 요청의 실제 처리 흐름

  1. 클라이언트가 HTTP 요청을 보냄
  2. Web Server가 정적 콘텐츠는 즉시 응답,
    동적 요청은 WAS로 전달
  3. WAS는 Servlet 생성 → Thread 실행
  4. 요청에 따라 doGet() 또는 doPost() 실행
  5. 결과 페이지를 Web Server → 클라이언트로 반환

✅ 왜 Web Server와 WAS를 분리해야 할까?

  • WAS가 정적 요청까지 처리하면 자원 낭비
  • 비즈니스 로직이 느려지고 전체 서비스 지연 발생
  • 정적 콘텐츠는 Web Server가 처리 → 부하 분산 & 속도 개선
728x90
반응형
728x90
반응형

프론트엔드 개발을 하다 보면 반드시 마주치는 두 가지 렌더링 방식, 바로 CSR(Client Side Rendering) 과 **SSR(Server Side Rendering)**입니다.
각 방식은 성능, 사용자 경험, SEO 대응에 있어서 확연한 차이를 보입니다. 이 글에서는 CSR과 SSR의 특징과 차이점을 명확하게 정리해 드립니다.


✅ CSR (Client Side Rendering) 이란?

  • 클라이언트에서 렌더링을 수행
  • 서버는 HTML 틀과 JavaScript만 내려주고,
    브라우저가 JS를 실행하여 실제 콘텐츠를 렌더링
  • 사용자 입장에서는 JS가 모두 실행되기 전까지 아무것도 보이지 않음

📌 특징 요약

  • 서버는 HTML+JS 전달만 하고, 렌더링은 브라우저가 수행
  • 첫 화면 진입 시 빈 화면이 잠깐 보일 수 있음
  • **SPA(Single Page Application)**에 적합

✅ SSR (Server Side Rendering) 이란?

  • 서버에서 HTML을 렌더링 완료된 상태로 전달
  • 사용자는 JS가 실행되기 전에도 일부 내용을 볼 수 있음
  • 검색 엔진이나 초기 로딩 속도에서 유리

📌 특징 요약

  • 서버가 완성된 HTML을 내려주기 때문에 초기 콘텐츠 노출이 빠름
  • JS 로딩은 이후에 수행되므로 사용자는 빠르게 피드백을 받음
  • SEO에 더 친화적

🔍 CSR vs SSR 비교

항목CSRSSR
렌더링 위치 클라이언트 서버
첫 페이지 로딩 속도 느림 (전체 JS 필요) 빠름 (HTML 먼저)
이후 페이지 이동 빠름 (이미 다운로드됨) 느림 (다시 렌더링)
SEO 대응 약함 (JS 실행 후 노출) 강함 (초기부터 HTML 제공)
서버 자원 사용 적음 많음
 

🧠 요약 포인트

  • 🔹 빠른 첫 화면이 중요하면 SSR
  • 🔹 페이지 전환 속도가 중요하면 CSR
  • 🔹 SEO에 민감한 페이지는 SSR 우위
  • 🔹 서버 부하를 줄이고 싶다면 CSR 적합
728x90
반응형
728x90
반응형

✅ OSI 7계층(OSI 7 Layer Model) 개요

OSI (Open Systems Interconnection) 7계층 모델은 국제표준화기구(ISO)가 제정한 통신 시스템 간 상호 호환성 확보를 위한 표준 아키텍처입니다.

  • 다양한 제조사의 시스템 간 네트워크 호환 가능
  • 계층 구조 기반으로 기능을 분리하여 분업화(Divide & Conquer) 가능
  • TCP/IP 4계층 모델의 한계를 보완하는 기술표준의 기반

🔹 OSI 7계층 요약표

계층이름 (영문)주요 역할대표 장비/프로토콜
7계층 응용 계층 (Application) 사용자 서비스 제공 HTTP, FTP, SMTP
6계층 표현 계층 (Presentation) 데이터 표현, 인코딩/암호화 XDR, JPEG
5계층 세션 계층 (Session) 세션 관리, 동기화 NetBIOS
4계층 전송 계층 (Transport) 종단 간 전송 제어 TCP, UDP
3계층 네트워크 계층 (Network) 라우팅, IP 주소 기반 전달 IP, ICMP, Router
2계층 데이터링크 계층 (Data Link) MAC 주소 통한 인접 노드간 통신 Ethernet, L2 Switch
1계층 물리 계층 (Physical) 실제 신호 전송, 전기/광 신호 처리 허브, 리피터, 케이블
 

🧠 각 계층별 특징 요약 (블로그 본문 연결 포인트)

  • 1계층: 전기/광 신호로 비트 전달, 장비: 허브, NIC
  • 2계층: MAC주소 기반 프레임 전송, 오류제어
  • 3계층: IP 주소 기반 라우팅 및 최적 경로 설정
  • 4계층: TCP/UDP로 신뢰성 있는 전송 보장
  • 5~7계층: 사용자 응용과 직결된 상위 계층 (세션/표현/응용)
728x90
반응형
728x90
반응형

HTTP 요청 방식인 GET과 POST는 웹 개발자에게 매우 익숙한 개념이지만, 실제로 데이터를 어떻게 전달하는지 정확히 알고 계신가요? 이 글에서는 GET과 POST의 데이터 전달 차이점을 구조적으로 정리해 드립니다.


✅ 1. GET 요청 – 쿼리 파라미터 방식

  • 형식:
    GET /url?username=kim&age=20
  • 특징
    • 데이터가 URL에 포함되어 전송
    • 브라우저 주소창에 보임
    • 캐시 저장 가능, 북마크 가능
    • 전송 데이터 길이에 제한 있음
  • 사용 예
    • 검색, 목록 필터링 등 조회 요청
    • 데이터 변경이 없는 요청

✅ 2. POST 요청 – HTML Form 방식

  • Content-Type: application/x-www-form-urlencoded
  • 형식:
    username=kim&age=20
    (HTTP Body에 담겨 전송)
  • 특징
    • 주로 HTML <form> 태그에서 사용
    • URL이 아닌 메시지 바디에 데이터 포함
    • GET보다 보안성이 높음 (노출되지 않음)
  • 사용 예
    • 회원가입, 로그인, 주문 등 사용자 입력 전송

✅ 3. POST/PUT/PATCH – HTTP API 방식 (JSON 전송)

  • Content-Type: application/json
  • 형식 예시:
{
  "username": "kim",
  "age": 20
}
  • 특징
    • REST API, 비동기 통신(AJAX)에서 일반적
    • JSON 외에도 XML, TEXT 가능
    • 구조적이고 유연한 데이터 전송 가능
  • 사용 예
    • 프론트엔드 → 백엔드 API 통신
    • 모바일 앱, SPA 등에서 서버로 데이터 전달 시

📚 요약 비교 표

구분전송 위치데이터 형식주요 용도
GET URL 쿼리 ?key=value 조회, 검색
POST (Form) HTTP Body key=value 회원가입, 로그인
POST/PUT (API) HTTP Body JSON 등 REST API 통신
 

🎯 결론

  • 단순 조회는 GET
  • 폼 전송은 POST (x-www-form-urlencoded)
  • REST API 통신은 JSON 기반 POST/PUT/PATCH

요청 목적과 환경에 따라 적절한 방식을 선택하는 것이 중요합니다.

728x90
반응형

+ Recent posts