36일차 / HTTPS / SSL / TLS, 3-WAY-Handshake, SSR배포

HTTPS / SSL / TLS

HTTPS는 기본포트가 443번

root dns서버는 .com / .net / .shop 은 어디로 가라는 내용이 등록되어 있어서 .com / .net / .shop을 기록하고 있는 컴퓨터에 하나씩 찾아서 들어오게 된다.
root dns 컴퓨터는 전세계에 13대가 있다.
이 컴퓨터가 동시에 마비가 되면 사이트 접속이 불가능.

HTTPS로 넘어가려면 ?

SSL 인증서를 설치해야함.
무료인증서가 있고 유료인증서가 있음.
certbot을 설치를 하면 파일이 만들어진다. (무료인증서를 위한 프로그램)
구글 클라우드 플랫폼의 로드밸런서에는 클릭 한 번에 설치를 할 수가 있는 구글인증서가 있다.
(AWS에도 그대로 있음, 스토리지 이름(S3), 로드밸런서(ELB))
로드밸런서에 인증서를 설치해서 로드밸런서 기반 HTTPS 만들어보기

버전이 업그레이드 되어서 사용하는게 TLS임에도 불구하고 SSL이라고 말하는 경우가 많다.

데이터가 왔다갔다 하는 것을 볼 수 있게 해주는 "와이어샤크"
조건을 걸게 되면 해당하는 서버로 왔다갔다 하는 데이터만 필터링해서 볼 수 있다.

패킷 내용을 해킹당해 노출위험이 있기 때문에 암호화시켜야한다. => HTTPS로 바꿔야하는 이유

3-WAY-Handshake

두 개의 컴퓨터가 연결하는 과정은 3 WAY Handshake라고 한다. 3번 악수를 한다.
서버에서 싱크를 받고, 그것에 대한 응답을 함께 보낸다(싱크+응답), 알겠다고 하는 응답을 한번 더 보내게 된다.
연결을 끊을 때의 과정은 4 WAY Handshake.

어떤걸 받아올 수 있는지에 대한 옵션이 먼저 던져진다.
옵션이 던져지기 이전에 연결을 먼저 해야한다.

3 WAY Handshake로 연결하는 모습

SSR 배포

서버사이드렌더링

서버에서 데이터까지 받아와서 최종적으로 만든 HTML을 보내줘야할 때, 서버사이드 렌더링을 쓴다.
스토리지에서는 안된다. 이미 HTML,CSS,JS를 만들어서 업로드 시켜버린것이기 때문에 다운로드만 가능하고 요청은 불가능한 상태.
24시간 대기상태인 서버에서만 가능하다. => 서버가 필요!

왼쪽사진: 1차적으로 받아온 자료들
useQuery로 content를 받아오려면 2차적으로 데이터를 받아와야하는데, SSR은 1차+2차 합친것을 날려주기 위함이다.
하드코딩 된 코드는 필요 X 동적으로 값이 바뀌는 것들이 SSR이 필요하다.
그런 부분이 어디있을까? ex) 게시글 상세보기, 상품 상세보기 ...

1번: 페이지 요청
2번: 서버사이드 렌더링 실행
3번: 프론트에서 백엔드 요청
4번: 백엔드에서 응답
5번: 리턴

이렇게 하면 해당 페이지에서만 서버사이드 렌더링이 작동.
useQuery는 아폴로셋팅이 다 되어있는 경우에만 가능.
하지만 여기서는 안하고 있어서 불가능하다.
이럴 때 쓰는 게 axios, 혹은 graphql-request를 사용해주면 된다.

이제 SSR 된 페이지를 배포해보자.
구글 클라우드 플랫폼에서 컴퓨터를 빌림.

외부IP: 외부에서 입력하고 엔터칠 때.
내부IP: 컴퓨터끼리 연결할 때. (우리가 설정X, VPC 내부에서 결정)

로드밸런서에 있는 IP도 외부 IP