[Network] Application Layer - 소켓, 프로토콜과 DNS

Application Layer

TCP/IP 네트워크 프로토콜 스택에서 가장 상위 레이어를 담당하고 있는 부분이 Application Layer이다. 이 계층에서는 이름에서 알 수 있듯이 host(=end system)들에게 직접적으로 여러가지 서비스를 제공하거나 받는 역할을 한다.

우리가 사용하는 수많은 네트워크 어플리케이션들(이메일, 웹, 원격로그인, 디스코드....etc)에서 제공되는 기능들은 모두 가장 먼저 이 계층을 거친다.

 

 

Application Architectures

ㆍClient-Server

클라이언트-서버 구조에서 서버는 host가 되어 항상 서버를 항상 제공해야 하고, 고정된 IP주소를 갖는다. 클라이언트는 필요할 떄 서버와 통신하여 필요한 정보를 주고받는다. 또한 클라이언트끼리 통신하는 것은 불가능하다.

ㆍPeer-to-peer

네트워크에 연결된 모든 컴퓨터들이 대등한 입장에서 데이터를 공유하는 방식이다. 항상 동작하는 서버가 존재하지 않고, peer라고 불리우는 다수의 개별 사용자들끼리 request-response를 이용한 직접 통신 방법으로 서비스를 주고받는다.

ㆍHybrid

Instant messaging이나 skype등에서 사용되며, client끼리의 통신이 가능하지만 서버가 존재하여 클라이언트의 현재 상태 등이 저장되는 형태가 대표적이다.

 

 

 

Socket

어플리케이션 계층의 하위 4계층은 OS가 관리하고 있기 때문에, 개발자는 단순히 어플리케이션 계층에서 생성되는 메세지를 전달해주기만 하면 된다. (간단하게 프로그램의 전달을 통해서 통신하는 것이 아니라, 두 개의 서로 다른 최종 시스템의 프로세스가 컴퓨터 네트워크를 통해 메세지를 교환하여 통신한다) 이때 프로세스는 네트워크로 데이터를 송/수신하기 위해서 소켓이라는 인터페이스를 이용하여 메세지를 주고 받는다. 

소켓은 프로토콜, IP주소, 포트번호로 정의된다.

ㆍ프로토콜 : 시스템간의 통신 규약

ㆍIP주소 : 고유 식별 주소

ㆍ포트번호 : 통신을 위해 같은 호스트 ip 내에서 프로세스가 할당받는 고유 숫자.

 

포트번호는 네트워크 상에서 통신하기 위해서 호스트 내부적으로 프로세스가 할당받아야 하는 고유한 숫자이다. 한 호스트 내에서 네트워크 통신을 하는 프로세스를 식별하기 위해 사용되는 값으로, 같은 호스트 내에서는 프로세스마다 각기 다른 포트번호를 가진다. 

 

 

Web Socket

(앞서 설명한 소켓과는 구분되는 용어이다)

 

웹 소켓은 HTTP가 실시간 통신이 어렵다는 문제를 해결하기 위해서 나온 기술이다. HTTP는 헤더의 크기가 크고, 단방향 통신만을 지원하기 때문에 실시간으로 많은 데이터를 주고 받기에는 한계가 존재한다. 따라서 웹 소켓 이전에는 서버로 일정 주기로 요청을 보내고 응답을 받는 Polling, Streaming과 같은 기술을 사용했다. 하지만 이 역시 real-time의 예측불가능성 때문에 불필요한 request를 발생하게 된다.

 

웹 소켓은 이러한 HTTP의 단점을 보완하면서 HTTP 위에서 작동하며, 실시간 통신이 필요한 경우 잘 쓰이는 프로토콜 중 하나이다. 웹 소켓은 다음과 같은 특징들을 가진다.

 

1. 양방향 통신 (Full-Duplex)

 웹 소켓은 양방향 통신을 지원한다. 즉, 클라이언트와 서버가 서로에게 원할때 데이터를 주고 받을 수 있다.

2. 실시간 서비스

 채팅, 비디오 데이터와 같이 연속된 데이터를 빠르게 노출시켜 주어야 하는 서비스에 적합하다.

3. TCP 기반

 웹 소켓은 TCP 기반으로 동작한다. 따라서 핸드쉐이킹을 통해서 연결을 수립한 후 통신한다.

4. Web Socket Handshaking

 최초에는 클라이언트와 서버가 HTTP 기반의 handshaking을 맺고, 성공했다면 http/https 대신 ws/wss로 프로토콜을 변경한다.

5. 프레임, 메시지

 웹 소켓은 메시지라는 단위로 통신하는데, 이 메시지는 프레임이라는 작은 단위로 분할되어 전송될 수 있다.

 

 

 

 

 

Web과 HTTP

HTTP(HyperText Transfer Protocol)은 텍스트 기반의 통신 규약으로, 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다. HTTP는 클라이언트가 브라우저를 통해서 서비스를 request하면 서버가 response하는 형태로 동작한다.

(Client-Server 구조) 

Clint : Server에 request
Server : Client에 response

HTTP는 TCP/IP를 이용하는 응용 프로토콜이며, 무상태(stateless), 비연결형(connectionless)이라는 특징을 가진다. stateless하다는 것은 서버가 클라이언트의 이전 상태와 정보를 보존/저장하지 않는다는 의미이며(저장이 필요할때는 쿠키와 세션을 이용한다) 서버 입장에서는 동일한 클라이언트의 요청이라도 각각의 요청을 독립적으로 받아들인다. 비연결성은 서버와의 request-response가 종료되면 바로 TCP/IP연결이 종료된다는 것이다. 이를 통해 서버의 resource를 효율적으로 관리할 수 있게 된다.

 

ㆍRTT(Round Trip Time)

RTT는 패킷망 위에서 패킷을 목적지에 보낼 때 패킷이 목적지에 도달하고 나서 응답이 다시 출발지로 돌아오기까지의 시간을 이야기한다. 

ㆍHTTP 응답코드

1XX : 조건부 응답
2XX : 성공 (200:OK)
3XX : 리다이렉션 완료 (301:Moved Permanently)
4XX : 요청 오류 (400:Bad Request, 404:Not Found)
5XX : 서버 오류 (505:HTTP Version Not Supported)

 

ㆍ쿠키

stateless한 HTTP의 stateful한 사용을 위해서 서버가 사용자의 웹 브라우저에 전송하는 데이터 조각을 의미한다. 쿠키는 클라이언트에 저장되며, 이름, 값, 만료시간, 경로 정보와 같은 정보들이 들어있다. 

 

 

 

FTP

 FTP(file transfer protocol)은 말 그대로 프로토콜의 일종인데, 파일 전송을 위한 프로토콜을 의미한다. FTP의 연결 설정을 위해서는 2개의 채널(port 20, 21)이 필요하다. 각 채널은 control connection, data connection으로 control channel(명령 채널)은 어떤 파일에 액세스할 수 있는지나 사용자 계정 등의 기본 정보를 전달하는 역할을, data channel(데이터 채널)은 파일 데이터를 송수신하는 채널이다. 이와 같이 전송과 제어를 위한 별도의 connection을 갖추는 방식을 out-of-band방식이라고 한다. 제어를 위한 21번 포트는 클라이언트와 서버의 접속이 유지되는 동안 연결되어있지만, 20번 포트는 파일을 주고 받을 때만 연결이 이루어진다.

 

 

 

SMTP

 애플리케이션 계층에는 이메일을 위한 SMTP라는 프로토콜이 있다. 대부분의 인터넷 시스템은 사용자간에 메일을 전송하는 방법으로 TCP를 이용한 SMTP를 사용한다. 포트번호 25번을 사용한다. 

 

 

user A가 user B에게 메일을 보내려고 한다고 하자. A는 A가 속한 메일 서버로 메일을 발송한다. 메일 서버의 큐에 A의 메세지가 enqueue되고, 큐에서 메세지는 B가 속한 메일 서버로 전송된다. 이때 SMTP가 사용된다. 그리고 B가 속한 메일 서버는 B의 mailbox에 메일을 넣어주고, B는 로그인 후에 서버에서 도착한 메일을 확인할 수 있다.

 

 

 

 

DNS

Domain Name System(DNS)는 도메인 주소를 IP주소로 변환한다. 인터넷상의 모든 컴퓨터는 IP주소를 이용하여 통신하는데, IP주소는 32비트의 긴 숫자이기 때문에 기억하기 쉽지가 않다. 따라서 사용자의 편의를 위해서 도메인 주소(ex. www.naver.com)와 같은 형태로 접근하게 하는데, 이러한 도메인 주소를 IP주소로 변환해주는 역할을 DNS가 한다.

 

브라우저에서 도메인 주소를 이용하여 검색하면, 먼저 DNS서버로 도메인 주소가 전달된다. 그러면 서버 내부에서 도메인 주소를 토대로 찾으려는 도메인 주소의 IP주소를 찾고, 다시 브라우저로 해당 IP주소를 갖고 있는 호스팅 서버로 연결하도록 지시한다.

 

그런데 세상에는 도메인 주소가 너무 많기떄문에, 하나의 도메인 서버가 위의 일을 모두 한다면 엄청난 트래픽이 발생할 것이다. 그래서 분산 데이터베이스(distributed db)형태로 DNS서버를 계층화하여 단계적으로 처리한다. 이를 부하를 분산한다고 표현하는데, 이는 failure의 감소, traffic 해결, decentralize와 유지보수등의 다양한 효과가 있다.

 

 

1. Root name Server(.)

루트 네임 서버는 최상위 레벨 영역의 권한이 어느 네임서버에 위치하는지를 알고 있다. 따라서 네임서버들이 mapping되어있지 않으면 네임서버와 매핑해주고(주소 정보 제공), TLD DNS서버 IP들을 관리한다. 전세계적으로 13개의 루트 네임 서버만이 존재한다.

 

2. TLD(Top-Level Domain) DNS Server

도메인 등록 기관이 관리하는 서버로, Authoritative DNS Server 주소를 저장하고 관리한다. 흔히 .com, .org, .net과 같은 일반 최상위 도메인과 .fr, .kr, .jp와 같은 국가코드 최상위 도메인이 있다.

 

3. Authoritative DNS Server

실제 개인 도메인과 IP주소의 관계가 저장/변경되는 서버. 실제 네임서버를 설정하는 곳이 이곳이다.

 

4. Local DNS Server (Recursive DNS Server, Default DNS Server)

인터넷 사용자가 가장 먼저 접근하는 DNS서버. 매 접근 시마다 모든 DNS서버를 통해서 접근한다면 속도나 효율 측면에서 좋지 않으므로, 한번 거친후 얻은 데이터를 캐시와 같이 저장해둔다. 

쉽게 말해서, 브라우저에서 처음 인터넷 주소를 물어보는 서버를 말한다. 계층적으로 어떤 한 서버를 명확하게 지칭해서 말하는 것은 아니고, 일반적으로 모든 host들의 DNS 쿼리는 ISP(통신사)마다 가지고 있는 local 서버로 접근한다.

 

 

 

실제 DNS서버를 통해서 도메인 주소를 IP주소로 변환하는 과정은 다음과 같다.

1. 사용자가 브라우저 등을 사용하여 네임서버로 www.naver.com에 대한 요청을 전달한다. 컴퓨터는 가장 먼저 Local DNS 캐시에 매칭되는 IP주소가 있는지를 확인하고, 존재한다면 바로 IP주소를 반환받고 프로세스를 종료한다.
2. 로컬 DNS 서버가 캐시 데이터를 가지고 있지 않다면 최상위 루트네임 서버로 IP주소를 요청한다.
3. 루트 DNS 서버는 *.com 도메인을 보고 .com 을 관리하는 TLD 서버 주소를 반환한다.
4. 로컬 서버는 받은 TLD 서버 주소로 IP주소를 요청한다.
5. TLD 서버는 해당 도메인(naver.com)을 관리하는 Authoritative 서버 주소를 찾아 반환한다.
6. 로컬 서버는 받은 Authoritative 서버 주소로 IP주소를 요청한다.
7. Authoritative서버는 요청에 따라 IP주소를 찾아서 알려준다.
8. 로컬 서버는 IP주소를 캐시로 저장하고, 브라우저에게 알아낸 IP주소를 안내한다.
9. 브라우저는 받은 IP주소를 통해 호스팅 서버로 연결한다.

+ 로컬 서버에는 보통 TLD서버의 캐시는 저장되어 있다. 따라서 루트네임 서버로 요청이 이루어지는 경우는 많지 않다.

참고:
https://www.liquidweb.com/kb/how-to-demystify-the-dns-process/
https://www.cloudflare.com/ko-kr/learning/dns/what-is-dns/

 

출처: https://aws.amazon.com/ko/route53/what-is-dns/

 

눈치챘겠지만 도메인 주소는 역순으로 이루어져 있다. 루트네임 서버가 가장 끝에, 그 앞에 최상위 서버와 추가적인 문자열로 이루어져 있다.

출처: https://webdir.tistory.com/161