[컴퓨터 네트워크 수업] Chapter 2. Application Layer 요약

Client-Server vs. P2P

• 클라이언트-서버
  • 서버는 항상 켜져있으며 고정 IP를 가짐
  • 클라이언트는 서버에 요청하고 서버에 응답하는 구조
• P2P(Peer-to-Peer)
  • 중앙 서버가 없고 피어 간 직접 통신
  • 각 피어가 클라이언트이자 서버 역할
  • 자체 확장성 뛰어나나 IP 주소 변동으로 인해 관리 복잡

프로세스 간 통신 및 소켓

• 프로세스 간 통신
  • 같은 호스트 내 → IPC 매커니즘
  • 다른 호스트 간 → 메시지 교환
• 소켓: 프로세스와 전송 계층 사이에서 데이터를 보내고 받는 인터페이스

애플리케이션 계층 프로토콜 및 전송 서비스 요구사항

• 애플리케이션에 필요한 전송 서비스
  • 데이터 무결성
  • 타이밍
  • 처리량
  • 보안
• 애플리케이션 계층 전송 게층 선택 기준
  • 데이터 무결성 필요 여부: 신뢰성 필요 → TCP
  • 타이밍 민감도: 실시간 요구 → UDP
  • 처리량 요구: 멀티미디어 전송 → 최소 throughput 보장 필요
• TCP vs. UDP
  • TCP
    • 신뢰성
    • 흐름 제어
    • 혼잡 제어
    • 연결 지향
    • 타이밍, 최소 처리량, 보안 등은 지원 x
  • UDP
    • 비신뢰성
    • 비연결 지향 → 타이밍에 유리
    • 아무것도 지원 X

웹과 HTTP

• HTTP 기본 개념
  • 클라이언트-서버 모델
  • TCP 사용
  • 무상태성(stateless)
• 비영구적(non-persistent) 연결 vs. 영구적(persistent) 연결
  • 비영구적 연결
    • 매 요청마다 TCP 연결을 생성 및 종료 → 각 객체에 대해 2RTT + 파일 전송 시간 필요
    • ⇒ 다수 객체 전송 시 오버헤드 및 지연 시간 증가
  • 영구적 연결(HTTP/1.1 이후)
    • 한 번의 TCP 연결에서 여러 객체 연속적으로 전송 가능
    • ⇒ TCP 연결 설정 비용 절감, RTT 횟수 감소로 응답 시간 단축
• HTTP 요청 및 응답 메시지
  • 요청 메시지
    • 요청 라인: 메서드, URL, HTTP 버전
    • 헤더 라인
    • 공백 라인
    • 요청 본문
  • 응답 메시지
    • 상태 라인: 프로토콜 버전, 상태 코드, 상태 구문
    • 헤더 라인
    • 응답 본문
• 쿠키(Cookie)를 통한 상태 유지
  • 쿠키를 이용하여 클라이언트의 상태를 서버가 추적할 수 있음
  • 상태 유지 방법
    • 서버가 응답 시 Set-Cookie 헤더로 쿠키를 클라이언트에 저장
    • 이후 클라이언트는 요청 시 쿠키 값을 포함하여 전송
    • 서버는 이를 통해 로그인 상태, 세션, 장바구니 등을 관리 가능
• 웹 캐시(Web-Cache)
  • 클라이언트 또는 프록시 서버가 자주 요청되는 객체를 로컬에 저장하여, 원 서버에 대한 요청을 줄여 응답 시간과 네트워크 부하를 감소
    • 캐시 적중 시 Access Network를 안 타서 지연 시간 대폭 감소
• 브라우저 캐시: 조건부 GET
  • 클라이언트: If-modified-since: <date>를 전달
  • 서버: 이미 브라우저에 캐시된 데이터가 up-to-date라면 응답 객체 포함 X
    • = HTTP/1.0 304 Not Modified
    • ⇒ 객체 전송 지연을 없애고, 네트워크 리소스 사용을 줄일 수 있음
• HTTP/2 및 HTTP/3
  • HTT/1.1의 문제점: FCFS 방식으로 인한 HOL blocking 문제 + loss recovery
  • HTTP/2 개선점
    • 멀티플렉싱: 요청 객체를 프레임 단위로 쪼개어 서로 간섭없이 전송
    • 우선순위 설정: 클라이언트가 각 객체에 대해 우선순위 지정 가능 ⇒ HOL 블로킹 문제 해결
    • 서버 푸시: 클라이언트가 요청하지 않은 객체도 미리 전송 가능
  • HTTP/3
    • UDP 기반으로 전환
    • 개별 객체의 에러 및 혼잡 제어 보다 효과적 수행

이메일

• 구성요소
  • 사용자 에이전트(UA):
  • 메일 서버
    • 메일박스(mailbox)
    • 메시지 큐
  • 프로토콜
    • 메일 전송 → SMTP
    • 메일 수신 → IMAP or POP
• SMTP 프로토콜
  • TCP 사용(25번 포트)
  • 특징
    • ASCII 기반 명령/응답 인터렉션
    • 영속적(persistent) 연결 사용 → 한 번에 여러 개 전달 가능
  • 메일 전송 시나리오
    • A host(UA) → A mail server (message queue) → TCP connection → B mail server(mailbox) → B host(UA)
• HTTP vs. SMTP
  • 공통점
    • ASCII 기반 메시지 형식
    • 요청/응답 구조와 상태 코드 사용
  • 차이점
    • HTTP는 client pull(non-persistent), SMTP는 client push(= persistent)
    • HTTP는 무상태(stateless), SMTP는 연결을 유지(persistent)

도메인 이름 시스템(DNS)

• DNS 서비스
  • hostname을 IP 주소로 번역
  • host aliasing
  • mail server aliasing
  • load distribution
• DNS 분산 데이터베이스 구조
  • 루트 서버: TLD 서버의 정보를 보유 및 반환
  • TLD 서버: 최상위 도메인에 대한 정보 제공
  • Authoritative DNS 서버: 도메인 IP 주소 매핑과 기타 리소스 레코드 관리
  • Local DNS 서버: 호스트가 DNS 질의 시작 시 가장 먼저 응답하며, 로컬 캐시 있음
    • 각 ISP가 Local DNS 서버를 가짐
    • 계층 구조에서 엄격하게 속하진 않음
• 질의 방식 비교
  • 반복(iterative) 질의: 클라이언트가 각 단계마다 적합한 서버에 질의하는 방식
  • 재귀(recursive) 질의: 로컬 DNS 서버가 모든 단계를 대신 수행하여 최종 결과를 반환하는 방식
• 캐싱: DNS 서버는 한 번 조회한 결과를 TTL(Time To Live) 동안 캐싱하여, 네트워크 부하와 응답 지연을 줄임
• DNS records
  • A 레코드: 도메인 이름(hostname)을 IPv4 주소에 매핑
  • NS 레코드: 도메인의 권한 있는 네임서버를 지정
  • CNAME 레코드: 하나의 도메인 이름을 또 다른 도메인 이름에 대한 별칭(alias)으로 지정
    • 동일 컨텐츠를 제공하는 여러 도메인 관리 시 사용
  • MX 레코드: 도메인에 할당된 이메일 서버를 지정
• DNS 프로토콜 메시지
  • query와 reply가 동일한 포맷 사용
  • 헤더
    • 메시지 식별자
    • 플래그
    • query인지 reply인지
    • recursion 방식을 취할지 여부
    • recursion 방식 사용 가능한지 여부
    • authoritative server로부터의 응답인지 여부
  • 질문 섹션(Questions): 클라이언트가 요청하는 도메인 이름과 조회할 레코드 유형(A, AAAA, MX 등)을 포함
  • 답변 섹션(Answers): 요청에 따른 실제 응답 데이터, 즉 해당 도메인에 매핑된 레코드 정보가 포함
  • 권한 섹션(Authority): 질의한 도메인에 대한 권한 있는 네임서버 정보가 포함
  • 추가 섹션(Additional info): 질의에 보완적인 정보를 제공하며, 예를 들어 관련된 IP 주소 정보를 포함

P2P 애플리케이션

• P2P의 특징
  • 중앙 서버 없이 엔드 시스템(피어)끼리 직접 통신
  • 각 피어는 동시에 클라이언트와 서버 역할을 수행함
  • 자체 확장성(self scalability): 새로운 피어가 참여하면 서비스 제공 능력이 함께 증가
• 파일 분배 시 클라이언트-서버 vs. P2P
  • 클라이언트-서버 방식
    • 클라이언트 수가 증가하면 전송 시간이 선형적으로 증가 ⇒ N이 커질수록 서버가 혼자 다 처리해야 하므로 느려짐
  • P2P 방식
    • 서버는 한 번만 업로드하고, 각 피어가 파일 조각을 서로 교환 → 피어들이 업로드 용량을 제공하여 전체 분배 시간이 줄어듦(= 업로드 주체가 서버 + 모든 peer)
    • N이 커질수록 시스템 자원, 즉 총 업로드 용량 증가 + 병렬적 분산 처리 가능
  • ⇒ 사용자가 많을수록 P2P가 훨씬 효율적
• BitTorrent 프로토콜
  • 파일 분할: 큰 파일을 256KB 크기의 조각(chunks)으로 분할
  • 트래커(tracker): 현재 토렌트에 참여 중인 피어들의 목록을 관리
  • 토렌트(torrent): 파일 조각을 교환하는 피어들의 그룹
  • 파일 조각 요청
    • 각 피어들은 서로 다른 조각들을 가지고 있기에, 한 피어는 주기적으로 다른 피어들에게 자신이 가지고 있는 파일 조각의 목록을 요청하여 조각 분포 파악
    • 희귀한 조각 우선 요청: 자신이 가지고 있지 않은 조각들 중 전체 네트워크에서 가장 희귀하게 분포된 조각을 우선 요청
      • ⇒ 파일 전체의 조각 분포를 고르게 만들어 특정 조각이 부족해지는 현상 방지
  • 파일 조각 송신(= Tit-for-Tat 전략) ⇒ "나에게 데이터를 보내는 피어에게만 데이터를 전송”
    • 대역폭이 제한되어 있으므로, 한 번에 전송 속도가 가장 빠른 소수의 peer(보통 4명)에게만 업로드 허용(unchocked), 나머지는 chocked
    • 주기적으로(보통 10초) 누가 나에게 가장 빠르게 보내주고 있는지 확인해서, 그 사람에게만 업로드 허용 ⇒ 공정성 유지
    • 낙관적 차단 해제(Optimistic unchocking): 주기적으로(보통 30초) 임의의 새로운 peer 1명에게 기회를 줌 ⇒ 새로운 피어에게도 기회 제공
      • 새로 선택된 피어는 성능이 좋으면 상위 4명의 그룹(unchocked group)에 합류할 기회를 얻게 됨

비디오 스트리밍 및 콘텐츠 배포 네트워크(CDNs)

• 비디오 기본 구성
  • 연속된 이미지(프레임)
  • 디지털 이미지를 압축
    • 공간적 코딩: 같은 색상 압축
    • 시간적 코딩: 프레임 간 차분 전송
  • 비디오 인코딩: CBR, VBR 방식으로 압축
• 스트리밍의 어려움
  • 네트워크 지연이나 패킷 손실이 영상 품질에 직접적인 영향을 미침..
  • ⇒ 버퍼링을 통해 네트워크 지연과 지터를 보상해야 함
• DASH(Dymaic Adaptive Streaming over HTTP)
  • 비디오를 조각(chunks) 단위로 나누고, 이를 다시 다양한 비트율로 인코딩하여 저장
  • 클라이언트는 네트워크 상황에 따라 적절한 비트율의 조각을 선택
  • Manifest file을 통해 요청할 조각의 URL 결정
  • 재생 중 실시간으로 품질, 타이밍, CDN 서버를 유동적으로 변경
    • ⇒ Intelligence at Client
• CDN
  • 필요성: 사용자 수 증가로 인한 중앙 서버의 부하 문제 → 분산 구조가 필요
  • 장점:
    • 사용자와 가까운 위치의 서버에서 콘텐츠 제공 → 지연 감소
    • 트래픽 부하 분산
    • 글로벌 스케일의 서비스 안정성 확보