数据帧产生在哪一层,怎么理解数据帧

源设备和目标设备通过网线连接，就可以通过物理层的二进制传输数据。

数据链路层，会使用对应的协议找到物理层的二进制数据，解码得到以太网的部首信息和对应的IP数据包，再将IP数据包传给上层的网络层。

数据链路层>网络层>传输层>应用层，一层层的解码，最后就可以在浏览器中得到目标设备传送过来的「index.html」。

「TCP/IP协议族」

从字面意义上来讲，TCP/IP是指「传输层」的TCP协议和「网络层」的IP协议。

实际上，TCP/IP只是利用 IP 进行通信时所必须用到的协议群的统称。

具体来说，在网络层是IP/ICMP协议、在传输层是TCP/UDP协议、在应用层是SMTP、FTP、以及 HTTP 等。他们都属于 TCP/IP 协议。

交换机可以接入多台电脑

每个电脑网卡的 「MAC 地址」都是不一样的，电脑发送数据时，数据头部携带网卡的 MAC 地址，用 MAC 地址标识来不同的电脑

交换机就可以识别数据头部的 MAC 地址来区分不同的电脑

交换机除了能识别不同的电脑，还需要找到电脑连接的「交换机端口」，才能顺利的把数据从相应端口发送出去

交换机通过「自学机制」，把学习到的设备 MAC 地址和交换机端口号添加到 「MAC 地址表」，并根据 MAC 地址表进行数据「转发」

交换机需要记录的 MAC 地址表也越来越多，需要的交换机也越来越多

但是交换机的「容量和性能有限」，MAC 地址表无法记录全世界电脑的 MAC 地址和对应的端口号，MAC 地址表太大也无法快速查找到对应的 MAC 地址表项

于是就有了三层网络设备「路由器」，路由器可以把全世界的网络连接起来

局域网内的网络连接可以使用「交换机」，例如一个公司内的网络或者一个校园内的网络通过交换机连接

不同区域的局域网互联使用「路由器」

❝

那么如何区分不同的网络区域呢？又是如何跨网络区域进行数据转发的呢？

❞

路由器有多个端口，分别连接不同的网络区域，不同网络区域的 IP 地址「网络号不同」

它通过识别目的 IP 地址的「网络号」，再根据「路由表」进行数据转发

「请求方法」

HTTP1.0 定义了三种请求方法：GET, POST 和 HEAD方法。

HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

序 号方法描述1GET请求指定的页面信息，并返回实体主体。2HEAD类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头3POST向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。4PUT从客户端向服务器传送的数据取代指定的文档的内容。5DELETE请求服务器删除指定的页面。6CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。7OPTIONS允许客户端查看服务器的性能。8TRACE回显服务器收到的请求，主要用于测试或诊断。9PATCH是对 PUT 方法的补充，用来对已知资源进行局部更新 。

「GET请求和POST请求的区别」

1. GET 请求的请求参数是添加到 head 中，可以在 url 中可以看到；POST 请求的请求参数是添加到body中，在url 中不可见。
2. 请求的url有长度限制，这个限制由浏览器和 web 服务器决定和设置的，例如IE浏览器对 URL的最大限制为2083个字符，如果超过这个数字，提交按钮没有任何反应，因为GET请求的参数是添加到URL中，所以GET请求的URL的长度限制需要将请求参数长度也考虑进去。而POST请求不用考虑请求参数的长度。
3. GET请求产生一个数据包; POST请求产生2个数据包，在火狐浏览器中，产生一个数据包，这个区别点在于浏览器的请求机制，先发送请求头，再发送请求体，因为GET没有请求体，所以就发送一个数据包，而POST包含请求体，所以发送两次数据包，但是由于火狐机制不同，所以发送一个数据包。
4. GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
5. GET是幂等的，而POST不是(幂等表示执行相同的操作，结果也是相同的)
6. GET是获取数据，POST是修改数据

「状态码由3位数字组成，第一位定义响应的类别」

1XX：指示信息，表示请求以接收，继续处理

2XX：成功，表示请求已经被成功接收、理解、接受

• 200 OK 是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。
• 204 No Content 也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。
• 206 Partial Content 是应用于 HTTP 分块下载或断电续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3XX：状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是「重定向」。

• 301 Moved Permanently 表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问，搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址。
• 302 Moved Permanently 表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问，搜索引擎会抓取新的内容而保存旧的网址。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

• 304 Not Modified不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

4XX：状态码表示客户端发送的「报文有误」，服务器无法处理，也就是错误码的含义。

• 400 Bad Request表示客户端请求的报文有错误。
• 401 Unauthorized：缺失或错误的认证，这个状态代码必须和WWW-Authenticate报头域一起使用。
• 403 Forbidden表示服务器禁止访问资源，并不是客户端的请求出错。
• 404 Not Found表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5XX：状态码表示客户端请求报文正确，但是「服务器处理时内部发生了错误」，属于服务器端的错误码。

• 501 Not Implemented 表示客户端请求的功能还不支持。
• 502 Bad Gateway 通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。
• 503 Service Unavailable 表示服务器当前很忙，暂时无法响应服务器。
• 504 Gateway Timeout：网关超时，由作为代理或网关的服务器使用，表示不能及时地从远程服务器获得应答。

「301和302的区别」

301重定向，指页面永久性转移，表示为资源或页面永久性地转移到了另一个位置。

301是HTTP协议中的一种状态码，当用户或搜索引擎向服务器发出浏览请求时，服务器返回的HTTP数据流中头信息中包含状态码 301 ，表示该资源已经永久改变了位置。

302重定向是页面暂时性转移，搜索引擎会抓取新的内容而保存旧的网址并认为新的网址只是暂时的。

「长连接」

HTTP 1.1支持长连接

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

HTTP 1.1则支持持久连接Persistent Connection，并且默认使用，在同一个TCP的连接中可以传送多个HTTP请求和响应，多个请求和响应可以重叠，多个请求和响应可以同时进行，更加多的请求头和响应头

HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为Close时，客户端通知服务器返回本次请求结果后关闭连接。

「管道网络传输」

HTTP/1.1 采用了长连接的方式，这使得管道网络传输成为了可能。

即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以「减少整体的响应时间。」

举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求，管道机制则是允许浏览器同时发出 A 请求和 B 请求。

但是服务器还是按照「顺序」，先回应 A 请求，完成后再回应 B 请求，要是 前面的回应特别慢，后面就会有许多请求排队等着。

「Host字段」

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名，但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。

此外，服务器应该接受以绝对路径标记的资源请求。

「100Status」

HTTP/1.1加入了一个新的状态码100。

客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；

如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。

100状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

「Chunked Transfer Coding」

HTTP/1.1将发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。

这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。

「Cache」

HTTP/1.1在1.0的基础上加入了一些Cache的新特性，当缓存对象的Age超过Expire时变为Stable对象，Cache不需要直接抛弃Stable对象，而是与源服务器进行重新激活。

「HTTP2.0和HTTP1.X相比的新特性」

• 新的二进制格式，HTTP1.x的解析是基于文本
• 多路复用，即连接共享，即每一个request都是是用作连接共享机制的，一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面
• header压缩，HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小
• 服务端推送

HTTP/2 还在一定程度上改善了传统的请求 - 应答工作模式，服务不再是被动地响应，也可以「主动」向客户端发送消息。

举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，「减少延时的等待」，也就是服务器推送。

「数据流」

HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。

因此，必须要对数据包做标记，指出它属于哪个回应。

每个请求或回应的所有数据包，称为一个数据流（Stream）。

每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数

客户端还可以「指定数据流的优先级」。优先级高的请求，服务器就先响应该请求。

「HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别」

• HTTP/1.1的Pipeling为若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法；
• HTTP2.0多个请求可同时在一个连接上并行执行，某个请求任务耗时严重，不会影响到其它连接的正常执行

「使用UDP协议」

HTTP/2 主要的问题在于：多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。

所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的「所有的 HTTP 请求都必须等待这个丢了的包被重传回来」。

• HTTP/1.1 中的管道传输中如果有一个请求阻塞了，那么队列后请求也统统被阻塞住了
• HTTP/2 多请求复用一个TCP连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。

这都是基于 TCP 传输层的问题，所以 「HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！」

「HTTP与HTTPS的区别」

HTTP 是明文传输协议，HTTPS 协议是由 SSL HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全

• HTTPS比HTTP更加安全，对搜索引擎更友好，利于SEO，谷歌、百度优先索引HTTPS网页
• HTTPS需要用到SSL证书，而HTTP不用
• HTTPS标准端口443，HTTP标准端口80
• HTTPS基于传输层，HTTP基于应用层
• HTTPS在浏览器显示绿色安全锁，HTTP没有显示

「工作原理」

HTTPS 协议会对传输的数据进行加密，而加密过程是使用了非对称加密实现

HTTPS的整体过程分为证书验证和数据传输阶段，具体的交互过程如下：

• Client发起一个HTTPS的请求
• Server把事先配置好的公钥证书返回给客户端。
• Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书），如果验证通过则继续，不通过则显示警告信息。
• Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
• Server使用自己的私钥解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
• Server使用对称密钥加密明文内容A，发送给Client。
• Client使用对称密钥解密响应的密文，得到明文内容A。
• Client再次发起HTTPS的请求，使用对称密钥加密请求的明文内容B，然后Server使用对称密钥解密密文，得到明文内容B。

客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

❝

这就存在些问题，如何保证公钥不被篡改和信任度？

❞

所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将「服务器公钥放在数字证书」（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

通过数字证书的方式保证服务器公钥的身份，解决冒充的风险。

「请求头」

HTTP 请求报文由3部分组成(请求行 请求头 请求体)