Python의 Asyncio Transport 이해하기: 저수준 네트워킹 심층 분석

현대 Python 세계에서 asyncio는 고성능 네트워크 프로그래밍의 핵심이 되었습니다. 개발자는 종종 aiohttp 또는 FastAPI와 같은 라이브러리와 함께 async 및 await를 사용하여 반응성이 뛰어난 애플리케이션을 놀랍도록 쉽게 구축하면서 아름다운 고수준 API로 시작합니다. asyncio.open_connection()과 같은 함수에서 제공하는 StreamReader 및 StreamWriter 객체는 네트워크 I/O를 처리하는 매우 간단하고 순차적인 방법을 제공합니다. 하지만 추상화가 충분하지 않으면 어떻게 될까요? 복잡하고 상태가 있거나 표준이 아닌 네트워크 프로토콜을 구현해야 하는 경우 어떻게 해야 할까요? 기본 연결을 직접 제어하여 성능을 최대한 끌어내야 하는 경우 어떻게 해야 할까요? 이것이 바로 asyncio의 네트워킹 기능의 진정한 기반인 저수준 Transport 및 Protocol API가 있는 곳입니다. 처음에는 위협적으로 보일 수 있지만 이 강력한 듀오를 이해하면 새로운 수준의 제어와 유연성을 얻을 수 있으며 상상할 수 있는 거의 모든 네트워크 애플리케이션을 구축할 수 있습니다. 이 포괄적인 가이드는 추상화의 계층을 벗겨내고, Transport와 Protocol 간의 공생 관계를 탐구하며, 실용적인 예제를 안내하여 Python에서 저수준 비동기식 네트워킹을 마스터할 수 있도록 지원합니다.

Asyncio 네트워킹의 두 가지 측면: 고수준 vs. 저수준

저수준 API를 자세히 살펴보기 전에 asyncio 생태계 내에서 저수준 API가 차지하는 위치를 이해하는 것이 중요합니다. Asyncio는 네트워크 통신을 위해 각각 다른 사용 사례에 맞게 조정된 두 개의 별도 계층을 지능적으로 제공합니다.

고수준 API: 스트림

일반적으로 "스트림"이라고 하는 고수준 API는 대부분의 개발자가 처음 접하는 것입니다. asyncio.open_connection() 또는 asyncio.start_server()를 사용하면 StreamReader 및 StreamWriter 객체를 받습니다. 이 API는 단순성과 사용 편의성을 위해 설계되었습니다.

• 명령형 스타일: 코드를 순차적으로 작성할 수 있습니다. 100바이트를 가져오기 위해 await reader.read(100)을 수행한 다음 응답을 보내기 위해 writer.write(data)을 수행합니다. 이 async/await 패턴은 직관적이고 이해하기 쉽습니다.
• 편리한 도우미: readuntil(separator) 및 readexactly(n)과 같은 메서드를 제공하여 일반적인 프레이밍 작업을 처리하므로 버퍼를 수동으로 관리할 필요가 없습니다.
• 이상적인 사용 사례: 간단한 요청-응답 프로토콜(예: 기본 HTTP 클라이언트), 라인 기반 프로토콜(예: Redis 또는 SMTP) 또는 통신이 예측 가능한 선형 흐름을 따르는 모든 상황에 적합합니다.

그러나 이러한 단순함에는 trade-off가 따릅니다. 스트림 기반 접근 방식은 예기치 않은 메시지가 언제든지 도착할 수 있는 고도로 동시적이고 이벤트 중심적인 프로토콜의 경우 덜 효율적일 수 있습니다. 순차적인 await 모델은 동시 읽기 및 쓰기를 처리하거나 복잡한 연결 상태를 관리하는 데 번거로울 수 있습니다.

저수준 API: Transport 및 Protocol

이것은 고수준 스트림 API가 실제로 구축된 기반 계층입니다. 저수준 API는 Transport와 Protocol의 두 가지 별도 구성 요소에 기반한 디자인 패턴을 사용합니다.

• 이벤트 중심 스타일: 데이터를 가져오기 위해 함수를 호출하는 대신, 이벤트가 발생하면 asyncio가 객체에서 메서드를 호출합니다(예: 연결이 설정됨, 데이터 수신). 이것은 콜백 기반 접근 방식입니다.
• 관심사 분리: "무엇"과 "어떻게"를 깔끔하게 분리합니다. Protocol은 데이터로 무엇을 할지(애플리케이션 로직)를 정의하는 반면, Transport는 데이터가 네트워크를 통해 어떻게 전송되고 수신되는지(I/O 메커니즘)를 처리합니다.
• 최대 제어: 이 API는 버퍼링, 흐름 제어(백프레셔) 및 연결 수명 주기에 대한 세밀한 제어를 제공합니다.
• 이상적인 사용 사례: 사용자 지정 바이너리 또는 텍스트 프로토콜을 구현하고, 수천 개의 영구 연결을 처리하는 고성능 서버를 구축하거나, 네트워크 프레임워크 및 라이브러리를 개발하는 데 필수적입니다.

이렇게 생각하세요. 스트림 API는 식사 키트 서비스와 같습니다. 미리 부분적으로 나뉜 재료와 따라야 할 간단한 레시피를 받습니다. Transport 및 Protocol API는 원자재와 프로세스의 모든 단계를 완벽하게 제어할 수 있는 전문 주방의 셰프와 같습니다. 둘 다 훌륭한 식사를 만들 수 있지만 후자는 무한한 창의성과 제어를 제공합니다.

핵심 구성 요소: Transport 및 Protocol 자세히 살펴보기

저수준 API의 강력함은 Protocol과 Transport 간의 우아한 상호 작용에서 비롯됩니다. 저수준 asyncio 네트워크 애플리케이션에서 별개의 파트너이지만 불가분의 관계입니다.

Protocol: 애플리케이션의 두뇌

Protocol은 사용자가 작성하는 클래스입니다. asyncio.Protocol(또는 해당 변형 중 하나)에서 상속받으며 단일 네트워크 연결을 처리하기 위한 상태 및 로직을 포함합니다. 이 클래스를 직접 인스턴스화하지 않습니다. asyncio에 제공합니다(예: loop.create_server에). 그러면 asyncio는 각 새 클라이언트 연결에 대해 프로토콜의 새 인스턴스를 만듭니다.

프로토콜 클래스는 이벤트 루프가 연결 수명 주기의 여러 시점에서 호출하는 일련의 이벤트 핸들러 메서드로 정의됩니다. 가장 중요한 것은 다음과 같습니다.

connection_made(self, transport)

새 연결이 성공적으로 설정되면 정확히 한 번 호출됩니다. 이것이 진입점입니다. 연결을 나타내는 transport 객체를 받는 곳입니다. 일반적으로 self.transport로 참조를 저장해야 합니다. 버퍼 설정 또는 피어의 주소 로깅과 같은 연결별 초기화를 수행하기에 이상적인 장소입니다.

data_received(self, data)

프로토콜의 핵심입니다. 이 메서드는 연결 반대편에서 새 데이터를 수신할 때마다 호출됩니다. data 인수는 bytes 객체입니다. TCP는 메시지 프로토콜이 아닌 스트림 프로토콜이라는 점을 기억하는 것이 중요합니다. 애플리케이션의 단일 논리적 메시지는 여러 data_received 호출에 걸쳐 분할되거나 여러 개의 작은 메시지가 단일 호출로 번들될 수 있습니다. 코드는 이 버퍼링 및 구문 분석을 처리해야 합니다.

connection_lost(self, exc)

연결이 닫히면 호출됩니다. 이것은 여러 가지 이유로 발생할 수 있습니다. 연결이 깔끔하게 닫히면(예: 반대편에서 닫히거나 transport.close()를 호출하는 경우) exc는 None이 됩니다. 연결이 오류로 인해 닫히면(예: 네트워크 오류, 재설정) exc는 오류를 자세히 설명하는 예외 객체가 됩니다. 이것은 정리 작업을 수행하고, 연결을 끊고 기록하거나, 클라이언트를 구축하는 경우 다시 연결을 시도할 기회입니다.

eof_received(self)

이것은 보다 미묘한 콜백입니다. 다른 쪽 끝에서 더 이상 데이터를 보내지 않을 것임을 알리는 경우(예: POSIX 시스템에서 shutdown(SHUT_WR)을 호출하여) 호출되지만 연결이 데이터를 보내도록 열려 있을 수 있습니다. 이 메서드에서 True를 반환하면 transport가 닫힙니다. False(기본값)를 반환하면 나중에 직접 transport를 닫는 역할을 합니다.

Transport: 통신 채널

Transport는 asyncio에서 제공하는 객체입니다. 만들지 않고 프로토콜의 connection_made 메서드에서 받습니다. 기본 네트워크 소켓 및 이벤트 루프의 I/O 스케줄링에 대한 고수준 추상화 역할을 합니다. 주요 작업은 데이터 전송과 연결 제어를 처리하는 것입니다.

메서드를 통해 transport와 상호 작용합니다.

transport.write(data)

데이터를 전송하는 기본 메서드입니다. data는 bytes 객체여야 합니다. 이 메서드는 non-blocking입니다. 데이터를 즉시 전송하지 않습니다. 대신 데이터를 내부 쓰기 버퍼에 배치하고 이벤트 루프는 백그라운드에서 가능한 한 효율적으로 네트워크를 통해 보냅니다.

transport.writelines(list_of_data)

일련의 bytes 객체를 한 번에 버퍼에 쓰는 보다 효율적인 방법으로, 잠재적으로 시스템 호출 수를 줄일 수 있습니다.

transport.close()

이것은 정상적인 종료를 시작합니다. transport는 먼저 쓰기 버퍼에 남아 있는 모든 데이터를 플러시한 다음 연결을 닫습니다. close()가 호출된 후에는 더 이상 데이터를 쓸 수 없습니다.

transport.abort()

이것은 하드 종료를 수행합니다. 연결이 즉시 닫히고 쓰기 버퍼에 대기 중인 모든 데이터가 삭제됩니다. 예외적인 상황에서 사용해야 합니다.

transport.get_extra_info(name, default=None)

조사를 위한 매우 유용한 방법입니다. 피어의 주소('peername'), 기본 소켓 객체('socket') 또는 SSL/TLS 인증서 정보('ssl_object')와 같은 연결에 대한 정보를 얻을 수 있습니다.

공생 관계

이 디자인의 아름다움은 정보의 명확하고 순환적인 흐름입니다.

1. 설정: 이벤트 루프는 새 연결을 수락합니다.
2. 인스턴스화: 루프는 Protocol 클래스의 인스턴스와 연결을 나타내는 Transport 객체를 만듭니다.
3. 링크: 루프는 your_protocol.connection_made(transport)를 호출하여 두 객체를 함께 연결합니다. 이제 프로토콜에는 데이터를 보낼 방법이 있습니다.
4. 데이터 수신: 데이터가 네트워크 소켓에 도착하면 이벤트 루프가 깨어나 데이터를 읽고 your_protocol.data_received(data)를 호출합니다.
5. 처리: 프로토콜의 로직은 수신된 데이터를 처리합니다.
6. 데이터 전송: 로직에 따라 프로토콜은 self.transport.write(response_data)를 호출하여 응답을 보냅니다. 데이터가 버퍼링됩니다.
7. 백그라운드 I/O: 이벤트 루프는 버퍼링된 데이터를 전송하는 non-blocking 처리를 transport를 통해 처리합니다.
8. 해제: 연결이 종료되면 이벤트 루프는 최종 정리를 위해 your_protocol.connection_lost(exc)를 호출합니다.

실용적인 예제 구축: 에코 서버 및 클라이언트

이론은 훌륭하지만 Transport와 Protocol을 이해하는 가장 좋은 방법은 무언가를 구축하는 것입니다. 고전적인 에코 서버와 해당 클라이언트를 만들어 보겠습니다. 서버는 연결을 수락하고 수신된 모든 데이터를 다시 보냅니다.

에코 서버 구현

먼저 서버 측 프로토콜을 정의합니다. 핵심 이벤트 핸들러를 보여주는 매우 간단합니다.

import asyncio class EchoServerProtocol(asyncio.Protocol): def connection_made(self, transport): # 새 연결이 설정되었습니다. # 로깅을 위해 원격 주소를 가져옵니다. peername = transport.get_extra_info('peername') print(f"Connection from: {peername}") # 나중에 사용할 수 있도록 transport를 저장합니다. self.transport = transport def data_received(self, data): # 클라이언트에서 데이터가 수신됩니다. message = data.decode() print(f"Data received: {message.strip()}") # 데이터를 클라이언트로 다시 에코합니다. print(f"Echoing back: {message.strip()}") self.transport.write(data) def connection_lost(self, exc): # 연결이 닫혔습니다. print("Connection closed.") # transport는 자동으로 닫히므로 여기에서 self.transport.close()를 호출할 필요가 없습니다. async def main_server(): # 서버를 무기한 실행할 계획이므로 이벤트 루프에 대한 참조를 가져옵니다. loop = asyncio.get_running_loop() host = '127.0.0.1' port = 8888 # `create_server` 코루틴은 서버를 생성하고 시작합니다. # 첫 번째 인수는 protocol_factory로, 새 프로토콜 인스턴스를 반환하는 호출 가능 객체입니다. # 이 경우 단순히 `EchoServerProtocol` 클래스를 전달하면 됩니다. server = await loop.create_server( lambda: EchoServerProtocol(), host, port) addrs = ', '.join(str(sock.getsockname()) for sock in server.sockets) print(f'Serving on {addrs}') # 서버는 백그라운드에서 실행됩니다. 메인 코루틴을 활성 상태로 유지하기 위해 # 완료되지 않는 새 Future와 같은 것을 기다릴 수 있습니다. # 이 예에서는 그냥 "영원히" 실행합니다. async with server: await server.serve_forever() if __name__ == "__main__": try: # 서버를 실행하려면: asyncio.run(main_server()) except KeyboardInterrupt: print("Server shut down.")

이 서버 코드에서 loop.create_server()가 핵심입니다. 지정된 호스트 및 포트에 바인딩하고 이벤트 루프에 새 연결을 수신 대기하도록 지시합니다. 각 들어오는 연결에 대해 protocol_factory(lambda: EchoServerProtocol() 함수)를 호출하여 해당 특정 클라이언트에 대한 새로운 프로토콜 인스턴스를 만듭니다.

에코 클라이언트 구현

클라이언트 프로토콜은 자체 상태를 관리해야 하므로 약간 더 복잡합니다. 즉, 어떤 메시지를 보낼지, 언제 작업을 "완료"된 것으로 간주할지입니다. 일반적인 패턴은 asyncio.Future 또는 asyncio.Event를 사용하여 클라이언트를 시작한 메인 코루틴으로 완료를 다시 신호하는 것입니다.

import asyncio class EchoClientProtocol(asyncio.Protocol): def __init__(self, message, on_con_lost): self.message = message self.on_con_lost = on_con_lost self.transport = None def connection_made(self, transport): self.transport = transport print(f"Sending: {self.message}") self.transport.write(self.message.encode()) def data_received(self, data): print(f"Received echo: {data.decode().strip()}") def connection_lost(self, exc): print("The server closed the connection") # 연결이 손실되고 작업이 완료되었음을 알립니다. self.on_con_lost.set_result(True) def eof_received(self): # 서버가 종료 전에 EOF를 보내는 경우 호출할 수 있습니다. print("Received EOF from server.") async def main_client(): loop = asyncio.get_running_loop() # on_con_lost future는 클라이언트 작업의 완료를 알리는 데 사용됩니다. on_con_lost = loop.create_future() message = "Hello World!" host = '127.0.0.1' port = 8888 # `create_connection`은 연결을 설정하고 프로토콜을 연결합니다. try: transport, protocol = await loop.create_connection( lambda: EchoClientProtocol(message, on_con_lost), host, port) except ConnectionRefusedError: print("Connection refused. Is the server running?") return # 프로토콜이 연결이 손실되었음을 알릴 때까지 대기합니다. try: await on_con_lost finally: # 정상적으로 transport를 닫습니다. transport.close() if __name__ == "__main__": # 클라이언트를 실행하려면: # 먼저, 한 터미널에서 서버를 시작합니다. # 그런 다음, 다른 터미널에서 이 스크립트를 실행합니다. asyncio.run(main_client())

여기서 loop.create_connection()은 create_server의 클라이언트 측 대응물입니다. 주어진 주소에 연결을 시도합니다. 성공하면 EchoClientProtocol을 인스턴스화하고 connection_made 메서드를 호출합니다. on_con_lost Future의 사용은 중요한 패턴입니다. main_client 코루틴은 이 future를 await하여 프로토콜이 connection_lost 내에서 on_con_lost.set_result(True)를 호출하여 작업이 완료되었음을 알릴 때까지 자체 실행을 효과적으로 일시 중지합니다.

고급 개념 및 실제 시나리오

에코 예제는 기본 사항을 다루지만 실제 프로토콜은 거의 그렇게 간단하지 않습니다. 필연적으로 직면하게 될 몇 가지 더 고급 주제를 살펴보겠습니다.

메시지 프레이밍 및 버퍼링 처리

기본 사항 다음으로 파악해야 할 가장 중요한 개념은 TCP가 바이트 스트림이라는 것입니다. 내재된 "메시지" 경계가 없습니다. 클라이언트가 "Hello"를 보낸 다음 "World"를 보내면 서버의 data_received가 한 번 b'HelloWorld'로, 두 번 b'Hello' 및 b'World'로, 또는 부분 데이터가 있는 여러 번 호출될 수 있습니다.

프로토콜은 이러한 바이트 스트림을 의미 있는 메시지로 재조립하는 "프레이밍"을 담당합니다. 일반적인 전략은 줄 바꿈 문자( )와 같은 구분 기호를 사용하는 것입니다.

다음은 줄 바꿈을 찾을 때까지 데이터를 버퍼링하여 한 번에 한 줄씩 처리하는 수정된 프로토콜입니다.

class LineBasedProtocol(asyncio.Protocol): def __init__(self): self._buffer = b'' self.transport = None def connection_made(self, transport): self.transport = transport print("Connection established.") def data_received(self, data): # 새 데이터를 내부 버퍼에 추가 self._buffer += data # 버퍼에 있는 만큼의 완전한 줄을 처리 while b'\n' in self._buffer: line, self._buffer = self._buffer.split(b'\n', 1) self.process_line(line.decode().strip()) def process_line(self, line): # 단일 메시지에 대한 애플리케이션 로직이 여기에 들어갑니다 print(f"Processing complete message: {line}") response = f"Processed: {line}\n" self.transport.write(response.encode()) def connection_lost(self, exc): print("Connection lost.")

흐름 제어(백프레셔) 관리

애플리케이션이 네트워크 또는 원격 피어가 처리할 수 있는 것보다 더 빠르게 데이터를 transport에 쓰고 있다면 어떻게 될까요? 데이터가 transport의 내부 버퍼에 쌓입니다. 이것이 계속 확인되지 않으면 버퍼가 무한정 커져 사용 가능한 모든 메모리를 소비할 수 있습니다. 이 문제는 "백프레셔" 부족이라고 합니다.

Asyncio는 이를 처리하는 메커니즘을 제공합니다. transport는 자체 버퍼 크기를 모니터링합니다. 버퍼가 특정 상한선을 넘으면 이벤트 루프가 프로토콜의 pause_writing() 메서드를 호출합니다. 이것은 애플리케이션에 데이터 전송을 중단하라는 신호입니다. 버퍼가 하한선 아래로 배수되면 루프는 resume_writing()을 호출하여 다시 데이터를 전송하는 것이 안전함을 알립니다.

class FlowControlledProtocol(asyncio.Protocol): def __init__(self): self._paused = False self._data_source = some_data_generator() # 데이터 소스라고 상상해 보세요 self.transport = None def connection_made(self, transport): self.transport = transport self.resume_writing() # 쓰기 프로세스를 시작합니다 def pause_writing(self): # transport 버퍼가 가득 찼습니다. print("Pausing writing.") self._paused = True def resume_writing(self): # transport 버퍼가 배수되었습니다. print("Resuming writing.") self._paused = False self._write_more_data() def _write_more_data(self): # 이것은 애플리케이션의 쓰기 루프입니다. while not self._paused: try: data = next(self._data_source) self.transport.write(data) except StopIteration: self.transport.close() break # 더 이상 보낼 데이터가 없습니다 # 버퍼 크기를 확인하여 즉시 일시 중지해야 하는지 확인 if self.transport.get_write_buffer_size() > 0: self.pause_writing()

TCP 이상: 기타 Transports

TCP가 가장 일반적인 사용 사례이지만 Transport/Protocol 패턴은 이에 국한되지 않습니다. Asyncio는 다른 통신 유형에 대한 추상화를 제공합니다.

• UDP: 연결이 없는 통신의 경우 loop.create_datagram_endpoint()를 사용합니다. 그러면 DatagramTransport가 제공되고 datagram_received(data, addr) 및 error_received(exc)와 같은 메서드를 사용하여 asyncio.DatagramProtocol을 구현합니다.
• SSL/TLS: 암호화를 추가하는 것은 매우 간단합니다. loop.create_server() 또는 loop.create_connection()에 ssl.SSLContext 객체를 전달합니다. Asyncio는 TLS 핸드셰이크를 자동으로 처리하고 보안 transport를 얻습니다. 프로토콜 코드를 전혀 변경할 필요가 없습니다.
• Subprocesses: 표준 I/O 파이프를 통해 자식 프로세스와 통신하기 위해 loop.subprocess_exec() 및 loop.subprocess_shell()을 asyncio.SubprocessProtocol과 함께 사용할 수 있습니다. 이를 통해 자식 프로세스를 완전히 비동기적이고 non-blocking 방식으로 관리할 수 있습니다.

전략적 결정: Transport vs. Streams를 사용해야 하는 경우

두 개의 강력한 API를 자유롭게 사용할 수 있으므로 작업을 위해 적합한 API를 선택하는 것이 주요 아키텍처 결정입니다. 다음은 결정을 내리는 데 도움이 되는 가이드입니다.

다음과 같은 경우 스트림(StreamReader/StreamWriter)을 선택하십시오...

• 프로토콜이 간단하고 요청-응답 기반입니다. 로직이 "요청을 읽고, 처리하고, 응답을 쓰는 것"이라면 스트림이 완벽합니다.
• 잘 알려진 라인 기반 또는 고정 길이 메시지 프로토콜에 대한 클라이언트를 구축하고 있습니다. 예를 들어, Redis 서버 또는 간단한 FTP 서버와 상호 작용하는 경우입니다.
• 코드 가독성 및 선형적, 명령형 스타일을 우선시합니다. 스트림을 사용한 async/await 구문은 비동기 프로그래밍을 처음 접하는 개발자가 이해하기 더 쉬운 경우가 많습니다.
• 신속한 프로토타입 제작이 핵심입니다. 몇 줄의 코드만으로 스트림을 사용하여 간단한 클라이언트 또는 서버를 가동하고 실행할 수 있습니다.

다음과 같은 경우 Transport 및 Protocol을 선택하십시오...

• 처음부터 복잡하거나 사용자 지정 네트워크 프로토콜을 구현하고 있습니다. 이것이 주요 사용 사례입니다. 게임, 금융 데이터 피드, IoT 장치 또는 P2P 애플리케이션용 프로토콜을 생각해 보십시오.
• 프로토콜이 매우 이벤트 중심적이고 순수하게 요청-응답 방식이 아닙니다. 서버가 언제든지 클라이언트에 예기치 않은 메시지를 보낼 수 있는 경우 프로토콜의 콜백 기반 특성이 더 자연스럽게 적합합니다.
• 최대 성능과 최소 오버헤드가 필요합니다. 프로토콜은 스트림 API와 관련된 일부 오버헤드를 우회하여 이벤트 루프에 더 직접적인 경로를 제공합니다.
• 연결에 대한 세밀한 제어가 필요합니다. 여기에는 수동 버퍼 관리, 명시적 흐름 제어(pause/resume_writing) 및 연결 수명 주기에 대한 자세한 처리가 포함됩니다.
• 네트워크 프레임워크 또는 라이브러리를 구축하고 있습니다. 다른 개발자에게 도구를 제공하는 경우 Protocol/Transport API의 강력하고 유연한 특성이 종종 올바른 기반입니다.

결론: Asyncio의 기반을 포용

Python의 asyncio 라이브러리는 계층적 디자인의 걸작입니다. 고수준 스트림 API는 접근 가능하고 생산적인 진입점을 제공하는 반면, asyncio의 네트워킹 기능의 진정한 강력한 기반을 나타내는 것은 저수준 Transport 및 Protocol API입니다. I/O 메커니즘(Transport)을 애플리케이션 로직(Protocol)과 분리하여 정교한 네트워크 애플리케이션을 구축하기 위한 강력하고 확장 가능하며 놀랍도록 유연한 모델을 제공합니다.

이 저수준 추상화를 이해하는 것은 단순한 학문적 훈련이 아닙니다. 간단한 클라이언트와 서버를 넘어 설 수 있도록 지원하는 실질적인 기술입니다. 어떤 네트워크 프로토콜이라도 해결할 수 있는 자신감을 주고, 압박 속에서 성능을 최적화할 수 있는 제어력을 제공하며, Python에서 차세대 고성능, 비동기 서비스를 구축할 수 있는 능력을 제공합니다. 다음에 어려운 네트워킹 문제에 직면하게 되면 표면 바로 아래에 있는 강력함을 기억하고 Transport 및 Protocol의 우아한 듀오를 주저하지 말고 활용하십시오.