[컴퓨터네트워크] 애플리케이션 계층 - 1 네트워크 애플리케이션의 원리

백은진·2021년 3월 28일
3

책과 함께하는 공부

목록 보기
8/22

네트워킹을 이해하는 것의 중요성은 항상 느끼고 있었지만, 그 방대하고 깊은 컴퓨터 지식이 두려워 공부를 시작하지 못하고 있었다.

그러다 다행히도 같이 공부한 사람들 중 한 분께서 스터디를 열어주셔서 네트워크에 대해 조금씩 공부를 시작했다.

스터디는 강의와 전공도서를 병행한다.

블로그 정리는 전공도서를 기준으로 하며, "01 컴퓨터 네트워크와 인터넷"은 추후 정리해 올릴 예정이다.

CHAPTER 2 애플리케이션 계층

목차
1. 네트워크 애플리케이션의 원리
2. 웹과 HTTP
3. 인터넷 전자메일
4. DNS-인터넷의 디렉터리 서비스
5. P2P 파일 분배
6. 비디오 스트리밍과 컨텐츠 분배 네트워크
7. 소켓 프로그래밍: 네트워크 애플리케이션 생성
8. 요약

네트워킹 기반구조와 프로토콜에 대한 필요는 네트워크 애플리케이션을 응용하는 것으로부터 발생되었다. 따라서 여러 가지 독창적이고 훌륭한 네트워크 애플리케이션이 없었다면, 컴퓨터 네트워크가 지금과 같이 발전하기 어려웠을 것이다.

인터넷 응용(네트워크 애플리케이션)의 예는 다음과 같다.

1970 ~ 1980년:

  • 텍스트 전자메일
  • 컴퓨터로의 원격 접속
  • 파일 전송
  • 뉴스 그룹

1990년 ~ :

  • 킬러 애플리케이션 (웹 서핑, 검색)
  • 전자 상거래를 포괄하는 월드와이드 웹
  • 인스턴트 메시징
  • P2P 파일 공유
  • 비디오 컨퍼런싱 (VolP, 스카이프, 페이스타임, 구글 행아웃)
  • 비디오 분배 (유튜브)
  • 요구형 영화 (넷플릭스)
  • 다중참여 온라인 게임 (세컨드 라이프)
  • 소셜 네트워킹 (페이스북, 인스타그램, 트위터, 위챗)
    -> 인터넷이라고 하는 네트워크 또는 라우터와 통신 링크 위에 '휴먼 네트워크'를 창조했다.

모바일 시대 :

  • 위치 기반 모바일 앱
    체크인 (옐프)
     데이팅 (틴더)
    * 교통상황 앱 (와즈, 이크야크)

1. 네트워크 애플리케이션의 원리

네트워크 애플리케이션 개발의 중심은 다른 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것이다. 예를 들어, 웹 애플리케이션은 서버와 클라이언트로 구별되며 두 프로그램은 서로 통신한다. 따라서, 새로운 애플리케이션을 개발할 때는 여러 종단 시스템에서 실행되는 소프트웨어를 작성할 필요가 있다. 여기서 중요한 것은 라우터나 링크 계층 스위치와 같이 '네트워크 코어 장비'에서 실행되는 소프트웨어를 작성할 필요는 없을 뿐더러, 이 장비를 위한 소프트웨어를 개발하더라도 이 소프트웨어는 애플리케이션 계층이 아닌 네트워크 계층 및 그 하위 계층에서 기능한다.

아래의 사진자료에서 TCP/IP 부분을 보면, 계층이 [Application, Transport, Internetwork(Network), Network Access(Link), Physical]로 나뉘어져 있는 것이 보인다. 각 종단 시스템은 아래와 같은 계층으로 나뉘고, 가장 위에 있는 애플리케이션 계층에서 네트워크 애플리케이션을 위한 통신이 발생한다.

각 계층의 주요 프로토콜은 다음과 같다.

  • Application - http
  • Transport - TCP, UDP
  • Network - IP
  • Link - 이더넷, LTE, 4G
  • Physical

1.1 네트워크 애플리케이션 구조

애플리케이션 구조는 애플리케이션 개발자에 의해 설계되고 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 지시한다.

애플리케이션 구조는 크게 두 가지로 나뉜다.

  • 클라이언트-서버 구조
  • P2P 구조

클라이언트-서버 구조

클라이언트-서버 구조에서 항상 켜져 있는 호스트를 서버라고 한다. 이 서비스(서버)는 클라이언트라는 다른 많의 호스트의 요청을 받는다. 클라이언트 호스트는 가끔 혹은 항상 켜져 있을 수 있다. 대표적인 예는 클라이언트 호스트에서 실행되는 브라우저가, 항상 켜진 웹 서버로 서비스를 요청하는 웹 애플리케이션이다. 웹 서버가 클라이언트 호스트로부터 객체를 요청받으면 웹 서버는 클라이언트 호스트로 요청된 객체를 보내어 응답한다.

이 때 클라이언트-서버 구조에서 클라이언트는 서로 직접적으로 통신하지 않으며, 서버는 고정 IP 주소를 갖는 것이 특징이다.

이러한 구조를 가진 애플리케이션의 예는 [웹, 파일 전송, 원격 로그인, 전자메일]이다.

그런데, 하나의 서버에서 너무 많은 클라이언트 요청에 응답하는 게 부담스럽거나 불가능할 때가 있다. 이런 경우를 대비하여 많은 수의 호스트를 갖춘 데이터 센터가 가상의 서버를 생성하여 응답 처리를 하는 것을 도와준다. 데이터 센터를 사용하는 예로는 [구글, 아마존, 지메일, 페이스북] 등이 있다.

P2P(peer-to-peer) 구조

P2P 구조에서는 항상 켜져 있는 기반구조 서버에 최소로 의존하거나 전혀 의존하지 않는다. 대신 애플리케이션은 피어(peer)라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신하도록 한다. 피어는 사용자들이 제어하는 데스크톱과 랩톱이다. P2P 구조에 기반을 둔 애플리케이션 예로는 [쉰레이(다운로드 가속기), 비트토렌트, 스카이프] 등이 있다.

P2P구조는 자가 확장성이라는 특성을 가지고 있다. 예를 들어, P2P 파일 공유 애플리케이션에서 각 피어들이 파일을 요구함으로써 작업 부하를 만들어 내지만, 각 피어들은 파일을 다른 피어들에게 분배함으로써 시스템에 서비스 능력을 추가한다.
또한, P2P구조는 비용이 효율적이라는 특성을 가지고 있다. 데이터 센터의 클라이언트-서버 설계와는 대조적으로 P2P 구조는 서버 기반구조와 서버 대역폭을 요구하지 않기 때문에 비용이 효율적이다.
다만, P2P 구조는 고도의 분산 구조 특성으로 인해 보안, 성능, 신뢰성이 좋지 않은 평가를 받고 있기도 하다.

하이브리드 구조 (클라이언트-서버 구조와 P2P 구조 결합)

인스턴트 메시징 애플리케이션의 경우, 서버는 사용자의 IP 주소를 추적하는 데 사용되고, 사용자 간 메시지는 중간 서버를 통하지 않고 사용자 호스트 사이에 직접 전달된다.

1.2 프로세스 간 통신

여러 종단 시스템에서 실행하는 프로그램이 서로 통신할 때, 운영체제 용어에서는 실제 통신하는 것이 프로그램이 아니라 '프로세스'라고 한다. 프로세스는 종단 시스템에서 실행되는 프로그램이다. 프로세스 간의 통신을 위한 규칙은 종단 시스템의 운영체제를 따른다. 우리는 다른 종단 시스템과 다른 운영 체제에서 셀행되는 프로세스와 통신하는 것에 대해 보려고 한다.

2개의 다른 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메세지 교환으로 서로 통신한다. 송신 프로세스는 메시지를 만들어서 네트워크로 보낸다. 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답한다.

프로세스 스택의 다섯 계층 [Application, Transport, Internetwork(Network), Network Access(Link), Physical] 중 애플리케이션 계층에서 프로세스가 통신한다.

클라이언트와 서버 프로세스

네트워크 애플리케이션은 네트워크에서 서로 메시지를 보내는 두 프로세스로 구성된다. 예를 들어, 웹 애플리케이션에서 '클라이언트 브라우저 프로세스'는 '웹 서버 프로세스'와 메시지를 교환한다. P2P 파일 공유 시스템에서는 한 피어의 프로세스에서 다른 피어의 프로세스로 파일을 전송한다.

통신하는 프로세스 각 쌍에 대해 일반적으로 클라이언트의 프로세스와 서버의 프로세스 중 하나로 이름 짓는다.

웹:

  • 브라우저 -> 클라이언트 프로세스
  • 웹 서버 -> 서버 프로세스

P2P 파일 공유:

  • 파일을 내려받는 피어 -> 클라이언트
  • 파일을 올리는 피어 -> 서버

클라이언트와 서버 프로세스의 정의:

두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스를 클라이언트라 하고, 세션을 시작하기 위해 접속을 기다리는 프로세스를 서버라고 한다.

프로세스와 컴퓨터 네트워크 사이의 인터페이스 - 소켓

대부분의 애플리케이션은 통신 프로세스 쌍(두 프로세스가 메시지를 서로에게 보냄)으로 구성된다 하나의 프로세스로부터 다른 프로세스로 보내는 메시지는 네트워크를 통해 움직인다. 프로세스는 소켓을 통해 네트워크로 메시지를 보내고 받는다.

보통 프로세스는 집, 소켓은 출입구로 비유된다. 프로세스가 메시지를 다른 호스트의 프로세스로 보내고 싶을 때, 그 프로세스는 출입구(소켓) 바깥 네트워크로 메시지를 밀어낸다. 이 송신 프로세스는 네트워크를 거쳐 목적지 프로세스의 출입구로 메시지를 보내기 위해 송신 프로세스 출입구 뒤편에 전송 구조가 있다고 가정한다. 메시지가 목적지 호스트에 도착하면 세시지는 수신 프로세스의 출입구를 거치고, 수신 프로세스는 메시지를 처리한다.

위의 그림자료는 인터넷에서 통신하는 두 프로세스 사이의 소켓 통신을 보여준다. (프로세스가 사용하는 하위 전송 프로토콜이 TCP 프로토콜이라고 가정했다.) 소켓은 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스다. 또한 소켓은 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스이므로, 애플리케이션과 네트워크 사이의 API라고도 한다.
애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 갖지만, 소켓의 프랜스포트 계층에 대한 통제권은 거의 갖지 못한다. 트랜스포트 계층에 대한 애플리케이션 개발자의 통제는 다음 둘 뿐이다.

  • 트랜스포트 프로토콜의 선택
  • 최대 버퍼와 최대 세그먼트 크기와 같은 (약간의) 트랜스포트 계층 매개변수의 설정

애플리케이션 개발자가 트랜스포트 프로토콜을 선택하면, 애플리케이션은 그 프로토콜이 제공하는 전송 서비스를 사용하여 구성된다.

프로세스 주소 배정

한 호스트상에서 수행되고 있는 프로세스가 자신의 패킷을 다른 호스트에서 수행되고 있는 프로세스로 보내기 위해서는 수신 프로세스가 주소를 갖고 있어야 한다. 수신 프로세스를 식별하는 데는 다음 두 가지의 정보가 명시되어야 한다.

  • 호스트의 주소
  • 그 목적지 호스트 내의 수신 프로세스를 명시하는 식별자

인터넷에서 호스트는 IP 주소로 식별된다. IP 주소는 32 비트이며, 호스트를 유일하게 식별한다.
한 호스트가 많은 네트워크 응용을 수행하기 때문에 목적지 포트 번호를 통해 수신 호스트에서 수행되고 있는 수신 소켓을 식별해야 한다. 포트 번호 리스트는 http://www.iana.org에서 찾아볼 수 있으며, 인기 있는 응용은 특정 포트 번호가 할당된다. 예를 들어, 웹 서버는 포트 번호 80번으로 식별되고, 메일 서버는 포트 번호 25번으로 식별된다.

1.3 애플리케이션이 이용 가능한 트랜스포트 서비스

소켓은 애플리케이션 프로세스와 트랜스포트 프로토콜 간의 인터페이스이다.

송신 측의 애플리케이션은 소켓을 통해 메시지를 보낸다. 소켓의 반대편에서 프랜스포트 프로토콜은 네트워크를 통해 그 메시지를 수신 프로세스의 소켓으로 이동시킨다.

인터넷을 포함한 많은 네트워크는 하나 이상의 트랜스포트 프로토콜을 제공한다. 애플리케이션을 개발할 때, 우리는 사용 가능한 트랜스포트 프로토콜 중에 하나를 선택해야 한다. 이 선택은 전송 프로토콜들이 제공하는 서비스를 연구하고 애플리케이션의 요구에 가장 적합한 서비스를 제공하는 프로토콜을 찾아 지정된다.

트랜스포트 계층 프로토콜이 그걸 이용하는 애플리케이션들에게 제공할 수 있는 서비스는 다음의 네 가지로 분류된다.

  • 신뢰적 데이터 전송
  • 처리율
  • 시간
  • 보안

신뢰적 데이터 전송

패킷은 컴퓨터 네트워크 내에서 손실될 수 있다. 예를 들어, 패킷이 라우터의 버퍼에서 오버플로우되거나, 패킷의 비트가 잘못되면 호스트 혹은 라우터에 의해 버려질 수 있다. 전자메일, 파일 전송, 원격 호스트 접속, 웹 문서 전송 및 재무 애플리케이션 같은 애플리케이션의 경우 데이터 손실은 너무 큰 위험을 지닌다. 따라서 이들 애플리케이션은 데이터가 올바르고 완전하게 다른 애플리케이션에 전달되도록 보장되어야 한다. 이 때 프로토콜이 보장된 데이터 전송 서비스를 제공한다면 이를 신뢰적 데이터 전송을 제공한다고 한다. 트랜스포트 프로토콜이 이 서비스를 제공하면 송신 프로세스는 데이터를 소켓으로 보내고 그 데이터가 오류 없이 수신 프로세스에 도착할 것이라는 확신을 갖는다.

트랜스포트 계층 프로토콜이 신뢰적 데이터 전송을 제공하지 않을 때, 송신 프로세스가 보낸 데이터는 수신 프로세스에 전혀 도착하지 않을 수 있다. 이런 경우는 '손실 허용 애플리케이션', 즉, 오디오/비디오와 같이 어느정도 데이터 손실을 참아낼 수 있는 애플리케이션에서 받아들여질 수 있으며, 손실 데이터는 해당 애플리케이션의 품질에 영향을 미칠 수 있다.

처리량

'가용한 처리율'이란 네트워크 경로를 따라 두 프로세스 간의 통신 세션에서 송신 프로세스가 수신 프로세스고 비트를 전달할 수 있는 비율을 나타낸다. 다른 세션들이 네트워크 경로를 따라 대역폭을 공유하고, 이 세션들이 생겼다 없어졌다 하기 때문에 가용한 처리율은 시간에 따라 변동한다. '명시된 속도에서 보장된 가용 처리율 제공 서비스'로 애플리케이션은 r bits/sec의 보장된 처리율을 요구할 수 있고, 트랜스포트 프로토콜은 가용한 처리율이 항상 적어도 r bps임을 보장한다. 이처럼 보장된 처리율 서비스는 인터넷 전화 애플리케이션 등에서 요구된다. 만약 트랜스포트 프로토콜이 이 처리율을 제공할 수 없다면, 애플리케이션은 낮은 속도로 인코드하거나 포기해야 한다. 이처럼 처리율 요구 사항을 갖는 애플리케이션은 대역폭 민감 애플리케이션이라고 한다. 많은 멀티미디어 애플리케이션이 대역폭에 민감하다.

이와 다르게 탄력적 애플리케이션 (전자메일, 파일 전송, 웹 전송 등)은 가용한 처리율을 많은 대로 혹은 적은대로 이용할 수 있다. 물론 대역폭은 많으면 많을수록 좋다.

시간

트랜스포트 계층 프로토콜은 시간 보장을 제공할 수 있다. 처리율 보장과 마찬가지로 시간 보장은 여러 가지 형태로 나타난다. 예를 들어 송신자가 소켓으로 내보내는 모든 비트가 수신자의 소켓에 100 msec 내에 도착하도록 하는 것이다. 이 서비스는 인터넷 전화, 가상 환경, 원격회의, 멀티플레이어 게임과 같은 상호 작용 실시간 애플리케이션에서 필요하다.

보안

트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공할 수 있다. 예를 들어, 송신 호스트에서 트랜스포트 프로토콜은 송신 프로세스가 전송하는 모든 데이터를 암호화할 수 있고, 수신 호스트에서 트랜스포트 프로토콜은 그 데이터를 수신 프로세스로 전달하기 전에 데이터의 암호를 해독할 수 있다. 이 서비스는 두 프로세스 사이에 비밀성 및 데이터 무결성, 종단 인증 등을 제공한다.

여기까지 컴퓨터 네트워크가 일반적으로 제공할 수 있는 트랜스포트 서비스를 소개했다.

1.4 인터넷 전송 프로토콜이 제공하는 서비스

인터넷이 제공하는 애플리케이션 지원 유형을 살펴보자.

인터넷(그리고 일반적인 TCP / IP 네트워크)은 애플리케이션에게 2 개의 전송 프로토콜, TCP와 UDP를 제공한다. 우리가 애플리케이션 개발자로서 새로운 인터넷 애플리케이션을 만들 때, TCP와 UDP 중 어느 것을 사용할 지 결정해야 한다. 두 프로토콜은 애플리케이션에게 서로 다른 서비스 모델을 제공한다.

TCP 서비스

TCP 서비스 모델은 연결지향형 서비스와 신뢰적인 데이터 전송 서비스를 포함한다. 애플리케이션이 TCP 전송 프로토콜을 사용하면, 애플리케이션은 TCP로부터 이 두 가지 서비스를 받는다.

  • 연결지향형 서비스: 

    	* 애플리케이션 계층 메시지를 전송하기 전에 TCP는 클라이언트와 서버가 서로 **전송 제어 정보를 교환**하도록 한다. 이 핸드셰이킹 과정이 클라이언트와 서버에 패킷이 곧 도달할 것이니 준비하라고 알려 주는 역할을 한다. 
	* 핸드셰이킹 단계를 지나면, TCP 연결이 두 프로세스의 소켓 사이에 존재한다고 이야기 한다. 이 연결은 두 프로세스가 서로에게 동시에 메시지를 보낼 수 있기에 전이중 연결이라고 한다. 애플리케이션이 메시지 전송을 마치면 연결을 끊어야 한다.

보안 TCP

TCP나 UDP는 암호화를 제공하지 않는다. 송신 프로세스가 소켓으로 보내는 데이터는 목적지 프로세스까지 네트워크 상으로 흐르는 데이터와 동일한다. 예를 들어, 송신 프로세스가 암호화되지 않은 내용의 비밀번호를 소켓으로 보내면, 그 평문의 비밀번호는 송신자와 수신자 사이의 모든 링크를 흘러가게 되는데 이때 중간의 어떤 링크에서나 탐지되고 발견될 가능성이 있다. 인터넷 커뮤니티는 TCP를 강화한 SSL을 개발했다. SSL로 강화된 TCP는 전통적인 TCP가 하는 모든 일을 하면서, 암호화, 데이터 무결성, 종단 인증을 포함하는 프로세스 vs 프로세스 보안 서비스를 제공한다.

SSL은 TCP나 UDP와 같은 제 3의 인터넷 트랜스포트 프로토콜이 아니라, 애플리케이션 계층에서 구현된 것으로서 TCP를 강화한 것이다. 애플리케이션이 SSL 서비스를 이용하고자 한다면, 애플리케이션의 클라이언트와 서버 측 모두에 SSL 코드를 포함해야 한다. SSL은 전통적인 TCP 소켓 API와 유사한 자신의 소켓 API를 갖고 있다.

애플리케이션이 SSL을 사용할 때 송신 프로세스는 평문 데이터를 SSL 소켓에 전달한다. 송신 호스트에 있는 SSL은 데이터를 암호화하고 암호화된 데이터를 TCP 소켓으로 전달한다. 안호화된 데이터는 수신 프로세스에 있는 TCP 소켓까지 인터넷을 타고 전달된다. 수신 소켓은 암호화된 데이터를 SSL로 전달하고, 이 SSL은 데이터의 암호를 푼다. 마지막으로 SSL은 SSL 소켓을 통해 평문 데이터를 수신 프로세스로 전달한다.

즉, SSL은 TCP 위에서 암호화 과정을 도와주는 역할을 함으로 TCP 그 자체라고 말할 수 없다.

  • 신뢰적인 데이터 전송 서비스: 

    	* 통신 프로세스는 모든 데이터를 오류 없이 올바른 순서로 전달하기 위해 TCP에 의존한다. TCP는 애플리케이션의 한쪽이 바이트 스트림을 소켓으로 전달하면 그 바이트 스트림을 손실하거나 중복되지 않게 수신 소켓으로 전달한다.

또한 TCP는 혼잡제어 방식, 즉 인터넷의 전체 성능 향상을 위한 서비스를 포함한다. TCP 혼잡제어 방식은 네트워크가 혼잡 상태에 이르면 프로세스 속도를 낮춘다. 이 방식은 각 TCP 연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한하려 한다.

UDP 서비스

UDP는 최소의 서비스 모델을 가진 간단한 전송 프로토콜이다.

  • UDP는 비연결형이므로 두 프로세스가 통신을 하기 전에 핸드셰이킹을 하지 않는다.
  • 비신뢰적인 데이터 전송 서비스를 제공한다.
    * 하나의 프로세스가 UDP 소켓으로 메시지를 보내면 UDP는 그 메시지가 수신 소켓에 도착하는 것을 보장하지 않는다.
    • 수신 소켓에 도착하는 메시지들의 순서가 뒤바뀔 수도 있다.
  • 혼잡제어 방식을 포함하지 않는다.
    * UDP의 송신 측은 데이터를 원하는 속도로 하위 계층(네트워크 계층)으로 보낼 수 있다.

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스

트랜스포트 서비스는 신뢰적 데이터 전송, 처리율, 시간, 보안을 제공한다.

그와 달리, TCP와 UDP는 시간이나 대역폭 보장을 제공하지는 않는다.

1.5 애플리케이션 계층 프로토콜

애플리케이션 계층 프로토콜은 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법을 정의한다.

  • 교환 메시지 타입 (요청 메시지, 응답 메시지)
  • 여러 메시지 타입의 문법 (메시지 내부의 필드와 필드 간의 구별 방법)
  • 필드의 의미, 즉 필드에 있는 정보의 의미
  • 언제, 어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙

만약 브라우저 개발자가 HTTP RFC의 규칙을 따른다면, 브라우저는 HTTP RFC의 규칙을 따른 어떠한 웹 서버로부터도 웹 페이지를 가져올 수 있다.

네트워크 애플리케이션과 애플리케이션 계층 프로토콜은 같은 개념이 아니다. 애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소일 뿐이다.

예를 들어, 웹은 사용자가 필요에 따라 웹 서버로부터 문서를 얻게 해주는 네트워크 애플리케이션이다. 웹 애플리케이션은 문서 포맷 표준(HTML), 웹 브라우저(크롬, 파이어폭스 등), 웹 서버(아파치, ms 서버), 애플리케이션 계층 프로토콜을 포함하는 여러 요소들로 구성된다.

웹 애플리케이션 계층 프로토콜(HTTP)은 브라우저와 웹 서버 사이에서 교환되는 메시지의 포맷과 순서를 정의한다. 따라서 HTTP는 웹 애플리케이션의 한 요소다.

profile
백은진
💡 Software Engineer - F.E
이전 포스트

[코어 자바스크립트] 07 클래스

다음 포스트

[JS-DSAA] 01 빅오 표기법

0개의 댓글