07-네트워크 기초&기본 개념 공부

 

 

1. Load Balancer(로드밸런서)

 : 여러 대의 서버에 트래픽을 분산시키는 역할을 한다.
 : 하나의 서버에 부하가 몰리지 않도록 해준다.
 ex) Nginx, HAProxy, AWS ELB
 ex) 백엔드 실무 할 시 예시
  : 사용자가 많은 서비스에서 서버를 2대 이상 두고, 로드밸런서가 요청을 균등하게 분산시킨다.
  : 많은 사람들의 요청을 여러 서버에 골고루 나눠준다.
  : 필요한 이유 ? 갑자기 사용자 수가 많아지면 한 서버만 버벅된다 -> 여러 대가 나눠서 처리해야함
  : 비유 - 롯데월드 매표소 : 창구가 1개면 줄이 길어진다. 여러 창구가 있으면 나눠서 빠르게 입장 가능!!! 

 **대표적인 로드밸런싱 방식

2. Reverse Proxy(리버스 프록스)
 : 클라이언트 대신 서버에 요청을 보내주는 중간 서버 역할을 한다.
 : 보안, 캐싱, SSL 종료, 로드 밸런싱에 활용이 된다.
 : Nginx나 Apache가 리버스 프록시로 자주 사용이 된다.
 : 사용자의 요청을 대신 서버에 전달하고, 응답을 다시 사용자에게 대신 전달한다.
 : 필요한 이유 ? 서버를 숨기고 보안 유지 + 캐시 + 부하 분산 가능
 : 비유 - 피자 가가에서 직원이 주문 받고 주방에 전달 후, 다시 손님에게 피자를 준다
  -> 주방(서버)은 바깥을 신경 안 쓴다!!

3. CORS(Cross-Origin Resource Sharing)
 : 브라우저 보안 정책 때문에 발생하는 문제이다.
 : 프론트엔드와 백엔드가 도메인이 다를 경우, 요청이 막힐 수 있다.
 : Access-Control-Allow-Origin 헤더로 설정
 : 다른 출처의 서버에 요청할 수 있게 허용 여부를 조정해준다!!
 : 필요한 이유 ? 보안상의 이유로 기본적으로는 "다른 도메인 접근 불가" -> 필요한 경우 열어줘야 한다
 : 비유 - 편의점(프론트)에서 다른 건물 식당(백엔드)에 음식 주문시, 출입증허가(CORS 헤더)를 보여줘야 들어갈 수 있다


4. HTTP 상태 코드 (Status Code)

코드 의미 설명
200 OK 정상 응답
201 Created 생성 성공 (POST)
204 No Content 응답 본문 없음 (삭제 등)
301 Moved Permanently 리디렉션 (영구)
400 Bad Request 잘못된 요청
401 Unauthorized 인증 필요
403 Forbidden 권한 없음
404 Not Found 존재하지 않는 리소스
500 Internal Server Error 서버 오류


5. HTTPS&SSL/TLS 인증서
 : HTTP는 암호화가 안 된 상태이다.
 : HTTPS는 TLS를 통해 암호화+무결성+인증을 제공한다.
 : 실무에서는 Let's Encrypt 같은 무료 인증서를 많이 사용 한다.
 : 웹 사이트 내용을 암호화해서 안전하게 전송한다.
 : 필요한 이유 ? 로그인, 결제정보 등 같은 중요한 정보가 중간에서 도청되지 않게 하기 위해
 : HTTPS는 자물쇠 표시가 있다(브라우저 주소창에) 


6. 웹서버 vs WAS
 : Web Server(ex) Nginx, Apache) - 정적 파일(html, js, css) 제공
 : WAS(Web Application Server) - 동적 페이지 처리(Spring, Django 등)
 : 실무에선 Web Server + WAS 함께 사용한다. (ex) Nginx+Spring Boot or Apache+Spring+JEUS)
 : HTML, 이미지 같은 정적인 파일을 보여준다(Nginx, Apache 등)
 : WAS 역할 - 자바, 파이썬 등으로 만들어진 동적인 내용 처리(Spring, Django 등)
 : 비유 - 웹서버 : 빵만 파는 가게(이미 만들어진 것만 제공)
         - WAS : 빵도 구워주는 가게(주문하면 바로 만들어준다)- 동적!

7. 쿠키 vs 세션 vs 토큰
항목 :         쿠키           세션         토큰 (JWT 등)
저장 위치 : 클라이언트 서버         클라이언트
인증 정보 :     O             O             O
보안성 :       중간          높음         높음 (단, 토큰 탈취 주의)
실무 사용 로그인 유지 사용자 상태 유지 REST API 인증 등
 : 방식 저장 위치 특징
 : 쿠키  클라이언트(브라우저) 브라우저에 저장, 조작될 수 있음
 : 세션  서버 안전하지만 서버 메모리 사용함..
 : 토큰 클라이언트(주로 로컬스토리지)  REST API에서 많이 사용, JWT는 자체적으로 정보 담음
 : 로그인 정보 유지
 : 필요한 이유 ? 로그인 했는데, 새로고침할 때마다 로그인 다시하면 불편하니깐!!!!
 : 비유 - 쿠키 : 손에 도장 찍음
         - 세션 : 놀이공원 입장권 들고 매표소에 맡기기
         - 토큰 : 바코드 카드 들고 다니기(내 정보가 담김)

8. WebSocket
 : HTTP는 요청-응답 기반이고, 지속적 연결이 불가하다.
 : WebSocket은 양방향 실시간 통신이 가능하다.
 : 실시간 채팅, 알림 등에 사용한다.
 : 실시간으로 양방향 소통
 : 필요한 이유 ? 채팅, 알림, 주식 실시간 가격처럼 빠르게 업데이트 해야할 때 주로 사용
 : 비유 - HTTP : 전화기 -> "여보세요" 하고 끊음
         - WebSocket : 메신저 채팅방 -> 계속 연결돼서 왔다갔다 소통


9. API Gateway
 : 여러 마이크로서비스를 하나의 앤드포인트로 통합한다.
 : 인증, 로깅, 트래픽 제어 등 기능을 중앙집중식으로 관리한다.
 ex) AWS API Gateway, Kong, Nginx
 : 여러 백엔드(API들)를 하나의 입구(API Gateway)로 통합!
 : 필요한 이유 ? 서비스가 커지면 마이크로서비스로 나뉘는데, 각각 접근하면 복잡해진다-> 하나로 모아서 관리
 : 비유 - 백화점 입구 하나 -> 안에 옷가게, 신발가게, 식당 여러 개 있음!

10. CDN(Content Delivery Network)
 : 전 세계 여러 서버에 정적 파일을 캐싱하여, 사용자가 가까운 서버에서 빠르게 응답한다.
 : 성능 향상 + 서버 부하 감소
 ex) Cloudflare, AWS CloudFront
 : 정적인 파일(이미지,CSS 등)을 전 세계 여러 서버에 미리 복사해서 빠르게 보여준다!
 : 전 세계에 흩어져 있는 서버들이 미리 정적 파일(이미지, CSS, JS 등)을 복사해서 저장해두고,
사용자가 요청했을 때 가장 가까운 서버에서 빠르게 응답해주는 시스템
 : 필요한 이유 ? 사용자 위치와 가까운 서버에서 파일 보여줘서 속도가 빠름
 : 비유 - 본사에서 택배 보내면 멀지만, 동네 지점에서 바로 받아볼 수 있음

**비유: “본사 vs 지점” 택배 비교
 : 본사에서 보내는 경우
네가 서울에 살고 있는데, 미국에 있는 쇼핑몰(=서버)에 이미지 요청을 하면,
미국 본사에서 직접 이미지를 보내야 하니까 느리고 멀어.

 : 동네 지점(CDN 서버)에서 보내는 경우
CDN은 서울, 부산, 도쿄, 뉴욕 등 여러 지역에 '지점 서버'를 두고, 본사 데이터를 미리 저장해놔.
그래서 너(서울 사용자)가 요청하면, 서울에 있는 CDN 지점 서버가 바로 응답해줘서 빠름!

**기술적으로 설명하면?
 : CDN 서버는 웹사이트의 정적 자원들을 캐싱해둠.
 : 사용자의 위치에 따라 가장 가까운 CDN 서버가 자동 선택되어 응답함.
 : 클라우드플레어(Cloudflare), AWS CloudFront, Akamai 등이 대표적인 CDN 서비스 제공자야.

**실무에서 왜 중요해?
 : 이미지가 많고 방문자도 많은 웹사이트라면, 서버 트래픽과 속도를 최적화할 수 있어.
 : 페이지 로딩 속도가 빨라지고, 사용자 경험(UX)이 좋아져.

정리 : CDN은 "파일 저장소를 여러 나라에 복사해두고, 사용자에게 가까운 곳에서 파일을 주는 시스템"이야.
        그래서 본사(원 서버)까지 안 가도 되고, 동네 지점(CDN 서버)에서 바로 파일 받는다고 생각하면 돼!

 

개념비유

방화벽(Firewall)	건물 경비 아저씨
로드밸런서(Load Balancer)	매표소 창구 여러 개 만들기
리버스 프록시(Reverse Proxy)	직원이 주문 받아 주방에 전달
CORS	출입증 보여줘야 다른 건물 출입 가능
쿠키/세션/토큰	손등 도장 / 입장권 / 바코드 카드
WebSocket	계속 연결된 채팅방
API Gateway	백화점 입구 하나로 통합
CDN	동네 창고에서 바로 상품 받기

 

 

2. TLS 암호화 과정 (HTTPS의 내부 구조)

HTTPS = HTTP + TLS(보안 계층)

• TLS는 대칭/비대칭 암호화, 무결성, 인증을 포함한 보안 프로토콜입니다.

🔹 TLS 과정 요약 (Handshake Flow)

단계설명

1️⃣ 클라이언트 Hello	브라우저가 서버에게 "TLS 시작할래요"라고 요청 (지원 가능한 암호화 방식 포함)
2️⃣ 서버 Hello	서버가 클라이언트에 인증서(공개키 포함)를 보냄
3️⃣ 인증서 검증	클라이언트가 CA(인증기관)로부터 인증서를 검증함 (공인된지 확인)
4️⃣ 대칭키 생성	클라이언트가 대칭키를 만들어 서버의 공개키로 암호화해서 보냄
5️⃣ 세션 시작	서버가 비밀키로 대칭키를 복호화함 → 양쪽이 같은 대칭키를 공유하게 됨
6️⃣ 암호화 통신 시작	이후 모든 HTTP 데이터는 공유된 대칭키로 암호화된 상태로 주고받음

 

🔹 비유

• 서버: 자물쇠와 열쇠 세트의 ‘자물쇠’를 공개함 (공개키)
• 클라이언트: 그 자물쇠로 비밀편지를 잠금 → 서버만 열 수 있음 (비밀키)

🔹 HTTPS 실무 중요성

• 로그인, 결제, 인증토큰 등 중요 정보 보호
• Google, AWS 등은 HTTP 접속 자체를 막거나 리디렉션 시킴

---

✅ 실무에서 자주 보이는 TLS 관련 이슈

문제원인해결 방법

인증서 만료	유효기간 초과	Let's Encrypt 등 자동 갱신 스크립트 사용
브라우저 보안 경고	자체 서명 인증서 사용	공인 CA 인증서 사용
Mixed Content 오류	HTTPS 페이지 내 HTTP 리소스 포함	모든 리소스를 HTTPS로 변경