Studying/API

네트워크 기초 - LAN, MAN, WAN, http, https, SOP, CORS

creamymood 2025. 5. 14. 13:45

💡 네트워크 종류

📡 1. LAN (Local Area Network)

  • 작은 지역 네트워크
  • 예: 집, 학교, 사무실 안에서 컴퓨터들이 서로 연결돼서 자료를 주고받을 수 있는 네트워크.
  • 빠르고 설정이 간단함.
  • 계층형 구조를 사용해 네트워크를 구성.
  • 보통 **스위치(Switch)**를 사용해서 장비들을 연결하고,
    **라우터(Router)**를 통해 외부 인터넷(WAN)과 연결돼.
  •  

🏙️2. MAN (Metropolitan Area Network)

  • 도시 단위의 네트워크야.
  • 주로 기업, 통신사, 정부기관이 운영.
  • 광케이블, 이더넷 링 등을 사용해 도시 내 여러 지점을 연결.
  • VLAN, MPLS 같은 기술로 네트워크 분리 및 트래픽 효율화함.

🌍3. WAN (Wide Area Network) 

  • 전 세계적으로 연결된 네트워크야.
  • 인터넷이 대표적인 WAN이야.
  • IP 주소 기반 통신, 다양한 라우팅 프로토콜(BGP, OSPF 등) 사용.
  • 속도는 느릴 수 있지만 범위는 가장 넓어.

 

🌐 웹 관련 프로토콜

4. HTTP (HyperText Transfer Protocol)

  • 웹사이트를 열 때 사용하는 **기본적인 통신 규칙(프로토콜)**이야.
  • 서버와 클라이언트(사용자 브라우저) 사이에서 정보 주고받는 약속.
  • 비연결성(Connectionless), 무상태성(Stateless) 프로토콜
  • 서버와 클라이언트는 요청(Request)과 응답(Response)만 주고받고 끝남.
  • 헤더(header), 본문(body), **메서드(GET, POST, PUT 등)**로 구성됨.

* http는 클라이언트와 서버 구조.

메시지는 요청 메시지, 응답 메시지인 http 메시지로 이루어져있고. 정해진 형식이 있다. (API)

 

*http는 비연결성

더보기

연결통로를 사용해서 데이터를 주고 받을 때 네트워크 비용이 발생.

그런데도 데이터를 주고 받지 않을 때도 네트워크 비용이 발생되는것!

(예를 들어 통화중인데, 아무 말을 안해도 연결이 되어 있으면 통화비가 나가는)..

 

따라서 > http는 비용절약을 위해서 네트워크 연결성을 끊어버리는 = 비연결성

 

기본적으로 비연결성이지만, 비연결성의 또 비효율성을 해결하기 위한 방법들을 쓰고 있다.

 

🟠 HTTP 1.0

  • 모든 요청마다 새로운 TCP 연결
  • 한 파일 받으면 연결 끊김
  • 👉 여러 이미지, JS 등 요청 = 매번 새 연결 = 느림

🔵 HTTP 1.1

  • 기본적으로 Connection: keep-alive
  • 한 연결로 여러 요청 가능
  • 하지만... 순서대로 응답만 가능
    → 앞 요청이 느리면 뒤에 줄줄이 기다림 (head-of-line blocking)

🟢 HTTP 2.0

  • 하나의 연결로 여러 요청을 동시에 병렬 처리
    → 이걸 Multiplexing이라고 해
  • 요청 순서와 응답 순서가 달라도 OK
    • 헤더 압축, 서버 push 등 더 효율적

 

🔍 각 HTTP 버전이 어떻게 개선했는지?

 

버전 비연결성 해결? 방법 특징
HTTP 1.0 기본적으로 비연결성 ❌ 없음 (요청마다 연결, 응답 후 끊음) 느림, 비효율적
HTTP 1.1 Persistent Connection 도입 ✅ 기본적으로 연결 유지 (Connection: keep-alive) 한 번 연결로 여러 요청 가능
HTTP 2.0 멀티플렉싱(Multiplexing) ✅ 하나의 연결로 동시에 여러 요청/응답 처리 가능 더 빠르고 효율적
 

 

*http는 무상태성

더보기

📦 쉽게 말하면?

서버는 클라이언트가 누구인지 매번 기억하지 못해.

HTTP는 이렇게 작동해:

  1. Jane이 서버에 "이 페이지 보여줘!" 하고 요청함
  2. 서버는 "알겠어!" 하고 응답을 줌
  3. 그다음 요청을 보낼 때 서버는
    "얘가 아까 그 Jane이구나" 라는 걸 모르고 새로 시작해

즉, Jane이 여러 번 요청을 보내도 서버는

“이 요청이 누구한테서 온 건지 몰라요~ 항상 처음 보는 사람처럼 응답할게요”
하는 거야.

🧠 왜 이렇게 설계됐을까?

  • 간단하고 빠르기 때문이야.
    서버가 매번 사용자 상태를 기억하면 복잡하고 리소스 낭비가 커.

💬 그럼 상태를 유지하려면?

  • 쿠키(Cookie)
  • 세션(Session)
  • 토큰(JWT)

이런 것들을 써서 서버가 “이 요청은 Jane 거야” 하고
사용자를 구분할 수 있게 도와줘.

 

이런 무상태성 특징으로써

무상태성이 서버 증설(확장)에 유리하다.

🌱 상태가 없다 = 서버가 사용자 기억 안 함

  • 각 요청은 독립적이고,
  • 서버는 “얘가 누구였더라?” 라고 고민할 필요가 없어

 그래서?

  • 요청을 어떤 서버에 보내든 결과가 똑같아
  • 어떤 알바생이, 주문을 받더라도 상관없는 느낌. 그래서 주문받을(서버)를 많이 늘릴 수 있는 것
    → 서버 간 사용자 상태 공유가 필요 없음

5. HTTPS (HTTP + Secure)

  • HTTP에 **보안(암호화)**을 추가한 버전이야.
  • URL이 https://로 시작하면 안전하게 정보를 주고받는다는 뜻.
  • 로그인, 결제 정보 같은 민감한 데이터 보호에 사용돼.
  • 웹사이트에서 개인정보, 비밀번호, 결제 정보를 주고받을 땐 반드시 HTTPS가 사용돼야 안전해.
  • TLS Handshake 과정에서 비대칭키 → 대칭키 방식으로 전환
  • HTTPS 사용 시 패킷 가로채도 내용은 암호화되어 노출되지 않음
  • 기본 포트:
    • HTTP: 80
    • HTTPS: 443🔐 추가 개념:
      • HTTPS를 사용하면 중간자 공격(MITM) 방지 가능
      • SSL 인증서는 **CA(인증기관)**가 발급하고, 신뢰 체인(chain of trust) 구조를 가짐
더보기
암호화 되어 있기 때문에, 데이터가 탈취 당하더라도 내용을 알 수 없다.

https의 암호화 방법 ?

 

우선 암호화 방법에는 두가지 방식

 

암호화 방식에는 암호화 할 키와 복구화 할 복구호화 할 키가 필요한데,

두개가 같다면 대칭 키 방식이고, 다르다면 비대칭 키 방식.

 

 

https는 두가지 방식 모두 사용하고,

 

인증기관과 서버는 자신이 사용할 공개키와 비밀키를 하나씩 가지고 있음

클라이언트는, 브라우저에 자기가 신뢰할 수 있는 인증 기관 리스트를 가지고 있고 그 인증기관의 공개키를 가지고 있다. 

 

 

1. https로 서버를 제공하고 싶은 서버가, 인증기관에 공개키를 보내고

2. 이 공개키를 받은 서버는 이 서버가 신뢰할 수 있는 서버인지 확인

 

3. 서버가 안전하다고 판단되면, 인증기관은 자신의 비밀키를 이용해서 서버의 공개키를 암호화 시킨다.

이렇게 공개키를 암호화한 결과물이 서버의 인증서가 된다.

4. 인증 기관은 이 인증서를 서버에게 전달 되고, 이제 이 서버는 https 서버 사용 가능

5. 이후에, 어떤 클라이언트가 이 서버가 제공하는 사이트에 접속하고자 요청을 보낸다.

6. 그러면 이 인증서를 클라이언트에게 전달하고,

 7. 자기 브라우저에 내장되어 있는 신뢰할 수 있는 인증서 리스트를 확인하고.

해당 인증서가 이 인증 기관 리스트에 있는 기관에서 발급한 리스트인지 확인

그리고 이 인증서가 신뢰할 수 있는 기관에서 발급된 인증서라면

가지고 있는 인증기관의 공개키로, 인증서를 복호화 시도

복호화가 잘 됐다면, 클라이언트는 서버의 공개키 획득

클라이언트는 대칭키를 하나 생성하고, 서버의 공개키로 대칭키를 암호화 후 서버로 전송

결과물을 받은 서버는 자신이 가진 비밀키로 복호화하여 대칭키 획득

 

따라서 클라이언트와 서버 둘 다 대칭키를 가지게 되었다.

 

결론!

 

클라이언트와 서버가 서로의 공개키와 비밀키를 가지고 있음에도, 대칭 키를 하나 더 만든 이유는

비대칭 키 방식은 너무 오래 걸리기 때문이다 !

 

🔐 보안 관련 개념

6. SOP (Same-Origin Policy)

웹브라우저 보안 정책 중 하나야.

*같은 출처(origin)**에서 온 요청만 허용(다른 웹사이트(출처)끼리는 마음대로 데이터를 주고받을 수 없어.).

* 같은 출처란? → 도메인, 프로토콜, 포트 번호가 같아야 함

 

예시: 

https://example.com 에서 로딩된 페이지는 https://example.com 서버에만 요청 가능.

https://example.com → http://example.com 요청은 SOP 때문에 차단됨.

7. CORS (Cross-Origin Resource Sharing)

SOP를 예외적으로 허용해주는 방법이야.

* 다른 출처의 자원을 사용하려면, **서버가 "괜찮아, 써도 돼"라고 허락(CORS 설정)**해야 함.

 

예시:

https://myapp.com 웹 앱이 https://api.weather.com의 정보를 가져오고 싶을 때
→ api.weather.com이 CORS 설정을 해줘야 함.

 

서버가 응답 헤더에 아래와 같은 정보 포함:

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type
  • 브라우저는 이 응답을 보고 본 요청을 진행할지 판단함.

● 실무에서 중요한 포인트:

  • CORS는 브라우저 기반에서만 동작함.
    → Postman이나 서버 간 통신은 SOP/CORS 영향 없음.
  • 서버 측에서 CORS 설정을 하지 않으면, 프론트엔드 fetch 요청이 실패함.
  • 보안상 Access-Control-Allow-Origin: *은 위험할 수 있음. (모든 도메인 허용)

출처 : 챗지피티, 오즈코딩스쿨학습자료