2. Application Layer(Basic+HTTP)

Key Words

- Internet protocol stack
- client-server
- peer-to-peer(P2P)
- HTTP

0. Intro

 

Internet은 계층적 구조를 가지고 있다. 'Internet protocol stack'은 다음과 같다.

application layer

transport layer

network layer

link layer

physical layer

또한 'ISO/OSI reference model' 에서는 application layer을 조금 더 세분화 하여 application, presentation, session으로 나눈다. 우선 이렇게 계층적인 구조를 띄는 이유는 무엇일까? Java, C#과 같은 객체 지향언어에서의 키 포인트는 바로 abstraction이다. 사용자가 실제 어떻게 돌아가는지는 모르지만 목적을 달성하는데 도움을 주는 객체를 사용한다. 인터넷 계층도 비슷한 맥락에서 이해할 수 있다. 복잡한 시스템을 필요로하는 인터넷 통신에서, 각각 역할을 세분화하고 관계지을 수 있다. application layer는 transport layer의 "지원"을 받아서 작동하며, 이와 마찬가지로 transport layer는 network layer의 "지원"을 받는다. 서로의 계층 사이에 인터넷 통신에 필요한 간단한 정보 정도는 오갈 수 있어도 서로가 어떻게 일을 처리하는지에 대한 간섭은 하지 못 한다. 이에 따라서 transport layer에서 새로운 기술이 도입되면 transport layer만 수정하면 되는 유지 관리, 시스템 업데이트 측면에서도 유리하다. 이제 각 계층의 역할을 간단하게 살펴보자.

 

--> application layer: 네트워크를 사용하는 애플리케이션을 지원해주는 계층 (HTTP, SMTP, FTP)

--> trasnport layer: process와 processt사이의 통신을 담당해주는 계층 (TCP, UDP)

--> network layer: 라우터 단위에서의 라우팅을 담당하는 계층, 시작<->끝 (IP, routing protocols)

--> link layer: 네트워크 내에서 인접한 네트워크 단위 사이의 통신을 담당하는 계층, 한 점 <-> 한 점 (802.11, Ethernet, PPP)

--> physical layer: 실제로 데이터가 이동되는 bit단위를 다루는 계층

 

오늘은 이 중 가장 사용자와 가까운 단계, 우리가 생활 속에서도 쉽게 접할 수 있는 단계인 "Application Layer"에 대해 간단히 살펴보자.

 

1. Models of Application layer 

application layer에서 사용되는 protocol들은 router 같은 network-core device에대해 신경 쓸 필요가 없다. 서로 다른 end-system사이를 네트워크를 통해 연결해주는 역할을 하는 계층으로, 흔히 사용하는 크롬, 사파리, 또는 앱이라면 페이스북 앱, 유투브 앱 같은 것들이 있을 수 있겠다. 한 가지 예를 들어보자. 유투브에 접속을 하여 플러리 관한 영상을 찾는다고 예를 들어보자. 플러리 관련 영상은 내 컴퓨터에 미리 저장된 것이 아니기 때문에 어디선가 가져와야 된다. 당연히 네트워크 넘어에서 가져오게 될텐데, 그렇다면 그 영상은 누가 제공해주는 것일까? 이에 대한 답을 다음과 같은 2개의 모델을 제시하여 설명한다.

• Client-Server Model
  
  Client-Server 모델에서 end-point는 크게 2개로 나뉜다. Server, Client. Server는 항상 켜져있으며, 영구적인 IP주소를 가지고 있는다. 여기서 영구적이라는 것은, 서버면 무조건 영구적이다! 가아닌, 서버라면 계속 같은 IP를 가지고 있어야 계속 Client가 들어올 수 있다는 뜻이다. 또한 client 수의 증가에 따른 대처도 필요하다. 나머지 end-point는 client인데(어떤 경우 server, client역할을 둘 다 할 수 있는 것도 있다)이는 server로부터 제공된 데이터를 받아 사용하는 것이다. client의 경우 다양한 IP주소를 가질 수 있으며 , Client-Server 모델의 가장 큰 특징 중 하나인 client 사이의 의사소통이 불가능하다. 즉, 카카오톡과 같은 application도 사실은 우리가 상대방의 폰으로 메세지를 보내는 것이 아닌, 카카오톡 서버로 메세지를 보내고 다시 카카오톡이 그 메세지를 상대방에게 전달하는 것이다. 
• Peer-to-Peer (P2P) Model
  
  Peer-to-Peer 모델은 말 그대로 동급자와 동급자 사이의 의사소통을 중심적으로 통신한다. 서버가 따로 존재하지 않고(이론상이며 보통 존재는 한다. 하지만 Client-Server 모델에서의 서버와는 다른 역할을 한다) end-system끼리 통신을 하는 것이다. 한때 큰 인기를 끌었던 토렌트와 같은 애플리케이션의 경우에도 P2P를 사용하였다. 나의 컴퓨터가 서버가 될 수 있고 동시에 client도 될 수 있는 것이다.

2. HTTP

 

특정 web페이지에 접근을 하려고 한다. 예를 들어 www.google.com이라고 해보자. 하나의 web page안에는 우선 HTML과 같은 마크업 랭귀지로 web페이지를 표현하는 object가 있을 것이고, web page에 사진이 들어간다면 사진도 object로 포함될 것이다. 이처럼 하나의 web page는 다양한 object로 구성되어 있다고 할 수 있다. HTTP는 Hyper Text Tranfer Protocol로, 우선 protocol이니까 어떤 약속이란 뜻일 것이고, Hyper Text는 HTML의 Hyper text mark-up language에서 유추해보면 다른 text또는 webpage로 이어지는 hyper link를 담고 있는 text라는 것을 알 수 있다. 즉, webpage안에 있는 내용을 전송할 때 사용하는 규칙으로 이해할 수 있다. HTTP protocol같은 경우는 앞에서 살펴본 Client-Server모델을 사용한다. HTTP에 대한 특징을 몇 가지 살펴보자

• HTTP는 TCP를 사용한다. (HTTP/3이전)
  application 아래 단계에서의 transport protocol 중 더 reliable 한 TCP를 사용한다. TCP의 경우 overhead가 있지만 data integrity가 지켜진다는 점에서 HTTP에서 사용된다. client는 socket을 만들어서 server와 TCP connection을 시도한다. server 에서 대기 중이던 socket은 이 connection을 받아들이고 연결이 성사되었다고 response를 보낸다. 
• HTTP는 기본적으로 stateless하다.
  Stateless하다는 것은 server 에서 client에 대한 정보를 저장하지 않는다는 뜻이다. 즉, 내가 쿠팡에 접속하여 장바구니에 무엇을 담고 무엇을 검색한 뒤, 웹 브라우저를 닫았다가 다시 켜서 쿠팡에 접속하면, 즉 TCP connection이 끊어졌다가 다시 이어지면 과거의 기록은 남지 않는다는 것이다. 이는 기본적인 상태이지만 제한된 경우에는 이를 기억하게 해주는 것이 존재하는데 그것이 바로 쿠키이다. 이는 뒤에서 더 자세히 설명하겠지만, server가 특정 client를 기억하게 도와주는 것이다.
• Persistent 와 non-Persistent HTTP가 존재한다.
  non-Persistent HTTP는 하나의 object를 보내고 TCP connection이 끊어지는 것을 뜻한다. HTTP version 1(1996)은 이것을 사용하였다. 반대로 persistent HTTP는 하나의 TCP connection으로 여러개의 object를 보낼 수 있게 되었다. 여기서 오는 overhead를 계산해볼 수 있다.
  우선, Client와 Server사이에 연결을 하기 위해 Client가 initiate을 해야 되고, 이에 대한 accept를 server가 해준다. 이렇게 왔다 갔다 하는 것을 "handshake라고 하며, 이렇게 연결이 된 이후에 다시 Client가 request를 보내고, 이에 대한 response를 서버가 해주는 것이다. 이때, 한번 client에서 작은 packet이 server까지 갔다가 오는데 걸리는 시간을 RTT(round trip time)이라고 한다. HTTP의 Response timed은(non-persistent)따라서 2*RTT+Transmission time(server에서 response로 보내주는 object를 보내는 데 걸리는 전송 시간) 이 된다. 이때 object의 수가 증가하게 되더라도 매번 handshake을 해야되기 때문에 overhead는 점점 커지게 된다. 반면, persistent connection을 맺은 경우에는 처음에 한 번 handshake를 진행하면 되기 때문에 큰 시간 절약을 할 수 있다. 

3. HTTP 통신(및 입력) 방법

이번에는 앞에서 간단하게 짚고 넘어갔던 request와 response에 대해 알아보도록 하자. request와 response는 HTTP message의 두가지 종류로 ASCCI,즉 단순 문자열의 메세지이다. 

• Request Message
  Request Message는 우선 request line과 header lines로 시작을 한 뒤 body가 시작한다. Request line은 method, UR, version(HTTP)등으로 구성이 되어 있다. 여기서 Method에 대해 알아볼 수 있는데. 대표적으로 GET과 POST가 있다. POST의 경우 body에 server로 넘겨줄 입력을 포함하고 있다. GET의 경우 가장 많이 사용하는 method로 server로 부터 object를 요구할 때 사용한다. GET의 경우 입력을 넘겨줄 때 URL을 사용하는데, '?'뒤에 있는 것을 입력 형식으로 가진다. 이렇게 입력을 넘겨주는 방식의 차이에서 Bookmark, cache 가능성, 보완성에 연관이 된다.
  non-persistent HTTP만을 사용하던 HTTP(1.0)당시에는 GET, POST, HEAD3개의 method만이 존재했다. 이후 1.1version부터는 GET, POST, HEAD, PUT, DELETE로 2개가 추가되었다. 
• Response Message
  Response Message는 Client가 보낸 Request Message에 대한 답변으로 status line, header line, data(requested object)로 구성이 된다. Response message의 가장 중요한 부분은 바로 status line에 들어가는 response status code이다. 다들 한번쯤 브라우징을 하다가 '404 not found'메세지를 본적이 있을 것이다. 이러한 것이 바로 response status code로, 말 그대로 response가 어떠한 상태인지 보여주는 것이다. 대표적으로
  --> 200 OK: 이는 우리가 자주 보지 못한다. 정상적인 결과임으로 가져온 object를 보여줄 것이다.
  --> 301 Moved Permanently: request한 object가 영원히 사라짐
  --> 400 Bad Request: request message를 server가 이해하지 못 함
  --> 404 Not Found: server에서 request한 data를 찾지 못 함
  --> 505 HTTP version not supported: 제곧

사실 이렇게 개념적인 부분만 짚고 넘어가면 쉽게 와닫지 않을 수 있다. 직접 request를 살아있는 서버에 보내본 뒤, 어떠한 request가 오는지 확인해보자. "Talnet"이라는 프로그램을 사용할 것인데, 이는 웹 브라우저와 비슷하게 TCP connection을 이어주지만 웹 브라우저 처럼 추가적인 처리는 해주지 못 한다. Macbook에서는 기본적으로 설치가 되어있지 않으며, Window의 경우 권한을 부여해주어야 실행이 가능하다. 

간단하게 talnet www.google.com 을 실행해보면 연결이 되었다는 문구가 뜰 것이고, 여기에 Request Message의 request line에 해당하는 부분만(이 부분만 있어도 request message는 유효하다)입력해서 보내면 200 ok라는 response status code가 돌아오는 것을 알 수 있다. (추후에 되면 사진 첨부해보겠다)

 

4. cookie, web cache

• Cookie
  앞에서 HTTP protocol은 stateless하다고 하였다. 하지만 우리는 네이버에 '로그인 접속 유지' 또는 무신사에 로그인을 하지 않고도 들어가서 몇개의 옷을 보다가 잠시 뒤 다시 들어가도 최근 본 목록에 있는 것을 볼 수 있다. 분명 TCP connection은 끊어졌으며 server는 우리를 기억할 수 없을 것이다.
  쿠키에 대해 알지 못하던 시절에는 단순히 '웹 브라우저'에서 내 아이디와 비밀번호를 특정 사이트마다 저장하여 해당 웹 페이지에 접속할 때 자동으로 로그인 정보까지 보내주어 로그인까지 완료하는 것이라고 생각했으며, 로그인한 유저에 따른 server가 client를 구분한다고 생각했다. 그리고 이 생각 또한 아직 맞는 것 같다.
  하지만 그런 경우도 있는 것을 알 수 있다. 아이디와 비밀번호를 저장하지 않았지만 짧은 시간에 웹 브라우저를 껐다가 킨 경우 접속이 유지된 적이 있을 것이다. 이렇게 서버에서 클라이언트가 누구인지에 대한 작은 힌트들이 바로 쿠키이다. 이는 웹 브라우저에 저장되며 서버 쪽에서도 해당 쿠키에 대응하는 내용을 데이터베이스에 저장하고 있다. 다음에 똑같은 쿠키 ID로 서버를 접속하게 되면, cookie specific action을 실행하게 되는 것이다.
• Web  Cache
  web cache(다른 말로는 proxy server)는 서버와 클라이언트 사이의 통신 overhead를 줄여준다. 즉, client의 request가 origin server까지 갔다오지 않아도 response를 보낼 수 있게 해준다. 앞에서 슬쩍 넘어갔지만 response message에는 해당 object가 마지막으로 언제 수정되었는지도 알려준다. client에서 request 를 보내면 우선 proxy server로 해당 request가 간다. proxy server는 해당 request에 대한 response할 내용을 담고 있는데, 만약 caching 되어 있는 Object가 out of date라면 결국 origin server까지 가서 object를 가져오게 된다. 이름 그대로 caching을 해놓은 것이다. 보톤 ISP(internet service provider)에서 설치를 하며 이를 토대로 response time을 줄이고 내부망과 외부망 사이의 trafic을 줄이는 기능을 한다. 
  이때, proxy server에서 origin server로 보내는 request에 대한 response에 만약 원하는 Object가 unmoidified라면 response status code로 "304 Not Modified"라는 코드를 반환한다. 

5. 정리

 

오늘은 간단하게 Application layer의 protocol 중 하나인 HTTP에 대해서 살펴보았다. 지금 당장 사용하는 웹 브라우저의 위에 URL주소창을 보면 가장 앞에 "http"가 붙어있다. 이만큼 많이 사용하는 protocol이며 이에 대해 더 자세히 공부할 필요가 있을 것 같다.