네트워크 4강 - Application Layer의 소개

우리는 일상적으로 웹서핑을 하거나 보이스톡으로 대화를 하면서 게임을 한다. 이전의 포스팅에서 얘기했듯이 평소 사용하는 프로그램 대부분은 네트워크를 이용하는 애플리케이션이다.  그러므로 먼저 네트워크 애플리케이션 계층을 살펴보도록 하자.

 

---

클라이언트 - 서버 아키텍쳐

• 클라이언트란?
  • 클라이언트 프로세스는 서버로부터 서비스를 받는 프로세스이다. 예를들어 웹클라이언트( == 웹브라우저)는 웹서버에게 웹 서비스를 요청(Request)하고 웹서버로부터 응답(Response)을 받는다
  • 클라이언트는 서비스를 받는 입장이므로 당연히 클라이언트끼리 직접적으로 통신하지않는다.
  • 항상 켜져있을 필요도 없고 서버는 특정 클라이언트가 고유하게 누군지 식별할 필요 없으므로 고정된 IP가 필요없다.
• 서버란?
  • 서버 프로세스는 클라이언트에게 서비스를 제공해주는 프로세스이다. 예를들어 웹서버는 웹클라이언트에게 요청을 받아서 필요한 경우 Database나 다른 서버들과 통신하여 응답을 만들어 클라이언트에게 보낸다.
  • 클라이언트는 특정 서버를 고유하게 알고있어야 하므로 고정 IP를 가져야한다.(변동 IP도 가능하긴 하나 논외로 하자. 본질적으로는 고정 IP가 필요하다.)
  • 여러 클라이언트들이 언제든지 요청을 보낼 수 있기 때문에 항상 켜져있는 상태여야한다.
• 서버와 클라이언트의 구분
  • 서버인지 클라이언트인지 헷갈릴 때는 이렇게 구분하자.
  • 클라이언트는 통신을 시작하는 프로세스이다.
  • 서버는 통신을 기다리는 프로세스이다.
• 다른 호스트에 있는 프로세스들은 메세지를 교환함으로써 통신한다.

 

---

P2P 아키텍쳐

• P2P 아키텍쳐란?
  • P2P 아키텍쳐에 참여하는 어떤 호스트가 서버이기도 하고 클라이언트이기도 하는 아키텍쳐다.
  • 예를들어 P2P 파일 공유 서비스를 생각해보자. 한 사용자는 다른 사람으로부터 파일을 전송받기도 하고 동시에 다른 사람에게 파일을 전송해주기도 한다.
  • 항상 켜져있는 서버가 없고 사용자는 서버 역할을 동시에 하므로 사용자가 늘어나면 동시에 서비스할 수 있는 능력(Capacity)도 늘어나는 Self-Scalability한 특징을 가진다.
  • 임의의 Endsystem을 peer라고 한다.
  • 당연히 관리가 복잡하다.

---

소켓, Socket

• 잠깐 복습하자면 인터넷 계층은 애플리케이션-전송-네트워크-링크-물리 계층순이다.
• 소켓이란 계층간의 인터페이스이다.

포트, Port

• Multi-Programming OS에서는 한 호스트에서 여러 프로세스가 실행중일 수 있다.
• 포트(Port)는 여러 프로세스 중 통신하고자 하는 프로세스를 구분하는 ID이다.

---

 

애플리케이션마다 원하는게 달라!

• Application마다 제각기 목적이 있다. 예를들어 멜론은 오디오 재생이 목적이고, 카카오톡은 메세지 전송이 목적이다.
• 목적이 다르면 요구하는 성능도 다르다. 세가지 측면에서 살펴보자.
• Data Integrity
  • File Transfer는 예민하다
  • Audio는 순간적으로 잡음이 발생도 큰 문제는 아니다.
• Timing
  • Game은 예민하다.
  • File Transfer는 덜 예민하다.
• Throughput
  • Streaming은 최소한의 프레임이 유지되어야 하므로 예민하다.
  • File Transfer는 당연히 덜 예민할 것이다.

---

인터넷 Transport 계층의 두 프로토콜, TCP와 UDP

• Transport 계층은 후에 자세하게 다루므로 여기서는 간단히만 알아보자.
• TCP : Transmission Control Protocol, 말 그대로 전송 제어를 담당하는 프로토콜이다.
  • 믿을만한 (reliable) 전송을 보장해준다.
  • Flow, Congestion Control을 제공해준다.
  • Connection Oriented : 서로 커넥션을 맺고 통신한다.
  • Timing, min throughput, security는 보장하지 않는다.
  • 기능이 많은 많큼 Overhead도 크다.
• UDP : User Datagram Protocol, TCP와 달리 Control이 들어가있지 않다.
  • Unreliable한 전송을 한다.
  • Flow, Congestion Control 없이 최선을 다해서 전송한다.
  • Application 계층에서 Integrity를 체크하는 경우 UDP를 사용한다.
  • 최선을 다해서 전송하므로 Real Time에 적합하다.
  • http 3.0은 UDP를 사용한다.

---

Application-Layer Protocol

• 무엇을 정의하나?
  • 메세지의 타입
    • 이 메세지가 서버에게 요청을 보내는 Request인지
    • 서버의 응답인 Response인지 구분한다.
  • 메세지의 문법(Syntax)
    • 메세지를 몇비트씩으로 쪼개서 그 부분엔 어떤 필드를 넣을까?
    • 예를들어 메세지의 첫 1비트는 메세지의 타입을 명시하자!라고 정할 수도 있다.
  • 메세지의 의미(Sementics)
    • 그래서 이 처음 1비트의 1과 0이 Request야 Response야?
    • 무슨 의미인지 정의한다.
  • 전송, 응답 규칙
• Web과 Http 프로토콜
  • Web은 World Wide Web (www)의 약자로서 인터넷 상에서 동작하는 정보교류 서비스이다. 
  • Http 프로토콜은 Web이 사용하는 프로토콜이다.
  • Web 페이지는 URL(Universal Resource Locater)로 연결된 Html 파일, 자바스크립트, 이미지 등으로 구성되어 있다.
  • 이런 웹페이지를 구성하는 항목들을 Object라고 한다.
  • 웹페이지는 Base Html파일 아래 여러 오브젝트들이 연결된 형태다.
• Http의 개괄적인 내용
  • Http는 Web상에서 정보(문서)를 주고받기 위한 프로토콜이다.
  • 문서 전송도 File Transfer이므로 앞에서 얘기했듯이 Data Integrity가 Critical하게 중요하다!
  • 그러므로 UDP가 아닌 TCP를 이용한다. (http 3.0은 최적화를 위해 UDP를 사용한다.)
  • Http 자체는 Stateless하다
    • 예를들어 로그인 상태가 유지되는 것이 아니라 매번 로그인을 해야한다고 생각하자
    • 쿠키를 사용해서 session-id로 stateless한 특성을 보완할 수도 있다.
  • Non-persistent http VS Persistent http
    • 한번 맺어진 tcp 커넥션을 재사용 하냐 / 안하냐의 차이다.
    • Non-persistent는 Base Html파일에 담겨진 Object마다 새로 TCP연결을 맺어 가져와야하므로 성능저하가 크다.
    • 다음 글에서 조금 더 자세히 다루겠다.

 

 

 

 

본 게시물은 kocw 이화여자대학교 이미정 교수님의 컴퓨터 네트워크 강의를 듣고 정리한 글임을 밝힙니다.

내용상 틀린 부분이 있을 수도 있으며 이에 대한 책임을 지지 않습니다.

틀린 부분이나 오타 지적은 댓글로 남겨주세요.

www.kocw.net/home/cview.do?cid=e44bdd9b3a3f9bb5