2차 프로젝트에서 암호화폐 거래소 클론을 하게 되어, 계속적으로 들어오는 데이터를 get할 수 있는 api를 구현하는 방법을 찾고 있다. 기술 조사 과정에서 channel, websocket에 대한 내용을 정리하려고 한다.

해당 게시물은 장고 공식 문서, 장고 채널 튜토리얼을 번역했다.

1. django channel

채널은 django가 비동기적asynchronous으로 코드를 짤 수 있도록 바꿔주고, django의 동기적인 핵심을synchronous core 통해 프로젝트가 HTTP뿐 아니라, 장기간 연결을 필요로 하는 프로토콜 Websockets, MQTT, chatbots, amateur radio 등을 핸들링할 수 있도록 해준다.

django의 동기적이고 쉽게 사용할 수 있는 속성을 유지하면서 코드 스타일을 고를 수 있도록 해주어 유용하다. django view style의 동기적 특징이나, 완전히 비동기적이거나, 둘 다 섞거나를 할 수 있다.

무엇보다도 django의 auth, session system과 통합되어 HTTP-only 프로젝트를 다른 프로토콜로 확장시켜주는 것이 쉽다.

channel 설치 방법
도커 설치 링크

도커란?
도커(Docker)는 리눅스의 응용 프로그램들을 소프트웨어 컨테이너 안에 배치시키는 일을 자동화하는 오픈 소스 프로젝트이다. 도커 웹 페이지의 기능을 인용하면 다음과 같다:

"도커 컨테이너는 소프트웨어를 소프트웨어의 실행에 필요한 모든 것을 포함하는 완전한 파일 시스템 안에 감싸는 것이다. 여기에는 코드, 런타임, 시스템 도구, 시스템 라이브러리 등 서버에 설치되는 무엇이든 아우른다. 이는 실행 중인 환경에 관계 없이 언제나 동일하게 실행될 것을 보증한다."

1.1 turtles all the way down

"Turtles all the way down"은 무한 회귀의 문제에 대한 표현이다. 무한 회귀는 P1의 진실에 대한 전제로 P2가 필요하고, P2에 대한 전제로 P3이 필요한 문제가 무한대로 발생하는 것이다.

장고 공식 문서에서 채널은 'turtles all the way down' 방식으로 운영된다고 나와있다. 무한 회귀 문제와 대체 뭔 상관인지 stackoverflow에 찾아보니, pure한 객체지향 언어 혹은 self-hosting 프로그래밍 언어를 가리키는 말이라고 하는데, 추가 설명이 없어서 정확하게 이해하긴 어렵다 🤔

채널은 basic consumer, url 라우팅, protocol detection, 등 full application을 만들기 위한 도구를 한 데 모아준다.

사실 전통적인 django view도 channels가 있고 사용할 수 있긴 하다. channels.httl.AsgiHandler라는 ASGI application 에 모여있다고 한다. 하지만 채널을 통해 커스텀화된 HTTP long-polling handling 즉 웹소켓 receiver를 써서 내 존재하는 코드와 함께 둘 수 있다.

- ASGI?

Asynchronous Server Gateway Interface. WSGI(Web Server Gateway Interface)는 웹서버와 웹 애플리케이션의 인터페이스를 위한 파이썬 프레임워크인데, 요거의 비동기적 버전이다. 채널이 만들어지는 비동기적 서버 spec의 이름이고, WSGI와 동일하게 channels와 daphne에 갇혀있기보다 다른 서버들과 프레임워크 중에서 내가 선택할 수 있도록 디자인되어있다.

Daphne
django channel을 보강하기 위해 개발된 HTTP, HTTP2 그리고 웹소켓 프로토콜 서버(for ASGI, ASGI-HTT)이다. 자동화된 프로토콜 중재를 지원한다. HTTP endpoint와 웹소켓 endpoint를 결정할 때 URL을 prefixing하지 않아도 된다.

2. django websocket

보통 django는 클라이언트와 서버 간 소통하기 위해 다음과 같이 HTTP를 사용한다.

1. 클라이언트가 서버에 HTTP request를 보낸다.
2. django는 request를 쪼개고, url을 view에 매칭한다.
3. view가 요청을 수행해 서버가 클라이언트에 reponse를 보낸다.

HTTP에서는 트릭을 사용해 실시간처럼 보이도록 통신할 수 있긴 하다. 클라이언트에서 서버로 계속 요청을 보내 이벤트를 받거나(polling), 클라이언트에서 계속 요청을 보내고 필요한 이벤트가 있을 때에만 response를 보낸다든지(streaming)하는 방식이다.

HTTP와 다르게, 웹소켓 프로토콜은 양방향 커뮤니케이션(bi-directional communication)을 허용한다. 서버와 클라이언트 사이에 소켓연결(클라이언트 — 서버연결이 계속 유지되어 있는상태)을 지원하는 것이다.push 방식이라고 하는데, 서버는 유저의 요청 없이 클라이언트에 데이터를 줄 수 있다는 뜻이다. HTTP로는 request을 보낸 클라이언트만 response를 받을 수 있는 반면, 웹소켓으로는 다중 클라이언트와 동시에 소통할 수 있다. html5 버전이 나올 때 웹소켓도 함께 등장했다고 한다.

클라이언트와 서버 간 기본 연결을 핸들링 할 첫 번째 consumer 예시를 만들어보자.

2.1 consumer

consumer는 웹소켓 연결을 받는다. 튜토리얼에 consumer가 django view의 counterpart라고 나와있는데, channel : consumer = django : view로 보면 된다.

http request를 받을 때, django는 view function을 보기lookup 위해 root URLconf를 찾고 요청을 처리하기 위해 view function을 호출한다. 비슷하게, 채널은 web socket의 연결을 받고, consumer를 보기 위해 root routing 설정을 찾는다. 그리고 연결으로부터 온 이벤트들을 핸들링하기 위해 consumer의 여러 함수를 호출한다.

웹 소켓 연결을 받아서 웹소켓으로부터 어떤 메시지든 받고, 같은 웹소켓으로 echo back 하는 basic consumer code는 다음과 같다.

import json
from channels.generic.websocket import WebsocketConsumer

#웹소켓 class instance를 만들어요
class ChatConsumer(WebsocketConsumer):
    #웹소켓에 연결, 혹은 연결 해제해요
    def connect(self):
        self.accept()

    def disconnect(self, close_code):
        pass

    def receive(self, text_data):
    	#josn으로 채팅 메시지를 받아요 
        text_data_json = json.loads(text_data)
        message = text_data_json['message']

	#json 객체를 인코딩 해서 보내요
        self.send(text_data=json.dumps({
            'message': message
        }))

2.2 routes

Django url 설정과 유사하게 작동하는 것이 routes다. urlpatterns 대신 channel_routing, url() 대신 route()을 정의하게 된다. 이 때 consumer functions를 웹소켓에 연결한 점을 주목하자!

채널이 개발 서버에 연결되면, ProtocolTypeRouter가 연결이 어떤 타입인지 조사한다. 만약 socket 연결(ws:// or wss://)이면, 연결을 AuthMiddlewareStack로 보낸다. AuthMiddlewareStack은 연결 범위를 최근에 검증된 유저로 확장하고, 다시 연결을 URLRouter로 보낸다. URLRouter는 urlpatterns를 기반으로 특정 consumer에게 연결된 http path를 조사 한다.

# chatapp/routing.py
from django.urls import re_path

from . import consumers

websocket_urlpatterns = [
    re_path(r'ws/chat/(?P<room_name>\w+)/$', consumers.ChatConsumer),
]

# rootapp/routing.py
from channels.auth import AuthMiddlewareStack
from channels.routing import ProtocolTypeRouter, URLRouter
import chat.routing

application = ProtocolTypeRouter({
    # (http->django views is added by default)
    'websocket': AuthMiddlewareStack(
        URLRouter(
            chat.routing.websocket_urlpatterns
        )
    ),
})

일반적인 HTTP 연결과 웹소켓 연결을 구분하기 위해, path prefix에 /ws/와 같은 것을 넣어주는게 좋다. 왜냐하면 production 환경에서 채널을 끊을 때 특정 설정을 더 쉽게 만들어주기 때문이다.

2.3 channel layer

채널 레이어는 커뮤니케이션 시스템의 일종이다. 사용자들이 서로 얘기하기 위해 여러 consumer instances를 만들게 해준다. 모든 consumer instance는 자동으로 생성된 unique channel name이 있고, 채널 레이어를 통해 통신할 수 있다.

• 채널: 메시지가 보내지는 메일박스다. 모든 채널은 이름이 있고, 그 채널 이름이 있는 누구든 채널에 메시지를 보낼 수 있다.
• 그룹: 채널과 관련된 것들의 묶음이고 마찬가지로 이름이 있다. 그룹의 이름을 알고 있는 누구든 그룹에 있는 모든 채널에 메시지를 보내거나 그룹에 채널을 추가, 삭제할 수 있다. 채널에 특정 채널이 있는지 일일히 세는 것은 불가하다.

같은 방에 있는 사람들이 서로 소통하게 만들기 위해서는, consumers.py에서 만든 ChatConsumer class의 instance를 여러 개 만들어야 한다. 그래서 모든 ChatConsumer가 채팅방의 이름을 기반으로 한 그룹에 채널을 추가하도록 만들고, 같은 방에 있는 다른 ChatConsumer가 메시지를 전송하도록 허가해야 한다.

튜토리얼에서는 backing store로서 Redis를 채널 레이어로 사용했다. port 6379에서 Redis server를 run하고, chennel_redis를 설치해야 한다.

$ docker run -p 6379:6379 -d redis:5
$ python3 -m pip install channels_redis

root app settings.py 에 채널 레이어를 설정한다.

ASGI_APPLICATION = 'mysite.routing.application'
CHANNEL_LAYERS = {
    'default': {
        'BACKEND': 'channels_redis.core.RedisChannelLayer',
        'CONFIG': {
            "hosts": [('127.0.0.1', 6379)],
        },
    },
}

채널 레이어가 생겼으면, consumers.py에서 코드를 다시 작성한다. 아래 코드와 설명을 보자.

import json
from asgiref.sync import async_to_sync
from channels.generic.websocket import WebsocketConsumer

class ChatConsumer(WebsocketConsumer):
    def connect(self):
        self.room_name = self.scope['url_route']['kwargs']['room_name']
        self.room_group_name = 'chat_%s' % self.room_name

        # Join room group
        async_to_sync(self.channel_layer.group_add)(
            self.room_group_name,
            self.channel_name
        )

        self.accept()

    def disconnect(self, close_code):
        # Leave room group
        async_to_sync(self.channel_layer.group_discard)(
            self.room_group_name,
            self.channel_name
        )

    # Receive message from WebSocket
    def receive(self, text_data):
        text_data_json = json.loads(text_data)
        message = text_data_json['message']

        # Send message to room group
        async_to_sync(self.channel_layer.group_send)(
            self.room_group_name,
            {
                'type': 'chat_message',
                'message': message
            }
        )

    # Receive message from room group
    def chat_message(self, event):
        message = event['message']

        # Send message to WebSocket
        self.send(text_data=json.dumps({
            'message': message
        }))

self.scope['url_route']['kwargs']['room_name']

• consumer에게 websocket 연결을 열어주는 chat/routing.py URLrout로부터 'room_name'을 얻는다.
• 모든 consumer는 자신의 연결, URLrout로부터 받은 positinal or keyword argument, 최근 인증된 유저 등에 대한 정보를 포함하는 scope를 가지고 있다.

self.roomgroup_name = 'chat%s' % self.room_name

• 유저에 특정화된 채팅방의 이름으로부터 채널의 그룹 이름을 생성한다.

async_to_sync(self.channel_layer.group_add)(...)

• 그룹에 참여하는 것이다.
• async_to_sync wrapper가 필요로 되는 이유는, ChatConsumer가 동기적인 웹소켓 consummer이지만 비동기적인 채널 레이어 메소드를 사용하기 때문이다. (모든 채널 레이어 method는 비동기 방식이다)

self.accept()

• 웹소켓 연결을 받는다.
• connect() method에서 accept()를 호출하지 않으면 연결은 거절된다. 만약 요청한 유저가 요청한 행동에 대해 인증되지 않았따면, 연결을 거절하고 싶을 수 있기 때문이다.
• 튜토리얼에서 accept()를 쓰고 싶다면 connect()의 마지막 action으로 넣을 것을 권장한다.

async_to_sync(self.channel_layer.group_discard)(...)

• 그룹을 떠나는 것이다.

async_to_sync(self.channel_layer.group_send)

• 그룹에 이벤트를 보낸다.
• 이벤트를 받는 consumers에서 발생해야 할 method의 이름에 대응하는 특별한 'type' key를 갖고 있다.

여기까지가 튜토리얼의 1,2에 대한 내용이다.

튜토리얼 3에서 consumer 코드를 완전 비동기적으로 만드는 것이 있는데, 특정 함수와 inherit하는 클래스를 async로 바꾸는 것이기 때문에 링크만 첨부한다.

튜토리얼 4에서는 셀레니움을 통해 아래 내용을 확인하는 test code를 만든다.

• 같은 방에 있는 모든 사람들이 포스트된 메시지를 볼 수 있는지
• 메시지가 올라올 때 다른 방에 있는 사람은 볼 수 없는지

chating app을 만드는 tutorial로 웹소켓이 무엇인지 이해를 했는데, 이제 웹소켓을 가지고 어떻게 데이터를 쏘는지가 문제다.

일단 개념은 알았으니 어떻게 활용해야 하는지에 대해 공부해야겠다 🤓

3. 추가 개념

Handshake

Websocket Handshake는 재미있는 점이 있다. 바로 Upgrade 라는 헤더인데. 'websocket' 으로 지정되어 있다.
분명히 지금은 GET 타입으로 보내고 있지만, 서버에서 스위칭 시켜준다.

1. Client -> Server
   GET /chat HTTP/1.1
   Host: server.example.com
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
   Origin: http://example.com
   Sec-WebSocket-Protocol: chat, superchat
   Sec-WebSocket-Version: 13

2. Server -> Client

   HTTP/1.1 101 Switching Protocols
   Upgrade: websocket
   Connection: Upgrade
   Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

'101 Switching Protocols' 가 response로 오면 Websocket 연결이 된 것이다. 그 이후로는 Socket Event를 등록하여 Emit (메시지 전송) , socket.on (메시지 리스닝) 를 사용하면 된다. 클라이언트 - 서버 양방향 통신이므로 서버에서 원하는 시점에 클라이언트로 Emit (메시지 전송) 을 날리면 바로 클라이언트가 응답한다.

출처: https://jjshun.tistory.com/46 [소파의 공부방]