2025-11-17

오늘 배운 것

네트워크

  • OSI 7계층 / TCP-IP 4계층

    • OSI 7계층

      계층 역할 대표 프로토콜 PDU
      7. Application 웹/메일/파일 전송 등 애플리케이션 기능 HTTP, FTP, DNS, SMTP Data
      6. Presentation 인코딩, 암호화, 압축 JPEG, MPEG, TLS(일부 기능) Data
      5. Session 세션 연결/유지/종료 NetBIOS, RPC Data
      4. Transport 종단 간 신뢰성, 포트번호 TCP, UDP Segment(TCP) / Datagram(UDP)
      3. Network IP 주소, 라우팅 IP, ICMP, ARP Packet
      2. Data Link 프레임화, MAC 주소 Ethernet, PPP Frame
      1. Physical 전기 신호, 비트 전달 케이블, 전파 Bit

    • TCP/IP 4계층

      TCP/IP 계층 OSI 대응 역할 대표 프로토콜 PDU
      Application OSI 5~7 애플리케이션 통신 HTTP, DNS, FTP Data
      Transport OSI 4 신뢰성/순서/포트 TCP, UDP Segment / Datagram
      Internet OSI 3 라우팅, IP 주소 IP, ICMP Packet
      Network Access OSI 1~2 프레임 전송, 물리 매체 Ethernet, Wi-Fi Frame / Bit

    • OSI vs TCP/IP

      구분 OSI 7계층 TCP/IP 4계층
      목적 이론적 모델 실제 인터넷 표준
      계층 수 7개 4개
      5~7계층 Application/Presentation/Session Application 계층 하나로 통합
      1~2계층 Physical + Data Link Network Access로 통합
  • IP, Subnet, ARP, Routing
    • IP(Internet Protocol)
      • 네트워크에서 호스트를 식별하는 논리적 주소
      • 패킷을 목적지까지 전달하기 위한 주소 체계
      • 역할
        • 호스트 식별
        • 네트워크 경로 지정
        • 데이터그램 기반(비연결형, 비신뢰성)
      • 구성
        • 네트워크 부분 + 호스트 부분
        • 서브넷 마스크에 따라 구분됨
      • IPv4 헤더 핵심 필드
        • Source IP / Destination IP
        • TTL(Time To Live)
        • Protocol(TCP=6, UDP=17)
        • Header Checksum
    • Subnet
      • 큰 네트워크를 작은 네트워크(서브넷)으로 나누는 기술
      • 목적
        • IP 효율적 사용
        • 브로드캐스트 범위 감소
        • 보안/네트워크 분리
      • 표기 방식
        • 192.168.0.0/24
        • /24 → 앞 24비트가 네트워크
        • 가능한 호스트 수 : 256개
      • 서브넷 마스크
        • 255.255.255. 0 = /24
        • 네트워크와 호스트 비트를 구분하는 값
    • ARP (Address Resolution Protocol)
      • IP → MAC 주소를 매핑하는 프로토콜
      • 동일 LAN 내에서 목적지 MAC 주소를 알아낼 때 사용
      • 동작 과정
        • ARP Request(브로드캐스트)
        • ARP Reply(유니캐스트)
        • 결과를 ARP Cache에 저장
      • ARP Cache
        • 일정 시간 저장
        • MAC 스푸핑 공격 위험 → 보안 포인트 가능
    • 라우팅
      • 패킷을 다른 네트워크로 전달하기 위한 경로 결정 과정
      • 목적
        • 목적지 IP를 보고 어떤 경로로 보낼지 판단
        • 라우터가 동작
      • 라우팅 방법
        • 정적 라우팅(수동 설정)
          • 변화 적고 구조 단순한 환경에 유리
        • 동적 라우팅(프로토콜 기반 자동 선택)
          • RIP : 거리 기반
          • OSPF : 링크 상태 기반
          • BGP : 자율 네트워크 간 라우팅 (대형 서비스 필수)
      • 라우팅테이블
        • 0.0.0.0/0 기본 게이트웨이

  • TCP / UDP 비교

    | 구분 | TCP | UDP | | — | — | — | | 연결 방식 | 연결형 (3-way handshake) | 비연결형 | | 신뢰성 | 보장(O) | 보장(X) | | 순서 보장 | O | X | | 재전송 | O | X | | 흐름/혼잡 제어 | O | X | | 속도 | 느림 | 빠름 | | 대표 사용 | HTTP/HTTPS, DB, 파일전송 | 게임, 스트리밍, DNS |

    • HTPTP/3 는 UDP 기반
      • QUIC를 사용 → 핸드쉐이크 감소 + 속도 개선
  • 3-Way / 4-Way Handshake
    • 3-Way Handshake(TCP 연결 수립)
      • TCP가 연결을 시작할 때 사용하는 절차
      • 과정
        • SYN
          • 클라이언트 → 서버
          • 연결하고 싶어(SYN), 내 시퀀스 번호는 X야
        • SYN + ACK
          • 서버 → 클라이언트
          • 좋아 네걸 받았어(ACK), 나도 연결할래(SYN), 내 시퀀스 번호는 Y야
        • ACK
          • 클라이언트 → 서버
          • 서버의 SYN도 확인했어(ACK)
        • 이후 연결 수립 완료
    • 4-way Handshake (TCP 연결 종료)
      • 과정
        • FIN
          • client → server
          • 나 이제 보낼 데이터 없어
        • ACK
          • server → client
          • 알겠어 너는 끊어도 돼
        • FIN
          • server → client
          • 나도 이제 보낼 데이터 없어
        • ACK
          • client → server
          • 알겠어
        • 이후 종료
    • 연결은 3번, 종료는 4번인 이유
      • 연결은 양쪽이 동시에 준비만 확인하면 됌
        • 서버는 SYN을 받는 동시에 ACK와 SYN를 합쳐 보낼 수 있음
      • 종료는 각 방향 독립적으로 종료해야 하기 때문
  • 흐름제어 / 혼잡제어 / 오류제어
    • 흐름 제어
      • 송신자가 너무 빨리 보내서 수신자 버퍼가 넘치는 것 방지
      • 대표 기법 : Stop-and-Wait, Sliding Window
      • sliding window 방식이 실무의 핵심
        • 수신자가 내가 처리 가능한 윈도우 크기(Receive Window, RWND)를 알려줌
        • 송신자는 그 범위 내에서만 데이터를 전송 → 수신자 버퍼 오버플로우 방지
    • 혼잡 제어
      • 네트워크 자체가 혼잡해져서 패킷 유실이 발생하는 것 방지
      • 대표 알고리즘
        • slow start
          • 처음에는 cwnd=1로 매우 느리게 시작
          • ACK 오면 창 크기 2배씩 증가 → 빠른 성능 회복
        • Congestion Avoidence
          • 특정 시점 이후(임계점)부터는 선형 증가로 변경 → 네트워크를 과부하시키지 않기 위해
        • Fast Retransmit
          • 같은 ACK를 3번 받으면 → 중간에 하나 유실 됐구나 하고 바로 재전송
        • Fast Recovery
          • 패킷 하나 유실된 거면 cwnd를 절반으로 줄이고
          • 다시 혼잡 회피 단계로 이동 → 연결을 완전히 떨어뜨리지 않음
    • 오류제어
      • 전송 과정에서 패킷이 깨지거나 유실될 때 처리하는 기법
      • 방법
        • Checksum
          • 패킷 손상 여부 확인
        • 재전송(ARQ)
          • 누락 되면 재전송
        • Sequencing
          • 패킷 순서 보장
        • ACK + Timeout(RTO)
          • 일정 시간 ACK 안오면 재전송
  • TCP 성능 요소(RTT, RTO, 윈도우, TIME_WAIT)
    • RTT (Round Trip Time)
      • 패킷이 왕복하는 데 걸리는 시간
      • 개념
        • 클라이언트 → 서버로 패킷 전송
        • 서버 → ACK 응답
        • 와복시간 = RTT
      • 중요 이유
        • RTT가 높으면 TCP 속도 저하
        • 혼잡 제어/재전송 타이머(RTO) 계산에도 사용됨
    • RTO(Retransmission Timeout)
      • ACK가 오지 않을 때 재전송하기까지 기다리는 시간
      • 동작
        • 송신자가 패킷 전송
        • ACK 일정시간(RTO) 안오면 → 패킷 유실로 판단하고 재전송
      • 계산 방식
        • 과거 RTT 를 기반으로 동적 계산
        • RTT 변동이 클수록 RTO도 길어짐
        • 너무 짧으면 불필요한 중복 전송 발생
        • 너무 길면 복구가 너무 느려짐
    • 윈도우
      • 한 번에 전송할 수 있는 데이터 양
      • 송신 윈도우(cwnd)
        • 혼잡제어와 관련됨
        • 네트워크 혼잡 수준 고려
      • 수신 윈도우(rwnd)
        • 수신자의 처리 가능한 버퍼 크기
        • 흐름제어와 관련됨
    • TIME_WAIT
      • TCP 연결 종료 후 일정시간 (일반적으로 2MSL) 동안 대기하는 상태
      • 필요 이유
        • 늦게 도착한 패킷(지연 패킷) 제거
          • 종료된 이전 연결의 패킷이 다음 연결로 잘못 전달되는 것 방지
        • 서버의 FIN 재전송 처리
          • 서버가 ACK 못받았네 하고 FIN을 다시 보낼 수 있으므로
          • 클라이언트가 살아서 그 FIN을 받아주는 상태여야 함
        • 어디가 TIME_WAIT?
          • 보통 연결 종료를 먼저 요청한 쪽

  • HTTP 1.1 / 2 / 3 비교

    | 항목 | HTTP/1.1 | HTTP/2 | HTTP/3 | | — | — | — | — | | 기반 | TCP | TCP | UDP(QUIC) | | 요청 처리 | 순차적 | Multiplexing | Multiplexing | | HOL Blocking | 심함 | TCP 레벨에서 존재 | 거의 없음 | | 헤더 | 텍스트 | HPACK(압축) | QPACK(압축) | | 연결 설정 | 느림 | 개선 | 0-RTT | | 모바일 변경 | 끊김 | 끊김 | Connection ID로 유지 |

    • HTTP/1.1 - 성능 제약 많은 기본 버전
      • 특징
        • Persistent Connection(Keep-Alive) 도입 → 요청마다 연결 새로 열지 않음
        • 하지만 요청은 순차적 처리(Head-of-Line Blocking) → 첫 요청이 늦어지면 뒤 요청도 같이 막힘
        • 다수의 리소스를 받으려면 → 여러 TCP 연결을 병렬로 열어야 함(비효율)
      • 문제점
        • HOL Blocking
        • TCP 연결 과도 생성
        • 헤더 중복 전송(매 요청마다 모든 헤더 전송)
    • HTTP/2 - 성능 대폭 개선된 버전
      • 핵심 기술
        • 멀티플렉싱
          • 하나의 TCP 연결에서 여러 요청/응답을 동시에 병렬 처리
          • HOL Blocking(애플리케이션 레벨) 제거
        • HPACK 헤더 압축
          • 중복 헤더를 압축 → 네트워크 전송량 감소
        • Server Push(지금은 대부분 비활성)
          • 너 이파일도 필요하지? 하고 서버가 먼저 리소스 푸시 → 지금은 남용 문제로 많이 꺼짐
        • Binary Framing Layer
          • HTTP/1.1의 텍스트 프롴토콜 → 바이너리 프로토콜
          • 파싱 비용 감소
      • 여전히 남은 문제
        • 전송 계층 HOL Blocking은 남아 있음
          • TCP 위에서 동작하기 때문에
          • 패킷 하나 손실되면 전체 스트림이 멈춤
    • HTTP/3 - QUIC(UDP 기반)으로 TCP 한계를 완전히 제거
      • 핵심 기술
        • UDP 기반 QUIC 프로토콜 사용
          • TCP가 갖는 HOL Blocking 제거
          • 패킷 손실 시 해당 스트림만 재전송 → 다른 스트림은 영향 없음
        • 0-RTT 핸드셰이크
          • 연결 설정 거의 없음
          • HTTPS 기반이라 TLS를 프로토콜에 내장 → 연결 지연 크게 감소
        • 연결 ID
          • 네트워크 변경(와이파이 ↔ LTE) 에도 연결 유지 → 모바일 환경에 최적
  • HTTPS & TLS 구조
    • HTTPS
      • HTTP + TLS로 암호화된 안전한 통신
      • 기존 HTPTP는 평문 → 중간에서 그대로 볼 수 있음
      • HTTPS는 TLS를 사용해 암호화 + 무결성 + 인증 제공
    • HTTPS가 제공하는 3가지 보안 성질
      • 기밀성
        • 제 3자가 내용을 볼 수 없음
        • 대칭키 암호화로 빠르게 암호화
      • 무결성
        • 데이터가 중간에 변조되지 않음
        • MAC/Hash로 검증
      • 인증
        • 서버가 진짜인지 확인
        • 인증서(CA) 기반
    • TLS Handshake의 핵심 흐름
      • HTTPS가 안전한 이유는 TLS Handshake로 대칭키를 안전하게 공유하고, 서버의 신원을 확인
      • TLS 1.2
        • ClientHello
          • 클라이언트가 지원 가능한 암호방식 목록 전송
          • 랜덤값 전송
        • ServerHello + Server Certificate
          • 서버가 사용할 암호 방식 선택
          • 서버 인증서(CA가 서명한 공개키) 전송 → 클라이언트는 인증서 검증(위조 여부 확인)
        • Client Key Exchange
          • 클라이언트가 대칭키를 서버 공개키로 암호화하여 전송 → 도청자도 공개키로는 복호화 불가능!
        • Finished
          • 서로 동일한 대칭키를 공유했음을 확인하고 암호화 통신 시작
      • TLS 1.3
        • Handshake 단계를 1 ~ 2 RTT → 1 RTT로 축소
        • 불필요한 프로토콜 제거
        • 속도 증가, 보안성 강화
        • 현대 웹 대부분 TLS 1.3 사용
    • 대칭키 + 비대칭키 같이 사용하는 이유
      • 비대칭키(공개키/개인키)
        • 매운 안전
        • 하지만 암호화 속도가 느림
      • 대칭키
        • 빠름
        • 하지만 키 교환이 위험
      • 따라서
        • 키 교환은 비대칭키로
        • 실제 데이터 암호화는 대칭키로 하는 조합이 가장 효율적
    • 인증서가 하는 역할
      • 인증서
        • 서버의 공개키 + 서버 정보 + CA 서명
      • 필요 이유
        • 클라이언트가 이 서버가 진짜냐? 를 확인하기 위해
      • 인증서 인증 과정
        • 서버가 인증서 전달
        • 클라이언트는 CA의 공개키로 서명 검증
        • 위조되면 TLS handshake 실패
        • 브라우저 경고 발새
  • DNS 동작 방식
    • DNS
      • 도메인 주소를 IP 주소로 바꿔주는 시스템
    • 조회 절차
      • 브라우저 캐시 확인
        • 이미 기록되어 있으면 바로 사용
      • OS 캐시(Local DNS cache) 확인
        • 운영체제 내부 DNS 캐시
      • 로컬 DNS 서버(Resolver)로 요청
        • 보통 ISP(SK/KT/LG)나 회사 내부 DNS
      • 재귀/반복 질의를 통한 IP 조회
        • Resolver가 대신 여러 DNS 서버를 순서대로 조회
        • 조회 순서
          • Root DNS 서버
            • . com 담당 서버로가
          • TLD DNS 서버(.com)
          • Authoritative DNS 서버
            • 실제 IP 주소 반환
      • 결과 캐싱
        • Resolver 캐싱
        • OS 캐싱
        • 브라우저 캐싱
        • TTL이 만료되기 전까지 재조회 안함

    • DNS 레코드 종류

      | 레코드 | 내용 | | — | — | | A Record | 도메인 → IPv4 주소 | | AAAA Record | 도메인 → IPv6 주소 | | CNAME | 도메인 → 또 다른 도메인 | | MX | 메일 서버 주소 | | NS | DNS 서버 주소 | | TXT | SPF, DKIM 등 인증 정보 |

      • 서비스 확장 시 CNAME 기반으로 CDN 연결 자주 사용
    • DNS의 캐싱 구조
      • DNS는 속도 때문에 다음 계층에서 모두 캐싱
        • 브라우저 캐시
        • OS DNS 캐시
        • 로컬 Resolver(ISP)
        • Authoritative DNS
      • TTL이 높을수록 → 빠르지만, 변경 반영이 느림
      • TTL이 낮을 수록 → 변경이 빠르지만, 매번 DNS 조회 비용 증가
    • DNS Lookup 최적화
      • CDN(클라우드플레어 같은거)과 함께 사용해 지리적으로 가까운 노드 연결
      • DNS Prefetch 등 브라우저 최적화 가
  • DNS 기반 로드밸런싱
    • DNS 기반 로드 밸런싱
      • DNS가 여러 IP 중 하나를 돌려주면서 트래픽을 분산하는 방식
      • 도메인 1개에 여러 서버 IP를 등록해두고 → DNS가 IP를 번갈아 응답
    • 동작 방식

      • 여러 A 레코드 등록

          kakao.com → 10.0.0.1  
  kakao.com → 10.0.0.2  
  kakao.com → 10.0.0.3
      • Resolver가 IP하나 선택
        • 보통 라운드 로빈 (1→2→3→1)
      • 선택된 서버로 트래픽 연결
        • 클라이언트는 DNS가 준 IP로 직접 요청을 보냄
    • 장점
      • 인프라 구성 간단
        • 서버 여러 대 등록만 하면 됨
      • 전세계 사용자 분산
        • Geo DNS를 사용하면 근접한 지역 서버로 연결 가능
      • 전세계 CDN 네트워크도 DNS 기반
        • Cloudflare, Akamai 등이 사용
    • 단점
      • DNS 캐싱 때문에 즉각적인 변경이 어려움
        • TTL이 남아있으면 죽은 서버 IP를 그대로 사용해버릴 수 있음
      • 트래픽 분산이 균등하지 않을 수 있음
        • Resolver/브라우저 캐싱 때문에 예상보다 특정 IP로 트래픽이 몰리기도 함
      • 서버 Health Check 불가
        • DNS 자체가 “서버 상태”를 모름
        • 죽은 서버 IP도 그냥 내려줄 수 있음
      • 따라서 대부분 L4/L7 LB와 함께 사용
        • DNS는 큰 방향만 분산
        • 실제 정교한 분산은 로드밸런서가 처리
    • Geo DNS
      • DNS가 사용자의 대략적인 위치에 따라 다른 IP를 줌
        • 한국 → 서울 리전 IP
        • 일본 → 도쿄 리전 IP
          • 전세계 트래픽 분산 + 지연 최소화

  • L4 / L7 Load Balancer

    | 구분 | L4 LB | L7 LB | | — | — | — | | 계층 | 전송 계층 | 애플리케이션 계층 | | 판단 기준 | IP, Port | URL, Header, Cookie | | 성능 | 매우 빠름 | 상대적으로 느림 | | 기능 | 단순 분산 | 세션·도메인·경로 기반 라우팅 | | 사용처 | 게임, 메시지 서버 | 웹 서비스, API 서버 |

    • 로드 밸런싱의 목적
      • 여러 서버에 트래픽 고르게 분산하여
        • 과부하 방지
        • 장애 시 자동 우회
        • 서비스 성능 및 안정성 향상
    • L4 로드 밸런서(전송 계층 로드밸런서)
      • 특징
        • TCP/UDP 포트 기반 분산
        • 패킷의 IP+Port 정보만 보고 판단
        • 내용(HTTP 요청 내용)은 모름
      • 장점
        • 빠름(단순 처림)
        • 비용 낮음
        • 고성능 대량 트래픽 처리에 강함
      • 단점
        • URI/헤더/쿠키 기반 분배 불가
        • 특정 사용자 세션 고정 등의 고급 기능 어려움
      • 언제 사용?
        • HTTP 외의 프로토콜
        • 메시지 서버(TCP), 게임 서버 등
        • 단순 트래픽 분산 목적
    • L7 로드 밸런서 (애플리케이션 계층 로드밸런서)
      • 특징
        • HTTP 헤더, 쿠키, URI, 메서드 등 패킷 내용을 분석해서 분산
        • 요청 내용을 보고 어디로 보낼지 판단 가능
      • 장점
        • Path 기반 라우팅 (/api/v1, /image 등)
        • Host 기반 라우팅 (mobile.kakao.com)
        • Cookie 기반 세션 유지(Sticky Session)
        • 캐싱 / 압축 / SSL 종료(TLS Offloading) 가능
      • 단점
        • 패킷 분석 비용 높음 → 속도 L4보다 느림
        • 비용 높음
      • 언제 사용
        • 웹서비스 대부분 (REST API, 웹앱 등)
        • 기능/도메인별 라우팅 필요할 때
        • 인증/보안 처리할 때
    • 로드밸런서에서의 Health Check
      • L4
        • TCP Port 열림확인
        • Ping/Port 체크 정도
      • L7
        • 특정 URL GET 요청
        • 응답 코드(200 여부) 확인
        • JSON 응답까지 검증가능
        • L4 보다 더 정확하게 장애 감지
    • Sticky Session
      • 같은 사용자의 요청을 항상 같은 서버로 보내는 기능
      • 예 : 로그인 세션 서버별 분리 시 필요
      • 구현방식
        • L7 : Cookie 기반
        • L4 : Source IP 기반 (부정확)
      • 단점
        • 특정 서버 과부하 위험
        • 서버 장애 시 세션 유실가능
          • 그래서 보통 Redis 같은 세션 공유 사용

  • Proxy / Reverse Proxy

    | 구분 | Forward Proxy | Reverse Proxy | | — | — | — | | 위치 | 클라이언트 앞 | 서버 앞 | | 목적 | 클라이언트 보호, 익명성 | 서버 보호, 로드밸런싱 | | 클라이언트는? | 프록시 존재 알고 있음 | 서버의 존재를 모름 | | 대표 예 | 회사 프록시, VPN | Nginx, ALB | | 사용 방향 | 안 → 밖 | 밖 → 안 |

    • forward proxy (프록시)
      • 정의
        • 클라이언트 앞단에 위치하여 클라이언트 → 프록시 → 인터넷 구조로 동작하는 서버
        • 클라이언트가 직접 외부 서버에 접근하지 않고 프록시가 대신 요청을 보내고 응답을 전달
      • 역할
        • 클라이언트 IP 숨기기(익명성)
        • 캐싱을 통한 응답 속도 향상
        • 접근 제한 우회
        • 보안 정책 적용
      • 사용 예
        • 회사, 학교에서 외부 인터넷 접속할 때
        • VPN, 웹 필터링 시스템
    • reverse proxy (리버스 프록시)
      • 정의
        • 서버(백엔드) 앞단에 위치하여 클라이언트는 항상 리버스 프록시만 본다
        • 실제 서버는 내부에 숨겨져 있다
        • 클라이언트 → 리버스 프록시 → 여러 백엔드 서버
      • 역할
        • 로드 밸런싱(L7 로드밸런서 역할 가능)
        • SSL/TLS 종료
        • 캐싱
        • 보안(원 서버 IP 숨김)
        • 압축, 헤더 조작
      • 사용 예
        • Nginx
        • Envoy
        • Apache
        • AWS ALB(사실상 L7 LB= 리버스 프록시 역할)
  • REST API 네트워크 관점
    • REST 개념
      • REST는 리소스를 URI로 표현하고
      • HTTP 메서드로 해당 리소스에 대한 행위를 정의하는 아키텍처 스타일
      • 네트워크 관점에서 Stateless /Cacheable / Uniform Interface가 중요
    • HTTP 메서드의 네트워크적 의미
      • GET
        • 데이터 조회
        • 멱등(Idempotent)
        • 캐싱 가능
        • Body 없음
      • POST
        • 리소스 생성
        • 멱등 아님
        • 캐싱 X
        • 항상 새 요청으로 처리
      • PUT
        • 리소스 전체 교체
        • 멱등(같은 요청 여러 번 보내도 결과 동일)
      • PATCH
        • 리소스 부분 수정
        • 멱등 보장 X (서버 구현에 따라 다름
      • DELETE
        • 리소스 삭제
        • 멱등(여러번 삭제 요청해도 상태 동일)

    • 멱등성 : 같은 요청을 여러번 보내도 결과가 달라지지 않는 성질

      Method Idempotent? 이유
      GET O 조회이므로
      PUT O 같은 내용으로 다시 보내면 동일함
      DELETE O 여러 번 삭제해도 결과는 “없음”
      POST X 여러 번 보내면 중복 생성
    • Stateless
      • 서버는 요청 간 클라이언트 상태를 보관하지 않음
        • 특징
        • 실무에서의 중요성
    • Cache
      • HTTP 레이어 캐시 활용
      • Cache-Control
        • public, private, max-age 적용
        • 정적 리소스 요청 성능 극대화
      • ETag / If-None-Match
        • 서버가 파일 버전 제공
        • 브라우저가 ETag와 비교 → 바뀌지 않았으면 304 Not Modified
      • GET만 캐싱하도록 원칙화
        • 어떤 메서드가 캐싱가능한지는 네트워크 레벨에서 매우 중요
    • URI 설계 - 네트워크 자원 기준
      • 좋은 REST API는 URI가 네트워크 자원 중심
      • 특징
        • 리소스 중심
        • 동사 대신 명사 사용
        • 계층 구조 표현
    • 보안 요소
      • HTTPS 필수
        • 기밀성/무결성 확보
        • 중간자 공격 방지
      • CORS
        • Origin 기반 통제
      • 인증방식
        • JWT, OAuth2
        • 모든 요청에 인증 정보 포함 → Stateless 유지

  • WebSocket / SSE / Long Polling

    | 기술 | 방식 | 방향 | 장점 | 단점 | 사용 예 | | — | — | — | — | — | — | | Long Polling | 요청 후 응답 지연 | 단방향(사실상 요청 기반) | 구현 쉬움 | 요청 과다, 비효율 | 푸시 미지원 환경 | | SSE | HTTP Persistent 연결 | 서버 → 클라이언트 | 서버 Push, 자동 재연결 | 단방향 | 알림, 이벤트 스트림 | | WebSocket | 프로토콜 업그레이드 | 양방향 | 실시간, 효율적 | 인프라 설정 필요 | 채팅, 게임, 실시간 주식 |

    • Long Polling (긴 폴링)
      • 동작 방식
        • 클라이언트가 서버에 요청 전송
        • 서버는 새 데이터가 생길 때까지 응답을 지연
        • 데이터 생기면 응답하고, 클라이언트는 즉시 다시요청을 보냄(무한 반복)
      • 장점
        • WebSocket 지원 안되는 환경에서도 사용 가능
        • 즉시 응답 효과
      • 단점
        • 요청/응답 반복 → 비효율
        • 연결이 지속적으로 끊겼다 다시 생김
        • 서버 부하 증가
        • 모바일 환경에서 네트워크 소모 증가
    • SSE(Server-Sent Events)
      • 서버 → 클라이언트 단반향 스트리밍
      • 동작 방식
        • 클라이언트가 HTTP 요청(Open)
        • 서버는 연결을 유지한 채로 여러 개 이벤트를 계속 푸시
        • 클라이언트는 브라우저 EventSource로 수신
      • 장점
        • HTTP 기반이라 구현 쉬움
        • 서버에서 클라이언트로 이벤트 푸시 가능
        • 자동 재연결 기능
        • 헤더 기반 인증 가능
      • 단점
        • 단반향(서버 → 클라이언트만 가능)
        • 바이너리 전송 불가
        • 웹소켓 보다 유연성 떨어짐
    • WebSocket(양방향 실시간 통신)
      • 서버 ↔ 클라이언트가 모두 실시간으로 주고받는 Full Duplex 방식
      • 동작 방식
        • 처음에는 HTTP로 Handshake
        • 이후 WebSocket 프로토콜로 업그레이드
        • 단일 연결로 양방향 지속 통신 가능
      • 장점
        • 진짜 실시간 통신
        • 양방향(채팅/게임/트레이딩)
        • 헤더 오버헤드 매우 적음
        • 서버 부하 적음( 긴 풀링 대비)
      • 단점
        • 서버 / 로드밸러서 / 방화벽 설정 필요(L7에서 업그레이드 처리)
        • 연결 유지 비용 존재
        • 메시징 서버 구현 난이도 증가
  • 브라우저 캐시 & CDN
    • 브라우저 캐시
      • 클라이언트(브라우저) 측에서 리소스를 저장해 서버 요청 없이 빠르게 로딩하는 기술
      • Cache-Control (강력 캐시 / Hard Cache)
        • 서버가 캐싱 규칙을 헤더로 지정
        • 주요 옵션
        • 동작
      • ETag(조건부 요청 / Validation Cache)
        • 파일 버전을 식별하는 해시값 같은것
      • Last-Modified / If-Modified-Since
        • ETag 와 유사하지만 시간 비교 기반이라 정밀도 떨어짐
    • CDN (Content Delivery Network
      • 전세계에 분산된 캐시 서버(엣지 서버)를 통해 사용자와 지리적으로 가까운 곳에서 콘텐츠 제공
      • 예 : Cloudflare, Akamai, AWS CloudFront
      • 동작 방식
        • 사용자가 static.kakao.com/logo.png 요청
        • 가장 가까운 CDN 엣지 서버로 요청 라우팅
        • 엣지 서버에 캐시가 있으면 즉시 응답
        • 없으면 원본 서버에서 가져와 캐싱
        • 이후부터는 캐시된 파일로 빠르게 응답
      • 장점
        • 성능 향상
        • 서버 부하 감소
        • 글로벌 서비스 필수
      • 캐시 정책
        • HTTP 캐시 규칙(Cache-Control, ETag)을 그대로 따름
        • 오리진 서버의 헤더를 그대로 복사해 캐싱 전략 결정
    • 브라우저 캐시 + CDN 조합이 중요한 이유
      • 대형 서비스는 정적 리소스의 대부분을 CDN에 캐싱해두고 사용자는 브라우저 캐시까지 활용
      • 이구조로 트래픽의 70~90% 오프로딩 가능
  • 네트워크 장애 분석 절차
    1. 문제 범위 파악
      • 체크 항목
        • 특정 사용자만의 문제인지?
        • 특정 지역/ISP만 문제인지?
        • 전체 서비스인지
        • 특정 기능(API)만 문제인지
      • 장애 범위 좁히기가 빠른 복구의 핵심
    2. 네트워크 계층 별 분리(OSI 관점 트러블 슈팅)
      • 물리계층(1)
        • 케이블/서버/네트워크 장비 장애
        • NIC(네트워크 인터페이스 컨트롤러 고유한 맥주소가지고있음) 다운 → ping도 안됨
      • 데이터 링크 계층(2)
        • MAC 충돌, ARP 문제
        • 스위치 포트 다운
      • 네트워크 (3)
        • 라우팅 문제
        • 잘못된 게이트 웨이
        • 서브넷 설정 오류
        • VPN/Firewall 설정 → traceroute로 확인 가능
      • 전송 계층 (4)
        • TCP handshake 실패
        • 포트 차단 → telnet/nc로 포트 열림 확인
      • 애플리케이션 (7)
        • API 오류
        • DB 장애
        • SSL 인증서 만료
        • LB 라우팅 문제 → HTTP 상태 코드/로그 확인
      • 계층별로 접근하면 문제원인 빠르게 좁히기 가능
    3. 핵심 진단 도구 활용
      • Ping
        • ICMP 응답 여부 → 네트워크 기초 연결 확인
      • Traceroute
        • 어느 구간에서 끊기는지 확인(라우팅 문제 확인)
      • nslookup / dig
        • DNS 문제 확인
      • telnet / nc
        • 특정 포트 열림 확인 → 방화벽 / L4 문제 체크
      • Curl
        • 실제 HTTP 요청 테스트
        • 헤더/상태 코드 확인
      • 서버 / 애플리케이션 로그
        • CPU/RAM 스파이크
        • DB 연결 오류
        • API 타임 아웃
    4. 로드 밸런서 쪽 문제 체크
      • 특정 서버만 죽었는지
      • 헬스 체크 실패 중인지
      • LB 라우팅 전략 문제인지
      • Sticky Session 때문에 특정 서버 과부하 인지
    5. 네트워크 패킷 레벨 확인(필요할 때만)
      • Wireshark, tcpdump등을 활용하여 분석 가능 요소
        • SYN 보내고 ACK 오는지
        • TLS Handshake 실패 이유
        • 패킷 재전송 잦은지
        • 대역폭 포화인지
    6. 근본 원인 분석
      • 문제 현상과 실제 원인을 구분해야 함
      • 예
        • DB 응답 느림 → 실제 원인 : 네트워크 MTU mismatch
        • 서비스 타임 아웃 → LB Health Check 설정 오류
    7. 재발 방지 대책 수립
      1. 모니터링 추가
        1. 프로메테우스, 그라파나
        2. 네트워크 지연값
        3. 오류율
        4. LB 별 토폴로지 모니터링
      2. 알림 기준 정의
        1. 시간 초과
        2. 오류율 상승
        3. 패킷 손실 증가
      3. 설정값 튜닝
        1. TCP 타임아웃
        2. LB Health Check 주기
        3. Keep-Alive
        4. 캐시 정책 보완

  • CORS / CSRF / XSS 네트워크 관점

    | 공격/정책 | 어떤 문제? | 네트워크 관점 포인트 | 방어 | | — | — | — | — | | CORS | 브라우저가 타 Origin 요청 제한 | 서버 응답 헤더 기반 허용 | Allow-Origin 설정 | | CSRF | 사용자의 쿠키를 악용한 요청 위조 | 브라우저의 자동 쿠키 전송 문제 | CSRF Token, SameSite | | XSS | 악성 JS 실행 | 서버가 악성 스크립트를 내려줌 | Escape, CSP |

    • CORS (Cross-Origin Resource Sharing)
      • 브라우저가 다른 오리진의 요청을 보안상 기본 차단하는 정책
      • 오리진 = 프로토콜 + 도메인 + 포트
      • 차단 이유
        • 브라우저는 보안을 위해 자바 스크립트가 임의로 다른 사이트에 API 요청하는 것을 막기 때문
      • 네트워크 동작 방식
        • 서버에서
        • 인증 필요한 경우
        • 프록시 서버로 우회(Nginx/Backend Proxy)
      • 중요 : 서버 보안 정책이지, 네트워크 연결 자체가 막힌 것이 아님
        • 프록시나 curl로는 정상 호출 가능
    • CSRF(Cross-Site Request Forgery)
      • 사용자가 로그인된 상태를 악용해 서버가 원치 않는 요청을 수행하게 만드는 공격
      • 공격 원리
        • 사용자가 이미 A사이트에 로그인 → 쿠키 저장
        • 공격자가 악성 사이트 제작
        • 그 사이트에서 A사이트로 요청 보냄
        • 브라우저는 자동으로 쿠키 포함
        • 서버는 정상 요청처럼 처리됨 → 피해 발생
      • 네트워크 관점 핵심
        • CSRF는 브라우저의 자동 쿠키 전송을 악용
        • 요청 자체는 정상 HTTP 요청이라 탐지 어렵다
        • 서버가 누가 보냈는지 모름 → 사용자가 요청했다라고 인식
      • 방어방법
        • CSRF Token (요청마다 임의 토큰 포함)
        • SameSite Cookie 설정
        • Referer/Origin 검증
        • JWT 기반 인증(쿠키 자동 전송 제거)
    • XSS(Cross-Site Scripting)
      • 웹페이지에 악성 스크립트를 삽입해 실행시키는 공격
      • 공격 원리
        • 공격자가 게시판/입력폼 등에 삽입
        • 서버가 이를 제대로 필터링하지 않고 저장
        • 다른 사용자가 페이지 방문시 → 악성 스크립트 실행
        • 쿠키 탈취, 세션 탈취, 화면 위조 등 가능
      • 네트워크 관점 핵심
        • XSS느느 브라우저에서 자바스크립트가 실행되는 것이 문제
        • 네트워크 프로토콜 자체 문제는 아님
        • 즉 서버가 악성 코드 그대로 내려준 것이 원인
      • 방어 방법
        • 입력값 escape
        • 출력 시 HTML Encoding
        • CSP(Content Security Policy) 적용
        • 쿠키에 HttpOnly 설정
  • 클라우드 VPC 기본(VPC, Subnet, SG, NAT, IGW)
    • VPC(Virtual Private Cloud)
      • 클라우드 환경에서 제공하는 사용자 전용 가상 네트워크
      • 특징
        • IP 대역을 내가 정의
        • 서브넷 나누기 가능
        • 보안 규칙, 라우팅, NAT 등 네트워크를 직접 구성
        • 다른 고개 VPC와 완전히 격리
      • 필요 이유
        • 서비스 네트워크 구조를 직접 설계
        • 내부망/외부망/DB망 분리
        • 대규모 서비스 운영에 필수 구성 요소
    • 서브넷
      • VPC를 여러 범위로 쪼개어 서버가 속한 네트워크 영역을 분리하는 단위
      • public subnet
        • Internet Gateway(IGW)와 연결됨
        • 외부 인터넷과 통신 가능
        • 예 : 웹 서버, 리버스 프록시, 로드밸런서
      • private subnet
        • IGW와 직접 연결 X
        • 외부로 나갈 필요 없음
        • 예 : DB 서버, 내부 API 서버
    • Internet Gateway(IGW)
      • VPC가 인터넷과 통신할 수 있게 해주는 장치
      • 역할
        • Public Subnet의 서버가 인터넷에 접근할 수 있도록 연결
        • 외부 사용자가 서비스로 접근 가능하게 함
      • 특징
        • 반드시 Public Subnet + 라우팅 테이블 설정이 필요
        • Private Subnet은 IGW를 직접 사용할 수 없음
    • NAT 게이트 웨이 / NAT 인스턴스
      • Private Subnet 내부서버가 인터넷으로 나갈 수 있도록 해주는 장치
      • 필요 이유
        • DB 서버처럼 인터넷에서 접근되면 안되는 서버가
        • 패치 다운로드, 외부 API 호출 등 아웃 바운드 트래픽이 필요할 때 활용
      • 특징
        • Private Subnet → NAT → IGW → 인터넷
        • 외부에서 private Subnet 서버로 접근 불가(인바운드 차단)
    • Security Group (SG)
      • 서버(EC2) 단위로 적용되는 가상 방화벽
      • 특징
        • 포트/프로토콜/소스 IP 기반으로 허용만 설정(deny 없음)
        • Stateful
        • 서버 단위 보안
      • 예
        • 80/443 포트만 공개
        • SSH(22)는 회사 고정 IP만 허용
        • DB 포트는 API 서버 SG만 허용
  • CSR vs SSR
    • CSR(Client Side Rendering)
      • HTML 뼈대 + JS 내려받고, 브라우저에서 화면 그림
      • 첫 로딩 느릴 수 있음, 이후 네비게이션 빠름
      • SEO 불리(요즘은 개선됨), API 호출 많음
    • SSR(Server Side Rendering)
      • 서버에서 완성된 HTML 만들어서 내려줌
      • 첫 페이지 로딩 빠름, SEO 유리
      • 서버 부하 ↑, 렌더링 로직이 서버에 있음
  • URL 입력시 발생하는 일
    1. 브라우저 캐시/DNS 캐시 확인
    2. DNS 조회 → 도메인 → IP
    3. TCP 연결 (3-way handshake)
    4. HTTPS면 TLS Handshake
    5. HTTP 요청 전송 → 응답 수신
    6. HTML 파싱, CSS/JS/이미지 추가 요청
    7. 렌더 트리 구성 → 화면 그리기
  • URL vs URI
    • URI(Identifier): 자원을 식별하는 모든 식별자 (포괄 개념)
      • 예: mailto:abc@test.com, ftp://..., http://...
    • URL(Locator): 위치를 나타내는 URI

      • 예: https://example.com/path

        👉 실무에선 거의 URL ≈ URI처럼 쓰지만, 면접에선 URL ⊂ URI 라고 말하면 됨.

  • Web Cache
    • 브라우저 캐시: 클라이언트 로컬 저장
    • 프록시 캐시: 회사/ISP 중간에서 공용 캐시
    • CDN 캐시: 전 세계 엣지 서버에 캐시
    • 강력 캐시: Cache-Control: max-age
    • 검증 캐시: ETag / If-None-Match, Last-Modified
  • Cookie vs Session vs Token(JWT)
    • Cookie
      • 브라우저에 저장, 자동으로 서버에 전송
      • 주로 세션ID, 간단 플래그 저장
    • Session
      • 서버 메모리/스토리지에 사용자 상태 저장
      • 클라이언트는 session_id만 쿠키로 들고 다님
      • 서버 확장 시 세션 공유 필요(Redis 등)
    • Token(JWT)
      • 클라이언트가 토큰 자체를 보관(보통 LocalStorage/쿠키)
      • 서버는 토큰 검증만, 상태 저장 X(Stateless)
      • 마이크로서비스/모바일/외부 API에 유리
  • SOP(Same Origin Policy) & CORS
    • SOP
      • 브라우저 보안 정책
      • 도메인+포트+프로토콜이 다르면 JS로 접근 제한
    • CORS
      • SOP 예외를 허용하기 위한 메커니즘

      • 서버가

        Access-Control-Allow-Origin 헤더로 허용 Origin 명시

      • Preflight(OPTIONS) 요청으로 먼저 허가 받음
  • HTTP vs HTTPS vs Socket
    • HTTP
      • TCP 위에서 동작하는 요청/응답 프로토콜
      • 평문(암호화 없음)
    • HTTPS
      • HTTP + TLS 암호화
      • 기밀성, 무결성, 서버 인증 제공
    • Socket (TCP/UDP Socket)
      • 전송 계층 수준의 연결 단위
      • HTTP/HTTPS/WebSocket 모두 결국 소켓 위에서 동작
      • WebSocket: HTTP → 프로토콜 업그레이드 → 양방향 통신
  • 암호화(단방향/양방향/HTTPS과정)
    • 단방향(해시)
      • 복호화 불가: SHA-256, bcrypt
      • 비밀번호 저장 등에 사용
    • 양방향 – 대칭키
      • 암복호화에 같은 키 사용 (빠름)
      • 키 공유가 문제
    • 양방향 – 비대칭키
      • 공개키/개인키 쌍
      • 공개키로 암호화 → 개인키로 복호화
      • 느리지만 키 교환에 사용
    • HTTPS 과정(요약)
      • 서버 인증서(공개키) 받음
      • 클라이언트가 대칭키를 서버 공개키로 암호화해 전송
      • 이후 데이터는 대칭키로 암호화해서 통신
  • OAuth
    • “비밀번호 안 주고, 다른 서비스가 내 계정에 접근하게 하는 방식”
    • 역할:
      • Resource Owner(유저)
      • Client(앱)
      • Authorization Server(로그인 창)
      • Resource Server(API 서버)
    • Authorization Code Flow(웹 기본)
      1. 클라이언트 → 인증서버 로그인 페이지로 리다이렉트
      2. 유저 로그인 & 동의
      3. 클라이언트는 Authorization Code 받음
      4. 그 코드로 Access Token 교환
      5. 토큰으로 API 호출
  • 브라우저 저장소
    • Cookie
      • 자동 전송(도메인/Path/보안 설정에 따라)
      • 용량 작음 (~4KB), 만료일 설정 가능
      • 주로 인증/세션
    • LocalStorage
      • 도메인별로 영구 저장 (명시 삭제 전까지)
      • 자동 전송 X (JS로만 접근)
      • 용량 큼(수 MB 수준)
    • SessionStorage
      • 탭/창 단위 저장
      • 탭 닫으면 삭제
      • 자동 전송 X
  • 서버 응답 코드
    • 1xx: 정보(거의 안 씀)
    • 2xx: 성공
      • 200 OK, 201 Created, 204 No Content
    • 3xx: 리다이렉트
      • 301 Moved Permanently, 302 Found, 304 Not Modified
    • 4xx: 클라이언트 오류
      • 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found
    • 5xx: 서버 오류
      • 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable
  • DHCP
    • IP 주소 자동 할당 프로토콜
    • DORA 과정
      1. Discover: 클라이언트 → “DHCP 서버 있나요?”
      2. Offer: 서버 → “이 IP 쓸래?”
      3. Request: 클라이언트 → “그 IP 주세요”
      4. Acknowledge: 서버 → “알겠어, 너꺼야”
  • MAC 주소
    • 네트워크 카드에 박힌 물리 주소 (L2)
    • AA:BB:CC:DD:EE:FF 형태
    • 동일 LAN 내에서 프레임 목적지 식별
    • IP는 논리 주소(L3), MAC은 물리 주소(L2)
  • CSMA/CD vs CSMA/CA
    • CSMA/CD (Ethernet 유선)
      • 먼저 듣고(Carrier Sense) → 비어 있으면 전송
      • 충돌 나면(Collision Detect) → 전송 중단 + 랜덤 대기 후 재전송
      • 요즘 스위치/풀듀플렉스 환경에선 사실상 충돌 거의 없음
    • CSMA/CA (Wi-Fi 무선)
      • 충돌을 탐지하기 어려워 “피하는(Collision Avoid)” 방식
      • 전송 전 랜덤 대기 + RTS/CTS 등으로 충돌 가능성 줄임

results matching ""

    No results matching ""