ブラウザがURLを入力してください入力した後に何をしますか？
（解決のURL - > DNSクエリ- > TCPコネクション- >処理要求- >応答を受け入れる- > [ページをレンダリング）
1は、入力が有効なURLやキーワードであるか否かを判断します
2は、ブラウザのキャッシュ（ - >システムキャッシュ - ブラウザのキャッシュ>ルータキャッシュ）を表示内容が直接表示されている場合は、第3のステップを取ることはありません
3、最初のHTTP DNSを送信する前に、IPを取得
4は、ブラウザサーバーがTCP接続を開始したい、TCP 3ウェイハンドシェイクを確立するために、
5、成功したハンドシェイクがHTTP要求、要求パケットを送信した後、
6、データ・サーバは、要求がブラウザに返されます受け取ります
図7に示すように、ブラウザは、デコード応答をHTTP応答を受信します
8、HTMLに埋め込まブラウザ要求リソースを取得します
9、ブラウザは、非同期リクエストを送信します
10、すべてのエンドをレンダリングするページ
いくつかの要求の方法を持ってhttpプロトコル、？
、POST、HEAD、OPTIONS、GET、および方法を接続します。
- GET：リソースへのアクセスの要求は、URI（統一資源識別子）が同定されている、URLを介してサーバにパラメータを渡すことができます
- POST：GETメソッドの主な機能と同様に、サーバーに情報を送信するために使用されるが、一般的にPOSTメソッドを使用することをお勧めします。
- PUT：ファイル転送は、メッセージ本体がファイルの内容を含む、対応するURIの位置に保存されています。
- HEAD：GETメソッドとメッセージヘッダは似てますが、一般的にURIが有効であることを確認するために使用され、メッセージ本文を返しません。
- DELETE：代わりに、ファイル、およびPUTメソッドを削除し、URIの位置に対応するファイルを削除します。
- OPTIONS：URIがサポートする適切なHTTPメソッドを確認してください。
GETとPOSTの違いは？
リンクの性質にGETとPOST TCPで、かつ非差別。しかし、彼らは、アプリケーション・プロセスにいくつかの違いを反映させるHTTPとブラウザ/サーバの規定に。
ブラウザがロールバックされ、POST要求を再び提出されたときにGETは無害です。
GET URLアドレスは、ブックマークを生成して、投稿しないことができます。
リクエストがアクティブキャッシュブラウザをされているGET、POSTしません、しない限り、手動で。
リクエストはURLだけエンコードすることができGET、POSTとは、複数のエンコーディングをサポートしています。
GETリクエストパラメータは、ブラウザの歴史の中で無傷である、とPOSTパラメータは保持されません。
リクエストパラメータは、URLの長さに渡される限られているが、POSTはそこにあるもの。
パラメータのデータ型は、GETはASCII文字のみを受け入れますが、何の制限POSTはありません。
パラメータは、直接URLに露出しているため、POSTよりも安全GET、機密情報を送信するために使用することはできません。
代わりにURLを経由して渡されたパラメータ、POSTリクエストボディをGET。
GETは、TCPパケットを生成し、POSTの2つのTCPパケットを生成します。
GETリクエストのために、ブラウザは、HTTPヘッダとデータは、一緒にサーバ応答200（リターンデータ）を送信します。
POSTのために、ブラウザは最初のヘッダを送信し、サーバ応答100を続けると、ブラウザは、サーバ200 OK（リターンデータ）に応答して、データを送信します。
POSTは、2つのステップを必要とするため、もう少し消費する時間は、それはGET、POSTよりも効果的と思われます。
だから、ヤフーチームは、サイトのパフォーマンスを最適化するために、GETとPOSTの交換を推奨しています。しかし、これはピットです！慎重にする必要性に飛び込みました。なぜ？
1. GETとPOSTだけで混合されていない、独自の意味を持っています。
2.調査によると、ネットワーク環境に送られた二つのパッケージ間の時間と時間の違いは、基本的に無視されたパッケージを送信、良いです。そして、2つのパケットの整合性の検証を超えるTCPパケット、貧弱なネットワーク環境の場合には、大きな利点があります。
3.すべてのブラウザがPOST中に2つのパケットを送信するわけではありません、Firefoxのは一度だけ送信されます。
HTTPとHTTPSの違い
HTTPデータ伝送プロトコルは、プレーンテキストは、したがって、データ伝送のプライバシーを確保するために、安全でない個人情報は、暗号化することができますされたHTTPプロトコルを使用して送信され、暗号化されていないので、とのNetscape SSL（Secure Sockets Layer）プロトコルを設計しデータ伝送のためのHTTPプロトコルは、このように、暗号化されたHTTPSを生まれました。簡単に言えば、HTTPSプロトコルはSSL + HTTPプロトコルから構成された伝送は、httpプロトコルのセキュリティよりもネットワーク認証プロトコルを暗号化することができます。
次のようにHTTPSとHTTPの主な違い：
全体：HTTPS = SSL + HTTP
1、httpsプロトコルは、このように料金が必要、一般にあまりフリー証明書、証明書を申請する必要があるCA。
図2は、HTTPの情報は、HTTPSは、セキュリティSSL転送プロトコルで暗号化され、平文で送信され、ハイパーテキスト転送プロトコルです。
図3は、HTTPおよびHTTPSの使用が完全に異なる接続である、ポートと同じではない、前者は443であり、80です。
（これは、ポートが実際に変更することができますされ、デフォルトのポートとまったく同じではありません）
図4は、HTTP接続が非常に簡単であり、ステートレスであり、セキュリティよりも、伝送プロトコル、ネットワーク認証プロトコル、HTTPプロトコルを暗号化されたHTTPSプロトコルSSL + HTTPによって構成されています。
図5は、OSIネットワークモデルは、HTTPのアプリケーション層で動作し、トランスポート・セキュリティ・メカニズムは、HTTPSトランスポート層で動作します
クッキーとセッションメカニズムメカニズムの違い
別の格納位置：クライアントデータに保存されたクッキーは、セッションデータはサーバーに保存されています。
異なるセキュリティレベル：クッキーは、サーバー上の圧力を軽減することができますが、安全な、簡単なクッキーは欺くために。
パフォーマンスの異なる程度を使用します。セッションより安全な、しかし、サーバーのリソースを取ります
異なるデータストレージサイズ：単一のクッキーデータが4Kを超えることはできません保存、多くのブラウザは、20のサイトの最大値に制限されているクッキーを保存したが、セッションがサーバで格納され、ブラウザはこれに限定されません。
セッションクッキーと永続的なCookieの違い
あなたは有効期限を設定しない場合、それはブラウジングセッション中にクッキーのライフサイクルは、単にブラウザウィンドウを閉じることを意味し、クッキーが消えました。ブラウジングセッションクッキーの人生のこの期間は、セッションクッキーと呼ばれています。一般的なセッションクッキーはハードディスクに保存されますが、メモリに保存されていません。
あなたは有効期限を設定した場合、ブラウザのクッキーを閉じた後、再びブラウザを開き、お使いのハードドライブに保存されます有効期限が設定を超えるまで、これらのクッキーは有効なまま。
ハードディスクに保存されたクッキーは、このような2つのIEのウィンドウとして、異なるブラウザプロセス間で共有することができます。メモリに保存されたクッキーのために、異なるブラウザは異なるアプローチを持っています。
HTTPプロトコルステートレスなプロトコルは、どのようにHTTPプロトコルステートレスなプロトコルを解決するために？何ですか？
思い出のないトランザクション処理のためのステートレスプロトコル。状態の欠如は、その後の処理は、以前の情報、つまり、HTTPリクエストが完了した後、クライアントは、クライアントがHTTPリクエストを送信するときに必要な場合、HTTPは現在のクライアントが知らないことを意味し、「古い顧客。」
クッキーはステートレスの問題を解決するために使用することができ、クライアントは再び、クッキー（パス）を保持する、サーバがあることを知っているとき、クッキーは、クライアントに送信されたクッキーの最初の訪問のパスに相当しますそれは「古い顧客」です。
HTTPリクエストとレスポンスメッセージフォーマット
Requestパケットは、次の4つの部分を含みます：
、リクエストライン：要求が含む方法、URI、HTTPのバージョン情報
B、リクエストヘッダフィールド
C、コンテンツ要求エンティティ
D、空白行
応答メッセージは、次の4つの部分を含みます：
、ステータス行は：HTTPのバージョン、ステータスコード、理由フレーズステータスコードを含み、
レスポンスヘッダフィールドでB、
C、応答内のコンテンツエンティティ
D、空白行
共通ヘッダ：
- 共通ヘッダフィールド（リクエストパケットと応答パケットのヘッダフィールドが使用されます）
- 日付：パケットの時間を作成します。
- 接続：接続管理
- Cache-Control：キャッシュ制御
- 転送エンコード：メッセージ本体の転送エンコード
- リクエストヘッダフィールド（要求パケットヘッダフィールドが使用されます）
- ホスト：サーバーリソース要求
- 受け入れ：処理できるメディアの種類を
- 受け入れ-文字セットを：文字セットを受け取ります
- -エンコーディングを受け入れ：許容可能なコンテンツのエンコード
- Accept-Language：可接受的自然语言
- 响应首部字段（响应报文会使用的首部字段）
- Accept-Ranges：可接受的字节范围
- Location：令客户端重新定向到的URI
- Server：HTTP服务器的安装信息
- 实体首部字段（请求报文与响应报文的的实体部分使用的首部字段）
- Allow：资源可支持的HTTP方法
- Content-Type：实体主类的类型
- Content-Encoding：实体主体适用的编码方式
- Content-Language：实体主体的自然语言
- Content-Length：实体主体的的字节数
- Content-Range：实体主体的位置范围，一般用于发出部分请求时使用
状态码
- 200：请求被正常处理
- 204：请求被受理但没有资源可以返回
- 206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
- 301：永久性重定向
- 302：临时重定向
- 303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
- 304：发送附带条件的请求时，条件不满足时返回，与重定向无关
- 307：临时重定向，与302类似，只是强制要求使用POST方法
- 400：请求报文语法有误，服务器无法识别
- 401：请求需要认证
- 403：请求的对应资源禁止被访问
- 404：服务器无法找到对应资源
- 500：服务器内部错误
- 503：服务器正忙
具体可参考：https://www.runoob.com/http/http-status-codes.html
http优化方案
HTTP优化方案
- TCP复用：TCP连接复用是将多个客户端的HTTP请求复用到一个服务器端TCP连接上，而HTTP复用则是一个客户端的多个HTTP请求通过一个TCP连接进行处理。前者是负载均衡设备的独特功能；而后者是HTTP 1.1协议所支持的新功能，目前被大多数浏览器所支持。
- 内容缓存：将经常用到的内容进行缓存起来，那么客户端就可以直接在内存中获取相应的数据了。
- 压缩：将文本数据进行压缩，减少带宽
- SSL加速（SSL Acceleration）：使用SSL协议对HTTP协议进行加密，在通道内加密并加速
- TCP缓冲：通过采用TCP缓冲技术，可以提高服务器端响应时间和处理效率，减少由于通信链路问题给服务器造成的连接负担。
参考文献：