Network

chrkb1569·2022년 10월 21일

이번 주에는 Network 부분에 대해서 공부하였습니다.
공개키 방식과 비밀키 방식, Http 프로토콜과 Https 프로토콜 사이의 차이점, 로드밸런싱 기법, Blocking & Non-Blocking 방식, Synchronous, Asynchronous에 대해서 알아보았습니다.

공개키 / 비밀키 방식

대칭키 암호화 방식

암호화 및 복호화에 사용되는 키가 동일한 방식을 의미합니다.

따라서, 해당 암호화 방식을 사용할 경우, 동일한 키를 가진 송신자와 수신자만이 데이터를 볼 수 있다는 특징을 가지고 있습니다.

이러한 대칭키를 사용하는 알고리즘은 DES, AES 등이 존재합니다.

이러한 대칭키 암호화 방식을 사용할 경우, 공개키 암호화 방식에 비하여 속도가 빠르다는 장점이 있지만, 키를 제3자에게 유출되지 않도록 주의하여야하며, 대칭키 암호화 방식을 많이 사용할수록 관리해야할 키가 많아진다는 단점이 존재합니다.

또한, 대칭키 방식을 사용하기 때문에 제3자에게 비밀키가 유출될 경우, 암호화된 내용을 확인할 수 있기 때문에 안전성 문제도 존재합니다.

공개키 암호화 방식

대칭키 암호화 방식과는 다르게, 암호화 및 복호화에 사용되는 키가 동일하지 않은 방식을 의미합니다. 따라서, 비대칭키 암호화 방식이라고도 불립니다.

공개키 암호화 방식을 사용하게 될 경우, 송신자와 수신자 모두 다른 사람에게 공개하는 공개키와 개인만이 가지고 있는 비밀키를 가지고 있게됩니다.

개인의 공개키는 암호화를 할때 사용되며, 개인의 비밀키는 공개키로 암호화된 데이터를 복호화 할때 사용됩니다.

데이터 송신자는 수신자의 공개키로 암호화하여 수신자에게 암호화된 데이터를 보내고, 수신자는 자신의 비밀키를 통하여 암호화된 데이터를 복호화합니다.

이러한 방식을 활용하여 암호화를 할 경우, 대칭키 사용에서의 문제점이었던 키분배 문제를 해결할 수 있지만, 대칭키 암호화 방식과 비교하였을때 속도 측면에서 느리다는 단점이 존재합니다.

HTTP / HTTPS

HTTP

HTTP란, Hyper Text Transfer Protocol의 약자로, 서버와 클라이언트가 데이터를 주고 받기 위한 모델을 의미합니다.

여기서 서버와 클라이언트가 주고받는 데이터인 Hyper Text는 사진, 동영상 등 파일의 위치를 지정할 수 있는 하이퍼링크를 나타낼 수 있는 텍스트를 의미합니다.

즉, 하이퍼 링크를 통하여 사용자가 문서에서 다른 문서로 넘어갈 수 있도록 하는 초월적인 글을 Hyper Text라고합니다.

Http의 경우, Application Layer에서 동작하며, 상태를 가지고 있지 않은 Stateless한 프로토콜이며, 클라이언트가 서버에게 데이터를 요청하는 행위를 Request, 서버가 클라이언트에게 요청한 데이터를 전달해주는 행위를 Response라고합니다.

이때, Request에서 사용되는 Http의 형태와, Response에 활용되는 Http의 형태가 다음처럼 조금 다르다는 특징을 가지고 있습니다.

HTTP Request 구조

Http Request 메세지는 Start line, Headers, Body 세가지 구조로 구성되어있습니다.

Start Line

특정 Http 메세지가 어떠한 메세지인지를 표기해주는 부분으로,

Start Line도 Http Method, Request Target, Http Version으로 구성되어 있습니다.

먼저, Http Method의 경우, 클라이언트가 의도한 action을 정의하는 부분입니다.

예를 들어, GET의 경우, 서버로부터 데이터를 얻어오는 행위, POST의 경우에는 데이터를 등록하는 행위에 많이 사용되곤합니다.

Request Target은 해당 Request 요청의 대상 URL을 의미합니다.

Http Version의 경우에는 사용되는 Http의 버전을 나타냅니다.

Headers

해당 Request에 대한 추가 정보를 담고 있는 부분을 나타냅니다. 쿠키 정보, Host, 캐시 관련 정보 등 매우 다양한 정보를 담고 있습니다.

Header의 경우, Map과 같이 Key와 Value값을 통하여 데이터를 저장합니다.

Body

Request를 통하여 전달되는 실제 메세지를 나타내며, Body 부분에 아무 것도 존재하지 않는 Request도 존재한다고 합니다.

HTTP Response 구조

Http Response 메세지도 Request와 비슷하게 Start Line, Headers, Body로 구성되어있습니다.

Start Line

Http Response 메세지의 구조의 가장 첫번째 부분으로, Http 버전, Status Code, Status Text로 구성되어 있습니다.

Http 버전의 경우, Request에서 살펴보았던 것과 마찬가지로 Http의 버전을 나타내며, Status Code의 경우, 클라이언트가 요청한 Request가 어떻게 처리되었는지 그 결과를 코드로 표기해줍니다.

200대의 경우 올바르게 처리되었다는 것을 나타내며, 400대와 500대는 오류가 발생하여 올바르게 처리되지 않았음을 나타냅니다.

Status Text의 경우에는 Status Code를 설명해주는 간단한 메세지가 담겨져 있는 부분입니다.

Headers

Response의 header와 동일하지만, Response에서만 사용되는 Header 값들이 존재합니다.

Body

Request의 Body와 동일한 기능을 수행합니다.

HTTPS

Http 프로토콜에서 보안적인 면을 강화한 프로토콜입니다.

Https 프로토콜은 Http 프로토콜과는 다르게, SSL 인증서라는 방식을 사용하여 서버의 정보를 취득하고, 신뢰성을 판단합니다.

SSL 인증서

해당 서버가 신뢰할 수 있는 서버임을 증명해주는 수단으로, SSL 인증서는 CA 혹은 Root Certificate라 불리는 기업들이 SSL 인증서를 발급해줍니다.

Https 프로토콜을 사용하는 경우, 이 SSL 인증서와 비밀키 알고리즘 혹은 공개키 알고리즘을 통하여 클라이언트와 통신을 하게됩니다.

로드밸런싱

서버를 이용하는 사람들이 증가하면서, 기존의 서버가 수용할 수 있는 한계치에 도달하였을 경우, Scale-up 혹은 Scale-out 방식을 통하여 해결해줄 수 있습니다. Scale-up 방식과 Scale-out 방식은 간단하게 더 많은 사용자들을 수용할 수 있도록 기존의 서버를 업그레이드 해주는 방식을 나타냅니다.

Scale-up

Scale-up 방식의 경우에는 서버의 하드웨어적인 부분을 향상시키는 기법입니다. 즉, 서버의 성능을 향상시키기 위하여 CPU나 메모리 등을 업그레이드 해줌으로써, 더 많은 사용자들을 수용할 수 있도록 업그레이드해줍니다.

Scale-out

Scale-out 방식의 경우에는 기존의 서버와 비슷한 성능을 가진 서버를 여러 개 배치하여 여러 사용자들을 수용하는 방식입니다.

Scale-out 방식을 사용하는 경우, 우리는 서버로 요청을 보내는 사용자들을 어떠한 서버로 보낼 것인지 결정하여야합니다.

이렇게, 클라이언트로부터 온 요청을 어떠한 서버로 보낼지 결정하는 방식이 바로 로드 밸런싱 기법입니다.

로드 밸런싱?

로드 밸런싱 기법은 네트워크 혹은 서버 사이에서 네트워크나 서버로 보내지는 클라이언트의 요청들을 분산시켜주는 기술을 의미합니다.

로드 밸런싱 기법을 사용함으로써, 특정 서버 혹은 네트워크에 부하가 집중되는 현상을 방지할 수 있다는 장점이 존재합니다.

- 클라이언트와 로드 밸런서가 데이터를 주고 받는 과정
    
1) 클라이언트의 브라우저에서 찾고자하는 DNS를 입력
    
2) 해당 클라이언트의 로컬 DNS 서버에게 해당 DNS의 IP주소 요청
    
3) 로컬 DNS 서버가 외부에 존재하는 계층적 DNS 구조 구성원들에게 IP요청
    
4) 로드 밸런서의 IP를 로컬 DNS 서버에게 반환
    
5) 로컬 DNS 서버가 해당 IP를 클라이언트에게 반환
    
6) 클라이언트가 해당 IP주소로 요청
    
7) 로드 밸런서가 해당 요청 서버로 처리
    
8) 서버에서 처리한 응답 로드 밸런서가 받아서 클라이언트에게 반환

로드 밸런서는 OSI 7계층에서 4계층에 해당하는 Transport Layer, 그리고 7계층에 해당하는 Application Layer에서 동작합니다.

L4 로드 밸런서(Transport Layer에서 동작하는 로드 밸런서) & 로드 밸런싱 기법

L4 로드 밸런서는 Transport Layer에서 동작하는 로드 밸런서로, Network Layer나, Transport Layer의 정보를 바탕으로 클라이언트의 요청을 분산시킵니다.

즉, IP주소, Mac주소, 통신 프로토콜 등에 따라서 클라이언트의 요청을 분산처리하는 것이 가능합니다.

라운드 로빈 기반 : 클라이언트의 요청을 각 서버에 순차적으로 맺어주는 방식을 나타냅니다. 단순하게 요청이 들어오는 순서대로 서버에 맺어주기 때문에, 경우에 따라서는 비효율적인 방식이 될 수도 있습니다.
가중치 및 비율 할당 방식 : 서버마다 가중치를 설정해두고, 해당 비율만큼 요청을 넘겨주는 방식입니다. 예를 들어, 서버 A의 경우에는 5의 가중치를 가지고 있으며, 서버 B의 경우에는 2의 가중치를 가지고 있다 할때, 서버 A에는 5개의 요청을, 서버 B에는 2개의 요청을 보내주는 방식입니다.
최소 연결 기반 방식 : 가장 많이 사용되는 방식으로, 가장 적은 요청을 처리하고 있는 서버에게 트래픽을 보내주는 방식입니다.
응답 시간 기반 방식 : 가장 응답 시간이 빠른 서버로 트래픽을 보내주는 방식입니다. 각 서버마다의 처리 속도가 다른 경우 적합한 방식입니다.
해시 기반 방식 : 특정 클라이언트는 특정 서버로만 할당시키는 방식입니다. 이러한 방식을 사용하는 경우, 경로가 보장되며 접속자가 많을 수록 분산 및 효율이 뛰어납니다.

L7 로드 밸런서(Application Layer 에서 동작하는 로드 밸런서) & 로드 밸런싱 기법

L7 로드 밸런서는 L4 로드 밸런서의 기능을 포함하는 것 뿐만 아니라, OSI 7계층의 프로토콜을 바탕으로도 분산 처리가 가능합니다.

URL 스위칭 방식 : 특정 하위 URL들은 특정 서버로 처리하는 방식입니다.
쿠키 지속성 : 쿠키 정보를 바탕으로 클라이언트가 연결했었던 동일한 서버에 계속 할당해주는 방식입니다.

Blocking / Non-Blocking, Synchronous / Asynchronous

프로그램이 동작하는데에 있어서, 함수를 호출하는 경우 함수가 종료될 때까지 흐름이 멈추는 경우가 있으며, 함수를 처리하면서 본 함수에서 동작을 이어갈 수 있는 경우도 존재합니다.

또한, 호출한 함수의 결과를 해당 함수에서 처리할 수도 있으며, 특정 함수를 호출하였던 본 함수에서 결과를 처리할 수도 있습니다.

이처럼, 프로그램의 흐름이 어떻게 이루어지고, 값의 처리를 어떻게 하느냐에 따라서 나눌 수 있는데, 함수가 호출될 경우 프로그램의 제어 권한을 누가 가지고 있느냐에 따라서 Blocking 방식과 Non-Blocking 방식으로 나뉘고, 호출한 함수의 결과를 어떠한 함수가 처리하느냐에 따라서 Synchronous, Asynchronous 방식으로 나뉩니다.

Blocking 방식 함수를 호출할 경우, 해당 함수로 제어권이 넘어가 본 함수에서 추가적인 작업을 수행하지 못하는 방식입니다.
Non-Blocking 방식 함수를 호출하여도 해당 함수에서 제어권을 다시 본 함수로 넘겨주기 때문에 추가적인 작업을 수행할 수 있는 방식입니다.
Synchronous 방식 함수가 처리한 결과를 본 함수에서 처리하는 방식입니다. 호출하는 함수가 호출되는 함수의 결과값을 기다리거나, 호출되는 함수로부터 바로 리턴 받더라도, 작업 완료 여부를 호출하는 함수 스스로 계속 확인하는 방식입니다.
Asynchronous 방식 함수가 처리한 결과를 해당 함수에서 처리하는 방식입니다.

다음처럼, 4가지의 방식이 존재하는데, Blocking, Non-Blocking 방식과 Synchronous, Asynchronous 방식이 섞여서 사용됩니다.

본 함수를 A함수라고 정의하고, 호출되는 함수를 B함수라고 정의하여 설명해보겠습니다.

Blocking & Synchronous 방식

A함수에서 B함수를 호출하였을 경우, B함수가 로직을 처리한 뒤에 결과를 반환하기 전까지 A함수에서는 추가적인 작업을 수행하지 못합니다. B함수의 결과를 A함수가 처리해야 하기때문에, A는 계속적으로 B의 결과를 기다리게됩니다.

Blocking & Asynchronous 방식

A함수에서 B함수를 호출하였을 경우, B함수가 로직을 처리한 뒤에 결과를 반환하기 전까지 A함수에서는 추가적인 작업을 수행하지 못합니다. Synchronous 방식과는 다르게, B함수가 처리한 결과값을 A함수가 신경쓰지 않는다는 특징을 가지고 있습니다.

Non-Blocking & Synchronous 방식

A함수에서 B함수를 호출하였을 경우, B함수는 제어권을 A함수로부터 받음과 동시에 다시 반환하여 A함수가 별도의 작업을 수행할 수 있도록 해줍니다. 그러나, 결과적으로 A함수는 B함수로부터 함수 실행 결과를 받아서 처리해야하기 때문에 주기적으로 B함수에게 연산을 끝냈는지 물어보는 신호를 날리게됩니다. 만일, B함수가 연산을 끝마칠경우 A함수는 B함수의 연산 결과를 처리합니다.

Non-Blocking & Asynchronous 방식

A함수에서 B함수를 호출하였을 경우, B함수는 제어권을 A함수로부터 받음과 동시에 다시 반환하여 A함수가 별도의 작업을 수행할 수 있도록 해줍니다. Asynchronous 방식을 사용하기 때문에, 추후에 B 함수 내부에서 함수 결과값을 계산한 뒤 반환할 경우 그 값을 A함수가 받습니다.

Blocking / Non-Blocking I/O

Blocking I/O

I/O작업이 수행될때, 제어권이 I/O 작업으로 넘어오는 방식입니다. 따라서, I/O작업을 모두 끝마치기 전까지 어플리케이션이 추가적인 동작을 수행할 수 없습니다.

Non-Blocking I/O

I/O작업이 수행될때, 제어권이 I/O 작업으로 넘어오지만, 바로 어플리케이션에 반환하여, I/O 작업이 수행되고 있음에도 불구하고 어플리케이션에서 추가적인 작업을 수행할 수 있는 방식입니다. 어플리케이션은 작업을 수행하면서 중간 중간 I/O 작업이 모두 완료되었는지 확인하는 신호를 보내고, 수행이 완료되었을 경우 작업 결과값을 받아옵니다.