Http

Http1.1
1，HTTP このプロトコルは、アプリケーション層に基づいており、トランスポート層ではTCPの信頼性の高い通信プロトコルを使用している。
2，MIME Typeこれは、メッセージ内容のタイプを記述するインターネット標準であり、いくつかの一般的なタイプがある。
 テキストファイル： text/html,text/plain,text/css,application/xhtml+xml,application/xml
 イメージファイル： image/jpeg,image/gif,image/png.
 ファイル： video/mpeg,video/quicktime
 ファイルのレンダリングタイプを設定する方法は2つあり、1つ目はAccept、2つ目はContent-Typeである。
 Accept: クライアントが受け取りたいデータのタイプを示す。つまり、どのようなメディアタイプのデータが必要かをサーバーに伝え、サーバーはAcceptリクエストヘッダに従って指定されたメディアタイプのデータを生成する。
 Content-Type: 送信者によって送信された物理データのタイプを示す。例えば、同様のことを書くべきだった：
 resposne.setContentType(「application/json;charset=utf-8”)コードは、サーバーから返されるデータ形式がjsonであることを示す。
 AcceptとContent-Typeが一致しない場合、例えばAcceptがimage/gifであるにもかかわらずサーバーがtext/htmlを返す場合、ブラウザはそれを解析することができない。
3，リクエストごとに接続を確立しなければならないのか？
 初期のhttpプロトコルでは、http通信のたびにtcp接続が必要だった。そして、接続には3回のハンドシェイクが必要で、これはトラフィックのオーバーヘッドを増加させる。
 HTTP/1.1 tcpコネクションは、持続的なコネクションの代わりに、コネクションが確立された後も、クライアントまたはサーバーが明示的に切断しない限り、コネクションを維持する。
 持続的接続の最大のメリットのひとつは、接続の確立と切断の待ち時間を大幅に短縮できることだ。
 HTTP1.1 の中にトランスポート・セグメントがある。それはコネクションを運ぶ:Keep-Alive，この接続を持続的接続として使用したいことを示す。
 HTTP/1.1 持続的接続は、特に指定がない限り、デフォルトで有効である。.1 すべてのコネクションが永続的であると仮定すると、トランザクション完了後にコネクションをクローズするには、次のようにする。，
 	HTTP/1.1 アプリケーションは、メッセージにConnection: closeヘッダーを明示的に追加しなければならない。
 パイプライン接続: http/1.1 持続的接続でリクエストパイプラインを使用できるようになった。これまでは、リクエストを送信した後、次のリクエストを送信する前に応答を待って受信する必要があった。パイプラインを使用すると、応答を待たずに次のリクエストを送信できる。これにより、複数のリクエストを並行して送信することができる。
4，Http ステートレスプロトコル
 ステートレスとは、HTTPプロトコル自体がリクエストとレスポンスの間の通信状態を保存しないことを意味する。
 Http クッキーの技術は、httpプロトコルのステートレスの問題を解決するためにプロトコルに導入された。
 サーバー・サイドは、JSP/サーブレット・コンテナなどの tomcat をベースにしており、サーバー・サイドのオブジェクトの状態を保存するセッションのようなメカニズムを提供する。
 セッションが存在する場合はそのまま返され、存在しない場合は新しいセッションを作成し、sessionIdをクッキーに追加する。
 （(注意: 実際には、サーバ・セッションによって開始され、サーバがクッキーにsessionIdを設定するだけで、クライアントはクッキーを持ち運び始めることができる)