前端开发知识点整理（1）—网络—秋招/春招/实习/工作

网络

目录

网络

1 HTTP和HTTPS

1.1 HTTP和HTTPS

1.2说一下HTTP2.0

1.3 HTTP1.0/1.1/2.0/3区别

1.4 HTTP3.0【极少问到，但如果了解，是加分项】

1.5 HTTP请求和响应报文的组成部分（各有3个）

1.6 常见的HTTP的头部

1.7 常用的HTTP请求头（客户端发的）

1.8 常用的HTTP响应头（服务器发的）

1.9 状态码

1.10 HTTP请求方式--9种

1.11 GET和POST的区别

1.12 PUT和POST的区别

1.13 Etag是什么？

1.14 HTTP是有状态还是无状态的请求？

1.15 HTTP协议如何实现像websocket那样实现双向通信?

1.16 抓包

2 TCP UDP HTTP协议

2.1 TCP三次握手和四次挥手【重要】

2.2 TCP为什么不能用两次握手进行连接？【重要】

2.3 TCP为什么连接的时候是三次握手，关闭的时候却是四次握手？【重要】

2.4 TCP挥手时为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

2.5 TCP如果已经建立了连接，但是客户端突然出现故障了怎么办？

2.6 TCP和UDP的区别【重要】

2.7 TCP 协议如何保证可靠传输【重要】

2.8 TCP和HTTP的区别【重要】

2.9 HTTP，TCP，IP怎么配合工作的？

3 TCP/IP模型，OSI模型

3.1 TCP/IP5层模型

3.2 OSI七层模型和TCP/IP5层模型【重要】

3.3 OSI中ARP是在哪一层？

4 其他

4.1 在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？【重要】

4.2 长连接/短连接

4.3 网关是干什么的？

---

---

• 1 HTTP和HTTPS

  • 1.1 HTTP和HTTPS

    • (1)HTTP和HTTPS的基本概念
      • HTTP: 超文本传输协议，是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
      • HTTPS: 是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。———可进行加密传输和身份认证—
        • HTTPS的SSL加密是在传输层实现的。
        • HTTPS采用混合加密机制，将非对称和对称加密两种加密算法组合使用，充分利用各自的优点，博采众长。在交换公钥阶段采用非对称加密，在传输报文阶段使用对称加密。
    • (2)HTTPS协议的工作原理——SSL建立的过程
      • 如图

 

• • • • 1、客户端-->服务器：SSL的指定版本、加密组件（Cipher Suite）列表
        • 客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。注意：客户端还会附加一个随机数，这里记为A。
      • 2、服务器-->客户端：SSL版本以及选中的加密组件
        • 服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。注意：这里服务器同样会附加一个随机数，发给客户端，这里记为B。
      • 3、服务器-->客户端：发公钥
        • 之后服务器发送Certificate报文。报文中包含公开密钥证书。（具体的数字签名请看证书一节）
      • 4、服务器-->客户端：Server Hello Done
        • 最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
      • 5、客户端：验证服务器证书
        • SSL第一次握手结束后，客户端会对服务器发过来的证书进行验证，如果验证成功，解密取出证书中的公钥。（具体查看证书一节）
      • 6、客户端-->服务器：公钥加密后面用到的对称密钥
        • 接着，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串（后面用到的对称密钥）。该报文使用从证书中解密获得的公钥进行加密（其实就是服务器的公钥）。
      • 7、客户端-->服务器：Change Cipher Spec报文，可以改为对称加密传输
        • 客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
      • 8、客户端-->服务器：Finished报文，校验值。
        • 客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值（也就是HASH值），用来供服务器校验。
      • 9、服务器-->客户端：私钥解密取出对称密钥，Change Cipher Spec报文
        • 服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret（对称密钥）取出来。接着，服务器同样发送Change Cipher Spec报文。
      • 10、服务器-->客户端：Finished报文，校验值。
        • 服务器同样发送Finished报文，用来供客户端校验。
      • 11、服务器<-->客户端：对称加密
        • 服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。应用层协议通信，即发送HTTP响应。
      • 12、最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。
    • (3)HTTP和HTTPS的区别
      • HTTPS协议需要CA证书，费用较高。
      • HTTP是超文本传输协议，信息是明文传输，HTTPS则是具有安全性的SSL加密传输协议。
      • 使用不同的链接方式，端口也不同，一般而言，HTTP协议的端口为80，HTTPS的端口为443
      • HTTP的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。
    • (4)HTTPS的缺点
      • 1）消耗资源
        • 通信两端都需要进行加密和解密，会消耗大量的CPU、内存等资源，增加了服务器的负载
      • 2）访问速度慢
        • 加密运算和多次握手降低了访问速度
      • 3）页面调试难度加大
        • 在开发阶段，加大了页面调试难度。由于信息都被加密了，所以用代理工具的话，需要先解密然后才能看到真实信息。
      • 4）SSL证书需要花钱购买，功能越强大的证书费用越高。
      • 5）SSL证书需要绑定IP，不能再同一个ip上绑定多个域名，ipv4资源支持不了这种消耗。

 

• • 1.2说一下HTTP2.0

    • HTTP2.0是基于1999年发布的HTTP1.0之后的首次更新。
    • 特点：
      • （1）二进制格式：HTTP2.0中所有加强性能的核心是二进制传输。
        • 在应用层（HTTP2.0）和传输层（TCP or UDP）之间增加一个二进制分帧层。
        • 在二进制分帧层上，HTTP2.0会将所有传输的信息分为更小的消息和帧，并采用二进制格式编码，其中HTTP1.x的首部信息会被封装到Headers帧，而Request Body则封装到Data帧。
        • 在HTTP1.x中，我们是通过文本的方式传输数据。基于文本的方式传输数据存在很多缺陷，文本的表现形式有多样性，因此要做到健壮性考虑的场景必然有很多，
      • （2）允许多路复用：
        • 多路复用允许同时通过单一的HTTP/2连接发送多重请求-响应信息。改善了：在HTTP1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制（连接数量），超过限制会被阻塞。
        • 这个功能相当于是长连接的增强，每个request请求可以随机的混杂在一起，接收方可以根据request的id将request再归属到各自不同的服务端请求里面，
      • （3）服务器端推送
      • （4）Header首部压缩
      • （5）提升访问速度
        • 相比HTTP1.0，请求资源所需时间更少，访问速度更快
      • （6）更安全
    • HTTP1.x的主要缺点 / 推进HTTP2的原因
      • （1）队列阻塞
        • HTTP/1.0一次只允许在一个TCP连接上发起一个请求，HTTP/1.1使用的流水线技术也只能部分处理请求并发，仍然会存在队列头阻塞问题，因此客户端在需要发起多次请求时，通常会采用建立多连接来减少延迟。
      • （2）单向请求，只能由客户端发起。
      • （3）请求报文与响应报文首部信息冗余量大。
      • （4）数据未压缩，导致数据的传输量大。

 

• • 1.3 HTTP1.0/1.1/2.0/3区别

    • HTTP1.0：
      • （1）无法长连接。
        • 每次请求和响应都需要建立一个单独的TCP连接，每次连接只是传输一个文档和图像，上一次和下一次请求完全分离。服务器不跟踪每个客户也不记录过去的请求。
      • （2）不支持只发送header信息(不能不带任何body信息)，
      • （3）HTTP1.0是没有host域的，HTTP1.1才支持这个参数。
        • 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
    • HTTP 1.1
      • （1）默认使用长连接，可有效减少TCP的三次握手开销。
        • 增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。
      • （2）支持只发送header信息(可以不带任何body信息)。
      • （3） HTTP1.1在Request消息头里头多了一个Host域
        • 在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。
    • HTTP2.0
      • （1）使用多路复用技术(Multiplexing)，多路复用允许同时通过单一的 HTTP/2 连接发起多重的请求-响应消息。
      • （2）HTTP/2新增首部压缩（Header Compression）
      • （3）HTTP/2新增服务端推送（Header Compression）
    • HTTP3【极少问到，但如果了解，是加分项】
      • 采用基于UDP的QUIC（Quick UDP Internet Connection）协议

 

• • 1.4 HTTP3.0【极少问到，但如果了解，是加分项】

    • HTTP/3采用了QUIC协议。
    • QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。
    • QUIC融合了包括TCP，TLS，HTTP/2等协议的特性，但基于UDP传输。
    • 为什么要推进HTTP3/QUIC协议
      • HTTP/2仍然存在一些缺陷，这些缺陷并不是来自于HTTP/2协议本身，而是来源于底层的TCP协议，我们知道TCP链接是可靠的连接，如果出现了丢包，那么整个连接都要等待重传，HTTP/1.1可以同时使用6个TCP连接，一个阻塞另外五个还能工作，但HTTP/2只有一个TCP连接，阻塞的问题便被放大了。
      • QUIC的一个主要目标就是减少连接延迟，当客户端第一次连接服务器时，QUIC只需要1RTT（Round-Trip Time）的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息，在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。
      • QUIC同时复用了HTTP/2协议的多路复用功能（Multiplexing），但由于QUIC基于UDP所以避免了HTTP/2的线头阻塞（Head-of-Line Blocking）问题。因为QUIC基于UDP，运行在用户域而不是系统内核，使得QUIC协议可以快速的更新和部署，从而很好地解决了TCP协议部署及更新的困难  。
    • QUIC协议的机制：从TCP切换到UDP【了解】
      • 机制一：自定义连接机制
        • 一条tcp连接是由四元组标识的，分别是源ip、源端口、目的端口，一旦一个元素发生变化时，就会断开重连，重新连接。再次进行三次握手，导致一定的延时
        • 在TCP是没有办法的，但是基于UDP，就可以在QUIC自己的逻辑里面维护连接的机制，不再以四元组标识，而是以一个64位的随机数作为ID来标识，而且UDP是无连接的，所以当ip或者端口变化的时候，只要ID不变，就不需要重新建立连接
      • 机制二：自定义重传机制
        • tcp为了保证可靠性，通过使用序号和应答机制，来解决顺序问题和丢包问题任何一个序号的包发过去，都要在一定的时间内得到应答，否则一旦超时，就会重发这个序号的包，通过自适应重传算法（通过采样往返时间RTT不断调整）
        • 但是，在TCP里面超时的采样存在不准确的问题。例如发送一个包，序号100，发现没有返回，于是在发送一个100，过一阵返回ACK101.客户端收到了，但是往返的时间是多少，没法计算。是ACK到达的时候减去第一还是第二。
        • QUIC也有个序列号，是递增的，任何宇哥序列号的包只发送一次，下次就要加1，那样就计算可以准确了
        • 但是有一个问题，就是怎么知道包100和包101发送的是同样的内容呢？QUIC定义了一个offset概念。QUIC既然是面向连接的，也就像TCP一样，是一个数据流，发送的数据在这个数据流里面有个偏移量offset，可以通过offset查看数据发送到了那里，这样只有这个offset的包没有来，就要重发。如果来了，按照offset拼接，还是能够拼成一个流。
      • 机制三： 无阻塞的多路复用
        • 有了自定义的连接和重传机制，就可以解决上面HTTP2.0的多路复用问题
        • 同HTTP2.0一样，同一条 QUIC连接上可以创建多个stream，来发送多个HTTP请求，但是，QUIC是基于UDP的，一个连接上的多个stream之间没有依赖。这样，假如stream2丢了一个UDP包，后面跟着stream3的一个UDP包，虽然stream2的那个包需要重新传，但是stream3的包无需等待，就可以发给用户。
      • 机制四：自定义流量控制
        • TCP的流量控制是通过滑动窗口协议。QUIC的流量控制也是通过window_update，来告诉对端它可以接受的字节数。但是QUIC的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在一个连接中的每个steam控制窗口。
        • 在TCP协议中，接收端的窗口的起始点是下一个要接收并且ACK的包，即便后来的包都到了，放在缓存里面，窗口也不能右移，因为TCP的ACK机制是基于序列号的累计应答，一旦ACK了一个序列号，就说明前面的都到了，所以是要前面的没到，后面的到了也不能ACK,就会导致后面的到了，也有可能超时重传，浪费带宽
        • QUIC的ACK是基于offset的，每个offset的包来了，进了缓存，就可以应答，应答后就不会重发，中间的空档会等待到来或者重发，而窗口的起始位置为当前收到的最大offset，从这个offset到当前的stream所能容纳的最大缓存，是真正的窗口的大小，显然，那样更加准确。

 

• • 1.5 HTTP请求和响应报文的组成部分（各有3个）

    • 请求报文：请求方法URI协议/版本 + 请求头(Request Header) + 请求正文
      • 

 

• • • 响应报文：状态行 + 响应头 + 响应正文
      • 

 

 

• • 1.6 常见的HTTP的头部

    • 可以将http首部分为通用首部，请求首部，响应首部，实体首部
      • （1）通用首部表示一些通用信息，比如date表示报文创建时间，
      • （2）请求首部就是请求报文中独有的，如cookie，和缓存相关的如if-Modified-Since
      • （3）响应首部就是响应报文中独有的，如set-cookie，和重定向相关的location，
      • （4）实体首部用来描述实体部分，如allow用来描述可执行的请求方法，content-type描述主题类型，content-Encoding描述主体的编码方式

 

• • 1.7 常用的HTTP请求头（客户端发的）

    • 协议头 | 说明
    • Accept 可接受的响应内容类型（Content-Types）。
      • eg: Accept: text/plain
    • Accept-Charset 可接受的字符集
    • Accept-Encoding 可接受的响应内容的编码方式。
    • Accept-Language 可接受的响应内容语言列表。
    • Accept-Datetime 可接受的按照时间来表示的响应内容版本
    • Authorization 用于表示HTTP协议中需要认证资源的认证信息
    • Cache-Control 用来指定当前的请求/回复中的，是否使用缓存机制。