歌って踊れる開発者になりたい

上記の広告は１ヶ月以上更新のないブログに表示されています。新しい記事を書く事で広告が消せます。

'control' + 'u'	セルの編集
'option' + '→' 'option' + '-'	シート切り替え
'control' + 'shift' + '+' 'control' + 'shift' + '-'	ズームイン/ズームアウト(個人設定)
'option' + 'command' + 'enter'	セル内の改行

よく使うもののみを列挙しました。
詳細は、ツール」=>「ショートカットのユーザ設定...」で確認の変更ができる。

sudo open /System/Library/CoreServices/Directory\ Utility.app/
でディレクトリユーティリティを起動して
編集メニューの「ルートユーザを有効にする」を選択するとターミナルでsuできるぞい！

現在WebSocketの仕様書を勉強のため翻訳中です。
内容は保証しません。あくまで個人の勉強のために翻訳しています。
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17
以下が翻訳内容です。
------------ ここから ------------

[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] 
                                                                        
Versions: (draft-hixie-thewebsocketprotocol)                            
          00 01 02 03 04 05 06 07 08 09 10 11                           
          12 13 14 15 16 17                                             
                                                                        

HyBi 作業部会                                               I. Fette
Internet-Draft                                              Google, Inc.
対象ステータス: Standards Track                             A. Melnikov
有効期限: April 2, 2012                                         Isode Ltd
                                                      September 30, 2011


                         WebSocket プロトコル
                draft-ietf-hybi-thewebsocketprotocol-17

要約

   WebSocketプロトコルは、制御された環境上で動作して信頼できないコードを
　　走らせているクライアントと、そのコードからの通信に対する opted-in を
　　有するリモートホストとの間で、双方向通信を可能にします。
　 このプロトコルに使われるセキュリティーモデルは、一般に Web ブラウザに
　よって使用される原点ベースのセキュリティーモデルです。このプロトコルは、
　handshakeオープンとそれに続く基本メッセージフレーミングがTCP上レイヤー
　を構成します。この技術の目的は、複数のHTTP 接続に頼らないサーバーとの
　双方向通信を必要とするブラウザベースのアプリケーションに対するメカニズ
　ムを提供することです。（例えば、XMLHttpRequest 
　あるいは \　およびロングポーリング。)

　フィードバックは、hybi@ietf.org のメーリング宛先リストにご送付ください。

このメモの状況

   この Internet-Draft は、BCP 78 と BCP 79　の規定に完全に準拠しています。

   Internet-Draft は、Internet Engineering Task Force (IETF) の作業ドキュ
　　メントですが、他の作業部会もInternet-Draftとして作業ドキュメントを
　　配布する場合もあります。 最新の Internet-Draftリストは、
 　　http://datatracker.ietf.org/drafts/current/に掲載されています。

   インターネット - ドラフトには、最大限６カ月の有効期限が設定されており、
　　いつでも、他の文書によって更新されて、書き換えられるか、あるいは情報
　　が古くなってくる可能性があります。  インターネット - ドラフトを参考
　　文献として使用するか、あるいは「作業中」としてする以外に引用すること
　　は不適当です。

   このインターネット - ドラフトは２０１２年４月２日が有効期限です。

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   このドキュメントは、BCP 78 と IETF トラスト法令に遵守しています。



Fette & Melnikov          Expires April 2, 2012                 [Page 1]
 
Internet-Draft           The WebSocket protocol           September 2011


   IETF ドキュメントに関連する規定は、この書類の出版の日付から実施される 
　　(http://trustee.ietf.org/license-info) 。  
　　このドキュメントに関する権利と制約が記述されているので、慎重にこれら
　　の書類をレビューしてください。 トラストリーガル規定のセクション 4.e 
　　で記述されるように、このドキュメントから抽出されたコードコンポーネン
　　トは、単純化 BSDライセンステキストを含まなくてはならなくて、そして、
　　単純化 BSD ライセンスで記述されている通り、保証なしで供給されます。
　　


目次

   1.  導入　　　　 . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  背景　　　 . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  Protocol 概要 　　 . . . . . . . . . . . . . . . . . . . .  6
     1.3.  Handshake オープン . . . . . . . . . . . . . . . . . . . .  7
     1.4.  Handshake クローズ . . . . . . . . . . . . . . . . . . . . 10
     1.5.  設計 方針　　　　  . . . . . . . . . . . . . . . . . . . . 10
     1.6.  セキュリティモデル . . . . . . . . . . . . . . . . . . . . 11
     1.7.  TCP と HTTP との関係　　　　　 . . . . . . . . . . . . . . 12
     1.8.  接続完了　　　　　　　　　 . . . . . . . . . . . . . . . . 12
     1.9.  WebSocket プロトコルを用いたサブプロトコル . . . . . . . . 12
   2.  準拠要件　　　　　　　　 . . . . . . . . . . . . . . . . . . . 14
     2.1.  用語および他の規則　　　　　　　　 . . . . . . . . . . . . 14
   3.  WebSocket URI　. . . . . . . . . . . . . . . . . . . . . . . . 16
   4.  Handshake オープン . . . . . . . . . . . . . . . . . . . . . . 17
     4.1.  クライアント要件　　 . . . . . . . . . . . . . . . . . . . 17
     4.2.  サーバー側要件　　　　　 . . . . . . . . . . . . . . . . . 22
       4.2.1.  クライアントHandshake オープン読み取り . . . . . . . . 23
       4.2.2.  サーバーHandshake オープン送信 　　　　. . . . . . . . 24
     4.3.  Handshakeに使用された新規ヘダー項目用の収集 ABNF 　　　. . 27
     4.4.  WebSocket プロトコルの複数バージョンサポート　　　 . . . . 28
   5.  データフレーミング . . . . . . . . . . . . . . . . . . . . . . 30
     5.1.  概要　　 . . . . . . . . . . . . . . . . . . . . . . . . . 30
     5.2.  基本フレーミングプロトコル . . . . . . . . . . . . . . . . 30
     5.3.  クライアント・サーバーマスク . . . . . . . . . . . . . . . 35
     5.4.  細分化　　　　 . . . . . . . . . . . . . . . . . . . . . . 36
     5.5.  フレーム制御　 . . . . . . . . . . . . . . . . . . . . . . 38
       5.5.1.  クローズ . . . . . . . . . . . . . . . . . . . . . . . 38
       5.5.2.  ピング . . . . . . . . . . . . . . . . . . . . . . . . 39
       5.5.3.  ポング . . . . . . . . . . . . . . . . . . . . . . . . 39
     5.6.  データフレーム . . . . . . . . . . . . . . . . . . . . . . 40
     5.7.  例　　　 . . . . . . . . . . . . . . . . . . . . . . . . . 40
     5.8.  拡張性　　　　 . . . . . . . . . . . . . . . . . . . . . . 41
   6.  データの送信と受信　　　　 . . . . . . . . . . . . . . . . . . 42
     6.1.  データ送信　 . . . . . . . . . . . . . . . . . . . . . . . 42
     6.2.  データ受信　　 . . . . . . . . . . . . . . . . . . . . . . 42
   7.  接続のクローズ　　　　 . . . . . . . . . . . . . . . . . . . . 44



Fette & Melnikov          Expires April 2, 2012                 [Page 2]
 
Internet-Draft           The WebSocket protocol           September 2011


     7.1.  定義　　　　 . . . . . . . . . . . . . . . . . . . . . . . 44
       7.1.1.  WebSocket 接続クローズ　　　　 . . . . . . . . . . . . 44
       7.1.2.  WebSocket Handshake　クローズ開始　　  . . . . . . . . 44
       7.1.3.  WebSocket Handshake　クローズの開始　　　　. . . . . . 44
       7.1.4.  WebSocket 接続のクローズ　　　　　 . . . . . . . . . . 45
       7.1.5.  WebSocket 接続クローズコード　　　　 . . . . . . . . . 45
       7.1.6.  WebSocket 接続クローズコード理由　　　 . . . . . . . . 45
       7.1.7.  WebSocket 接続失敗　　　　　　 . . . . . . . . . . . . 46
     7.2.  異常クローズ　　　 . . . . . . . . . . . . . . . . . . . . 46
       7.2.1.  クライアント始動クローズ . . . . . . . . . . . . . . . 46
       7.2.2.  サーバー始動クローズ　　 . . . . . . . . . . . . . . . 47
       7.2.3.  異常クローズの回復　　　　　　　 . . . . . . . . . . . 47
     7.3.  接続の正常クローズ　　　　　　 . . . . . . . . . . . . . . 47
     7.4.  ステータスコード . . . . . . . . . . . . . . . . . . . . . 47
       7.4.1.  既定ステータスコード . . . . . . . . . . . . . . . . . 48
       7.4.2.  予備ステータスコード　　　　 . . . . . . . . . . . . . 49
   8.  エラー処理　　 . . . . . . . . . . . . . . . . . . . . . . . . 51
     8.1.  UTF-8 符号化データのエラーを処理 　　　. . . . . . . . . . 51
   9.  拡張　　　　 . . . . . . . . . . . . . . . . . . . . . . . . . 52
     9.1.  拡張交渉　　　　　　　 . . . . . . . . . . . . . . . . . . 52
     9.2.  既知拡張　　　　 . . . . . . . . . . . . . . . . . . . . . 53
   10. セキュリティ考慮　　　　 . . . . . . . . . . . . . . . . . . . 54
     10.1. 非ブラウザクライアント . . . . . . . . . . . . . . . . . . 54
     10.2. 起点（オリジン）考慮　 . . . . . . . . . . . . . . . . . . 54
     10.3. インフラでのアタック (マスク)　　　  . . . . . . . . . . . 55
     10.4. 実行依存の制限　　　　　　　　 . . . . . . . . . . . . . . 56
     10.5. WebSocket クライアント認証　　　 . . . . . . . . . . . . . 56
     10.6. 接続の機密性と完全性　　　　　　　　　　　 . . . . . . . . 57
     10.7. 無効データの処理　　　　 . . . . . . . . . . . . . . . . . 57
     10.8. WebSocket handshake　によるSHA-1使用　　 . . . . . . . . . 57
   11. IANA 考慮　　　　　  . . . . . . . . . . . . . . . . . . . . . 59
     11.1. 新規 URI スキームの登録　　　　  . . . . . . . . . . . . . 59
       11.1.1. "ws" スキームの登録　　　　  . . . . . . . . . . . . . 59
       11.1.2. "wss" スキームの登録　　　　 . . . . . . . . . . . . . 60
     11.2. "WebSocket" HTTP アプグレードキーワードの登録　　　　. . . 61
     11.3. 新規 HTTP ヘッダ項目の登録　　　　　　 . . . . . . . . . . 61
       11.3.1. Sec-WebSocket-Key  . . . . . . . . . . . . . . . . . . 62
       11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 62
       11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 63
       11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 64
       11.3.5. Sec-WebSocket-Version  . . . . . . . . . . . . . . . . 64
     11.4. WebSocket Extension 名レジストリ　 . . . . . . . . . . . . 65
     11.5. WebSocket Subprotocol 名レジストリ　 . . . . . . . . . . . 66
     11.6. WebSocket バージョン番号レジストリ . . . . . . . . . . . . 67
     11.7. WebSocket クローズコード番号レジストリ . . . . . . . . . . 68
     11.8. WebSocket Opcode レジストリ. . . . . . . . . . . . . . . . 70
     11.9. WebSocket フレーミングヘッダレジストリ . . . . . . . . . . 71
   12. 他仕様　WebSocket プロトコルの使用　　　　　　　　　　　 . . . 72



Fette & Melnikov          Expires April 2, 2012                 [Page 3]
 
Internet-Draft           The WebSocket protocol           September 2011


   13. 謝辞　　　　　　 . . . . . . . . . . . . . . . . . . . . . . . 73
   14. 参照文献　 . . . . . . . . . . . . . . . . . . . . . . . . . . 74
     14.1. 標準の参照文献　　　 . . . . . . . . . . . . . . . . . . . 74
     14.2. 参考の参照文献　　　　 . . . . . . . . . . . . . . . . . . 75
   著者連絡先　　　　 . . . . . . . . . . . . . . . . . . . . . . . . 77














































Fette & Melnikov          Expires April 2, 2012                 [Page 4]
 
Internet-Draft           The WebSocket protocol           September 2011


1.  導入

1.1.  背景

   _This section is 標準外。_

   歴史的に、クライアント・サーバー間で双方向性のコミュニケーションを必要
　　とするウェブアプリケーション（例えば、インスタントメッセージ送信と
　　ゲームアプリケーションなど）を作成するには、別の HTTP コールとして、
　　アップストリーム通知を送っている間、 HTTP を乱用して更新のためにサー
　　バーをポールする必要があります。[RFC6202]

   これによって、以下の問題が発生します。

   o  サーバーは、各クライアントに対して、多数の異なる原因 TCP 接続使用します。
　　　−１つはクラインとに情報を送るため
　　　ー１つは入力された各メッセージのため
   o  有線プロトコルは、オーバーヘッドが高く、各クライアントからサーバー
　　　へのメッセージには　HTTP ヘッダーが含まれています。

   o  クライアント側スクリプトは、返答を追跡するため、出力接続から入力接続
　　　までのマッピングを維持することを強制されます。

   より簡単な解決策は、双方向トラフィックのために単一つの TCP 接続を使用
　　することです。これは WebSocket プロトコルが提供するものです。  
　　WebSocket API を併用することで、ウェブページからの対リモートサーバー
　　への双方向通信のため、HTTP ポーリングの代替策を提供します。 [WSAPI]

   同じテクニックを、各種のウェブアプリケーションのために使用することが
　　できます。ゲーム、株式相場表示機、同時編集機能を持つマルチユーザの
　　アプリケーション、リアルタイムでサーバー側サービスを知らせるユーザ
　　インタフェース、などです。

   WebSocket プロトコルは、既存のインフラ（プロキシ、フィルタリング、認証）
　　から利益を得るために HTTP をトラスポートレイヤとして使用する既存の双方
　　向性の通信テクノロジーに取って代わるよう設計されています。  このような
　　技術は、 HTTP が当初双方向性のコミュニケーションに使われることを意図さ
　　れていなかったので、効率と信頼性の間にトレードオフとして実装されていま
　　した。（より詳細については［ RFC6202 ］を参照） WebSocket プロトコルは、
　　既存の双方向性の HTTP 技術のゴールを、現存の HTTP インフラ環境で達成し
　　ようと試みます。したがって、現在の環境に特殊な若干の複雑さを意味する
　　場合でも、HTTP プロキシと中間体をサポートすると同様に HTTP ポート８０と
　　４４３での運用するように設計されています。  ただし、この設計では 
　　WebSocket を HTTP に限定されておらず、将来のインプリメンテーションでは、
　　プロトコル全体を再構築することなく、より簡単なハンドシェークをが使う
　　ことができます。
 


Fette & Melnikov          Expires April 2, 2012                 [Page 5]
 
Internet-Draft           The WebSocket protocol           September 2011


   対話型のメッセージ交換のトラフィックパターンは、標準的な HTTP トラフィ
　　ックを完全に一致していないことと、若干のコンポーネントに異常な負荷を
　　誘発する可能性があるので、この最後のポイントは重要です。

1.2.  プロトコル概要

   _This section is non-normative._

   プロトコルは２つの部分があります。
　　ハンドシェークと、それに続くデータ転送です。

   クライアントからのハンドシェークは次の通りです。

        GET /chat HTTP/1.1
        Host: server.example.com
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
        Origin: http://example.com
        Sec-WebSocket-Protocol: chat, superchat
        Sec-WebSocket-Version: 13

   サーバからのハンドシェークは次の通りです。

        HTTP/1.1 101 Switching Protocols
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
        Sec-WebSocket-Protocol: chat

   クライアントからの先頭行はRequest行フォーマットの後に続きます。
   サーバーからの先頭行はStatus行フォーマットの後に続きます。  
   Request行とStatus行の生成は［ RFC2616 ］で定義されています。

   両方のケースの場合、先頭行の後に規則性のない１セットのヘッダー項目が
　　続きます。これらのヘッダー項目の意味は、このドキュメントの第４節で
　　特定されます。クッキーのような追加のヘッダー項目も存在する可能性が
　　あります。 ［ RFC6265 ］
　　フォーマットとヘッダーの解析は［ RFC2616 ］で定義されている通りです。


   一旦、クライアントとサーバーの両方がハンドシェークを送信すると、それが
　　成功した場合、データ転送部分が開始します。
   これは双方向通信チャネルであり、各サイドでは、他のサイドとは独立して、　
　　自由にデータを送ることができます。

   ハンドシェークの成功後、クライアントとサーバーでは、「メッセージ」と
　　して指定された概念的なユニットにおいてデータが戻ってきたり、送られた
　　りします。



Fette & Melnikov          Expires April 2, 2012                 [Page 6]
 
Internet-Draft           The WebSocket protocol           September 2011


   有線では、メッセージは１つ以上のフレームで構成されています。
   WebSocket メッセージは必ずしも特定のネットワーク層構成に対応しないので、
　　フラグメントされたメッセージは、中間体によって合成、あるいは分割され
　　ます。

   １つのフレームは、関連タイプを持っています。  同じメッセージに属して
　　いる各フレームは、同じタイプのデータを含んでいます。  概括的に言って、 
　　テキストデータのタイプには、UTF - ８［ RFC3629 ］テキスト、バイナリー
　　データ（その解釈はアプリケーションで行います）と制御フレーム（アプリ
　　ケーションのためにデータを運んでいないが、プロトコルレベルの信号、
　　例えば、ある接続を閉じる必要があることのシグナル）があります。
　　プロトコルのこのバージョンは６つのフレームタイプを定義しており、
　　１０個のタイプが将来の使用のために確保されています。

1.3.  Handshake オープン

   _This section is non-normative._

   Handshake オープンは、HTTP ベースのサーバーサイドソフトウェアと中間体
　　に互換性を持たせるように意図されています。それで単一ポートは、サーバ
　　ーに話をしている HTTP クライアントとサーバーに話をしている WebSocket 
　　クライアントの両方によって使用できます。  これの終わりは、WebSocket 
　　クライアントのhandshakeはHTTP アップグレードのリクエストです。

        GET /chat HTTP/1.1
        Host: server.example.com
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
        Origin: http://example.com
        Sec-WebSocket-Protocol: chat, superchat
        Sec-WebSocket-Version: 13

   ［ RFC2616 ］に従って、handshakeのヘッダーフィールドは、任意の順序
　　でクライアントによって送られる可能性がるので、異なったヘッダーフィ
　　ールドが受け取られる順序は重要でありません。

   "Request-URI" の GET メソッド [RFC2616] は WebSocket 接続の終端を
　　識別すること、１つのＩＰアドレスから複数ドメインがサポートされる
　　ことを可能にすること、そして複数の WebSocket 終端に単一サーバーに
　　よってサービスされることを許すことに使われます。


   クライアントは［ RFC2616 ］に従ってそのhandshakeのホストヘッダーフィ
　　ールドにホスト名が含まれます。これによってクライアントとサーバーの
　　両方が、どのホストが使用中であるかに関して合意に達することを確かめ
　　ることができます。



Fette & Melnikov          Expires April 2, 2012                 [Page 7]
 
Internet-Draft           The WebSocket protocol           September 2011


   追加のヘッダーフィールドが WebSocket プロトコルでオプションを選択する
　　ために使われます。このバージョンで利用可能な典型的なオプションは 
　　subprotocol セレクター(|Sec-WebSocket-Protocol|)、クライアントによって
　　サポートされる拡張リスト(|Sec-WebSocket-Extensions|)、|Origin|ヘッダー
　　フィールドなどです。  |Sec-WebSocket-Protocolリクエストヘッダーフィー
　　ルドは、どんな subprotocols（WebSocket プロトコルに関して重ねられた
　　アプリケーションレベルプロトコル）がクライアントにとって受け入れられる
　　かを示すために使用することができます。
   サーバーは受容できるプロトコルの１つを選択するか、あるいは選択しないで、
　　そしてプロトコルが選択されたかどうかを示すためにそのhandshakeでその値
　　をエコーします。 
   
        Sec-WebSocket-Protocol: chat

   |Origin|ヘッダーフィールド[I-D.ietf-websec-origin] は、Web ブラウザで 
　　|WebSocket| API を使用するスクリプトによりWebSocket サーバーの無許可
　　のcross-origin使用を保護するために使われます。
　　サーバーは、WebSocket 接続要請を生成するスクリプトoriginが通知されます。 
　　サーバーがこの起点からの接続を受けとることを望まない場合、適切な HTTP 
　　エラーコードを送ることによって、接続を拒絶することを選択することがで
　　きます。  このヘッダーフィールドはブラウザクライアントによって送られ
　　ますが、非ブラウザのクライアントの場合は、それがそれらのクライアント
　　関係で意味があると、このヘッダーフィールドは送られる可能性があります。
  
   最終的に、サーバーはクライアントの WebSocket 握手を受けたことを、クライ
　　アントに証明しなければなりません。それでサーバーは WebSocket 接続以外の
　　接続を受け入れません。  これによってアタッカーが、 |XMLHttpRequest| 
　　[XMLHttpRequest] あるいは|form|提出を使って慎重に作成されたパケットを
　　送ることによって、 WebSocket サーバーをだますのを阻止します。

   握手が受けられたことを証明するために、サーバーは２つのインフォメーション
　　を取り込んで、それらを結合して回答を作成しなければなりません。  インフォ
　　メーションの最初の小片は、クライアント握手の|Sec-WebSocket-Key| 
　　がヘッダーフィールドから取り出します。

        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

   このヘッダーフィールドについて、サーバーはある値（ヘッダーフィールド
　　に存在しており、例えば、base64 で符号化された値［ RFC4648 ］バージョン
　　から先頭および後続する空白スペースを差し引いた値）取り込んでこの値を
　　 ストリング形式でグローバルにユニークなＩＤ(GUID, [RFC4122]) 
　　"258EAFA5-E914-47DA-95CA-C5AB0DC85B11" と連結しなければなりません。 
　　その形式は、WebSocket プロトコルを理解しないネットワーク終端
　　によって使われることはありません。SHA-1ハッシュ（１６０ビット）とbase64 
　　で符号化された値（［ RFC4648 ］の第４節　参照）のこの結合がサーバーの
　　握手で戻されます。［ FIPS.180-2.2002 ］
　　

   具体的には、上記の例の場合、|Sec-WebSocket-Key|ヘッダーフィールドは値
　　"dGhlIHNhbXBsZSBub25jZQ=="を持っており、サーバーはその値をストリング
　　"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"と結合して



Fette & Melnikov          Expires April 2, 2012                 [Page 8]
 
Internet-Draft           The WebSocket protocol           September 2011


  　ストリング "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA-
   C5AB0DC85B11"を設定します。
　 サーバーは、この SHA - １ハッシュを取り込んで、値 0xb3 0x7a 0x4f 0x2c 0xc0 
　　0x62 に 0x4f 0x16 0x90 0xf6 0x46 0x06 0xcf　0x38 0x59 0x45 0xb2 0xbe 0xc4 
　　0xea を作成します。  この値はbase64 によって符号化され（［ RFC4648 ］の
　　第４節　参照）、値"s3pPLMBiTxaQ9kYGzzhZRbK+xOo="が作成されます。 その後
　　この値は|Sec-WebSocket-Accept| ヘッダーフィールドにエコーされます。


   サーバーからの握手は、クライアント握手よりずっと単純です。  最初のラインは、
　　ステータスコード１０１を伴うHTTP Status行です。

        HTTP/1.1 101 Switching Protocols

   １０１以外のステータスコードは、WebSocket 握手が未完了であり、そして HTTP
　 　の意味論がまだ適用されることを示します。ヘッダーはステータスコードの後に
　　続きます。
　　
    |Connection| と |Upgrade| ヘッダーフィールドが HTTP アップグレードを完了
　　します。 |Sec-WebSocket-Accept|ヘッダーフィールドは、サーバーが接続を受け
　　入れることを望んでいるかそうかを示します。 存在している場合、このヘッダー
　　フィールドは、|Sec-WebSocket-Key| で送られたクライアントの乱数のハッシュが
　　定義済みの GUID とともに含まれていなくてはなりません。他のいかなる値も、
　　サーバーによる接続の受け入れとして解釈されてはなりません。
　 
        HTTP/1.1 101 Switching Protocols
        Upgrade: websocket
        Connection: Upgrade
        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

   これらのフィールドは、記載されたページについて|WebSocket| クライアントに
　　よってチェックされます。  |Sec-WebSocket-Accept| 値が予想される値と一致
　　しない場合か、ヘッダーフィールドが欠けている場合か、または HTTP ステータ
　　スコードが１０１以外の場合、接続は確立されず、WebSocket フレームが送られ
　　ません。

   オプションフィールドも含めることができます。  プロトコルのこのバージョン
　　では、主要オプションフィールドの|Sec-WebSocket-Protocol|は、サーバーが
　　選択した subprotocol を示します。  WebSocket クライアントは、WebSocket
　　クライアントの握手で指定された値の１つをサーバーが含んだことを確かめます。  
　　多数の subprotocols　を話すあるサーバーが、クライアントの握手に基づいた
　　subprotocolを選択して、そしてそれを握手に指定していることを確認
　　しなければなりません。
　
        Sec-WebSocket-Protocol: chat



Fette & Melnikov          Expires April 2, 2012                 [Page 9]
 
Internet-Draft           The WebSocket protocol           September 2011


   ［ RFC6265 ］で記述されているように、サーバーは同じくクッキー関連の
　　オプションフィールドに　_set_cookies　をセットすることができます。T

1.4.  Handshake クローズ

   _This section is non-normative._

   Handshake クローズは、Handshake オープンよりはるかに単純です。

   いずれかのピアは、Handshake クローズを始めるために、指定されたコント
　　ロールシーケンスを含むデータを伴うコントロールフレームを送ること
　　ができます（第５.５.１節で詳述）。  このようなフレームを受け取った
　　際、まだ未送信であれば、他のピアはクローズフレームを応答で送ります。  
　　receiving _that_ controlを受け取る際、最初のピアはそれ以上
　　データを送らないので安心して接続をクローズします。

   接続が閉じられるべきであることを示すコントロールフレームを送った後、
　　ピアはそれ以上のデータを送りません。接続が閉じられるべきであること
　　を示すコントロールフレームを受け取った後、ピアはそれ以降受け取った
　　すべてのデータを破棄します。

   両方のピアは同時にこのhandshakeを安全に始めます。

   Handshake クローズは、TCP Handshake クローズ(FIN/ACK)を補助すること
　　を意図しています。これは、特にプロキシ傍受または中間体が存在すると、
　　端末間接続（end-to-end）においてTCP Handshake クローズが常に信頼
　　できないからです。

   クローズフレームを送って、その応答のクローズフレームを待つことに
　　よって、データが不必要に失なわれる特定のケースが避けられます。  
　　例えば、若干のプラットホーム上で、データが待ち行列にある状態で
　　ソケットが閉じられると、RST パケットが送られて、読み取りを待っ
　　ているデータがあっても、その結果、RST データを読み取った部分に
　　ついてrecv ()の失敗が発生します。 

1.5.  設計 方針　

   _This section is non-normative._

   WebSocket プロトコルは最小フレーミングの原則で設計されています
　（存在する唯一のフレミングは、プロトコルをストリームベースの代わり
　　にフレームベースにすることと、ユニコードテキストと２進フレームと
　　の区別をサポートすることです）。  メタデータがアプリケーション
　　レイヤによってTCP の上に重ねられるのと同じ方法で、メタデータは
　　アプリケーションレイヤによって WebSocket の上に重ねられていき
　　ます（例えば、 HTTP）。
　



Fette & Melnikov          Expires April 2, 2012                [Page 10]
 
Internet-Draft           The WebSocket protocol           September 2011

auのXOOMをまっさらな状態に初期化する方法をメモします。
この情報をもとに初期化する場合にはあくまでも自己責任でお願いします。

1. Android SDKをインストールしておきます


2. KDDI用のソフトウェアイメージファイルをダウンロードします。


3. ダウンロードしたファイルを解凍しAndroid SDKのplatform-toolsにコピーします。MAC OSの場合には fastboot-macが必要になります。fastboot-macも Android SDKのplatform-toolsにコピーしましょう


4. XOOMをUSBでPCに接続します


5. コマンドプロンプトで

   adb reboot bootloader



6. XOOMが再起動したら以下のコマンドを実行
   

   
   fastboot-mac flash boot boot.img
   fastboot-mac flash system system.img
   fastboot-mac flash recovery recovery.img
   fastboot-mac erase cache
   



7. ブートローダの再ロックをします。以下のコマンドを実行します
   

   
   fastboot oem lock
   

   
   XOOM側でボリュームダウンを押してYESにが表示されたら、ボリュームアップで決定します
   

【ショートカットキー一覧】
「Ctrl」＋「M」 [MENU]表示
「Ctrl」＋「2」または「Ctrl」＋「J」 記号一覧表示
「Ctrl」＋「3」または「Ctrl」＋「K」 顔文字一覧表示
「Ctrl」＋「4」または「Ctrl」＋「L」 定型文一覧表示
「Ctrl」＋「5」または「Ctrl」＋「G」 単漢字変換
「Ctrl」＋「6」または「Ctrl」＋「U」 ひらがな変換
「Ctrl」＋「7」または「Ctrl」＋「I」 全角カタカナ変換
「Ctrl」＋「8」または「Ctrl」＋「O」 半角カタカナ変換
「Ctrl」＋「9」または「Ctrl」＋「P」 全角英字変換
「Ctrl」＋「0」または「Ctrl」＋「T」 半角英字変換
「Ctrl」＋「B」 区点入力
「Ctrl」＋「Space」 文字種切り替え
「Ctrl」＋「A」 全選択
「Ctrl」＋「C」 コピー
「Ctrl」＋「X」 カット
「Ctrl」＋「V」 ペースト
「Ctrl」＋「Z」 Undo