🐃 네트워크 애플리케이션

네트워크 애플리케이션 개발

• 애플리케이션 프로그램
  • 서로 다른 종단 시스템(end system)에서 동작
  • 네트워크 상에서 통신
• 네트워크 코어 장비에서 실행되는 소프트웨어를 개발할 필요 없음
  • 네트워크 코어 장비는 사용자 애플리케이션 실행하지 않음
  • 따라서 종단 시스템의 애플리케이션을 빠르게 개발하고 전파가 가능

클라이언트/서버 구조

• 서버 (server)
  • 항상 켜져 있는 호스트 : 서비스 제공
  • 고정 IP 주소
  • 데이터 센터로 확장
• 클라이언트 (client)
  • 서버와 통신 : 서비스 요청
  • 클라이언트들 간 직접 동신하지 않음
  • 유동 IP 가질 수 있음
  • 항상 연결되어 있지 않고 간헐적으로 통신할 수 있음
  • 클라이언트들끼리 직접 통신 불가능
  • 예) HTTP, IMAP, FTP

P2P 구조

• 항상 켜져 있는 서버 없음
• 임의의 종단 시스템과 직접 통신
• 각 피어(peer)들이 각각 서비스를 요청하고 제공
  • 높은 자기 확장성
  • 새 피어가 새로운 서비스가 제공하고, 새 서비스를 요청

프로세스 간 통신 (Processes Communicating)

• 프로세스(process)는 호스트에서 실행 중인 프로그램
  • 호스트 내에서 두 프로세스는 OS에서 정의한 IPC(inter-process communication)로 통신
  • 다른 호스트 간의 프로세스들은 메시지(message)를 교환하여 통신
• 클라이언트(client)와 서버(server) 프로세스
  • 클라이언트는 두 프로세스 간의 통신 세션을 초기화(접속을 초기화)하는 프로세스
  • 서버는 세션을 시작하기 위해 접속을 기다리는 프로세스
  • P2P 구조의 애플리케이션들은 클라이언트 프로세스와 서버 프로세스를 가짐

소켓 (Socket)

• 프로세스는 소켓 (socket)을 통해 네트워크로 메시지를 송수신
  • 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스
  • 프로세스는 집 (house), 소켓은 출입구(door)에 비유
  • 소켓은 애플리케이션과 네트워크 사이의 API(Application Programming Interface)

프로세스의 주소

• 메시지 수신을 위해 프로세스를 구분하는 식별자(indentifier)가 있어야 함
• 호스트는 32비트 IP 주소로 식별
• 호스트 상의 프로세스는 IP주소와 포르 번호로 구분

🐲 애플리케이션 계층 프로토콜

• 애플리케이션 계층 프로토콜은 다음과 같은 내용을 정의
  • 교환되는 메시지의 타입 : 요청 메시지, 응답 메시지
  • 여러 메시지 타입의 문법 (syntax) : 메시지 내부의 필드와 필드 간의 구별 방법
  • 메시지 의미 (message sematics) : 필드에 있는 정보의 의미
• 오픈 프로토콜 (open protocol)
  • RFC (Request For Comments)로 정의
  • 상호작용(interoperability) 허용
  • 예) HTTP, SMTP

🏺 애플리케이션이 요구하는 트랜스포트 서비스

• 데이터 무결성 (data integrity) : 일부 으용들은 100% 신뢰적 데이터 전송 요구
• 처리율 (throughput) : 일부 으용들은 효과적인 서비스를 위해 요구되는 최소의 처리율 보장
• 시간 (time) : 일부 응용들은 효율적인 서비스를 위해 최소의 지연을 요구
• 보안 (security) : 암호화(encryption), 데이터 무결성 등 서비스 제공

🌸 인터넷 트랜스포트 계층이 제공하는 서비스

TCP(Transmission Control Protocol) 서비스

• 신뢰적인 데이터 전송 : 송수신 프로세스 간에 데이터의 손실 없이 올바른 순서로 전달
• 흐름 제어(flow control) : 송신 프로세스가 수신 프로세스의 데이터 수신 속도에 맞추어 송신
• 혼잡 제어(congestion control) : 네트워크가 혼잡 상태에 이르면 프로세스의 전송 속도를 낮춤
• 연결지향형 서비스 (connection-oriented service) : 클라이언트와 서버 프로세스들 간에 연결 설정 (핸드쉐이킹 후 송수신 준비)
• 제공하지 않는 서비스 : 시간 보장, 최소 처리율 보장, 보안

UDP (User Datagram Protocol) 서비스

• 비신뢰적인 데이터 전송 서비스를 제공
• 비연결형으로 두 프로세스가 통신 전에 정보 교환(hanshaking)을 하지 않음
• 흐름제어, 혼잡제어, 시간 보장, 처리율 보장, 보안등의 서비스도 제공하지 않음
• 실시간 애플리케이션들이 전송속도를 위해 UDP 사용
  • TCP 혼잡제어와 패킷 오버헤드 문제 회피
  • 많은 방화벽들이 UDP 트래픽을 차단하도록 설정되어 대부분 TCP로 넘어가는 중

보안 TCP

• TCP와 UDP : 암호화를 제공하지 않음
• TLS (Transport Layer Security) : 암호화된 TCP 연결을 제공, 데이터 무결성 (data integrity), 종단 인증
• TLS는 애플리케이션 계층에서 구현 : 애플리케이션은 TLS 라이브러리를 사용하여 평문을 소켓에 전송

🍎 웹과 HTTP

• 웹 페이지는 객체(HTML 파일, JPEG 이미지, 오디오 …)들로 구성
• 웹 페이지는 기본 HTML 파일과 여러 참조 객체들로 구성
• 각 객체는 URL (Uniform Resource Locator)로 지정 : URL은 객체를 가지고 있는 서버의 호스트 이름과 객체의 경로 이름으로 구성

🚌 HTTP 개요

• HTTP (HyperText Transfer Protocol)는 웹의 애플리케이션 계층 프로토콜
• 클라이언트/서버 모델
  • 클라이언트: HTTP 웹 객체들을 요청하고 받아서 디스플레이 → 브라우저
  • 서버 : HTTP 요청에 응답하여 객체 전송 → 웹 서버
• HTTP는 TCP 트랜스포트 프로토콜을 사용
  • 클라이언트는 80번 포트로 서버에게 TCP 연결을 시작
  • 서버는 클라이언트의 TCP 연결 요청을 수락
  • 브라우저와 웹 서버 사이에 HTTP 메시지를 교환
  • TCP 연결 종료
• HTTP는 비상태 프로토콜 (stateless protocol) : 서버는 클라이언트의 과거 요청들에 대한 정보 x

🍫 HTTP 연결

HTTP 연결은 비지속 연결과 지속 연결 2가지 방식이 있음

비지속 연결 HTTP (non-persistent connection)

• 요구/응답 쌍이 분리된 TCP연결을 통해 송수신
• 하나의 TCP 연결로 하나의 객체만 전송
• RTT (Round-Trip Time) : 클라이언트에서 송신된 작은 패킷이 서버까지 간 후 (그 응답이) 다시 클라이언트로 되돌아오는데 걸리는 시간
• HTML 파일 요청 응답 시간(response time)
  • TCP 연결을 초기화 하는 1 RTT
  • HTTP 요청을 하고 HTTP 응답으로 처음 몇 바이트를 받는데 필요한 1 RTT
  • 파일 전송 시간 : 2RTT + 파일 전송시간
• 단점 : 각 객체 당 2 RTT 필요, 각 TCP 연결에 대한 OS 오버헤드, 종종 병렬 TCP 연결 시도

지속 연결 HTTP (persistent connection) : HTTP 1.1

• 모든 요구/응답 쌍이 같은 TCP 연결 상에서 송수신
• 다수의 객체들이 하나의 TCP 연결로 전송
• 서버는 응답을 보낸 후 TCP 연결을 그대로 유지
• 클라이언트/서버 간의 이 후 HTTP 메시지들은 같은 연결을 통해 송수신
• 클라이언트는 객체를 참조하자마자 요청을 송신
• 모든 참조 객체들에 대해 1RTT만 필요

🐇 HTTP 요청 메시지

두 유형의 HTTP 메시지 : 요청(request), 응답(response)

HTTP 요청 메서드 (Method)

• POST 메서드
  • 웹페이지에 폼 입력이 포함된 경우
  • 클라이언트의 사용자 입력이 HTTP POST 요청 메시지의 몸체에 포함되어 서버로 전송
• GET 메서드
  • 사용자 입력은 요청 라인의 URL 필드(? 이 후)에 포함되어 서버에 전송
• HEAD 메서드
  • 문서의 정보만 요청하여 응답 메시지에는 몸체 없이 헤더 정보만 응답
• PUT 메서드
  • 서버에 새로운 파일(객체)을 업로드
  • 서버의 지정된 URL 위치에 파일이 존재하면 새 파일로 대체

HTTP 응답 상태 코드

일반적인 상태 코드

• 200 OK : 요청이 성공되었고, 요청된 객체가 이 메시지로 보내짐
• 301 Moved Permanently : 요청된 객체가 이동되었고, 새로운 위치는 메시지의 “Location” 헤더로 표시
• 400 Bad Request : 서버가 요청을 이해할 수 없다는 일반 오류 코드
• 404 Not Found : 요청된 문서가 서버에 존재하지 않음
• 505 HTTP Version Not Supported : 요청된 HTTP 프로토콜 버전을 서버가 지원하지 않음

🐻 쿠키 (Cookie)

대부분의 상용 웹 사이트들이 쿠키(cookie)를 사용하여 사용자 상태를 추적하고 유지

• 쿠키는 4가지 요소로 구성
  • HTTP 응답 메시지의 쿠키 헤더 라인
  • HTTP 요청 메시지의 쿠키 헤더 라인
  • 사용자 호스트에 저장되어 브라우저에 의해 관리되는 쿠키 파일
  • 웹 사이트의 백엔드 데이터 베이스

• 쿠키의 활용 : 사용자 식별 확인, 쇼핑 카트, 제품 추천, 사용자 세션 상태
• 상태 보존 : 쿠키는 프로토콜 종단에서 상태를 유지하지 않고 HTTP 메시지가 상태를 전송
• 쿠키와 사용자 사생활 침해
  • 쿠키와 사용자 계정정보(이름, 메일주소 등)와 결합
  • 사용자의 많은 정보가 노출

🔖 웹 캐시 (web cache)

• 웹 캐시(web cache)는 원래 웹 서버를 대신하여 클라이언트의 요청을 충족 시켜주는 네트워크 개체 : 프록시 서버(proxy server) 라고도 함
• 브라우저는 웹 캐시와 연결을 설정하고 웹 캐시에 HTTP 요청 전송
  • 웹 캐시에 객체가 있으면 객체를 전송
  • 없으면 웹 캐시가 기점 서버에 객체를 요청하여 가져와서 클라이언트에 전송
• 웹 캐시는 클라이언트와 서버로 동작
  • 웹 요청을 한 클라이언트(브라우저)에게는 서버로 동작
  • 웹 문서가 저장된 원래 웹 서버에게는 클라이언트로 동작
  • 서버는 응답 헤더에 객체의 캐싱 가용 여부 포함
• 웹 캐싱 이점
  • 클라이언트의 요청에 대한 응답 시간을 줄일 수 있음
  • 인터넷으로의 기관 접속 회선 상의 웹 트래픽(web traffic)을 줄일 수 있음
  • 웹 캐시를 갖는 고밀도 인터넷 : 콘텐츠 제공자가 저속도의 접속 회선을 가진 느린 서버에서 사이트를 운영하더라도 빠른 콘텐츠 분배를 위한 기반 구조 제공

🦴 참고

Computer Networking A Top-Down Approach 7th