강의 전체 흐름
- 소프트웨어 개발 프로세스
- 웹서비스 아키텍처
- 백엔드와 프론트엔드 연동 (다룰 내용)
핵심 요소
- HTTP
- API
- 데이터 교환 포맷
- AJAX
- 실시간 데이터 처리
- 인증
- CORS
HTTP
특징
- 클라이언트<->서버 구조
- 클라이언트 : 브라우저 등 , 서버 : 웹 어플리케이션 등 - 무상태 (Stateless)
- 서버가 클라이언트의 상태를 저장하지 않음- 다소 복잡 (쿠키, 세션 등을 매번 관리)
- 비연결성 (Connectionless)
- 요청을 주고 받을 때에만 연결을 유지함
HTTP는 텍스트기반 프로토콜이라서 브라우저에서 확인할 수 있음
HTTP Method : GET, POST, PUT, PATCH, DELETE ..
Request Header
- Host : 요청의 도메인과 port 번호
- User-Agent : 운영체제나 소프트웨어 번호 식별
- Accept : 클라이언트가 처리할 수 있는 컨텐츠 유형
- Accept-Language : 클라이언트가 선호하는 언어, 어떤 언어로 랜더링할지
- Accept-Encoding : 클라이언트가 선호하는 컨텐츠 인코딩
- Authorization : 사용자 인증 전달 관련한 (Bearer 등)
- Content-Length : 요청 본문의 길이를 바이트 단위로
- Content-Type : POST, PUT에 사용됨
- Cookie : 중요 ! 서버에 의해 생성된 클라이언트에 저장된 쿠키를 서버에 다시 전송
- Referer : 이전 웹페이지 주소를 저장
- If-Modified-Since :
- If-None-Match :
- Cache-Control : 캐싱 동작 제어
Responce Header
- Content-Type : 응답 데이터의 MIME 타입 지정 (ex. application/json, text/html)
- Content-Length : 응답 본문의 바이트 크기
- Content-Encoding : 응답 데이터의 인코딩 방식 (ex. gzip)
- Set-Cookie : 클라이언트에 쿠키를 설정
- Cache-Control : 캐시 동작 제어
- Expires : 리소스의 만료 시각 설정
- Last-Modified : 리소스가 마지막으로 수정된 시각
- ETag : 리소스의 고유 식별자 (캐시와 관련)
- Server : 서버 소프트웨어 정보
- Location : 리다이렉션 경로 지정 (ex. 3xx 응답에서 사용)
- Access-Control-Allow-Origin: CORS 설정을 위한 허용 도메인
응답 상태 코드
- 200 성공
- 201 새로운 리소스를 생성함
- 301 리소스가 영구적으로 이동 (리소스 이름 변경 등) 자동 리다이렉트
- 304 리소스가 변경되지 않았음
- 400 서버가 요청을 이해할 수 없을 때
- 401 인증이 필요할 경우
- 403 서버가 요청을 거부 (권한 없음)
- 404 요청한 리소스를 찾을 수 없을때
- 500 서버에서 스크립트가 잘못되었거나 오류 발생시
- 503 서버가 처리할 수 없을 때
*Cookie
- 사용자의 웹브라우저에 저장된 작은 데이터 조각
- 응답에 set-cookie를 사용하면, 동일한 요청시 브라우저는 쿠키를 매번 보내게된다.
- 기능
- 세션관리
- 개인화
- 추적
Cookies 속성
- Expires : 유효기간 지정 (만료되는 날짜를 지정)
- Max-Age : 유효기간 지정 (얼마나 유지될지 '초'단위로 지정)
- Domain : 전송 범위 제한 (전송될 도메인 지정)
- Path : 전송 범위 제한 (전송될 경로 지정)
- Secure : 쿠키가 Https 프로토콜에서만 전송되도록 지정 (보안 강화)
- HttpOnly : 쿠키가 javascript를 통해 접근할 수 없도록 막음
Http는 프론트-백엔드에 있어서 기본적인 요소임.
API
API
- 서로 다른 소프트웨어가 통신하기 위해 따라야하는 규칙
- 종류
- REST API
- GraphQL API
- SOAP
REST API
- Http URI를 사용해 리소스를 명시, 여러 http메소드를 통해서 리소스를 처리하는 방식
REST API 구성요소
- Resource (자원)
- 정보의 핵심 단위 - Verb (행위)
- 클라이언트가 리소스에 수행하려는 작업 - Representation (표현)
- 클라이언트-서버 간에 전송되는 리소스의 구체적인 데이터 형태
REST API 설계 규칙
- URI는 정보의 자원을 표현해야한다.
-GET /members/1=> 동사보다는 명사members를 사용, 소문자 사용 - 자원에 대한 행위는 HTTP 메소드로 표현한다.
REST API 장단점
- 장점 : 단순성, 유연성, 확장석, Stateless, 다양한 플랫폼 및 언어 지원
- 단점 : 과도한 데이터 전송, 복잡한 쿼리, 표준 부재
GraphQL API
- 단일한 엔드 포인트에 쿼리를 하여 필요한 데이터만 요청하는 방식
- 장점 : 데이터 요청의 유연성, 전송량 감소, 단일 엔드포인트, 강력한 스키마, 자동 문서화
- 단점 : 학습 곡선, 캐싱의 복잡성, 쿼리 복잡성, 보안 문제
SOAP
- XML 기반 메시지를 사용하여 데이터를 전송하는 표준 프로토콜
- 장점 : 다양한 보안 기능, 확장 가능한 설계
- 주로 금융, 전자상거래 같이 높은 보안성을 요구할때 사용함 - 단점 : 다른 프로토콜에 비해 복잡함, 성능이 떨어짐
데이터 교환 포맷
웹서비스에서 데이터 교환하기 위해서 JSON, XML을 주로 사용한다.
JSON
- 간단하고 가벼운 텍스트 기반 데이터 교환 포맷
- 위 이미지 : bookstore라는 루트객체에 books라는 속성이 있고 , books는 2개의 객체를 가지오 있다. 각 객체는 제목, 저자, 가격 등을 가지고 있다.
- 장점 : 간결성, 프로그래멍 언어 독립적, 구조화된 데이터 표현
- 단점 : 기능 부족 (스키마가 따로 없음), 데이터 크기(절대적으로 작지만 상대적으로 크다.)
JSON 데이터 유형
XML
- HTML과 비슷한 텍스트 기반의 마크업 언어
- html과 유사하게 트리구조처럼 생성된다(위 이미지 참고)
- 장점 : Self-Descriptive, 확장성, 다양한 플랫폼, 유효성 검사
- 단점 : 복잡성, 처리 속도, 가독성, 네트웤 효율성(데이터 량이 많아질 수도)
XML 스키마
- 데이터 타입과 디폴트 값을 지정할 수 도 있다. XML문서가 스키마를 따르는지를 확인도 할 수 있음
AJAX
AJAX 개념
- 비동기적으로 서버와 통신(JavaScript)을 함으로써 웹 페이지 전체를 다시 로딩하지 않고도 웹페이지의 일부분만을 업데이트할 수 있게 하는 기술
- 주로 JSON을 사용해서 서버와 데이터 통신을한다.
AJAX 장단점
- 장점
- 웹 페이지 속도 향상
- 향상된 사용자 경험
- 서버 부하 감소 - 단점
- 보안 취약점 (CORS)
- 브라우저 호환성 (모든 브라우저에 작동하지 않을 수 있음..?)
- SEO 문제 (동적으로 컨텐츠를 보여주기에 검색엔진에 맞지 않음)
- 디버깅 어려움 (동적으로 생성된느 데이터로 인해 디버깅이 어려움)
AJAX는 웹 개발에서 매우 중요한 기술, 사용자 경험을 크게 개선, 동적이고 반응성이 뛰어난 어플리케이션 구축시 필요함
실시간 데이터 처리
웹에서 데이터를 실시간으로 수발신 하는 기술
주식, 채팅 등 실시간 데이터를 보여줄때 필요함
실시간 데이터 처리 방식
- Server Push
- 서버에서 클라이언트에게 데이터 스트림을 푸시 방식으로 전송 (클라이언트 요청 필요없이 서버가 보냄)
- 클라이언트와 서버가 지속적으로 연결을 유지, 상태를 관리해야되서 서버 부하가 있을 수 있다.
- WebSocket과 SSE (Server-Sent Events) - Client Pulling
- 클라이언트가 서버에 주기적으로 요청을 보내어 새로운 데이터가 있는지 확인하는 방식
- 연결을 유지할 필요가 없지만 요청 주기에 따라 지연시간이 발생할 수 있다.
- AJAX Polling과 Long Polling
WebSocket
다른 기술들보다 상대적으로 구조가 복잡, 방화벽 및 프록시 등으로 연결이 안될 수 있음
WebSocket 동작 방식
클라이언트는 handshake를 위해서 http요청을 보냄
웹소켓을 위한 업그레이드 헤더가 포함됨.
서버는 핸드쉐이크 요청을 받아 101 스위치 프로토콜 상태코드를 반환
클라이언트는 상태코드를 받아 양방향 수발신 상태로 전환해버림
SSE
웹소켓과 유사하지만 1번만 연결하고 나서 단방향으로 데이터를 보내버림
실시간 데이터 처리기술를 사용하면 사용자 경험이 매우 올라갈 수 있다.
인증
사용자의 신원을 확인하는 과정을 인증이라고 한다.
인증 방식
- 세션 쿠키
- JWT (JSON WEB TOKEN)
세션 쿠키
- JWT가 나오기 이전에 많이 사용하던 방식
- 순서
- 아이디와비밀번호 입력 후 인증 요청
- 서버는 세션 아이디, 정보 생성 후 저장 (DB 또는 Redis 같은 곳에 저장)
- 쿠키를 사용해서 세션 아이디를 클라이언트에 반환
- 모든 요청은 세션 아이디를 쿠키에 담아서 서버에 전달
- 인증이 필요한 경우 세션 아이디로 사용자를 검증하여 로직 수행 - 장점
- 호환성 : 대부분의 브라우저에서 사용가능
- 보안 : 세션 아이디만 브라우저에 저장되므로 사용자 개인정보는 모름
- 서버측 제어
- 개인화 : 세션 정보에 추가적인 정보를 넣어둘 수 있음 - 단점
- 서버 부하 : 매번 서버에서 정보를 읽어와야한다.
- 확장성 제한 : 서버를 확장하는데 병목 지점이 될 수 있음
- 세션 쿠키 탈취 : 세션 아이디가 클라에 저장되어 있기에 탈취가능성이 있음
JWT
-
인증 및 정보 교환에 필요한 표준
-
인증에 필요한 정보를 토큰에 담아 암호화하는 방식
-
서버에서 세션정보를 매번 읽어야하는 세션과 달리 토큰에 인증 정보를 저장하기에 서버에 부하를 줄 일수 있다.
-
순서
- 토큰 발급 후 클라이언트에게 전달
- API 요청마다 헤더에 Authorization에 담아 보냄
- 서버는 해석 후 요청에 대해나 로직 수행
-
iss(Issuer)
- 토큰 발급자 -
sub
- 토큰의 주체, 일반적으로 사용자 ID를 의미 -
aud
- 토큰의 수신자 -
exp
- 토큰의 만료시간 -
iat
- 토큰의 발급 시간
JWT 장단점
- 장점
- self-contained : 정보가 토큰에 있어서 별도의 저장소가 필요하지 않음
- 효율성 : 세션 정보를 서버에 저장하지 않아 효율적
- 확장성 : 다양한 도메인에 걸쳐서 사용할 수 있음 (MSA등 가능)
- 높은 보안성 : 데이터 무결성 보장, 위변조 불가능 하다고 한다. - 단점
- 토큰 크기 : 토큰의 크기가 커질 수 있음
- Payload 보안 : Payload는 암호화되지 않아 민감한 정보는 넣을 수 없음
- 토큰 만료 관리 : 토큰 무효화를 위해 별도의 처리가 필요함
세션쿠키는 전통적인 방식, 상태관리가 쉽다. 분산관리 시스템에 어려움 JWT는 확장성이 좋지만 크기가 크고 보안에 주의
CORS
왜 CORS에러가 발생할까..
웹 브라우저는 보안을 위해서 기본적으로 '동일 출처 정책'을 따른다.
사이트에 악성 코드가 심어지거나 , 쿠키 같은 정보를 탈취되지 않도록 하는 것이다.
Origin 구성
Origin은 Protocol, Hostname, Port로 구성되어 있다.
CORS 문제 해결방법
스크립트를 포함한 페이지를 내려줄때
서버에서 허용된 출처정보를 헤더에 추가해서 응답!
CORS 정책을 올바르게 구현하는 것은 사용자와 어플리케이션을 보호하는데 중요한 개념이다.
