Application Layer

---

Network Application

Network application은 각기 다른 end system에서 모두 돌아갈 수 있도록 설계가 되어야하고 network를 거쳐서 통신이 가능해야한다. 그러나 application간의 소통이 중요한 것이지 software가 network-core devices를 위한 것이 아니기에 network-core에 적합하게 설계하지 않는다.

---

Application architectures

Apllication을 설계할때 가능한 구조는 client-server방식과 peer-to-peer(P2P)방식이 있다.

우선 client-server방식은 아래와 같이 server와 client가 정해져있어서 각각이 정해진 역할만 수행한다.

특징을 조금만 더 살펴본다면 client-server구조에서 server는 client가 언제 접근할지 모르기 때문에 항상 켜져있다. 또한 거의 영구적으로 고정적인 IP주소를 이용한다.

반면 client는 항상 켜져 있을 필요가 없고 동적인 IP를 가져도 상관이 없다. 동적인 IP를 갖는 것의 장점은 IP주소가 무한정 존재하는 것이 아니기 때문에 나눠서 사용할 수 있고 유동성이 높다는 점이다. 또한 client끼리는 서로 직접 연결할 수 없다.

 

다음으로 P2P 구조는 아래와 같이 peer간에 연결이 되어있는 구조이다.

우선 always-on server가 존재하지 않는다. end-system끼리 직접적으로 소통을을 하는 것이다. 따라서 확장성이 좋아서 다양한 조합의 network를 형성할 수 있다는 장점이 있다. 그러나 고정적인 IP가 없기 때문에 서로의 IP를 찾아서 network를 연결하기가 어렵다.

---

Process communicating

우선 process는 host가 실행중인 모든 프로그램을 의미한다. 예를들어 web창이 10개가 떠있으면 process가 10개가 실행중인 것이다. 같은 host에 대해서 두 process가 communication을 할 때는 OS로 정의되는 inter-process communication을 진행한다.

다른 host에 있는 두 process가 communication을 할 때는 message를 교환하며 이루어진다. 여기서 message는 application 수준에서 packet을 부르는 방식이다.

Client와 server의 역할에서 유추할 수 있지만 client process는 server에게 요청을 해야 하기에 communication을 시작하는 역할을 맡고 server process는 연결되기를 기다린다.

---

Socket

위에서 봤듯이 application layer 바로 밑에는 transport layer가 맞다아있다. 그 사이를 연결하는 것이 socket이다. 소켓은 응용 프로그램이 네트워크 서비스에 접근할 수 있게 해주는 추상화된 인터페이스이다. 보통 IP 주소와 포트 번호의 조합으로 식별된다. 응용 프로그램은 소켓을 생성하고, 해당 소켓을 통해 데이터를 전송하거나 수신한다.

Open API (Open Application Programming Interface)는 제3의 개발자들이 특정 응용 프로그램이나 플랫폼의 기능 혹은 데이터에 접근할 수 있게 해주는 API이다. Open API 자체는 소켓과 직접적인 연결은 없지만, 인터넷을 통해 외부 서비스에 요청을 보낼 때는 내부적으로 소켓을 사용한다. 예를 들어, 웹 애플리케이션에서 Open API를 호출하여 날씨 정보를 가져오려 할 때, 해당 애플리케이션은 내부적으로 소켓을 생성하고, 해당 소켓을 통해 서버에 데이터 요청을 전송하게 된다. 그 후, 서버에서 응답을 받아 해당 데이터를 애플리케이션에 표시하게 된다.

---

Addressing process

아래는 application이 communication하는 과정이다.

우선 client에서의 process들에는 OS가 Port Number를 지정해준다. IP가 성남시 분당구와 같은 큰 주소라면 process의 port number는 정자일로999 X동 XXXX호 와 같은 상세 주소라고 보면된다. 문제는 이 주소는 매번 바뀌기 때문에 server에게 communication 요청을 할때마다 요청의 출처를 상세히 담아서 요청해야한다.

이때 궁금증이 생긴다. Server의 process에 대한 port number는 어떻게 알고 communication 요청을 하는거지? Server의 process에 대한 port number는 고정이 되어있다. 예를들어 HTTP server는 80, mail server는 25이다.

 

Client는 web페이지에 naver.com이라는 도메인 이름만 검색하면 원하는 server의 IP와 원하는 process의 port number를 알지 못해도 원하는 페이지에 쉽게 접근할 수 있다. 이렇게 도메인 이름을 그에 일치하는 IP로 번역해서 찾아주는 protocol을 DNS(Domain Name System)이라고 한다.

---

App-Layer protocol

HTTP, FTP, SMTP와 같은 open protocol도 많이 있지만 이는 추후에 하나씩 다뤄보도록 하고 지금은 우선 기본적인 protocol을 살펴보자.

Message가 교환될때의 type들에 대한 protocol도 존재한다. 예를들어 request, response를 할때 어떤 message를 보내서 서로 알릴지와 같은 약속이 있다.

다음으로 아래 그림과 같이 message syntax에 대한 protocol인데 이는 message의 각 field가 어떤 의미를 담고 있을지 그리고 그런 field를 몇 bit씩 어떤 방식으로 경계를 지어줄지 등의 규칙이 담겨있다.

마지막으로 살펴볼 protocol은 message semantics인데 이는 기본적으로 00001이 무슨 의미인지와 같은 근본적인 message가 어떤 뜻인지에 대한 규칙이다.

---

Transport service

데이터가 전송되는데 각 application들 마다 service 요구사항이 다를 수 있다. 몇몇 조건들을 살펴보면 data의 신뢰성, timing, throughput, security등이 있을 수 있다.

위에서 볼 수 있듯이 file과 mail을 다루는 application은 데이터의 100% 정확성을 요구하고 시간이나 품질에 대해서는 비교적 유연한 것을 볼 수 있다. 내용이 정확하기만 하면 network에서의 delay는 ms단위이기 때문에 크게 상관이 없다는 것이다.

그러나 interactive game과 같은 application은 어느정도의 data loss는 허용이 되지만 동시에 상호작용해야하는 게임인 만큼 time sensitive가 중요한것을 볼 수 있다.

---

Transport protocol service

TCP는 다양한 역할을한다. Application의 집사라고 봐도 무방하다.

우선 transport는 오류를 잡아내고 오류가 해결될때까지 data를 재요청하여 무결한 data를 application layer에 올려보낸다.

다음으로 data flow에 문제가 생기면 속도를 맞춰주어 병목현상을 막아준다.

또한 network 수준에서 생기는 혼잡도 transport가 혼잡도를 낮출 수 있도록 돕는다.

그러나 timing, minimum throughput guarantee, security등은 제공하지 않는다.

---