Node.js / 네트워크 기초

 

네트워크의 종류

 

네트워크는 데이터를 전달하는 반경, 속도에 따라 LAN, MAN, WAN으로 나눌 수 있다.  

 

	LAN(Local Area Network)	MAN (Metropolitan Area Network)	WAN(Wide Area Network)
범위	좁음(주로 집, 사무실, 건물, 캠퍼스 내의 제한된 영역)	도시나 대도시의 통신망을 의미	넓음(국가나 대륙 간의 범위)
구성	단순  <------------------------------------>  복잡
속도	빠름  <------------------------------------>  느림

 

* LAN : 정확히는 동일한 Subnet Mask를 이용한다면 근거리 통신망이 되기 때문에 LAN이라고 볼 수 있다.

* MAN : 두 개 이상의 LAN으로 연결되어 구성되며, 라우터 / 브릿지 등으로 연결된다. 

* WAN : 넓은 지리적 영역에 걸쳐 분산된 모든 대규모 네트워크를 WAN이라고 하며, 인터넷도 WAN으로 볼 수 있다.

 

 

네트워크의 계층

계층 이름	설명	프로토콜	전송단위	장비
응용 계층 (Application Layer)	사용자와 네트워크 간 응용서비스 연결, 데이터 생성	HTTP, FTP, SMTP, POP3, IMAP 등	데이터 (Data)	호스트 (PC 등)
표현 계층 (Presentation Layer)	데이터 형식 설정, 부화 교환, 암·복호화해 변환	JPEG, MPEG 등
세션 계층 (Session Layer)	송수신 간 논리적 연결 설정·접속, 동기화 기능	RPC, NetBIOS 등
전송 계층 (Transport Layer)	송수신 프로세스 간 연결, 데이터 전송의 신뢰성 보장, 데이터 분할 / 재조립 / 흐름·오류·혼잡 제어	TCP / IP, UDP 등	세그먼트 (Segment)	L4 스위치
네트워크 계층 (Network Layer)	단말기 간 데이터 전송을 위한 최적화된 경로 제공, 논리적 주소(IP 주소) 관리	IP, ICMP, RIP, OSPF 등	패킷 (Packet)	라우터
데이터 링크 계층 (Data Link Layer)	물리적 네트워크 연결 설정, 인접 시스템간 데이터 전송, 동기화, 오류·흐름·회선 제어	HDLC, PPP, 프레임 릴레이, ATM 등	프레임 (Frame)	브리지, L2 스위치
물리 계층 (Physical Layer)	비트 정보를 회선에 보내기 위한 전기적 신호 변환	RS-232C	비트(Bit)	허브, 리피터

 

 

캡슐화, 역캡슐화

이미지 출처 : 팔만코딩경

 

데이터를 보내기 위해서는 헤더(* 데이터의 앞부분에 전송 시 필요한 정보)를 붙여 다음 계층으로 보낸다. 

이처럼 데이터를 송신하는 측에서 헤더를 붙여나가는 것을 캡슐화라고 하며,

데이터를 수신하는 측에서 헤더를 하나씩 제거해나가는 것을 역캡슐화라고 한다.

 

 

---

 

 

HTTP

HyperText Transfer Protocol의 약자로, 웹 기반 응용 프로그램에서 가장 많이 사용되는 프로토콜이다.

일반적으로 TCP/IP 통신 프로토콜 기반으로 동작한다. 

 

 

클라이언트 서버 구조

출처 : 오즈코딩스쿨

 

HTTP는 클라이언트 - 서버 구조를 가지고 있는데, 클라이언트가 요청을 하면 서버에서 응답하는 방식이다.

이 때 요청 / 응답 시 오고가는 메시지를 HTTP 메시지라고 한다.

 

HTTP 메시지는 다음과 같은 형태로 이루어져있다.

첫 줄에는 HTTP 요청 메서드, URL 경로, HTTP 프로토콜 버전 정보를 담고 있으며

두 번째 줄부터는 HTTP 요청의 헤더들인데, 헤더는  key:value  쌍으로 이루어져 있다.

헤더에는 웹사이트 도메인의 호스트, 언어, 사용자의 브라우저같은 정보가 있다.

 

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept-Language: ko-KR

 

 

브라우저의 네트워크 탭에서도 확인해볼 수 있는데, 왼쪽은 헤더, 오른쪽은 헤더 값들이다.

 

 

무상태성

HTTP에서 서버는 클라이언트의 상태를 기억하지 않는다.

HTTP 요청은 각각 독립적이기 때문에, 클라이언트에서는 서버에 요청을 보낼 때 마다 필요한 모든 정보를 매번 함께 보내야 한다.

예를 들어 API에서 연결하기 위해 필요한 키나 토큰의 경우라던가, 로그인 된 유저의 정보 등은 서버가 기억하지 못하므로, 매 요청마다 토큰 등을 보내서 인증해야 한다.

 

(매번 아래와 같은 인증 정보를 보내야한다...)

GET /user/profile
Authorization: Bearer eyxxxxxxx...

 

 

비연결성

출처 : 오즈코딩스쿨

 

HTTP에서는 요청 - 응답이 끝나면 연결이 바로 끊어버리기 때문에, 서버에서는 동시에 많은 요청을 효율적으로 처리할 수 있고 연결 중에 지출되는 비용을 아낄 수 있다. (요청 - 응답이 끝나더라도 연결이 계속 되어있다면 서버 비용이 지출된다...)

 

 

 

HTTPS

 

Hypertext Transfer Protocol Secure의 약자로, 모든 요청 및 응답을 SSL(Secure Socket Layer) 및 TLS(Transport Layer Security) 프로토콜에 따라 브라우저와 서버가 데이터를 전송하기 전 데이터를 암호화한다.

 

암호화 방식

1. 대칭키 암호화 방식

- 하나의 키가 존재하며, 암호화, 복호화할 때 동일한 키가 사용되는 방식

- 속도가 빠르지만 보안성이 미흡함

 

2. 비대칭 키(공개 키) 방식

- 두 개의 키가 존재하며, 암호화하는 키와 복호화하는 키가 다른 방식

- 암호화 연산 시간이 오래 걸리고 비용이 큼

 

HTTPS에서는 두 가지 방식을 모두 사용한다! ⬇️

 

서버 ↔ 인증기관

1) 서버가 인증기관에 자신의 공개키를 보냄

2) 인증 기관은 해당 서버가 신뢰할 수 있는 서버인지 확인하고, 신뢰할 수 있다고 판단 되면 인증 기관의 비밀키로 서버의 공개키를 암호화

3) 인증기관이 발급된 인증서를 서버에게 전달

4) 서버에서는 HTTPS 사용 가능

 

클라이언트 ↔ 서버

5) 클라이언트가 HTTPS로 접속 요청

6) 서버가 HTTPS 통신을 위해 인증서 전달

7) 클라이언트는 브라우저에 내장된 인증 기관 리스트를 확인 후, 신뢰할 수 있는 인증 기관이면 가지고 있는 공개키로 인증서 복호화 시도

7-1) 만약 복호화가 안된다면 인증서가 잘못된 것 => HTTPS 연결 실패

8) 복호화 성공 => 클라이언트는 서버의 공개키 획득

9) 클라이언트 측에서 대칭키 생성

10) 서버의 공개키로 대칭키를 암호화

11) 암호화한 대칭키를 서버로 전송

12) 비밀키로 복호화해 대칭키 획득

13) HTTPS 연결 성립!

=> 이후로는 데이터 교류 시 대칭키를 이용해 암호화 및 복호화

HTTPS 인증 방식

• 비대칭 키 방식 -> 인증서 발급 & 검증할 때, 대칭키를 주고 받을 때
• 대칭 키 방식 -> 클라이언트와 서버가 데이터를 주고 받을 때

 

 

---

 

 

 

SOP_CORS

SOP

Same-Origin Policy (동일 출처 정책)의 약자로, 동일한 출처(Origin)의 자원만 가져올 수 있으며, 서로 다른 출처간의 리소스 접근을 기본적으로 차단한다.

 

출처(Origin) : 프로토콜 + 도메인 + 포트

위 세 가지가 모두 같아야 동일 출처로 판단된다!

 

ex) https://example.com:443 라는 origin이 있다면

http://example.com → 프로토콜 다름
https://api.example.com → 도메인 다름
https://example.com:3000 → 포트 다름

 

ex) http://localhost:5174

http://localhost:3000 → 포트 다름
https://localhost:5174 → 프로토콜 다름
http://127.0.0.1:5174 → 호스트 다름

 

 

 

CORS

Cross Origin Resource Sharing (교차 출처 리소스 공유)의 약자로, 다른 도메인, 프로토콜 또는 포트 간 웹 페이지와 서버의 자원을 공유할 수 있도록 허용하는 보안 메커니즘이다. SOP로 인해 기본적으로 차단된 요청을 허용할 수 있게 하는 메커니즘이다. 

 

CORS 에러

CORS가 가능하도록 설정하는 가장 간단한 방법은 서버에서 직접 응답 헤더를 세팅하는 것이다.

 

CORS 헤더

• Access-Control-Allow-Origin: 리소스에 접근할 수 있는 주소
• Access-Control-Allow-Methods: 서버에서 허용할 HTTP 메서드
• Access-Control-Allow-Headers: 서버에서 허용할 HTTP 헤더

 

CORS 설정 시 / 설정을 안하거나 요청을 거부했을 시

 

- Preflight Request (사전요청) : 본격적인 요청 전에 서버 측에서 그 요청의 메서드와 헤더에 대해 인식하고 있는지를 확인하는 CORS 요청 (말 그대로 사전에 미리 요청해보는 것)

 

 

 

 

참고
LAN : https://aws-hyoh.tistory.com/entry/LAN-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
WAN : https://www.cloudflare.com/ko-kr/learning/network-layer/what-is-a-wan/
OSI 7계층 : 수제비 - 정보처리산업기사 실기 
캡슐화/역캡슐화 : https://80000coding.oopy.io/2a16be4e-9187-4ce7-86b0-cb8e7b1e26af 
HTTP : https://docs.tosspayments.com/resources/glossary/http-protocol
HTTPS : https://velog.io/@ddangle/HTTPS%EB%8A%94-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%95%94%ED%98%B8%ED%99%94%ED%95%98%EB%8A%94%EA%B0%80 
CORS : https://en.wikipedia.org/wiki/Cross-origin_resource_sharing#:~:text=CORS%20(%20%EA%B5%90%EC%B0%A8%20%EC%B6%9C%EC%B2%98%20%EB%A6%AC%EC%86%8C%EC%8A%A4%20%EA%B3%B5%EC%9C%A0,%EC%9E%88%EB%8F%84%EB%A1%9D%20%ED%97%88%EC%9A%A9%ED%95%98%EB%8A%94%20%EA%B2%83%EC%9E%85%EB%8B%88%EB%8B%A4. 
Preflight Request : https://developer.mozilla.org/ko/docs/Glossary/Preflight_request