【コンピューターネットワーク】HTTPインタビューテストサイト

テストポイント1：コンピューターネットワークレイヤー、アプリケーションレイヤーhttpはJavaプログラマーに最も近いレイヤーです

テストポイント1：コンピューターネットワークの階層化。アプリケーションレイヤーのhttpは、Javaプログラマーに最も近い
レイヤーです。コンピューターネットワークを学んだときに知っていました。コンピューターネットワークを5つのレイヤーに階層化しました。現在はTCP / IPを使用しています。そのような層状構造。
公式はISOが提案する7層構造ですが、理論的な根拠に過ぎません。実際、ほとんどの人がTCP / IPの層構造を使用しています。
まず、コンピュータネットワークを層に分割する必要があるのはなぜですか。？？
なぜなら、2台のコンピューターが通信できると、実際の操作が非常に難しいからです…階層化の目的は、難しい問題を単純化することであり、階層化すると、使用するときだけ注意を払うことができます。他のレベルに関係なく、レベルに注意を払う必要があります。
デザインを変更する必要がある場合は、他のレイヤーを使用せずに、変更したレイヤーを置き換えるだけで済みます。これは、プログラミングにおける結合が少ない概念です。

インタビュー言語の構成：HTTPプロトコルは最上位層、つまりアプリケーション層にあります。これはJavaプログラマーに最も近いレベルです。
コンピューターネットワークレベルから、JavaプログラマーはHTTP、HTTPS、DNS、SSL / TLS、および対称性を学習する必要があります。暗号化と非対称暗号化次
に、トランスポート層でのTCP / UDP 3ウェイハンドシェイク、4つのウェーブハンド、
ネットワーク層のIPプロトコル、ARPプロトコル、IPアドレス、Macアドレス
、データリンク層と物理層、基本的には何もありません。使用する。

チート1：HTTPプロトコルは、アプリケーション層である最上位層にあります。これは私たちのプログラマーに最も近いレベルです。
チート2：http + ssl / tls = https

テストポイント2：コンピューターネットワーク通信プロセス（ブラウザー/クライアント+サーバー）

テストポイント2：コンピュータネットワーク通信プロセス（ブラウザ/クライアント+サーバー）
HTTPがアプリケーション層にあることはわかっています。明らかに、Web通信のプロセスでは、HTTPプロトコルだけでなく、他のプロトコルも必要です。契約。
アプリケーション層：DNS：ドメイン名の解決を担当します
。Webページにアクセスするとき、ドメイン名を介してwww.zhongfucheng.siteにアクセスすることがよくあり、コンピューター通信はホストアドレス（192.168.xxx.xxx）のみを認識します。ドメイン名を入力するとき、アクセスのためにドメイン名をホストに解決するためにDNSが必要です。
アプリケーション層：HTTP：要求メッセージデータの生成
Webページを操作すると、HTTPメッセージデータが生成され、対応するサーバーに応答を要求します。

TCPプロトコル：HTTPデータを分割してデータ転送を保証します
。TCPプロトコルはスリーウェイハンドシェイクを使用してデータの正確な転送を保証します。データを転送するとき、識別子はサーバーに送信され、サーバーは識別子をクライアントに返し、クライアントは受信します。メッセージを受信した後、識別子は再びサーバーに返されます。これにより、データ転送の信頼性が確保されます。
ネットワーク層：IPプロトコル：データパケットの送信、通信先アドレスの検索（チート：IPアドレスはネットワークアドレス、変更されます、Macアドレスはハードウェアアドレス、変更されません、ARPプロトコルはIPアドレスを次のように反映できます） Macアドレス）。
IPプロトコルは、生成されたデータパケットを相手に送信します。IPアドレスはノードのアドレスを示しますが、IPアドレスは変更される可能性があります。ARPプロトコルを使用して、IPアドレスをMACアドレスに反映できます。MACアドレスは変更されません。これはネットワークカードの固定アドレスです。
通信先を見つける前に、継続的に転送する必要があります。このプロセスは「ルート転送」と呼ばれ、ルートが何回転送されたかはわかりません。そのため、インターネット上での送信状況を完全に把握することはできません。
データリンクレイヤー：省略。
物理層：省略。

テストポイント3：ブラウザ/クライアントはサーバーにリクエストの意図を通知する必要があります（GET | POST）

テストポイント3：ブラウザ/クライアントはサーバーにリクエストの意図を通知する必要があります（GET | POST）
Webプログラムを開発した場合、一般的に使用される送信メソッドはPOSTメソッドとGETメソッドであり、GETがデータの取得に使用されることもわかっています。 POSTはデータの送信に使用されます。
実際、HTTPプロトコルでは、Input、Delete、OPTIONSなどの他のメソッドがサポートされています。また、一般的に使用されているため、GETメソッドとPOSTメソッドしかわからない場合があります。
HTTPメソッドの目的は、クライアントが実行する操作をサーバーに通知することです。HTTPがOPTIONSメソッドの場合、サーバーはサポートするHTTPメソッドを返します。
もちろん、現在はRESTfulが普及しており、HTTPプロトコルのこれらのメソッドを最大限に活用することです。

テストポイント4：HTTPはステートレスプロトコル、つまりユーザーステータスを保存しないプロトコルです

テストポイント4：HTTPはステートレスプロトコル、つまりユーザー状態を保存しないプロトコルです
。HTTPはステートレス、つまり通信状態を保存しません。以前に誰と通信したかはわかりません。この設計の目的は、HTTPを簡素化し、多数のトランザクションを迅速に処理することです。

質問：Webバックエンド開発では、誰がアクセスしているかを知る必要があることがよくあります。httpプロトコルではユーザーステータスを保存できないため、ユーザーステータスを保存するための最も基本的なCookieテクノロジーを実装するにはどうすればよいですか。
回答：Cookieテクノロジーを使用してください。サーバーがクライアントを記憶したい場合は、クライアントにCookieを発行します。クライアントはCookieをハードディスクに保存します。サーバーが次回サーバーにアクセスすると、ブラウザは自動的にクライアントのCookieを取得します。このようにして、サーバーはこの男が誰であるかを知ることができます。
ps：セッションはサーバーメモリに保存されるため、揮発性です。セッションは保存され、CookieまたはURLリダイレクトを介して送信されます。

テストポイント5：永続的な接続（短い接続から長い接続、HTTP1.0からHTTP1.1）

テストポイント5：永続的な接続（短い接続から長い接続、
HTTP1.0からHTTP1.1）HTTP1.0は短い接続です：HTTP1.0では、HTTP通信が切断されるたびに。テキスト送信の容量が少ない場合は問題ありません。しかし、Webページにアクセスすると、そのWebページにはたくさんの写真があります。画像はHTTPリクエストと見なされます。次に、旅の途中で、TCP接続が継続的に確立され、画像が取得され、TCP接続が切断されます。
HTTP1.1では長い接続が導入されます。これはリソースの浪費であるため、HTTP1.1バージョンでは永続的な接続です。1つのHTTP接続で複数の要求を処理できます。「パイプライン」方式で永続接続を送信することができます。HTTP接続では、サーバーが要求に応答するのを待たずに、2番目の要求を送信し続けることができます。

テストポイント6：伝送効率を向上させる2つの方法（圧縮とブロック）

テストポイント6：伝送効率を向上させる2つの方法（圧縮とブロック）

説明する前に、まずエンティティ本体とは何かを知る必要があります。
エンティティ本体は、HTTPでデータとして送信されるデータです。

一般に、エンティティの本文は、HTTPの一部であるメッセージの本文と同等にすることができます。
何も使用しない場合、サーバーから返されるデータエンティティ本体はそのまま返されます。伝送効率を向上させるには、2つの方法を使用できます
（1）圧縮：圧縮技術を使用してエンティティ本体のサイズを縮小し、クライアント側でデータを解析します
（2）ブロック：ブロック転送コーディングを使用してエンティティ本体をブロックで転送します。ブラウザがエンティティ本体に解決されると、それを表示できます。

テストポイント7：ブレークポイントでアップロードを再開します（機能：ブレークポイントでアップロードを再開します;実現：スコープ要求）

テストポイント7：ブレークポイントで
ダウンロードを再開する（機能：ブレークポイントでダウンロードを再開する;実装：範囲要求）何かのダウンロードプロセスで中断された場合は、前に再度ダウンロードする必要がありますが、中断中もダウンロードを続行できます。範囲データを取得するために使用できます。これは範囲要求と呼ばれます。
スコープリクエストの定義：リソースの一部のみがダウンロードされます。つまり、私の写真の半分がダウンロードされ、残りの半分をダウンロードするだけで完全な写真を作成できます。そして、リクエストする際には、ダウンロードされていない部分が必要です。
概要：

テストポイント8：一般的に使用されるステータスコードの簡単な説明

テストサイト8：一般的に使用されるステータスコードの簡単な説明（より重要で、頻繁な試験、インタビューでは、次の一般的なものを言うことができます）
2XX一般的に、要求は成功します
200通常の処理
204処理は成功しましたが、サーバーは新しいデータを返さず、表示ページは更新されません
206サーバーに対して範囲要求が行われ、データの一部のみが返されます
。3XXは通常
、リダイレクト301によって要求されたリソースに新しいURIが割り当てられ、URLアドレスが変更されたことを示します。[永続的なリダイレクト]
302要求されたリソースには一時的に新しいURIが割り当てられ、URLアドレスは変更されていません。[転送]
303 302と同じ機能ですが、クライアントがGETを使用してリソースを取得する必要があることは明らかです。[転送]
304添付の要求が送信されます。 、ただし条件を満たしていない[期限切れのキャッシュデータを返す]
307は302と同じですが、POST要求をGETに変換しません[転送]
4XXクライアントエラー
400要求メッセージ構文エラー401ID
を認証する必要が
あります403アクセスできません[実際には（連絡先の練習）、Nginxにはこれがよくあります]
404サーバーにはこのリソースがありません[実際には（連絡先の練習）、2つの状況：1。リソースが存在しません; 2。パスが間違ってい
ます] 5XXサーバーエラー
500内部リソースエラー[練習（練習あり）、バックエンドプログラマーが間違っている、自分でデバッグする]
503サーバーは言語組織へのインタビューで忙しい
：
最初の文：2XX要求が成功した、3XXリダイレクト、4XXクライアントエラー、5XXサーバーエラーが
最初2番目の文：上記の一般的に使用されるものを暗記し、拡張できるものに注意を払います。練習に関する限り、すべて直接暗記します。低すぎます。

テストポイント9：仮想ホスティング

テストポイント9：仮想ホスト（Nginxはこのテクノロジーを実装できます）、サーバーとクライアント間のアプリケーション
最初に言うことは、HTTPサーバーは複数のサイトを持つことができる、つまり、複数の仮想ホストをHTTPで構成できるということです。ユーザーが異なるホストにアクセスする場合、実際には同じHTTPサーバーにアクセスします。

テストポイント10：クライアントとサーバーでの通信データ転送用のアプリケーションもいくつかあります

テストポイント10：クライアントとサーバーでの通信データ転送に使用されるアプリケーションプログラムもいくつかあります。
プロキシ（クライアント側は順方向プロキシ、サーバー側は逆方向プロキシ）
を使用して、データをプロキシキャッシュとしてキャッシュできます。データを受信した後、クライアントはプロキシを直接使用してデータを取得
できます。これを使用して、Webサイトへのアクセスを制御し、アクセスログレコードを取得できます。
ゲートウェイ
は、HTTP以外の要求操作を提供し、データベースにアクセスできます。
トンネルは
、安全な通信パスを確立できます。SSLを使用できます。そして他の暗号化は通信することを意味します。
インタビュー言語構成（主にエージェント）：
1。エージェント定義：エージェントモードでは、エージェントクラスと実際のクラスは同じインターフェイスを実装します。フォワードプロキシかリバースプロキシかに関係なく、実際のエージェントです。
2.フォワードプロキシとリバースプロキシ：クライアント側のプロキシはフォワードプロキシであり、サーバー側のプロキシはリバースプロキシです。

テストポイント11：HTTPリクエストメッセージ、リクエストヘッダー（より重要）

テストポイント11：HTTP要求メッセージ、要求ヘッダー（より重要）
HTTP要求メッセージ：要求では、HTTPメッセージは、メソッド、URI、HTTPバージョン、HTTPヘッダーフィールドおよびその他の部分で構成されます。

リクエスト行[クライアントのリクエスト方法、リクエストされたリソース名、使用されたHTTPプロトコルのバージョン番号を
記述]ヘッダーフィールド[クライアントリクエストをホストするホスト、クライアントの環境情報などを記述]
空白行
ヘッダーフィールドの例：
Accept： text / html、image / * [ブラウザはサーバーにサポートするデータタイプを通知します]
Accept-Charset：ISO-8859-1 [ブラウザはサーバーにサポートする文字セットを通知します]
Accept-Encoding：gzip、compress [参照ブラウザはサーバーに圧縮形式をサポートしていることを通知します]
Accept-Language：en-us、zh-cn [ブラウザはサーバーにその言語環境を
通知します]ホスト：www.it315.org：80 [ブラウザはサーバーに必要なことを通知しますどのホストにアクセスするか]
If-Modified-Since：Tue、11 Jul 2000 18:23:51 GMT [ブラウザはサーバーにデータをキャッシュする時間を指示します]
参照元：http：//www.it315.org/index.jsp [参照ブラウザは、クライアントがそのページから来たことをサーバーに通知します—アンチホットリンク]
ユーザーエージェント：Mozilla / 4.0（互換、MSIE 5.5、Windows NT 5.0）[ブラウザはサーバーにブラウザのコアを通知します]
Cookie [参照デバイスは、持ってきたCookieが何であるかをサーバーに通知します]
接続：close / Keep-Alive [ブラウザは、リクエスト後にリンクを切断するか保持するかをサーバーに通知します]
日付：2000年7月11日火曜日18:23:51 GMT [ブラウザはサーバーにリクエストの時刻を通知します]

テストポイント12：HTTP応答メッセージ、応答ヘッダー（より重要）

テストポイント12：HTTP応答メッセージ、応答ヘッダー（より重要）
HTTP応答メッセージ：応答では、HTTPメッセージは、HTTPバージョン、ステータスコード（番号と理由フレーズ）、およびHTTPヘッダーフィールドの3つの部分で構成されます。

ステータス行[サーバーが要求を処理した結果を説明するために使用されます。]
ヘッダーフィールド[サーバーの基本情報とデータの説明を説明するために使用されます。これらのデータの説明を通じて、サーバーはクライアントに、しばらくしてから返送するデータの処理方法を通知できます]
空の行
エンティティコンテンツ[サーバーはクライアントを返送しますデータ]
ステータス行：
形式：HTTPバージョン番号ステータスコード理由の説明
ステータス行：HTTP / 1.1 200 OK
ステータスコードは、サーバーによる要求の処理結果を示すために使用されます。これは3桁の10進数です。応答ステータスコードは5つのカテゴリに分類されます。

ヘッダーフィールドの例：
場所：http：//www.it315.org/index.jsp [サーバーはブラウザにジャンプ先のページを
通知します]サーバー：apache tomcat [サーバーはブラウザにサーバーのモデル番号は何ですか]
Content-Encoding：gzip [サーバーはブラウザーにデータ圧縮形式を通知します]
Content-Length：80 [サーバーはブラウザーに返されるデータの長さを通知します]
Content-Language：zh-cn [サーバーはブラウザーにサーバーの言語を通知します環境]
Content-Type：text / html; charset = GB2312 [サーバーはブラウザーに返されるデータのタイプを通知します]
最終変更日：2000年7月11日火曜日18:23:51 GMT [サーバーはブラウザにリソースの最終更新時刻を
通知します]更新：1; url = http：//www.it315.org [サーバーはブラウザに定期的に更新するように通知します]
Content-Disposition：attachment; filename = aaa.zip [サーバーはブラウザにダウンロードとしてデータを開くように指示します]
Transfer-Encoding：chunked [サーバーはブラウザにデータをチャンクで送り返すように指示します]
Set-Cookie：SS = Q0 = 5Lb_nQ; path = / search [サーバーはブラウザにCookieを保存するように指示します]
有効期限：-1 [サーバーはブラウザにキャッシュを設定しないように指示します]
Cache-Control：no-cache [サーバーはブラウザにキャッシュを設定しないように指示します]
プラグマ：no-cache [サーバーは指示しますブラウザにキャッシュを設定しないでください]
接続：close / Keep-Alive [サーバーはブラウザに接続方法を指示します]
日付：2000年7月11日火曜日18:23:51 GMT [サーバーはブラウザにデータを送り返すタイミングを指示します]

テストポイント13：HTTP + SSL / TLS == HTTPS、対称暗号化、非対称暗号化

テストポイント13：HTTP + SSL / TLS == HTTPS、対称暗号化、非対称暗号化
HTTP安全でない
HTTPはセキュリティの観点から不十分であり、既存の3つのポイントに対する特定の変更：
（1）通信はプレーンテキストを使用します[コンテンツは暗号化されていません]
（2）通信相手の身元が確認されない場合、クライアントとサーバーの両方が自由に通信
できます。（3）メッセージの整合性を証明できません[他の人が監視された後、改ざんされる可能性があります]
通常、オンライン時にパケットキャプチャツールを使用して取得します。これはHTTPによって要求される情報であり、ネットワーク通信のTCP / IPでは避けられません。
HTTPメッセージを暗号化すると仮定すると、それはコンテンツの暗号化のみです。他の誰かがHTTPコンテンツを取得した場合、HTTPコンテンツを解読できなくても、改ざんされる可能性があります。
HTTP + SSL / TLS == HTTPS
SSLを使用して安全な通信回線を確立するのが最善です。そうすると、この回線でHTTP通信を実行できます。
実際、HTTPSはSSLでカバーされるHTTPです...
HTTPSは、暗号化に共有シークレット（対称暗号化）と非対称暗号化を組み合わせて使用​​します。非対称暗号化は必要なリソースが多すぎるため、常に非対称暗号化と通信することは不可能です。そのため、HTTPは通信回線の確立時に非対称暗号化を使用し、接続が確立された後、共有キー（対称暗号化）を使用して暗号化と復号化を行います。
認証の場合、HTTPSはサードパーティの認証機関に基づいて認証を取得します。したがって、認識された証明書は、サーバーが正当であるかどうかを検証できます。
クライアント側では、自分で証明書を購入する必要がありますが、これは実装が非常に困難です[証明書にはお金が必要です]。
したがって、ほとんどのWebサイトがフォーム認証を使用している場合でも、これは最も広く使用されているクライアント認証です。

インタビュー言語の構成：
1。HTTP+ SSL / TLS == HTTPS
2.プロセス：HTTPSは、暗号化に共有キー（対称暗号化）と非対称暗号化を使用します。非対称暗号化は必要なリソースが多すぎるため、常に非対称暗号化と通信することは不可能です。そのため、HTTPは通信回線の確立時に非対称暗号化を使用し、接続が確立された後、共有キー（対称暗号化）が暗号化と復号化に使用されます。