网络协议面试题

最新推荐文章于 2024-02-21 15:12:50 发布

哈哈ha~

最新推荐文章于 2024-02-21 15:12:50 发布

阅读量729

点赞数 1

分类专栏： node.js 文章标签：服务器网络协议

本文链接：https://blog.csdn.net/qq_56668869/article/details/126297135

版权

node.js 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

一、终端、客户端与服务器

终端：

也称终端设备，是指实物，如笔记本、手机、平板、电视机、打印机、指纹打卡机等等

客户端：

是指为客户提供本地服务的应用程序，如浏览器、电子邮件客户端，但是客户端功能的实现往往需要与服务器相互配合，接收服务器的服务

服务器：

视为客户端提供服务的应用程序。根据业务的服务类型不同，可分为文件服务器、数据库服务器、应用程序服务器、web服务器、视频服务器等

客户端电脑上安装的是日常使用的应用软件

如QQ、音乐播放器、浏览器等，这些应用都可以被称为客户端

服务器电脑上安装的是为客户端提供服务的软件

如提供网页服务的应用有：Apache/Nginx/Tomcat/IIS等
提供文件上传和下载服务的有vsftp等
提供邮件服务的应用有posfix等

两种体系结构：

B/S：

使用H5技术开发网页应用部署到服务器上，用户在浏览器上访问，称为B/S（Browser/Server）结构

C/S：

使用H5技术开发APP、小程序等应用，服务器端放到服务器上，称为C/S（Client/Server）结构

二、网络协议

（一）输入 URL 到页面渲染发生了什么？

1.DNS解析

DNS 的作用就是通过域名查询到具体的 IP（即把域名解析为IP地址）

域名相当于某个 IP 的别名，DNS 就是去查询这个别名的真正名称是什么。

在 TCP 握手之前就已经进行了 DNS 查询，这个查询是操作系统自己做的。

若想浏览器中访问www.google.com时，会进行以下操作（DNS 迭代查询）：

操作系统会首先在本地缓存中查询 IP

没有的话会去系统配置的 DNS 服务器中查询

如果也没有的话，会直接去 DNS 根服务器查询，这一步查询会找出负责com这个一级域名的服务器然后去该服务器查询google这个二级域名接下来三级域名的查询其实是我们配置的，可以给www这个域名配置一个 IP，还可以给别的三级域名配置一个 IP

还有一种是递归查询，区别就是前者是由客户端去做请求，后者是由系统配置的 DNS 服务器做请求，得到结果后将数据返回给客户端。

2.TCP握手

应用层会下发数据给传输层，这里 TCP 协议会指明两端的端口号，然后下发给网络层。网络层中的 IP 协议会确定 IP 地址，并且指示在数据传输中如何跳转路由器。然后数据包会再被封装到数据链路层的数据帧结构中，最后就是物理层面的传输了。

在这一部分中，可以详细说下 TCP 的握手情况以及 TCP 的一些特性。

当 TCP 握手结束后就会进行 TLS 握手，然后就开始正式的传输数据

3.TLS握手

数据在进入服务端之前，可能还会先经过负责负载均衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时假设服务端会响应一个 HTML 文件。

首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向，这里会有个重定向计数器，避免过多次的重定向，超过次数也会报错。

4.浏览器开始解析文件

浏览器开始解析文件，如果是 gzip 格式(是一种优化)的话会先解压一下，然后通过文件的编码格式知道该如何去解码文件。

5.构建 DOM 树、构建 CSSOM 树、解析JS

文件解码成功后会正式开始渲染流程，先会根据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话，会判断是否存在 async 或者 defer ，前者会并行进行下载并执行 JS，后者会先下载文件，然后等待 HTML 解析完成后顺序执行。

如果以上都没有，就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件，这里如果使用 HTTP/2 协议的话会极大的提高多图的下载效率。

6.生成 Render 树

CSSOM 树和 DOM 树构建完成后会开始生成 Render 树，这一步就是确定页面元素的布局、样式等等诸多方面的东西

7.调用 GPU 绘制，合成图层，将内容显示在屏幕上

在生成 Render 树的过程中，浏览器就开始调用 GPU 绘制，合成图层，将内容显示在屏幕上

-----GPU绘制：1.描点layer 2.渲染painting

这一部分就是渲染原理中讲解到的内容，可以详细的说明下这一过程。并且在下载文件时，也可以说下通过 HTTP/2 协议可以解决队头阻塞的问题

（二）网络基础

1、什么是TCP/IP协议?

不同硬件、操作系统之间的通信，所有的一切都需要一种规则，这种规则称为协议(protocol)

协议中存在各种各样的内容：从电缆的规格到IP地址的选定方式、寻找异地用户的方法、双方建立通信的顺序，以及Web页面显示需要处理的步骤等。

把与互联网相关联的协议集合起来总称为 TCP/IP

也有说法认为，TCP/IP是指TCP和IP这两种协议

还有一种说法认为，TCP/IP是在IP协议的通信过程中，使用到的协议族的统称

2、TCP/IP协议族按层次划分为了哪几层？

TCP/IP协议族按层次分为了4层： 应用层、传输层、网络层、数据链路层

3、TCP/IP协议族各层的作用是什么？

应用层

应用层决定的是向用户提供应用服务时的活动
TCP/IP协议族中预存了各类通用的应用服务如:FPT(文件传输协议)、DNS(域名系统)
HTTP 也是在应用层

传输层

传输层对上层的应用层提供处于网络链接中的两台计算机之间的数据传输
在传输层有两个性质完全不同的协议： TCP(传输控制协议) 、 UDP（用户数据报协议）

网络层

网络层用来处理网络上流通的数据包，数据包是网络传输的最小的单位，该层规定了通过怎样的路径到达对方计算机，并把数据包传送给对方
与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线

数据链路层

用来处理连接网络的硬件部分。硬件上的范畴均在链路层的作用范围之内
包括控制操作系统、硬件的设备驱动、NIC（网络适配器，即网卡），及光纤等物理可见部分（还包括连接器等一切传输媒介）

4、请画出并说明HTTP请求时，TCP/IP通信传输流?

利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信

发送端从应用层往下走，接收端则从链路层往上走

第一步：首先作为发送端的客户端在应用层（HTTP协议）发出一个想看某个Web 页面的HTTP请求

第二步：为了传输方便，在传输层（TCP协议）把从应用层接收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号转发给网络层

第三步：在网络层（IP协议），增加作为通信目的地的MAC地址后转发给链路层。这样一来，发送网络的通信请求就准备齐全了。

第四步：接收端的服务器在链路层接收到数据，按序往上层发送，一直到应用层。当传输到应用层，才能算真正接收到客户端发送过来到HTTP请求。

发送端在层与层之间传输数据时，每经过一层时必定会被打上一个该层所属到首部信息。反之，接收端在层与层传输数据时，每经过一层时会把对应的首部消去。这种把数据信息包装起来的做法称为封装

5、IP协议位于哪一层？

按层次分，IP（Internet Protocol）网际协议位于网络层

IP协议的作用是把各种数据包传送给对方。而要保证确实传送到对方那里，则需要满足各类条件：其中两个重要的条件是IP地址和MAC地址

IP地址指明了节点被分配到的地址

MAC地址是指网卡所属的固定地址

IP地址可以和MAC地址进行配对

IP地址可变换，但是MAC地址基本不会更改

6、TCP协议位于哪一层？

按层次分，TCP位于传输层，提供可靠的字节流服务

7、什么是字节流服务？

字节流服务是指：为了方便传输，将大块数据分割成以报文段为单位的数据包进行管理。

而可靠的传输服务是指，能够把数据准确可靠地传给对方。

TCP协议为了更容易传送大数据才把数据分割，而且TCP协议能够确认数据最终是否送达到对方。

8、TCP头部有哪些重要字段？

Sequence number：保证了 TCP 传输的报文都是有序的，对端可以通过序号顺序的拼接报文
Acknowledgement Number：表示数据接收端期望接收的下一个字节的编号是多少，同时也表示上一个序号的数据已经收到
Window Size：窗口大小，表示还能接收多少字节的数据，用于流量控制
标识符 URG=1：该字段为1表示本数据报的数据部分包含紧急信息，是一个高优先级数据报文，此时紧急指针有效。紧急数据一定位于当前数据包数据部分的最前面，紧急指针标明了紧急数据的尾部
ACK=1：该字段为1表示确认号字段有效。此外，TCP 还规定在连接建立后传送的所有报文段都必须把 ACK 置为1
PSH=1：该字段为一表示接收端应该立即将数据 push 给应用层，而不是等到缓冲区满后再提交
RST=1：该字段为一表示当前 TCP 连接出现严重问题，可能需要重新建立 TCP 连接，也可以用于拒绝非法的报文段和拒绝连接请求
SYN=1：当SYN=1，ACK=0时，表示当前报文段是一个连接请求报文
当SYN=1，ACK=1时，表示当前报文段是一个同意建立连接的应答报文
FIN=1：该字段为一表示此报文段是一个释放连接的请求报文

9、TCP协议的三次握手？

一个重要的性能指标 RTT：表示发送端发送数据到接收到对端数据所需的往返时间

建立连接三次握手

首先假设主动发起请求的一端称为客户端，被动连接的一端称为服务端。不管是客户端还是服务端，TCP 连接建立完后都能发送和接收数据，所以 TCP 是一个全双工的协议。

起初，两端都为 CLOSED 状态。在通信开始前，双方都会创建 TCB。服务器创建完 TCB 后便进入 LISTEN 状态，此时开始等待客户端发送数据。

第一次握手

客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。

第二次握手

服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态。

第三次握手

当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

PS：第三次握手中可以包含数据，通过快速打开（TFO）技术就可以实现这一功能。其实只要涉及到握手的协议，都可以使用类似 TFO 的方式，客户端和服务端存储相同的 cookie，下次握手时发出 cookie 达到减少 RTT 的目的。

10、为什么 TCP 建立连接需要三次握手，明明两次就可以建立起连接？

这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而导致产生错误。

可以想象如下场景：

客户端发送了一个连接请求 A，但是因为网络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送一个连接请求 B。此时请求顺利到达服务端，服务端应答完就建立了请求，然后接收数据后释放了连接。

假设这时候连接请求 A 在两端关闭后终于抵达了服务端，那么此时服务端会认为客户端又需要建立 TCP 连接，从而应答了该请求并进入 ESTABLISHED 状态。但是客户端其实是 CLOSED 的状态，那么就会导致服务端一直等待，造成资源的浪费。

PS：在建立连接中，任意一端掉线，TCP 都会重发 SYN 包，一般会重试五次，在建立连接中可能会遇到 SYN Flood 攻击。遇到这种情况可以选择调低重试次数或者干脆在不能处理的情况下拒绝请求。

11、TCP协议断开链接的四次握手（挥手）

TCP 是全双工的，在断开连接时两端都需要发送 FIN 和 ACK

第一次握手

若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。

第二次握手

B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B 的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。

第三次握手

B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。

PS：通过延迟确认的技术（通常有时间限制，否则对方会误认为需要重传），可以将第二次和第三次握手合并，延迟 ACK 包的发送。

第四次握手

A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃）时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

为什么 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态？

为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。

12、UDP 与 TCP 的区别是什么？

UDP 协议是面向无连接的，也就是说不需要在正式传递数据之前先连接起双方
UDP 协议只是数据报文的搬运工，不保证有序且不丢失的传递到对端，且UDP 协议也没有任何控制流量的算法，总的来说 UDP 相较于 TCP 更加的轻便。
面向无连接首先UDP：不需要和 TCP 一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送，并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。
具体来说就是：
在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作不可靠性首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠。
并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。
再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。即使网络条件不好，也不会对发送速率进行调整。这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。
高效虽然 UDP 协议不是那么的可靠，但是正是因为它不是那么的可靠，所以也就没有 TCP 那么复杂了，需要保证数据不丢失且有序到达。
因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的。

UDP 头部包含了以下几个数据

两个十六位的端口号，分别为源端口（可选字段）和目标端口
整个数据报文的长度整个数据报文的检验和（IPv4 可选字段），该字段用于发现头部信息和数据中的错误
传输方式 UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。
适合使用的场景 UDP 虽然对比 TCP 有很多缺点，但是正是因为这些缺点造就了它高效的特性，在很多实时性要求高的地方都可以看到 UDP 的身影。

直播使用了基于 TCP 的协议会发生什么事情？

TCP 会严格控制传输的正确性，一旦有某一个数据对端没有收到，就会停止下来直到对端收到这个数据。这种问题在网络条件不错的情况下可能并不会发生什么事情，但是在网络情况差的时候就会变成画面卡住，然后再继续播放下一帧的情况。

但是对于直播来说，用户肯定关注的是最新的画面，而不是因为网络条件差而丢失的老旧画面，所以 TCP 在这种情况下无用武之地，只会降低用户体验。

王者荣耀虽然不知道王者荣耀底层具体使用了什么协议，但是对于这类实时性要求很高的游戏来说，UDP 是跑不了的。

为什么这样说呢？首先对于王者荣耀来说，用户体量是相当大的，如果使用 TCP 连接的话，就可能会出现服务器不够用的情况，因为每台服务器可供支撑的 TCP 连接数量是有限制的。

再者，因为 TCP 会严格控制传输的正确性，如果因为用户网络条件不好就造成页面卡顿然后再传输旧的游戏画面是肯定不能接受的，毕竟对于这类实时性要求很高的游戏来说，最新的游戏画面才是最需要的，而不是老旧的画面，否则角色都不知道死多少次了。

13、关于TCP/UDP总结性回答?

UDP 相比 TCP 简单的多，不需要建立连接，不需要验证数据报文，不需要流量控制，只会把想发的数据报文全部发给对端虽然 UDP 并没有 TCP 传输来的准确，但是也能在很多实时性要求高的地方有所作为

14、什么是ARQ协议？

TCP协议通过使用连续ARQ协议和滑动窗口协议来保证数据传输的正确性,从而提供可靠的传输。

ARQ 协议也就是超时重传机制。通过确认和超时机制保证了数据的正确送达，ARQ 协议包含停止等待 ARQ和连续 ARQ两种协议。

-停止等待 ARQ

正常传输过程

只要 A 向 B 发送一段报文，都要停止发送并启动一个定时器，等待对端回应，在定时器时间内接收到对端应答就取消定时器并发送下一段报文。

报文丢失或出错

在报文传输的过程中可能会出现丢包。这时候超过定时器设定的时间就会再次发送丢失的数据直到对端响应，所以需要每次都备份发送的数据。
即使报文正常的传输到对端，也可能出现在传输过程中报文出错的问题。这时候对端会抛弃该报文并等待 A 端重传。

PS：一般定时器设定的时间都会大于一个 RTT 的平均时间。

ACK 超时或丢失

对端传输的应答也可能出现丢失或超时的情况。那么超过定时器时间 A 端照样会重传报文。这时候 B 端收到相同序号的报文会丢弃该报文并重传应答，直到 A 端发送下一个序号的报文。
在超时的情况下也可能出现应答很迟到达，这时 A 端会判断该序号是否已经接收过，如果接收过只需要丢弃应答即可。

这肯定不是一个高效的方式。假设在良好的网络环境中，每次发送数据都需要等待片刻肯定是不能接受的。下面看看相对高效的协议

-连续 ARQ

在连续 ARQ 中，发送端拥有一个发送窗口，可以在没有收到应答的情况下持续发送窗口内的数据，这样相比停止等待 ARQ 协议来说减少了等待时间，提高了效率。

累计确认连续 ARQ 中，接收端会持续不断收到报文。如果和停止等待 ARQ 中接收一个报文就发送一个应答一样，就太浪费资源了。通过累计确认，可以在收到多个报文以后统一回复一个应答报文。报文中的 ACK 标志位可以用来告诉发送端这个序号之前的数据已经全部接收到了，下次请发送这个序号后的数据。

但是累计确认也有一个弊端。在连续接收报文时，可能会遇到接收到序号 5 的报文后，并未接收到序号 6 的报文，然而序号 7 以后的报文已经接收。遇到这种情况时，ACK 只能回复 6，这样就会造成发送端重复发送数据的情况。

15、什么是滑动窗口协议？

TCP协议通过使用连续ARQ协议和滑动窗口协议，来保证数据传输的正确性，从而提供可靠的传输。

在 TCP 中，两端其实都维护着窗口：分别为发送端窗口和接收端窗口。

发送端窗口包含已发送但未收到应答的数据和可以发送但是未发送的数据。滑动窗口是一个很重要的概念，它帮助 TCP 实现了流量控制的功能。接收方通过报文告知发送方还可以发送多少数据，从而保证接收方能够来得及接收数据，防止出现接收方带宽已满，但是发送方还一直发送数据的情况。

Zero 窗口在发送报文的过程中，可能会遇到对端出现零窗口的情况。在该情况下，发送端会停止发送数据，并启动 persistent timer 。该定时器会定时发送请求给对端，让对端告知窗口大小。在重试次数超过一定次数后，可能会中断 TCP 链接。

16、拥塞处理

拥塞处理和流量控制不同，后者是作用于接收方，保证接收方来得及接受数据。而前者是作用于网络，防止过多的数据拥塞网络，避免出现网络负载过大的情况。

拥塞处理包括了四个算法，分别为：慢开始，拥塞避免，快速重传，快速恢复。

慢开始算法: 慢开始算法，顾名思义，就是在传输开始时将发送窗口慢慢指数级扩大，从而避免一开始就传输大量数据导致网络拥塞。想必大家都下载过资源，每当我们开始下载的时候都会发现下载速度是慢慢提升的，而不是一蹴而就直接拉满带宽。

慢开始算法步骤: 连接初始设置拥塞窗口（Congestion Window）为 1 MSS（一个分段的最大数据量）每过一个 RTT 就将窗口大小乘二指数级增长肯定不能没有限制的，所以有一个阈值限制，当窗口大小大于阈值时就会启动拥塞避免算法。拥塞避免算法

拥塞避免算法相比简单点，每过一个 RTT 窗口大小只加一，这样能够避免指数级增长导致网络拥塞，慢慢将大小调整到最佳值。

在传输过程中可能定时器超时的情况，这时候 TCP 会认为网络拥塞了，会马上进行以下步骤：将阈值设为当前拥塞窗口的一半将拥塞窗口设为 1 MSS 启动拥塞避免算法快速重传

快速重传一般和快恢复一起出现。一旦接收端收到的报文出现失序的情况，接收端只会回复最后一个顺序正确的报文序号。如果发送端收到三个重复的 ACK，无需等待定时器超时而是直接启动快速重传算法。具体算法分为两种：

TCP Taho 实现: 将阈值设为当前拥塞窗口的一半将拥塞窗口设为 1 MSS 重新开始慢开始算法

TCP Reno 实现: 拥塞窗口减半将阈值设为当前拥塞窗口进入快恢复阶段（重发对端需要的包，一旦收到一个新的 ACK 答复就退出该阶段），这种方式在丢失多个包的情况下就不那么好了使用拥塞避免算法 TCP New Ren 改进后的快恢复

TCP New Reno算法改进了之前TCP Reno算法的缺陷。在之前，快恢复中只要收到一个新的 ACK 包，就会退出快恢复。

在TCP New Reno中，TCP 发送方先记下三个重复 ACK 的分段的最大序号。

假如我有一个分段数据是 1 ~ 10 这十个序号的报文，其中丢失了序号为 3 和 7 的报文，那么该分段的最大序号就是 10。发送端只会收到 ACK 序号为 3 的应答。这时候重发序号为 3 的报文，接收方顺利接收的话就会发送 ACK 序号为 7 的应答。这时候 TCP 知道对端是有多个包未收到，会继续发送序号为 7 的报文，接收方顺利接收并会发送 ACK 序号为 11 的应答，这时发送端认为这个分段接收端已经顺利接收，接下来会退出快恢复阶段。

17、什么是DNS服务？

DNS（Domain Name System）服务是和HTTP协议一样位于应用层的协议。它提供域名到IP地址之间的解析服务。 DNS协议提供通过域名查找IP地址或逆向从IP地址反查域名的服务

18、URL和URI分别是什么？

URI是一种资源定位符 URL是一种特殊的URI

一个绝对URI的格式：

http://user:pass@www.example.jp:80/dir/index.html?uid=1#ch1

        http：协议方案名

        user:pass：登陆信息（认证）

        www.example.jp：服务器地址

        80：服务器端口号

        dir/index.html：带层次的文件路径

        uid=1：查询字符串

        ch1：片段标识符

19、什么是RFC？

用来制定 HTTP 协议技术标准的文档被称为RFC(Request for Comments，征求修正意见书) ，通常应用程序会遵照由RFC确定的标准实现。

RFC是互联网的设计文档，要是不按照RFC标准执行，就有可能导致无法通信的状况。

三、HTTP

（一）HTTP协议

1、HTTP请求报文由哪几部分组成？

请求报文是由请求方法、请求URI、协议版本、一些可选的请求首部字段和内容实体构成。

示例：(network截取的一个请求)

General：

Request URL: https://www.baidu.com/home/xman/data/tipspluslist?indextype=manht&_req_seqid=0x8466e3ac0001093f&asyn=1&t=1552961901647&sid=28628_1427_21083_28720_28558_28607_28585_26350_28603_28625_28703

Request Method: GET

Status Code: 200 OK

Remote Address: 112.34.112.40:443

Referrer Policy: unsafe-url

Response headers

Cache-Control: private

Connection: keep-alive

Content-Encoding: gzip

Content-Length: 78

Content-Type: text/html;charset=utf-8

Date: Tue, 19 Mar 2019 02:18:22 GMT

Expires: Tue, 19 Mar 2019 02:18:22 GMT

Server: BWS/1.0

Tracecode: 11023798470767062538031910

Vary: Accept-Encoding

Request headers

Accept: text/plain, */*; q=0.01

Accept-Encoding: gzip, deflate, br

Accept-Language: zh-CN,zh;q=0.9,en;q=0.8

Cache-Control: no-cache

Connection: keep-alive

Cookie: BIDUPSID=18640EC56A0710DC537203C0A89DDE20

Host: www.baidu.com

Pragma: no-cache

Referer: https://www.baidu.com/

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

X-Requested-With: XMLHttpRequest

Query String Parameters

indextype: manht

_req_seqid: 0x8466e3ac0001093f

asyn: 1

t: 1552961901647

sid: 28628_1427_21083_28720_28558_28607_28585_26350_28603_28625_28703

2、HTTP协议是无状态还是有状态？

HTTP是一种不保存状态，即无状态（ stateless ）协议
HTTP协议自身不对请求和响应之间的通信状态进行保存即在HTTP这个级别，协议对于发送过的请求或响应都不做持久化处理。
使用HTTP协议，每当有新的请求发送时，就会有对应的新响应产生。协议本身并不保留之前一切的请求或者响应报文的信息。
这是为了更快地处理大量事务，确保协议的可伸缩性，而特意把HTTP协议设计成如此简单的。
随着 WEB 的不断发展，因无状态而导致业务处理变得棘手的情况增多了。为了实现期望的保持状态功能，于是引入了 Cookie 技术。有了Cookie 再用HTTP协议通信，就可以管理状态了。

3、HTTP方法有哪些？ (传输数据的方式)

方法	说明	支持的HTTP协议版本
GET	获取资源	1.0 1.1
POST	传输实体主体	1.0 1.1
PUT	传输文件	1.0 1.1
HEAD	获得报文首部	1.0 1.1
DELETE	删除文件	1.0 1.1
OPTIONS	询问支持的方法	1.1
TRACE	追踪路径	1.1
CONNECT	要求用隧道协议连接代理	1.1
LINK	建立和资源之间的联系	1.0
UNLINK	断开连接关系	1.0

4、GET和POST方法的区别？

1.GET请求只能进行url编码，而POST支持多种编码方式。

2.GET请求在URL中传送的参数是有长度限制的，而POST么有。但是GET这个长度的限制不是HTTP协议限制的，是各个浏览器限制的。

3.因为GET方法是通过URL传递参数对，所以如果参数里面有一些特殊字符，比如 + 号，浏览器会对 + 号进行编码，可能会造成后台报错。而POST就不会有这种现象。如果使用GET时，参数中有特殊字符，可以先对参数编码，然后进行传输。

4.同源时候，GET请求里面会带 Origin 字段，而POST不会。这个可能造成安全检查对错误，如果有 nginx服务器，可再nginx服务器上设置。

5.GET方法一般设置 Content-type为application/x-www-form-urlencoded，POST方法一般设置Content-type为text/plain;charset=utf-8，对于POST请求，服务器后台以流对方式接收。这都是实际应用中得出来的结论，如果这样回答，肯定会对你的面试加分,当然,按照面试题大全中的方式回答也是可以的,建议这个用作面试,大全中的答案用作笔试！

6.get不安全，快 post安全，慢

5、HTTP是如何利用Cookie进行状态管理的？

Cookie技术通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。 Cookie会根据从服务器端发送的响应报文内的一个叫做 Set-Cookies 的首部字段信息，通知客户端保存 Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入 Cookie 值后发送出去。服务器端发现客户端发送过来的 Cookie后，会去检查究竟是从哪一个客户端发来的连接请求，然后对比服务器上的记录，最后得到之前的状态信息。

即：

第一步：由客户端发出一个 HTTP 请求，服务器端在响应中添加 Cookie后返回。

第二步：客户端下一次再向服务器端发送 HTTP 请求时，会在请求中添加 Cookie后发送。服务器端会检测这个 Cookie 进行认证

PS:可以通过缓存解决http无状态问题

6、在ajax请求中如何使用Cookie？

需要在 ajax 请求中设置 withCredentials = true参数，即：

let xhr = new XMLHttpRequest();

xhr.withCredentials = true; //携带本地缓存进行跨域

axios的设置：axios.default.withCredentials = true;

7、在ajax请求中使用Cookie时，如何解决跨越问题？

如果跨域问题是通过在服务器端设置response.setHeader("Access-Control-Allow-Origin", ""); 解决的，当设置 withCredentials = true参数后会报错

需要这样解决： response.setHeader("Access-Control-Allow-Origin", req.headers.origin);

（二）HTTP报文内的HTTP信息

1、HTTP报文有哪几种，HTTP报文包含哪写部分？

用于 HTTP 协议交互的信息被称为 HTTP 报文。

请求端（客户端）的 HTTP 报文 request 叫做 请求报文

响应端（服务器端）response 的叫做响应报文

HTTP报文大致可以分为 报文首部 和 报文主体 两块

两者由最初出现的空行（CR+LF）来划分，通常，并不一定要有报文主体

具体的请求信息，可以通过谷歌浏览器控制台里面的 network 进行分析

（三）HTTP状态码

1、常见的状态码有哪些？（必背）

状态码表示了响应的一个状态，可以让我们清晰的了解到这一次请求是成功还是失败，如果失败的话，是什么原因导致的，当然状态码也是用于传达语义的。如果胡乱使用状态码，那么它存在的意义就没有了。

2XX 成功

200 OK，表示从客户端发来的请求在服务器端被正确处理

204 No content，表示请求成功，但响应报文不含实体的主体部分

205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容

206 Partial Content，进行范围请求

3XX 重定向

301 moved permanently，永久性重定向，表示资源已被分配了新的 URL

302 found，临时性重定向，表示资源临时被分配了新的 URL

303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源

304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况

307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

4XX 客户端错误

400 bad request，请求报文存在语法错误

401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息

403 forbidden，表示对请求资源的访问被服务器拒绝

404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

500 internal sever error，表示服务器端在执行请求时发生了错误

501 Not Implemented，表示服务器不支持当前请求所需要的某个功能

503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

（四）与HTTP协作的 Web 服务器

通信数据转发程序

HTTP通信时，除客户端和服务器端外，还有一些用于通信数据转发的应用程序，例如代理、网关和隧道。他们可以配合服务器工作。这些应用程序和服务器可以将请求转发给通信线路上的下一站服务器，并且能接收从那台服务器发送的响应并转发给客户端。

代理

代理服务器的基本行为就是接收客户端发送的请求后转发给其他服务器。代理不改变请求URI，会直接发送给前方持有资源的目标服务器。

使用代理服务器的理由有：利用缓存技术减少网络带宽的流量组织内部针对特定网络的访问控制

获取访问日志代理有多种方法，按两种基准分类，一种是是否使用缓存，另一种是是否会修改报文。

缓存代理

代理转发响应时，缓存代理会预先将资源的副本（缓存）保存在代理服务器上。当代理再次接收到相同资源的请求时，就可以不从源服务器那里获取资源，而是将之前缓存的资源作为响应返回。

透明代理

转发请求或响应时，不对报文做任何加工的代理类型被称为透明代理。反之，对报文内容进行加工的代理被称为非透明代理

网关

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非 HTTP 协议服务。利用网关能提供通信的安全性，因为可以在客户端与网关之间的通信线路上加密以确保连接的安全。比如，网关可以连接数据库，使用SQL语句查询数据。另外，在 Web 购物网站上进行信用卡结算时，网关可以和信用卡结算系统联动。

隧道

隧道可按照要求建立起一条与其他服务器的通信线路，届时使用 SSL 等加密手段进行通信。隧道的目的是确保客户端能与服务器进行安全的通信。隧道本身不会去解析HTTP请求。也就是说，请求保持原样中转给之后的服务器。隧道会在通信双方断开连接时结束。

（五）HTTP首部

1、什么是HTTP首部字段

HTTP 协议的请求和响应报文中必定包含 HTTP 首部。
首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。
报文首部由几个字段构成。在报文众多的字段当中，HTTP首部字段包含的信息最为丰富。
使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。
HTTP 首部字段是由首部字段名称和字段值构成，中间用冒号 ":" 分隔。

2、HTTP首部字段有哪几种类型？

HTTP 首部字段根据实际用途被分为以下 4 种类型：

通用首部字段（General Header Fields）

请求报文和响应报文两方都会使用的首部

请求首部字段（Request Header Fields）

从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息

响应首部字段（Response Header Fields）

从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息

实体首部字段（Entity Header Fields）

针对请求报文和响应报文的实体部分使用的首部：补充了资源内容更新时间等与实体有关的信息

3、通用首部字段有哪些？

4、请求首部字段有哪些？

5、响应首部字段有哪些？

6、实体首部字段有哪些？

7、非HTTP/1.1 首部字段

在 HTTP 协议通信交互中使用到的首部字段，不限于 RFC2616 中定义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disponsition 等在其他 RFC 中定义的首部字段，它们的使用频率也很高。这些非正式的首部字段统一归纳在 RFC4229 HTTP Header Field Registrations中。

8、为Cookie服务的首部字段有哪些？

9、其他首部字段

HTTP首部字段是可以自行扩展的。所以在 Web 服务器和浏览器的应用上，会出现各种非标准的首部字段。

要进行 P3P 的设定，需按以下操作步骤进行：

-创建 P3P 隐私

-创建 P3P 隐私对照文件后，保持命名在 /w3c/p3p.xml

-从 P3P 隐私中新建 Compact policies后，输出到 HTTP 响应中

四、HTTPS

1、HTTP的缺点有哪些？

通信使用明文（不加密），内容可能会被窃听
不验证通信方的身份，可能遭遇伪装
无法证明报文的完整性，有可能已遭篡改
通信使用明文可能会被窃听
由于HTTP本身不具备加密的功能，所以也无法做到对通信（使用HTTP协议通信的请求和响应内容）进行加密。即 HTTP报文使用明文（未经过加密的报文）方式发送。
如果要问为什么通信时不加密是一个缺点，这是因为，按TCP/IP协议族的工作机制，通信内容在所有的通信线路上都有可能遭到窥视。

加密处理防止被窃听

在目前大家正在研究的如何防止窃听保护信息的几种对称中，最为普及的就是加密技术。

加密的对象：

通信的加密：

HTTP可以通过和 SSL （Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全传输层协议）的组合使用，加密HTTP的通信内容。
用 SSL 建立安全通信线路之后，就可以在这条线路傻姑娘进行HTTP通信了。与SSL组合使用的HTTP被称为 HTTPS（HTTP Secure，超文本传输安全协议）或HTTP over SSL。

内容的加密：

还有一种将参与通信的内容本身进行加密的方法。由于HTTP协议中段还有加密机制，那么就对HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。

任何人都可以发起请求

HTTP协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，故不确认通信方，会存在以下各种隐患：

无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 web 服务器。
无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限。
无法判断请求是来自何方、出自谁手。即使是无意义的请求也会照单全收。
无法阻止海量请求下的 Dos 攻击（Denial of Service，拒绝服务攻击）查明对手的证书

虽然使用HTTP协议无法确定通信方，但如果使用SSL则可以。

SSL不仅提供加密处理，而且还使用了一种被称为证书的手段，可用于确定方。
证书是由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
另外，伪造证书从技术角度来说是异常困难的一件事情。所以只要能够确认通信方持有的证书，即可判断通信方的真实意图。

无法证明报文完整性，可能已遭到篡改

由于HTTP协议无法证明通信的报文完整性，因此，在请求送出之后直到对方接收之前的这段时间内，即使请求或响应的内容遭到篡改，也没有办法获悉。
像这样，请求和响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击。

2、什么是HTTPS?

HTTPS并非是应用层的一种新协议，只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS （Transport Layer Security）协议代替而已。
通常，HTTP直接和 TCP 通信。当使用 SSL 时，则演变成先和 SSL 通信，再有SSL 和 TCP 通信了。简言之，所谓的HTTPS，其实就是身披 SSL 协议这层外壳的 HTTP。
在采用SSL后，HTTP就拥有了 HTTPS 的加密、证书和完整性保护这些功能。
SSL 是独立于HTTP的协议，所以不光是HTTP协议，其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是当今世界应用最为广泛的网络安全技术。

3、HTTPS是如何进行加密的？

HTTPS采用共享密钥加密和公开密钥加密的混合加密机制

共享密钥加密

加密和解密同用一个密钥的方式称为共享密钥加密，也被称为 对称密钥加密

以共享密钥方式加密时必须将密钥也发给对方。可究竟怎样才能安全地转交？在互联网上转发密钥时，如果通信被监听那么密钥就可会落入攻击者之后，同时也就失去了加密的意义，另外还得设法安全地保管接收到的密钥。

公开密钥加密

公开密钥加密的方式很好的解决了共享密钥加密的问题。

公开密钥加密使用一对非对称的密钥。

一把为私钥（私有密钥），一把为公钥（公开密钥），其中私有密钥不能让任何人得知，而公开密钥则可以随意公布。发送密文的那一端，使用对方的公开密钥进行加密处理，对方接收到被加密的信息后，使用私钥对此密文进行解密。

利用这种方式，不需要发送用来解密的私钥。从而解决了共享密钥加密存在的问题。

使用混合加密机制的HTTPS

HTTPS采用共享密钥加密和公开密钥加密的混合加密机制。

如果为了实现密钥的安全，那么可以考虑仅使用公开密钥加密技术。（公开密钥加密比共享密钥加密处理速度要慢）所以，应当充分利用两者的优势，将多种方法组合起来进行通信：在交换密钥环节，使用公开密钥加密技术（比如说，从客户端到服务器，那么在这样一个安全的通信中，客户端可以将共享密钥加密中的密钥用公开密钥加密中的公钥进行加密，发送给服务器，然后服务器使用公开密钥加密技术的私钥进行解密，就拿到了共享密钥加密技术中的私钥），之后建立通信报文交换的阶段则可使用共享密钥加密技术。

4、HTTPS的通信步骤是什么？

客户端发送报文进行SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件列表（加密算法及密钥长度等）。
服务器应答，并在应答报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接受到的客户端加密组件内筛选出来的。
服务器发送报文，报文中包含公开密钥证书。
服务器发送报文通知客户端，最初阶段SSL握手协商部分结束。
SSL第一次握手结束之后，客户端发送一个报文作为回应。报文中包含通信加密中使用的一种被称Pre-master secret的随机密码串。该密码串已经使用服务器的公钥加密。
客户端发送报文，并提示服务器，此后的报文通信会采用Pre-master secret密钥加密。
客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够完成成功，要以服务器是否能够正确解密该报文作为判定标准。
服务器同样发送Change Cipher Spec报文。
服务器同样发送Finished报文。
服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。
应用层协议通信，即发送HTTP响应。
最后由客户端断开链接。断开链接时，发送close_nofify报文。

5、相比HTTP，HTTPS有哪些缺点？

与纯文本通信相比，加密通信会消耗更多的CPU和内存资源。
如果每次通信都加密，会消耗相当多的资源，平摊到一台计算机上时，能够处理的请求数量必定也会随之减少。
因此，如果是非敏感信息则使用HTTP通信，只有在包含个人信心等敏感数据时，才利用HTTPS加密通信。
特别是每当那些访问量比较多的Web网站进行加密处理时，它们所承担着的负载不容小觑。
在进行加密处理时，并非对所有内容都进行加密处理，而是仅在那些需要信息隐藏时才会加密，以节约资源。

五、基于HTTP的功能追加协议

1、SPDY协议

Google在2010年发布了SPDY（取自SPeeDY，发音同 speedy），其开发目标旨在解决HTTP的性能瓶颈，缩短Web页面的加载时间

背景

在 Facebook 和 Twitter 等 SNS 网站上，几乎能够实时观察到海量用户公开发布的内容，这也是一种乐趣。当几百、几千万的用户发布内容时，Web网站为了保持这些新增的内容，在很短的时候内就会发生大量的内容更新。

为了尽可能实时地显示这些更新内容，服务器上一有内容更新，就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的，但HTTP却无法妥善地处理好这项任务。使用HTTP协议探知服务器上是否有内容更新，就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新，那么就会产生徒劳的通信。

HTTP瓶颈

一条连接上只可发送一个请求。

请求只能从客户端开始。客户端不可以接收除响应以外的指令。请求/响应首部未经压缩就发送。首部信息越多延迟越大。发送冗长的首部。每次互相发送相同的首部造成的浪费较多。可任意选择数据压缩格式。非强制性压缩发送。

SPDY 的设计与功能

SPDY没有完全改写HTTP协议，而是在 TCP/IP 的应用层与传输层之间通过新加会话层的形式运作。同时，考虑到安全性问题，SPDY 在规定通信中使用 SSL。

SPDY 以会话层的形式加入，控制对数据的流动，但还是采用HTTP建立通信连接。因此，可照常使用HTTP的GET和POST等方法、Cookie以及HTTP报文等。

使用SPDY后，HTTP协议额外获得的功能:

多路复用：通过单一的TCP连接，可以无限制地处理多个HTTP请求。所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。
赋予请求优先级：SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
压缩HTTP首部：压缩HTTP请求和响应的首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
推送功能：支持服务器主动向客户端推送数据的功能。这样，服务器可直接发送数据，而不必等待客户端的请求。
服务器提示功能：服务器可以主动提示客户端请求所需要的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。

SPDY消除 Web 瓶颈了吗？

使用SPDY后，web 的内容端不必做什么特别改动，而 Web 浏览器及 Web 服务器都要为对应 SPDY 做出一定程度的改动。
因为 SPDY 基本上只有将单个域名（IP地址）的通信多路复用，所以当一个 Web网站上使用多个域名下的资源，改善效果就会受到限制。

2、webSocket是什么？

WebSocket 协议在2008年诞生，2011年成为国际标准。所有浏览器都已经支持了。 WebSocket同样是HTML 5规范的组成部分之一，现标准版本为 RFC 6455。 WebSocket 相较于上述几种连接方式，实现原理较为复杂，用一句话概括就是：客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。由于 WebSocket 本身是基于TCP协议的，所以在服务器端我们可以采用构建 TCP Socket 服务器的方式来构建 WebSocket 服务器。

WebSocket 是一种全新的协议。它将 TCP 的Socket（套接字）应用在了web page上，从而使通信双方建立起一个保持在活动状态连接通道，并且属于全双工(双方同时进行双向通信)

其实是这样的，WebSocket 协议是借用 HTTP协议的 101 switch protocol 来达到协议转换的，从HTTP协议切换成WebSocket通信协议。

3、webSocket有什么特点？

服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种
建立在 TCP 协议之上，服务器端的实现比较容易
与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443 ，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器
数据格式比较轻量，性能开销小，通信高效
可以发送文本，也可以发送二进制数据
没有同源限制，客户端可以与任意服务器通信
协议标识符是ws（如果加密，则为wss），服务器网址就是 URL