2월 8일 월 개발일지

누군가에게 도움이 될 목적이다보단,
스스로 배운 내용 들을 잊지 않기 위해 작성하는 것이니
정확하지 않을수도 있습니다. 개인적인 생각과 하루하루
기록하고 싶은 마음 뿐입니다.✨
-생활코딩 및, 구글링으로 정리한 내용입니다.

next_public

기본적으로 모든 환경 변수 .env.local 은 Node JS 환경에서만 사용할수있다.
브라우저에 노출되지 않는다.

현재 프로젝트에서는 host info , test info , multi client 에서 사용하는 URI 주소이다 .

nextJS에서의 컨벤션이다 .

https 와 SSL

https ⇒ Over Secure Socket Layer 보안이 강화된 http

웹이 인터넷 위에서 돌아가는 서비스 중 하나인 것처럼

https도 ssl 프로토콜 위에서 돌아가는 프로토콜이다.

SSL

네스케이프에 의해서 SSL 이 발 명되었다. 폭 넓게 사용 되다가 표준화 기구인 IETE의 관리로 변경되면서
TLS 라는 이름으로 바뀌었다. 하지만 지금은 TLS 보다 SSL 이름을 훨씬 많이 사용하고있다.

❗️ 그러면 SSL이란 무엇인가?

SSL 은 무엇인가?

디지털 인증서는 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서이다.

클라이언트가 서버에 접속한 직후에 서버는 클라이언트에게 이 인증서 정보를 전달한다.(공증과도같은 역할

• 통신 내용이 공격자에게 노출되는것을 막을 수 있다. - 암호화
• 클라이9언트가 접속하려는 서버가 신뢰 할 수 있는 서버인지를 판단 할 수 있다.
• 통신 내용의 악의적인 변경을 방지 할 수 있다.

대칭키

대칭키는 보내는사람이 보내는 내용을 어떠한 규칙이나 설정으로 암호화를 해서 상대방으로 전송하면

상대방은 역으로 반대의 순서로 암호를 풀어 해독하는 방식이다.

ex) ⇒ 보낸쪽 232#$$%!/3(key) = 안녕하세요

 받는쪽  232#$$%! / 3(key) = 안녕하세요 이렇게 키값을 알고있어야 해독이 가능하다 

하지만 간단해보일것같지만 결국에 한번은 서로 키값을 알기위해 어떻게 해독하는지에 대한 키를 보내줘야하기때문에 결국 보안에 취약할수밖에없다 그래서 나온것이 비대칭키 !

비대칭키(공개키)

서로 다른 키를 가지고 정보를 주고받는 방법이다.

예를 들어 네이버에 접속한다고 가정해보자 네이버로 접속할수있는 공개키로 열려있다.

그 주소로 접근할려면 그주소가 공개한 공개키에 접속되는것이다.(public_key)

내 컴퓨터 브라우저에서 네이버로 접속을 시도 한다 이때에 내 컴퓨터의 브라우저가

네이버로 접속을 시도한다.
클라이언트측에서 네이버로 접속했지만 아직 신뢰하지 못하는상태가되는데

이때에 네이버 서버와 클라이언트 브라우저에서 서로 탐색과정을 거치게되고 이를 handshacke

악수라고 한다.

클라이언트에서 어떠한 랜덤 데이터를 실어보내면 네이버 서버에서 응답으로 또다른 랜덤데이터 내용과
서버의 인증서를 함께 실어보낸다. 이과정이 서로 악수를 한것이다.

이제 브라우저에서는 내장된 CA들의 정보를 비대칭시스템을 통해 확인하게 된다.

보낸 내용이 네이버에서 보낸게 진짜라면 CA에서도 발급되어 있는 공개키로 복호화 할수가 있다.

이 공개키로 복호화될 수있는 인증서를 발급할수있는건 개인키를 가진 CA 뿐일테니까 말이다.

만약 키가 없다면 not secure 라고 뜨게된다.

복호화가 된 상태라면 이미 인증서로 실어보낸 내용중 공개키가 포함되어있게된다.

이제 서로 통신을 주고받을수 있는 상태가되었다.

그러다면 실제 통신은 비대칭으로만 이루어질까?

no!

이제부터는 대칭키 방식과 비대칭키 방식이 함께 혼합되어서 사용되어진다.

비대칭키로 정보를 전달하는것은 컴퓨터에 큰부담을 주기때문에 대칭키를 사용한다.

그런데 대칭키로만 하면 보안에 취약하다고했는데?

그건 바로 그 대칭키를 사용할때 비대칭키로 통신 하는것이다.

❗️ 확인차원에서 이루어진 악수 과정에서 그 대칭키가 암호화되서 만들어지게된다.

이렇게 되면 3자가 내용을 가로챈다해도 암호를 풀기가 어려워지는것이다!

DNS (domain Name System)

DNS SERVER⇒ 수많은 IP 주소의 도메인이 저장되어있다.

IP와 hosts

IP ⇒ 내 컴퓨터의 주소

host ⇒ 각각에 인터넷에 연결되어있는 컴퓨터

mac ⇒ /etc/hosts
ex) 192.501.230.0 www.webserver.com

이렇게 수정 할 수 있다.

클라이언트가 서버로 접속할때는 서버의 IP를 알아야한다.

이렇게 93.184.216.34 IP 주소를 example.com이란 도메인이름으로 갖게 하고싶다 라고

Domain Name System Server에 요청한다 .

도메인 네임은 이렇게 세분화 되어있는데

각각 전담하는 서버들이 다르다

root 서버는 top-level을 담당하는 애들을 알고있어야하고

top-level은 second-level 을 담당하는 애들을 알고있어야한다

이렇게 각각 서버는 하위 서버들을 알고 있게 된다.

단 상위 레벨은 하위레벨 서버만 알고있을뿐 그하위 아래 하위서버는 알지못한다.

사용자는 어떻게 주소를 알아가게될까?

1. 사용자가 root 서버에게 요청을한다
2. root 서버는 잘모르겠지만 top-level 서버한테 물어 보라면서 top-level 도메인 주소를 알려준다.
3. top-level 서버도 마찬가지로 모르겠다면서 second-level 서버의 주소를 알려준다
4. 이런식으로 sub 서버까지 내려가게 된다.

이렇게 전세계의 도메인주소를 알수있게 되는것이다. www. OOO 주소를 쳐서 들어갈수있는 이유가 여기에있다.

전체적인 통신 흐름을 보자

루트서버를 관리하는 단체와 top-level 서버를 관리하는 단체 쉽게 도메인을 등록할수있게 도와주는 등록대행자

가있고 등록자가 등록대행자에게 요청을하면 절차대로 등록이 이루어진다

그리고 클라이언트 브라우저에서 이제 등록된 도메인네임으로 접속을 할려고하면

내 컴퓨터 IP 주소를 연결 해놓은 dns 서버(현재쓰고있는 인터넷망) 가 존재하게 되는데

그 서버가 요청을 한다 위에서 말한것처럼 root ⇒ top-level ⇒ second-level ⇒ sub 절차대로 갔다가

최종적으로 다시 내컴퓨터 ip와 연결되어있는 DNS 서버로 응답을주어 내컴퓨터로 다시 응답해주게된다

이게 너무 빠른속도로 진행되는것이다.

한번 접속했던 부분들은 dns 서버가 기억하고있게된다

매번 통신을 통해 접속을 하게된다면 그것또한 시간이 걸리는 작업이 될것이다.

저장은 cache를 통해 기억된다.

느낀점
매번 느끼는거지만 무수히 많은 개발지식들과 배워야할 부분이 너무나 많아
정말 죽을때까지 공부해야한다는 생각이 든다.
실제 개발을 해보면서 많은 문제에 직면했다.
어떤환경에서는 실행이안되고 어떤 부분들은 또, 다르게 바꿔줘야하고
알면알수록 너무 깊은 세계..
가치가 있는 것을 얻는길은 지름길이 없다고 한다.
그냥 반복이고 익숙해지는것 어제보다 성장하는 오늘이 되길 바랄뿐이다!!

그래도 즐겁게 하고있으니 그것만으로도 다행이다!

내일은 어떤 에러와 마주하게될까?