HTTPパケットの構造やクッキー、セッションの区別

WWW

HTTPハイパーテキスト転送プロトコル

ワールド・ワイド・ウェブの顧客とのやり取りは、Webサーバプログラム間の厳密なプロトコルと手順を遵守するようにするためには、HTTPハイパーテキスト転送プロトコルを出産しました。

機能

1. OSI 7層モデルのアプリケーション層は、HTTPはアプリケーションプロトコルであります
2. これは、TCP接続の信頼性の高い配信を使用しています

HTTPパケットの構造。

HTTPメッセージの2種類があります。

1. クライアントからサーバに送られた---要求パケット要求パケット
2. サーバからユーザ端末へ---答え応答メッセージ

パケット内の各フィールドは、ASCIIコードの文字列の一部であり、従って、各フィールドの長さが不確実になるようにHTTPは、テキスト指向であるので、

HTTPリクエストヘッダと応答ヘッダは、3つの部分から構成されています。図から分かるように、これら2つのメッセージフォーマットの違いがあるスタートライン異なります。

1. 行を開始します（）

   要求パケット又は応答パケットを区別するために使用され、要求パケットのスタートラインは、リクエストラインと呼ばれ、応答メッセージのスタートラインにステータスラインと呼ばれます。スタートラインでは三つのフィールド間のスペースで区切られ、最後のCRとLFは、「入力」と「ラップ」を表します

2. ヘッダー行（ヘッド）

   情報ブラウザ、サーバー、または新聞スタイルのいくつかを説明するために。最初の部分は、いくつかのラインを持っているかもしれませんが、使用することはできません。各列の各行の端部が「入力」と有していなければならないヘッダヘッダフィールド名とその値、有する「ラップ」を 全体ヘッダー行の最後に、バック別々に空白行エンティティ本体の最初の行とがあります

3. エンティティボディ（ボディ）

   要求パケットでは、一般的には、このフィールドを持っていない、と応答メッセージのフィールドを持っていないかもしれません

ここではいくつかの機能は、最も重要なHTTP要求パケットです

1. リクエストメッセージ「リクエスト行」の最初の行のみ三つの要素、すなわち方法、要求されたリソースのURL、およびHTTPのバージョン。

   注意：ここでは名詞「メソッド」は、オブジェクト指向技術で使用される用語です。いわゆる「方法」は、これらのメソッドのいくつかは、実際にそれがコマンドで、要求された操作の対象となります。したがって、要求パケットタイプは、その使用法によって決定されます。いくつかの一般的に使用される方法のRequestパケット：

   GET、POST、およびHEADメソッド：HTTP1.0要求は3つのメソッドを定義します。

   HTTP1.1 5つの新しい要求方法：OPTIONS、PUT、PATCH、DELETE、TRACE、およびCONNECTメソッド。

   方法	意味
   取得する	リクエストページ情報が指定され、エンティティボディを返します。
   頭	GETリクエストと同様、ヘッダを取得するため、応答ではなく、特定のコンテンツを返します
   役職	処理要求指定されたリソース（例えば、ファイル送信フォームまたはアップロード）にデータを送信します。リクエストボディに含まれるデータ。POSTリクエストは、新しいリソースにおよび/または既存のリソースを確立するために改訂することがあります。
   プット	文書の内容を交換するために指定されたクライアントからサーバに送信されたデータ。
   DELETE	指定されたページを削除するには、サーバーを要求します。
   CONNECT	HTTP / 1.1プロトコルは、プロキシサーバのパイプラインモードへの接続のために予約することができます。
   OPTIONS	これは、クライアントがサーバーのパフォーマンスを表示することができます。
   トレース	エコー要求は、主にテストや診断のために、サーバーが受信しました。
   パッチ	これは、局部的に知られているリソースの更新を使用PUTメソッドを補完します。

   例：「清華大学大学」ページへリンクします。HTTP要求パケットの開始行（すなわち、要求線）されるべきであるGETおよびHTTP / 1.1上記の後ろの空間にことに注意します

   GET http://www.tsinghua.edu.cn/chn/yxsz/index.htm HTTP/1.1

   以下は、要求パケットの例です。

   GET /chn/yssz/index.htm HTTP/1.1   {请求行使用了相对URL}
   
   Host: www.tsinghua.edu.cn        {此行是首部行的开始。这行给出主机的域名}
   
   Connection: close                    {告诉服务器发送完请求的文档后就可释放连接}
   
   User-Agent: Mozilla/5.0          {表名用户代理是使用Netscape浏览器}
   
   Accept-Language: cn              {表示用户希望优先得到中文版本的文档}
   {请求报文的最后还有一个空行}

   次のヘッダー行（行2）ドメイン名のホストを与えているため（すなわち、ホストのドメイン名が省略された）要求行の相対URLを使用することです。3行目は、永続的な接続を使用しないように、サーバーに指示、ブラウザサーバはTCP接続オブジェクトは、転送が完了した後に要求されて閉じていることへの期待を表明しました。また、この要求には物理的なボディ（ボディ）パケットありません

2. 主な機能のHTTP応答パケットを見に

   送信された要求パケットのそれぞれには、応答パケットを受信することができます。メッセージの最初の行に応答して、ステータスラインです。

   ステータス行は、3つの要素、すなわち、HTTPバージョン、ステータスコード、およびステータスコードを説明する簡単なフレーズを含みます。

   ステータスコードは、例えば、33種の五つの主要なカテゴリに分かれて3桁、以下のとおりです。

   1 **このような要求を処理または受信されているように、通知情報であります

   2 **は、受諾または知っているように、成功を示します

   3 **、このような要求を満たすためになどのリダイレクトは、さらに行動を取る必要があることを示し

   4 **は、要求が間違った構文を持っているか、完了することができないなど、異なる顧客を示し、

   そのような要求サーバを完了するために失敗として、サーバーエラーを示し** 5

   パケットラインに応じて、以下の3つの状態がしばしば見られます。

   HTTP / 1.1 200受け入れ{受け入れ}

   HTTP / 1.1 400不正な要求{エラー}リクエスト

   HTTP / 1.1 404 {}が見つかりませんが見つかりません

   http://www.ee.xyz.edu/index.htmlから要求されたページが新しいアドレスに転送する場合は、応答パケットとフォームのヘッダ行のステータス行は次のとおりです。

   HTTP / 1.1 301} {永久に移動完全に譲渡します

   LOCATION：http://www.xyz.edu/ee/index.html {新しいURL}

サーバー上のストアのユーザー情報（クッキー）

例：

在网上购物时，一个顾客要购买很多种物品。当他把选好的一件物品放入“购物车”后，他还有继续浏览和选购其他的物品。因此，服务器需要记住用户的身份，使他再接着选购的一些物品能够放入同一个“购物车”中，这样就便于集中结账。有时某些万维网站点也可能想限制某些用的访问。要做到这点，可以在HTTP中使用Cookie.

在RFC 2109中对Cookie进行了定义，规定万维网站点可以使用Cookie来跟踪用户。Cookie原意是“小甜饼”（广东人用方言音译为“曲奇”），目前尚无标准译名，在这里Cookie表示在HTTP服务器和客户之间传递的状态信息。现在很多网站都已广泛使用Cookie

どのように動作します：

当用户张三浏览某个使用Cookie的网站时，该网站的服务器就为张三产生一个唯一的识别码，并以此作为索引在服务器的后端数据库中产生一个项目。接着给张三的HTTP响应报文中添加一个叫做Set-cookie的首部行。这里的“首部字段名”就是"Set-cookie"，而后面的“值”就是赋予该用户的“识别码”。例如这个首部行时这样的：
Set-cookie: 12345678
张三收到响应后，其浏览器会在管理的特定Cookie文件中添加一行，包括这个服务器的主机名和Set-cookie后面给出的识别码。张三每发一个HTTP请求报文，浏览器就会从其Cookie文件中取出这个识别码，放到HTTP请求报文的Cookie首部行中：
Cookie: 12345678
于是，这个网站就能够跟踪用户1234567（张三）在该网站的活动。服务器不需要知道这个用户的姓名和其它信息，但能够知道它在什么时间访问了什么页面，访问的顺序等。如果是网上购物，服务器可以为张三维护一个所购物品列表，一起付费。
如果张三几天后访问这个网站，那么他的浏览器会在其HTTP请求报文中继续使用首部行Cookie: 12345678，而这个网站服务器根据张三过去的访问记录可以向他推荐商品

クッキーの主要素：

cookie的内容主要包括：名字，值，过期时间，路径和域。 
其中域可以指定某一个域比如.google.com，相当于总店招牌，比如宝洁公司，也可以指定一个域下的具体某台机器比如www.google.com或者froogle.google.com，可以用飘柔来做比。 
路径就是跟在域名后面的URL路径，比如/或者/foo等等，可以用某飘柔专柜做比。 
路径与域合在一起就构成了cookie的作用范围。 
如果不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。 

存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。对于IE，在一个打开的窗口上按Ctrl-N（或者从文件菜单）打开的窗口可以与原窗口共享，而使用其他方式新开的IE进程则不能共享已经打开的窗口的内存cookie；对于Mozilla Firefox0.8，所有的进程和标签页都可以共享同样的cookie。一般来说是用javascript的window.open打开的窗口会与原窗口共享内存cookie。浏览器对于会话cookie的这种只认cookie不认人的处理方式经常给采用session机制的web应用程序开发者造成很大的困扰。 

下面就是一个goolge设置cookie的响应头的例子 
HTTP/1.1 302 Found 
Location: http://www.google.com/intl/zh-CN/ 
Set-Cookie: PREF=ID=0565f77e132de138:NW=1:TM=1098082649:LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com 
Content-Type: text/html 

クッキーの役割：

1. パスワードを覚えて、自動ログイン次回
2. ショッピングカート機能
3. ユーザーの閲覧データを記録し、商品（広告）が推奨しました

クッキーの欠陥：

1. クッキーはそう実質流量を増加、各HTTPリクエストに添付されています。
2. HTTPリクエストでクッキーがクリアテキストで渡されているので、それはセキュリティ上の問題があります。（HTTPSを使用する場合を除きます）
3. クッキーのサイズの上限は4キロバイト程度です。複雑なストレージ要件については、それは十分ではありません。

詳細なセッション

要約：

Session代表服务器与浏览器的一次会话过程，这个过程是连续的，也可以时断时续的。Session是一种服务器端的机制，Session 对象用来存储特定用户会话所需的信息

どのように動作します：

当用户访问到一个服务器，如果服务器启用Session，服务器就要为该用户创建一个SESSION，在创建这个SESSION的时候，服务器首先检查这个用户发来的请求里是否包含了一个SESSION ID，如果包含了一个SESSION ID则说明之前该用户已经登陆过并为此用户创建过SESSION，那服务器就按照这个SESSION ID把这个SESSION在服务器的内存中查找出来（如果查找不到，就有可能为他新创建一个），如果客户端请求里不包含有SESSION ID，则为该客户端创建一个SESSION并生成一个与此SESSION相关的SESSION ID。这个SESSION ID是唯一的、不重复的、不容易找到规律的字符串，这个SESSION ID将被在本次响应中返回到客户端保存，而保存这个SESSION ID的正是COOKIE，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。

効果

1. ユーザーがログインしているかどうかを確認
2. ショッピングカート機能

違いのクッキーとセッション

1. 別の保管場所

   Cookie保存在客户端，Session保存在服务端。

2. アクセスのさまざまな方法

   Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二进制数据，需求先进行编码。Cookie中也不能直接存取Java对象。若要存储略微复杂的信息，运用Cookie是比拟艰难的。 
   
   而Session中能够存取任何类型的数据，包括而不限于String、Integer、List、Map等。Session中也能够直接保管Java Bean乃至任何Java类，对象等，运用起来十分便当。能够把Session看做是一个Java容器类

3. セキュリティ（プライバシーポリシー）異なります

   Cookie存储在浏览器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。 假如选用Cookie，比较好的方法是，敏感的信息如账号密码等尽量不要写到Cookie中。最好是像Google、Baidu那样将Cookie信息加密，提交到服务器后再进行解密，保证Cookie中的信息只要本人能读得懂。而假如选择Session就省事多了，反正是放在服务器上，Session里任何隐私都能够有效的保护

4. 異なるの妥当性

   只需要设置Cookie的过期时间属性为一个很大很大的数字，Cookie就可以在浏览器保存很长时间。 由于Session依赖于名为JSESSIONID的Cookie，而Cookie JSESSIONID的过期时间默许为–1，只需关闭了浏览器（一次会话结束），该Session就会失效。

5. 別のサーバーによる圧力

   Session是保管在服务器端的，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十分多的Session，耗费大量的内存。而Cookie保管在客户端，不占用服务器资源。假如并发阅读的用户十分多，Cookie是很好的选择

6. クロスドメインのサポートの違い

   Cookie支持跨域名访问，例如将domain属性设置为“.baidu.com”，则以“.baidu.com”为后缀的一切域名均能够访问该Cookie。跨域名Cookie如今被普遍用在网络中。而Session则不会支持跨域名访问。Session仅在他所在的域名内有效。