이런 저런 관련 단어들이 익숙하지만, 머릿속에서 제대로 정리되지 않았던 내용들을 정리해보았다. 개발 공부 처음할 때, 취업 준비할 때도 공부했던 내용들인데, 다시 보니 모두 새롭네.

🎨 브라우저의 렌더링 원리

브라우저는 HTML, CSS, JS 파일을 받아 화면에 그림을 그린다.

1. HTML 파싱 → DOM(Document Object Model) 생성

   HTML 코드를 한 줄씩 읽어 DOM 트리 생성

2. CSS 파싱 → CSSOM(CSS Obejct Model) 생성

   CSS 파일 혹은 <style> 내용을 읽어 스타일 정보를 트리로 생성

3. Render Tree 생성

   DOM과 CSSOM을 합쳐 실제로 화면에 보여줄 요소와 스타일 정보를 가진 Render Tree를 생성

4. Layout (배치)

   각 요소의 크기와 위치를 계산. 반응형 레이아웃일 경우 화면 크기에 따라 이 과정이 달라짐

5. Paint (그리기)

   계산된 정보대로 픽셀을 그림. 배경색, 글자, 이미지 등이 렌더링

6. Composite (합성)

   여러 레이어를 합쳐 최종적으로 화면에 표시

🧑🏻‍🎨 Reflow와 Repaint

• Reflow

  • 브라우저가 요소의 크기나 위치를 다시 계산하는 과정

  • 노드 추가/삭제로 DOM 구조가 변경될 때, 요소의 크기나 위치가 변경될 때, 폰트가 변경되거나 창 크기가 변경될 때 → Layout 재계산이 필요할 때

  • Layout → Paint → Composite 전 과정을 다시 하므로 큰 비용

• Repaint

  • 요소의 색상, 배경, 그림자 등 시각적 표현만 다시 그리는 과정

  • 요소의 크기나 위치에는 영향을 주지 않는 스타일만 변경될 때 → Layout 계산은 건너뛰고 픽셀만 다시 칠함

  • Paint → Composite 만 다시 하므로 상대적으로 가벼운 과정

🖼️ 브라우저 렌더링 성능 최적화

• DOM 조작 최소화, 조작을 한 번에 모아서 처리

• CSS 변경을 묶어서 처리

• CSS 속성 중 layout에 영향을 덜 주는 속성 활용 (transform, opacity)

• 애니메이션은 가능하면 GPU 가속 속성 활용

🔗 주소창에 google.com을 입력하면 일어나는 일

[입력] → [네트워크 요청] → [브라우저 렌더링]

1. URL 해석

   브라우저가 주소를 분석해서 프로토콜(https), 호스트(google.com), 경로(/)를 구분

2. DNS(Domain Name System) 조회

   google.com의 실제 IP 주소를 찾기 위해 로컬 캐시 → OS 캐시 → DNS 서버 순으로 조회

3. TCP 연결

   IP 주소를 알면, 서버와 TCP 3-way handshake로 연결

   • 클라이언트 → 서버: 연결 요청

   • 서버 → 클라이언트: 요청 확인 + 응답

   • 클라이언트 → 서버: 응답 확인

   위 3번의 패킷 교환이 끝나면 통신 준비 완료

4. TLS handshake (https인 경우)

   인증서 교환과 암호화 키 설정으로 안전한 통신 채널 생성

   • 서버가 인증서 전송 → 브라우저는 인증서가 신뢰할 수 있는 기관이 발급했는지 확인

   • 암호화 키를 서로 안전하게 교환 (대칭키/비대칭키 조합)

   • 이후 모든 데이터는 암호화되어 전송

5. HTTP 요청 전송

   브라우저가 서버로 GET / HTTP/1.1 요청과 함께 헤더(쿠키, User-Agent 등)를 전송

6. 서버 응답

   서버가 HTML 문서(+ CSS, JS, 이미지 경로)를 응답

7. 추가 리소스 요청

   브라우저가 HTML을 읽으며 <link>, <script>, <img> 등을 발견하면 다시 DNS 조회 → TCP 연결 → 요청 과정을 수행

8. 브라우저 렌더링

   • HTML 파싱 → DOM 생성

   • CSS 파싱 →CSSOM 생성

   • JS 실행

   • Render Tree 생성 → Layout → Paint → Composite

📦 브라우저 저장소

모두 브라우저에 데이터를 저장하지만, 용도/용량/수명/전송여부가 다르다.

1. LocalStorage

   • 수명: 명시적으로 삭제하기 전까지 영구 저장

   • 용량: 도메인당 약 5~10MB

   • 전송 여부: HTTP 요청시 서버로 자동 전송 안함

   • 용도: 사용자 설정, 캐싱 데이터 등 장기 보관

     • 자동 로그인

2. SessionStorage

   • 수명: 브라우저 탭이 닫힐 때까지 유지

   • 용량: 도메인당 약 5~10MB

   • 전송 여부: 서버로 자동 전송 안함

   • 용도: 페이지 세션 동안만 필요한 임시 데이터

     • 입력 폼 정보, 비로그인 장바구니

3. Cookie

   • 수명: 설정된 만료일 또는 브라우저 종료 시까지

   • 용량: 약 4KB

   • 전송 여부: 같은 도메인 요청시 HTTP 헤더에 자동 포함

   • 용도: 세션 식별, 로그인 상태 유지, 서버 측 인증

     • 팝업 창

   • HTTPOnly, Secure 속성을 설정하여 XSS나 탈취 방지

• LocalStorage는 XSS 공격에 취약하기 때문에 JWT와 같은 인증 토큰은 HTTPOnly Cookie에 저장하여 자바스크립트 접근을 막는 것이 안전합니다.

• LocalStorage와 SessionStorage는 API가 동일하며 차이는 저장 범위와 수명입니다.

  • 메서드 이름과 사용법이 동일하며 둘 다 문자열 형태로만 저장 가능

  • 둘 다 도메인 단위로 접근 가능

🪙 JWT (JSON Web Token)

• JSON 객체를 Base64URL로 인코딩한 문자열 토큰으로, 인증과 정보 전달에 사용

• 구조 (Header.Payload.Signature) - xxxxx.yyyyy.zzzzz

  • Header: 토큰 타입과 서명 알고리즘 정보

  • Payload: 실제로 담고 싶은 정보

    { "sub": "1234567890", "name": "Yoon", "admin": true, "exp": 1691587200 }

  • Signature: Header와 Payload를 비밀키로 서명한 값, 토큰 위변조 방지

• 동작 방식

  1. 사용자가 로그인하면 서버가 JWT 생성/서명하여 클라이언트에 전달

  2. 클라이언트는 JWT를 HTTPOnly 쿠키에 저장

  3. 이후 요청시 Authorization 헤더에 JWT를 함께 전송 Bearer <JWT>

     • Bearer: ‘이 토큰을 가진 사람은 자원에 접근할 수 있다’는 인증 방식을 의미

  4. 서버는 서명 검증을 통해 토큰의 무결성과 유효기간을 확인

  5. 검증 성공시, 토큰의 Payload 정보를 사용해 요청 처리

• 장점

  • 무상태 (stateless): 서버가 세션 상태를 저장할 필요 없음

  • 범용성: 다양한 서비스, 도메인 간 인증에 사용 가능 (OAuth 등)

  • 빠른 검증: 서명만으로 인증 가능

• 단점

  • 발급 후 즉시 폐기 불가 (만료 전까지 유효 → 블랙리스트 관리 필요)

  • Payload는 암호화가 아님 (Base64URL은 누구나 디코딩 가능) 민감정보 금지

  • 토큰 길이가 길어질 수 있음 (HTTP 헤더 부담)

📡 REST API (Restful API)

• REST (Representational State Transfer)

  자원을 이름(URI)으로 구분하고, HTTP 메서드(CRUD - GET, POST, PUT, DELETE 등)로 자원을 처리하는 아키텍처 스타일, 원칙

  • 클라이언트 - 서버 구조

    UI(클라이언트)와 데이터 저장(서버) 역할을 분리

  • 무상태성 (stateless)

    각 요청은 필요한 모든 정보를 포함, 서버는 세션 상태 저장 안함

  • 캐시 가능 (cacheable)

    서버가 응답에 캐시 여부를 명시하면 클라이언트가 response를 캐싱하여 성능과 트래픽 최적화

  • 계층 구조 (Layered System)

    로드밸런서, 프록시, 게이트웨이 등 중간 계층 투명 사용 가능

  • 통일된 표준 인터페이스

    HTTP 메서드, 상태 코드, MIME 타입 등 표준 규칙 준수

  • 코드 온 디맨드 (Optional)

    필요시 서버에서 클라이언트로 실행 코드 전송 (JS)

• Restful API

  REST 원칙을 엄격하고 충실하게 지킨 API

• /getUsers → 이는 URI에 행위(get)가 포함되므로 Restful하지 않다. 행위는 HTTP 메서드로 표현해야 한다.

• HTTP 메서드

  • GET: 요청받은 URI의 정보를 검색하여 응답

  • POST: 요청된 자원을 생성

  • DELETE: 요청된 자원을 삭제

  • PUT: 요청된 자원 전체를 수정

  • PATCH: 요청된 자원 일부를 수정

  • HEAD: GET 방식과 동일하지만 응답에 BODY가 존재하지 않으며 응답코드와 HEAD만 응답, 메타데이터 확인 용도

  • OPTIONS: 웹서버에서 지원되는 메서드의 종류를 확인하는 경우, CORS 사전 요청(Preflight)에서도 사용

  • CONNECT: HTTPS 프록시 연결시 사용

  • TRACE: 요청 경로 추적, 디버깅용으로 보안상 거의 사용되지 않음

• HTTP 메서드의 안전성, 멱등성

  • 안전성 (safe)

    호출해도 서버 상태가 변하지 않음 → GET, HEAD, OPTIONS

  • 멱등성 (idempotent)

    여러 번 호출해도 결과가 같음 → GET, PUT, DELETE

📄 HTTP, HTTPS

• HTTP (HyperText Transfer Protocol)

  • 웹에서 데이터를 주고받는 기본 통신 규약

  • 암호화 없이 평문(Plain text)으로 전송

• HTTPS (HTTP Secure)

  • HTTP에 SSL/TLS 암호화 계층을 추가한 보안 버전

  • 통신 내용을 암호화하여 도청/변조 방지

• HTTPS 동작

  1. TCP 3-way handshake

     1. 클라이언트 → 서버: 연결 요청

     2. 서버 → 클라이언트: 요청 확인 + 응답

     3. 클라이언트 → 서버: 응답 확인

  2. TLS handshake

     1. 서버: SSL/TLS 인증서 전송

     2. 클라이언트: 인증서의 유효성 검증 (발급기관, 도메인, 만료일 등)

     3. 키 교환

  3. HTTP 데이터 송수신 (암호화된 상태로 요청/응답 처리)

✉️ TCP vs UDP

• 둘 다 네트워크 전송 계층 프로토콜이며, 데이터 배송 방식을 의미

• TCP (Transmission Control Protocol) → 등기우편

  • 연결 지향적

  • 3-way handshake 후에 데이터를 전송

  • 패킷 순서 보장과 손실시 재전송으로 신뢰성이 높으나 속도가 느림

  • HTTP/HTTPS, 이메일(SMTP), 파일 전송(FTP)

• UDP (User Datagram Protocol) → 엽서

  • 연결 없이 데이터를 보내 속도가 빠름

  • 순서 보장과 손실시 재전송 없음

  • 실시간 스트리밍, 게임, 통화 같이 속도가 중요한 서비스에 적합