Application Layer on Kelly Dev

Network. 쿠키, 세션

Sun, 02 Feb 2025 00:00:00 +0000

개요

웹 애플리케이션에서 사용자 정보를 저장하고 관리하는 방식, HTTP는 statelessness이기 때문에, 이전 요청에 대한 정보를 기억하지 않는다. 따라서 이 문제를 해결하기 위해 쿠키와 세션이 필요하다.

쿠키

클라이언트에 저장되는 작은 데이터 파일, 서버가 클라이언트에게 데이터를 저장하도록 지시하면, 해당 데이터를 전송하게 됨

용도

사용자 인증 정보 저장 (로그인 상태 유지)
웹사이트 설정 저장
사용자 행동 추적

특징

주기적 전송: 사용자가 특정 사이트에 다시 방문하면 브라우저가 자동으로 쿠키를 서버로 전송함
수명: 유효 기간을 설정할 수 있고, 만료되면 삭제됨, 유효기간이 없으면 브라우저 세션이 종료될 때 삭제
용량: 한 도메인당 쿠키는 4KB 정도로 제한

보안

사용자의 브라우저에 저장되기 때문에 클라이언트에서 조작할 수 있다. 따라서 민감한 데이터는 쿠키에 저장하면 안됨

Network. DHCP(Dynamic Host Configuration Protocol)

Sat, 01 Feb 2025 00:00:00 +0000

개요

DHCP: Dynamic Host Configuration Protocol

디바이스가 네트워크에 접속하려면 고유한 IP주소가 필요하지만, 수동으로 설정하면 불편하고 충돌이 발생할 가능성이 있음, DHCP 서버는 자동으로 IP 주소와 서브넷 마스크, 게이트웨이와 같은 파라미터를 배정한다.

동작 방식

DORA

Discovery
- 클라이언트가 네트워크에 연결되면, IP 주소가 필요하다고 브로드 캐스트 요청을 보냄
Offer
- DHCP 서버가 사용 가능한 IP 주소를 찾아서 클라이언트에게 제안
Request
- 클라이언트가 서버에게 응답함
Acknowledge
- DHCP 서버가 설정을 최종적으로 승인

임대

DHCP는 IP 주소를 영구적으로 할당하지 않고 일정 시간 동안 임대(Lease)하는 방식으로 관리한다.

Network. DNS(Domain Name System)

Sat, 01 Feb 2025 00:00:00 +0000

DNS

DNS: Domain Name System

도메인 이름을 IP 주소로 변환하는 시스템, 웹 사이트 주소를 IP주소로 변환해주는 역할

동작 방식

DNS는 계층 구조를 가지며, 요청을 처리하는 과정에서 필요한 DNS 서버를 순차적으로 탐색한다. 한 번 조회한 결과는 캐시에 저장되어 이후에는 같은 과정을 반복하지 않을 수 있다.

사용자가 google.com을 입력했다고 하면, 맥이 자동으로 로컬 DNS 서버에 요청을 보냄 → 만약 로컬 DNS 서버가 정보를 가지고 있지 않다면, 상위 DNS 서버로 요청을 보냄

1. 맥 → 로컬 캐시 확인
2. 로컬 DNS 서버(ISP DNS 서버) → 로컬 캐시 확인
3. 로컬 DNS 서버 → 재귀 DNS 서버에 요청
4. 재귀 DNS 서버 → 루트 DNS 서버 → TLD DNS 서버 → 권한 있는 네임서버
5. 권한 있는 네임서버 → IP 주소 반환
6. 재귀 DNS 서버 → 로컬 DNS 서버 → IP 주소 전달
7. 로컬 DNS 서버 → 맥에 최종 IP 주소 전달
8. 맥 → 구글 접속

재귀 DNS 서버(Recursive DNS Server)는 클라이언트를 대신하여 필요한 DNS 서버를 차례대로 조회하고 최종 결과를 반환하는 역할을 한다.

Network. REST(Representational State Transfer)

Sat, 01 Feb 2025 00:00:00 +0000

REST

REST: Representational State Transfer
RESTful API: REST를 기반으로 한 API
REST 아키텍처 스타일의 설계 원칙을 준수하는 API

Note.

REST는 HTTP와 동일한 개념이 아니다. REST는 웹 API를 설계하기 위한 아키텍처 스타일이며, HTTP는 REST를 구현할 때 가장 많이 사용하는 프로토콜이다.

설계 원칙

Uniform interface

동일한 리소스에 대한 모든 API 요청은 동일하게 표시되어야 한다(리소스는 단일 URL을 통해 식별할 수 있도록 고유해야 한다). 서버는 표준 형식으로 정보를 전송하고, 형식이 지정된 리소스를 REST에서는 표현(Represent)라고 한다.

Network. URI(Uniform Resource Identifier)

Sun, 12 Jan 2025 00:00:00 +0000

URI (Uniform Resource Identifier)

자원(파일, 웹 페이지, 이메일 주소)등을 식별하는 문자열

URI는 URL과 URN을 포함하는 상위 개념이다.

URL (Uniform Resource Locator)

자원의 위치(Location)와 접근 방법을 나타내는 URI

HTTP, HTTPS, FTP 등의 프로토콜을 포함할 수 있다.
프로토콜, 호스트, 경로, 쿼리 등을 통해 자원에 접근하는 방법을 나타낸다.

URN (Uniform Resource Name)

자원의 이름(Name)으로 식별하는 URI

자원의 위치와 관계없이 고유한 이름으로 식별한다.
대표적으로 ISBN, ISSN 등이 사용된다.

관계

URI
├── URL
└── URN

Network. HTTP(HyperText Transfer Protocol)

Thu, 14 Mar 2024 00:00:00 +0000

HTTP

HTTP: HyperText Transfer Protocol

HTTP는 웹에서 클라이언트와 서버가 데이터를 주고받기 위한 애플리케이션 계층 프로토콜이다.

클라이언트가 요청(Request)을 보내면 서버가 응답(Response)을 반환하는 Request-Response 방식으로 동작한다.

동작 방식

Client
↓ HTTP Request
Server
↓ HTTP Response
Client

특징

Request-Response 방식으로 동작한다.
Stateless를 기본으로 한다.
HTTP/1.x와 HTTP/2는 TCP를 기반으로 동작한다.

버전별 변화

HTTP/1.0

기본적으로 요청마다 연결을 새로 만드는 방식이 널리 사용됐다. 서버에서 여러 파일을 가져올 때 TCP 연결을 반복해서 설정하면 지연이 커질 수 있다. 다만 HTTP/1.0에서도 Connection: keep-alive를 확장 기능으로 사용할 수 있었다.