Java后端高频知识点学习笔记8---计算机网络

Java后端高频知识点学习笔记8---计算机网络

参考网址：牛 _ 客 _ 网
https://www.nowcoder.com/discuss/819312

1、OSI七层模型

OSI 模型把网络通信的工作分为 7 层，从下到上分别是物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

1、物理层
协议：IEEE802.11(无线局域网)
传输单位：比特/bit
任务：在物理媒体上为数据端设备透明地传送比特流
实现硬件：集线器、中继器

2、数据链路层
协议：ARQ、STP、PPP
ARQ：自动重传请求协议； PPP：点对点协议； STP：生成树协议
传输单位：帧/frame
任务：将网络层传来的IP数据报组装成帧
实现硬件：交换机、网桥

3、网络层
协议：IP、ARP、OSPF； ARP:将ip地址转化为Mac地址； OSPF:路由选择协议
传输单位：数据包
任务：
1、将传输层传下来的报文段封装成分组
2、选择合适的路由，使得传输层传下来的分组能够交付到目的主机
实现硬件：路由器

4、传输层
协议：TCP、UDP；
TCP：传输控制协议； UDP：用户数据包协议
传输单位：数据段：报文段（TCP）；用户数据段（UDP）
任务：

  • TCP：负责主机中两个进程之间的通信，为端到端的连接提供 可靠的传输服务
  • UDP：负责向两台主机进程之间的通信提供 通用的数据传输服务

5、会话层
任务：不同主机上各进程间的对话
功能：管理主机间的会话进程，包括建立、管理以及终止进程间的会话

6、表示层
处理在两个通信系统中交换信息的表示方式
主要负责数据格式的转换，如加密解密、转换翻译、压缩与解压缩 等

7、应用层
协议：HTTP、FTP、DNS、SMTP
任务：提供系统与用户的接口
为应用程序提供交互服务；在互联网中的应用层协议很多，例如：域名系统DNS，支持万维网应用的HTTP协议，支持电子邮件的SMTP协议等

2、TCP三次握手和四次挥手

三次握手

  • 为了准确⽆误地把数据送达⽬标处，TCP协议采⽤了三次握⼿策略来建立连接
    1、一次握手：客户端––>服务端； 发送SYN（请求）报文
    2、二次握手：服务端––>客户端； 收到SYN（请求）报文后会发送SYN+ACK（请求+确认）报文
    3、三次握手：客户端––>服务端； 收到SYN+ACK（请求+确认）报文后发送ACK（确认）报文

为什么要三次握手？

三次握⼿的本质⽬的是建⽴可靠的通信信道，或者说是，双⽅确认⾃⼰与对⽅的发送与接收都是正常的

  • 第⼀次握⼿：Client 什么都不能确认；Server 确认了对⽅发送正常，⾃⼰接收正常

  • 第⼆次握⼿：Client 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常；Server 确认了：对⽅发送正常，⾃⼰接收正常

  • 第三次握⼿：Client 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常；Server 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常

  • 总结：三次握⼿就能确认双发收发功能都正常，缺⼀不可

为什么不两次握手 / 为什么要三次握手？

  • 客户端首先向服务器发送一个连接请求，但是可能这个连接请求走了远路，等了很长时间，服务器都没有收到，那么客户端可能会再次发送请求并完成连接、数据传输、断开连接；
    此时服务器端才收到之前的请求；并且回复SYN+ACK报文；在这个时候最先发送的那个连接请求到达服务器，那么服务器会回复一个SYN+ACK报文；但是客户端表示自己已经不需要进行数据传输，并不搭理这个回复，那么服务器可能陷入等待，如果这种情况多了，那么会导致服务器瘫痪，所以要三次握手

四次挥手

  • 断开⼀个 TCP 连接则需要“四次挥⼿，在双方都没有数据要传输后才能真正断开连接
    1、客户端不再向服务器端发送数据，发送⼀个 FIN(连接释放请求)报文，⽤来关闭客户端到服务器的数据传送
    2、服务器收到 FIN(连接释放请求)报文，回复⼀个 ACK(确认)报文，确认序号为收到的序号加1；和 SYN ⼀样，⼀个FIN 将占⽤⼀个序号
    3、服务器也不再向服务器端发送数据；关闭与客户端的连接，发送⼀个FIN给客户端
    4、客户端回复 ACK报文，并将确认序号设置为收到序号加1

为什么要四次挥手？

  • TCP连接是全双工传输，任何⼀⽅既能发送数据又能接收数据，因此TCP双方断开连接前，需要确认双方没有数据要传输；
  • 当 A 没有数据要发送时，则发出连接释放请求（FIN报文），告知 B 自己没有数据要发送了，但 B 还可能发送数据过来，因此 B 先向 A 发送确认报文，当 A 接收到 B 的 ACK(确认)报文，进入半关闭状态；
  • 当 B 也没有数据要发送时，B 向 A 发送 FIN(连接释放请求)报文，A 收到释放请求后发送确认；对⽅确认后就完全关闭了TCP连接

3、如果建立TCP连接后，客户端挂了怎么办

TCP 协议的保活机制

  • TCP设有一个保活计时器，服务器每收到一次客户端的请求后，都会重新复位这个计时器，时长通常设置为2个小时，如果两个小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每间隔75秒发送一次，如果一连发了10个探测报文仍然没响应，服务器就认为客户端出了问题，关闭连接

保活机制的原理

  • 在一个时间段内，如果没有任何连接相关的活动，每隔⼀个时间间隔，发送⼀个探测报⽂，该探测报⽂包含的数据⾮常少；如果连续⼏个探测报⽂都没有得到响应，则认为当前的TCP 连接已经死亡，系统内核将错误信息通知给上层应⽤程序

4、TCP和UDP的区别

TCP和UDP的区别

总结

  • 1、TCP是面向连接的传输层协议，即传输数据之前必须先建立好连接，UDP无连接
  • 2、TCP是点对点的两点间服务，即一条TCP连接只能有两个端点；UDP支持一对一，一对多，多对一，多对多的交互通信
  • 3、TCP是可靠传输，UDP不可靠
  • 4、TCP有 流量控制 和 拥塞控制 保证数据传输的安全性；UDP没有流量控制和拥塞控制，网络拥塞不会影响源主机的发送效率
  • 5、如果要保证数据的完整性，则应选用TCP协议，例如：文件传输、重要状态的更新；如果要保证数据传输的实时性，则应选用UDP协议，例如：视频传输、实时通信
  • 6、TCP传输的数据是以字节流的形式；UDP传输的形式是以数据报文段的形式
  • 7、TCP首部开销大，首部最少有20个字节；UDP首部开销小，8个字节

5、TIME_WAIT 和 CLOSE_WAIT

TIME_WAIT状态：发生在 Client端 主动关闭连接时，发送最后一个ACK（确认）报文后

CLOSE_WAIT状态：发生在 在 Sever端 收到 Client端的FIN消息（连接释放请求）并向客户端发送ACK后

TIME_WAIT出现的意义 / 为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态 ？

  • 1、可靠地关闭TCP连接
    确保客户端发送ACK后能够让服务端正常关闭，如果服务端没有收到客户端发送的ACK，服务端就会进行超时重传，向客户端重传FIN报文，如果客户端关闭了就收不到了，所以客户端要有2MSL（MSL：最大报文段生存时间）的TIME_WAIT等待时间

  • 2、2MSL能够保证本次连接的所有报文中网络中消失，避免新旧连接历史数据错乱

MSL（报文段最大生存时间）

  • 指的是报文段的最大生存时间，如果报文段在网络中活动了 MSL时间，还没有被接收，那么就会被丢弃；MSL指一个报文段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间；如果直到2MSL后，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接

为什么要等待2MSL而不是1MSL？

  • 等待 2MSL 的真正目的：让此次 TCP 连接中的所有报文在网络中消失；换句话说，为了避免（前后两个使用相同四元组的连接中的）前一个连接的报文干扰到后一个连接，

假如现在 A 发送 ACK 后，最坏情况下，这个 ACK 在 1MSL 时到达 B；此时 B 在收到这个 ACK 的前一刹那，一直在重传 FIN，这个 FIN 最坏会在 1MSL 时间内消失；因此从 A 发送 ACK 的那一刹那开始，等待 2MSL 可以保证 A 发送的最后一个 ACK，和 B 发送的最后一个 FIN 都在网络中消失

CLOSE_WAIT出现的意义？

  • 服务端在被动关闭连接情况下，在已经 接收到FIN报文 且 已回复ACK报文 ，但是还没有发送自己的FIN的时刻，Server端 处于CLOSE_WAIT状态；Server端发送FIN报文后，服务端没有收到客户端地ACK（确认）报文，那么服务端将重发FIN（连接释放请求）报文

TCP断开连接时各端地状态变化 / TIME_WAIT 和 CLOSE_WAIT是什么时候出现？

  • 1、Client端发送一个FIN报文给Server端，Client状态变为 FIN_WAIT_1
  • 2、Server端收到FIN报文后，发送一个ACK报文给Client端，Server端状态变为 CLOSE_WAIT，Client收到ACK后的状态变为 FIN_WAIT_2
  • 3、Server端也没有数据要发送后，发送了一个FIN报文给Client端，Server端状态变为 LAST_ACK
  • 4、Client端收到报文FIN后，也发送一个ACK报文给服务器。Client状态变为 TIME_WAIT，等待2MSL（若Server端未能收到ACK报文，则超时重传FIN报文，当Client再次收到FIN报文，再发送ACK报文）
  • 5、Server端收到ACK后，Server的状态变为 CLOASED
  • 6、Client等待2MSL之后，Client的状态也变为 CLOSED

6、TCP报文段

TCP报文段 分为 TCP首部 和 TCP数据 两个部分，整个TCP报文段作为IP数据报的数据部分封装在IP数据报中

  • TCP首部的最小长度是20字节；TCP报文段首部的前20个字节是固定的，后面有4N字节是根据需要而增加的选项

  • TCP首部字段：源端口、目的端口、序号、确认号、数据偏移、保留字段、紧急位URG、确认位ACK、推送位PSH、复位位RST、同步位SYN、终止位FIN、窗口字段、检验和、紧急指针字段、选项字段、填充字段

7、UDP数据报

UDP数据报包含两个部分：UDP首部 和 用户数据；整个UDP数据报作为IP数据报的数据部分封装在IP数据报中

  • UDP首部有 8个字节，由 4个字段 组成，每个字段的长度都是2个字节

UDP首部字段：源端口、目的端口、长度、校验和

  • UDP首部有 8个字节，由 4个字段 构成，每个字段都是 2个字节(Byte)
  • 1、源端口： 记录源端口号，需要对方回信时选用，告诉对方回信的 目的端口号 写什么，不需要回信时，全部置0
  • 2、目的端口：记录目的端口号，在终点交付报文的时候需要用到，将UDP数据提交给主机的某一端口
  • 3、长度：UDP数据报的长度（包括首部和数据）；实际上是UDP数据包的字节数，最小值为8（即只有首部）
  • 4、校验和：检测UDP数据报在传输中是否出错，出错则丢弃；该字段是可选的，当源主机不想计算校验和，全部置0

当传输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交给应用进程；如果接收方UDP发现收到的报文中的目的端口号 “不正确”（不存在对应端口号的应用进程），就丢弃该报文，并由ICMP发送“端口不可达”差错报文给对方

8、TCP协议如何保证可靠传输

TCP协议 保证数据传输可靠性 的方式主要有：校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制

  • 1、校验和

    • 发送方在发送数据之前 计算检验和，并进行校验和的填充；接收方在收到数据后，对数据以同样的方式进行计算，求出校验和，与填充的检验和 ** 进行比对；如果比对结果不一致，那么传输中，数据一定出错；但是如果比对结果一致**，数据不一定传输成功

  • 2、序列号和确认应答

    • 序列号(seq)：TCP传输时将每个字节的数据都进行了编号，即序列号
      序列号的作用不仅仅是应答的作用，有了序列号能够将接收到的数据根据序列号排序，并且去掉重复序列号的数据；这也是TCP传输可靠性的保证之一
    • 确认应答(ack)：TCP传输的过程中，每次接收方收到数据后，都会对传输方进行确认应答，也就是发送ACK报文；这个ACK报文当中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发

  • 3、超时重传

    • 发送方在发送完数据后等待一个指定时间，在此时间段到达没有接收到ACK报文，那么重新发送数据

  • 4、连接管理

    • 连接管理就是三次握手与四次挥手的过程，保证可靠的连接 是 保证可靠性 的前提

  • 5、流量控制

    • 流量控制就是让发送方慢点，要让接收方来得及接收；如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失

  • 6、拥塞控制

    • 拥塞控制就是防止过多的数据注入到网络中，造成 网络拥塞 的情况；若出现拥塞而不进行控制，整个网络的 吞吐量 将随输入负荷的增大而下降

9、滑动窗口 与 流量控制

TCP 利⽤ 滑动窗⼝ 实现流量控制。流量控制是为了控制发送⽅发送速率，保证接收⽅来得及接收；接收⽅发送的 确认报⽂ 中的 窗⼝字段 可以⽤来控制发送⽅窗⼝⼤⼩，从⽽影响发送⽅的发送速率；若将窗⼝字段设置为 0，则发送⽅不能发送数据

10、流量控制 与 拥塞控制

流量控制：流量控制就是让发送方慢点，要让接收方来得及接收，如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失

拥塞控制：拥塞控制就是防止过多的数据注入到网络中，造成 网络拥塞 的情况

TCP流量控制解决方法

  • TCP的流量控制是利用滑动窗口机制实现的，接收方在返回的ACK（确认）报文中会包含自己的接收窗口的大小，以 “影响” 发送方的数据发送

TCP拥塞控制解决方法

  • TCP拥塞控制的四种算法：慢开始、拥塞避免、快重传、快恢复

  • 慢开始算法：当主机开始发送数据时，并不清楚网络的负载情况，所以从1开始逐渐增大拥塞窗口，每经过一个传输轮次没有出现超时就将拥塞窗口加倍；同时还需要设置一个慢开始门限，在拥塞窗口小于慢开始门限时使用慢开始算法，大于慢开始门限时，使用拥塞避免算法；等于时，两种算法都可以；慢开始算法，并不是指拥塞窗口的增长速度“慢”，而是指拥塞窗口从一个较小的值开始增长

  • 拥塞避免算法：在拥塞窗口大于慢开始门限时，让拥塞窗口按线性规律缓慢增长；即每经过一个传输轮次，拥塞窗口增大一个MSS（最大报文段尺寸）；拥塞避免算法并非完全能够避免拥塞，只是使网络比较不容易出现拥塞

  • 快重传算法：使发送方早知道发生了个别报文段丢失，并不是出现网络拥塞；要求接收方不要等自己发送数据时才进行捎带确认，而是立即发送确认；即使收到了失序的报文段也要立即发出对已收到报文段的重复确认

  • 而发送方一旦收到三个连续的重复确认，就将相应的报文段立即重传，二不是等该报文的超时重传计时器超时再重传

  • 假设该3号报文丢失，接收方不会发送针对该报文的确认报文给发送方，发送方还可以将发送窗口内的4号数据报文段发送出去，接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段，发送方还可以将发送窗口中的5号报文段发送出去,接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段,，发送方还可以将发送窗口内的最后一个数据段即6号数据报文段发送出去，接收方收到后，发现这不是按序到达的报文段，因此给发送方发送针对2号报文段的重复确认，表明我现在希望收到的是3号报文段，但是我没有收到3号报文段，而收到了未按序到达的报文段，

  • 快恢复算法：发送方知道只有个别报文段丢失而不是网络拥塞时，不启动慢开始算法，而是执行快恢复算法，将慢开始门限和拥塞窗口值调整为当前窗口的一半，开始执行拥塞避免算法

11、在浏览器中输入url后执行的全过程，会用到哪些协议

打开⼀个⽹⻚，整个过程会使⽤哪些协议？

总体来说分为以下几个过程：

  • 1、浏览器查找域名的IP地址
    2、浏览器向web服务器发送一个HTTP请求
    3、服务器处理请求
    4、服务器返回一个HTML响应
    5、浏览器解析渲染页面

12、域名解析

域名解析是指把域名映射成为IP地址或把IP地址映射成为域名的过程；前者称为正向解析，后者称为反向解析

当客户端需要域名解析时，通过本机的DNS客户端构造一个DNS请求报文，以UDP数据报方式发往本地域名服务器

  • 1、检查浏览器缓存中是否缓存过该域名对应的IP地址
    2、如果在浏览器缓存中没有找到IP，将继续查找本机系统是否缓存过IP
    3、向本地域名服务器发起域名解析请求
    4、如果本地域名服务器的本地缓存中没有该域名对应的IP，则将DNS客户端的身份向根域名服务器发出解析请求
    5、根域名服务器收到请求后，经过判断后，将对应的顶级域名服务器的IP地址返回给本地域名服务器
    6、本地域名服务器向顶级域名服务器发出解析请求报文
    7、顶级域名服务器收到请求后，经过判断，将对应的授权域名服务器的IP地址返回给本地域名服务器
    8、本地域名服务器向授权域名服务器发起解析请求报文。
    9、授权域名服务器收到请求后，将查询结果返回给本地域名服务器。
    10、本地域名服务器将查询结果保存到本地缓存，同时返回给客户端

13、Http状态码

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用

HTTP状态码共分为5种类型

  • 1、1xx：服务器接收到请求，需要请求者继续执行操作
    2、2xx：服务器成功处理了请求
    3、3xx：重定向 （需要进一步的操作以完成请求）
    4、4xx：客户端错误 （请求包含语法错误或无法完成请求）
    5、5xx：服务器错误 （服务器在处理请求的过程中发生了错误）

常见的状态码

  • 200：表示从客户端发送给服务器的请求被正常处理并返回
    301：永久重定向
    302：临时重定向
    303：表示请求的资源被分配了新的URL，应使用Get的方法定向获取请求的资源
    302和303的区别：303明确表示客户端应当采用Get方式获取资源
    404：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用
    500：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时
    503：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求

14、HTTP和HTTPS的区别

1、Http信息是明文传输不安全，HTTPS是具有安全性的SSL加密传输协议
2、http和https使用的是完全不同的连接方式，用的端口也不一样，Http端口是80，Https端口是443
3、Http不需要申请证书，Https需要到证书颁发机构申请证书
4、Https协议是由SSL+HTTP协议构建的可进行加密传输，身份认证的网络协议，比Http协议安全
5、HTTP 安全性没有 HTTPS⾼，但是 HTTPS ⽐HTTP耗费更多服务器资源

15、get和post区别

1、Get的参数通过URL传递，Post的参数放在Request body中
2、Get的参数直接暴露再URL上，不能用来传输敏感信息，而Post较安全
3、Get请求在URL中传送的参数是有长度限制的，而Post没有
4、Get请求是幂等性的，Post请求不是幂等性的（幂等性：对同一个URL的多个请求应该返回相同的结果）
5、GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留

16、cookie和session的区别

1、cookie存放在客户端，session存放在服务端
2、cookies不安全，session是安全的
3、session依赖于cookie
4、cookie有存储容量限制，session没有（单个cookie保存的数据<=4KB，一个站点最多保存20个cookie）
5、cookie只能保存ASCII类型的数据 ,session可以保存任意类型的数据

17、转发与重定向的区别

转发（forward）：由服务端进行页面跳转；地址栏不发生变化，显示的是上一个页面的地址，只有一次请求

重定向（Redirect）：由浏览器端进行页面的跳转；地址栏显示新的地址，有2次请求

区别：
1、转发是服务器收到请求后为了完成响应跳转到一个新的地址；重定向是浏览器向服务器发送一个请求并收到响应后再次向一个新地址发出请求；转发是服务端的行为，重定向是客户端行为
2、转发请求一次，重定向至少请求两次
3、转发一次请求共享数据，重定向两次请求不共享数据
4、转发地址栏不会发生改变，重定向地址栏发生变化
5、转发只能跳转到本站点资源，重定向可以跳转到任意URL

18、HTTPS执行过程

HTTPS在传输的过程中会涉及到三个密钥：

① 服务器端的公钥和私钥，用来进行非对称加密

② 客户端生成的随机密钥，用来进行对称加密

一个HTTPS请求实际上包含了两次HTTP传输，如下图可以细分为以下8步：

1、客户端向服务器发起HTTPS请求，连接到服务器的443端口

2、服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的；服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人

3、服务器将自己的公钥发送给客户端

4、客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续

严格的说，这里应该是验证服务器发送的数字证书的合法性

如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥；然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此HTTPS中的第一次HTTP请求结束

5、客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

6、服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加 密，这样数据就变成了密文。

7、然后服务器将加密后的密文发送给客户端。

8、客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成

posted @ 2021-12-21 21:23  紫薇哥哥  阅读(226)  评论(0)  编辑  收藏  举报