프론트엔드 데브코스 5기 TIL 2일차

타래·2023년 9월 21일
국비지원교육코딩부트캠프프로그래머스 데브코스프론트엔드 데브코스
0

네트워크 기초

주소창에 url을 입력하면, 잠시 로딩 후 해당 페이지로 이동하게 됩니다.
이때, 잠시 로딩하는 동안 어떤 일이 일어나고 있는걸까요 ?

  1. URL을 해석합니다.

  1. DNS (Domain Name System) 조회

    DNS는 도메인과 IP주소를 서로 변환해줍니다.

    헷갈리는 단어인, 도메인과 IP주소에 대하여 알아보겠습니다.

도메인 : 웹사이트의 이름과 주소입니다.
사람이 읽을 수 있는 주소로, IP 주소를 사람이 기억하기 쉽게 만든 것입니다. 
		일반적으로 "www.naver.com"과 같은 형식을 가집니다.

IP주소 : 인터넷 프로토콜 (IP)에서 컴퓨터, 서버 또는 장치를 고유하게 식별하는 숫자로 된 라벨입니다.
일반적으로 IPv4 로써 네 개의 숫자 블록으로 구성되며, 데이터 패킷이 올바른 위치로 전송되도록 돕습니다.
  1. 해당 IP가 존재하는 서버로 이동합니다.

  2. ARP을 이용해 MAC 주소 변환을 합니다.
	여기서 IP주소와 MAC 주소는 각각 논리주소와 물리주소 입니다.
	MAC 주소는 기계의 실제 위치를 알기위해 필요합니다.
	그리고 ARP는 논리주소를 물리주소로 변환해주는 역할을 하는 프로토콜입니다.

	여기서, 왜 논리주소와 물리주소를 구분하는 것일까요?
	청와대를 기준으로 
	   - 논리주소: '서울 종로구 청와대로 1'
	   - 물리주소: '위도와 경도' 등으로 나타낼 수 있습니다.
  
	택배를 보낸다고 가정하면, 논리주소만 봐서는 정확한 위치를 알기 어렵습니다.
	표기 체계가 바뀐다거나 하는 경우도 생길 수 있으니까요.
	그래서 물리주소가 필요합니다.

	또한 위 주소에서 각 도시들 중 서울을 먼저 선택합니다. 
	이후에 종로구, 청와대로, 1번지를 선택하듯 
	논리주소는 대역을 통해 범위를 좁혀나갑니다.
  1. TCP 통신을 통해 Socket을 열어야 합니다.
  2. 서버는 응답을 반환합니다.
  3. 브라우저는 렌더링 합니니다.

추가적으로, HTTP가 이미 있음에도, HTTPS는 왜 탄생했는지, 왜 필요한지 알아보겠습니다.

HTTPS는 HTTP에 SSL/TLS 암호화 계층을 추가하여 통신을 보호합니다.

HTTPS를 사용함으로써
1. 데이터의 기밀성
2. 데이터의 무결성
3. 쿠키 및 세션 보호
등을 얻을 수 있다는 장점이 있습니다.

또한, 클라이언트와 서버 간에 통신을 시작할 때, 암호화된 연결을 설정하기 위해
SSL/TLS 핸드셰이크가 발생합니다.
이는 클라이언트와 서버 간의 안전한 연결을 초기화하고 설정하는 과정입니다.
이 과정에서 양쪽 모두 통신에 사용될 암호화 알고리즘과 키를 협상하며, 서버의 신원을 검증합니다.

암호화

단방향 암호화와 양방향 암호화

  • 단방향 암호화 ?
    한 방향으로 암호화해서 보내는 방법입니다.
    따라서 원본 데이터를 복구할 수 없는 방식으로 변환합니다.
    이러한 특성 때문에, 주로 패스워드와 같은 민감한 데이터를 보관할 때 사용합니다.

    하지만 이러한 단방향 암호화는, 동일한 메시지에 동일한 다이제스트를 갖게 됩니다.
    오늘 a를 해쉬해도, 내일 a를 해쉬해도 같은 결과값이 나온다는 뜻입니다.
    이 경우, 해커들이 여러 값들을 대입해보면서 얻었던 다이제스트들을 모아놓은 리스트인,
    레인보우 테이블에 우리의 소중한 데이터가 해커들의 손에 넘어갈 수 있습니다.

    이를 방지하기 위해 salt, key stretching 방식 등으로 해시 함수를 보완하곤 합니다.

  • 양방향 암호화 ?
    암호화된 데이터에 대한 복호화가 가능한 암호화 방식.
    대표적으로 대칭키, 공개키 암호화 방식이 있습니다.

    • 대칭키
      대칭키는 암복호화키가 동일하며, 해당 키를 아는 사람만이 문서를 복호화해 볼 수 있게 합니다.
    • 공개키
      키가 공개되어있기 때문에, 키를 교환할 필요가 없어집니다.
      공개키는 모든 사람이 접근 가능한 키이고, 개인 키는 각 사용자만이 가지고 있는 키 입니다.

함수형 프로그래밍

함수형 프로그래밍 ?

데이터를 한 함수에서 다음 함수로 전달하여 데이터를 가공하고,
이러한 일련의 함수 호출을 통해 새로운 데이터를 만드는, 데이터 파이프라인 형태로 프로그램이 작동합니다

객체지향에서는 추상화의 최소 단위가 객체! 함수형은 최소단위가 함수입니다.
때문에 함수형이 재사용성이 높다는 장점이 있습니다.

또한, 함수형은 불변성을 지향합니다.
이에 Side Effect를 최소화하거나 제어할 수 있고, 동작을 예측하기 용이합니다.

// 예를 들어
const str = '123';
// str의 각 숫자의 합인 6을 함수형으로 구해보겠습니다.

console.log(
  str
    .split("")
    .map((v) => +v)
    .reduce((a, b) => a + b, 0)
);

물론 함수형에도 단점은 있습니다.

데이터의 불변성 때문에, 

a = a + 1;

와 같은 단순한 계산도 데이터를 변경하는 대신, 새로운 데이터를 생성하여 반환하는 방식을 사용합니다.
이는 불필요한 메모리 낭비가 발생할 수 있습니다.
또한 재사용성이 높다는 것은 함수를 잘게 쪼갠다는 뜻이고, 코드가 복잡해질 수 있다는 단점이 있습니다.

그렇다면 둘 중 JS는 어떤 방식을 사용할까요 ?

둘 다 입니다. JS는 함수형 + 객체형인 멀티 패러다임이 가능하니, 둘 다 사용하는 것이 좋을 것 같습니다.


명령형 프로그래밍 vs 선언형 프로그래밍

  • 명령형 프로그래밍 : 어떻게(How) 작업을 수행할 것인지를 명시하는 방식입니다.
  • 선언형 프로그래밍 : 무엇(What)을 얻고자 하는지를 명시하고, 시스템은 어떻게(How) 그 목표를 달성할지를 처리합니다.

객체지향과 프로토타입

객체지향의 객체는 현실에 있는 것을 추상화 한 것 !

이때 추상이란, 사물이 지니고있는 여러 측면 중 특정한 부분만 보는 것

마치 지구본을 펼친 평면지도를 보는 것 처럼
(구체를 펼친 것이기에 손실이 있는~)

Prototype

부모 유전자를 상속받는 것과 유사하다고 생각합니다.

우선, 간단한 예시를 보겠습니다.

function Person(name, age){
	this.name = name;
	this.age = age;
  
 	this.getName = function() {
      return this.name;
    }
   	this.getAge = function() {
      return this.age;
    }
}

const me = new Person('bgh', 1);
console.log(me);
/*	
	이때, 출력된 me 값은 , 다음과 같습니다.
	Person {
	  name: 'bgh',
	  age: 1,
	  getName: [Function (anonymous)],
	  getAge: [Function (anonymous)]
	}
   	당장 필요하지않은 메서드들까지 포함되어, 메모리 낭비가 되고 있습니다.
*/

프로토타입은 위와 같은 문제를 해결할 수 있습니다.

	this.getName = function() {
      return this.name;
    }
	// 위 코드를 아래와같이

	Person.prototype.getName = function() {
      return this.name;
    }

이제 me는 Person {name: 'bgh', age: 1} 값만을 가지게 됩니다.
또한 프로토타입 체인으로 연결된 하위 자식들은, 부모의 부모가 (혹은 그 이상) 가진 프로토타입을 사용할 수 있습니다.

쿠키와 세션, 웹 스토리지

HTTP Request는 기본적으로 상태가 존재하지 않아, 서버는 어떤 브라우저에서 온 것인지 기억을 하지 못합니다.
따라서 헤더에 쿠키를 담아 보내고 있습니다.
(이때 쿠키는 브라우저를 닫더라도 로그인 정보가 남아있는 등을 도와주는, 데이터를 유지할 수 있게끔 도와주는 역할을 합니다.)

사실 클라이언트가 쿠키를 서버에다 보내도, 서버는 쿠키 주인을 모릅니다...
때문에 세션을 추가해서 보냅니다.
쿠키에 HTTP Session ID를 식별자로 넣어 보냅니다.

이외에도 새로운 표준으로 나타난 웹 스토리지가 있습니다.
웹 스토리지는 클라이언트 사이드에서 Key-Value 형태로 데이터를 안전하게 저장할 수 있게 도와주는 웹 API로써, 쿠키 대신 로컬 데이터를 관리해줍니다.

웹 스토리지는 로컬 스토리지와 세션 스토리지로 구분됩니다.

  • 로컬 스토리지 : 데이터를 반영구적으로 저장하고싶을때 유용합니다.
    또한 저장한 도메인과 이용하는 도메인이 다르면 접근할 수 없다는 특징이 있습니다.
  • 세션 스토리지 : 새 창 or 새 탭마다 개별적으로 데이터를 관리하며, 브라우저를 닫으면 사라집니다.
    또한 세션이 서로 다르다면 데이터에 접근할 수 없다는 특징이 있습니다.

웹 스토리지는 쿠키보다 훨씬 큰 데이터를 저장할 수 있으며, 데이터를 클라이언트 사이드에 저장하기에 서버에 추가적인 부하를 줄일 수 있습니다.
(쿠키와 세션의 경우 서버의 파일에 저장되는데, 수천 수만명의 접속자가 서버에 접속한다면 서버는 큰 부하를 겪게되는 단점이 있습니다.)

후기

깊게 파고들면 끝도 없는 내용들이다보니, 얕게만 공부하려해도 굉장히 오래 걸리는 것 같습니다 ;ㅅ;
주말 이용해서 조금 더 공부해보며 익숙해지기위해 노력하겠습니다.

profile
타래
이전 포스트

프론트엔드 데브코스 5기 TIL 1일차

다음 포스트

JS Linked List 구현 연습

0개의 댓글