정리[NetWork]

용어 정리

네트워크 : 네트워크란 데이터를 교환하기 위해 전송 매체를 매개로 서로 연결되어 있는 것을 의미합니다.

인터넷 : 전세계의 컴퓨터들이 서로 연결되어있는 거대한 네트워크를 뜻합니다.

프로토콜 : 사람간의 대화에서 같은 언어를 이용해서 의사소통하듯이 네트워크 상에서 데이터를 주고받기 위해서 일종의 정해진 규약이 있는데 이것을 프로토콜입니다.

OSI(Open Systems Interconnection Reference Model) 7계층이란?

네트워크 상에서 정보를 주고받으려면 어느 경로로 보낼지, 어떤 방식으로 보낼지 등등의 고려사항들이 많이 발생하게 됩니다. 만약 하나의 규약을 정해놓았다면 이슈에 대한 관리가 어려워지게 되고 또다른 문제가 발생하게됩니다. 따라서, 네트워크 관리에 대하여 7가지 계층으로 나누어 관리하게됩니다. 따라서, 7가지의 각 계층 중 어떤 문제가 발생하였을 때, 해당 계층에 대해서만 문제를 해결하면 되는 효율적인 관리가 가능하게됩니다.

7) 응용 계층(Application Layer 7계층)

응용 프로세스가 네트워크에 접근하기 위한 여러 인터페이스들을 지원하는 단계입니다.

6) 표현 계층(Presentation Layer 6계층)

표현 계층은 응용 계층이 전달받고자 혹은 전달하고자 하는 데이터를 인코딩하고 디코딩하며 암호환하는 계층입니다. 그리고 응용 계층에서 데이터를 이해할 수 있도록 포맷 변환을 합니다.

5) 세션 단계( Session Layer 5계층)

양 끝단의 엔드 유저들이 데이터를 통신하기 위한 논리적인 연결을 관리하고 연결을 지속시켜주는 계층입니다. 세션 계층에서 TCP/IP 세션을 만들고 제거해주며 통신하는 사용자들을 동기화하고 오류를 복구시켜줍니다.

4)전송 단계(Transport Layer 4단계) - TCP, UDP

통신을 활성화하기 위한 단계입니다. 보통 TCP프로토콜을 사용하고, 포트를 열어서 응용프로그램들 간의 통신이 가능하도록 합니다. 이 단계에서는 양 끝단의 end유저들이 서로 신뢰성 있는 데이터를 주고받게 해주고 만약 실패한 패킷들이 있다면 다시 전송해주는 역할을 합니다. 

3)네트워크 단계(Network Layer 3단계) - 라우터, IP

네트워크 단계는 라우팅 기능을 수행하는 단계입니다.

데이터를 어디에 전달할지 IP주소를 사용하고 최적의 경로를 설정하여 빠르게 패킷을 전송하는 단계입니다.

네트워크에서 부르는 데이터 단위는 패킷이다.

2)데이터링크 단계(Data Link 2단계) - 브릿지, 스위치

물리 단계에서 데이터를 전달함에 있어서 데이터의 오류를 검출하고 재전송하며 흐름을 제어하는 등의 관리함으로써 안전하게 정보를 전달하도록 도와주는 단계입니다.물리적인 고유 주소인 맥 주소가 프레임에 부여됨으로써, 이 맥주소를 통해 관리할 수 있습니다.(브릿지 스위치)

1)물리 단계(Physical Layer 1단계) - 통신케이블 허브

데이터를 전기적 신호로 변환해서 통신 케이블이나 허브를 통해 데이터를 전송하는 단계입니다.

 

TCP 3 way Handshake & 4 way Handshake

TCP 프로토콜이란?

TCP 프로토콜은 연결지향적이며 오류,흐름,혼잡제어 등의 기능을 사용하여 신뢰성있는 데이터 전송을 지향하는 프로토콜입니다. 연결지향이라는 말은 데이터를 전송하는 측과 받는 측에서 전용의 데이터 전송 선로인 세션을 만든다는 의미입니다. 따라서, TCP프로토콜은 데이터의 신뢰도가 중요하다고 판단될때 주로 사용하게 됩니다.

3way handshake - 연결성립

TCP프로토콜은 연결지향적이고 신뢰성 있는 데이터 전송을 보장해주기 위한 프로토콜입니다. 이러한 TCP가 연결지향적인 특성을 갖게해주는 과정이 3 way handshake입니다. 즉, 서버와 클라이언트가 서로 연결할 환경이 잘 구성되었는지 확인하는 과정입니다.

첫번째로, 클라이언트가 서버에게 연결을 요청하는 SYN패킷을 보내게 됩니다.

두번째로, 서버가 SYN을 받고 클라이언트에게 요청을 받았다는 신호인 ACK와 SYN패킷을 보내게됩니다.

세번째로, 클라이언트는 서버의 응답인 ACK와 SYN을 받고 신호를 받았다는ACK(y+1)을 서버로 보내게됩니다.

이렇게 세가지의 과정을 통해서 통신이 완료되면 연결이 성립되게됩니다.

 

4way handshake - 연결 해제

연결이 성립되고 모든 통신이 끝났다면 해제를 해야 합니다. 따라서 4 way handshake과정을 통해서 연결을 종료해야합니다.

첫번째로, 클라이언트가 서버에게 연결을 종료한다는 FIN플래그를 보냅니다.

두번째로, 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보냅니다.

세번째로, 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN플래그를 클라이언트에게 보냅니다.

네번째로, 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보냅니다.

서버는 ACK를 받은 이후 소켓을 닫고 TIME WAIT시간이 끝나면 클라이언트도 소켓을 닫게됩니다.

 

TCP/IP 흐름제어 & 혼잡제어

TCP는 네트워크 통신에서 신뢰적인 연결방식으로서, Unreliable network에서 reliable network를 보장하도록 하는 프로토콜입니다. 따라서, Endsystem과 Endsystem에 대한 흐름제어와 혼잡제어 기능을 수행해야합니다.

 

흐름제어

흐름제어란 송신측과 수신측에서 데이터 처리 속도 차이를 해결하기 위한 기법입니다. 수신측이 송신측보다 데이터 처리 속도가 빠르다면 문제가 없지만, 송신측의 속도가 빠를 경우 문제가 생깁니다. (아직 처리도 못했는데 또 정보를 보낸다고?) 수신측에서 제한된 저장 용량을 초과한 이후에 데이터가 또 도착하게 되면 데이터 손실이 발생할 수 있습니다. 이러한 문제를 해결하기 위해서는 크게 두 가지 방식이 있습니다.

 

이러한 흐름 제어 방식에는 크게 두가지의 방식이 있습니다.

첫 번째로, Stop And Wait방식입니다.

데이터를 하나 보내면 데이터를 받았다는 ACK패킷을 보낸다음, ACK신호를 확인하면 다음 데이터를 보내는 방식입니다. 즉, 상대가 응답을 하면 데이터를 보낸다는 구조이기 때문에 구현이 간단하다는 장점이 있습니다. 하지만 그만큼 속도 성능이 안좋다라는 단점이 있습니다.

 

두 번째로, Sliding Window방식입니다.

Stop and Wait는 속도측면에서 비효율적인 부분이 있기 때문에 오늘날의 TCP는 Sliding Window방식을 사용하고 있습니다. 슬라이딩 윈도우는 수신 측이 한번에 처리할 수 있는 데이터를 정해놓고 그때그때 수신 측의 데이터 처리 상황을 송신측에 피드백하여 데이터의 흐름을 제어하는 방식입니다. Stop and Wait와의 가장 큰 차이점은 송신 측이 수신측에서 처리할 수 있는 데이터의 양을 미리 알고있다는 것입니다. 따라서, 수신측에서 일일이 응답을 하지 않아도 된다는 큰 장점을 가지고 있습니다. 

 

슬라이딩 윈도우는 윈도우라고 하는 일종의 마스킹 도구와 버퍼를 핵심으로 동작하게 됩니다. 일단 송신측과 수신측은 자신의 버퍼 크기를 서로에게 알려주고 송신측은 수신측의 버퍼 크기를 기반으로하며 네트워크 상황을 종합해서 윈도우 크기를 수신측의 크기보다 작거나 같게 설정하게됩니다. 윈도우에 해당하는 데이터를 쭉 전송한 후에, ACK응답을 받게 되면 그만큼 Window를 옆으로 이동시켜 새로운 데이터를 전송하는 방식으로 동작합니다.

오류제어

Stop And Wait의 경우에는 이 자체로서 오류제어가 가능합니다. 왜냐하면 데이터를 제대로 받았다는 패킷인 ACK를 그때그때 보내기 때문에 어떤 부분에서 에러가 발생했는지 알 수 있기 때문입니다.

 

하지만, 문제는 Sliding Window방식입니다. Sliding Window는 윈도우에 해당하는 데이터들을 일정수준 보내고, ACK를 받으면 또 일정수준 보내는 방식이기 때문에 오류에 대한 제어가 필요하게 됩니다. 따라서 Go Back N방식을 사용하게 됩니다. 만약 3개를 보내고 ACK와 함께 버퍼에 남아있는 공간의 크기를 함께 넘기면 그거에 맞게 또 송신을 하다가 만약 4번째 데이터에서 오류가 생겼다면 4개 이후로 받은 데이터를 모두 폐끼하고 NACK를 송신측에 보내게 됩니다. 드러면 송신측은 NACK를 받고 다시 데이터를 전송하게 됩니다.

혼잡제어

송신측의 데이터는 지역망이나 인터넷으로 연결된 거대한 네트워크를 통해서 전달됩니다. 만약 하나의 라우터에 데이터가 몰릴 경우, 자신에게 온 데이터를 모두 처리할 수 없게됩니다. 이런 경우에 또 다시 재전송을 하게되고 결국 혼잡만 가중시켜 더 큰 문제로 번지게 됩니다. 이러한 혼잡문제를 해결하기 위해서 여러가지 방안들이 존재하는데,

첫번째로, AIMD(합증가 곱감소)가 있습니다.

처음에 패킷을 하나씩 보내다가 문제없이 도착하는 Window Size(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가면서 전송하는 방법입니다. 만약 전송에 실패하거나 일정 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄이게됩니다. 이 방식은 속도 측면에서도 효율적이지 못하지만, 혼잡문제를 겪고 나서야 해결하는 방안이라는 문제점이 있습니다.

두번째로, Slow Start가 있습니다.

이 방식은 AIMD와 비슷하게 처음에 패킷을 하나씩 보내는 것부터 시작을 하지만, 패킷이 문제없이 도착하면 각각의 ACK패킷마다 Window Size를 하나씩 늘려 한 주기가 지나면 Window Size가 두배가 됩니다. 대신에 혼자 현상이 발생하면 창 크기를 1로 떨어뜨립니다. 합증가곱감소 보다는 효율적일 수 있지만 혼잡한 상황이 된 경우에는 타임아웃이 될때까지 기다리는 공백 시간이 발생하게됩니다.
세번째로, 빠른 재전송이 있습니다.

패킷을 받는 쪽에서 먼저 도착해야할 패킷이 도착하지 않고 그 다음 순번의 패킷이 도착한 경우에도 ACK패킷을 보냅니다. 하지만 순서대로 잘 도착한 마지막 패킷의 다음 패킷의 순번을 ACK패킷에 실어서 보냅니다. 따라서, 중간에 패킷하나가 손실되게 되면 보내는 측에서는 순번이 중복된 ACK패킷을 받게되면 이것을 감지하느 순간 문제가 되는 순번의 패킷을 재전송해주게 됩니다. 이러한 형상이 일어난 것은 약간의 혼잡문제라고 판단하고 Window Size를 줄이게 됩니다.

네번째로, 빠른 회복이 있습니다.

혼잡한 상태가 되면 창 크기를 1로 떨어뜨리지 않고 반으로 줄여 선형 증가시키는 방법입니다. 빠른 회복은 혼잡 상황을 한번 겪고 나서부터 합증가곱감소와 동일한 방식으로 동작하게됩니다.

 

UDP

UDP란 User Datagram Protocal의 약자로, 데이터를 데이터근램 단위로 처리하는 프로토콜입니다. TCP와는 반대로 비연결형이며 신뢰성이 없는 전송 프로토콜입니다.

 

TCP와 UDP는 왜 등장?

- IP의 역할은 OSI 7계층에서 네트워크 단계에서 Host To Host 즉, 장치에서 장치로 이동하는 것을 지원합니다. 하지만, IP에서 오류가 발생한다면 ICMP(운영체제에서 오류 메시지를 전송받는데에 주로 쓰임)에서 알려주게됩니다. 하지만 ICMP는 메시지 프로토콜로서 오류 메시지를 알려주기만 할뿐이지 대처를 못하기 때문에 IP보다 윗단계에서 대처를 해주어야합니다. 따라서 TCP UDP가 등장하게 되었습니다.

(번외 : IP는 OSI7계층에서 3단계에 속하는 네트워크 단계에서 Host TO Host만을 지원합니다. 장치에서 장치로 이동은 IP로 해결이 되지만, 하나의 장비 안에서 수많은 프로그램들이 통신을 할 경우에는 IP만으로 한계가 있습니다. 이 한계를 극복하기 위해 포트번호가 등장하였습니다)

 

TCP와 UDP는 어떻게 오류를 해결하는가?

TCP

데이터의 분실, 중복, 순서가 뒤바뀜 등을 자동으로 보정해줘서 송수신 데이터의 정확한 전달을 할 수 있도록 해준다. 즉 데이터의 신뢰성을 보장해준다.

UDP

IP가 제공하는 정도의 수준만을 제공하는 간단한 IP 상위 계층의 프로토콜이다. TCP와는 다르게 에러가 날 수도 있고, 재전송이나 순서가 뒤바뀔 수도 있어서 앱단에서 전송여부를 확인해야합니다.

 

UDP는 그럼 왜써?

UDP의 결정적인 장점은 데이터의 신속성입니다. TCP는 일단 3 way Handshake과정을 통해서 정확한 데이터 전달을 지향하고 흐름제어나 혼잡제어를 통해 신뢰성을 보장합니다. 하지만 UDP는 연결의 개념이 없어서, 서버와 클라이언트가 1:1, 1:N, M:N등으로 연결되어 있습니다. 또한 혼잡제어가 없고, 수신측의 허용치마저 고려하지 않기 때문에 신뢰성은 부족하지만 빠르게 데이터를 전송할 수 있습니다. 그래서, 데이터의 신뢰도가 중요한 상황에서는 예를들어, HTTP프로토콜로 된 웹페이지 문서와 같은 경우에는 TCP를 사용하는 것이 좋겠지만, 실시간 Streaming 서비스와 같이 데이터의 신뢰성보다는 빠른 속도를 지향해야 하는 경우에는 UDP프로토콜을 사용하는 것이 옳다고 판단되어집니다.

 

 

 

DNS는 reliable해야할 것 같은데 왜 UDP를 사용할까?

일단 TCP는 3way handshake를 사용함으로써 연결지연이 발생하는 반면에 UDP는 연결을 위한 선행과정이 없고 Connection을 유지할 필요 없다는 것입니다. DNS는 HOST측에서 한번의 패킷 송수신으로 서비스가 완료되어 자료의 순서가 바뀔 염려가 없기 때문에 reliable이 어느정도 보장되어 있습니다. 그리고 DNS Request 사이즈 자체가 작아서 UDP Segment에 더 알맞습니다. UDP자체는 비신뢰성이 지향되어 있지만 application 단에서 timeout이나 resend작업을 통해서 신뢰성을 보완할 수 있습니다. 따라서, DNS Query과정에서는 UDP를 사용하게 됩니다. 하지만, TCP를 사용하는 경우도 있습니다. 대표적인 경우가 Zone Transfer가 있습니다. DNS는 도메인명을 IP주소로 변환하는 네임서버가 구축되어야 하고 이에 따라서 도메인명과 IP주소에 대한 데이터베이스가 필요한데 그것이 바로 Zone File입니다. 이제 DNS는 관리 측면에서 서버를 이중화할 수 있는데 Master와 Slave로 구분해서 Zone FIle을 직접 관리하는 권한을 가진 Master Name Server에 장애가 발생한 경우에 Slave Server에서 서비스를 중단없이 지속적으로 제공하게됩니다. 따라서 Slave Server도 Zone File을 가지고 있어야 하기 때문에 Master Name Server의 Zone File을 Slave Name Server에 동기화하는 것을 Zone Transfer입니다. 이때에는 데이터의 양이 많고, 무결성을 보장해야하기 때문에 TCP 프로토콜을 사용하게 됩니다.

 

대칭키와 공개키

SSL디지털 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서이다.

1. 클라이언트가 서버에 접속한 직후 서버는 클라이언트에게 이 인증서 정보를 전달한다

2. 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지 검증한 후에 다음의 절차를 수행한다

 1) 통신 내용이 공격자에게 노출되는 것을 막을 수 있다.

 2) 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 판단할 수 있다.

 3) 통신 내용의 악의적인 변경을 방지할 수 있다.

 

SSL의 핵심은 암호화이며 암호화 종류는 대칭키와 공개키가 있다.

 

대칭키 암호화 방식

암호화와 복호화에 같은 암호키 즉, 대칭키를 사용하는 알고리즘(DES,3DES,SEED..)입니다. 이 방식은 송신측과 수신측이 서로 동일한 키를 기준으로 암호화하고 복호화하기 때문에 속도가 빠르다는 장점이 있습니다. 하지만, 키를 교환하는 도중에 키가 탈취될 수 있는 문제가 있고 키값을 알게되면 암호화된 메시지를 복호화 할 수 있어서 보완적인 문제가 발생하게 됩니다.

EX) LOVE를 MPZF로 암호화(대칭키 알고리즘 = 대칭키: 알파벳-1)하여 전송, 수신자는 MPZF를 복호화((대칭키 알고리즘 = 대칭키: 알파벳-1)를 통해 복호화

공개키 암호화 방식

공개키는 대칭키에서 암호키 전달로 인한 보완문제를 해결한 암호화 방식입니다.

자신이 가지고 있는 고유한 암호키(개인키)로만 복호화할 수 있는 공개키를 대중에게 공개하는 방식입니다.

예를 들어, A가 B에게 데이터를 보낸다고 할 때, A는 B의 공개키로 암호화한 데이터를 보내고 B는 본인의 개인키로 해당 암호화된 데이터를 복호화해서 보기 때문에 데이터는 B의 공개키에 대응되는 개인키를 갖고 있는 B만이 볼 수 있게됩니다.

= 나한테 데이터를 보낸다고? 그럼 공개키 올려놓을테니까 이거로 암호화해줘, 내 개인키로 해독해서 볼게

1. B는 공개키와 개인키 한쌍을 생성합니다.

2. B는 공개키를 공개합니다.

3. A가 B의 공개키를 받아옵니다.

4. A가 B의 공개키를 사용해 데이터를 암호화합니다.

5. 암호화된 데이터를 B에게 전송합니다

6. B는 암호화된 데이터를 개인키로 복호화합니다.

하지만, 암호화하는 키는 공개키이고 복호화하는 키는 개인키이기 때문에 서로 다르다는 차이로 인해 암호화와 복호화가 매우 복잡해지게 된다는 문제점이 있습니다.

 

따라서, 대칭키와 공개키 암호화 방식을 적절히 혼합해볼 수 있는데

대칭키 암호화에서 문제가 되었던, 대칭키를 교환하는 과정에서만 공개키 암호화 방식을 사용하여 교환하고 이후에는 계속 대칭키 암ㄴ호화 방식으로 통신하는 것입니다.(일단 대칭키를 공개키로 서로 교환하고 대칭키를 복호화하면 앞으로 대칭키로 이용함)

이 방식이 SSL 암호화 프로토콜 탄생의 시초가 되기도 하였습니다.

1. A가 B의 공개키를 통해 대칭키를 암호화하여 B에게 보냄

2. B는 개인키로 암호화된 대칭키를 복호화함

3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화해서 A에게 보냄

4. A는 자신의 대칭키로 암호문을 복호화함

5. 앞으로 이 대칭키로 암호화를 통신함.

 

Http와 Https

Http는 웹서버와 사용자의 브라우저 간에 웹 서비스를 구성하는 문서를 전송하기 위한 통신 규약 즉, 프로토콜입니다. 사용자가 어떤 웹에 방문해서 브라우저를 통해 문서를 요청하게되면 웹 서버는 요청에 대한 응답으로 문서를 전달하는 방식으로 이루어지는데 이 과정에서 Http는 평문화된 텍스트 기반의 데이터를 주고받는다는 것입니다. 즉, 중요한 자료의 경우에는 암호화과정이 없기 때문에 보완상에 문제가 발생할 수도 있게되는 것입니다.

 

따라서 HTTP옆에 Secure의 s를 붙인 HTTPS가 등장하게 된 것입니다. HTTPS는 서버와 클라이언트가 소켓을 통해 통신을 할 때, 일반 텍스트가 아니라 SSL이나 TLS프로토콜을 통해서 암호화된 데이터 기반의 통신을 진행하며 대표적으로 대칭키 암호화 방식과 공개키 암호화 방식을 통해서 시스템을 구축하게 됩니다. 

 

HTTPS의 통신 흐름

1. 먼저 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해서 공개키(암호화)와 개인키(복호화)를 만듭니다.(공개키로 암호화해서 보내라 내가 개인키로 해석해서 디비에 저장하든 연산을하든 할게)

2. 그 다음에 신뢰할 수 있는 CA 기업을 선택하고 그 기업에 내 공개키를 관리해달라고 계약을 합니다.

3. 계약을 완료한 CA 기업은 또 CA 기업만의 공개키와 개인키가 있습니다.

CA 기업은 CA기업의 이름과 A서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공합니다.(CA는 개인키로 암호화를 하고, 신뢰할만한 CA의 공개키는 브라우저가 가지고있어서 해석함)

4. A서버는 암호화된 인증서를 갖게 되었습니다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청(Request)이 오면 이 암호화된 인증서를 클라이언트에게 줍니다.

5. 이제 클라이언트 입장에서, 예를 들어 A서버로 index.html 파일을 달라고 요청했습니다. 그러면 HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게되겠지요.

6. 여기서 중요합니다. 세계적으로 신뢰할 수 있는 CA 기업의 공개키는 브라우저가 이미 알고 있습니다!

7. 브라우저가 CA 기업 리스트를 쭉 탐색하면서 인증서에 적혀있는 CA기업 이름이 같으면 해당 CA기업의 공개키를 이미 알고 있는 브라우저는 해독할 수 있겠죠? 그러면 해독해서 A서버의 공개키를 얻었습니다.

8. 그러면 A서버와 통신할 때는 A서버의 공개키로 암호화해서 Request를 날리게 되겠죠.

9. A서버는 A서버의 공개키로 암호화된 데이터를 개인키로 해석하여 연산을하든 저장을하든 하게된다.

 

A서버가 공개키 개인키를 만든다 -> CA에 등록한다 -> CA가 A키의 공개키를 자신들의 개인키로 암호화하여 인증서를 만들어서 A서버에게 준다 -> 클라가 A서버에게 문서를 요청하면 A서버는 클라에게 인증서를 준다 -> 클라의 브라우저는 CA의 공개키를 가지고 인증서를 해석한다 -> 인증서에 A서버의 공개키가 있으니 그것으로 암호화 해서 A서버에게 request를 날린다 -> A서버는 개인키로 해석한다

 

CA가 신뢰받는 기업이 아닌 자체 인증성 발급기관인 경우는 위험할 수 있다.

 

로드밸런싱

인터넷 사용이 보편화되면서 점점 더 많은 클라이언트들이 서버에 데이터를 요청하게되는데, 많은 클라이언트들에 대한 모든 트래픽을 서버 한대가 감당하기에는 많이 부족해졌습니다. 따라서, 이에 대한 대응 방안으로 Scale UP하는 방안도 있지만 여러대의 서버거 나눠서 일하도록 만드는 Scale Out방법이 더 많이 지향되고 있습니다. 이렇게 여러 서버에게 균등하게 트래픽을 분산해주는 것이 로드밸런싱입니다. 서버를 운영하는 웹사이트의 규모에 따라서 웹 서버를 추가로 증설하고 이를 로드밸런서를 이용해서 관리해주면 웹 서버의 부하를 해결할 수 있습니다.

 

로드 밸런서가 서버를 선택하는 방식

1) 라운드 로빈 : CPU 스케줄링에서 사용하는 라운드 로빈 방식과 동일하게 로드밸런서가 서버를 선택하는 방식이 있습니다.

2) Least Connections : 연결 개수가 가장 적은 서버를 선택하는 방식입니다.(트래픽으로 인해 세션이 길어지는 경우에 권장되는 방법입니다.)

3. Source : 사용자의 IP를 해싱하여 분배하는 방식입니다.(특성 사용자가 항상 같은 서버로 연결되는 것을 보장하는 방식입니다.)

로드 밸런스가 고장난 경우에는 로드밸런스를 이중화해서 Active중인 메인 로드밸런서에 문제가 발생한 경우 Passive상태였던 서브 로드밸런스를 활성화시켜서 동작하는 방안으로 진행하게됩니다.

 

Blocking & Non-Blocking I/O

Blocking I/O 형태의 작업은 Process 혹은 Thread가 Kernel에게 I/O를 요청하는 함수를 호출하면 I/O작업이 진행되는 동안 User Process는 제어권을 잃고 자신의 작업을 잠시 대기하고 있습니다. Kernel이 작업을 완료하면 제어권과 함께 결과값을 반환하여 User Process가 제어권을 다시 획득하고 남은 작업을 실행합니다.

=> 여러 클라이언트가 접속하는 서버를 Blocking으로 구현하면, 한 클라이언트가 I/O요청을 하게되면 다른 클라이언트의 작업이 중단되기 때문에 Client별로 별도의 Thread를 구현하게되는데 그러면 접속자수가 많아짐에 따라 자원도 낭비하게되고 Context Switching회수도 증가하게 됩니다.

 

Nonblocking I/O 형태의 작업은 Kernel에서 I/O작업이 진행되는 동안 User Process의 작업이 중단되지 않는 것입니다. 만약 User Process가 Nonblocking으로 I/O를 요청하면 Blocking과 마찬가지로 제어권이 넘어가게 되는데, Blocking과는 다르게 결과값과 제어권이 함께 반환되는 것이 아니라 제어권이 곧바로 넘어오게되어 User Process가 일을 이어서 할 수 있습니다. 물론 결과값도 반환이 되는데 일을 다 마치지 못했다라는 오류문이 결과값으로 오게됩니다. 그러면 받고자 하는 결과값이 올때까지 이 일을 반복하게되고 결과문이 나오면 그 때 온전한 값을 리턴받게 됩니다.

 

Sync Async의 개념이 추가

제가 Blocking과 nonBlocking에 Sync Async개념이 추가되었을 때 이해했떤 것은 Sync는 상대방이 결과값을 반환하는 것을 신경쓰는 것, Async는 상대방이 결과값을 반환하는 것에 신경쓰지 않는 것으로 이해했습니다.

예를 들어서, Sync-Nonblocking의 경우에는 A가 B를 호출해서 제어권이 넘어가더라도 즉시 반환이 되지만 결과값은 결과값은 아직 미완됐다는 메시지를 받습니다. 따라서, 결과값을 받을때까지 계속 신경쓰면서 온전한 결과값을 받을때까지 계속 확인을 합니다. 하지만 Async-Nonoblocking의 경우에는 A가 B를 콜백함수와 함께 호출하고 신경을 쓰지 않고 다른일을 하다가, B에서 조건이 완료되면 Callback함수가 호출되어 결과가 반환되는 즉, 간접적으로 결과값이 반환되는 것을 이해했습니다.

Async-Blocking의 경우에는 Blocking이다보니 함수를 호출하면 제어권이 넘어가서 대기상태로 들어가기 때문에 Sync Blocking과 별반 다른점이 없지만, Callback함수와 함께 호출해서 결과값을 Callback호출로부터 받게됨으로부터 간접적으로 결과값을 받는다 즉, 신경쓰지 않고있다가 결과값을 간접적으로 받았다라고 이해했습니다.