Computation suite

라우팅 프로토콜 라우터 간 통신 방식을 규정하는 통신 규약. 다음 3가지 클래스가 IP 네트워크에 널리 사용된다. 링크 스테이트 라우팅 프로토콜을 통한   내부 게이트웨이 라우팅 경로 벡터 OR 거리 벡터 프로토콜을 통한   내부 게이트웨이 라우팅 외부 게이트웨이 라우팅    BGP 경계 경로 프로토콜    자율 시스템 사이에서    트래픽을 교환할 목적으로 인터넷에 쓰임. AS(Autonomous System) 인터넷에 대한 라우팅 정책을 대표하는 하나 이상의 네트워크 운영자의 통제 하에서 각기 연결된 인터넷 프로토콜 라우팅 접두사의 모임이다. 인터넷은 ISP의 라우팅 정책만을 주시한다. 인터넷이 주시하는 ISP 는 공식적으로 등록된  (ASN, 자율 시스템 번호) 를 소유하고 있다. 2007년까지 16비트였다가 -> RFC 4893에서 32비트의 AS 번호 도입.  IGP 내부 게이트웨이 프로토콜은 1개의 라우팅 도메인 안에서 라우팅 정보를 교환한다. EX ) OSPF, RIP, IS-IS, EIGRP IGRP Cisco 사에서 발명한 거리 벡터 내부 게이트웨이 프로토콜(IGP). 자율 시스템 내  라우팅 데이터를 교환 할 목적으로 라우터 가 사용하는 프로토콜이다. 대역폭 , 지연, 부하 MTU, 신뢰성을 포함하여 개별 경로에 여러 개의 메트릭을 지원하며 2개의 경로를 비교할 때, 이 메트릭들은  미리 설정된 상수들을 사용해서 수정할 수 있는 공식을 이용하여 하나의 메트릭으로 병합된다. EIGRP(구 IGRP) IGRP 업그레드 버전. IGRP에서 고려했던 대역폭, 처리 능력도 이용할 뿐 아니라 네트워크 토폴로지 변경 후 생기는 불안정한 라우팅을 최소화 하는 고급 거리 벡터 라우팅 프로토콜이다. EIGRP를 지원하는 라우터들은 IGRP의 이웃 장비들에게 경로 정보를 자동으로 재분배한다. 이 때 사용되는 라우팅 최적화 기법은 대부분 SRI사의 확산 ...

blocking / non-blocking Blocking socket mode 소켓 함수 호출 시, 조건이 만족되지 않으면  함수가 r eturn하지 않고 스레드 실행이 그 위치에서 정지 한다. 조건이 만족될 때, socket 함수가 return하며 정지 상태의 스레드가 깨어난다.(wake-up) 그리고 작업을 재개한다. 조건이 만족되는 시점이 길어지면 교착 상태로 인해 스레드가 오랜 시간 정지할 수 있다. 다른 스레드가 있다면 TerminateThread() 함수를 호출해 강제 종료시키거나 주 스레드가 종료되어 모든 스레드가 종료되기를 바래야한다. Non-blocking socket mode 소켓 함수 호출시, 조건이 만족되지 않아도 일단 함수가 return 한다. (이 때, 조건이 만족되지 않았다는 오류를 리턴한다.) 때문에 중단 없이 다음 코드를 계속 수행한다. 멀티스레드를 사용하지 않고도 싱글스레드로 여러 소켓을 번갈아가며 입출력 처리를 할 수 있으며 중간에 다른 작업을 수행할 수 있다. 그러나 위에서 말한 '조건이 만족되지 않았다는 오류'를 처리해야한다. 클라이언트가 없어도 계속 cpu자원을 소모하여 함수 return 로직을 수행하기 때문에 blocking 소켓보다 CPU 사용률이 높다. 윈도우에서 제공하는 Select 모델을 사용하면 소켓 함수 호출 성공시점을 미리 알 수 있다. 블록킹 소켓의 단점인 교착상태 돌입 위험과 넌블록킹 소켓의 단점인 '조건 불충족 오류' 처리 로직을 해결할 수 있다. 동기 입출력 / 비동기 입출력 동기 입출력 ( synchronous I/O ) 1. 응용 프로그램이 입출력 함수를 호출하고,    입출력 작업이 끝날 때까지 기다린다. 2. OS는 입출력 작업을 커널 모드에서 수행한다. 3. 커널 모드의 입출력 작업이 완료되면 입출력 함수가 리턴한다. 4. 응용 프로그램은 리턴된 값을 처리하거나     다른 작업을 진행한다. 입출력 작업이 완료될 때까지 기다린다. 비동기 입출력 (...

이런 저런 채용공고를 둘러보다가 이런 개발 세상도 있구나~ 하고 잠깐 조사했다. 윈도우 운영체제에서 제공하는 기술이라 생소한 용어들이 많다. 윈도우의 소켓 입출력 모델을 사용한다는 것은? 윈도우는 다양한 소켓 입출력 모델을 제공한다. - Select, WSAAsyncSelect, WSAEventSelect - Overlapped(1), Overlapped(2) - Completion Port 윈도우에서 제공하는 소켓 입출력 모델을 활용한다는 것은 새로운 전송 프로토콜을 작성하는 것이 아니다. TCP나 UDP와 같은 전송 프로토콜은 유지하되, 종단에서 Socket(구조체/인터페이스)이 어떻게 데이터를 Read/Write 할 지 로직을 작성하는 것이다. 즉, 여기서 데이터를 인출하고, 데이터를 쓸 때의 효율 을 따지는 과정이다. 많은 연결이 서버에서 이뤄지고 연결당 계산이 무거운 경우, User 모드와 Kernel 모드에서 자원 분배가 효율적으로 이뤄진다면 ( CPU/메모리 ) Response time을 줄일 수 있다. Raw Socket과 차이 앞서 설명한 소켓 입출력 모델의 전제는 소켓으로서 TCP 소켓이나 UDP 소켓을 사용한다는 것이다. 데이터를 전송할 때, 네트워크 계층을 내려가며 운영체제가 프로토콜 헤더를 붙여서 패킷을 제작한다. Raw socket을 사용하면 애플리케이션 단에서 직접 프로토콜의 헤더 일부를 생성할 수 있다. 헤더 일부를 직접 생성함으로서 세부적으로 제어할 수 있지만 그만큼 동작이 복잡해진다.

Proxy = 대신/대리 네트워크에서 proxy는 client나 server를 대신하여/대리하여 요청을 전달한다. 물리적인 위치는 사용자의 컴퓨터일 수도 있고 사용자의 컴퓨터 - 목적지 중간의 한 지점일 수 있다. 왜 대신하는가? 캐싱 자주 요청되는 리소스 or 자주 변하지 않는 리소스의 경우 proxy 서버에 리소스를 저장할 수 있다. - (본 목적지까지 전달했던) network hop을 줄일 수 있다. - 리소스가 캐싱된 스토리지에 따라 더 빠른 응답 시간를 얻을 수 있다. 보안 내부망과 인터넷이 소통하는 지점인 게이트웨이로서 작동. 로그 물리적인 서버, 또는 로컬 컴퓨터에 쌓인 기록을 바탕으로 보안 정책을 구성할 수 있음. 우회 보안과 공통적인 면이 있다. 자신의 실제 IP가 아닌 프록시가 대신 요청을 수행하고 응답을 대신 받아서 본인에게로 전송해준다. 목적 리소스가 있는 컴퓨터에서는 프록시가 요청을 수행한 것으로 인식하고 프록시에게 응답을 돌려준다. Forward proxy 대 Reverse proxy Forward proxy(= gateway, proxy) 1. 클라이언트, 클라이언트 풀에서 나가는 요청 에 대한 제어 수행. 클라이언트는 요청의 출발지 주소를 프록시 주소로 대신 사용함으로서 클라이언트의 원 정보를 숨길 수 있으며 우회 기능을 사용할 수 있음. ex) Tor의 여러 프록시 서버 노드를 경유하는 proxy chaining 요청에 대한 들어오는 응답 에 대한 제어 또한 수행하며 클라이언트 풀의 각각의 클라이언트에게 응답을 돌려준다. 2. HTTP 터널링을 통한 암호화 프록시 서버가 클라이언트 대신 인터넷을 연결한다. TLS를 지원하는 웹 서버에 proxy 서버를 사용하여 연결한다. (http1.1부터 connect method로 TLS tunnel을 사용할 수 있음) connect method가 평문 형태의 http proxy를  ssl 암호화된 요청을 tcp/ip 터널로 전환한다. - client가 http proxy 서버에게 t...

서버 개발이 나의 주된 업무이므로, 서버단 socket.io 설정 위주로 설명함. socket.io 클라이언트- socket.io 서버 구성 프론트엔드 코드가 무사히 사용자 브라우저에 전달되고 사용자의 브라우저가 호환된다면 js기반의 socket.io로 통신할 준비를 마치게된다. 여기서 서버측은 python-socketio의 패키지를 사용한다 가정. socket.io 프론트엔드 서버 - 백엔드 서버 구성 이번에는 node.js 서버가 django 백엔드 서버를 호출하고, django는 동기식 rest api를 사용한다 가정하자. 전체구조를 살펴보면 다음과 같다. [ Client ] <-Socket.IO-> [ Node.js Server ] <-HTTP-> [ Django REST API ] <-ORM-> [ Database ] client - node.js 사이에 활성화돼있는 연결이  django rest api를 호출한 후 응답을 받기까지는 동기식으로 처리된다. 때문에 django rest api - database 라인의 최적화 처리가 되어있지 않으면 node.js 서버가 응답받는 시간이 늘어나고 client 또한 응답을 늦게 받을 수 있다. 어느 서버에 탑재할 것인가? WSGI, ASGI 서버 비동기 통신에 기반하기 때문에 socket.io가 어느 서버 환경에서 실행되는 지 중요하다. 따라서 socket.io 서버 객체를 만들 때 - async_mode - cors_allowed_origins - logger 의 옵션 중에 async_mode에 비동기 처리 설정을 해주어야한다. WSGI 서버 -> Client - Server ASGI 서버 -> AsyncClient - AsyncServer gunicorn과 같은 WSGI 서버에서 python-socketio 사용을 위해서는 python2, 3에서 coroutine을 사용한 동시성 네트워킹을 지원하는 eventlet 라이브러리가 설치돼있어야한다. 설치시 g...

Socket.IO Socket.IO는 클라이언트-서버 사이에 실시간 양방형 통신을 가능하게 하는 오픈소스 라이브러리. 양방향이며 이벤트 기반이다. (양쪽에 등록된 이벤트를 탐지하여 로직을 수행한다.) 본래 node.js를 바탕으로 만들어진 기술이지만 현재는 다양한 언어로 구현되어있다. WebSocket protocol 기반이며 raw WebSocket에서 제공하는 기능에 이어 추가적인 기능들을 제공한다. Engine.IO와 Socket.IO socke.io의 핵심 프로토콜 기능이 담겨있다. socket.io는 Engine.IO를 기능을 사용하여 작동한다. engine.io는 cross-browse호환성을 제공하며 연결 관리(및 프로토콜 업그레이드), fallback 동작을 수행한다. socket.io는 개발자가 용이하게 애플리케이션을 구현할 수 있도록 namespace, room, 이벤트 기반 통신을 기능을 제공한다. WebSocket과 다른 특징 간단하게 말해서 기능이 더 많다. - websocket은 socket.io에서 채택할 수 있는 양방향 통신 수단 중 하나이고 - websocket이 지원되지 않는 환경(클라이언트나 서버 둘 중 하나가 지원 안 한다던가)에서는    http long polling과 같은 다른 통신 수단을 채택하여 선택한다.    ( JSONP polling도 있었으나 현재는 deprecated )     - 소켓 연결 실패시에는 자동으로 재연결을 시도한다. - 자동 재연결을 제공하기는 하지만 다양한 오류를 핸들링하는 코드를 별도로 구현하여    안정성을 높여야함. - 네임스페이스, 룸, 인증 기능을 활용할 수 있음. Service 사용하기 WebSocket protocol 보다는 편리한 기능이 많고 무료라는 장점이 있지만  유지보수 측면에서 믿고 사용할 수 있는 MS의 Azure SignalR, Google의 Firebase와 같은 전용 클라우드 서비스를 ...

웹소켓 이전 클라이언트-서버간 양방향 통신 기술 polling - 전송할 데이터의 유무에 상관없이    클라이언트가 지정된 시간 간격에 맞춰 주기적으로 요청을 수행한다.    보낼 데이터가 없는 경우 적절히 서버에서 핸들링 해준다. - 대부분의 경우 연결이 많이 필요하다. - 전송할 양에 비해 너무 많은 자원을 소비한다.    보낼 데이터가 없는데도 일단 요청을 받는다. - 서비스 규모가 작은 경우 사용 할만하다. - 서버 push가 불가능하다.(full-duplex가 아니다.) - 매 요청마다 http header가 패킷에 동반되기 때문에   상대적으로 websocket보다 부하가 높다. long polling - polling과 달리 지연 없이 메시지를 전달한다.    polling은 주기에 도달했을 때만 요청을 수행하기 때문에    다음 요청까지 기다려야 데이터를 받을 수 있지만    long polling은 데이터가 생길 때 까지 연결을 닫지 않고 유지한다.(untill timeout)    데이터가 생기면 곧바로 응답한다. - 타임아웃 된 경우에도 응답을 반환한다. - 위의 이유로 폴링보다 성능적으로 향상되었다. - polling보다 실시간성이 높다. - 연결을 닫지않고 유지하기 때문에    연결 유지와 동시 접속 처리에 대한 고려가 필요하다.    ( 계속해서 TCP 연결은 유지되므로 ) HTTP Polling Use-case - 이메일 업데이트 - 날씨 정보 업데이트 스트리밍 - 클라이언트의 요청에 대해 서버는 무기한 연결을 유지한다. - 준비가 되면 데이터를 보낸다. 스트리밍은 앞 2가지 방법에 비해 다음과 같은 개선이 이루어졌다. 과도한 요청의 수를 줄였고 데이터 스트림을 연결 1개로 유지할 수 있다. 하지만 HTTP 헤더가 포함되어있다. HTTP 헤더의 정보량은 꽤 많다. 이 ...

http 1.1보다 비교해서  http 2.0의 어떤 특성들이 속도 향상에 영향을 주는지, 그리고 http/1.1에서 2.0으로 전환시 주의해야 하는 안티 패턴에 대해 공부했다. 이 안티 패턴들은  웹서버의 애플리케이션 레벨 프로토콜을 무조건 http2.0으로 업그레이드한다고 성능이 좋아지지 않음을 의미한다. 대다수의 프로젝트나 서비스의 경우  "이 문제를 해결하기 위해서는 http2.0으로 업그레이드 해야돼요" 보다  시스템 아키텍쳐를 수정하거나 쿼리문을 최적화, 캐싱을 사용하는 등의 안이 더 현실적일 것이다. 소프트웨어 버전을 최신 버전으로 업그레이드 한다고 성능이 좋아진다는 결론은 다소 hacky한 risky한 결론이라고 생각한다. 업그레이드 전에 프로토콜의 업그레이드 해야할 필요성과 업그레이드 시 영향도를 체크해야한다. HTTP 1.1 1.0과 비교해서 다음이 추가되었음. - 웹 서버는 응답 후에도 클라이언트와 TCP 연결을 유지할 수있다. - Range 요청 추가 - OPTIONS 메서드 추가 - Transfer-encoding 추가 - 파이프라이닝 : 클라이언트가 모든 요청을 동시에 서버로 전송하는 기능.   동시에 보내더라도 서버에서는 응답을 위해 어쩔 수없이 직렬화를 해야한다.   (러닝 http/2에 따르면 이를 구현한 서버에서는 제대로 동작하지 않는 경우가 많고    HOL 현상으로 잘 쓰이지 않는다고한다.) HTTP의 대안 SPDY와 HTTP 2 SPDY 구글의 마이크 벨시, 로베르토 페온이 2009년 HTTP의 대안으로 SPDY를 제시함. HTTP/2의 기반을 마련했으며 크롬과 파이어폭스 및 서버 제품에서도 이를 지원한다. http 1.1의 의미체계를 유지하면서 다음과 같은 기능들이 추가되었다. - 멀티플렉싱으로 HOL 현상 해결   데이터를 이진 코드 메시지로 분할하고   클라이언트가 각 이진 메시지가 속한 스트림을 알 수 있도록  ...

서비스 분리 채팅과 같은 소셜 기능을 담당하는 서버는  게임 서버와 분리하는 것이 성능과 확장성 측면에서 좋다. 채팅 서비스, 게임 서버 서비스를 분리해서 운영한다면 마이크로서비스 지향 아키텍처를 더 관리하기 쉬워진다. monolithic 아키텍쳐에서 멀티플리어 게임 서버를 구축하는 경우 같은 기술 스택-데이터베이스-개발 환경을 사용해야한다. monotlithic 아키텍쳐에서는 서비스의 한 부분이 망가지면 모든 게임 서비스가 망가지게된다. 게임이라는 서비스를 마이크로서비스화 한다면 전체를 구성하는 하나의 서비스가 망가지더라도 다른 서비스는 정상 운영할 수 있고 고치기 쉽다. 게임 서버는 유저의 움직임 및 상태를 실시간으로 수신해서 처리하는 것이 목적이다. 위의 예시와 같이 하나의 서버에 두가지 목적을 가진 프로그램이 돌고 있다면 탈중앙화한 컴포넌트로 전환하여 관리하는 것이 유지보수 측면에서 좋다. 채팅 서비스 뿐 아니라 게임 서버와 분리하면 좋은 서비스들은 인증-통계-리더보드 서비스 등이 있다.   서비스 분리를 하지 않는다면 멀티플레이어 게임의 게임 서버는 성능이 중요하다. 사내 테스트에서는 잘 돌아갈 지몰라도 프로덕션 환경에서 채팅+게임 서버 프로세스가 같이 돌아간다면 지연 시간이 늘어날 것이다. 때문에 마이크로서비스화 한 후에도 cpu와 네트워크 자원을 지속적으로 모니터링하고 효율적으로 사용할 전략을 세울 필요가 있다. 사용자가 100명 정도로, 다수가 참여하는 멀티플레이어 서버를 예를 들면 게임 서버로 동시에 수 천개의 메시지가 전송될 수 있다. 사용자도 많거니와 사용자: 사용자 상태 정보는 1:N이기 때문이다. 채팅 서버가 같이 돌고 있다면 악의적으로 채팅 서버로 채팅을 많이 보내서 전체적인 게임 서버의 성능을 하락시킬 수 있다. 게임 서버는 이미 게임 플레이를 위해 물리/그래픽/사운드 처리를 cpu intensive하게 하고 있어서 대응하기 어렵다. UDP 대 TCP 게임 서버 턴제 게임같은 경우가 아닌 빠른 페이스로 진행되는 멀티플...