프로그래밍 메모장

가끔 공부하다보면 anycast란 내용이 보이길래 요약겸 정리해논다.

Anycast

Anycast는 각각 동일한 IP 주소가 할당된 엔드포인트 그룹에 여러 라우팅 경로를 제공하는 기술 - microsoft

??? 이렇게 말하면 무슨 말인지 감이 잡히지 않는다.

보통 우리가 알고 있는 IP는 '고유한' 주소이고, Unicast IP이다. 

우선 unicast가 뭔지 알고 넘어가야 될꺼 같다.

참고)

유니캐스트 (Unicast) - 1 : 1 

유니캐스트는 정보를 전송하기 위한 프레임에 자신의 MAC 주소와 목적지의 MAC 주소를 첨부하여 전송

브로드캐스트 (Broadcast) 1 : N

브로드캐스트 방식은 로컬 네트워크에 연결되어 있는 모든 시스템에게 프레임을 보내는 방식

멀티캐스트(Multicast) 1: N (특정 그룹)

멀티캐스트는 네트워크에 연결되어 있는 시스템 중 일부에게만 정보를 전송하는 것으로 특정 그룹에 속해 있는 시스템에게만 한 번에 정보를 전송할 수 있는 방법

라우터가 멀티캐스트를 지원해야만 사용 가능하다는 단점

멀티캐스트 전송이 지원되면 송신자는 여러 수신자에게 한 번에 메시지가 전송되도록 하여

데이터의 중복 전송으로 인한 네트워크 자원 낭비를 최소화할 수 있게 된다.

멀티캐스트 전송을 위해서는 헤더에 수신자의 주소 대신 수신자들이 참여하고 있는 그룹 주소를 표시하여 패킷을 전송한다.

Anycast란?

Anycast IP는 서로 다른 호스트끼리 동일한 IP 주소를 가질 수 있는 개념이다.

링크 계층(L2)에서 맥 주소를 보고 데이터를 전달할때는 충돌이 일어나면 사용이 불가능하지만

라우터(L3)에서는 네트워크 라우팅 알고리즘(BGP)을 통해 가장 가까운곳으로 판단되는 쪽으로 사용 가능한 식으로 구현되어 있다. 

anycast는 주로 DNS 서비스에 많이 활용되고 있다는데 지역별로 DNS 서버를 분산하고, 항상 네트워크 경로상 가까운 DNS 서버가 응답하게 된다.

왜 이런 구조를 사용하냐면 root DNS에 하위 DNS 서버들이 계층적으로 쌓여있는 기존 구조에서는 네트워크 DNS DDos 공격이나 웜 공격등으로 root DNS가 마비되게 되면 전 세계 DNS가 마비되게 된다. 그래서 DNS를 적절히 분산 구성해 분산 처리 및 가까운 거리로 인한 네트워크 지연 감소 등 여러 이유로 사용하고 있다고 한다.

가장 유명한 예시로는 구글의 public DNS IP 8.8.8.8 이 anycast로 구성되어 있고,

전세계 국가에 분산되어 있다고 한다. 

장점

- L4/L7 로드밸런싱 장비 대신 쓰기 가능?(라우팅+서버)

- 사용자와 네트워크 적으로 가장 가까운 곳으로 안내

- L4/L7 이 대규모 트래픽 처리가 힘든데 서버로 바로 트래픽을 보내니 대규모 트래픽 처리에 용이

- 회선문제로 장애시 자동으로 다른곳으로 우회(회선 이중화 비용 절감)

- 오픈소스 -> 가격 X!

단점

- 네트워크 적으로 가장 가까운곳 !== 지리적으로 가까운곳

ISP 마다 라우팅 정책이 다르므로 제어가 힘들다.

- 라우터에서 라우팅만 하기 때문에 L4/L7에선 가능한? 서버의 상태 체크(죽었나 살았나)가 안된다는 단점

reference 

https://docs.microsoft.com/ko-kr/windows-server/networking/dns/deploy/anycast

https://tech.kakao.com/2014/05/29/anycast/

엄청 헷갈리는 개념이라 메모해두려고 한다.

URI (Uniform Resource Identifiter - 통합 자원 식별자)

웹 기술에서 사용하는 논리적 or 물리적 리소스를 식별하는 고유한 문자열 시퀀스

주소보다는 '식별자'의 개념

URL (Uniform Resource Locator)

네트워크 상에서 웹 리소스에 대한 참조

흔히 웹 주소라고 한다.

우리가 주로 쓰는 주소가 URL

URL은 URI의 서브셋이다.

URI - 식별자

URL - 위치

URN (Uniform resource name)

URI의 특정 포맷중 하나로 이름으로 리소스를 특정하는 URI 

프로토콜을 제외하고 리소스의 name 을 가리키는데 사용

URN에는 접근 방법 & 위치가 표기 X

참고) URL 구조

scheme:[//[user[:password]@]host[:port]][/path][?query][#fragment]

scheme : 사용할 프로토콜을 뜻하며 웹에서는 http 또는 https를 사용

user와 password : (서버에 있는) 데이터에 접근하기 위한 사용자의 이름과 비밀번호

host와 port : 접근할 대상(서버)의 호스트명과 포트번호

path : 접근할 대상(서버)의 경로에 대한 상세 정보

query : 접근할 대상에 전달하는 추가적인 정보 (파라미터)

fragment : 메인 리소스 내에 존재하는 서브 리소스에 접근할 때 이를 식별하기 위한 정보

reference

https://www.charlezz.com/?p=44767 

https://mygumi.tistory.com/139

수학적으로 멱등성이란

어떤 집합이 연산 A에 대해 닫혀있을때, 연산 A를 여러번 적용해도 달라지지 않는 성질을 뜻한다.

네트워크 HTTP 에서 멱등성이란

동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고,

서버의 상태도 동일하게 남을 때, 해당 HTTP 메서드가 멱등성을 가졌다고 말한다.

다만 서버가 REST API를 잘 따랐다는 전제하에 멱등성 제약이 보장된다.

(ex : 서버가 get으로 CRUD 전체를 다 처리한다던가 restful하지 않게 구현되어 있다면 멱등성 보장 X)

멱등성이 성립하는 기준

멱등성은 요청의 효과를 보고 판단한다.

같은 행위를 여러번 반복하더라도 같은 효과를 가져야한다.

많이 쓰이는 http method중 POST를 제외한 GET, PUT, DELETE 가 멱등성이 보장되고,

그외 method로는 OPTIONS, HEAD 등이 있다.

예를 들어 PUT의 경우

PUT /user/4

라는 요청이 간다면 4번째 유저가 없다면 생성되고, 있다면 update 되는 형식으로 동작할것이다.

그런데 PUT 요청을 여러번 보내더라도 항상 4번 유저는 요청된 값과 똑같은 값으로 갱신하니

같은 상태일 것이다.

DELETE도 비슷한 방식으로 동작하고, GET, OPTIONS, HEAD 같은 경우는 조회(read) 동작만 하므로

항상 서버의 상태는 동일하다고 기대할 수 있다.

다만 PATCH(리소스의 일부만 수정)의 경우 멱등성이 보장이 되지 않는다.

예를 들어

PATCH users/1
{
    $increase: 'age',
    value: 1,
}

같이 increase하고 싶은 변수 이름과 값을 보낸다고 해보자.

그럼 PATCH를 보낼때마다 상태가 변경되니 멱등성을 기대할 수 없다고 볼 수 있다.

안전한 메소드

그럼 안전한 메소드란?

서버의 상태를 아예 변경시키지 않는 메소드를 말한다.

해당 메소드로는 GET, OPTIONS, HEAD 등 read 메소드들이 있다

https://velog.io/@dion/HTTP-%EB%A9%94%EC%86%8C%EB%93%9C%EC%9D%98-%EB%A9%B1%EB%93%B1%EC%84%B1-%EA%B7%B8%EA%B2%8C-%EB%AD%94%EB%8D%B0

https://oen-blog.tistory.com/211

https://developer.mozilla.org/ko/docs/Glossary/Idempotent

3-way handshake와 4-way handshake는 TCP 프로토콜에서 연결을 시작/종료할때 쓰는 방식이다.

우선 TCP부터 알아보자.

TCP

TCP란 연결 지향적 프로토콜로 데이터패킷을 주고받을때 신뢰성을 보장한다.

그외 특징으로는

• 흐름 제어, 혼잡 제어, 오류 제어
• UDP보다 느린 대신 OSI 4계층(transport)에서 신뢰성 보장
• 파일을 분할해서 전송(MSS)
• 연결형 서비스로 가상 회선 방식을 제공

신뢰성을 보장하는 방식으로는 패킷을 보낸 후, 수신 확인(ACK)를 받는다.

제한시간내에 ACK가 오지 않는다면 패킷이 네트워크 중간에 손실되었다고 가정하고 다시 보낸다.

따라서 해당 방식때문에 신뢰성을 보장하지만 느리다.

(혼잡제어나 패킷을 보내는 방식은  흥미로운 부분이라 나중 글을 관련 부분으로 더 쓸 예정)

3-way handshake

연결하기 위해 두 장치의 논리적 접속을 성립하기 위해 사용하는 연결 확인 방식이다.

3번의 확인을 거친다고 해서 3 way handshake라 부른다

tmi) 4계층(transport)는 host 프로세스와 guest 프로세스 간 양 호스트 종단의 논리적 통신을 보장하고,

3계층(network)는 host와 guest 간 논리적 통신을 보장한다.

접속 시도시 client는 SYN 패킷을 보내 server에 접속 요청을 보낸다.

서버는 SYN 패킷을 받으면 접속이 가능하다는 의미로 client에세 SYN과 ACK 패킷을 보낸다.

client는 서버에세 SYN+ACK 패킷을 받았다면 이제 통신을 시작했다는 의미로 ACK를 보내고,

통신을 시작한다.

SYN (synchronize sequence numbers) - 연결 확인을 위해 보내는 무작위의 숫자값

ACK (acknowledgements) - Client 혹은 Server로부터 받은 SYN에 1을 더해 SYN을 잘 받았다는 ACK

ISN (Initial sequence numbers) - Client와 Server가 각각 처음으로 생성한 SYN

- SYN의 값에 무작위 수를 사용하는 이유?

• Connection을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용된다. 따라서 두 통신 호스트가 과거에 사용된 포트 번호 쌍을 사용할 가능성이 존재한다. 서버 측에서 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적인 숫자가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있어 이러한 문제 발생 가능성을 줄이기 위해 ISN을 무작위 난수로 사용하는 것이다.

4-way handshake

4-way handshake는 반대로 가상 회선 연결을 해제할때 주고 받는 확인 작업이다.

4번의 확인과정을 거친다고 하여 4 way handshake라고 부른다.

흔히 client가 close를 요청하고, server가 확인하고 닫는다고 알려져 있는데

서버도 close를 요청할 수 있다.

그래서 먼저 4-way handshake를 요청하는 쪽을 Active Closer, 받는 쪽을 Passive Closer라 한다.

과정을 요약하자면

Active closer가 먼저 서버를 닫고 싶다는 FIN 요청을 보내고 FIN-wait 상태에 들어간다.

그럼 Passive closer는 알았다는 ACK를 보내고, close-wait 상태에 들어간다.

그리고 Passive closer는 통신을 종료할 준비가 완료되면 FIN 을 다시 Active closer에 보낸다.

Active Closer는 FIN을 받았으면 time-wait 과정에 들어가고 ACK를 passive closer에게 보낸다. 

passive closer는 ACK를 받으면 통신을 종료한다.

active closer는 time wait상태에서 대기하다가 통신을 종료한다.

time wait는 

먼저 연결을 끊는 (active closer) 쪽에 생성되는 소켓으로, 혹시 모를 패킷 전송 실패에 대비하기 위하여 존재하는 소켓이다.

time-wait가 없다면 패킷의 손실이 발생하거나 통신자 간 연결 해제가 제대로 이루어지지 않을 수 있다.

읽어보면 좋을 글)

3 way handshake의 과정을 악용한 SYN flooding attack(보안)

https://run-it.tistory.com/51

reference

https://seongonion.tistory.com/74

https://tech.kakao.com/2016/04/21/closewait-timewait/

기존 HTTP 프로토콜은 '요청'과 '응답'으로 이루어진 Client-Server Architecture로 구성되어 있다. 

그래서 클라이언트에서 요청을 하게 되면 서버가 응답 하는 방식으로 구성되어 있는데,

기존 정적인 HTML 파일로 구성된 초기 웹 서비스에서는 실시간 양방향 통신을 할 필요가 없으므로

이런 반이중 통신으로 충분히 웹 홈페이지를 만들어나갈 수 있었다.

그런데 웹을 메신저(페이스북 등?)처럼 쓰거나 게임, PWA(웹앱)등 다양한 용도로 사용하기 시작하면서

실시간 양방향 통신 방식이 필요하게 되었는데

pooling, long pooling, streaming 방식은 기존 HTTP 프로토콜 방식에서 양방향 통신(처럼) 작동하려고

노력한 일종의 시도이다.

최근엔 WebSocket이라는 양방향 통신을 제공하는 새로운 프로토콜이 생겼지만

js의 socket.io는 브라우저가 만약 웹 소캣을 지원하지 않으면 pooling, long pooling, streaming 방식으로 자동 치환되서 작동한다고 하니 pooling, long pooling, streaming에 대해 알아놓으면 좋을것 같다.

Pooling 방식

pooling 방식은 가장 간단하다.

주기적으로 서버에 클라이언트가 AJAX request를 보내 발생하는 이벤트를 계속 체크하는 것이다.

주기가 짧아지면 신속하게 받아올 수 있지만, 불필요한 요청/응답 트래픽이 자주 발생한다. 

요청에 대한 서버 부담이 크지 않거나 실시간 메시지 전달이 크게 중요하지 않은 서비스에 적합하다. 

Long Polling 방식 

Long Polling 방식은 실시간 메시지 전달이 중요하지만 서버의 상태 변경이 빈번히 발생하지는 않는 서비스에 적합하다.

Long-Polling 방식은 서버에 요청을 보내고 서버 이벤트가 발생할 때까지 연결을 유지한다. 이 상황에서 이벤트가 발생하면 응답을 받아서 처리하고 그 즉시 또 다른 이벤트를 받기 위해 연결을 맺는 방식이다. 

Long Polling 방식은 보통 서버 응답을 무한정 기다리는 게 아니라 특정 시간이 지나면 해당 요청/응답 트랜잭션을 완료하고 새로이 요청하는 방식으로 구현한다. (이것은 스트리밍 방식도 동일하다)

만약 상태변경이 빈번하고, 그것을 client에 계속 알려주게 된다면 상태 변경 이벤트가 발생할때마다 polling 방식보다 과부하가 더 많이 발생할수도 있다.

streaming 방식

스트리밍 방식은 한 번 요청 후 응답을 완료하지 않고 해당 응답 스트림으로 필요할 때마다 데이터를 전송하는 방식이다.

long polling 방식과 다른 점은 long pooling은 이벤트를 받으면 종료하고 바로 다시 연결을 시도하지만 streaming 방식은 연결을 계속 유지하고 HTTP/1.1 의 Chunked 인코딩 방식을 이용해 이벤트가 발생할때마다 서버에서 클라이언트로 결과를 전송한다.

streaming은 서버의 상태 변경이 매우 잦은 경우 유리하지만 연결을 길게 맺고 있는 경우 연결의 유효성 관리 등의 부담이 발생한다. 

해당 방식들은 설명만 훑어봐도 네트워크로 통신하는데 엄청한 cost가 발생할것이라고 예측할 수 있다.  (유감스럽게도 소켓도 마찬가지다)

로드밸런서나 pub-sub pattern을 사용한 서버의 수평 스케일 확장으로 과부하되는 트래픽을 분산하려고 시도할 수 있다고 까지는 들었다..

같이 읽어보면 좋을 글들)

단방향, 반이중, 전이중 통신

  https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=cashy72&logNo=80013187033 

PWA (웹앱)

https://perfectmoment.tistory.com/1632

Socket.io

https://edu.goorm.io/learn/lecture/557/%ED%95%9C-%EB%88%88%EC%97%90-%EB%81%9D%EB%82%B4%EB%8A%94-node-js/lesson/174379/web-socket%EC%9D%B4%EB%9E%80

reference 

https://d2.naver.com/helloworld/1052