항상 모든 내용을 자세하게 정리하려고 노력했었는데, 이 페이스를 지속하면 쉽게 지칠 것 같아서
TIL은 최대한 짧게 정리해보려고 한다!
꾸준히 지속할 수 있는 습관을 들일 때까지 화이팅~!~!😣
브라우저의 통신 과정
1) URL 해석
URL(Uniform Resource Locator)은 scheme, user, password, host, port, url-path로 이루어진다.
scheme://[user]:[password]@[host]:[port]/[url-path]
- scheme : 사용하는 프로토콜
- user : ftp 사용시 user
- password : ftp 사용시 password
- host : 접근하려는 주소, 도메인이 여기에 포함된다.
- port : 포트 번호
- url-path : 추상화된 파일 경로
2) DNS(Domain Name System) 조회
DNS는 Domain과 IP Adress를 서로 변환해주는 시스템이다.
DNS 조회 순서는 다음과 같다.
-
브라우저의 캐시 확인
- 캐시가 존재하는 경우 IP 반환
- 그렇지 않다면 로컬 컴퓨터의 hosts 파일을 참조
-
hosts 파일에 정의가 되어있다면 IP 반환
-
hosts 파일에도 정보가 없다면 DNS 호출,
Root server -> TLD server -> Authoritative server 순으로 탐색
3) 해당 IP가 존재하는 서버로 이동
라우터(Router)를 통해 해당 IP가 있는 서버로 이동한다.
4) ARP(Adress Resolution Protocol)을 이용한 MAC Adress 변환
IP Adress는 논리적인 주소이기 때문에 상황에 따라 변할 수 있다, 그래서 통신을 위해 기기의 실제 주소인 MAC Adress를 필요로 하게 된다.
MAC Adress는 네트워크 내에 ARP Broadcasting을 해서 해당 IP 주소를 가지고 있는 기기의 MAC Adress를 얻어온다.
5) 웹 서버와 TCP 연결
3 way handshake를 이용해서 웹 서버에 연결하며, 정상적으로 연결되었다면 데이터를 전달함.
6) 클라이언트에게 응답
서버는 HTTP 프로토콜로 전달받은 패킷을 해석해서, 요청에 따라 적절한 응답을 한다.
HTML을 응답받은 경우 브라우저의 렌더링 과정을 통해서 화면에 그려진다.
HTTP와 HTTPS의 차이
HTTP는 데이터 전송시 암호화를 지원하지 않기 때문에, 개인정보같은 중요한 데이터가 외부에 유출될 수 있는 문제점이 있다.
이러한 문제를 해결하기 위해 HTTP에 SSL을 이용한 보안기능을 추가한 것이 HTTPS이며, 사용하는 포트 번호 또한 HTTP는 80번, HTTPS는 443번으로 차이가 있다.
컴퓨터 시간
시간 표현이 문화, 역사적 사건, 사회적 합의에 의해 달라지는 경우를 해결하기 위해서 표준화를 도입.
그렇게 협정 세계시(UTC)가 탄생.
컴퓨터가 시간을 표현하는 방법
-
컴퓨터는 자체적으로 시스템 클럭을 가지고 있다.
-
시스템 클럭은 메인보드에 붙어있어 전원을 끄더라도 계속 작동한다.
-
특정 시각을 기준으로 시스템 클럭의 틱을 세서 시간을 구하는데, 이를 시스템 시간이라고 부른다.
-
시스템 시간을 값으로 표현한 것은 타임 스탬프(Timestamp)라고 한다.
-
표준으로 Unix Time(1970년 1월 1일 0시 0분 0초)을 이용한다.
컴퓨터가 현재 시간을 알아내는 방법
-
NTP(Network Time Protocol)을 통해 동기화 해서 알아낸다.
-
NTP 서버에 네트워크 요청을 통해 시간을 받아오기 때문에 인터넷의 사용이 필수적이다.
-
NTP 서버는 트리구조로 되어있으며, 각 계층을 Stratum이라고 부른다.
-
최상위 Stratum(PRC, Primary Reference Clock)으로부터 시간을 받아와서 동기화 하기 때문에, 하위 계층에 있는 Stratum은 시간 정밀도가 떨어지게 된다.
Time zone
-
모든 시간 데이터를 별도의 DB에 저장하는데, 이 데이터를 Time zone 이라고 부른다.
-
표기는 대륙/도시의 형태로 표기하고, 이 데이터는 ZoneId라고 부른다. ex) Asia/Seoul, America/New_York
-
주로 역사, 사회 문화를 고려하여 사용자의 이용 시간을 정확히 알아야 할 때 사용한다.
- 결제 시각
- 푸시 알림 시간
- UI 시각 표시
- 캘린더
UTC
- 역사, 사회, 문화에 대한 맥락 없이 사건이 발생한 시각만을 고려할 때 사용한다.
- 로깅
- 감사
- 시계열 데이터
암호화
해킹을 방지하기 위해 평문(Plaintext)을 암호문(Ciphertext)로 변환하는 것을 말한다.
단방향 암호화와 양방향 암호화가 있다.
단방향 암호화
평문을 해시 알고리즘을 이용해 복호화 할 수 없는 형태로 암호화 하는 방법.
단방향 암호화의 과정은 아래와 같다.
-
메시지 전송
-
메시지를 받으면 중간에 변조된 것이 아닌지 확인 요청
-
보낸 메시지의 해시값 생성 및 전송
-
받은 메시지의 해시값을 생성하고 해시값의 비교를 통해 확인
Rainbow Table 공격에 취약하므로, 평문에 임의의 문자열을 추가하는 Salt, 혹은 해싱을 반복해서 원문을 알기 어렵게 만드는 Key Stretching을 이용한다.
양방향 암호화
평문을 복호화 할 수 있는 형태로 암호화하는 방법.
대칭키와 비대칭키 알고리즘으로 나뉜다.
대칭키 암호 알고리즘
-
암호화를 위한 키와 복호화를 위한 키가 동일하다.
-
다수를 대상으로 암호문을 받기 힘들고, 모든 사용자가 대칭키를 알아야 하기 때문에 보안 위험이 발생한다.
-
대표적인 방식으로 AES가 있다.
비대칭키 암호 알고리즘
-
암호화를 위한 공개키와, 복호화를 위한 개인키가 따로 존재한다.
-
다수를 대상으로 하기 안전함
-
HTTPS에서 사용한다.
-
대표적인 방식으로 RSA가 있다.
이벤트 루프
Single-thread인 JavaScript 엔진에서 병렬 작업을 위해 브라우저, 혹은 node.js 환경이 제공하는 시스템
이벤트 루프는 어떠한 순서로 태스크를 처리해야 하는지 Call Stack과 Task Queue를 감시하며, 태스크의 실행 순서를 제어한다.
아래의 설명은 모두 V8 엔진 기준이다.
태스크(Task)
이벤트 핸들러를 실행하거나, setTimeout의 콜백이 실행될 때 등 비동기 작업의 단위를 태스크(Task)라고 한다.
태스크들은 태스크 큐(Task Queue)에 등록되어 가장 오래된 태스크부터 실행되며, 태스크의 종류마다 다른 태스크 큐에 등록된다.
매크로태스크(Macrotask)
-
setTimeout,setInterval함수 안에서 실행되는 콜백이 매크로태스크에 해당한다. -
매크로 태스크는 매크로태스크 큐(Macrotask Queue)에 등록된다.
-
가장 낮은 우선순위를 가진다.
마이크로태스크(Microtask)
-
Promise에 관련된 콜백(async/await 포함)이 마이크로태스크에 해당한다. -
queueMicroTask(function)함수를 이용해 의도적으로 마이크로태스크 큐에 등록이 가능하다. -
마이크로태스크는 마이크로태스크 큐(Microtask Queue)에 등록된다.
-
매크로태스크보다 높은 우선순위를 가지며, 한 번 실행되면 마이크로태스크 큐가 빌 때까지 태스크가 모두 실행된다.
애니메이션 프레임(Animation Frames)
-
requestAnimationFrame의 콜백이 이곳에 등록된다. -
매크로태스크 보다 우선순위가 높지만, 마이크로태스크 보다는 낮다.
이벤트 루프는 Call Stack에 있는 작업을 우선적으로 처리하며, 그 외의 다른 Task의 실행 순서는 아래와 같다.
Microtask -> Animation Frame -> Macrotask
모듈
-
스크립트의 크기가 커지게 되면서 전역 스코프의 오염을 막고 의존성 파악을 쉽게 하기 위해 생긴 시스템.
-
로컬에서는 동작하지 않으며 HTTP, HTTPS 프로토콜을 통해서 동작한다.
-
모듈의 특징은 아래와 같다.
- 항상 엄격 모드(use strict)로 실행된다.
- 모듈 단위 스코프를 가진다.
- 같은 모듈을 import 하면 한 번만 평가한다.
- defer를 적용한 것처럼 지연 실행되기 때문에, DOM이 생성되기 전에 스크립트를 실행해도 에러가 발생하지 않는다.
유니코드
-
다양한 나라가 서로 다른 인코딩 방식을 사용해서 생기는 문제를 해결하기 위한 산업 표준
-
최대 4바이트 영역까지 사용한다.
-
알파벳과 한글 모두 2바이트로 취급, 이모티콘은 4바이트로 취급한다.
CCS(Coded Character Set)
-
BMP(Basic Mulilingual Plane)에 현재 쓰이는 대부분의 문자가 정의되어 있다.
-
이모티콘은 BMP 영역을 벗어나 있음
-
2바이트보다 큰 문자는 Surrogate Pair를 이용해서 나타낼 수 있다.
-
Surrogate Area 영역에 있는 보조문자와 BMP 외부 영역에 있는 문자를 합쳐서 한 글자를 만든다.
CES(Character Encoding Scheme)
Code Point가 어떤 단위로 조합되어 인코딩 되는 지 정의한 것, 대표적으로 UTF가 있다.
-
Little Endian : 작은 쪽에서 큰 쪽으로 저장.
-
Big Endian : 큰 쪽에서 작은 쪽으로 저장.
BOM(Byte Order Mark)
문서의 제일 앞에 U+FEFF를 삽입하여 어플리케이션이 바이트 순서(LE, BE)를 알 수 있게 해준다.
정규 표현식
정규식에 정리해놓은 개념을 다시 보자.
쿠키와 세션, 웹 스토리지
HTTP(HyperText Transfer Protocol)
-
웹에서 클라이언트(Client)와 서버(Server)가 통신하기 위한 프로토콜
-
연결 상태를 유지하지 않는(Stateless) 프로토콜이다.
Cookie
-
클라이언트에서 저장, 관리하는 데이터. 브라우저를 닫아도 유지한다.
-
서버에서 Set-Cookie를 응답 헤더로 내려주면, 클라이언트가 응답을 받아 저장한다.
-
클라이언트에서 자체 조작이 가능하며, 수명을 정할 수 있다.
-
XSS(Cross-Site Script) 공격에 취약함. HTTPS를 사용하면 해결된다.
Set-Cookie
-
key=value형태로 이루어져 있으며, 서버측에서 응답 헤더에 담아서 보내면 클라이언트의 브라우저에서 저장한다. -
각 데이터에는 여러 옵션이 존재한다.
- Expires : 쿠키 만료 날짜를 지정
- Secure : HTTPS 에서만 쿠키를 전송
- HttpOnly : JS로 쿠키에 접근하는 것을 막는다.
- Max-Age : 쿠키 수명을 결정, 이때 Expires는 무시된다.
- Domain : 도메인이 일치하는 요청만 쿠키가 전송된다.
- Path : Path와 일치하는 요청만 쿠키가 전송된다.
Session
-
Cookie의 HTTP Session ID를 식별자로 사용자를 구분한다.
-
서버에서 자체적으로 기록하고 관리하기 때문에 사용자 수가 많을 경우 과부하가 생김.
-
그렇기 때문에 서버와 클라이언트간 인증은 JWT같은 별도의 토큰을 이용한다.
웹 스토리지(Web Storage)
쿠키의 단점을 해결하기 위해
HTML5에서 추가된 새로운 기능, 데이터를 서버가 아닌 클라이언트에 저장한다.
로컬 스토리지와 세션 스토리지로 나뉜다.
로컬 스토리지(Local Storage)
-
반영구적으로 데이터를 저장하기 때문에, 브라우저를 종료해도 계속해서 데이터가 남는다.
-
저장했던 도메인과 이용하는 도메인이 다른 경우에는 접근이 불가능하다.
-
쿠키와 마찬가지로 key-value 형태로 값을 저장한다.
세션 스토리지(Session Storage)
-
새 창을 생성할 때마다 개별적(세션별로)으로 저장되는 데이터를 관리한다.
-
세션이 종료되면 저장된 데이터는 사라진다.
-
같은 도메인이라 할지라도 세션이 다르면 데이터에 접근이 불가능하다.
-
쿠키와 마찬가지로 key-value형태로 값을 저장한다.
참고 자료
[JavaScript Visualized: Promises & Async/Await]
[JavaScript의 queueMicrotask()와 함께 마이크로태스크 사용하기]
[브라우저의 이벤트 루프 - fundametal frontend]
[[Javascript] 비동기 스케쥴링과 Frame의 Life cycle]
