Webセキュリティの詳しい解説（ペネトレーションテストの基礎）

1. Webの基礎知識

1.httpプロトコル

ハイパーテキスト転送プロトコルは、インターネット上で最も広く使用されているネットワーク プロトコルです。すべての www ファイルが遵守しなければならない規格は、ASCII コードで伝送される TCP/IP プロトコルに基づくアプリケーション層の仕様で、簡単に言うと固定の通信ルールです。

2. 3つのネットワークアーキテクチャとその特徴

ネットワーク アプリケーションのアーキテクチャには、次の 3 つのタイプがあります。
クライアント/サーバー構造 (C/S)
ブラウザ/サーバー構造 (B/S)
P2P 構造

C/Sアーキテクチャ

1. 特定のクライアント プログラムをインストールする必要があります
2. 異なるプラットフォーム向けに異なるバージョンを開発する
3. アプリをアップグレードするには再インストールが必要です
4. クライアントのハードウェア リソースを直接使用する機能

B/S構造

1. クライアントをインストールする必要はなく、Web ブラウザのみが必要です
2. クロスプラットフォーム機能
3. シームレスなアップグレード、クライアントのメンテナンス不要

P2P アーキテクチャ
ポイントツーポイント システム、サーバー転送の必要がなく、クライアントとクライアントが直接通信します。

3. Webアプリケーションの特徴

1. このアプリケーションはグラフィカルで操作が簡単で、ページ上にカラフルなグラフィックとテキストが表示されます。
2. アプリケーションはプラットフォームとは無関係であり、任意のプラットフォームを使用してインターネット経由でアクセスできます。
3. Web アプリケーションは分散されており、異なる情報を異なるサイトに配置できます。
4. Web アプリケーションは動的であり、Web サイトの情報にはサイト自体の情報が含まれ、情報提供者は Web サイトの情報を更新することもできます。

4. URLの構成

プロトコル: 使用するトランスポート プロトコルを指定します。
hostname: ホスト名
port: ポート番号
path: パス
パラメータ: パラメータ

query: オプション。パラメータを動的 Web ページに渡すために使用されます。複数のパラメータを「&」記号で区切って指定でき、各パラメータの名前と値は「=」記号で区切られます。

フラグメント: 情報フラグメント、文字列。ネットワーク リソース内のフラグメントを指定するために使用されます。

6. Http プロトコルの性質

1. HTTPは簡単です
2. HTTP はスケーラブルです
3. HTTP はステートレスであり、セッションがあります
4. HTTPは信頼できる

7. 要求応答メッセージのフォーマット

HTTP リクエスト メッセージは 3 つの部分に分かれています

1. リクエストラインのリクエストメソッド、URL、プロトコルバージョンなど（メッセージヘッダー）
2. リクエストヘッダーは、ヘッダードメイン名、コロン、および値フィールドで構成されます。
3. リクエストボディ

応答

1. 応答回線プロトコルとステータス コード ステータス コードの分類
2. 応答ヘッダー
3. レスポンスボディ

8. リクエスト方法

ポストオプションの取得 head put 削除 トレース 接続

9. httpキャッシュ

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。这样带来的好处有：缓解服务器端压力，提升性能(获取资源的耗时更短了)。

   
   
    
    

   
   
    
    

     
     
1
    
    

10. キャッシュの鮮度の判断方法

Web サーバーは、ブラウザーのキャッシュが最新かどうかを判断するために 2 つの方法 (
1、Last-Modified と If-Modified-Since
2、ETags と If-None-Match)を使用します。

11. HTTP リダイレクトの原則とステータス コード

在 HTTP 协议中，重定向操作由服务器通过发送特殊的响应（即 redirects）而触发。HTTP 协议的重定向响应的状态码为 3xx 。浏览器在接收到重定向响应的时候，会采用该响应提供的新的 URL ，并立即进行加载；大多数情况下，除了会有一小部分性能损失之外，重定向操作对于用户来说是不可见的。

   
   
    
    

   
   
    
    

     
     
1
    
    

1XX 命令
2XX リクエストは正常に送信されました
3XX リダイレクト
4XX クライアントによって送信されたリクエストに構文エラーがあります
5XX サーバー エラー

12. HTTPSプロトコルデジタル証明書

	HTTPS协议是以安全为目标的HTTP通道，其实就是HTTP的升级版本
数字证书：是由权威的CA（Certificate Authority）机构给服务端进行颁发，CA机构通过服务端提供的相关信息生成证书，证书内容包含了持有人的相关信息，服务器的公钥，签署者签名信息（数字签名）等，最重要的是公钥在数字证书中。

• 1
• 2
• 3

​

13. HTTPS プロトコルと HTTP プロトコルの違いは何ですか?

1. HTTP はハイパーテキスト転送プロトコルであり、情報はプレーン テキストで送信されます。一方、HTTPS は安全な SSL 暗号化転送プロトコルです。
2. HTTP は接続にポート 80 を使用しますが、HTTPS はポート 443 を使用します。
3. HTTPS プロトコルは CA に行って証明書を申請する必要があります。通常、無料の証明書はほとんどなく、料金を支払う必要があります。TOMCAT などの一部の Web コンテナでも証明書を提供しています。HTTP プロトコルは必要ありません。

14. Web クライアントの役割

1. HTTP リクエストの送信に使用されます
2. サーバー応答を受信する
3. サーバーから返された HTML コードをインターフェイス Web クライアント (主にブラウザー) にレンダリングします。

15. Webサーバーの機能

1. 顧客の要望を聞く
2. クライアントからの単純なリクエスト (通常は静的ページ) を処理します。
3. クライアントとデータベース間の障壁
4. ビジネスと複雑なシステムのデータベース アクセスを処理する

16. クラスタ環境の役割

	集群环境：服务器集群是指将很多服务器集中起来去进行同一种服务。集群可以利用多个计算机并行计算从而获得很高的计算速度（负载均衡），也可以用多个计算机做备份，从而使得实现故障转移。

 
 
  
  

 
 
  
  

   
   
1
  
  

17. Cookie とは何ですか、また Cookie は何をしますか。

Cookie: Cookie实际上是一小段的文本信息（key-value格式）。

クライアントはサーバーへのリクエストを開始し、サーバーがユーザーのステータスを記録する必要がある場合、応答を使用してクライアントのブラウザに Cookie を発行します。クライアントのブラウザは Cookie を保存します。ブラウザが Web サイトを再度リクエストすると、ブラウザはリクエストされた URL を Cookie とともにサーバーに送信します。サーバーは Cookie をチェックしてユーザーのステータスを識別します。

• 1
• 2
• 3

18. クッキーの種類

1. セッション Cookie: メモリに保存され、ブラウザによって維持され、ブラウザを閉じると消えます。
2. 永続 Cookie: 有効期限付きでハードディスクに保存され、ユーザーが手動でクリアするか、有効期限に達すると永続 Cookie が削除されます。

Expires 属性: Cookie の maxAge はこの属性を表すために使用され、単位は秒です。

19. セッションの役割と原則

在计算机中，尤其是在网络应用中，称为“会话控制”。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。

 
 
  
  

 
 
  
  

   
   
1
  
  

セッションの原則

1. ユーザーが初めてサーバーをリクエストすると、サーバーは sessionId を生成します。
2. サーバーは生成された sessionId を set-cookie を通じてクライアントに返します。
3. クライアントは sessionId を受信して​​ Cookie に保存し、クライアントが再度サーバーにアクセスすると、sessionId を取得します。
4. サーバーはクライアントから再度リクエストを受信すると、まず sessionId が存在するかどうかを確認し、存在しない場合は新しい sessionId を作成して 1 と 2 の処理を​​繰り返し、存在する場合はセッション ファイルを走査します。ファイル内のキー値は sessionId で、その値は現在のユーザーの情報です。
5. 後続のリクエストでは、この sessionId がステートフル セッションと交換されます。

Session の 2 つの実装 (つまり、配信メソッド)

1. Cookieを通じて実現
2. URL書き換えによる実装

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

1. Cookieデータはクライアントブラウザに保存され、セッションはサーバーに保存されます。
2. サーバー側のストレージ状態メカニズムはクライアント側でマークする必要があるため、セッションは Cookie メカニズムを使用する可能性があります。
3. Cookie は通常、ユーザーのログイン状態を保存するためにクライアントによって使用されます。
4. セッションはあらゆる種類のデータにアクセスできますが、Cookie は文字列のみを保存できます。
5. Cookie の保存データ サイズには制限がありますが、セッションには制限がありません

20. トークンの原理

1. ユーザーは、ユーザー名とパスワードを使用してリクエストを送信します。
2. プログラムの検証。
3. プログラムは署名されたトークンをクライアントに返します。
4. クライアントはトークンを保存し、リクエストを送信するたびにそれを使用します。
5. サーバーはトークンを検証し、データを返します。

21. データの暗号化方式

URL エンコードは、ブラウザーがフォーム入力をパッケージ化するために使用する形式です。

Base64 は、64 個の ASCII 文字で任意のバイナリ データを表す方法です。

MD5 は、メッセージの整合性を保護するためにコンピュータ セキュリティの分野で広く使用されているハッシュ関数です。現時点では取り消し不能です。

22. Webテストの種類

1. インターフェーステスト：ナビゲーションテスト、グラフィックステスト、コンテンツテスト、全体インターフェーステスト、インターフェース制御テスト
2. 機能テスト：
3. 性能試験
4. 互換性テスト
5. セキュリティテストなど

23. H5の利点

1. クロスプラットフォームの利点として、H5 ページはすべてのプラットフォームに適用でき、Web ページ上で直接デバッグおよび変更でき、開発とメンテナンスのコストが低く、開発サイクルが短いです。
2. Web ページのパフォーマンスが強化されました。2次元グラフィックスを描画するだけでなく、動画や音声を再生するためのタグも用意されています。
3. ローカルデータベースなどのWebアプリケーションの機能が追加されました。
4. H5マーケティングのデータ統計が便利

24. APPテスト/Webテスト/H5テストの違い

類似点

针对同一个系统功能的测试，三端所测的业务流程是一样的

通常、モバイル端末とPC端末の両方が一連のバックグラウンドサービスに対応しており、PCとモバイル端末の表示が不一致であったり、特殊な処理が発生したりする機能もあります。この場合、バックグラウンドは、対応するビジネス ニーズを処理するために 2 セットの異なるインターフェイスを作成します。

• 1
• 2
• 3

違い

1. テストプラットフォーム（コンテナ）が異なります
2. 互換性テストは異なります
3. システムアーキテクチャが異なります
4. リリースプロセスが異なります
5. APPにはいくつかの特別なテストもあります

25. モバイル端末でよく使われる3つの開発モード

主要有原生APP（Native App）、混合APP（Hybrid App）、WEB APP三种.

 
 
  
  

 
 
  
  

   
   
1
  
  

2. 探索的テスト

1. パススルーテスト: データの確認

2. 1 つをテストしてもう 1 つを無料にする: 2 つの同じ操作を同時に実行します。

3. トラバーサル テスト方法: ポップアップ ウィンドウをテストし、すべてのポップアップ ウィンドウをテストします。

4. 破壊試験方法: ネットワークやメモリなど。(最初の 4 つはほとんどがグローバルです)

3. アジャイルテスト手法

3.1 ウォーターフォール モデルとアジャイル モデルの比較

シーケンシャル (ウォーターフォール モデル): シンプル、段階的、段階間の因果関係があり、ユーザーの参加をサポートせず、事前に決定された要件が必要です。
適用範囲: 要件の定義が容易で変更が難しいソフトウェア システム。

アジャイル（反復型）：事前に要件を完全に定義する必要がなく、ユーザーの参加をサポートし、要件の段階的な改善と確認をサポートし、ユーザーのニーズの変化に適応できます。
適用範囲: 要件が複雑で、判断が難しく、動的に変更されるソフトウェア システム

3.2 スクラム フレームワークには 3 つの役割、3 つの成果物、5 つのイベント、および 5 つの値が含まれています

3 つの役割: プロダクトオーナー、スクラムマスター開発チーム

3 アーティファクト
製品バックログ
SprintBacklog
製品の増分

5つのイベント
スプリント（以下の4つのイベントを含むスプリント自体がイベントです）
スプリント計画会議
デイリースタンディングミーティング
スプリントレビュー会議
スプリントレビュー会議

5 つの価値観
コミットメント – 目標に取り組む意欲
フォーカス – コミットした仕事に自分の心と能力を注ぐ
オープン – スクラムでプロジェクトのすべてを全員にオープンにする
尊重 – 誰もが独自の背景と経験を持っている
勇気 – 信念を持つ約束をし、それを守り、他人の尊敬を受ける勇気

3.3 ユーザーストーリーは 3 つの要素で構成されます

1. 役割 (誰): 誰がこれを使用するのか
2. アクティビティ (何を): どのアクティビティを完了するか
3. Value（価値）：なぜこれをやりたいのか、これを行うことでどのような価値をもたらすことができるのか

3.4 ユーザーストーリーの特徴

1. 独立した
2. 議論可能
3. 貴重な
4. 推定できる
5. 小さい
6. テスト可能

3.5 ユーザーストーリーの優先順位付け

1.しなければならない 2.しなければならない 3.できる 4.してはならない

3.6 カンバンの役割

1. ステージと参加条件をクリアします。
2. 各ステージのタスクの数、コントロール WIP<=4。
3. リードタイムの​​時間の長さはさまざまです。
4. 提供される価値 提供される価値。
5. 情報の可視化と変更通知。

3.7 DevOpsとは何ですか

:文化の変化 + 自動化ツール = 市場の変化。開発モデルも: アジャイル + 自動化ツール

3.8 テスト左シフトとテスト右シフト

テスト左シフト

1. レビュー
2. テクノロジーの調整
3. 自己テストのエンパワーメント
4. 多役割のコラボレーション

テスト右シフト

1. グレースケール
2. モニター
3. 問題の帰属

4. ウェブセキュリティ

4.1 侵入テストの主な目的は何ですか?

通过实际的攻击进行安全测试与评估的方法就是渗透测试

 
 
  
  

 
 
  
  

   
   
1
  
  

4.2 侵入テストのプロセス

1. 明確な目標
2. メッセージを収集する
3. 脆弱性の検出
4. 脆弱性の検証
5. レポートを書く
6. 情報の収集と分析

4.3 情報収集の内容

1. ドメイン情報
2. 機密ディレクトリ
3. ポートスキャン
4. サイドステーションセクションC
5. サイト全体の分析

4.4 同一生成元ポリシーの概念と意義

概念: 2 つのページ アドレスのプロトコル、ドメイン名 (または IP)、サブドメイン名、およびポート番号は一貫しており、同じ発信元であることを示しています。

意味: 「ドキュメント」またはさまざまなソースからのスクリプトが現在の「ドキュメント」の特定のプロパティを読み取ったり設定したりすることを制限します。

4.5 ブラウザサンドボックス

サンドボックス: 「リソース分離モジュール」の同義語

デザインサンドボックスの目的:

1. 信頼できないコードを特定の環境で実行し、信頼できないコードによる隔離領域外のリソースへのアクセスを制限します。

2. サンドボックスの境界を越えてデータ交換を生成する必要がある場合、リクエストの合法性が厳密にチェックされる、カプセル化された API などの指定されたデータ チャネルを通じてのみ実行できます。

4.6 悪意のある Web サイトのブロックメカニズム

ブラウザは、最新の悪意のある URL のブラックリストをサーバーから定期的に取得し、ユーザーがインターネット上でアクセスする URL がこのブラックリストに含まれている場合、ブラウザは警告ページをポップアップ表示します。

4.7 XSS攻撃の原理

攻撃者は、それらの間に JavaScript コードを入力して、何らかの「特殊効果」を実現できます。
実際の攻撃では、攻撃者はボックスをポップアップさせるだけでなく、通常、

外部スクリプトをロードする方法、

攻撃者の悪意のある JavaScript コードは x.txt に保存されており、このコードは
ユーザーの Cookie を盗んだり、キーロギングなどの悪意のある動作を監視したりするために使用される可能性があります。

4.8 3 種類の xss

反射型: パラメータ インスタンスに悪意のあるコードを添付します。

ストレージ タイプ: ユーザーが XSS コードを送信すると、そのコードはサーバーによって受信および保存され、攻撃者が再度ページにアクセスすると、プログラムによって XSS コードが読み取られ、ブラウザーに応答します。

DOM: JavaScript を通じてページの DOM ノードを変更することによって形成される XSS

4.9 XSS脆弱性の防止

1. HTMLをフィルタリングする
2. PHP が JS コードに出力する場合、または Json API を開発する場合、フロントエンドは JS でフィルターする必要があります。
3. Cookieを設定するときに、HttpOnlyパラメータを追加します

4.10 SQL インジェクションとは何ですか?

SQL インジェクションとは、Web ページの元の URL、フォーム フィールド、またはデータ パケット入力パラメータを変更して SQL ステートメントに結合し、それらを Web サーバーに渡し、さらにデータベース サーバーに渡してデータベース コマンドを実行することです。

4.11 SQL インジェクションの種類?

1. キャラクターインジェクション
2. デジタルインジェクション
3. 盲注
4. 関節注射

4.12 ブラインドの種類は?

1. ブールブラインド
2. 時間盲目

4.13 ファイルインクルードの脆弱性とは何ですか?

コードの柔軟性を高めるために、開発者は通常、インクルードされるファイルを動的呼び出し用の変数として設定しますが、この柔軟性があるからこそ、クライアントは悪意のあるファイルを呼び出すことができ、その結果、ファイルインクルードの脆弱性が発生します。PHP、JSP、ASP、その他の言語にはファイル インクルードの脆弱性が存在する可能性がありますが、それらのほとんどは PHP にあります。

4.14 ファイルインクルードの脆弱性を悪用して、次の 2 つの条件を満たすか?

1. Include() およびその他の関数は、動的変数を通じてインクルードする必要があるファイルを導入します。
2. ユーザーはこの動的変数を制御できます

4.15 ファイルには脆弱性対策が含まれています

1. ファイルインクルードの脆弱性悪用の成功の鍵は、インクルードされたファイルが外部から制御できるかどうかであるため、インクルード内のパラメータが外部から制御可能かどうかを厳密に判断します。
2. パス制限: 含まれるファイルが特定のフォルダー内にのみ存在するように制限し、「.../」などのディレクトリ ジャンプ文字を禁止する必要があります。
3. インクルード ファイルの検証: インクルードされたファイルがホワイト リストのメンバーであるかどうかを確認します。
4. 動的インクルージョンは使用しないようにしてください。インクルードする必要があるページで、include("head.php"); のように修正できます。

4.16 ファイルアップロード検知の内容は何ですか?

1. クライアント検出: ファイルがアップロードされていない場合、クライアントは JS 検出を使用してファイルを検証します。
2. サーバー側の検出: ファイル拡張子が正当かどうかを検出し、ファイルに悪意のあるコードが埋め込まれているかどうかを検出します。

4.17 ファイルアップロードの脆弱性を防ぐ一般的な方法は?

1. ファイルがアップロードされるディレクトリは実行不可能に設定されています
2. ファイルの種類を決定する
3. ファイル名とファイルパスを乱数で上書きします
4. ファイルサーバーのドメイン名を別途設定

4.18 クリックジャッキングとは何ですか?

攻击者使用一个透明的、不可见的iframe,覆盖在一个网页上,然后诱使用户在该网页上进行操作，此时用户将在不知情的情况下点击透明的iframe页面。通过调整iframe的位置，可以诱使用户恰好点击在iframe页面的一些功能性按钮上。

 
 
  
  

 
 
  
  

   
   
1
  
  

​

4.19 CSRF 原則?

攻撃者は、何らかの技術的手段を使用してユーザーのブラウザをだまして、認証した Web サイトにアクセスし、何らかの操作 (電子メールの送信、メッセージの送信、さらには送金や商品の購入などの資産操作など) を実行します。ブラウザは認証されているため、訪問したWebサイトは実際のユーザーの操作とみなされ、実行されます。これは、Web 上のユーザー認証の抜け穴を利用しています。単純な認証では、リクエストがユーザーのブラウザから送信されたことのみを保証できますが、リクエスト自体がユーザーによって自発的に送信されたことは保証できません。

4.20 CSRF防御?

1. HTTP リファラーフィールドを検証する
2. 2回目の確認のため認証コードを入力してください
3. トークン認証。トークンを使用して CSRF を防御します。
4. クッキーのハッシュ化

4.21 HTML5 のセキュリティ上の問題?

1. CORS攻撃
2. ウェブストレージ攻撃
3. Web ワーカー攻撃
4. 新しいタブ攻撃

4.22 セッション攻撃手法は？

1. セッション固定攻撃

サーバー上のアプリケーション システムのセッション ID 固定化メカニズムを使用して、他人から同じセッション ID による認証と認可を取得し、そのセッション ID を使用して他人のセッションを乗っ取り、他人になりすますことにより、セッション固定攻撃が発生します。

2. セッションは攻撃を続ける

セッションにはライフサイクルがあります。攻撃者は有効なセッションを保持します。セッションが期限切れになっていない場合、攻撃は常にこの有効なセッションを通じてユーザーのアカウントを使用し、永続的な「バックドア」となります。

4.23 シングルサインオン

SSOと略されます。複数のアプリケーション システムでは、一度ログインするだけで他のすべてのアプリケーション システムにアクセスできます。

4.24 ロールベースのアクセス制御とデータベースのアクセス制御

ロールベースのアクセス制御: アクセス制御は、実際にはユーザーとアクセス許可の間の対応関係を確立します。
水平的なアクセス許可管理は、システムにデータ レベルのアクセス制御がないために発生するためです。

4.25 OAuth 2.0の原則

OAuth では、上記の問題を解決するために認証リンクが導入されています。サードパーティ アプリケーションが保護されたリソースへのアクセスを要求すると、リソース サーバーは、リソース ユーザーによって承認された後、サードパーティ アプリケーションにアクセス トークン (AccessToken) を発行します。アクセス トークンには、リソース ユーザーの許可されたアクセス範囲や許可の有効期間などの主要な属性が含まれます。サードパーティ アプリケーションは、ユーザーが認証を積極的に終了するか、トークンの有効期限が自動的に切れるまで、後続のリソース アクセス プロセスでトークンを保持する必要があります。

4.26 4 つの認証方法

1. 認証コード
2. 隠れた
3. 暗号
4. クライアント資格情報
   n が無効化されていない場合、攻撃は常にこの有効なセッションを通じてユーザーのアカウントを使用し、永続的な「バックドア」となります。

4.23 シングルサインオン

SSOと略されます。複数のアプリケーション システムでは、一度ログインするだけで他のすべてのアプリケーション システムにアクセスできます。

4.24 ロールベースのアクセス制御とデータベースのアクセス制御

ロールベースのアクセス制御: アクセス制御は、実際にはユーザーとアクセス許可の間の対応関係を確立します。
水平的なアクセス許可管理は、システムにデータ レベルのアクセス制御がないために発生するためです。

4.25 OAuth 2.0の原則

OAuth では、上記の問題を解決するために認証リンクが導入されています。サードパーティ アプリケーションが保護されたリソースへのアクセスを要求すると、リソース サーバーは、リソース ユーザーによって承認された後、サードパーティ アプリケーションにアクセス トークン (AccessToken) を発行します。アクセス トークンには、リソース ユーザーの許可されたアクセス範囲や許可の有効期間などの主要な属性が含まれます。サードパーティ アプリケーションは、ユーザーが認証を積極的に終了するか、トークンの有効期限が自動的に切れるまで、後続のリソース アクセス プロセスでトークンを保持する必要があります。

4.26 4 つの認証方法

1. 認証コード
2. 隠れた
3. 暗号
4. クライアントの資格情報

1. Webの基礎知識

1.httpプロトコル

ハイパーテキスト転送プロトコルは、インターネット上で最も広く使用されているネットワーク プロトコルです。すべての www ファイルが遵守しなければならない規格は、ASCII コードで伝送される TCP/IP プロトコルに基づくアプリケーション層の仕様で、簡単に言うと固定の通信ルールです。

2. 3つのネットワークアーキテクチャとその特徴

ネットワーク アプリケーションのアーキテクチャには、次の 3 つのタイプがあります。
クライアント/サーバー構造 (C/S)
ブラウザ/サーバー構造 (B/S)
P2P 構造

C/Sアーキテクチャ

1. 特定のクライアント プログラムをインストールする必要があります
2. 異なるプラットフォーム向けに異なるバージョンを開発する
3. アプリをアップグレードするには再インストールが必要です
4. クライアントのハードウェア リソースを直接使用する機能

B/S構造

1. クライアントをインストールする必要はなく、Web ブラウザのみが必要です
2. クロスプラットフォーム機能
3. シームレスなアップグレード、クライアントのメンテナンス不要

P2P アーキテクチャ
ポイントツーポイント システム、サーバー転送の必要がなく、クライアントとクライアントが直接通信します。

3. Webアプリケーションの特徴

1. このアプリケーションはグラフィカルで操作が簡単で、ページ上にカラフルなグラフィックとテキストが表示されます。
2. アプリケーションはプラットフォームとは無関係であり、任意のプラットフォームを使用してインターネット経由でアクセスできます。
3. Web アプリケーションは分散されており、異なる情報を異なるサイトに配置できます。
4. Web アプリケーションは動的であり、Web サイトの情報にはサイト自体の情報が含まれ、情報提供者は Web サイトの情報を更新することもできます。

4. URLの構成

プロトコル: 使用するトランスポート プロトコルを指定します。
hostname: ホスト名
port: ポート番号
path: パス
パラメータ: パラメータ

query: オプション。パラメータを動的 Web ページに渡すために使用されます。複数のパラメータを「&」記号で区切って指定でき、各パラメータの名前と値は「=」記号で区切られます。

フラグメント: 情報フラグメント、文字列。ネットワーク リソース内のフラグメントを指定するために使用されます。

6. Http プロトコルの性質

1. HTTPは簡単です
2. HTTP はスケーラブルです
3. HTTP はステートレスであり、セッションがあります
4. HTTPは信頼できる

7. 要求応答メッセージのフォーマット

HTTP リクエスト メッセージは 3 つの部分に分かれています

1. リクエストラインのリクエストメソッド、URL、プロトコルバージョンなど（メッセージヘッダー）
2. リクエストヘッダーは、ヘッダードメイン名、コロン、および値フィールドで構成されます。
3. リクエストボディ

応答

1. 応答回線プロトコルとステータス コード ステータス コードの分類
2. 応答ヘッダー
3. レスポンスボディ

8. リクエスト方法

ポストオプションの取得 head put 削除 トレース 接続

9. httpキャッシュ

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。这样带来的好处有：缓解服务器端压力，提升性能(获取资源的耗时更短了)。

   
   
  
  

   
   
  
  

   
   
1
  
  

10. キャッシュの鮮度の判断方法

Web サーバーは、ブラウザーのキャッシュが最新かどうかを判断するために 2 つの方法 (
1、Last-Modified と If-Modified-Since
2、ETags と If-None-Match)を使用します。

11. HTTP リダイレクトの原則とステータス コード

在 HTTP 协议中，重定向操作由服务器通过发送特殊的响应（即 redirects）而触发。HTTP 协议的重定向响应的状态码为 3xx 。浏览器在接收到重定向响应的时候，会采用该响应提供的新的 URL ，并立即进行加载；大多数情况下，除了会有一小部分性能损失之外，重定向操作对于用户来说是不可见的。

   
   
  
  

   
   
  
  

   
   
1
  
  

1XX 命令
2XX リクエストは正常に送信されました
3XX リダイレクト
4XX クライアントによって送信されたリクエストに構文エラーがあります
5XX サーバー エラー

12. HTTPSプロトコルデジタル証明書

	HTTPS协议是以安全为目标的HTTP通道，其实就是HTTP的升级版本
数字证书：是由权威的CA（Certificate Authority）机构给服务端进行颁发，CA机构通过服务端提供的相关信息生成证书，证书内容包含了持有人的相关信息，服务器的公钥，签署者签名信息（数字签名）等，最重要的是公钥在数字证书中。