[컴퓨터 네트워크] 8. Application Layer (1) : 어플리케이션 계층 개요

인터넷을 사용하는 어플리케이션을 만들 때, 프로그래머는 Transport 계층이 제공하는 서비스 중 어떤 서비스를 사용해서 어플리케이션을 만들 것인지, 어떤 구조로 만들 것인지만 결정하면 된다.

어플리케이션 밑에 있는 라우터, 스위치 같은 core device의 동작에 대해서는 신경쓰지 않아도 된다.

 

Application Design Paradigm

네트워크 어플리케이션을 만들 때 사용할 수 있는 디자인 패러다임으로 크게 client - server 패러다임과 peer to peer 패러다임이 있다.

client - server paradigm

데이터를 요구하는 클라이언트와 데이터를 제공하는 서버로 역할을 구분하는 패러다임이다.

 

서버는 항상 켜져있는 컴퓨터(host)이고, 고정된 IP주소를 가지고 있다.

마치 손님을 기다리면서 똑같은 위치에 항상 문을 열고 있는 식당과 같다.

서버 컴퓨터(host)는 보통은 data center 안에 모여있으며, 요즘은 클라이언트의 요청량에 따라 서버의 크기를 자동으로 조절해주기도 한다.

 

클라이언트는 필요할 때만 서버와 연결되어 통신하는 host 이다.

보통 동적 IP 주소를 가지고 있으며, 클라이언트끼리는 서로 직접 통신하지 않는다. (서버를 경유한다.)

 

대부분의 인터넷 어플리케이션은 이 패러다임을 따르며, 이를 위해 사용하는 프로토콜이 HTTP, IMAP, FTP 등이다.

 

peer - peer paradigm

p2p 패러다임은 서버와 클라이언트의 역할을 고정하지 않는 패러다임이다.

임의의 두 컴퓨터가 서로 직접 연결된 뒤, 그때그때 데이터를 제공하는 쪽이 서버가 되고, 데이터를 요청하는 쪽이 클라이언트가 되는 구조이다.

 

항상 켜져있는 서버가 없고, 각각의 peer는 간헐적으로 연결되며 IP주소도 계속 바뀔 수 있기에 관리의 어려움이 크다.

대표적인 예는 Bit Torrent 같은 파일 공유 서비스와 블록체인 네트워크가 있다.

 

Process Comunication

프로세스는 호스트 컴퓨터에서 실행되고 있는 하나의 프로그램으로 생각하면 된다.

하나의 컴퓨터(호스트) 안에서 두 프로세스가 통신할 때는 IPC (Inter-Process Communication) 방식을 사용한다.

(운영체제에서 다루는 내용이다.)

 

서로 다른 호스트의 프로세스가 데이터를 주고 받을 때는 '메세지' 를 주고 받는다.

이때 클라이언트 프로세스는 통신을 시작하는 프로세스이고, 서버 프로세스는 연결을 기다리는 프로세스를 말한다.

(마찬가지로 P2P 구조라면 프로세스 하나가 서버, 클라이언트 역할을 모두 할 수 있다.)

 

Socket

프로세스와 프로세스가 통신할 때 Socket 이라는 인터페이스를 사용한다. (일종의 API)

소켓은 BSD 라고 불리는 UNIX 운영체제의 버전에서 시작되어 이 초기 소켓이 제공하는 기능들을 포함하도록 이후 소켓들도 설계되었다.

 

소켓은 Trnasport 계층과 Application 계층 사이에 존재하며, Application 계층에서 Transport 계층을 사용하는 인터페이스이다. 마치 문과 같은 존재라서, 어플리케이션은 메세지를 만든 뒤, 그냥 소켓으로 보내기만 하면, 이후에 메세지가 전송되는 과정은 알아서 처리된다.

 

소켓은 트랜스포트 계층에서 어떤 서비스를 이용할 지에 따라 TCP, UDP 소켓으로 구분된다.

 

Addressing Process

메세지를 주고 받으려면 프로세스를 지칭할 '식별자'가 필요하다.

이를 위해 사용하는 것이 첫번째로 IP 주소이다.

IP주소는 host 컴퓨터에 붙는 32bit 주소이다. (정확히는 네트워크 인터페이스 카드에 붙으므로, 하나의 컴퓨터가 여러개의 네트워크 인터페이스 카드를 갖고 있다면 여러 IP주소를 가질 수도 있다.)

각각의 숫자가 점으로 구분되기 때문에 dotted decimal 이라고 부르기도 한다.

 

두번째로 필요한 것은 16bit 체계의 port number 이다.

IP 주소는 host를 식별하는데 사용되는데, 하나의 host 에서는 여러 프로세스가 실행되고 있을 수 있기 때문에 IP주소만으로는 process를 식별할 수 없다.

그래서 특정 포트로 가면 특정 서비스(프로세스)에 접근할 수 있다는 것을 알려주는 포트번호가 필요하다.

 

Application-Layer Protocol 이 정의하는 내용

어플리케이션 계층의 프로토콜은 아래와 같은 내용들을 정의하고 있다.

1. 교환할 메세지의 타입 (request, response)

2. 메세지의 syntax (메세지에 어떤 필드가 얼마만큼의 사이즈로 있는지)

이를 통해 혹시 공격자가 메세지를 조작하거나 noise 에 의해 bit error 가 났을 때 이를 검출할 수 있다.

3. message symantics = 메세지의 각 필드의 정보 (필드의 경계 구분, 필드의 내용과 인코딩 방식 등을 지정)

4. rule : 메세지를 주고받는 각각의 상황 (이벤트)마다 어떻게 행동해야 정해둔 규칙

 

프로토콜의 종류

Open Protocol : 인터넷 표준 단체에서 제정한 프로토콜, 어떤 제조사든지 이 프로토콜을 준수하여 만들면 다른 제조사라도 호환성을 보장한다는 의미이다. (즉, 인터넷이라는 공용 공간에서 사용할 수 있다.)

이를 '상호 운용성을 보장한다' 라고도 한다. (interoperability)

대표 예시로는 HTTP, SMTP, TCP, UDP, IP 등이 있다.

이런 표준은 IETF (Internet Engineering Task Force) 라는 단체에서 만드는 RFC(Request For Comment) 문서에 정의되어 있다.

 

Proprietary protocol : 반대로 회사의 지적 자산 IP가 되는 프로토콜이다. 말 그대로 자체 개발해서 쓰는 프로토콜로 공개되지 않은 프로토콜이다.

대포적인 예시로 Skype, Zoom 에서 사용하는 프로토콜이 해당한다.

이 프로토콜들은 비공개되어 있기 때문에 직접적으로 알 수 없고, 리버싱 엔지니어링을 통해 간접적으로 추측만 할 수 있다.

 

어플리케이션이 필요로 하는 Transport 계층의 서비스

1. data integrity (데이터 무결성)

파일 전송과 같은 경우에는 전송하는 파일이 변조, 훼손되면 안되기 때문에 100% 믿을 수 있는 무결성을 요구한다.

음성 통화 앱같은 경우에는 일부 데이터의 손실이 있어도 감내가능하기 때문에, 100%의 무결성을 요구하지 않는다.

 

2. timing

스카이프 같은 인터넷 전화 앱이나, 실시간 온라인 게임은 데이터 무결성보다 낮은 delay를 더 중요하게 여긴다.

 

3. throughput (=band width)

멀티미디어 앱같은 경우, 효율적으로 미디어를 제공하기 위해 최소한으로 필요로하는 대역폭이 있다.

(꾸준히 일정량 이상의 데이터가 전송이 되어야 한다.)

하지만 전송하는 데이터의 양이 들쭉날쭉해도 괜찮은 elastic app의 경우, throughput을 크게 상관하지 않는다.

(file transfer 프로그램 등)

 

4. security

보안이 중요하지 않은 앱은 없다. 따라서 어느정도는 기본으로 반영하고 들어간다.

HTTP라는 기존 프로토콜 위에서 TLS, SSL 등을 활용하여 시큐리티를 보장하는 것이 대표적인 에시다.

 

TCP service

트랜스포트 계층에서는 크게 TCP서비스와 UDP서비스를 제공한다.

 

1. TCP는 신뢰성있는 전송(transport) 서비스를 제공한다.

신뢰성이 있다는 말은 sender process 가 보낸 데이터를 그 순서와 그 내용 그대로 훼손, 오류없이 수신자에게 도착하는 것을 보장해준다는 말과 같다.

 

2. Flow Control 서비스를 제공한다.

흐름 제어는 송신자가 수신자의 버퍼 공간을 고려하여 데이터를 보낸다는 뜻이다.

데이터를 보내는 송신자는 TCP에게 데이터를 보내달라고 세그먼트를 만들어 보낸다.

그러면 TCP는 이 데이터를 버퍼에 저장해둔다.

TCP는 신뢰성있는 전송을 보장하기 때문에, 혹시 전송이 실패하면 다시 전송해야 하기 때문이다.

 

데이터를 수신하는 쪽도 버퍼가 필요하다.

데이터가 들어왔을 때, 잠시 다른 일을 하느라 그 데이터를 처리하지 못할 수도 있기 때문이다.

이럴 때 버퍼에 임시로 받은 데이터를 저장해두고, TCP가 처리할 여유가 생겼을 때 해당 데이터를 순차적으로 처리한다.

 

흐름 제어는 수신자의 버퍼 공간이 얼마나 비어있는지를 먼저 확인하고, 그 남은 공간만큼의 데이터를 보내서 데이터가 버퍼를 넘치지 않을 정도로만 보내는 것을 의미한다.

기껏 멀리 보냈더니 버퍼에 공간이 없어서 데이터가 버려지는 일이 없도록 하는 것이다.

 

3. Congesion Control 서비스를 제공한다.

송신자와 수신자의 1대1 쌍이 100쌍이 있다고하자

이들은 모두 같은 네트워크 코어를 지난다고 할 때 네트워크 코어에서는 혼잡이 발생할 수 있다.

네트워크 코어는 고속도로와 같은 역할을 하는데, 평소에 안쓰다가 고속도로에 한번 들어갔더니 굉장히 차가 막히고 있어서 목적지에 데이터가 늦게 도착하는 상황이 발생할 수 있고, 이를 '혼잡' 이라고 한다.

TCP는 이에 대한 방지책으로 고속도로에 있는 모든 데이터를 천천히 보내자는 정책을 사용한다.

이는 TCP의 알고리즘이 계산해서 명령하며, 네트워크 코어의 혼잡도에 따라서 어느정도 속도로 보낼지를 결정한다.

 

4. Connection-Oriented

데이터를 주고받기 전에 클라이언트 프로세스와 서버 프로세스 사이에 연결을 설정해야한다.

서킷 스위칭 방식과 유사하지만, 이 두 프로세스 간에서만 알고있는 예약이라고 생각하면 된다.

 

하지만 보장하지 않는 것

1. 전송 시간을 보장하지 못한다. (반드시 이 시간 내로 보낸다)

2. minimun bandwidth (throughput) 을 보장하지 못한다. (최소한 이 속도로는 보낸다)

3. sequrity (tcp가 아니라 별도 레이어로 보장한다. TLS, SSL 등)

 

UDP

1. unreliable data transfer

UDP는 데이터의 신뢰성있는 전송을 보장하지 않는다. ('지키지 않는다'가 아니라 '보장하지 않는다'!)

 

2. reliability, flow control, congestion control, timing, throughput guarantee, security, connection setup 등을 모두 보장하지 않는다.

즉, TCP가 보장하는 것을 보장하지 않고, TCP가 보장하지 못하는 것은 UDP도 보장하지 못한다.

 

그럼 UDP를 왜 쓸까?

UDP는 매우 심플한 프로토콜이기 때문이다.

UDP라는 말 자체에 Datagram 이라는 말이 들어간다.

Datagram은 3계층인 네트워크 레이어의 전송단위인데, UDP는 4계층에서도 이 전송단위를 그대로 쓸 정도로 데이터그램에 추가적인 정보가 별로 필요없다. (프로세스를 지정하기 위한 port 정보 정도가 필요하다.)

 

UDP를 사용하면 좋은 상황을 예로 들면

TCP를 사용하는데, 네트워크 혼잡이 발생하여 네트워크 전송속도가 느리고 답답한 상황이다.

TCP는 자체 규약에 의해 속도를 제한해서 보내게 되는데, UDP는 그런 규약이 없기 때문에 이기적으로 데이터를 빠르게 보낸다. (대신 데이터를 확실히 받는지 확인은 하지 않는다)

 

데이터의 수신을 확인할 필요는 없으면서 데이터는 빠르게 전송하고 싶은 상황이 UDP를 사용하기 적합한 상황이다.

사실 이 상황이 쓰기 좋은 상황의 전부이지만, 생각보다 이런 상황이 자주 발생해서 UDP를 사용한다고 한다.

 

인터넷 전화같은 SIP, RTP 프로토콜이나 게임에 사용하는 프로토콜은 UDP 기반의 프로토콜을 사용하기도 한다.

FTP, SMTP, HTTP, DASH (비디오 스트리밍) 프로토콜은 데이터의 신뢰성있는 전송이 중요하므로 TCP기반의 프로토콜을 사용한다.

(비디오 스트리밍은 UDP를 쓰는게 좋지 않냐고 할 수 있는데, TCP에 의한 지연을 중간에 버퍼를 둠으로써 해결할 수 있다. 자세한 내용은 뒤에서 또 정리할 예정이다.)

 

 

TCP Sequrity

TCP는 초기에 Sequrity가 고려되지 않았다.

하지만 인터넷이 상업적으로 사용되기 시작하면서 보안 문제가 대두되었고, TCP에도 Sequrity의 필요성이 등장했다.

 

바닐라 TCP, UDP 소켓에는 암호화 개념이 없기 때문에 비밀번호같은 민감한 정보도 평문 그대로의 데이터로 주고받는다.

이 문제를 해결하기 위해 처음에는 SSL이 등장했다. 그러나 SSL에 보안상 문제가 발견되어 이를 해결한 개념이 새로 등장하였고, 이것이 바로 TLS (Transport Layer Sequrity) 이다. TLS는 기존 Transport Layer에 새로운 보안용 레이어를 추가한 것이다.

TLS는 암호화된 TCP Connection을 제공하고, 데이터의 무결성을 검증하며, 송신자에 대한 정보까지 포함시켜 제공하도록 한다.

 

TLS는 Transport 계층과 Application  계층 사이에 위치하고 있기 때문에, 어플리케이션에서 TLS를 거치지 않고 바로 Trnasport 계층의 서비스를 이용하면 민감한 정보를 평문으로 보내는 등 보안 문제가발생할 수 있다.

따라서 어플리케이션은 TCP 계층의 서비스를 사용하는 TLS 라이브러리를 사용하여 데이터를 주고 받도록 해야한다.