[コンピュータネットワーク]あなたが本当に12個の知識ポイントHTTP（HTTPS）プロトコルDOを理解しています

OSI参照モデルとTCP / IP 5層モデルを説明1.

1.1 OSI 7層モデル

1.2 TCP / IP 5層モデル

1.3機器層

[機器の層]

1.4対応プロトコル層

2. HTTPプロトコルと機能

2.1基本概念

[！NOTE]
HTTPは、ハイパーテキスト転送プロトコル（ハイパーテキスト転送プロトコル）の略称です。それは、標準のクライアントサーバーモデルで、要求と応答で構成されるアプリケーション層プロトコルです。HTTPはステートレスなプロトコルです。

2.2パケットの構造

パケットの詳細

2.3プロトコル機能

1. 接続なし（理解に焦点を当てます）

• 接続あたり1つの要求を処理する制限。サーバがクライアントの要求を処理し、顧客の応答を受信した後、すなわち、切断。このようにして、送信時間を節約することができます。

1. ステートレス

• トランザクション処理とメモリのためのプロトコルではありません。

1. シンプルで速いです

• 代わりに、リクエストメソッドとパスを送るのサーバにすると顧客サービスの要求、。

1. 柔軟

• HTTPは、データ・オブジェクトの任意のタイプの送信を可能にします。コンテンツタイプでマークされている伝送のタイプです。

2.4要求メッセージ

• リクエストライン
  • 要求タイプ
  • リソースにアクセスするには
  • HTTPプロトコルのバージョン番号
• リクエストヘッダ
  • （キーと値のペアの一部）の使用を例示するために使用される付加情報サーバー
  • 例如：のUser-Agent、受け入れ、コンテンツタイプ、接続
• 空行
  • 要求ヘッダーとリクエストボディを分割
• リクエストボディ
  • あなたは、他のデータを追加することができます

2.5応答メッセージ

• ステートライン
  • ステータスコード
  • ステータスメッセージ
  • HTTPプロトコルのバージョン番号
• メッセージヘッダ
  • クライアントが使用する記述の追加情報
  • 以下のような：時間のContent-Type、文字セット、応答
• レスポンスボディ
  • クライアントのテキスト情報に戻ります

2.6 HTTPメソッド

• 取得する
  • リソースへのアクセス
• 役職
  • 送信リソース
• プット
  • 更新リソース
• DELETE
  • 削除リソース
• 頭
  • メッセージヘッダを取得します

2.6.1ポストとGETの違い

• ブラウザがロールバックされたときにGETは無害であり、POSTが再び提出されます
• 重点要求をキャッシュできるGET、POSTはできません
• Post相对Get相对安全一些，因为Get请求都包含在URL中，而且会被浏览器保存记录，Post不会。但是再抓包的情况下都是一样的。
• Post 可以通过 request body来传输比 Get 更多的数据
• URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的
• Post 支持更多的编码类型且不对数据类型限制
• 重点POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)
• 补充：100状态码表示（继续）请求者应当继续提出请求。 服务器返回此代码表示已收到请求的第一部分，正在等待其余部分。

副作用和幂等的概念

[!NOTE]

1. 副作用：指对服务器上的资源做改变，搜索是无副作用的，注册是副作用的。
2. 幂等：指发送 M 和 N 次请求（两者不相同且都大于 1），服务器上资源的状态一致，比如注册 10 个和 11 个帐号是不幂等的，对文章进行更改 10 次和 11 次是幂等的。

[!NOTE]
在规范的应用场景上说，Get 多用于无副作用，幂等的场景，例如搜索关键字。Post 多用于副作用，不幂等的场景，例如注册。

2.7 常见状态码

2.7.1 1XX 指示信息（面试考点）

表示请求已接收，继续处理

2.7.2 2XX 成功

• 200 OK
• 204 No content，表示请求成功，但响应报文不含实体的主体部分
• 205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
• 206 Partial Content，进行范围请求

2.7.3 3XX 重定向

• 301 永久性重定向，表示资源已被分配了新的 URL
• 302 临时性重定向，表示资源临时被分配了新的 URL
• 303 表示资源存在着另一个 URL，应使用 GET 方法获取资源
• 304 未修改，重定位到浏览器。自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。如果网页自请求者上次请求后再也没有更改过，您应将服务器配置为返回此响应（称为 If-Modified-Since HTTP 标头）。服务器可以告诉 Googlebot 自从上次抓取后网页没有变更，进而节省带宽和开销。
• 307 临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

2.7.4 4XX 客户端错误

• 404 在服务器上没有找到请求的资源
• 403 forbidden，表示对请求资源的访问被服务器拒绝
• 400 请求报文存在语法错误
• 401 表示发送的请求需要有通过 HTTP 认证的认证信息

2.7.5 5XX 服务器错误

• 500 表示服务器端在执行请求时发生了错误
• 501 表示服务器不支持当前请求所需要的某个功能
• 503 表明服务器暂时处于超负载或正在停机维护，无法处理请求

2.8 HTTP持久连接（HTTP1.1支持）

[!NOTE]
HTTP协议采用“请求-应答”模式，并且HTTP是基于TCP进行连接的。普通模式（非keep-alive）时，每个请求或应答都需要建立一个连接，完成之后立即断开。

当使用Conection: keep-alive模式（又称持久连接、连接重用）时，keep-alive使客户端道服务器端连接持续有效，即不关闭底层的TCP连接，当出现对服务器的后继请求时，keep-alive功能避免重新建立连接。

2.9 HTTP管线化 （HTTP1.1支持）

管线化后，请求和响应不再是依次交替的了。他可以支持一次性发送多个请求，并一次性接收多个响应。

• 只有get与head请求可以进行管线化，POST有限制
• 初次创建连接时不应该启动管线机制，因为服务器不一定支持该协议

2.10 HTTP数据协商

在客户端向服务端发送请求的时候，客户端会申明可以接受的数据格式和数据相关的一些限制是什么样的；服务端在接受到这个请求时他会根据这个信息进行判断到底返回怎样的数据。

2.10.1 请求

• cookie
• Host
  
• Connection
• Accept
  • 在请求中使用Accept可申明想要的数据格式(image/webp,image/apng,image/)
• Accept-Encoding
  • 告诉服务端使用什么的方式来进行压缩
  • 例如：gzip、deflate、br
• Accept-Language
  • 描述语言信息(zh-CN)
• User-Agent(Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.15 Safari/537.36)
  • 用来描述客户端浏览器相关信息
  • 可以用来区分PC端页面和移动端页面

2.10.2 响应

• Content-Type
  • 对应Accept，从请求中的Accept支持的数据格式中选一种来返回
• Content-Encoding
  • 对应 Accept-Encoding，指服务端到底使用的是那种压缩方式
• Content-Language
  • 对应Accept-Language

2.10.3 form 表单中enctype数据类型

• application/x-www-form-urlencoded
  • key=value&key=value 格式
• multipart/form-data
  • 用于提交文件
  • multipart表示请求是由多个部分组成（因为上传文件的时候文件不能以字符串形式提交，需要单独分出来）
  • boundary 用来分隔不同部分
• text/plain

// 原生ajax 方式对get的url，使用POST请求方式进行发送
document.querySelector("#btnAjax").onclick = function () {
     var ajax = new XMLHttpRequest();

     // 使用post请求
     ajax.open('post','ajax_post.php');

     // 如果 使用post发送数据 必须 设置 如下内容
     // 修改了 发送给 服务器的 请求报文的 内容
     // 如果需要像 HTML 表单那样 POST 数据，请使用 setRequestHeader() 来添加 HTTP 头。然后在 send() 方法中规定您希望发送的数据：
     ajax.setRequestHeader("Content-type","application/x-www-form-urlencoded");
     // 发送
     // post请求 发送的数据 写在 send方法中
     // 格式 name=jack&age=18 字符串的格式
     ajax.send('name=jack&age=998');

     // 注册事件
     ajax.onreadystatechange = function () {
         if (ajax.readyState==4&&ajax.status==200) {
             console.log(ajax.responseText);
         }
     }
 }

2.11 HTTP Redirect 重定向

• 302 暂时重定向
  • 浏览器每次访问都要先去目标网址访问，再重定向到新的网址
• 301 永久重定向
  • 当浏览器收到的HTTP状态码为301时，下次访问对应网址就直接调整到新的网址，不会再访问原网址

2.12 HTTP CSP 内容安全策略

HTTP CSP 内容安全策略

CSP Content-Security-Policy

• 限制资源获取
• 报告资源获取越权

例子：

• Content-Security-Policy: default-src http: https: 表示只允许通过http、https的方式加载资源
• 'Content -Security-Policy': 'default-src' \'self\'; form-action\'self\' ' 表示只能加载本域下的资源，只能向本域发送表单请求

2.12.1 TLS 握手过程如下图

1. 客户端发送一个随机值，需要的协议和加密方式
2. 服务端收到客户端的随机值，自己也产生一个随机值，并根据客户端需求的协议和加密方式来使用对应的方式，发送自己的证书（如果需要验证客户端证书需要说明）
3. 客户端收到服务端的证书并验证是否有效，验证通过会再生成一个随机值，通过服务端证书的公钥去加密这个随机值并发送给服务端，如果服务端需要验证客户端证书的话会附带证书
4. 服务端收到加密过的随机值并使用私钥解密获得第三个随机值，这时候两端都拥有了三个随机值，可以通过这三个随机值按照之前约定的加密方式生成密钥，接下来的通信就可以通过该密钥来加密解密.

通过以上步骤可知，在 TLS 握手阶段，两端使用非对称加密的方式来通信，但是因为非对称加密损耗的性能比对称加密大，所以在正式传输数据时，两端使用对称加密的方式通信。

3. HTTP2(面试重点)

[!NOTE]
HTTP 2.0 相比于 HTTP 1.X，可以说是大幅度提高了 web 的性能。

在 HTTP 1.X 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量，当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。

3.1 二进制传输

HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

3.2 多路复用

在 HTTP 2.0 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。

帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。

多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

3.3 Header 压缩

在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。

3.4 服务端 Push

在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。

可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch。

4. HTTP首部

通用字段	作用
Cache-Control	控制缓存的行为
Connection	浏览器想要优先使用的连接类型，比如 keep-alive
Date	创建报文时间
Pragma	报文指令
Via	代理服务器相关信息
Transfer-Encoding	传输编码方式
Upgrade	要求客户端升级协议
Warning	在内容中可能存在错误

请求字段	作用
Accept	正しく受信したメディアの種類
受け入れ、文字セット	正しく受信文字セット
受け入れエンコード	リストが正しくエンコード形式を受信することができます
受け入れる言語	正しく言語のリストを受け取り、
期待します	サーバーの動作を指定するために楽しみにしています
から	依頼者のメールアドレス
ホスト	ドメイン・ネーム・サーバ
もしマッチ	リソースタグの両端を比較
変更 - 開始	ローカルリソース未修飾リターン304（比較時間）
もし-なしマッチ	（比較マーカー）修飾されていないローカルリソース304戻ります
ユーザーエージェント	クライアント情報
マックス・フォワード	数は、エージェントとゲートウェイを転送することができる限界
プロキシ認証	プロキシサーバに認証情報を送信します
範囲	要求内容の一部
リファラー	アクセスへのブラウザのフロントページ
TO	転送エンコード

応答フィールド	効果
-範囲を受け入れます	範囲の特定の種類をサポートするかどうか
年齢	リソースは、プロキシキャッシュ時間内に存在します
ETagを	リソース識別
ロケーション	クライアントがURLにリダイレクトされます
プロキシ認証	プロキシサーバに認証情報を送信します
サーバ	サーバーの名前
WWW認証	認証情報に必要なリソースを獲得

エンティティのフィールド	効果
許します	要求リソースへの正しい方法
コンテンツのエンコード	コンテンツのエンコーディング形式
コンテンツ言語	言語コンテンツの利用
コンテンツの長さ	リクエストボディ長
コンテンツの場所	代替リターンアドレスデータ
Content-MD5	Base64でMD5暗号化形式のコンテンツチェック値
コンテンツレンジ	コンテンツの場所の範囲
コンテンツタイプ	メディアタイプのコンテンツ
有効期限	コンテンツの有効期限
最終更新日	最終更新内容

参考記事：https://www.cnblogs.com/qishui/p/5428938.html

参考リンク：https://blog.csdn.net/sinat_21455985/article/details/53508115