프론트엔드 데브코스 5기 TIL 2 - JS주요문법

김영현·2023년 9월 21일

국비지원교육 코딩부트캠프 프로그래머스 데브코스 프론트엔드 데브코스

TIL

목록 보기

2/129

네트워크 기초

네트워크는 따로 조금 더 깊게 배워둬서 훑고 지나갔다.
단, 일련의 흐름은 리마인드할 필요가 있음

브라우저가 URL해석
hosts에 dns-ip캐싱 안되있으면 프로토콜스택 의뢰해서 udp로 gethostbyname
스위치 => 라우터 거쳐서 IP가 존재하는 대역으로 이동
목적지 서브넷 도착했으면 ARP이용해서 해당 IP의 MAC주소 찾음
소켓 open해서 서버와 3hand-shake
서버 응답 받아옴
브라우저가 토큰 => 노드 => 파싱단계 거쳐서 DOM, CSSOM 합쳐서 렌더트리 => 레이아웃 => 리플로우..

마지막엔 숙제를 내주셨다!

https

https는 http의 보안을 위해 탄생했다. 본래 http는 전혀 암호화되지 않음.
따라서 정보가 노출되면 치명적인 상황이 생길 수 있음.

https://velog.io/@loevray/CS-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC1-Http-IP-DNS#http-hyper-text-transfer-protocol
https://velog.io/@loevray/CS-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC2-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%8A%A4%ED%83%9D-%EB%9E%9C-%EC%96%B4%EB%8C%91%ED%84%B0#%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%8A%A4%ED%83%9D%EC%97%90-http%EB%A9%94%EC%8B%9C%EC%A7%80%EB%A5%BC-%EB%84%98%EA%B2%A8%EB%B3%B4%EC%9E%90
http 통신방식에 대해서는 자세히 기술해놓았다.

https는 비대칭 공개키방식을 사용하여 전송 내용을 암호화 한다.
이 유형의 방식은 2가지 키를 사용한다.

개인 키 : 서버에 저장. 비공개며, 공개 키로 암호화된 정보를 해독하기위해 사용.
공개 키 : 공개 키는 공개되어있음. 하지만, 공개 키로 암호화된 정보는 개인 키로만 해독 가능
=> 그래서 비대칭이며, 공개키다.

암호화를 도와주는 계층을 SSL(Secure Sockets Layer)라고 한다.
1999년 이후에는 TLS(Transport Layer Security)라고 불리운다.

어떻게 안전한 통신을 할까?

https://www.cloudflare.com/ko-kr/learning/ssl/what-happens-in-a-tls-handshake/

기존의 3hand-shake가 진행된 뒤 4번의 handshake를 더 거침.

아래는 tls 1.3버전 이전의 교환 방식.

클라이언트가 기존의 SYN처럼 Hello메시지를 보낸다.
TLS버전, 암호 제품군, 클라이언트 무작위 바이트 문자열 포함.
서버 역시 답장으로 Hello메시지를 보낸다.
서버의 SSL 인증서(공개 키 포함), 서버 암호 제품군, 서버 무작위 바이트 문자열 포함.
서버에서 받아온 SSL인증서를 클라이언트가 검증. 이때 발행기관에 검증을 맡김.
클라이언트가 예비 마스터 암호를 전송. => 공개키로 암호화 되어있어서, 서버가 개인키로만 해독가능.
서버가 예비 마스터 암호를 해독.
클라이언트, 서버 모두 예비 마스터 암호를 이용해 세션 키 생성 => 둘 다 같은 결과가 도출되야함.
클라이언트가 세션 키로 암호화된 Finished 전송. 이후 서버도 같은 메시지 전송.
세션키를 이용해 통신 계속 진행.

=> 1.3버전 이후에는 4가지로 줄어들었다.

클라이언트가 hello메시지전송.
이때 서버가 선호하는 키 교환방식을 알고 있음(1.3부터 단순화 됨). 예비 마스터 암호 포함
서버도 예비 마스터 암호 생성 가능. 서버가 hello + hellodone메시지전송. 이때 인증서, 예비 마스터 암호도 포함.
클라이언트가 서명 및 인증서 확인 후 완료!
서버도 완료!

또한, 1.3버전 이후에는 이미 연결된 적 있는 클라이언트-서버는
왕복통신이 필요없이 서로만의 암호를 통해 빠르게 연결함!

그림으로 알기 쉽게 설명되어있는 사이트도 있음!
https://howhttps.works/ko/why-do-we-need-https/

컴퓨터 시간

클럭기반

특정 시각을 기준으로 시스템 클럭 틱 세는것으로 결정. === 시스템 시간
값으로 표현하면 TimeStamp. 운영체제마다 다를수 있음.

클럭 틱은 RTC라는 부품으로 셈. 카운터 회로의 결정 진동자가 만드는 주파수를 이용
1클럭에 32.768kHz
=> 32.768khz는 32768hz라고 볼수있음. 보통 실제클럭이 128번뛰면 카운터는 이를 1번이라고 인지함.
32768/128 = 256. 타이머의 카운터는, 오버플로우 인터럽트라는 방식을 사용함
=> 클럭 카운팅의 레지스터값은 보통 8bit임. 0~255니까 256부터 오버플로우발생. 인터럽트해서 카운터 채감 = 그때가 1초.

운영체제가 유닉스면 UNXI TIME을 사용. 기준시 1970-01-01 0시 0분 0초. 이전은 음수

NTP

위의 방법만으로는 로컬 컴퓨터 시간만 정확해짐. 통신을 위해서는 서로의 시간이 맞아야 함.
이를 위해 Network Time Protocol이 생김.
NTP서버에서 시간을 뿌려줌. 최상위 서버는 원자시계 이용. 각 PC는 UDP통신으로 시간을 받아옴.
서버가 한정되어있으면 패킷 너무 많이들어온다. => 트리구조로 된 시간서버들이 있음. 거기서 받아옴.
오차가 수ms 이하. 아주 정밀하다.

출처 : https://ko.wikipedia.org/wiki/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC_%ED%83%80%EC%9E%84_%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C

세계적 시간대 고려

현실 세계의 시간대 데이터를 모아둔곳이 존재함.
ex)서머타임, 갑자기 시간대를 바꾸는 경우 등.

https://www.iana.org/time-zones
알고보니 최상위 도메인 관리하는 사이트에서 제공해주고 있다!
표기법은 보통 대륙/도시 형태다.

글로벌 서비스를 운영하려면 시간대가 굉장히 중요함.

절대적 시간도 필요함
=> 생일, 기념일, 국경일 등
UTC는 사건이 발생한 시각만 고려할때 사용.
=> 로깅, 감사, 시계열 데이터, 주식
Time zone은 사용자 기준으로 시간을 보여줘야 할 때
=> sns 타임라인, 결제시각, 푸시알림 등.

구체적 예제

a라는 유저의 생일은 절대적 시간.
글이 포스팅 된 시각은 UTC
a라는 유저 본인이 보게 될 시각은 UTC에서 계산된 time zone

Date객체

길어져서 분리...
https://velog.io/@loevray/%EB%8F%99%EC%9E%91%EC%9B%90%EB%A6%AC-4-JS%EB%8D%B0%EC%9D%B4%ED%8A%B8-%EA%B0%9D%EC%B2%B4

암호화

평문 > 암호 만드는 것. 무전병이었어서 잘 알쥐...
단방향, 양방향 암호화 존재.
단방향부터 살펴보자

단방향

대표적으로 MD5, SHA가 있음
이중 MD5, SHA0, SHA1은 해시 충돌이 일어남.
해시충돌이란?
=> 해시함수는 본래 다른 값 입력되면 다른값 출력되어야함. 그런데, 확률적으로 같은값이 출력되버릴 수 있음. 이는 모든 해시함수가 그렇다. 다만 위의 예들은 이미 충돌쌍이 발견 됨.

평문과 해시함수로 이루어진 표, rainbow table유출 주의
유출 되더라도 알아낼수 없게 salt, key stretch같은 기능으로 조치 해야함.
=> 평문에 임의의 문자열 추가해서 해시함수 돌리거나, 해시함수를 반복해서 돌림.
PBKDF2, bcrypt가 있음.

양방향

양방향 알고리즘은 대칭 키-비대칭 키둘로 나뉜다.

대칭 키 : 같은 key로 암호-복호화 가능
비대칭 키 : 공개키, 개인키 두가지가 존재. 소수(prime num)활용.

브라우저에서의 암호 보관

나도 의문이 들었다. 강사님께서 추측하여서 표를 보여주시긴했지만, 나도 한번 찾아보려고 했다.
보안상 알고리즘을 전부 노출시키진 않겠지만 조금은 나와있겠지?

https://security.stackexchange.com/questions/244795/how-does-google-save-our-passwords-on-their-server

구글 비밀번호 관리자는 그냥 텍스트로 저장하는거였다.
...??!

함수형 프로그래밍

프로그램은 순차, 분기, 반복, 참조로 구성된다. 패러다임은 이를 어떻게 이용할지 다루는 것 뿐.

추상화의 최소단위는 함수
데이터의 불변성 지향 => 사이드이펙트를 방지하면 동시성 문제 해결 원만

https://velog.io/@loevray/CS-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C5-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%8F%99%EA%B8%B0%ED%99%94
https://velog.io/@loevray/CS-%EC%9A%B4%EC%98%81%EC%B2%B4%EC%A0%9C5-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4-%EB%8F%99%EA%B8%B0%ED%99%942
동시성 문제는 여기...
함수단위로 나뉘어져서 재사용성 높음 => 객체보다 더 작은단위. 귀찮겠지만 재사용성이 더 높겠구나
코드가 짧고 간결

하지만, 장점이 그대로 단점이 될수도 있다.

데이터의 불변성 => 작은 데이터를 바꾸려고 원본을 복사해서 수정 후 덮어쓰기...시간,공간 낭비
함수단위로 나누어짐 => 귀찮음
코드가 짧고 간결 => 난이도 높음

선언형 프로그래밍

함수형 프로그래밍은 선언형 프로그래밍에 가깝다.
예를들어 [1,2,3,4,5]의 배열을 더하는 작업을 나타내보자

// 명령형
const arr = [1, 2, 3, 4, 5];
let sum = 0;
for(let i = 0; i<arr.length; i++){
	sum += arr[i];
}
return sum;
// 선언형
const arr = [1, 2, 3, 4, 5];
return arr.reduce((a,b) => a+b);

비슷하지만 사고방식이 다르다.
명령형 프로그래밍은 데이터의 제어 필요없이 필요한 함수만 뚝딱 사용하면 됨
뭔가 반복문vs재귀 사고방식과 비슷한것 같기도 하고...

사실 JS는 패러다임을 나눌 필요가 없다.

객체지향과 프로토타입

간단하게 객체지향을 다루고 JS에서의 객체지향은 따로 문서를 파놨다.(계속 업데이트중)

https://velog.io/@loevray/OOJSObject-oriented-JavaScript

객체는 현실을 추상화한것.
내 방식대로 이해한 추상화는 어렵고 복잡한 기능을 사용자가 쉽게 사용할 수 있게 엮어낸 것 이라생각한다.

예를들어 운영체제. 운영체제는 CPU, 메모리 등 하드웨어관리를 한다.
자원분배도 하고, 오류도 검출하고. 사용자가 이를 전부 알 필요는 없다.
그저 작업관리자에서 뚝딱하고, 메모리 많이 잡아먹는건 꺼버리고.
또한 하드웨어 드라이버도 마찬가지다. 사용자가 입-출력장치가 어떻게 돌아가는지는 전혀 알 필요가 없다.
추상화 잘 된 드라이버를 설치해서, 호환되게 한다. 그뿐이다.
잡설은 여기까지 하고.

객체지향의 추상화 최소단위는 객체.
객체끼리 메시지 주고받기 가능(절차지향은 공유메모리에 접근하는 것이라면, 객체지향은 프로세스들이 소켓통신을 하는 느낌)

이벤트 루프

길어져서 따로 분리.
https://velog.io/@loevray/%EB%8F%99%EC%9E%91%EC%9B%90%EB%A6%AC-6-JS%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%B4%EB%B2%A4%ED%8A%B8-%EB%A3%A8%ED%94%84

모듈

현대의 웹사이트는 여러개의 JS파일로 이루어져있음.
예전에는 전역스코프에서 파일간 통신했지만, 파일 크기가 커지면서 힘들어짐.
모듈은 스크립트간 의존도 파악, 실행순서 제어에 큰 도움을 줌.
모듈과 컴포넌트는 비슷하게 쓰임

모듈 : 설계단계에서 의미가 있음.
컴포넌트 : 실행단계에서 의미가 있음.

참고로 JS모듈은 로컬환경에서 동작x. http, https에서 동작.
모듈의 특징들은 이렇다

단 한번만 평가됨(2번이상 선언해도 의미x)
전역변수 선언해도 레벨스코프 존재
지연실행됨(defer와 같음)

요즘은 webpack으로 번들링(파일 하나로 합쳐줌)하기에 type=module을 사용하진 않는다.

유니코드

이모지는 길이 2
한글,영어 등 언어는 길이 1

정규표현식

패턴을 이용하여 문자열 검색
성능이 구리다 => 백트래킹 방식
현업 개발자들도 찾아보면서 사용하기에 외울필요 x(아주좋소)
정규표현식으로 잘라내려면 패턴찾기.
개미수열을 정규식으로 풀어보자

쿠키, 세션, 웹 스토리지

http통신은 기본적으로 stateless.
서버에게 주는 헤더에 쿠키를 담으면, 서버가 어디서 온것인지 파악 가능.

쿠키는 브라우저에서 유지하는 데이터.
수명을 정할수도 있음.
서버에서 set-cookie로 내려줄수 있음.
쿠키에는 다양한 옵션 존재.
쿠키 탈취 가능. => https로 해결(네트워크 부분에서...)

서버가 사용자를 구분하려면?
session을 사용해 구분. 서버에 기록함.
최근에는 서버 공간복잡도 문제, 다중서버 문제때문에 잘 사용x

html5에서 웹 스토리지가 등장.
로컬,세션 스토리지.

로컬스토리지
저장했던 도메인과 다르면 접근불가능. 키-밸류쌍

세션스토리지.
새 창마다 세션 생김. 브라우저닫으면 삭제. 같은 도메인이어도 세션다르면 접근 x. 키-밸류쌍.

느낀점

가볍게 다루지만, 깊이있게 공부해야하는 주제만 나온다. 역시 데브코쓰...
아직도 남아있는 것들

OOJS 완성하기
쿠키, 세션, 웹스토리지 차이점 정확히 구분
개미수열 정규식으로 풀어보기
유니코드...는 깊게 알 필요가 있을까 싶기도 하고. 이모지와 언어의 길이차이가 나는것은 일단 알았다

김영현

모르는 것을 모른다고 하기

이전 포스트

프론트엔드 데브코스 5기 TIL 1 - JS 주요문법

다음 포스트