URL はどれくらいの長さが必要ですか?なぜこの質問をするのでしょうか? WEB ページのリクエストと読み込みを最適化するために、COOKIE を最小限に抑える、URL を短くする、GET リクエストをできるだけ使用するなどの最適化ガイドが数多くあります。ただし、いわゆる「できるだけ」「可能な限り」は、定量的な観点から、何バイト短縮すれば短いとみなされるかという定性的な説明にすぎません。
ホームページの改訂中に、http アナライザーを通じて、次のようないくつかの興味深い .js ファイル URL を確認しました。 .alipay.net/build/js/app/tracker.js?v=083
https://static.alipay.net/build/js/home/home.js?t=20101012
https://static .alipay.net/build/js/pa/alieditcontrol-update.js?t=20101012 https://static.alipay.net/javascript/arale_v1.0.js
https:/ /static.alipay.net /min/?b=javascript&f=arale/lang/aspect.js,arale/lang/md5.js,arale/lang/uri.js,arale/lang/tmpl.js,arale/lang/ date.js,arale/ lang/number.js,arale/http/jsonp.js,arale/http/ajax.js,arale/http/core.js,arale/event/event-chain.js,arale/class/declare.js,arale/ fx/animator.js、aralex/widget.js、aralex/tplwidget.js、aralex/view.js、aralex/tab/tab.js、aralex/dropdown/dropdown.js、aralex/slider/ slider.js、aralex/ slider/switchslider.js
MSS はさまざまな伝送環境に関連しており、2 つの推奨値があります。一般的に、宛先アドレスがローカル アドレスではない場合 (送信元アドレスとは異なるネットワーク セグメントにある場合)、デフォルトの MSS 値は通常 536 です。それ以外の場合、デフォルトの MSS 値は通常 1460 です。 MTU はネットワーク環境に関連しており、2 つの推奨値があります。一般に、 - シリアル ポートの場合は 576 バイト、 - イーサネットの場合は 1500 バイトです。
MTU/MSS の 2 つの推奨値の間には 40 バイトの差があり、これは (TCP ヘッダー + IP ヘッダー) の一般的な値であり、値は 120 バイト (IP/IP の 20+20 バイト) に制限されます。 TCP ヘッダー、40+40 バイトの IP/TCP オプション ヘッダー）。したがって、複雑なネットワーク環境では、アプリケーション層ネットワーク プロトコルで使用できる単一データ パケットのサイズの最適値は 536-80 = 456 バイト未満である必要があり、1460-80 = 1380 バイトに制限されるようにしてください。このような制限は、トランスポート層とリンク層のプロトコルを総合的に考慮した結果です。ただし、一般的な提案の中には 536/1460 という 2 つの値を使用するものもありますが、これはここでの議論と基本的に変わりません。ここで強調したいのは、「十分に最適化されたリクエスト」が必要な場合、制限はどれくらいであるべきなのかということです。
2. HTTP プロトコルのヘッダー問題
それでは、アプリケーション層プロトコルである HTTP について説明します。 HTTP リクエストはヘッダーとデータ領域で構成されます。HTTP GET リクエストの場合、データ領域なしでヘッダーのみが存在できます。これは、HTTP ヘッダーの内容が次のとおりであるためです (ヘッダーは 2 で終わる必要があります)。連続した復帰と改行):
[xhtml]
view plaincopy
--------
GET (...) HTTP/1.1
Accept:* /* Referer:http://www.alipay.net/
Accept-Language:zh-cn User-Agent: (...)
ここでの GET (...) の後には、完全な GET リクエスト URL を続けることができ、GET リクエストのパラメータもこの URL に配置されるため、別個のデータ領域は必要ありません。上記の HTTP リクエストでは、一部の特定のクライアントの http ヘッド フィールドが多少前後する場合がありますが、通常はフィールドは短くなります。この例は説明のためにのみ使用します。では、この「デフォルト (不完全) HTTP ヘッダー」は何バイトを使用するのでしょうか?
答えは 184 バイトです。ただし、リファラーは現在閲覧中の URL に直接関連していることを強調する必要があります。たとえば、現在閲覧しているページは 500 バイトの URL であり、現在の Web ページ上のハイパーリンクがクリックされると、リファラーフィールドが表示されます。 Web ページ内の URL が長すぎると、ハイパーリンクをクリックする際の通信量が増加します。別の例を次に示します。
上記を例として、Referer フィールドの影響については説明しません。使用できる最適な値は 456-184=272 バイトのみです。これらの 272 バイトは 3 か所、つまり、上記の (...) マークが付いた 3 か所、GET、User-Agent、および Cookie で使用されます。 User-Agent フィールドはブラウザーに関連しており、ブラウザーが処理するオペレーティング システム環境が異なると表示も異なります。 JS やサーバー上の統計ソフトウェアでは、このフィールドは OS やバージョンなどのブラウザ環境を判断するためによく使用されます。このフィールドの値は比較的長い場合があります。私の現在のマシンを例に挙げると、その値は次のとおりです: --------- Mozilla/4.0 (互換性、MSIE 8.0、Windows NT 5.1、Trident/4.0、QQWubi 108) ; EmbeddedWB 14.52（http://www.bsalsa.com/）; .NET CLR 3.0.4506.2152; .NET CLR 3.5.21022; .NET4.0C; .NET4.0E) --------- 274 バイトを占有します。つまり、実際には、理想的な状況下では 456 バイトを使用するだけでは十分ではありません。前に説明したように、次善の策を講じることができます: - 80 バイトの tcp/ip オプション ヘッダーを考慮しない、536 バイトの境界値を使用します。
さらに、強調する必要があるのは、User-Agent の長さの変動性です。たとえば、上記の「EmbeddedWB...」の 64 バイトは、通常のコンピューターでは使用できない可能性があります。 。同様に、他のブラウザ環境 (Maxthon など) では、このフィールドが長くなる可能性があります。この事実を踏まえて、今回の特殊な状況を引き続き分析していきます。
536 バイトを例にとると、実際には 78 バイトが利用可能であるため、ここでは 最適化の最初のレベルを 70 バイトに設定します。 企業はサーバー側で収集されたデータに基づいてバランスのとれた値を取ることをお勧めします。
3. COOKIE の消費量を 0 に減らすことができます
現在のマシンを例に挙げると、この値はいくつかの状況にあります (異なるプロトコルとドメインでは異なります)。 :
(1) ホームページ http://www.alipay.net/ の場合、値は 49 バイトです: ali_apache_id=12.1.11.70.1275978936200.5; lastpg=
(2) の場合 http://*.alipay.net/、値は 171 バイトです: ali_apache_id=12.1.11.70.1275978936200.5; ali_apache_sid=12.1.46.46.128998714836.4|1289988948; YJ SESSIONID=bYWcn4Wq0Z5FBCoHzfpn2f1XxDAmBepay=uid=
(3) https://static.alipay.net/の場合、値は307バイトです: cna=AKAaAhYBhU0BAeMdAHlnHNcd=169.17.198.19.1272623861747.7; payMethod=directPay; b_order=38016166656317; ICBC; __utma=22931947.260433774.1277279158.1277279158.1282287558.2; __utmz=22931947.1282287558.2.2.utmcsr=life.alipay.net|utmccn=(紹介) ral|utmcct=/index.php
(4) for http( s )://img.alipay.net/、値は 379 バイトです: apay_id=159588238.127262386236866.128979461890689.1289969142342368.137; cna=AKAaAhYBhU0BAeMdAHlnHNcd; _apache_id=1 69.17.198.19.1272623861747.7; payMethod=directPay=38016166656317; ICBC; __utma=22931947.260433774.1277279158.1277279158.1282287558.2; __utmz=22931947.1282287558.2.2.utmcsr=life.alipay.net|utmccn=(紹介) ral|ut mcct=/index.php
(5) その他の状況。
状況 2、3、4 で Cookie の使用が劇的に増加したのはなぜですか?実際、状況 3 と状況 4 は若干異なりますが、問題の根本原因は状況 2 と完全に一致しています。したがって、次の記事ではケース 2 のみを例として取り上げます。 http 要求プロセスを追跡すると、次のことがわかります。 - ホームページを要求すると、サーバーは 4 つの set-cookie 応答を返しました。
4 つの応答 (http 応答ヘッド) は次のとおりです: --------
Set-Cookie:ali_apache_sid=10.2.46.46.128998714836.4|1289988948; path=/;セット-Cookie:JSESSIONID=A8CE523AEA03E2C990D6796D6BAEC81E; セット-Cookie:ALIPAYJSESSIONID=bYWcn4Wq0Z5FBCoHzfpn2f1XDAmBepay; セット-Cookie:ali_apache_tracktmp=uid=; ; パス=/
------
したがって、後続のすべての http リクエストでは、前の例 (3) の 171 バイトの Cookie が使用されます。ただし、明らかに、これらの Cookie は少なくとも次の状況では意味がありません。 - ステータス コード: 302 を返すリダイレクトや、HTML ページで http-meta を使用するリダイレクトを含むリダイレクト ページにアクセスした場合。 - 訪問したページがキャッシュされている場合。たとえば、ステータス コード: 304 "未変更" が返されます。 - 訪問したページが静的であり、static.alipay.net 内の .img、.js、.js などの Cookie 認識を必要としない場合。等
明らかに、img や static 内の写真やその他の静的リソースはキャッシュできますが、キャッシュされたか初めてアクセスされたかにかかわらず、Cookie の値はまったく意味がありません。静的ページ (.html) の場合、静的ページへのアクセスを統計的に分析するために http サーバーを使用しない場合、これらの Cookie は必要ありません。したがって、これらのリソースとコンテンツについては、これらの Cookie が送信されないか、使用が最小限であることを強調する必要があります (一部の .html 静的ページでは、ユーザー アクセス チェーンを分析するためにセッション ID のみが必要な場合があります)。
Cookie を最適化する方法は非常に簡単です。ドメインとして .alipay.net を持たないサーバー/グループにこれらの静的リソースをデプロイするか、他の独立したドメイン名を使用します。この場合、リソースの特定の、そして確かに最大の部分については、COOKIE の消費を 0 に減らすことができます。
4. URL を短縮する
最後に、URL はどのくらいの長さにすることができますか?前の分析では、特定の条件下でも、いくつかのページ訪問 (セッションなど) の追跡データを残す必要がある場合でも、まだ 40 ～ 50 バイトが利用可能です。ただし、それだけでは、この記事の冒頭で述べた 443 バイトにはまだ程遠いです。
しかし、本当にそんな長いURLが必要なのでしょうか？答えは「いいえ」です。URL を短縮できます。たとえば、前の例では、元の URL の取得部分は次のようになります:
[xhtml]
view plaincopy
--------
よく見てください、実際の意味は --------- /min?b=javascript&f=... ---------
フィールド f に続くものは、実際には、アラレ スクリプト プロジェクト内のいくつかの静的リソースの結合です。サーバー側では、min プログラムはパラメータ「b=javascript&f=...」に従っていくつかのスクリプト フラグメントを単一の .js ファイルに結合し、変更がない場合はブラウザに直接ステータス コードを返します。 304.
実際、リクエストする「f=...」フィールドの後のパラメーター ブロックは、毎回まったく同じになります。あるいは、接続する必要があるファイルのリストが状況によって異なる場合でも、組み合わせはかなり限られています。これにより、私たちは自然に「合計」ということを考えるようになります。このメソッドを使用して上記の文字列のキー (ハッシュ、md5、crc など) を検索すると、この一意のキーを使用して結合された .js コンテンツを見つけることができます。これは、min プログラムが必要ないことも意味します。テキストをスプライスするたびに使用されます。このようにして、上記の URL は次のようになります (例として f フィールド後の 396 バイトの crc32 を取り上げます): --------- /min?b=javascript&f=313466DB ------- - - さまざまなバージョン管理を考慮して: --------- /min?b=javascript&v=0.9b&f=313466DB ---------
現在、URL を公平に管理しています。規模は小さく、必要に応じて、サーバー側の min プログラムを動的に生成してキャッシュすることもできます。これらの変更は当初のニーズと矛盾しませんでした。重要なことは、get リクエストを 35 バイトに制御することに成功し、残りのスペースが
全体の最適化ニーズを完全に満たしたということです:
最適化の最初のレベル、70 バイト!5. テクノロジーの成熟度と価値
1. Twitter はこのテクノロジーを長年使用してきました。
2. Arale プロジェクトと同様に、YQL (Yahoo! Query Language) プロジェクトにも同様のニーズがあるため、上記のテクノロジーを使用して「SQL を URL にアップロード」を短い名前に変換しました (例: http:/)。 / y.ahoo.it/iHQ8c0sv は http://developer.yahoo.com/yql/console/?q=select%20woeid%20from%20geo.places%20where%20text%3D%22san%20francisco%2C% と同等です20ca% 22
3. Microsoft はまだ「明確に説明できない」ため、公式 Web サイトを表示するのが非常に遅いです。 ^^。
4. http ヘッダーを 456 バイト未満に削減する条件が整っている場合は、最善を尽くす必要があります。たとえば、Wangwang には独立したクライアントがあるため、http リクエスト ヘッドをカスタマイズして、User-Agent などのフィールドを減らすことができます。
5. ブラウザから常に最小化された HTTP リクエストを発行すると、ネットワークは複数のパッケージが結合されるのを待たずに、常にできるだけ早くリクエストをサーバーに送信できます。この影響は、低速なネットワークやパケット損失が多いネットワークでは非常に顕著になります。簡単に言えば、誰かが LAN 上で Thunder または BT を使用している場合、HTTP リクエストを最小限に抑えると、Web ページの閲覧エクスペリエンスが大幅に向上します。
6. スクリプトなどの静的リソースのバージョン管理を行う必要があります。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
