2. 어플리케이션 계층 1

2.1 네트워크 어플리케이션의 원리

• 네트워크 어플리케이션 개발의 중심은 다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것.
• 라우터나 링크 계층 스위치와 같이 네트워크 코어 장비에서 실행되는 소프트웨어를 작성할 필요 없음.

 

네트워크 어플리케이션 구조

• 네트워크 구조

• 애플리케이션 구조
  • 애플리케이션 구조: 애플리케이션 개발자에 의해 설계되고 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 지시함.
  • 클라이언트-서버 구조
    • 서버Server: 항상 켜져 있는 호스트. 클라이언트라는 다른 많은 호스트의 요청을 받음
    • 클라이언트Client: 가끔 혹은 항상 켜져 있을 수 있는 호스트. 
  • 클라이언트-서버 구조에서 클라이언트는 서로 직접적으로 통신하지 않음
  • 서버는 고정 IP주소라는 잘 알려진 주소를 가짐.
  • 클라이언트는 서버 주소로 패킷을 보내서 항상 서버에 연결할 수 있음.
  • ex) 웹, 파일 전송, 원격 로그인, 전자메일 
  • 많은 수의 호스트를 갖춘 데이터 센터data center가 강력한 가상 서버를 생성하는 데 흔히 사용됨.

 

프로세스 간 통신

• 운영체제 용어에서 실제 통신하는 것은 프로그램이 아니라 프로세스임.
• 프로세스는 종단 시스템에서 실행되는 프로그램임.
• 통신 프로세스가 서로 같은 호스트에서 실행될 때 그들은 서로 프로세스 간에 통신하며 프로세스 간의 통신을 윈한 규칙은 종단 시스템의 운영체제에 의해 좌우됨.
• 네트워크는 서로 다른 호스트(또한 다른 운영 체제)에서 실행되는 프로세스와 통신 하는 것에 대한 방법론을 의미함.
• 2개의 다른 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지(message) 교환으로 서로 통신함.

 

클라이언트와 서버 프로세스

•  클라이언트: 두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스.
  • ex) 브라우저
• 서버: 세션을 시작하기 위해 접속을 기다리는 프로세스
  • ex) 웹 서버

 

프로세스와 컴퓨터 네트워크 사이의 인터페이스

• 하나의 프로세스로부터 다른 프로세스로 보내는 메시지는 네트워크를 통해 움직임.
• 프로세스는 소켓Socket을 통해 네트워크로 메시지를 보내고 받음.
• 소켓Socket
  • 다른 호스트의 프로세스와 통신을 하기 위해 os가 만들어 놓은 인터페이스.
  • 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스.
  • 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로 애플리케이션과 네트워크 사이의 API(Application Programming Interface)라고도 함.
• 어플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만 소켓의 트랜스포트 계층에 대한 통제권은 거의 갖지 못함.

 

프로세스 주소 배정

• 한 호스트상에서 수행되고 있는 프로세스가 패킷을 다른 호스트에서 수행되고 있는 프로세스로 패킷을 보내기 위해서는 수신 프로세스가 주소를 갖고 있을 필요가 있음.
• 두 가지 정보가 명시되어야 함.
  1. IP: 호스트의 주소
  2. port number: 목적지 호스트 내의 수신 프로세스를 명시하는 식별자
• 인기 있는 응용은 특정 포트 번호가 할당됨.
  
  • ex) 웹 서버 : 80 / 메일 서버: 25 ...
• 사람들의 편의성을 위해 포트 번호는 URL 형태로 쓰여지고, 이 URL을 DNS 서버가 IP 형태로 바꿔줌.

 

애플리케이션이 이용 가능한 트랜스포트 서비스(어플리케이션에게 필요한 트랜스포트 서비스)

• 신뢰적 데이터 전송Data Integrity
  • 송신 프로세스가 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는 서비스.
  • 트랜스포트 계층 프로토콜이 애플리케이션에 제공할 수 있는 유일한 서비스
  • 손실 허용 어플리케이션loss-tolernat application: 어느 정도의 데이터 손실을 참아낼 수 있는 애플리케이션.
    • ex) 실시간 오디오/비디오, 저장 오디오/비디오와 같은 멀티 어플리케이션

• 처리량Throughput
  • 애플리케이션이 r bits/sec의 보장된 처리율을 요구할 때 트랜스포트 프로토콜은 가용한 처리율이 항상 적어도 r bps임을 보장하는 서비스
  • 대역폭 민감 애플리케이션bandwith-senstive application: 처리율 요구사항을 갖는 애플리케이션.
  • 탄력적 애플리케이션elastic application: 가용한 처리율이 많으면 많은 대로, 적으면 적은 대로 이용할 수 있는 애플리케이션.

• 시간Timing
  • 여러 형태의 시간 보장을 해주는 서비스. ex) 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100 msec 내에 도착하도록 함.
  • ex) 인터넷 전화, 가상 환경, 원격 회의, 멀티플레이어 게임

• 보안
  • 애플리케이션에 하나 이상의 보안 서비스를 제공하는 서비스.

 

인터넷 전송 프로토콜이 제공하는 서비스(실제로 트랜스포트 계층이 제공하는 서비스)

• TCP
  • 연결지향성 서비스와 신뢰적인 데이터 전송 서비스를 제공.
    • 연결지향성 서비스: 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환하도록 해주며, 이 핸드 셰이킹 단계를 지나면 TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 얘기함.
  • 전자 메일(SMTP), 원격 터미널 접속(Telnet), 웹(HTTP), 파일전송(FTP) 등은 TCP를 하위 트랜스포트 프로토콜로 사용하고 있음
• UDP
  • 비연결형이므로 핸드 셰이킹을 하지 않음.
  • 하나의 프로세스가 UDP 소켓으로 메시지를 보내면 UDP는 그 메시지가 수신 소켓에 도착하는 것을 보장하지 않음.
  • 수신 소켓에 도착하는 메시지들의 순서가 뒤바뀔 수 있음.

 

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스

• 처리율
• 시간 보장

 

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

• 애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의함
  • 교환 메시지 타임. ex) 요청 메시지와 응답 메시지
  • 여러 메시지 타입의 문법. ex) 메시지 내부의 필드와 필드 간의 구별 방법
  • 필드의 의미(필드에 있는 정보의 의미)
  • 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
• ex) HTTP - 웹 애플리케이션 계층 프로토콜

 

2.2 웹과 HTTP

HTTP 개요

• HTTP(HyperText Transfer Protocol): 웹의 애플리케이션 계층 프로토콜
• 클라이언트 프로그램과 서버 프로그램 두 가지 프로그램으로 구현됨.
• 서로 다른 종단 시스템에서 수행되는 클라이언트 프로그램과 서버 프로그램은 서로 HTTP 메시지를 교환하여 통신함.
• 웹 페이지web page는 객체로 구성됨
  • 객체Object: 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일, JPEG 이미지, GIF 이미지, 자바 애플릿, 오디오 클립).
  • 대부분의 웹 페이지는 기본 HTML파일과 여러 참조 객체로 구성됨. ex) 웹페이지가 HTML 텍스트 1개 + JPEG 이미지 5개로 구성되어 있으면, 이 페이지는 6개의 객체를 갖고 있는 것.
• 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언트로 어떻게 웹 페이지를 전송하는지 정의.
• 사용자가 웹 페이지를 요청request(예: 하이퍼링크를 클릭) -> 브라우저는 페이지 내부의 객체에 대한 HTTP 요청 메시지를 서버에게 보냄 -> 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지로 응답response함.
• HTTP 서버는 클라이언트에 대한 정보를 유지하지 않음 -> HTTP를 비상태 프로토콜stateless protocol이라고 함.

 

비지속 연결과 지속 연결

• 비지속 연결non-persistant connection: 각 request/response 쌍이 분리된 TCP 연결상으로 보내지는 방식
• 지속 연결persistant connection: 모든 request에 해당하는 response들이 같은 TCP 연결상에서 보내지는 방식

 

비지속 연결 HTTP

• 페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고 이 11개의 객체가 같은 서버에 있다고 가정. 
• 기본 HTML 파일의 URL은 http://www.someschool.edu/someDepartment/home.index.
• 연결 수행 과정 예시
  1. HTTP 클라이언트는 HTTP 기본 포트 번호 80을 통해 http://www.someschool.edu 서버로 TCP 연결 시도. 이때 TCP 연결과 관련하여 클라이언트과 서버에 각각 소켓이 생김.
  2. HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지를 보냄.
     • 이 요청 메시지는 /someDepartment/home.index 경로 이름을 포함함.
  3. HTTP 서버는 1단계에서 설정된 연결 소켓을 통해서 요청 메시지를 받음. 저장장치로부터 /someDepartment/home.index 객체를 추출함. HTTP 응답 메시지에 그 객체를 캡슐화함. 그리고 응답 메시지를 소켓을 통해 클라이언트로 보냄.
  4. HTTP 서버는 TCP에게 TCP 연결을 끊으라고 함. (실제로 TCP 클라이언트가 응답 메시지를 올바로 받을 때까지 끊지 않음)
  5. HTTP 클라이언트가 응답 메시지를 받으면 TCP연결이 중단됨. 메시지는 캡슐화된 객체가 HTML 파일인 것을 나타냄. 클라이언트는 응답 메시지로부터 파일을 추출하고 HTML 파일을 조사하고 10개의 JPEG 객체에 대한 참조를 찾음
  6. 그 이후에 참조되는 각 JPEG 객체에 대해서 처음  4단계를 반복함.
• 이 연결 과정 수행 예시에서 11개의 TCP 연결이 만들어짐.
• 대부분의 브라우저는 5~10개의 TCP 연결을 동시에 설정할 수 있음. (사용자가 원하는 경우 최대 동시 연결 수를  1로 만들 수 있음)

 

지속 연결 HTTP

• 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지함
• 전체 웹 페이지(앞 예에서 기본 HTML 파일과 10개의 이미지)를 하나의 지속 TCP 연결을 통해 보낼 수 있음.
• 이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들 수 있음(파이프라이닝Pipelining)