From 6ef1fa4618e08426b874529619a66adbd3d1fcf0 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:07:59 +0100 Subject: unslug ja: move --- .../connection_management_in_http_1.x/index.html | 38 +++++ .../web/http/headers/user-agent/firefox/index.html | 175 +++++++++++++++++++++ .../http/headers/x-dns-prefetch-control/index.html | 35 +++++ 3 files changed, 248 insertions(+) create mode 100644 files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html create mode 100644 files/ja/conflicting/web/http/headers/user-agent/firefox/index.html create mode 100644 files/ja/conflicting/web/http/headers/x-dns-prefetch-control/index.html (limited to 'files/ja/conflicting/web/http') diff --git a/files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html b/files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html new file mode 100644 index 0000000000..adb8b20a69 --- /dev/null +++ b/files/ja/conflicting/web/http/connection_management_in_http_1.x/index.html @@ -0,0 +1,38 @@ +--- +title: HTTP Pipelining FAQ +slug: HTTP_Pipelining_FAQ +tags: + - Necko +translation_of: Web/HTTP/Connection_management_in_HTTP_1.x +translation_of_original: Web/HTTP/Pipelining_FAQ +--- +

HTTP/1.1 パイプライン化 FAQ +

+

HTTP パイプライン化とは？

+

通常、HTTP リクエストは、次のリクエストは完全に受け取られた現在のリクエストに対するレスポンスのあとにだけ発行されるという形で、連続して発行されます。ネットワークの待ち時間と帯域幅の制限により、次のリクエストがサーバによって受け取られるまでに、著しい遅れを生じさせることもあります。 +

HTTP/1.1 では、複数 HTTP リクエストを対応するレスポンスを待つことなくソケットに同時に書き出すことを許しています。リクエスト発行者は、リクエストされた順序での到着のためのレスポンスを待っています。リクエストの「パイプライン化」の作用でページ読み込み時に劇的に改善をみせることもあります。高い待ち時間をともなう接続においては特にそうです。 +

パイプライン化はまた、TCP/IP パケットの数を劇的に減少させることもあります。536 ～ 1460 バイトの典型的な MSS (最大セグメントサイズ) で、1 つの TCP/IP パケットにいくつかの HTTP リクエストが可能です。少ないパケットは通常、IP ルータとネットワークの負荷を減らすため、読み込みに必要なパケットの数を減らすことは、全体としてはインターネットに利益になります。 +

HTTP/1.1 に合致するサーバはパイプライン化のサポートが必要とされています。これはサーバにパイプライン化したレスポンスが必要とされることを意味するわけではありません。しかし、クライアントがパイプライン化したリクエストを選択した時に失敗してはいけないことを要求します。著名な Mozilla 以外のブラウザがパイプライン化を実装していないため、これは明らかにエバンジェリズム (啓蒙) に関する新しいカテゴリのバグとなる可能性があります。 +

+

パイプライン化したリクエストをいつすべきですか？

+

GET や HEAD といったリクエストのように独立したリクエストだけが、パイプライン化可能です。POST と PUT といったリクエストはパイプライン化すべきではありません。新しいコネクションの上でもまた、パイプライン化したリクエストをすべきではありません。なぜなら、相手のサーバ (もしくはプロキシ) が HTTP/1.1 をサポートしているかどうかまだわからないからです。そのために、パイプライン化は存在する「keep-alive」接続の再利用時のみ可能です。 +

+

どのくらいの数のリクエストのパイプライン化をすべきでしょうか？

+

うーん。多くのリクエストのパイプライン化は、もし早い時点でコネクションが切断された場合コストが高くつきます。新しいコネクションの上でだけ繰り返せばいいのに、ネットワークへリクエストを書き出す時間を浪費するからです。そのうえ、最初のリクエストが完了するのに長い時間がかかると、長いパイプライン化は実際にユーザに知覚されてしまうほどの遅れを引き起こします。サーバあたり、2 つの「keep-alive」接続を超えないという制限を勧めます。明らかに、それはアプリケーションに依存します。Web ブラウザはたぶん、前述の理由のためにあまりに長いパイプライン化は望まないでしょう。2 というのは適切な値でしょう。しかし、この数値にはまだ試行により変えられる余地があります。 +

+

もし、リクエストがキャンセルされたらどうなるのでしょうか？

+

もし、リクエストがキャンセルされたとき、パイプライン全体がキャンセルされるのでしょうか？ それとも、パイプラインに属する他のリクエストを繰り返すことを強いてはいけないので、キャンセルされたリクエストだけがただ単に捨てられるべきなのでしょうか？ 答えは、受け取られていないままキャンセルされたリクエストに対するレスポンスの破片のサイズを含むいくつかの要素に依存します。実直なアプローチでは、ただパイプラインをキャンセルし、すべてのリクエストを再発行するというのもあるでしょう。これは、リクエストが一度の発行で何度も利用できるときだけできることです。パイプライン化さているリクエストは大抵、キャンセルされている同じ読み込みのグループ (ページ) に属するので、この実直なアプローチはよく筋が通っています。 +

+

コネクションに失敗するとどうなるのでしょうか？

+

もし、コネクションが失敗するか、サーバによってパイプライン化されたレスポンスのダウンロードの一部へ放り込まれた時、Web ブラウザは失ったリクエストの再開始の能力がなくてはなりません。この場合、単純にも、上述の取り消された場合と等価にハンドリンクされているでしょう。 +

+
+

原文書の情報

+ +
+
+
+{{ languages( { "en": "en/HTTP_Pipelining_FAQ" } ) }} diff --git a/files/ja/conflicting/web/http/headers/user-agent/firefox/index.html b/files/ja/conflicting/web/http/headers/user-agent/firefox/index.html new file mode 100644 index 0000000000..c14a549f89 --- /dev/null +++ b/files/ja/conflicting/web/http/headers/user-agent/firefox/index.html @@ -0,0 +1,175 @@ +--- +title: User Agent Strings Reference +slug: User_Agent_Strings_Reference +tags: + - 要更新 +translation_of: Web/HTTP/Headers/User-Agent/Firefox +translation_of_original: User_Agent_Strings_Reference +--- +

このドキュメントの状況

+

これは、元の user-agent のバージョン文字列提議の改訂版です。元の、時代遅れの提議 と、netscape.public.mozilla.seamonkey 及び netscape.public.mozilla.netlibでの議論を改訂の参考にしてください。

+

This document is the official Mozilla user-agent string specification. However, the following issues are under review and may be revised in the near future:

+ +

目標点

+

元の目標は:

+ +

議論の中で出てきた他の事項は:

+ +

提議

+

Mozillaに基づくブラウザは、user-agentのバージョン文字列を以下の形式にすべきである:

+

MozillaProductToken (MozillaComment) GeckoProductToken *(VendorProductToken|VendorComment)

+

Gecko レイアウトエンジンが埋め込まれたアプリケーションの user-agent のバージョン文字列は以下の形式に従うべきである:

+

ApplicationProductToken (ApplicationComment) GeckoProductToken *(VendorProductToken|VendorComment)

+

上記の定義中の参照は以下の通り:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
MozillaProductTokenMozilla/ MozillaVersion
MozillaVersionMajor . minor
Majorメジャーリリース番号を示す整数値。In practice, always 5.
Minorもし 0 でないなら、3 桁の 0 で埋められた数字であるべきで、たとえば 001 である。もし 0 なら、0 とするのが望ましい。
MozillaComment( Platform ; Security ; OS-or-CPU ; Localization information ; GeckoVersion ) *[; Optional Other Comments] )
Platform使用してよい文字列: +
    +
  • Windows: 全ての Windows 環境
    • +
  • Macintosh: 全ての Mac OS 環境
    • +
  • X11: 全ての X-Window システム環境
    • +
  • etc.
    • +
+
Security使用してよい文字列: +
    +
  • N: セキュリティー無し
    • +
  • U: 強化セキュリティーバージョン
    • +
  • I: 弱いセキュリティーバージョン
    • +
+
OS-or-CPUWindows システム用の文字列: +
    +
  • Win3.11: Windows 3.11
    • +
  • WinNT3.51: Windows NT 3.11
    • +
  • WinNT4.0: Windows NT 4.0
    • +
  • Windows NT 5.0: Windows 2000
    • +
  • Win95: Windows 95
    • +
  • Win98: Windows 98
    • +
  • Win 9x 4.90: Windows Me
    • +
  • etc.
    • +
+ MacOS システム用の文字列: +
    +
  • 68K: 68k ハードウエア
    • +
  • PPC: PowerPC ハードウエア
    • +
  • etc.
    • +
+ Unix システム用の文字列: コマンド uname -sm の出力を用いる。(also accessible as the sysname and machine fields of the utsname structure.) (Previous versions of this document said they should be the output of uname -srm, but the release field of the utsname structure was considered to reveal too much information about the system, such as potential security holes.)
Localization Information文字コードの表現は、RFC 1945 及び RFC 2068 の規格に従う。例としては
+ en, en-US, es, es-CO, ja, ja-JPなどがあげられる。
GeckoVersionString starting with "rv:" followed by the Gecko version.  This is a set of numbers separated by periods, possibly followed by a pre-release indicator (e.g. "a1" for the first alpha).
GeckoProductTokenGecko/GeckoDate +

Mozilla を含む、Gecko エンジンに基づく製品には、Gecko 製品文字列をその二次製品であることを明確にするために利用を許可する。

+
GeckoDateYYYYMMDD 形式の日付。正式な Mozilla ビルドにおいては、これは BuildID の中の日付に一致させる。Mozilla の公開版においては、GeckoDate はソースコードが mozilla.org から取り出された日付と一致させなければならず、必ずしも生成された BuildID の日付部分とは一致しない。複数のブランチが同時に公開される場合、この日付からは Gecko のバージョンを特定できない。
ApplicationProductToken, Application CommentGecko レイアウトエンジンに基づくアプリケーションが使用する部分である。それらの製品文字列とコメントの形式はここで指定するものではないが、HTTP 標準に基づくべきである。
( VendorProductToken | VendorComment )Mozilla に基づくアプリケーションの製品文字列を記述する部分である。形式や内容はベンダー規定とするが、HTTP 標準に基づくべきであり、上記の GeckoVersion を含むことが望ましい。
*0 かそれ以上のトークンを入れることを指定する記号
?0 か 1 つのトークンを入れることを指定する記号
+

例

+ + + + + + + + + + + + + + + + + + + + + + + +
mozilla.org のブラウザMozilla/5.001 (windows; U; NT4.0; en-US; rv:1.0) Gecko/25250101
上のブラウザと同じソースに基づいて作られた商標リリースMozilla/5.001 (Macintosh; N; PPC; ja; rv:1.0) Gecko/25250101 MegaCorpBrowser/1.0 (MegaCorp, Inc.)
再構成リリースMozilla/9.876 (X11; U; Linux 2.2.12-20 i686, en; rv:2.0) Gecko/25250101 Netscape/5.432b1 (C-MindSpring)
Gecko に基づくブラウザTinyBrowser/2.0 (TinyBrowser Comment; rv:1.9.1a2pre) Gecko/20201231
+

Implementation notes for applications, vendors, and extensions

+

Starting with Mozilla 1.8 beta2, the best way for applications, vendors, and extensions (if needed) to add to default preferences to add VendorProductTokens or VendorComments is to add a default preference of the form general.useragent.extra.identifier. All of the general.useragent.extra.* preferences will have their string values added to the User-Agent string in alphabetical order by identifier. For example:

+ +
+

これに対するコメントは netscape.public.mozilla.netlib または dbaron@dbaron.org まで

diff --git a/files/ja/conflicting/web/http/headers/x-dns-prefetch-control/index.html b/files/ja/conflicting/web/http/headers/x-dns-prefetch-control/index.html new file mode 100644 index 0000000000..f6ef54e17d --- /dev/null +++ b/files/ja/conflicting/web/http/headers/x-dns-prefetch-control/index.html @@ -0,0 +1,35 @@ +--- +title: DNS プリフェッチの制御 +slug: Controlling_DNS_prefetching +--- +

{{ fx_minversion_header(3.5) }}

+

Firefox 3.5 では DNS prefetching が導入されました。これにより、 Firefox は文書中に埋め込まれたアンカーに加え、画像、CSS、JavaScript などの文書内で参照されている外部リソースの URL に対し、予めドメインの名前解決を行います。

+

このプリフェッチはバックグラウンドで行われるため、実際にリソースが必要となった際には既に名前解決が終了していることになります。これにより、例えばユーザーがリンクをクリックした際の待ち時間を減らすことができます。

+

背景

+

DNS による名前解決に必要な帯域幅は小さなものですが、それにかかる時間は非常に大きく、特にモバイル環境では顕著なものとなります。予め名前解決を行っておくことで、例えばユーザーがリンクをクリックした際に、ページが表示されるまでの待ち時間を大きく削減することができ、場合によっては秒単位の効果が現れる場合もあります。

+

Firefox での実装においては、実際のページコンテンツの取得と並行して DNS による名前解決が行われるため、名前解決に時間がかかっても実際のページコンテンツの取得に遅れが生じることはありません。

+

特にモバイル環境においては、 DNS プリフェッチによりページの読み込みにかかる時間が劇的に改善されます。例えば、多数の画像が表示されるページにおいて、画像が要求される前に名前解決が行われている場合では読み込み時間が 5% 以上削減されるでしょう。

+

ブラウザーでのプリフェッチ制御

+

通常、ユーザーはプリフェッチ機能に対して何ら設定する必要はありません。が、何らかの理由でプリフェッチ機能を無効にしたい場合は、 network.dns.disablePrefetch を true に設定してください。

+

また、既定では HTTPS にて読み込まれた文書に対する埋め込みリンクのホスト名は事前に解決されないように設定されています。これを変更するにはnetwork.dns.disablePrefetchFromHTTPS を false としてください。

+

コンテンツでのプリフェッチ制御

+

コンテンツ・プロバイダー側でもプリフェッチ機能をある程度制御することができます。これは、 Google Chrome が DNS プリフェッチをコントロールする 際の手法と互換性があります。

+

プリフェッチのオン・オフ

+

まず、サーバーはコンテンツの配信時に x-dns-prefetch-control HTTP ヘッダを "off" とすることで、DNS プリフェッチ機能をオプト・アウトとして（ユーザーの意志とは関係なく）実装することができます。

+

同様に個々の文書に対して制御を行うことも可能で、 meta 要素の http-equiv 属性を次のように設定することで実現できます:

+
<meta http-equiv="x-dns-prefetch-control" content="off">
+
+

逆に、 content 属性を "on" とすることで、プリフェッチが有効になります。

+

特定のホスト名の名前解決を強制する

+

コンテンツ・プロバイダーは、文書内にアンカーを埋め込まずとも、特定のホスト名に対する DNS の事前解決を強制することができます。これは、 link 要素に以下のように記述します:

+
<link rel="dns-prefetch" href="http://www.spreadfirefox.com/">
+
+

この例では、 Firefox は "www.spreadfirefox.com" について、予め名前解決を行うよう試みます。

+

また、 link 要素中に必ずしも完全なアドレスを記述せずとも、ホスト名の前に二つのスラッシュを加えることで名前解決が行われます:

+
<link rel="dns-prefetch" href="//www.spreadfirefox.com">
+
+

特定のホスト名について強制的に予め名前解決を行うというのは、次のような場合に有効と考えられます: トップページそのものでは参照されていないものの、サイト内の他のページでは頻繁に参照されている外部ドメインをトップページにて強制的に名前解決を行うことで、トップページ自体の速度向上は望めませんが、サイト全体でのパフォーマンス向上が期待できます。

+

参考文献

+ +

 

-- cgit v1.2.3-54-g00ecf