计网 #

基础篇 #

体系结构 #

OSI体系结构 #

• 应用层
• 表示层
• 会话层
• 运输层
• 网络层
• 数据链路层
• 物理层

TCP/IP体系结构 #

• 应用层
• 运输层
• 网络层
• 网络接口层

原理体系结构 #

• 应用层
• 运输层
• 网络层
• 数据链路层
• 物理层

原理体系结构详情 #

应用层 #

应用层只需要专注于为用户提供应用服务，不需要关心数据是如何进行传输的，它只会将数据包给“快递员”负责，这个“快递员”就是运输层

运输层(传输层) #

传输层的任务就是负责传输数据，在传输层中，有两个重要的协议TCP和UDP

TCP协议 #

提供面向连接的，可靠的数据传输服务，数据的传输单位为报文段，在TCP协议中，如果数据吧大小超过MSS(TCP最大报文段长度)，就要把数据包分块传，每个分块叫做TCP段

UDP协议 #

提供无连接的，尽最大努力（不可靠的）进行数据传输，数据的传输单位是用户数据段

网络层 #

实际上，传输层并不认真的从一个设备传输数据到另外一个设备上，传输层只是一个媒介，更好地服务应用层罢了，真正进行传输的是网络层，网络层最常用的是IP协议

IP协议 #

IP协议会将传输层产生的报文段数据与IP包头组成IP报文，如果IP报文太大超过了MTU，就会再次分片

IP协议的寻址和路由 #

IP 协议的寻址作用是告诉我们去往下⼀个目的地该朝哪个方向走，路由则是根据下一个目的地选择路径。寻址更像在导航，路由更像在操作方向盘

数据链路层 #

数据链路层的任务就是将分组从一端传送到另外一端，传送的数据单位为：帧。这个传输设备一般是路由器

路由器计算出下一个IP地址，再通过ARP协议找到目的地网卡的MAC地址，就知道该IP是哪个设备了

物理层 #

物理层会将数据包转化为电信号，让其在物理介质中传输，它主要为数据链路层提供二进制传输任务

原理体系结构(教科书) #

应用层 #

应用层：通过应用进程间的交互来实现特定网络应用，直接为用户或应用进程提供特定的应用服务，如文件传输、电子邮件等

运输层 #

负责两台主机中进程之间的通信提供通用的数据传输服务。具体包括：复用与分用、可靠数据传输、流量控制、拥塞控制等

网络层 #

负责为分组交换网上的不同主机提供通信服务。核心功能是逻辑编址、路由选择和分组转发

数据链路层 #

在两个相邻结点间（主机和路由器或路由器和路由器之间）的链路上传送以帧为单位的数据。具体包括：组帧、差错控制、物理编址、接入控制、流量控制等

物理层 #

在物理媒体上传送比特流。具体包括：与物理媒体的接口、比特的表示与同步、数据率、线路配置、物理拓扑等

HTTP篇 #

HTTP基本概念题 #

HTTP是什么？ #

HTTP全名为 超文本 传输 协议 ，HTTP协议是一个在计算机世界里专门在两点之间传输超文本数据的规定和规范

超本文

一种超级文本，能包含文字、图片、视频等，具有超链接，能从一个超文本跳转到另外一个超文本

传输

双向传输，允许中间有接力，但是要符合规定

协议

为计算机之间的交流通信确立一种规范

五大类常见HTTP状态码 #

• 1xx：属于提示信息，是一种协议处理的中间状态

• 2xx：表示服务器成功处理了客户端的请求

  • 200：ok，一切正常
  • 204：no content，成功，但是响应头没有body数据
  • 206：partial content，表示返回的body数据只是一部分

• 3xx：表示客户端请求的资源发生了变动，需要重定向

  • 301：moved permanently，表示永久重定向，说明请求资源已经不存在了，需要改用新的url访问，新的url会在响应的 Location 首部，一般来说永久重定向是会被浏览器缓存的
  • 302：found，表示临时重定向，说明请求的资源还在，但暂时需要另外一个url访问，一般来说临时重定向是不会被浏览器缓存的
  • 304：与浏览器缓存控制有关，状态码304并不是一种错误，而是告诉客户端有缓存，直接使用缓存中的数据

• 4xx：表示客户端发送的报文有误，服务器无法处理（错误码）

  • 400：bad request，笼统的错误，表示客户端请求的报文有误
  • 401：forbidden，表示服务器禁止访问资源，并不是客户端的错误
  • 404：not found，表示请求的资源在服务器上找不到

• 5xx：表示客户端请求的报文正确，但是服务端内部出现了一些错误

  • 500：笼统的错误，表示服务器出错了
  • 501：not implemented，表示客户端请求的功能服务端还支持不了
  • 502：bad getway，通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，但是后端服务器发生了错误
  • 503：service unavailable，表示服务器当前很忙，暂时无法响应

常见的HTTP请求头字段 #

• Accept:浏览器能够处理的内容类型
• Accept-Charset:浏览器能够显示的字符集
• Accept-Encoding：浏览器能够处理的压缩编码
• Accept-Language：浏览器当前设置的语言
• Connection：浏览器与服务器之间连接的类型
• Cookie：当前页面设置的任何Cookie
• Host：发出请求的页面所在的域（客户端发送请求时，用来指定服务器的域名）
• Referer：发出请求的页面的URL
• User-Agent：浏览器的用户代理字符串

常见HTTP响应头字段 #

• Date：表示消息发送的时间，时间的描述格式由rfc822定义
• server:服务器名称
• Connection：浏览器与服务器之间连接的类型
• Cache-Control：控制HTTP缓存
• content-type:告诉客户端，本次数据是什么格式

常见HTTP请求头字段(补充) #

Accept #

客户端能够处理的内容类型，如application/json，text/plain等，是MIME类型

Accept-Encoding #

Accetpt-Encoding可以将客户端能够理解的压缩编码方式告知给客户端，如gzip，compress，deflate

Connection #

客户端与服务器的连接类型，在HTTP 1.1以后一般是默认长连接，也就是keep-alive

Authorization #

身份验证的凭证，一般用于存放token

X-Requested-With #

主要用于判断是否是ajax请求，如果是ajax请求的话，其值一般为XMLHttpRequest

If-Modified-Since #

在请求头中用于保存 Last-Modified 时间标识符的值，用于协商缓存作判断

If-None-Match #

在请求头中用于保存 Etag字符串标识符的值，用于协商缓存作判断

Content-Type #

MIME类型，非常重要，在响应头中也会有

application/x-www-form-urlencoded(form) #

普通表单post方式的默认类型，当为post的时候，需要用qs库将JS对象参数转化成由&连接的字符串，HTTP会将此字符串并放到请求体里面。当为get的时候，也需要qs库转化，HTTP会将此字符串拼接到url上，中间用?隔开

multipart/form-data(form) #

一般用于上传文件的表单。它会以标识符boundary开始，也会以它就是，中间是文件或者文本的附加信息，类型不同，附加信息也不同，文件会多一个filename

application/json;charset=UTF-8;(payload) #

如果是Restful风格接口一般使用这个，axios默认格式就是json，所以发送请求的时候可以不需要特地设置，这里的话我们可以使用JSON.stringfy将JS对象转化为json格式。当为post请求的话，会原封不动的将json数据放在请求实体里

常见HTTP响应头字段 #

Cache-Control(强缓存) #

由HTTP 1.1 提出，静态资源如（js，css，img）可以被浏览器缓存，而像html以及网页业务数据也不能被缓存。所谓强缓存就是不需要发送网络请求，资源直接从本地缓存中获取

Cache-Control:max-age=N #

浏览器获取到资源内容后，将资源内容缓存在本地，缓存有效期是N秒

Cache-Control:no-store #

禁止缓存，浏览器每次都要请求服务器，服务器每次都要返回200状态码以及资源内，既不走强缓存，也走协商缓存

Cache-Control:no-cache #

资源可以缓存在浏览器本地，但每次使用缓存前，都要跟服务器协商确认资源是否有更新(协商缓存)

Cache-Control:private #

只能允许最终用户做缓存，最终的用户就是你的电脑手机等

Cache-Control:public #

允许中间路由或者中间代理做缓存

Expires(强缓存) #

由HTTP 1.0 提出

Expires是用于表示资源的过期时间的请求头字段，值是一个绝对值，是由服务器返回的。当第一次请求的时候，服务端返回的响应头会附上EXpires字段，当客户端在下一次请求这个资源的时候会根据上次的EXpires字段决定是否使用缓存资源（当请求时间小于服务端返回的到期时间，直接使用缓存数据，否则将重新请求）

补充：

• Expires有个缺点，它是根据本地时间来判断的，因此当客户端的本地时间被修改的时候，会导致缓存命中误差，可能会直接向服务器请求新的资源
• 优先级小于Cache-Control

Last-Modified(协商缓存) #

Last-Modified 表示资源的最后修改时间，对应请求头为 If-Modified-Since，判断只能精确到秒级

Etag(协商缓存) #

Etag 的本质是一个字符串，代表着资源的唯一标识符。对应请求头为 If-None-Match，优先级比Last-Modified高，用 Etag 就能够保证在文件被频繁改动的情况下，客户端以秒级别的刷新也能得到最新的资源

HTTP 0.9 特性 #

HTTP 0.9 是最早的一个版本，是在1991年提出的，它的功能较为简单

• 只有一个请求行，没有请求头和请求体
• 服务器返回的数据没有头信息
• 服务器返回文件的内容是以ASCII字符流来传输的，因为只支持HTML文件

HTTP 1.0 特性 #

为了满足可以传输多类型文件的需求，HTTP 1.0 出来了！！!

• 增加了请求头和响应头，满足了传输多类型文件的需求
• 引入了状态码，来告知浏览器发送请求的处理情况
• 提供了Cache机制，用于缓存数据
• 在请求头中加入了User Agent字段，方便了服务器统计客户端的信息

HTTP 1.1 特性 #

优点 #

• 简单：HTTP 基本的报⽂格式就是 header + body ，头部信息也是 key-value 简单⽂本的形式，便于理解
• 灵活和易扩展性：HTTP协议里的各类请求状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充
• 应用广泛和跨平台：HTTP的应用相当广泛，不管是PC端还是移动端都有大量使用

缺点 #

• 无状态：服务器没有记忆能力，完成关联性的操作很麻烦，比如登录->下单->结账等都需要知道用户的身份，这一点可以通过cookie解决
• 明文传输：HTTP 的所有信息都暴露出来了，相当于信息裸奔，信息极有可能会被窃取
• 不安全：可能会被窃听（明文传输）、伪装（没有验证对方的身份）、篡改（报文被修改）

HTTP 1.1 性能 #

HTTP是基于TCP/IP协议的，并且使用了请求-应答模式，关键点就在这里

长连接（持久连接） #

在早期的HTTP 1.0 中，浏览器每发送一次请求都要进行一次TCP连接，也就是三次握手和四次挥手，这是做了无谓的开销。在HTTP 1.1 中使用长连接的模式，只要任意一端没有明确提出断开连接，那么会保持TCP连接的状态

管道传输 #

即可在同⼀个 TCP 连接里面，客户端可以发起多个请求，只要第⼀个请求发出去了，不必等其回来，就可以发第 二个请求出去，可以减少整体的响应时间，但是服务端响应还是会按照请求的顺序响应，也会存在队头阻塞

队头阻塞 #

当请求队列的一个请求因为某种原因而得不到响应，也就是被阻塞的时候，会导致后面的请求也得不到服务端的回应，导致客户端一直请求不到数据，这就是队头阻塞，好比路上上班时候的堵车情况

HTTP 2.0 缺陷 #

HTTP 2.0 采用多路复用，可以在同一个TCP连接中并发多个请求。但是就是因为多个请求共用一个TCP连接，一旦发送丢包，就会触发TCP的重传机制，而其他的请求都必须等待这个丢了的包完成重传。这样其实也就会阻塞了HTTP请求

HTTP 3.0 特性 #

HTTP 1.1 管道传输会存在队头阻塞。HTTP 2.0 多路复用时候，一旦发生丢包，就会阻塞HTTP的所有请求。造成这些的原因都是传输层TCP的问题。所以HTTP 3使用UDP来进行传输

基于UDP的QUIC协议 #

我们都知道UDP传输是不可靠的，但基于UDP的QUIC协议也可以做到可靠传输的效果

• QUIC 有自己的⼀套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响
• TLS使用最新的1.3版本，头部压缩算法升级成了QPACK
• 对于HTTPS来说，建立一次连接需要6次交互，而QUIC把6次交互合并成了3次，减少了交互次数

HTTPS特性 #

HTTPS解决了HTTP的不安全的问题，具体有：窃听风险、篡改风险、伪装风险

混合加密 #

混合加密包括非对称加密和对称加密，它解决了信息风险

• 在通信建立前采用非对称加密的方式交换会话密钥，后续不再使用非对称加密的方式
• 在通信过程中采用对称加密的方式来加密数据

摘要算法 #

摘要算法用来实现数据的完整性，能够为数据生成独一无二的指纹，能够解决篡改风险

客户端在发送明文之前会通过摘要算法计算出明文的指纹，然后发送的时候把明文和指纹一起加密打包发送给服务器，服务器接受到并且解密后，用相同的摘要算法计算出明文的指纹，通过比对看是否指纹一样，如果不一样则说明数据是不完整的

数字证书 #

证书能保证服务端的身份是可信的，解决了伪装风险

服务器会把公钥放在数字证书里，只要证书是可信的，那么公钥也是可信的。因此可以通过CA证书的方式来保证服务器身份是可靠的，解决了伪装的风险

TLS 1.2 四次握手过程 #

TLS握手主要的目的是使用非对称加密交换密钥

• 第一次握手：客户端向服务端发出请求，具体内容有自己支持TLS的版本、加密套件和一个随机数，这个随机数稍后用于计算会话密钥
• 第二次握手：服务端回应，并且也把自己支持的TLS版本，加密套件和随机数发给客户端，接着服务端还把证书和公钥发给客户端，然后告知客户端发送完毕
• 第三次握手：如果证书真实有效，则客户端会向服务端发送三项信息：一个用服务端公钥加密后的随机数（也就是预主密钥）、编码改变通知、客户端握手结束通知
• 第四次握手：服务端收到预主密钥后，会结合第一次随机数和第二次随机数计算出会话密钥，然后会向客户端发送两项信息：编码改变通知、服务端握手结束通知

TCP篇 #

TCP头部格式分析 #

• 序列号：用来解决网络包乱序的问题
• 确认应答号：指的是下一次希望收到数据的序列号，用来解决丢包的问题
• 控制位：
  • ACK：该位为1时，确认应答字段变成有效，TCP规定除了初次建立连接以外，改位必须为1
  • RST：该位为1时，表示TCP连接出现异常必须强制断开连接
  • SYN：该位为1时，表示希望建立连接
  • FIN：该位为1时，表示以后不会再有数据发送，希望断开连接

TCP特点 #

• 面向连接：一对一全双工通信
• 可靠：保证数据一定能够到达接收端
• 字节流：消息无论多大都能够进行传输，并且消息是有序的，同时重复的报文会进行丢弃
• 拥塞控制和流量控制：保证数据传输的安全性

TCP三次握手 #

TCP需要在在不可靠的信道上建立可靠的连接，三次握手的主要原因是为了防止旧的重复连接初始化造成混乱

连接过程 #

1. 客户端向服务端发送SYN报文，表示请求连接，然后进入SYN_SENT状态
2. 服务端接受到客户端发送的SYN包后，如果同意连接，则向客户端发送SYN+ACK报文，然后进入SYN_RCVD状态
3. 客户端收到后回复一个ACK报文，表示确认，然后进入ESTABLISHED状态；服务器接受到ACK报文后也会进入ESTABLISHED状态

为什么不是两次握手？ #

如果采用两次握手，假如客户端第一次发送SYN，因为某种原因导致其在网络节点上出现滞留而没有送到服务端，则客户端会重发SYN包希望建立连接，假如这次能正常应答并且客户端和服务端建立起了连接。这时候突然第一次发送的SYN突然恢复正常，发送到了服务端中，服务端会以为是新建立的连接，会一直等待客户端发送数据，这种情况会造成资源浪费

为什么不是四次握手？ #

很显然，四次握手也同样能达到我们想要的效果，但是我们可以将发送ACK报文和发送SYN报文这两步可以简化成一步，这样做可以提高连接的速度，因此三次握手会更好。

TCP四次挥手 #

断开连接过程 #

• 第一次挥手：客户端发送一个FIN报文，进入FIN_WAIT_1状态
• 第二次挥手：服务端收到FIN报文之后，会向客户端发送ACK报文，表明已经收到客户端的报文了，服务端自己会进入CLOSE_WAIT状态，客户端收到ACK报文后会进入FIN_WAIT_2状态
• 第三次挥手：服务端向客户端发送FIN报文，之后服务端会进入LAST_ACK状态
• 第四次挥手：客户端收到了FIN报文后，会向服务端发送一个ACK报文后，然后进入TIME_WAIT状态。如果服务端收到了ACK包后就进入CLOSED状态即完成了断开连接的关闭，而客户端需要等待一段时间后才会进入CLOSED状态

为什么挥手需要四次？ #

关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等我服务端所有的报文都发送完了，才能发送FIN报文，因此不能一起发送，故需要四次挥手

为什么在最后一次挥手中，客户端要等待一段时间再关闭？ #

为了防止客户端发送给服务端的ACK报文丢失，导致服务端不能正常关闭，因此要等待2MSL

TCP粘包 #

原因 #

默认情况下，TCP连接会启用延迟传送算法，在数据发送之前会缓存他们，如果短时间有多个数据发送，就会缓冲到一起发送，这样可以提高IO的效率。如果是传送整个文件的话，就不需要处理粘包问题，而如果是多个零碎的消息，就需要处理粘包问题

解决方法 #

• 关闭延迟传送算法，不再进行缓冲，而是直接发送
• 多次发送之前间隔一个的等待时间
• 进行特殊地封包和拆包处理，在发送数据之前，会在其前后放有一些有特征的数据，然后收到数据后，根据特征值提取各个数据包

DNS篇 #

作用 #

DNS是Domain Name System的缩写，可以将域名解析为IP地址，客户端向DNS服务器发送查询域名请求，DNS服务器会告知其该域名对应的IP地址

使用TCP和UDP协议 #

DNS占用53端口，同时使用TCP和UDP协议

• 在区域传输之间使用TCP协议：辅域名服务器会定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步
• 在域名解析的时候使用UDP协议：客户端向DNS服务器查询域名时候使用UDP协议，这样的话DNS服务器负载更低，响应更快

DNS域名解析过程（例子） #

比如要查询 www.baidu.com 的 IP 地址，首先会在浏览器的缓存中查找是否有该域名的缓存，如果不存在就将请求发送到本地的 DNS 服务器中，本地DNS服务器会判断是否存在该域名的缓存，如果不存在，则向根域名服务器发送一个请求，根域名服务器返回负责 .com 的顶级域名服务器的 IP 地址的列表。然后本地 DNS 服务器再向其中一个负责 .com 的顶级域名服务器发送一个请求，负责 .com 的顶级域名服务器返回负责 .baidu 的权威域名服务器的 IP 地址列表。然后本地 DNS 服务器再向其中一个权威域名服务器发送一个请求，最后权威域名服务器返回一个对应的主机名的 IP 地址列表

CDN篇 #

定义 #

CDN的全称是Content Delivery Network也叫内容分发网络，由部署在各地的边缘服务器组成

CDN的作用 #

简单来说，CDN可以理解为加速器，它可以将用户的请求定向到最近的缓存服务器上去获取内容，这样，大大提高用户访问网站的速度

CDN的适用场景 #

• 图片文件
• 音乐或视频
• 直播
• 访问加速

区别题 #

Get和Post的区别 #

• 含义不同：Get方法的含义是向服务器获取资源；Post方法的含义是向URL指定的资源提交数据，数据就会放在body里

• 是否幂等：Get方法是幂等的，无论操作多少次，服务器上的数据都是安全的并且每次返回的数据也是相同的；Post方法是不幂等的，他会修改服务器上的数据

• 支持的参数类型不同：Get请求只能进行url编码；Post请求支持多种编码方式

• 长度限制：Get请求在URL中传送的参数是有长度限制的；Post请求没有

• 是否缓存：一般来说，浏览器会对Get请求进行缓存而Post不会

HTTP和HTTPS区别 #

• HTTP传输是明文传输，而HTTPS解决了HTTP的不安全的缺陷，它多了一个SSL/TLS安全协议，使得报文能进行加密传输
• HTTP只需要建立TCP三次握手后即可进行报文传输，而HTTPS还要进行SSL/TLS握手才能进行加密报文传输
• HTTPS需要CA证书，来保证服务器的身份是可信的，而HTTP没有
• HTTP的端口为80，而HTTPS的端口为443

HTTP 1.0 和 HTTP 1.1 区别 #

• 连接方面：HTTP 1.0 默认使用非持久连接，HTTP 1.1 默认使用持久连接
• 资源请求方面：HTTP 1.0 不支持断点续传功能，服务器会将整个对象送过来，而HTTP 1.1 允许只请求资源的某个部分，节省了宽带
• 缓存方面：HTTP 1.1 有了更多可供选择的缓存头来控制缓存
• 字段方面：HTTP 1.1 新增了host字段，用来指定服务器的域名
• 请求方面：HTTP 1.1 新增了PUT、HEAD等操作

HTTP 1.1 和 HTTP 2.0 区别 #

• 二进制格式：HTTP 1.1 报文是纯文本的，而HTTP 2.0 的报文全面采用二进制形式，并且统称为帧，分为头部帧和数据帧，对人可能不友好，但是对于计算机来说很友好，提高了数据传输的效率
• 头部压缩：HTTP1.1是无状态的，所以每次都必须附上所有的信息，因此有很多信息都是重复的。在HTTP 2.0，如果同时发送多个请求，那么协议会帮你消除重复的部分（HPACK），这样可以提高速度
• 数据流：HTTP 2.0提出了数据流的概念，因为HTTP 2.0 数据包并不是按照顺序进行发送的，同一个连接里面连续的数据包，可能属于不同的请求，因此必须要对数据包做标记，指出它是属于哪一个回应
• 多路复用：HTTP 2.0可以在一个连接中并发多个请求或者响应，而不用按照顺序一一对应，而HTTP 1.1 是串行请求的，还存在着队头阻塞的问题。HTTP 2.0的多路复用大大降低了延迟，大幅度提高了连接的利用率
• 服务器推送：服务器不再是被动的响应请求，它还可以主动推送一些资源给客户端

TCP和UDP区别 #

• 连接方式：TCP面向连接的，而UDP是无连接的
• 连接对象个数：TCP只能一对一，而UDP可以一对一，也可以一对多
• 可靠性：TCP能保证数据完整安全地进行传输，而UDP是尽最大努力交付
• 传输方式：TCP是流式传输，没有大小限制，而UDP是一个包一个包的发送，有大小限制
• 拥塞控制、流量控制：TCP有而UDP没有，即使网络非常拥堵了也不会影响UDP的发送速率
• 首部开销：UDP首部只有8字节，TCP首部最小20字节，最大60字节

综合题 #

从浏览器输入URL到页面显示发生了什么？ #

• 浏览器首先会对URL进行分析，分析哪一部分代表着什么信息和什么含义
• 浏览器向DNS请求解析URL的IP地址，DNS解析并返回对应的IP地址
• 浏览器和服务器建立TCP连接，这里默认成功连接
• 浏览器发送请求，服务器处理请求并且返回响应结果
• 关闭TCP连接
• 浏览器拿到数据后就进行渲染