01. Application Layer

 00 부분에서 전반적인 이야기를 잘 다루었으니 이제 하나씩 하나씩 이야기를 해보자!

 저번에 이야기 했듯이 컴퓨터에는 여러 어플들이 동시에 돌아가고 있다는 사실! 그리고 이 어플들을 프로세스라고 한다. 계산기 어플이 있을 때 1+1 과 2+2 는 다른 결과를 낸다. 같은 어플이라도 인풋 값이 바뀌거나 조그마한 설정 하나만 다르게 되면 다른 프로세스라고 보면 된다. 물론 1+1을 두 번 하면 같은 프로세스? 아뇨아뇨 다른 프로세스. 그니깐 어플은 실행 틀이고 실제 실행 중인 것을 프로세스라고 생각하면 된다. 마치 클래스와 객체 관계처럼.. 아무튼 이 이야기를 왜 했을까? 눈치 챘다면, 프로세스가 바로 application layer의 산물이라 생각하면 된다. 참고로 프로토콜은 대화 방식 규약이라고 생각하라.

 

1. 역할과 종류, 단어

 일단 알아야할 단어로는 프로세스가 있었고 port 개념이 있다. port를 이야기 하자면, 하나의 컴퓨터에 여러 프로세스가 돌아간다고 했다. 프로세스간 통신에서 상대방 컴퓨터를 간 다음에 어느 프로세스로 들어갈지 테이블 같은 것이 존재해서 port 번호가 80이면, 아 이 정보는 저 프로세스에 전달 되면 되는 구나! 라고 깨닫기 위해 이용한다. 

 

Application Layer에서 정보를 주고 받을 때 message단위라고 부른다. 

 주로 두 개의 message가 존재한다. 요청 메시지, 응답 메시지. 말 그대로 요청 메시지를 클라이언트에서 서버로 가면 서버가 클라이언트에게 그에 응하는 응답 메시지를 주면 된다. 주 예시로서는 HTTP, FTP, SMTP 등등이 있다. 얘들 뭐냐고? Application Layer의 삼대장 프로토콜이라고 여기면 된다. 이제 이 삼대장과 Socket에 대해 이야기 해보자.

 

 휴 마지막으로 UDP와 TCP 가 있다. 이 둘은 두 어플리케이션이 메시지를 어떠한 방식으로 통신할지 정하는 것이다.

무슨 사전 준비가 이렇게 오래 걸리나 싶지만,, 다 쓸모가 있으니.. 힘내고! 컴퓨터가 서로에게 정보를 주고받을 때~~

 TCP는 서로 이 경로로 이야기 할거야! 라고 정한 상태에서 msg를 주고 받는다. 그래서 두 컴퓨터는 지속적으로 연결되어 있고 msg들이 순서대로 전달 된다. 그 후 정보가 다 잘 전달 되면 합의 하에 연결을 끊는다. 그니깐 기차처럼 쭈루루룩 연결 되어서 정해진 경로로만 딱딱 움직인다.

 UDP는 그냥 msg를 밀어 넣어 버리고 나몰라라 해버린다. 그럼 이 똑똑한 msg들이 (사실 msg가 똑똑한 건 아니지만) 누구는 버스 타고 누구는 로켓타고 누구는 대포가 날려주는 자기들만의 방식을 통해서 상대방에게 도착한다. 그럼 상대방은 순서성 없이 누구는 빨리 오고 누구는 늦게온 이 난감한 상황을 똑똑하게 잘 순서를 끼워 맞추어 정보를 받아낸다.  이 두 프로토콜은 사실 transport layer에서 엄청 자세히 다루게 되는데.. 5계층 설명하는데 필요하다. 여기까지 사전 정보 정리 완료! 이제 잠깐 스트레칭하고...읏차

 

2. HTTP

 너무너무 익숙한 단어 http. 맞아 그 http 다루는 거다. http는 당연히 웹 브라우저에서 많이 보았을 것 같다. 간단하게 http는 웹페이지를 요청하고 받아서 띄우는 프로토콜이다. 클라이언트가 HTTP를 이용하여 요청 메시지를 보내고 응답 메시지를 받으면 웹 페이지를 보여준다. 서버는 이 응답 메시지에 들어갈 object들을 구성해준다. 

 http는 TCP 방식으로 소통하고 port번호는 80이다. 또한 서버는 클라이언트의 이전 정보들을 저장하고 있지 않다. 어? 근데 우리 쇼핑몰 같은 곳 가면 실수로 누른 상품이 창 닫을 때 까지 집요하게 쫒아오는 경험은 뭐야?! 이것은 쿠키라는 것이 담당한다. 

 

2-1. Web caches(proxy server)

HTTP 메시지들은 사실 중간 톨게이트인 proxy server라는 녀석이 있다. client1이 origin server에 요청한 HTTP msg에 대응한 HTTP 응답 메시지를 잠시 관리하고 있는데 이 타이밍에 운좋게도 client2가 똑같은 정보를 요청하게 된다면 proxy server에서 origin server로 가지 않고 자기가 응답 

메시지를 보내준다. 수치적으로 계산하면 너무 깊게 들어가니 그냥 말해주자면 이것 덕에 네트워크 상에 있을 delay를 상당히 낮추어 준다.

 

 

 

 

 

 

3. DNS

 도메인 네임 서비스.. 꽤 유명한 단어이다. 사실 우리가 naver라고 주소창에 치면 진짜로 naver 문자열을 인식하는 것이 아니라 naver에 맞는 여러 주소 값들 중 하나로 변경해 주는 서비스이다. 그리고 이 주소들은 그 유명한 IP주소를 칭하는 것이다.

 이때 그 IP주소를 던져주는 방식이 크게 두 가지가 있다. 이 방식들일 이야기 하기전에 계층 개념이 필요한데 아래 그림과 같다.

DNS 계층 구조

 가장 위에가 Root DNS Server이고 마지막에 .com 이라던지 .edu 처럼 뭐로 끝났느냐로 나뉜다. 이 계층을 TLD 계층이라고 부른다. 그 밑은 Authoritiative name server라고 부르고 우리가 최종적으로 찾는 IP주소가 되겠다.

 이 계층 구조를 통해 우리는 IP주소를 얻어 올 수 있는데 이 IP 주소를 얻는데 가장 중요한 역할을 해주는 것이 Local DNS server이다. 우리는 항상 인터넷이 접속 할 때마다 이 server를 무조건 거친다는 사실을 알았는가!

 여기에는 두 방식이 있는데, Local DNS server가 root->TLD->authoritiative 순서로 재귀적으로 탐색할지 반복적으로 탐색할지로 나뉜다. 아래 두 사진중 왼쪽이 재귀이고 오른쪽이 반복적으로 탐색할 경우이다. 

  이러한 방식을 쓰는 이유는 만약에 각 DNS 서버에서 이미 목적지 IP 주소를 알고 있다면 바로 리턴한다. 만약 애초에 local이 목적지를 들고 있었다면 바로 리턴하는 거고 local이 없다면 위에서부터 차례로 물어보는 것이다. 중간에 IP주소를 안다? 그럼 바로 리턴 해서 탐색이 종료된다.

 

4. FTP

 File Transfer Protocol의 준말. 말 그대로 파일 주고 받기 하는 것에 쓰이는 프로토콜이다. 이 녀석도 TCP를 사용하고 신기하게도 두 개의 포트번호 20, 21을 사용한다. 클라이언트는 21번 포트번호로 연결을 요청하고 서버와 클라이언트는 20번으로 정보를 주고 받는다. 이후 정보 주고 받기가 다 끝나면, 연결을 끊는다(TCP..). 그러하니 새로운 파일을 주고 받으려면 다시 연결하고 주고받아야 겠지?!

 

5. SMTP

 이 프로토콜도 마찬가지로 TCP를 이용하고 포트 번호는 25번이다. 메일을 주고 받는 과정은 다음과 같다.

프랑스 얼음왕자가 스페인 공주에게 메일을 보내게 되면 왕자의 mail server의 message queue에 저장된다. 왕자의 mail server가 공주의 mail server와 SMTP를 이용하여 TCP 연결을 한다. 연결이 성공하면 메일을 보내게 되고 공주의 mail server의 mailbox에 저장된다. 공주가 mail 프로그램에 접속하면 mail server가 메일이 왔다고 띄운다.

 

6. Socket!

 socket.. socket..  바로 socket이 각 프로세스마다 하나씩 배치 되어 있다고 생각하면 된다. 

노란색 네모가 바로 socket!

   오른쪽 그림에서 노란색 부분을 socket이다. 이 socket을 통해 메시지가 transport layer로 나가게 되는데 이때 주로 두가지 버전을 선택한다. 바로 TCP vs UDP. 앞선 예시를 보면 알 수 있는 점이 있었다.

 TCP의 경우 두 host 간의 연결과 경로를 설정하는데 이 작업을 conntection set-up이라고 그러고 그 종류 중에 하나인 3-way hand shaking이라는 방식을 쓴다. 이것은 다음 글에..

 UDP의 경우 연결을 설정하지 않고 단지 목적지의 IP주소와 port번호만 msg들에게 각 msg들이 자신들의 편한 방식에 맞게 움직이게 된다.

 아무튼 원래는 transport layer에서 자세히 다루기로 했는데 왜 막바지와서 심란하게 언급하냐면,, socket과 관련해서 짚고 넘어 갈 것이 하나 있다.

 서버 입장에서 TCP연결 요청이 들어오면 서버는 계속 새로운 socket을 만들어서 연결 요청한 클라이언트와 소통을 한다. 반면 UDP는 하나의 소켓만으로도 서버가 여러 클라이언트의 요청을 처리할 수 있다. 여기까지 보면 UDP > TCP인 것처럼 보이지만 아마 다음 글에서의 비교를 통해 UDP가 무조건 좋은게 아니구나~~ 라는 것을 일깨워 주겠다.