学习笔记19——计算机网络八股大厂面试知识点整理

本文链接：https://blog.youkuaiyun.com/CZY925323/article/details/135690859

学习笔记系列开头惯例帮忙发布一些寻亲消息，感谢关注！

链接：https://www.mca.gov.cn/lljz/indexdetail.html?id=9295b013729a4202986da46f9632d344&type=0&t=10.4333732219626494

八股学习记录：

湖科大计网视频
过书，重点看书上运输层的知识（谢希仁第八版）
阿秀的学习笔记
整理笔记，查缺补漏

计网的五层协议/四层是将最下边两层压缩了称为链路层
- 物理层：双绞线，物理传输媒介
- 数据链路层：将ip数据报组装成帧，包括是否错误信息以及从哪里开始是可读的，类似一个数据盒子
- 网络层：将上层得到的数据报（6表示封装的TCP报文，17表示UDP数据报），路由选择（ip地址解析根据路由转发表选择下一步路由）
- 运输层：进程之间的通信UDP/TCP
- 应用层
OSI七层协议
- 物理层：比特流
- 数据链路层：帧
- 网络层：包
- 传输层：tcp报文/udp用户数据报
- 会话层：应用程序之间的会话能力
- 表示层：数据格式
- 应用层
UDP协议
- 支持单播，多播和广播
- 面向报文的
- 无连接不可靠的传输，没有流量控制和拥塞控制
- 首部开销小
TCP协议
- 三握手，仅仅支持单播
- 面向字节流的
- 有连接、可靠传输服务，使用流量控制和拥塞控制
- 首部开销大
TCP流量控制
- 根据返回来的ACK确认值和接收方窗口大小，移动窗口并选择发送数据
TCP拥塞控制
- 慢开始
- 拥塞避免
- 快重传：要求接收方每次都立即发送确认信息，当发送方可以收到三次确认信息，说明网络并不没有堵死，而是由于别的原因导致某个包丢了一直重复确认，此时只需要让发送方马上重传，不要进入超时重传状态，从而无需改变拥塞窗口造成网络资源浪费
- 快恢复：
为什么不是两次握手？
- 是为了防止已失效的连接请求又传送到TCP服务端，导致错误和资源浪费
- 个人理解：我认为前两次握手是让客户端和服务器彼此知晓对方的存在，而第三次握手是对之前的两次握手信息的确认才会正式进入连接建立的状态，如果只有两次握手，那么如果有一些异常连接比如滞留在网络中的客户连接请求发起，那么服务器就会不经过验证直接相应进入到连接建立状态，但是这个连接对于客户端是异常的，所以是不合法的连接，这种情况下服务器端的响应非常浪费资源。
简单说一下四报文挥手？
请说一下完整的HTTP请求的流程？
- 首先我发给DNS去解析网址，得到目的IP
- 经过路由转发，找到目的ip，并三次握手建立连接
- 我访问80端口，对方监听到我的连接请求就会返回前端信息
- 我把接收到的前端信息通过电脑上的搜索引擎渲染成界面
- 当我点击别的东西或者搜索时，就会将数据传到后端服务器，后端服务器响应我的搜索
- 当搜索结束，我主动关掉网页，与对方进行四次挥手，结束
说一下DNS域名解析的原理
- 检查浏览器缓存
- 检测系统缓存
- 通过UDP查询访问，检查本地域名服务器
- 检查根域名服务器——主域名服务器——顶级域名服务器找到对应ip
  - 递归查询，A-B-C
  - 迭代查询：帮忙找到相关的服务器，而不会帮忙查 A-B A-C
- 本地域名服务器，系统缓存以及浏览器缓存缓存这个域名和对应ip，结束
大厂面试：
- 不同版本的http协议对比[02 网络面经：一个TCP连接可以发送多少个HTTP请求？_tcp 并发http-优快云博客](https://blog.youkuaiyun.com/wo541075754/article/details/119903758#:~:text=问题二：一个TCP连接可以对应几个HTTP请求？,如果Connection为close，则一个TCP连接只对应一个HTTP请求。如果Connection为Keep-alive，则一个TCP连接可对应一个到多个HTTP请求。)
- DNS原理：面试官:讲讲DNS的原理？ - 知乎 (zhihu.com)
  - 域名解析用UDP，快
  - 区域复制，辅助DNS服务器从主DNS服务器上复制数据，数据量大且可靠性好
  - UDP只能传输512字节数据
http中缓存的私有和共有字段
- private：将资源作为私有缓存，存储在用户浏览器中
- public：将资源作为公共资源，存储在代理服务器中
HTTP不同版本
- 一篇文章详解请求头Host的概念-优快云博客
- http1.0 短连接，即一次http请求对应一个tcp连接
- http1.1 长连接，即多个http请求可以复用同一个tcp连接，单个TCP连接在同一时刻只能处理一个请求，任意两个HTTP请求在同一个TCP连接中不能重叠
- http2.0 多路复用 Multiplexing，即一个连接上可以同时发起多次request，根据id不同来划分到不同的请求
浏览器对于同一host建立的TCP连接数量有没有限制？
- 浏览器与一个host传输的数据很多时，先商量能不能用http2 （现实中的 HTTP2 都是在 HTTPS 上实现的，所以也就是只能使用 HTTP/1.1）
- 如果不能用那么浏览器就会在一个host上建立多个TCP连接，数量取决于浏览器
http请求方法一般有 get post head
- get和post的区别
- - get是获取数据，post是修改数据
  - get把请求的数据放在url上，以?分割URL和传输数据，参数之间以&相连，所以get不太安全。而post把数据放在HTTP的包体内（request body 相对安全）
  - get产生一个TCP数据包，会将http header和data一并发出去，服务器响应200；post产生两个TCP数据包，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok(返回数据)
  - GET请求会被浏览器主动缓存，而POST不会
  - 本质区别：GET是幂等的，而POST不是幂等的【正因为它们有这样的区别，所以不应该且不能用get请求做数据的增删改这些有副作用的操作。因为get请求是幂等的，在网络不好的隧道中会尝试重试。如果用get请求增数据，会有重复操作的风险，而这种重复操作可能会导致副作用（浏览器和操作系统并不知道你会用get请求去做增操作）。】
输入url到回车经历了什么？
- 域名解析：检查浏览器缓存，本地缓存，检查本地DNS服务器
- - 如果在一个子网内，则采用ARP地址解析进行ARP查询
  - 不在一个子网内，则通过DNS域名解析，得到域名对应的IP地址
- http默认端口为80， https的默认端口为443，三次握手，先尝试通过80建立TCP连接
- - 如果服务器使用的是http，则后续用户端传输请求get、post，后端服务器解析请求，进行数据处理并响应
  - 如果服务器使用的是https传输请求，则给用户端返回一个5开头的重定向并四次挥手，让客户端下次通过443端口进行访问
  - 客户端再次访问443端口，还会采用SSL加密技术保证传输安全，三次握手建立连接，沟通好双方使用的认证算法，加密和检验算法，在此过程中也会检验对方的CA安全证书，确认无误开始通信
- 根据响应结果渲染页面
http和https的区别（SSL加密技术）
- http：被监听；被篡改；网站冒充
- https：交互信息无法被窃取；通信内容校验无法被篡改；真实网站拥有身份证书
- - http的信息是明文传输，https在TCP和HTTP之间加入了SSL/TLS安全协议，使得报文能够加密传输
  - https协议需要向CA申请数字证书，保证服务器的身份是可信的
- https实现的方法？
- - 混合加密：非对称的方式进行共享密钥，对称的方式进行内容加密。
  - - 私钥加密可以由多个公钥解密，而公钥加密只能由私钥解密
    - 服务器生成私钥和多个公钥，客户端向服务器端索要并验证公钥，服务器端保存唯一的私钥
    - 客户端用公钥对对称密钥进行加密
    - 服务器利用私钥对对称密钥进行解密
    - 此时客户端和服务器端都用对称密钥对数据进行传输
  - 摘要算法（哈希算法保持完整性）+数字签名（持有私钥，证明身份可靠性）
  - - 摘要就是对传输的内容通过hash算法得到固定的串
    - 对摘要进行加密得到的结果就是数字签名
  - 数字证书
  - - 验证公钥的合法性
服务器缓存
- 为了缓解服务器的压力，并降低客户端获取资源的延迟
- 可以是服务器缓存，也可以是客户端的浏览器缓存
DNS负载均衡
- 在DNS服务器中为同一个域名配置多个IP地址，在应答DNS查询的时候，按照记录的IP地址顺序返回不同的IP解析结果，从而将客户端的访问分散到不同的服务器上，达到负载均衡的目的
Cookie是什么？
- cookie是 服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器。
- cookie包括
- - 会话状态管理（登陆状态，游戏分数）
  - 个性化设置
  - 浏览器行为追踪
用session来将用户的登录信息存储到服务器端redis，在redis中的key就是session ID，将key传回客户端，下次再来访问的时候，客户端拿着key来就可以拿到用户登录信息value
cookie和session的区别
- cookie保存在客户端，如果是在内存中保存cookie就是会话cookie，关闭浏览器自动销毁，如果是在客户端磁盘上那么就是持久cookie，存储在磁盘中的cookie是多个浏览器共享的
- session是在服务器端保存的，用一个存储在cookie中的session id来唯一标识该客户端
地址解析协议ARP
- [每台主机都设有一个ARP高速缓存，里边有本局域网上各主机和路由器的IP地址到MAC的映射]
- ARP进程在局域网上广播一个ARP请求分组：我的主机为xxx我的ip为xxxx，我想知道ip地址为xxxx的主机的MAC地址
- 所有主机上运行的ARP进程收到请求分组
- 如果主机ip为查询的ip则首先并返回MAC地址，如果不一致则不理睬，因此属于单播
MTU和MSS
- IP数据分片之MTU和TCP的MSS - 知乎 (zhihu.com)
- MTU是数据链路层的最大传输单元，如果上层给下来的数据大于限制，则需要进行分片
- MSS是TCP为了尽量避免下层分片而给出的限制，等于MTU去掉ip头和TCP头剩余的部分
- UDP不分片，只是一股脑地把数据丢给下层去传输，因此会产生由于数据链路层的分片而影响性能
TCP首部
- 端口
- 序号：记录自己正要发送数据的首位偏移
- 确认号：接收方目前收到的序号
- 首部长：标识首部的长度
- 标志位：
  - ACK：标识确认号是否有效
  - SYN：标识请求建立一个连接
  - FIN：发送带有FIN标志位的TCP数据包后连接将被断开
- 窗口：用于告知对方，本方的缓存还能接收多少数据
- 校验和：接收端检查报文是否损坏
三次握手过程
- 初始状态：客户端处于closed状态，服务器处于listen监听转台
- 客户端向服务器发送一个SYN连接请求，并告诉对方自己此时初始化序列号为x，发送之后处于SYN_send状态
- 服务器收到客户端发来的请求，如果同意建立连接，那么就也发送一个SYN=1的信号，并发送自己的初始化序列号seq = y，同时为了告诉客户端自己下一步想要接收的信息（为了告诉客户端你的消息我收到了），发送确认序列号ack = x+1，并将ACK置为1发送回去，服务器此时为SYN_Receive状态【站在客户端，此时发送信息并得到回应，她会认为这是个靠得住的服务器，但是对于服务器来说，你发送我就全盘接收可太没有保障了，我都不知道你是谁，也不知道你到底有没有发送能力，就白白留一个连接等着你，所以服务器不答应两次握手，他也要试试客户端是真有能力还是假有能力，此时迎来第三次握手】
- 第三次握手是客户端收到服务端的返回后，客户端发送同步序列号seq = x+1，并对服务器端的序列进行确认响应，将ACK置为1并回复ack=y+1，客户端转为established，服务器收到这个消息之后也转为established。
如果第三次握手包丢了怎么办？
- TCP第三次握手能携带数据吗？做个实验就知道！ - 知乎 (zhihu.com)
三次握手过程中可以携带数据吗？
- 第一次和第二次不可以，因为此时客户端和服务器在第一次第二次时都是第一次收到对方的连接信息，彼此尚不信任，而对于第三次，客户端已经处于established状态，已经确认对方的收发能力没问题，所以可以发送数据，服务器只要收到这个数据就可以知道客户端的发送能力没问题，所以也会进入established状态，接收下这批数据
什么是半连接队列？SYN_received状态的集合
- 服务器端将只收到第一次客户端发来的SYN的请求连接放在一个队列里边，成为半连接队列
- 已经完成三次握手的连接称为全连接队列
DDos攻击【SYN攻击就是其中一种】
- 客户端向服务器端发出请求连接，服务器向客户端发送确认数据包后，客户端不再响应，留下服务器端一直在等待客户端的确认，造成资源浪费
- 解决方法
  - 限制同时打开SYN半连接队列的数目
  - 在固定的SYN半连接重传次数下，缩短SYN半连接的等待时间
  - 关闭不必要的服务
  - 过滤网关服务
  - SYN cookie是在二次握手结束后，服务器不分配资源，直到三次握手结束才通过客户端发送的ack倒推出报文序号
四次挥手流程
- 1、客户端：我要和你离婚，这是离婚协议书，我已经签了你签个字吧【发送FIN=1，并发送此时的序列号seq=u，进入FIN_WAIT1】
- 2、服务端：啊？你再说一遍？你要和我离婚，我还有好多愿望没和你一起实现呢【发送ACK=1,ack=u+1，seq=v,服务端进入CLOSE_WAIT，客户端听了进入了FIN_WAIT2】你听我说啊巴拉巴拉
- 3、服务器端见到自己挽回了这么久，客户端也没有说一句话，知道没有希望了：好吧，缘分尽了莫强求。他狠下心来签了离婚协议书【FIN=1,ACK=1,seq=w，ack=u+1，服务端进入LAST_ACK状态，客户端进入TIME_WAIT】
- 4、客户端冷静的看到签好的离婚协议书，说：从此一别两宽吧【ACK=1,seq=u，ack=w+1，服务器收到进入CLOSED】，她顿了一下，想看看服务器还要说什么，毕竟夫妻一场以后再也见不到了，心中还是空落落的，可过了一会儿见还是一阵沉默，她心想：”算了，一切都结束了！“【客户端进入CLOSED】
为什么需要四次挥手？
- 先说为什么要基于三次？客户端说断了，服务器说断了，客户端说好的，既然都同意那就正式断开，但是如果没有最后一次客户端回复，那么第二次服务器说断开的时候，如果消息丢了，那么客户端就需要一直等着，造成资源浪费
- 那么为什么还要多一次呢？是因为断开连接的想法是某一方单独发起的，她并不知道对方是否也没有数据要传输了，所以在一方提起断开后，另一方收到说我知道你的意思了，你等我解释一下，等消息发完了说我这边没什么要说的了就这样吧，断了，发起方说好的，既然都同意那么就正式断开
2MSL等待时间（MSL是任何报文在网络中存在的最长时间，超过这个时间就会被丢弃）
- 为了防止最后一个ack丢失，规定该连接必须在TIME_WAIT状态等待2MSL，一旦丢失（MSL时间内还未传到，那么该报文在网络中的停留时间已经达到MSL，就被丢弃了）另一端会超时重传FIN，那么就需要重发ack，如果没有等待时间，在挥手不完整的情况下，客户端就已经断开连接，导致服务器端资源被空占
- 防止本次连接产生的已失效连接请求报文出现在下一次连接中：客户端在发送完最后一个ACK报文段后，再经过2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
网络层的IP首部
TCP首部的校验和和IP首部的校验和区别：TCP校验包括TCP首部和TCP数据，发送方计算接收方验证，如果结果不匹配则TCP段直接丢弃，而IP首部中的校验只包括IP首部，两者都是采用反码求和得到的。
数据链路层的首部
TCP粘包问题和解决方案
- 一次请求发送的数据太少，TCP会将多个请求合并到一个TCP包发送
- Nagle算法是为了避免发送小的数据包而提出的
- TCP-IP详解：Nagle算法-优快云博客
- MSS就直接发送
- 只有上一个分组确认后，才发送下一个分组
- 在等待上一个分组确认的过程中，会累计收集多个小分组，确认一到就一起发出去
- 面试题：聊聊TCP的粘包、拆包以及解决方案 - 知乎 (zhihu.com)
- 解决方案
  - 发送端将包的大小固定，不满足大小的进行填充
  - 在每个请求数据尾部加固定分隔符
  - 消息分为头部和尾部，头部保存长度，尾部保存信息
  - Netty解码【待补充】
封包和拆包听说过吗？
- 封包就是在发送数据包的时候加上包头，一个TCP数据包包括包头和包体两部分
- 拆包就是根据包头中的长度信息进行截取
TCP如何保证可靠传输
- 是面向连接的，三次握手和四次挥手确保通信双方具有收发数据的能力
- 确认重传机制：收到会回复确认，没有收到确认消息的会重新发
- 校验和：TCP首部和TCP的数据会在接收方进行校验和，如果有误则丢掉
- 数据合理分片和排序：按照最大传输单元合理分片，在接收方会缓存未按序到达的数据，重新排序后交给应用层，但是UDP在网络层会被切片，而接收方IP层则需要进行数据报的重组。由于UDP的特性，某一片数据丢失时，接收方便无法重组数据报，导致丢弃整个UDP数据报。
- 流量控制
- 拥塞控制
Ping命令基于什么协议？
- ping是基于网络层的ICMP协议实现的【ICMP协议被封装在IP数据包中传输到目的主机，中间经过的每个路由都可以拆开并能看懂协议】，主机A向对方主机B发送一个ICMP回送请求报文，如果主机B可达，就会响应一个ICMP回送回答报文，如果主机B不可达，那么就会回复差错报告报文，如终点不可达或时间超过。
TCP滑动窗口为0时，可以特殊发送的数据
- 允许用户终止在远程机上的运行程序
- 允许发送方发送一个1字节的数据报通知接收方重新声明希望接收的下一字节及发送方的滑动窗口大小
超时重传、RTO、RTT
- 超时重传：超过等待时间尚未收到确认就重新发送
- RTO:上一次发送到下一次重发之间的时间，通常每次RTO是前一个RTO的2倍，达到一定次数就停止重传
- RTT:是数据发送到收到对方响应的时间间隔
服务器出现大量的close_wait连接
- 服务器业务处理占用时间很多，没能处理完/数据没有发送完/业务没有正确close
- 服务器啊父进程派生出紫禁城
四种前端安全漏洞
- XSS攻击：攻击者篡改网页，嵌入恶意脚本程序，控制用户浏览器
  - 前端和后端对输入的字符串长度进行限制
  - 前端和后端对HTML中特殊字符转义编码，防止被篡改
- CSRF攻击：盗用合法用户身份进行非法操作
  - 安全框架
  - token验证
  - 验证码
  - referer：记录http请求的来源地址
- 文件上传漏洞
  - 用户上传一个可执行的脚本文件，该脚本文件获得了执行服务端命令的能力
    - 判断文件类型
    - 白名单
    - 对上传的文件进行重命名，使得攻击者不知道上传文件的访问路径
    - 限制上传文件的大小
    - 单独设置文件服务器的域名
- SQL 脚本注入