비전공자의 전공자 따라잡기 - 네트워크, HTTP

HTTPS

과정을 볼 때 알아야할 것

공개키로 암호화한 것은 비밀키로 복호화, 비밀키로 암호화한 것은 공개키로 복호화할 수 있다.
비밀키는 개인키라고도 한다. (전체적은 과정은 밑에)

HTTPS가 필요한 이유

HTTPS (HTTP Secure)는 HTTP protocol의 암호화된 버전이라고 한다.
보안이 뛰어나다는 것이다.

내가 들어간 사이트가 정말 내가 찾는 사이트가 맞는지, 안전한 사이트가 맞는지, 인증된 사이트가 맞는지 확인하려면 필요하다.
단순히 주소를 보면 알 수 있는 것이 아니다.
해커가 만든 사이트일 수도 있기때문에 안전한 사이트인지 잘 봐야한다.
아무리 주소 이름이 같아보여도 다른 문자하나를 바꿨을 수도 있다.

인증된 사이트인지 확인하는 방법

정말 Naver가 맞는지 증명하려고 한다면 서버는 인증서를 발급받는다.
주소옆 자물쇠를 누르고 인증서 정보를 볼 수 있다. 발급기관과 세부정보 등 볼 수 있다.
네이버 인증서가 있을 것이고 CA1, CA로 3개의 계층으로 되어있다. 3개보다 많을 수도 있다.
혹시나 인증서 자체가 변조될 수 있기때문에 더 단계적으로 나눈 것이다.
해커가 2개 이상 변조하기는 어렵기때문이다.

팁

인증서를 무료로 발급해주는 곳이 있다.
개인사이트 서버에 HTTPS를 적용하고 싶다면 Let’s encrypt로 인증서를 발급 받는 것이 좋다!

RSA

공개키로 인증서를 복호화를 하면 하나 더 생긴다.
서버 공개키다. 인증서 안에 있던 것이다.
공개키가 있으면 서버 비밀키가 있다.
데이터 암호화용 키를 브라우저가 만든다.
그리고 데이터 암호화용 키를 서버 공개키로 암호화하여 서버에 보내준다.
그렇게 되면 서버에서는 서버 비밀키로 복호화를 할 수 있고
데이터 암호화용 키를 클라이언트(브라우저)와 동일하게 가지게 된다.
클라이언트와 서버는 서로 동일한 키를 갖고 있어서 암호화된 HTTP데이터를 주고 받을 수 있게 된다.
이 방식을 RSA라고 한다. 공개키, 비밀키를 사용한 RSA

RSA 단점

데이터 암호화용 키를 해커가 알아버리면 데이터를 주고 받을 때 어떤 데이터인지 다 알 수 있게 된다.

더 좋은 방법

더 개선된 알고리즘으로 DH가 나왔다.
키를 보내는 것이 아니라 키를 만들 수 있는 조각을 보내서 키를 만든다.
이 조각을 해커가 얻어도 아무것도 할 수 없다.
DHE을 적용하면 특정시간마다 데이터 키를 자동으로 변경해준다.
유출이 됐다고 하더라도 일정시간만 볼 수 있고 또 바뀌어버린다.
RSA보다는 보안이 더 뛰어난 DHE을 더 많이 쓴다.

HTTPS의 전체적인 과정

클라이언트와 서버로 나누어 생각하면 된다.

서버는 CA로부터 인증서를 발급받겠다고 한다.
CA라는 인증서 발급기관에서 인증서를 서버가 받게 된다.
CA는 인증서(비밀키)를 암호화해서 서버에 저장한다.

브라우저가 정말 Naver가 맞는지 물어본다. 이 때 서버가 인증서 암호화한 것을 전달한다.
브라우저는 CA가 공개키를 제공을 해두기때문에 가지고 있다.
그 공개키로 복호화하여 서버를 믿을 수 있다고 판단한다.
믿을 수 있다고 판단되면 서버 공개키를 브라우저가 갖게 된다.
서버 공개키로 데이터 암호화용 키를 만들 수 있는 조각을 서버로 전달한다.
서버는 자기만의 조각을 클라이언트에 보낸다.
조각을 서로 주고 받게 되면 서로 간의 조각으로 데이터 암호화용 키를 만든다.
그 후에 HTTP데이터를 암호화하여 주고 서버에서는 복호화한다.
혹시나 데이터가 유출이 되더라도 특정시간마다 키를 계속 변경해주는 알고리즘을 사용한다.

복호화가 되지 않는다거나 풀었더니 다른 사이트일 경우 안전하지 않은 사이트라고 판단한다.
브라우저에서 안전한 연결이 아니다라고 나오는 것을 볼 수 있다.

HTTP/2, HTTP/3

HTTP1.1에서 HTTP2/HTTP3까지 나온 이유와 역할, 장점

HTTP

설계가 text기반이지만 현재로써는 미디어가 맞다.
TCP의 특징인 3 way handshake도 비효율적이다.
요청을 할 때마다 매번 3 way handshake과정을 거쳐야한다는 것이 비효율적이기 때문에 여러가지 해결방법이 나왔다.
connection : Keep-Alive » HTTP1.0가 유명하다.
HTTP1.1에서는 이것이 기본이 됐다.

Keep-Alive라는 헤더에 정해놓은 시간이 흐르지 전까지는 연결이 끊기지 않는다.
3 way handshake을 하고 나서 연결을 한번만 했어도 연결이 끊기기 전까지는 매번 3 way handshake 과정을 거치지 않아도 된다.
아직 부족하긴 하다. 무수한 요청을 보내는 것은 connection으로는 힘들다.
HOL블로킹(Head of line blocking)이라는 현상때문에 실제로는 사용하지 않게 됐다.
Head of line blocking 검색해보기!

HTTP2

HTTP에 있던 문제들이 많기때문에 HTTP2를 만들게 된다.

SPDY라는 프로토콜을 쓰다가 표준인 HTTP2가 되었다. 구글에서 생각한 것이다.
HTTP의 비효율성때문에 데이터 낭비가 많은 거 같다라고 해서 만들게 됐다.

특징은 바이너리기반이다. / 0과 1(bit)
미디어들을 전송할 때 더 효율적이다.
Text기반이 아니기때문에 와이어샤크로 분석할 때 어렵다.
알아보지 못하는 것이 많아졌다.

하나의 커넥션안에서 여러 스트림을 사용한다.
하나의 커넥션을 맺어도 동시에 여러 개의 요청을 보낼 수 있게 됐다.
스트림은 우선순위가 있어서 어떤 것을 먼저 받을지 순위를 정할 수 있다.

헤더를 압축할 수 있게 하여 용량을 줄였다.

서버푸시 방식이다. 예전에는 서버에서 html을 보내고 브라우저가 css와 js를 파악하고 서버로 보내고 받고 하는 방식이였다.
HTTP2에서는 더 효율적으로 서버에서 html을 보내면서 css와 js를 파악하여 같이 요청없이도 보낼 수 있도록 만들었다.
서버에서 코딩을 해줘야한다는 것은 어쩔 수 없다.

HTTP2에서는 HTTPS가 필수다.
브라우저 구현에서는 HTTPS없이 HTTP2를 쓰는것이 구현이 되어있지 않기때문에 HTTPS를 강제적으로 적용해야 HTTP2를 쓸 수 있다.
큰 제약은 아니다.

HTTP2는 아직도 TCP기반이다.
TCP는 패킷손실이라는 것이 있다.
인터넷 환경이 좋지 않아서 IP가 다녀갈 때 손실이 될 수 있다.
인터넷 환경이 좋지 않으면 TCP 성능이 안 좋아진다.
HTTP2에서 인터넷 환경이 좋지 않으면 성능이 좋지 않다라고 알아두자.

HTTP3

HTTP3에서는 패킷손실을 UDP로 극복을 한다.
패킷손실 시에도 성능이 저하되는 것을 줄였다.
더이상 TCP를 사용하지 않게 만들었다.
UDP기반이기때문에 동영상 속도가 빠르다는 장점이 있다.
구글이 QUIC이라는 프로토콜을 써서 HTTPS가 필수다.
요즘에는 TLS1.2를 쓰지만 HTTP3에서는 TLS1.3을 쓴다.
0RTT(제로RTT)라는 것이 있다. (보안위협이 존재한다.)
3 way handshake 문제를 극복했다고 보면 된다.
원래는 3RTT로 3번이나 왔다가지만 너무 비효율적이니 HTTP3에서는 1번으로 줄였다.
안전한 환경에서는 0RRT(0번)까지도 가능하다. 성능이 좋게 만들었다.
더 자세히는 검색!

웹소켓

웹소켓

웹소켓은 프로토콜이다.

node.js실습을 할 때 바로 서버 실행을 하지 않고
npm i라는 명령어로 설치를 하고 실행을 해야한다.
웹소켓이라는 프로토콜을 바로 지원하지 않기때문에 node.js에서 실행시키려면 필요한 것이다.

웹소켓을 쓰는 이유

우리가 지금까지 배웠던 것은 항상 클라이언트에서 요청을 보내고 서버가 응답하는 방식이었다.
서버에서 먼저 데이터를 보낼 수는 없다.
서버에서 실시간 데이터를 받아오고 싶을 때 HTTP는 난감하다.
클라이언트가 매번 매초마다 요청을 하는 것은 비효율적이다.
이 불편함을 해결하기 위해 웹소켓이라는 프로토콜을 만들었다.
물론 웹소켓도 클라이언트가 요청 한 번은 해야한다.
한 번 서버와 연결을 맺었다면 또 요청을 하지 않아도 그 연결을 통해 데이터를 받아올 수 있다.
실시간 데이터 전송을 하는 것에는 꼭 웹소켓을 많이 쓰기때문에 알아둬야 한다.
실시간 데이터를 전송해야한다거나 양 쪽에서 데이터를 많이 주고 받으려면 웹소켓 프로토콜로 업데이트를 하면 좋다.
앱으로도 웹소켓을 지원하는 게 있다.
node.js 같은 것에서 웹소켓을 지원하지 않더라도 직접 지원하게 만들어주는 라이브러리를 설치하면 쓸 수 있는 경우가 많다.
웹소켓은 모든 서버, 모든 클라이언트가 지원하지 않을 수 있기때문에 항상 연결을 맺어보고 되면 쓰고, 연결이 되지 않는다면 HTTP로 보낸다.

VPN, (포워드,리버스)프록시/게이트웨이

VPN의 역할, VPN을 사용하는 이유

VPN : Virtual Private Network (가상 사설망)

집과 회사를 생각해보자. 모두 땅에서부터 네트워크를 설치해놨다고 보면 된다.
인터넷은 누구나 이용할 수 있다. 공개가 되어있는 네트워크로 데이터가 흐른다.
집과 회사에서 공개 되어있는 망이 아니라 사설망은 물리적으로도 설치하는 것과 비용이 엄청 들고 말이 안 된다.
회사와 회사(지점) 간에는 사설망을 설치할 수 도 있지만…
사설망을 더 선호하기때문에 생각한 것이 VPN이다.
사설망을 따로 설치하지 않고도 공개 네트워크를 사용하면서 사설망처럼 동작할 수 있도록 만든 것이다.
공개 네트워크 안에서 VPN을 사용해서 사설망의 효과를 낸다.
그래서 가상의 사설망이라고 한다.

VPN을 설치하면 앞으로 인터넷 접속을 할 때 VPN을 통해 인터넷에 접속하게 된다.
마치 회사와 사설망을 통해 데이터를 주고 받는 것처럼 보인다.
감시나 필터링을 할 수 있고 이 데이터는 같은 프로그램에서 인증되지 않으면 외부로 공개가 되지 않는다.
이런 이유때문에 VPN을 사용한다.

VPN을 깔았다.
미국인 척을 하려고 할 때 사설망을 설치한 효과를 내기때문에 사설망에 미국이라고 적혀있다면 마치 우리는 미국에서 접속을 한 것처럼 보일 수 있다.
국가의 검열 이슈나 개인정보 이슈를 피해가기 위해 VPN을 쓰기도 한다.
공개 인터넷은 그대로 쓰는 것이지만 사설망의 효과를 내서 그 효과를 위해 VPN을 쓴다.

회사의 VPN을 통해 접속했다고 한다면
내가 컴퓨터에서 인터넷 접속을 한 기록들을 볼 수 있다…조심ㅋㅋ

Proxy

클라이언트 > 프록시 > 인터넷 연결 > 프록시 > 서버 남의 인터넷에 접속하기 위해 요청을 보내는 과정이 필요한 것인데 남의 서버로 갈 때는 인터넷을 거친다.

요청을 보내는 과정에서 인터넷으로 가기 직전에 프록시 서버(Forward)가 하나 있을 수 있고 거치지 않을 수도 있다.
요청이 상대방 서버에 도착을 했는데 진짜 서버에 도착한 것이 아니라 프록시 서버(Reverse)가 요청을 대신 받을 수 있다.

클라이언트는 왜 바로 인터넷으로 가지 않고 프록시를 거칠까?
서버는 요청을 왜 바로 받지 않고 프록시를 거칠까?
클라이언트에서의 포워드 프록시는 무슨 역할인지, 서버에서의 리버스 프록시는 무슨 역할인지 보면 된다.

Forward Proxy: 불필요한 헤더 제거를 제거할 수 있다.
브라우저에서 불필요한 헤더를 자동으로 추가해서 서버로 요청을 보낼 수도 있다.
우리들의 IP나 다른 헤더들이 있을 수 있고 지우고 싶어도 지울 수 없는 경우가 있다.
브라우저가 헤더를 넣는 경우라서 손을 댈 수 없는 경우,
포워드 프록시를 클라이언트 서버쪽에 세팅을 해두면 브라우저가 불필요한 헤더를 넣는 것을 지울 수 있다.
혹시나 실수로 악성 서버에 요청을 보내는 것을 포워드 프록시에서 필터링을 거쳐서 요청이 가지 않게 할 수 있다.
포워드 프록시는 서버로 요청이 가기 전에 진짜 이 요청이 가도 되는 것인지 검사, 필터를 거친다고 보면 된다.

Reverse Proxy: 불필요한 요청이 왔을 경우 필터링을 해준다. 압축도 가능하다.
HTTPS를 적용해주는 역할도 할 수 있다. 정적파일 서빙의 역할도 있다.
html, css, js, image 등 진짜 서버를 거치지 않고 리버스 프록시에서 자체적으로 제공을 해줄 수 있다.

로드밸런싱, 오토스케일링

진짜서버가 여러개일 수도 있다. 1, 2, 3…
요청별로 어떤 진짜 서버로 요청을 보내줄지 요청을 분배하는 것을 로드밸런싱이라고 한다.
한 서버에만 요청이 많이가서 터지지 않도록 요청 분배를 하는 것이다.
로드밸런싱하고 같이 생각해야 될 것이 오토스케일링이라는 것도 있다.
로드밸런싱으로 요청분배를 나눌 수 있지만 너무 버거운 요청량이라면 자동으로 서버를 늘려주는 것이다.
리버스 프록시에서 그것을 판단하고 진짜 서버 개수를 줄이거나 늘려준다.

이런 작업들은 진짜 서버도 가능하지만 왜 리버스 프록시가 대신 할까?

진짜 서버보다 프록시가 더 잘하기때문이다.
서로 잘하는 것이 다르기때문에 역할을 나눠서 수행한다고 보면 된다.
제일 큰 이유는 필터링이다.
장점을 정리하자면 이상한 스팸 요청들을 필터링을 할 수 있고 HTTPS를 적용할 수 있고 정적파일 서빙과 압축, 로드밸런싱을 할 수 있다.
진짜 서버도 할 수 있는 것들이지만 리버스 프록시가 더 효율적으로 잘 수행하기때문에 프록시가 대신 해준다.

Gateway

기본 역할은 프로토콜을 변경해주는 것이다.

클라이언트 요청을 HTTPS로 보냈다고 한다면 서버로 요청이 가기 전에 게이트를 거쳐서 HTTP로 바뀐다거나 웹소켓 등으로 바뀌는 것을 처리해주는 것이다.
프록시처럼 중간역할을 하는 서버인 것이랑 똑같다.
게이트웨이의 목적은 프로토콜을 바꿔주는 것이다.

Gateway와 프록시의 구별이 유명무실한 이유

리버스 프록시에서 HTTPS적용이 가능하다는 역할을 보면 게이트웨이의 역할과 다르지 않다.
인터넷을 통해 HTTPS요청이 온다면 리버스 프록시에 HTTPS를 적용을 했다고 치면 진짜 서버에서는 주로 HTTP로 데이터를 주고 받는다.
HTTPS로 암호화하고 복호화하는 것도 자원이 드는 이유도 있고 굳이 같은 서버 내부에서 암호화할 필요가 없기때문이다.
리버스 프록시에 HTTPS를 적용해놨고 HTTPS요청이 오면 자동으로 HTTP로 복호화해서 진짜 서버한테 전달할 수가 있는 것이다.
리버스 프록시를 중심으로 프로토콜이 변경된다.
게이트웨이의 역할도 할 수 있고 더 다양한 역할을 수행할 수 있기때문에 게이트웨이를 굳이 쓰지 않는다.
그렇기 때문에 게이트웨이와 프록시를 엄격하게 구별하지 않는다.
API 게이트웨이라는 것이 있는데 그 게이트웨이를 의미하는 것이 아니라 프록시를 의미한다.
구별을 크게 하지 않아서 게이트웨이라고 해도 프록시일 것이다.