:iOS の WebView シナリオで HTTPDNS を使用する

1. はじめに

iOS のネイティブシナリオで HTTPDNS を使用するでは、iOS プラットフォームのネイティブシナリオで HTTPDNS を使用し、ハイジャック対策、正確なスケジューリング、即時の DNS 名前解決を実現する方法を説明しました。

WKWebView は、iOS においてネットワークリクエストが頻繁に発生するもう 1 つのシナリオです。WKWebView は WebKit フレームワークが提供する最新の Web ビューであり、iOS アプリケーションで Web コンテンツを表示するために使用します。従来の UIWebView に代わるもので、より高いパフォーマンス、より多くの機能、より高いセキュリティを提供します。WKWebView が Web ページを読み込む際に HTTPDNS を使用すると、ネットワークのセキュリティとパフォーマンスを向上させることができます。

2. 現状の技術

iOS システムの進化に伴い、HTTPDNS を WKWebView と統合するための技術ソリューションも進化しています：

• iOS 17.0 より前： Apple は WKWebView の DNS 名前解決に対する公式のフックインターフェイスを提供していませんでした。また、カスタムのネットワークリクエスト実装のためのインターフェイスも直接は提供していませんでした。このため、プライベート API をフックしてトラフィックをインターセプトする複雑なソリューションが必要でした。

• iOS 17.0 以降： Apple は ProxyConfiguration API を導入しました。この API は WKWebView 用の公式なプロキシ設定機能を提供します。これにより、すべてのネットワークリクエストを確実にインターセプトでき、HTTPDNS をシームレスに統合できます。

Apple の公式統計 (2024 年 6 月 4 日時点) によると、iOS 17 以降は全 iPhone デバイスの 85% 以上にインストールされており、この数値は増加しています。HTTPDNS は、WKWebView シナリオにおいて、ハイジャック対策、正確なスケジューリング、即時の名前解決といった非機能面の改善を提供します。そのため、このソリューションを使用して HTTPDNS を統合することを推奨します。このアプローチで大多数のお客様に対応できます。古いシステムバージョンのユーザーも、アップグレードに伴い徐々にこの機能を利用できるようになります。

3. 推奨ソリューション：iOS 17+ 向けローカルプロキシベースのソリューション

source 'https://github.com/aliyun/aliyun-specs.git'

target 'yourAppTarget' do
    use_framework!
    
    pod 'AlicloudHTTPDNS', 'x.x.x'
    pod 'EMASLocalProxy', 'x.x.x'
end

#import <EMASLocalProxy/EMASLocalProxy.h>
#import <AlicloudHttpDNS/AlicloudHttpDNS.h>

// WKWebViewConfiguration を作成します
WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];

// DNS リゾルバーを構成します
[EMASLocalHttpProxy setDNSResolverBlock:^NSArray<NSString *> *(NSString *hostname) {
    // HTTPDNS サービスインスタンスを取得します
    HttpDnsService *httpdns = [HttpDnsService sharedInstance];
    HttpdnsResult *result = [httpdns resolveHostSyncNonBlocking:hostname byIpType:HttpdnsQueryIPTypeBoth];

    if (result && (result.hasIpv4Address || result.hasIpv6Address)) {
        NSMutableArray<NSString *> *allIPs = [NSMutableArray array];
        if (result.hasIpv4Address) {
            [allIPs addObjectsFromArray:result.ips];
        }
        if (result.hasIpv6Address) {
            [allIPs addObjectsFromArray:result.ipv6s];
        }
        NSLog(@"HTTPDNS resolution successful. Domain name: %@, IP: %@", hostname, allIPs);
        return allIPs;
    }

    NSLog(@"HTTPDNS resolution failed. Domain name: %@", hostname);
    return nil;
}];

// ログレベルを設定します
[EMASLocalHttpProxy setLogLevel:EMASLocalHttpProxyLogLevelDebug];

// WebView プロキシを構成します
BOOL proxyConfigured = [EMASLocalHttpProxy installIntoWebViewConfiguration:config];
if (proxyConfigured) {
    NSLog(@"WebView proxy configuration successful.");
} else {
    NSLog(@"WebView proxy configuration failed. Using system network.");
}

WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:config];

4. グローバル NSURLProtocol インターセプトソリューション

このソリューションは、HTTPDNS を iOS WebView と統合するための、最も初期の実現可能な選択肢でした。導入の障壁が非常に高く、あまり効果的ではありません。しかし、初期の iOS には他の選択肢がなかったため、このソリューションは存続してきました。その原理は NSURLProtocol に基づいており、これにより iOS の NSURLConnection/NSURLSession のような上位レイヤーのネットワークライブラリから送信されるネットワークリクエストをインターセプトできます。WKWebView からのリクエストも含まれます。リクエストをインターセプトした後、このソリューションは HTTPDNS を使用してドメイン名の解決とその後の処理を行います。手順は次のとおりです。

1. 次のインターフェイスを介してカスタム NSURLProtocol を登録することで、WKWebView からの上位レイヤーのネットワークリクエストをインターセプトできます。その後、新しいネットワークリクエストを作成して、データの送受信、リダイレクト、およびその他の処理ロジックを引き継ぐことができます。結果は元のリクエストに返されます。

   [NSURLProtocol registerClass:[HttpDnsNSURLProtocolImpl class]];

2. カスタム NSURLProtocol の処理手順の概要は次のとおりです。

   • canInitWithRequest で、HTTPDNS ドメイン名解決が必要なリクエストをフィルターします。

   • リクエストをインターセプトした後、HTTPDNS のドメイン名名前解決を実行します。

   • 名前解決が完了したら、通常のリクエストと同様に URL.host フィールドと HTTPヘッダーの Host フィールドを置き換えます。その後、このリクエストのデータ送信、受信、リダイレクトなどの処理を引き継ぎます。

   • NSURLProtocol インターフェイスを使用して、リクエストの処理結果を元の WebView リクエストに返します。

3. カスタム NSURLProtocol の実装ロジックの詳細については、提供されているデモの HttpDnsNSURLProtocolImpl.m をご参照ください。

5. ソリューションの概要と比較

このドキュメントでは、iOS 上の WKWebView シナリオで HTTPDNS を統合するための主な技術ソリューションとして、iOS 17 以降に基づくローカルプロキシソリューションと、グローバルな NSURLProtocol インターセプトソリューションの 2 つを紹介します。

各ソリューションには、適用シナリオ、利点、欠点、実装の複雑さがあります。迅速に判断できるよう、次の表で 2 つのソリューションを並べて比較します：

安定性、開発および保守コスト、今後のトレンドを踏まえ、 iOS 17 以降に基づくローカルプロキシソリューションを強く推奨します。

iOS 17 以降のシステムバージョンが急速に普及する中、このソリューションは最小限のコストで大多数のユーザーに安定して信頼性の高い HTTPDNS サービスを提供します。ドメインハイジャックを効果的に解決し、ネットワークパフォーマンスを改善します。洗練された実装と公式サポートにより、長期的な実現可能性が保証されます。iOS 17 より前のシステムバージョンでは、スムーズなフォールバック戦略が使用されます。つまり、システムのデフォルトのネットワークリクエストが使用されます。ユーザーがシステムをアップグレードすると、自動的に HTTPDNS の恩恵を受けられます。

もう一方のソリューションには、本質的な複雑さと不確実性があります。採用は慎重に判断してください。特別な要件と深い技術的専門性を持つチームが、十分な評価と徹底したテストを行ったうえで採用する場合にのみ推奨します。