은학의 코딩 일기장

OSI 계층과 TCP/IP 계층, 실무에서 어떻게 활용될까?

<Eunhak> — Wed, 7 Jan 2026 09:18:36 +0900

네트워크를 공부하다 보면 가장 먼저 접하게 되는 개념이 OSI 7계층과 TCP/IP 계층 모델이다.
개념 자체는 오래전부터 존재하지만, 요즘 들어 다시 중요해지는 이유는 명확하다.
클라우드 환경, 마이크로서비스 아키텍처, 트래픽 증가로 인해 문제 발생 지점을 빠르게 좁히는 능력이 점점 더 중요해졌기 때문이다.

이 글은 다음과 같은 사람에게 도움이 된다.

네트워크 개념을 이론으로만 알고 있는 개발자
장애 대응이나 로그 분석 시 네트워크 계층이 헷갈리는 경우
OSI와 TCP/IP를 “외우는 개념”이 아니라 “써먹는 기준”으로 이해하고 싶은 사람

OSI 7계층 모델 다시 정리

OSI(Open Systems Interconnection) 모델은 네트워크 통신 과정을 7단계로 나눈 개념적 모델이다.
실제 구현 모델이라기보다는 문제 원인 분석과 역할 구분을 위한 기준에 가깝다.

핵심은 “통신을 단계별로 쪼개서 생각하자”는 데 있다.

OSI 7계층 구조

물리 계층 (Physical)
데이터 링크 계층 (Data Link)
네트워크 계층 (Network)
전송 계층 (Transport)
세션 계층 (Session)
표현 계층 (Presentation)
응용 계층 (Application)

[이미지: OSI 7계층 구조 다이어그램]

OSI 계층별 실제 응용 사례

이론 설명만으로는 감이 잘 오지 않기 때문에, 실무에서 자주 겪는 상황 위주로 정리해본다.

1️⃣ 물리 / 데이터 링크 계층

랜선 불량, 포트 연결 오류
동일 네트워크인데 통신이 안 되는 경우

실제로 써보면, 이 단계 문제는 개발자가 직접 해결하기보다는 인프라 쪽 이슈인 경우가 많다.
다만 “핑이 아예 안 간다”면 이 계층부터 의심해볼 수 있다.

2️⃣ 네트워크 계층 (IP, 라우팅)

서로 다른 네트워크 간 통신
서브넷, 라우팅 테이블 문제

예를 들어, 서버 A에서 서버 B로 요청을 보내는데 같은 포트, 같은 서비스인데도 연결이 안 된다면,
IP 대역이나 라우팅 설정을 이 계층에서 확인하게 된다.

3️⃣ 전송 계층 (TCP / UDP)

포트 번호
연결 지향 / 비연결 지향

HTTP API 호출 시 타임아웃이 발생한다면,
“서버가 안 떠 있나?”보다 먼저 포트가 열려 있는지, TCP 연결이 정상인지를 확인하는 게 일반적이다.

4️⃣ 세션 / 표현 / 응용 계층

OSI 상으로는 나뉘어 있지만, 실무에서는 묶어서 생각하는 경우가 많다.

인증 세션 유지
데이터 인코딩(JSON, UTF-8)
HTTP, FTP, SMTP 같은 애플리케이션 프로토콜

로그인은 되는데 특정 API만 실패한다면, 이 계층에서 문제를 찾게 된다.

TCP/IP 계층 모델은 왜 따로 볼까?

TCP/IP 모델은 실제 인터넷에서 사용하는 표준 모델이다.
OSI보다 단순하고, 구현 중심적이다.

TCP/IP 4계층 구조

네트워크 인터페이스 계층
인터넷 계층
전송 계층
응용 계층

[이미지: TCP/IP 4계층 구조 다이어그램]

OSI와 TCP/IP를 비교하면 다음처럼 대응된다.

OSI 계층TCP/IP 계층

1~2계층	네트워크 인터페이스
3계층	인터넷
4계층	전송
5~7계층	응용

TCP/IP 기준으로 보는 실무 응용

실무에서는 보통 TCP/IP 기준으로 사고한다.

HTTP API 장애 예시

응용 계층
- URL, 헤더, 인증 토큰 확인
전송 계층
- 포트, TCP 연결 여부
인터넷 계층
- IP 접근 가능 여부
네트워크 인터페이스
- 서버 NIC, 방화벽

실제로 장애 대응 시에는
“이게 OSI 몇 계층 문제인가?”보다는
TCP/IP 기준으로 위에서 아래로 내려가며 확인하는 경우가 많다.

OSI vs TCP/IP, 어떻게 활용하면 좋을까?

개념 정리는 OSI, 실제 문제 해결은 TCP/IP

OSI 계층
- 면접 대비
- 개념 설명
- 원인 분류 기준
TCP/IP 계층
- 로그 분석
- 장애 대응
- 실제 네트워크 설계

⚠️ OSI 계층을 그대로 코드나 설정에 적용하려고 하면 오히려 헷갈릴 수 있다.
개념용과 실무용을 구분해서 쓰는 게 좋다.

정리하며

OSI와 TCP/IP 계층 모델은
외워야 할 이론이라기보다 문제를 나누어 생각하기 위한 프레임에 가깝다.

네트워크 흐름을 이해하고 싶다면 OSI
실제 장애를 처리해야 한다면 TCP/IP

이런 기준으로 접근하면,
네트워크 관련 이슈를 만났을 때 훨씬 덜 막막해진다.

[운영체제] 프로세스(Process)

<Eunhak> — Mon, 29 Dec 2025 09:05:37 +0900

프로세스(Process)는 실행 중인 프로그램을 의미하며,
운영체제가 CPU, 메모리, 파일과 같은 시스템 자원을 할당하고 관리하는 기본 단위입니다.
단순히 디스크에 저장된 프로그램 파일이 아니라,
메모리에 적재되어 실제로 실행되고 있는 상태를 프로세스라고 부릅니다.

운영체제는 다수의 프로세스를 동시에 관리하며,
각 프로세스가 서로 간섭하지 않고 효율적으로 실행되도록 제어합니다.

프로세스의 주요 개념

1. 프로그램 vs 프로세스

프로그램(Program)
디스크에 저장된 실행 파일 (정적인 상태)
프로세스(Process)
프로그램이 메모리에 올라가 실행 중인 상태 (동적인 상태)

같은 프로그램이라도 여러 번 실행하면
서로 다른 프로세스가 생성됩니다.

2. 프로세스의 구성 요소

프로세스는 다음과 같은 정보들을 포함합니다.

코드(Code)
실행할 프로그램 명령어
데이터(Data)
전역 변수, 정적 변수
힙(Heap)
동적 메모리 영역
스택(Stack)
함수 호출, 지역 변수, 매개변수 저장
PCB(Process Control Block)
프로세스 상태, PID, 레지스터 정보, 메모리 정보 등 관리용 데이터

PCB는 운영체제가 프로세스를 관리하기 위해 사용하는 핵심 자료구조입니다.

3. 프로세스 상태(Process State)

프로세스는 실행 과정에서 여러 상태를 오갑니다.

New
프로세스가 생성된 상태
Ready
실행 준비 완료, CPU 할당 대기 상태
Running
CPU를 할당받아 실행 중
Waiting (Blocked)
I/O 작업 등으로 인해 대기 중
Terminated
실행 종료 상태

운영체제는 이 상태 전이를 통해
CPU 자원을 효율적으로 분배합니다.

4. 프로세스 생성

프로세스는 다음과 같은 상황에서 생성됩니다.

시스템 부팅 시
사용자가 프로그램 실행 시
부모 프로세스가 자식 프로세스를 생성할 때

대표적인 예:

UNIX 계열: fork(), exec()
Windows: CreateProcess()

부모 프로세스와 자식 프로세스는
독립적인 메모리 공간을 가지는 것이 특징입니다.

5. 프로세스 간 통신 (IPC)

프로세스는 기본적으로 서로 메모리를 공유하지 않기 때문에
IPC(Inter-Process Communication) 기법을 통해 통신합니다.

파이프(Pipe)
메시지 큐(Message Queue)
공유 메모리(Shared Memory)
소켓(Socket)
시그널(Signal)

IPC는 협력 프로세스 환경에서 필수적인 개념입니다.

프로세스의 장점

안정성
프로세스 간 메모리 보호로 인해 하나의 프로세스 오류가 전체 시스템에 영향을 주지 않음
독립성
각 프로세스는 고유한 주소 공간을 가짐
보안성
접근 권한이 명확히 분리됨

프로세스의 단점

생성 비용 큼
메모리 할당 및 PCB 생성 비용 발생
컨텍스트 스위칭 비용
CPU 레지스터 및 상태 저장/복원에 따른 오버헤드
통신 복잡성
IPC 구현이 상대적으로 까다로움

이러한 단점을 보완하기 위해 스레드(Thread) 개념이 등장했습니다.

마무리

프로세스는 운영체제의 가장 기본적인 실행 단위로,
CPU 스케줄링, 메모리 관리, 동기화 등
다양한 운영체제 개념의 출발점이 됩니다.

운영체제를 이해하려면
프로세스 → 스레드 → 스케줄링 → 동기화 흐름으로 학습하는 것이 매우 효과적입니다.

[컴퓨터 네트워크] 라우팅

<Eunhak> — Thu, 12 Sep 2024 19:26:17 +0900

라우팅이란?

라우팅은 네트워크 간에 데이터 패킷을 전달하는 과정을 말합니다. 네트워크에 연결된 여러 장치(노드)들이 서로 통신하기 위해 데이터 패킷을 전달할 경로를 선택하는 것을 라우팅이라고 합니다. 이 작업은 주로 라우터라는 네트워크 장치에 의해 수행되며, 라우터는 패킷을 최적의 경로로 전달하여 목적지까지 도달하게 합니다.

라우팅의 핵심은 경로 선택으로, 목적지에 도달할 수 있는 여러 경로 중 가장 효율적인 경로를 결정하는 것입니다. 이를 위해 라우팅 테이블을 사용하며, 각 네트워크 장치는 자신이 알고 있는 네트워크 경로 정보를 기반으로 라우팅 테이블을 구성합니다.

라우팅 프로토콜

라우팅 프로토콜은 네트워크 장치들이 서로 통신하며, 경로 정보를 공유하고 업데이트하는 규칙 및 절차를 말합니다. 이를 통해 네트워크 장치들이 데이터를 어디로 보낼지 결정할 수 있게 됩니다. 라우팅 프로토콜은 크게 두 가지로 나뉩니다.

내부 라우팅 프로토콜 (IGP, Interior Gateway Protocol):
- 같은 자치 시스템(AS, Autonomous System) 내에서 작동하며, 네트워크 간의 경로를 설정하는 데 사용됩니다.
- 예:
  - RIP (Routing Information Protocol): 단순한 거리 벡터 기반의 프로토콜로, 경로의 홉 수를 기준으로 라우팅 테이블을 구성합니다.
  - OSPF (Open Shortest Path First): 링크 상태 기반의 프로토콜로, 네트워크 내 모든 라우터가 경로 정보를 공유하며 최적의 경로를 설정합니다.
  - EIGRP (Enhanced Interior Gateway Routing Protocol): 거리 벡터와 링크 상태를 모두 사용하는 혼합형 프로토콜입니다.
외부 라우팅 프로토콜 (EGP, Exterior Gateway Protocol):
- 다른 자치 시스템 간에 경로 정보를 설정하는 데 사용됩니다.
- 예:
  - BGP (Border Gateway Protocol): 자치 시스템 간의 네트워크 경로를 설정하며, 인터넷 상에서 가장 널리 사용되는 프로토콜입니다. BGP는 네트워크 정책에 따라 경로를 선택하는 기능을 제공합니다.

서브넷과 서브넷 마스크

서브넷(Subnet)은 하나의 큰 네트워크를 더 작은 네트워크로 나누는 방법입니다. 서브넷을 사용하면 네트워크 자원을 효율적으로 관리하고, 네트워크 트래픽을 줄이며, 보안을 강화할 수 있습니다. 예를 들어, 대규모 기업 네트워크를 여러 서브넷으로 나누면, 각 부서나 팀마다 별도의 네트워크 세그먼트를 제공할 수 있습니다.

서브넷 마스크(Subnet Mask):
- 서브넷을 정의하는 데 사용되는 32비트 숫자입니다. IP 주소를 네트워크 부분과 호스트 부분으로 나누는 역할을 합니다.
- 예: IP 주소 192.168.1.0에 서브넷 마스크 255.255.255.0을 적용하면, 앞의 192.168.1은 네트워크 주소를 나타내고, 마지막 0은 호스트 주소를 나타냅니다.
- 서브넷 마스크는 네트워크 범위를 결정하며, 이를 통해 네트워크 장치들이 특정 IP 주소가 어느 서브넷에 속하는지 알 수 있습니다.

서브넷팅의 장점:

네트워크 트래픽을 줄여 성능을 개선.
IP 주소를 더 효율적으로 사용.
보안을 강화하여 서브넷 간 접근을 제한.

[컴퓨터 네트워크] IP 프로토콜

<Eunhak> — Thu, 12 Sep 2024 19:26:04 +0900

IP주소란

IP 주소는 네트워크에 연결된 장치들이 서로 통신하기 위해 사용하는 고유한 숫자 식별자입니다. IP 주소는 인터넷과 같은 네트워크에서 데이터를 전송하고 수신하는 데 필수적입니다. IP 주소는 크게 두 가지 종류로 나뉩니다: IPv4와 IPv6.

IPv4 (Internet Protocol version 4):
- 32비트 주소 체계를 사용하며, 숫자 4개가 점으로 구분된 형태로 나타납니다. 예: 192.168.0.1
- IPv4는 약 43억 개의 고유한 주소를 제공하지만, 네트워크 장치 수가 급격히 증가하면서 주소가 부족해졌습니다.
IPv6 (Internet Protocol version 6):
- 128비트 주소 체계를 사용하며, 훨씬 더 많은 수의 주소를 제공합니다. IPv6 주소는 16진수로 작성된 8개의 그룹으로 나뉩니다. 예: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
- IPv6는 주소 부족 문제를 해결하고 더 나은 네트워크 효율성과 보안을 제공합니다.

Public IP (공인 IP):
- 인터넷상에서 고유한 IP 주소로, 전 세계에서 유일하게 식별됩니다. 공인 IP는 ISP(인터넷 서비스 제공자)에 의해 할당되며, 이를 통해 장치가 인터넷 상에서 다른 네트워크나 장치와 직접 통신할 수 있습니다.
- 예: 웹사이트 서버나, 인터넷에 연결된 가정용 라우터가 공인 IP 주소를 사용합니다.
Private IP (사설 IP):
- 로컬 네트워크에서만 유효한 IP 주소로, 인터넷에서는 사용되지 않습니다. 사설 IP는 주로 가정, 회사, 또는 사설 네트워크 내에서 장치들이 서로 통신하기 위해 할당됩니다. 동일한 사설 IP 범위가 전 세계적으로 여러 네트워크에서 재사용될 수 있습니다.
- 예: 집 안의 PC, 스마트폰, 프린터 같은 장치들이 라우터로부터 사설 IP를 받아 로컬 네트워크에서 통신합니다.

공인 IP와 사설 IP의 범위

사설 IP 주소 범위 (RFC 1918에 정의됨):
- 10.0.0.0 ~ 10.255.255.255
- 172.16.0.0 ~ 172.31.255.255
- 192.168.0.0 ~ 192.168.255.255
이 범위를 제외한 모든 IP 주소는 공인 IP입니다.

IP 주소는 어떻게 할당될까

공인 IP 할당:
- 공인 IP 주소는 **ISP(인터넷 서비스 제공자)**가 인터넷에 연결된 장치나 네트워크에 할당합니다. ISP는 IANA(Internet Assigned Numbers Authority) 및 RIR(Regional Internet Registry)로부터 IP 주소 블록을 받아 사용자가 인터넷에 연결할 수 있도록 제공합니다.
- 예: 가정이나 회사가 인터넷에 연결되면 ISP로부터 공인 IP가 할당되어 외부와 통신합니다.
사설 IP 할당:
- 사설 IP 주소는 로컬 네트워크 내의 라우터나 DHCP 서버가 자동으로 할당합니다. 이를 통해 로컬 네트워크 안에서 여러 장치가 서로 통신할 수 있습니다.
- 예: 가정 내 라우터가 사설 IP 주소를 네트워크에 연결된 각 장치에 자동으로 배포합니다(DHCP 프로토콜 사용).

NAT (Network Address Translation)

NAT는 네트워크 주소 변환을 의미하며, 하나의 공인 IP 주소를 사용하여 내부 네트워크의 여러 장치가 외부 인터넷과 통신할 수 있도록 해주는 기술입니다. 사설 IP 주소를 사용하는 장치들이 외부 네트워크와 직접 통신할 수 없기 때문에, NAT는 공인 IP 주소를 사용해 외부로 나가는 트래픽의 출발지를 변환하여 처리합니다.

NAT의 주요 기능:

IP 주소 절약: 공인 IP 주소의 부족 문제를 해결하기 위해 사설 네트워크 내에서 여러 장치가 하나의 공인 IP 주소를 통해 인터넷에 접속할 수 있도록 합니다.
보안 강화: 사설 네트워크의 IP 주소를 외부에 노출하지 않음으로써 보안성을 높이는 데 기여합니다.
NAT 유형:
- Static NAT: 하나의 공인 IP와 하나의 사설 IP를 매핑합니다.
- Dynamic NAT: 여러 사설 IP를 공인 IP 풀에서 할당받아 동적으로 변환합니다.
- PAT (Port Address Translation): 여러 사설 IP가 하나의 공인 IP 주소를 공유하며, 각 통신에 다른 포트를 사용하여 구분합니다.

ICMP (Internet Control Message Protocol)

ICMP는 네트워크 장치 간에 오류 메시지와 제어 메시지를 주고받기 위한 제어 프로토콜입니다. 데이터 패킷이 목적지에 도달하지 못하거나 네트워크 문제를 감지할 때 ICMP를 사용해 문제를 보고하거나 진단할 수 있습니다. 이는 실제로 데이터를 전송하는 역할은 하지 않으며, 네트워크의 상태를 모니터링하고 문제를 해결하는 데 중요한 역할을 합니다.

ICMP의 주요 기능:

에러 보고: 패킷이 목적지에 도달하지 못하거나 네트워크 문제 발생 시 해당 오류를 보고합니다.
진단 도구: ping 및 traceroute와 같은 네트워크 진단 도구가 ICMP를 사용해 네트워크 연결 상태를 확인합니다.
네트워크 상태 모니터링: ICMP를 통해 네트워크의 혼잡도나 장애 상태를 진단할 수 있습니다.

ICMP는 IP 프로토콜의 일부분이며, 데이터 전송 경로에서 발생하는 문제를 네트워크 관리자에게 알리는 중요한 역할을 합니다.

[javascript] Promise

<Eunhak> — Tue, 3 Sep 2024 13:41:09 +0900

Promise란?

자바스크립트 비동기 통신에 사용되는 객체중 하나로 비동기 작업의 완료 또는 실패를 나타냄

기존 callback 방식의 call back 지옥을 해결하기 위해 Promise가 사용됨

Promise의 이점

비동기 처리 시점을 명확하게 표현할 수 있다.
연속된 비동기 처리 작업을 수정, 삭제, 추가하기 편하고 유연하다.
비동기 작업 상태를 쉽게 확인할 수 있다.
코드의 유지 보수성이 증가한다.

Promise 3가지 상태

Pending(대기) : 비동기 로직이 아직 완료되지 않은 상태

Fullfilled(이행) : 비동기 작업이 처리되어 프로미스가 결과값을 반환해준 상태

rejected(실패) : 비동기 작업이 실패된 상태

후속 처리 메소드

then

then 메소드는 두 개의 콜백 함수를 인자로 전달 받습니다.
첫 번째 콜백 함수는 성공(fulfilled, resolve 함수가 호출된 경우)시에 실행됩니다.
두 번째 콜백 함수는 실패(rejected, reject 함수가 호출된 경우)시에 실행됩니다.
then 메소드는 기본적으로 프로미스를 반환합니다.

const promise = () => new Promise((resolve, reject) => {
    let a = 1 + 1

    if(a == 3) {
        resolve('success')
    } else {
        reject('failed')
    }
})

promise().then((message) => {
    console.log('This is in the then ' +  message)
}, (error) => {
    console.log('This is in the then ' +  error)
})

catch

catch 메소드는 비동기 처리 혹은 then 메소드 실행 중 발생한 에러(예외)가 발생하면 호출됩니다.
catch 메소드 역시 프로미스를 반환합니다.

const promise = () => new Promise((resolve, reject) => {
    let a = 1 + 1

    if(a == 3) {
        resolve('success')
    } else {
        reject('failed')
    }
})

promise().then((message) => {
    console.log('This is in the then ' +  message)
}).catch((error) => {
    console.log('This is in the catch ' + error)
})

프로미스 체이닝

프로미스의 특징 중 하나는 프로미스를 여러개를 연결하여 사용할 수 있다는 것

then 메소드를 호출하여 아래와같이 연결할 수 있음

function getData() {
  return new Promise({
// ...});
}

// then() 으로 여러 개의 프로미스를 연결한 형식getData()
getData()
  .then(function(data) {
    // ...
  })
  .then(function() {
    // ...
  })
  .then(function() {
    // ...
  });

Promise.all()

promise.all은 promise가 담겨있는 배열과 같은 이터러블 객체를 인자로 받음

인자로 전달받은 모든 promise를 병렬로 처리하고 그 결과값을 배열에 받아 resolve로 반환함

서로 의존관계이지 않은 여러 프로미스들을 이터러블 객체에 담아 Promise.all 메소드를 이용해 한번에 병렬처리 할 수 있음

가장 마지막으로 끝나는 프로미스를 기준으로 수행되고, 모든 프로미스가 fullfilled 상태가 되면 결과값을 배열에 담아 새로운 프로미스를 반환

Promise.all([
    new Promise(resolve => setTimeout(() => resolve(1), 1000)),
    new Promise(resolve => setTimeout(() => resolve(2), 2000)),
    new Promise(resolve => setTimeout(() => resolve(3), 3000))
]).then(console.log) // 프로그램을 실행하고 3초뒤에 실행됨
.catch(console.log)

[ 1, 2, 3 ]

[컴퓨터 네트워크] TCP / UDP

<Eunhak> — Mon, 2 Sep 2024 16:34:43 +0900

TCP (Transmission Control Protocol)

TCP는 연결 지향적 프로토콜로, 인터넷 프로토콜 스위트의 중요한 요소 중 하나입니다. TCP는 데이터의 신뢰성과 순서를 보장하며, 데이터가 전송된 순서대로 도착하고 손실되거나 손상된 경우 이를 복구하는 기능을 제공합니다.

특징:

연결 지향적: 데이터를 전송하기 전에 송신자와 수신자 사이에 연결을 설정합니다.
신뢰성: 데이터가 정확하게 도착하는지 확인하고, 손실되거나 손상된 패킷은 재전송됩니다.
흐름 제어: 수신자의 처리 능력을 고려해 데이터 전송 속도를 조절합니다.
혼잡 제어: 네트워크 혼잡을 방지하기 위해 전송 속도를 조절합니다.
패킷 순서 보장: 송신된 데이터 패킷의 순서가 유지되도록 합니다.

장점:

데이터의 신뢰성과 정확성을 보장합니다.
패킷의 순서를 보장하며, 흐름 제어와 혼잡 제어 기능을 제공합니다.

단점:

연결 설정과 유지, 데이터 확인 등의 과정으로 인해 속도가 느릴 수 있습니다.
상대적으로 높은 오버헤드가 발생합니다.

UDP (User Datagram Protocol)

UDP는 비연결형 프로토콜로, TCP와 달리 데이터 전송의 신뢰성을 보장하지 않습니다. UDP는 패킷이 순서에 상관없이 독립적으로 전송되며, 손실된 패킷에 대한 재전송은 이루어지지 않습니다.

특징:

비연결형: 데이터를 전송하기 전에 연결을 설정하지 않습니다.
신뢰성 없음: 패킷 손실이나 순서가 뒤바뀌는 상황을 처리하지 않으며, 데이터의 도착 여부를 확인하지 않습니다.
낮은 지연: 추가적인 오버헤드가 없기 때문에 TCP보다 전송 속도가 빠릅니다.
오버헤드가 적음: 단순한 프로토콜 구조로 인해 네트워크 자원을 적게 사용합니다.

장점:

TCP보다 빠른 데이터 전송이 가능합니다.
오버헤드가 적어 실시간 애플리케이션에 적합합니다.

단점:

데이터 전송의 신뢰성을 보장하지 않으며, 패킷이 손실될 수 있습니다.
패킷 순서를 보장하지 않으며, 데이터가 손상될 수 있습니다.

3-Way Handshake

3-Way Handshake는 TCP 연결을 설정할 때 사용하는 절차입니다. 송신자와 수신자가 서로 데이터를 주고받을 준비가 되었음을 확인하기 위해 3단계의 신호를 주고받습니다.

SYN: 클라이언트가 서버에 연결 요청을 보냅니다. 이 때 클라이언트는 SYN 플래그가 설정된 패킷을 서버로 전송합니다.
SYN-ACK: 서버는 클라이언트의 SYN 패킷을 수신하고, 이를 수락한다는 의미로 SYN-ACK 패킷을 클라이언트로 전송합니다. 이 패킷에는 서버 측의 SYN 요청도 포함됩니다.
ACK: 클라이언트는 서버로부터의 SYN-ACK 패킷을 수신한 후, 이를 확인하는 ACK 패킷을 서버로 전송합니다. 이로써 연결이 설정됩니다.

이 과정이 완료되면, 클라이언트와 서버 간의 연결이 설정되며, 데이터를 주고받을 준비가 완료된 상태가 됩니다.

4-Way Handshake

4-Way Handshake는 TCP 연결을 종료할 때 사용하는 절차입니다. TCP 연결 종료는 4단계의 신호 주고받기를 통해 이루어집니다.

FIN: 클라이언트가 연결을 종료하기 위해 FIN 플래그가 설정된 패킷을 서버로 전송합니다. 이는 클라이언트가 더 이상 데이터를 전송하지 않겠다는 신호입니다.
ACK: 서버는 클라이언트의 FIN 패킷을 수신하고, 이를 확인하는 ACK 패킷을 클라이언트로 전송합니다. 이 시점에서 서버는 아직 데이터를 클라이언트로 전송할 수 있습니다.
FIN: 서버가 더 이상 데이터를 전송하지 않기로 결정하면, FIN 플래그가 설정된 패킷을 클라이언트로 전송합니다.
ACK: 클라이언트는 서버로부터 FIN 패킷을 수신하고, 이를 확인하는 ACK 패킷을 서버로 전송합니다. 이로써 연결이 완전히 종료됩니다.

4-Way Handshake는 양방향에서 데이터를 전송하는 TCP 연결을 종료하기 위해 필요한 절차로, 연결의 종료를 양측이 명확하게 인식하도록 합니다.

[javascript] 이벤트루프

<Eunhak> — Mon, 2 Sep 2024 14:51:44 +0900

자바스크립트 ⇒ 싱글스레드언어 ( 한번에 하나의 작업만 처리)

때문에 비동기 방식은 자바스크립트가 아닌 브라우저의 web apis에서 비동기 + 논블로킹 방식으로 처리됨

이벤트루프란?

브라우저의 동작을 제어하는 관리자역할

싱글 스레드인 자바스크립트의 작업을 멀티 스레드로 돌려 작업을 동시에 처리시키게 하던가, 또는 여러 작업 중 어떤 작업을 우선으로 동작시킬 것인지 결정하는 세심한 컨트롤을 하기 위해 존재하는 것이 바로 이벤트 루프

이벤트 루프를 이용한 프로그램 방식을 이벤트 기반(Event Driven) 프로그래밍이라고함

자바스크립트의 내부 구성도

call stack : 자바스크립트 엔진이 코드실행을 위해 사용하는 메모리구조
callback queue : 비동기 작업이 완료되면 실행되기위해 대기하는 공
event loop : 비동기를 적절한 시점에 처리시키는 작업자
web apis : 비동기 작업을 처리

[javascript] 클로저 / 스코프

<Eunhak> — Mon, 2 Sep 2024 14:50:34 +0900

스코프

참조 대상 식별자를 찾아내기 위한 규칙

변수 / 함수의 유효범위를 뜻함

전역 스코프 (Global scope) : 스크립트 전체에서 참조되는 것을 의미하며, 어느 곳에서든 참조 된다.

지역 스코프 (Local scope) : 정의된 함수 내에서만 참조되는 것을 의미하며, 밖에서는 참조 되지 않는다.

렉시컬 스코프

함수를 어디 선언하는지에 따라 상위 스코프가 결정되는 자바스크립트를 포함한 대부분의 프로그래밍 언어는 렉시컬 스코프를 따름

var x = 1;

function foo() {
	var x = 10;
	bar();
}

function bar() {
	console.log(x);
}

foo(); // 1
bar(); // 1

위와 같은 상황에서 bar 함수에서 참조하는 x 변수는 bar 함수의 상위 스코프가 무엇인지에 따라 결정된다. 따라서, 상위 스코프가 무엇인지 알려면 bar 함수가 어디에 선언되었는지 봐야되는데, 위 코드에서는 bar 함수가 전역에 선언되었으므로 상위 스코프는 전역 스코프가 된다. 그래서 bar 함수 내의 x 변수는 전역에 선언된 x 변수를 참조하게 된다.

클로저

반환된 내부함수가 자신의 렉시컬스코프를 기억하여 자신의 스코프 밖에서 호출되어도 그 환경에 접근할 수 있는 것

const outerFunc = () => {
		let x = 10; // '자유 변수' 라고 한다.

		// 클로저
		const innerFunc = (y) => {
				x = x + y;
				console.log(x);
		}

		return innerFunc;
}

const addFunc = outerFunc();
addFunc(5); // 15
addFunc(10); // 25

위 코드에서 innerFunc의 x는 렉시컬 스코프에 의해 outerFunc의 지역변수 x를 참조하고 있다.

그리고 outerFunc는 const addFunc = outerFunc(); 구문에서 호출된 후 콜스택에서 제거된다.

따라서, 이후에 addFunc를 호출 할 때 innerFunc의 x를 참조할 수 없어 보이는데, 외부함수 실행 컨텍스트 내의 *활성 객체가 내부함수에 의해 참조되는 한 유효하기 때문에 그렇지 않다.

즉, 내부함수가 유효한 상태에서 외부함수가 종료되어도, 외부함수의 x 변수를 참조할 수 있다. 여기서 내부함수를 클로저라고 한다.

클로저가 필요한 이유

1. 전역변수를 줄일 수 있다.

전역변수는 예상치 못한 Side Effect를 일으킬 수 있기에 최대한 줄이는 것이 좋다.문에 최대한 전역변수를 줄여서 코딩해야한다.

하지만 프로그램 구현 시 함수 하나에 사용하는 전역변수가 필요한 순간이 있다. 이럴 때 클로저가 유용하게 사용된다.

2. 비슷한 형태의 코드를 재사용률을 높일 수 있다.

인자에 open,close,content를 한번에 다 받는다면,This is my content! 와 같은 값을 출력을 하고 싶을 때 가독성이 떨어질 수 있다.

하지만 클로져로 구현하면 코드의 가독성도 좋은 재사용하기 편한 코드를 구현할 수 있음.

[컴퓨터 네트워크] L4/ L7 로드밸런서

<Eunhak> — Wed, 28 Aug 2024 17:07:49 +0900

L4 로드밸런서

L4 로드 밸런서는 OSI 4계층(전송 계층)에서 동작하는 로드 밸런서입니다. 이 계층에서의 로드 밸런서는 주로 TCP(Transmission Control Protocol) 또는 UDP(User Datagram Protocol) 연결 정보를 기반으로 트래픽을 분산시키는 역할을 합니다.

L4 로드 밸런서의 특징

전송 계층에서의 트래픽 분산:
- L4 로드 밸런서는 IP 주소와 포트 번호를 기반으로 클라이언트의 요청을 분산시킵니다. TCP/UDP 연결을 기준으로 트래픽을 분배하며, 패킷 수준에서 작동합니다.
- 트래픽 분산은 클라이언트의 IP 주소, 포트 번호, 목적지 IP 주소, 목적지 포트 번호 등을 기준으로 이루어집니다.
프로토콜 무관:
- L4 로드 밸런서는 HTTP, HTTPS, FTP, SMTP 등 다양한 프로토콜에 대해 트래픽을 분산할 수 있습니다. 애플리케이션 계층의 데이터(HTTP 헤더, URL 등)는 고려하지 않고, 전송 계층에서의 정보만을 사용하기 때문에 더 범용적으로 사용할 수 있습니다.
빠른 처리 속도:
- L4 로드 밸런서는 전송 계층에서만 트래픽을 처리하므로, L7 로드 밸런서에 비해 더 빠르고 효율적으로 트래픽을 처리할 수 있습니다. 애플리케이션 계층의 데이터를 검사하지 않기 때문에, 처리 속도가 더 빠르며, 리소스 사용량이 적습니다.
간단한 로드 밸런싱 전략:
- L4 로드 밸런서는 일반적으로 라운드 로빈(Round Robin), 최소 연결(Minimum Connections), 해시(Hashing) 등의 단순한 로드 밸런싱 알고리즘을 사용하여 트래픽을 분산합니다.
- 이로 인해 설정과 관리가 상대적으로 단순하며, 고성능 트래픽 처리에 적합합니다.
상태 비저장(Stateless):
- L4 로드 밸런서는 상태를 저장하지 않습니다. 즉, 각 요청은 독립적으로 처리되며, 이전 요청의 상태나 세션 정보는 유지되지 않습니다. 이로 인해 대규모 트래픽 처리에 유리합니다.

L4 로드 밸런서의 장점

성능 최적화: 애플리케이션 계층의 데이터를 분석할 필요가 없기 때문에, L4 로드 밸런서는 매우 빠르고 효율적입니다. 대량의 트래픽을 처리할 수 있습니다.
범용성: HTTP뿐만 아니라 다양한 프로토콜(TCP, UDP 등)에 대해 트래픽을 분산할 수 있습니다.
단순성: 설정과 관리가 비교적 간단하며, 리소스 사용량이 적습니다.

L4 로드 밸런서의 단점

세밀한 트래픽 분산 불가: L4 로드 밸런서는 전송 계층에서만 작동하기 때문에, 애플리케이션 계층의 데이터를 기반으로 세밀한 트래픽 분산이나 콘텐츠 기반 라우팅을 수행할 수 없습니다.
보안 기능 제한: SSL 종료, 웹 애플리케이션 방화벽(WAF) 등과 같은 고급 보안 기능을 지원하지 않습니다. 이러한 기능은 L7 로드 밸런서에서 제공됩니다.
세션 유지 기능 부족: 세션을 유지하거나 상태를 저장하지 않기 때문에, 특정 클라이언트의 요청이 항상 동일한 서버로 전달되도록 보장하기 어렵습니다.

L4 로드 밸런서 사용 사례

고성능 네트워크 트래픽 처리: 대규모 트래픽을 빠르고 효율적으로 처리해야 하는 경우, L4 로드 밸런서가 적합합니다.
다양한 프로토콜 지원: HTTP/HTTPS뿐만 아니라, FTP, SMTP, VoIP 등 다양한 프로토콜을 사용하는 애플리케이션에서 L4 로드 밸런서를 활용할 수 있습니다.
단순한 트래픽 분산: 간단한 로드 밸런싱 알고리즘으로 트래픽을 균등하게 분산해야 하는 경우 적합합니다.

L7 로드밸런서

L7 로드 밸런서는 OSI 7계층(애플리케이션 계층)에서 동작하는 로드 밸런서입니다. 이는 주로 HTTP, HTTPS, WebSocket, FTP와 같은 애플리케이션 프로토콜을 기반으로 클라이언트의 요청을 분산시키고, 트래픽을 최적화하며, 서버의 부하를 균형 있게 분배하는 역할을 합니다.

L7 로드 밸런서의 특징

애플리케이션 레벨 트래픽 분산:
- L7 로드 밸런서는 요청의 내용을 분석하고, URL, 쿠키, 헤더, HTTP 메서드 등과 같은 애플리케이션 계층의 데이터를 기반으로 트래픽을 분산시킬 수 있습니다. 이를 통해 더 세밀한 로드 밸런싱이 가능합니다.
- 예를 들어, 특정 경로(/images, /api)의 요청을 특정 서버에만 보내도록 설정할 수 있습니다.
콘텐츠 기반 라우팅:
- 요청된 콘텐츠의 종류에 따라 다른 서버로 트래픽을 분산시킬 수 있습니다. 예를 들어, 이미지 요청은 이미지 서버로, API 요청은 API 서버로 라우팅하는 방식입니다.
- 이를 통해 서버가 특정 유형의 요청을 처리하는 데 최적화될 수 있으며, 전체 시스템의 성능을 높일 수 있습니다.
SSL 종료(SSL Termination):
- L7 로드 밸런서는 클라이언트와 서버 간의 SSL/TLS 암호화를 처리할 수 있습니다. 클라이언트와의 연결에서 SSL을 해제(종료)하고, 백엔드 서버로는 평문으로 트래픽을 전달하는 방식입니다.
- 이를 통해 백엔드 서버는 SSL 처리 부담이 줄어들어 성능이 향상될 수 있습니다.
상태 유지(Session Persistence):
- L7 로드 밸런서는 특정 클라이언트의 요청이 항상 동일한 서버로 전달되도록 할 수 있습니다. 이를 세션 유지 또는 스티키 세션(Sticky Session)이라고 합니다.
- 예를 들어, 사용자가 로그인한 상태를 유지해야 하는 경우, 동일한 사용자의 요청이 항상 같은 서버로 전달되도록 하여 세션 정보를 유지할 수 있습니다.
고급 트래픽 관리:
- L7 로드 밸런서는 트래픽을 관리하기 위해 고급 규칙을 설정할 수 있습니다. 예를 들어, 특정 사용자 에이전트(User-Agent)를 기반으로 요청을 필터링하거나, 특정 시간대에만 요청을 허용하는 등의 규칙을 적용할 수 있습니다.
- 또한, QoS(Quality of Service) 정책을 설정하여 중요한 트래픽이 우선적으로 처리되도록 할 수 있습니다.
캐싱 및 압축:
- L7 로드 밸런서는 트래픽을 최적화하기 위해 정적 콘텐츠를 캐싱하거나, 데이터를 압축하여 클라이언트로 전송하는 기능을 제공할 수 있습니다. 이를 통해 네트워크 트래픽을 줄이고 응답 속도를 향상시킬 수 있습니다.

L7 로드 밸런서의 장점

정교한 트래픽 분산: HTTP/HTTPS 요청의 내용에 따라 트래픽을 세밀하게 분산할 수 있어, 트래픽 관리의 유연성이 높습니다.
보안 강화: SSL 종료, 웹 애플리케이션 방화벽(WAF) 등의 기능을 통해 보안이 강화될 수 있습니다.
확장성: 다양한 조건에 따라 트래픽을 분산시키므로, 애플리케이션의 확장성과 유연성이 증가합니다.
사용자 경험 개선: 세션 유지를 통해 사용자 경험을 향상시킬 수 있습니다.

L7 로드 밸런서의 단점

복잡성: L7 로드 밸런서는 더 많은 데이터를 분석하고 처리해야 하므로, L4 로드 밸런서보다 설정과 관리가 더 복잡할 수 있습니다.
성능 부담: 애플리케이션 계층의 데이터를 처리하기 때문에, L4 로드 밸런서에 비해 더 많은 리소스를 소비할 수 있습니다. 대규모 트래픽을 처리할 때 성능이 저하될 수 있습니다.

[컴퓨터 네트워크] 웹캐시

<Eunhak> — Wed, 28 Aug 2024 17:04:42 +0900

웹 페이지나 웹 애플리케이션에서 자주 요청되는 자원(이미지, HTML 문서, CSS 파일, JavaScript 파일 등)을 임시로 저장하여, 이후 동일한 자원에 대한 요청이 있을 때 원본 서버로부터 다시 다운로드하지 않고 저장된 복사본을 제공하는 기술입니다. 웹 캐시는 웹 성능을 최적화하고, 서버 부하를 줄이며, 네트워크 트래픽을 절감하는 데 중요한 역할을 합니다.

웹 캐시의 주요 개념

캐싱 위치:
- 브라우저 캐시(Browser Cache): 사용자의 웹 브라우저에 저장되는 캐시입니다. 브라우저는 자주 방문하는 웹 페이지의 자원을 로컬에 저장하여, 동일한 페이지를 다시 방문할 때 로딩 속도를 높입니다.
- 프록시 캐시(Proxy Cache): 네트워크 경로 중간에 위치한 캐시 서버에서 자원을 저장하고 제공하는 방식입니다. 회사나 ISP에서 많이 사용하며, 여러 사용자가 동일한 자원에 접근할 때 원본 서버 대신 프록시 서버에서 데이터를 제공하여 성능을 개선합니다.
- 서버 캐시(Server Cache): 원본 서버에서 자체적으로 캐시를 운영하는 방식입니다. 데이터베이스 쿼리 결과나 렌더링된 페이지를 캐시하여, 동일한 요청에 대해 빠르게 응답할 수 있도록 합니다.
캐시 제어(Cache Control):
- Cache-Control 헤더: HTTP 헤더의 일종으로, 캐시 정책을 정의합니다. 예를 들어, Cache-Control: max-age=3600은 자원을 1시간 동안 캐싱하도록 지시합니다.
- Expires 헤더: 자원의 유효 기간을 설정합니다. 이 시간이 지나면 캐시된 자원은 만료되며, 새로 요청해야 합니다.
- ETag(Entity Tag): 자원의 고유 식별자로, 서버가 자원의 변경 여부를 확인하는 데 사용됩니다. 캐시된 자원과 원본 자원의 ETag가 동일하면 캐시된 자원을 사용할 수 있습니다.
- Last-Modified 헤더: 자원이 마지막으로 수정된 시간을 나타냅니다. 클라이언트는 이 정보를 사용해 서버에 자원의 변경 여부를 확인하고, 변경되지 않은 경우 캐시된 자원을 사용할 수 있습니다.
캐시 전략:
- Freshness (신선도): 캐시된 자원이 여전히 유효한지 판단하는 기준입니다. Cache-Control, Expires 등을 사용해 설정합니다.
- Revalidation (재검증): 캐시된 자원의 신선도가 만료되었을 때, 원본 서버에 자원이 변경되었는지 확인하는 과정입니다. ETag와 Last-Modified가 재검증에 사용됩니다.
- Invalidation (무효화): 자원이 변경되거나 만료되어 캐시가 더 이상 유효하지 않게 되는 상태입니다. 무효화된 캐시 자원은 원본 서버에서 새로 요청해야 합니다.
장점:
- 성능 향상: 캐시된 자원을 사용하면 로딩 속도가 빨라지고, 사용자 경험이 개선됩니다.
- 서버 부하 감소: 캐시 서버나 브라우저에서 자원을 제공함으로써, 원본 서버의 요청 수를 줄일 수 있습니다.
- 네트워크 트래픽 절감: 자주 사용되는 자원이 캐시되므로, 동일한 자원에 대한 반복적인 다운로드를 줄일 수 있습니다.
단점:
- 정확성 문제: 캐시된 자원이 오래되었거나 변경된 경우, 최신 정보를 반영하지 못할 수 있습니다. 이를 해결하기 위해 적절한 캐시 무효화 전략이 필요합니다.
- 캐시 복잡성: 다양한 캐시 정책과 전략을 구현하고 관리하는 데 복잡성이 수반될 수 있습니다.