当前位置: 首页 > news >正文

计算机网络知识点总结 (2)

目录

HTTP和HTTPS的区别

为什么用HTTPS

Https建立连接过程

HTTPS会加密URL吗

客户端怎么确认证书的合法性?

HTTP是无状态的?

cookie和session的区别

TCP

TCP的三次握手机制

为什么不能是四次或者是两次握手呢?

什么是泛洪攻击

三次握手每一次没收到ACK会怎么办

第二次握手返回了ACK,为什么还要返回SYN 

第三次握手是可以传输数据的

TCP四次挥手

为什么需要四次挥手?

为什么经过2MSL才进入closed状态

保活计时器

TCP报文格式

为什么说TCP可靠

TCP的流量控制

TCP滑动窗口

TCP的拥塞控制

拥塞控制的常用算法

TCP粘包拆包

TCP和UDP的区别

IP

ARP

 MAC地址和IP地址

ICMP


HTTP和HTTPS的区别

HTTPS 是 HTTP 的增强版,在 HTTP 的基础上加入了 SSL/TLS 协议,确保数据在传输过程中是加密的。

HTTP 的默认端⼝号是 80,URL 以http://开头;HTTPS 的默认端⼝号是 443,URL 以https://开头。

为什么用HTTPS

http是明文传输的,容易被窃听,数据篡改和身份伪造

SSL/TLS 在加密过程中涉及到了两种类型的加密方法:

  • 非对称加密:服务器向客户端发送公钥,然后客户端用公钥加密自己的随机密钥,也就是会话密钥,发送给服务器,服务器用私钥解密,得到会话密钥。
  • 对称加密:双方用会话密钥加密通信内容。

客户端会通过数字证书来验证服务器的身份,数字证书由 CA 签发,包含了服务器的公钥、证书的颁发机构、证书的有效期等。

Https建立连接过程

1、客户端向服务端发送请求

2、通过TCP+SSL\TLS建立连接,服务器返回自己的证书,包括公钥,颁发机构

3、确定证书没有问题,会生成一个随机码,用公钥加密这个随机码发送服务器

4、服务器用私钥解密

5、然后用解密后的会话秘钥加密通话内容进行传输

HTTPS会加密URL吗

会,https加密的是HTTP头部还有内容,url属于http的头部

客户端怎么确认证书的合法性?

证书是CA机构进行颁发的,CA机构是个受信任的第三方

HTTP是无状态的?

是无状态的,每个 HTTP 请求都是独立的,服务器不会保留任何关于客户端请求的历史信息。

由于 HTTP 是无状态的,像用户的购物车状态就必须通过其他方式来保持,如在每次请求中传递用户的 ID,或者使用 Cookie 在客户端保存购物车状态。

记录状态一用cookie,session,token

cookie和session的区别

  • Cookie 是保存在客户端的一小块文本串的数据。客户端向服务器发起请求时,服务端会向客户端发送一个 Cookie,客户端就把 Cookie 保存起来。在客户端下次向同一服务器再发起请求时,Cookie 被携带发送到服务器。服务端可以根据这个 Cookie 判断用户的身份和状态。
  • Session 指的就是服务器和客户端一次会话的过程。它是另一种记录客户状态的机制。不同的是 cookie 保存在客户端浏览器中,而 session 保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上,这就是 session。客户端浏览器再次访问时只需要从该 session 中查找用户的状态。
  • 存储位置不一样,Cookie 保存在客户端,Session 保存在服务器端。
  • 存储数据类型不一样,Cookie 只能保存 ASCII,Session 可以存任意数据类型,一般情况下我们可以在 Session 中保持一些常用变量信息,比如说 UserId 等。
  • 有效期不同,Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般有效时间较短,客户端关闭或者 Session 超时都会失效。
  • 隐私策略不同,Cookie 存储在客户端,比较容易遭到不法获取,早期有人将用户的登录名和密码存储在 Cookie 中导致信息被窃取;Session 存储在服务端,安全性相对 Cookie 要好一些。
  • 存储大小不同, 单个 Cookie 保存的数据不能超过 4K,Session 可存储数据远高于 Cookie。

TCP

TCP的三次握手机制

①、第一次握手:SYN(最开始都是 CLOSE,之后服务器进入 LISTEN)

  • 发起连接:客户端发送一个 TCP 报文段到服务器。这个报文段的头部中,SYN 位被设置为 1,表明这是一个连接请求。同时,客户端会随机选择一个序列号(Sequence Number),假设为 x,发送给服务器。
  • 目的:客户端通知服务器它希望建立连接,并告知服务器自己的初始序列号。
  • 状态:客户端进入 SYN_SENT 状态。

②、第二次握手:SYN + ACK

  • 确认并应答:服务器收到客户端的连接请求后,如果同意建立连接,它会发送一个应答 TCP 报文段给客户端。在这个报文段中,SYN 位和 ACK 位都被设置为 1。服务器也会选择自己的一个随机序列号,假设为 y,并将客户端的序列号加 1(即 x+1)作为确认号(Acknowledgment Number),发送给客户端。
  • 目的:服务器告诉客户端,它的连接请求被接受了,并通知客户端自己的初始序列号。
  • 状态:服务器进入 SYN_RCVD 状态。

③、第三次握手:ACK

  • 最终确认:客户端收到服务器的应答后,还需要向服务器发送一个确认。这个 TCP 报文段的 ACK 位被设置为 1,确认号被设置为服务器序列号加 1(即 y+1),而自己的序列号是 x+1。
  • 目的:客户端确认收到了服务器的同步应答,完成三次握手,建立连接。
  • 状态:客户端进入 ESTABLISHED 状态,当服务器接收到这个包时,也进入 ESTABLISHED 状态

SYN 不仅确保了序列号的同步,使得后续的数据能够有序传输,还能防止旧的报文段被误认为是新连接。

为什么不能是四次或者是两次握手呢?

  • 为了防止服务器一直等,等到黄花菜都凉了。
  • 为了防止客户端已经失效的连接请求突然又传送到了服务器。

三次已经可以建立可靠的连接了,就不需要四次了

什么是泛洪攻击

泛洪攻击(SYN Flood Attack)是一种常见的 DoS(拒绝服务)攻击,攻击者会发送大量的伪造的 TCP 连接请求,导致服务器资源耗尽,无法处理正常的连接请求。

半连接服务拒绝,也称为 SYN 洪泛攻击或 SYN Flood。

所谓的半连接就是指在 TCP 的三次握手过程中,当服务器接收到来自客户端的第一个 SYN 包后,它会回复一个 SYN-ACK 包,此时连接处于“半开”状态,因为连接的建立还需要客户端发送最后一个 ACK 包。

在收到最后的 ACK 包之前,服务器会为这个尚未完成的连接分配一定的资源,并在它的队列中保留这个连接的位置。、

三次握手每一次没收到ACK会怎么办

超时重传机制

第二次握手返回了ACK,为什么还要返回SYN 

ACK 是为了告诉客户端传来的数据已经接收无误。

而传回 SYN 是为了告诉客户端,服务端响应的确实是客户端发送的报文。

第三次握手是可以传输数据的

TCP四次挥手

第一次挥手:客户端向服务器发送一个 FIN 结束报文,表示客户端没有数据要发送了,但仍然可以接收数据。客户端进入 FIN-WAIT-1 状态。

第二次挥手:服务器接收到 FIN 报文后,向客户端发送一个 ACK 报文,确认已接收到客户端的 FIN 请求。服务器进入 CLOSE-WAIT 状态,客户端进入 FIN-WAIT-2 状态。

第三次挥手:服务器向客户端发送一个 FIN 报文,表示服务器也没有数据要发送了。服务器进入 LAST-ACK 状态。

第四次挥手:客户端接收到 FIN 报文后,向服务器发送一个 ACK 报文,确认已接收到服务器的 FIN 请求。客户端进入 TIME-WAIT 状态,等待一段时间以确保服务器接收到 ACK 报文。服务器接收到 ACK 报文后进入 CLOSED 状态。客户端在等待一段时间后也进入 CLOSED 状态。

为什么需要四次挥手?

因为 TCP 是全双工通信协议,数据的发送和接收需要两次一来一回,也就是四次,来确保双方都能正确关闭连接。

  1. 第一次挥手:客户端表示数据发送完成了,准备关闭,你确认一下。
  2. 第二次挥手:服务端回话说 ok,我马上处理完数据,稍等。
  3. 第三次挥手:服务端表示处理完了,可以关闭了。
  4. 第四次挥手:客户端说好,进入 TIME_WAIT 状态,确保服务端关闭连接后,自己再关闭连接。

为什么经过2MSL才进入closed状态

1. 为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 

1. 为了保证客户端发送的最后一个 ACK 报文段能够到达服务端。 这个 ACK 报文段有可能丢失,因而使处在 LAST-ACK 状态的服务端就收不到对已发送的 FIN + ACK 报文段的确认。服务端会超时重传这个 FIN+ACK 报文段,而客户端就能在 2MSL 时间内(超时 + 1MSL 传输)收到这个重传的 FIN+ACK 报文段。接着客户端重传一次确认,重新启动 2MSL 计时器。最后,客户端和服务器都正常进入到 CLOSED 状态。

2. 防止已失效的连接请求报文段出现在本连接中。客户端在发送完最后一个 ACK 报文段后,再经过时间 2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

MSL 是 Maximum Segment Lifetime,报⽂最⼤⽣存时间,它是任何报⽂在⽹络上存在的最⻓时间,超过这个时间报⽂将被丢弃。

保活计时器

就是防止服务器一直等待,每有一个请求就会重新更新保活计时器,如果长时间没有请求,超过了保活计时器,就认为客户端不工作了关闭这个连接

         CLOSEWAIT 和TIMEWAIT

服务端收到客户端关闭连接的请求并确认之后,就会进入 CLOSE-WAIT 状态。此时服务端可能还有一些数据没有传输完成,因此不能立即关闭连接,而 CLOSE-WAIT 状态就是为了保证服务端在关闭连接之前将待发送的数据处理完。

  • 在 TIME_WAIT 状态中,客户端可以重新发送 ACK 确保对方正常关闭连接。
  • 在 TIME_WAIT 持续的 2MSL 时间后,确保旧数据包完全消失,避免它们干扰未来建立的新连接

TCP报文格式

为什么说TCP可靠

校验和 

TCP 报文段包括一个校验和字段,用于检测报文段在传输过程中的变化。如果接收方检测到校验和错误,就会丢弃这个报文段。

序列号/确认机制:TCP 将数据分成多个小段,每段数据都有唯一的序列号,以确保数据包的顺序传输和完整性。同时,发送方如果没有收到接收方的确认应答,会重传数据。

流量控制:接收方会发送窗口大小告诉发送方它的接收能力。发送方会根据窗口大小调整发送速度,避免网络拥塞。

超时重传:如果发送方发送的数据包超过了最大生存时间,接收方还没有收到,发送方会重传数据包以保证丢失数据重新传输。

拥塞控制:TCP 会采用慢启动的策略,一开始发的少,然后逐步增加,当检测到网络拥塞时,会降低发送速率。在网络拥塞缓解后,传输速率也会自动恢复。

TCP的流量控制

TCP 提供了一种机制,可以让发送端根据接收端的实际接收能力控制发送的数据量,这就是流量控制

TCP滑动窗口

TCP 引入了窗口,它是操作系统开辟的一个缓存空间。窗口大小值表示无需等待确认应答,而可以继续发送数据的最大值。 

TCP 头部有个字段叫 win,也即那个 16 位的窗口大小,它告诉对方本端的 TCP 接收缓冲区还能容纳多少字节的数据,这样对方就可以控制发送数据的速度,从而达到流量控制的目的。

TCP 滑动窗口分为两种: 发送窗口和接收窗口。发送端的滑动窗口包含四大部分,如下:

  • 已发送且已收到 ACK 确认
  • 已发送但未收到 ACK 确认
  • 未发送但可以发送
  • 未发送也不可以发送

  • 深蓝色框里就是发送窗口。
  • SND.WND: 表示发送窗口的大小, 上图虚线框的格子数是 10 个,即发送窗口大小是 10。
  • SND.NXT:下一个发送的位置,它指向未发送但可以发送的第一个字节的序列号。
  • SND.UNA: 一个绝对指针,它指向的是已发送但未确认的第一个字节的序列号。

接收方的滑动窗口包含三大部分,如下:

  • 已成功接收并确认
  • 未收到数据但可以接收
  • 未收到数据并不可以接收的数据

 

  • 蓝色框内,就是接收窗口。
  • REV.WND: 表示接收窗口的大小, 上图虚线框的格子就是 9 个。
  • REV.NXT: 下一个接收的位置,它指向未收到但可以接收的第一个字节的序列号。

TCP的拥塞控制

流量控制是为了避免发送⽅的数据填满接收⽅的缓存

当⽹络出现拥堵时,如果继续发送⼤量数据包,可能会导致数据包延时、丢失等,这时 TCP 就会重传数据,但重传会增加⽹络负担,于是会导致更⼤的延迟以及更多的丢包,就进⼊了恶性循环....

所以,TCP 被设计成了⼀个非常⽆私的协议,当⽹络发送拥塞时,TCP 会⾃我牺牲,降低发送的数据流。

拥塞控制的⽬的就是避免发送⽅的数据填满整个⽹络。

拥塞窗口cwnd是发送⽅维护的⼀个的状态变量,它会根据⽹络的拥塞程度动态变化的。、

拥塞控制的常用算法

  • 慢启动
  • 拥塞避免
  • 拥塞发生
  • 快速恢复

 

①、慢启动算法

慢启动算法,慢慢启动。

它表示 TCP 建立连接完成后,一开始不要发送大量的数据,而是先探测一下网络的拥塞程度。由小到大逐渐增加拥塞窗口的大小,如果没有出现丢包,每收到一个 ACK,就将拥塞窗口 cwnd 大小就加 1(单位是 MSS)每轮次发送窗口增加一倍,呈指数增长,如果出现丢包,拥塞窗口就减半,进入拥塞避免阶段。

②、拥塞避免算法

一般来说,慢启动阀值 ssthresh 是 65535 字节,cwnd到达慢启动阀值

  • 每收到一个 ACK 时,cwnd = cwnd + 1/cwnd
  • 当每过一个 RTT 时,cwnd = cwnd + 1

显然这是一个线性上升的算法,避免过快导致网络拥塞问题。

③、拥塞发生

当网络拥塞发生丢包时,会有两种情况:

RTO 超时重传 快速重传 如果是发生了 RTO 超时重传,就会使用拥塞发生算法

慢启动阀值 sshthresh = cwnd /2 cwnd 重置为 1 进入新的慢启动过程

其实还有更好的处理方式,就是快速重传。发送方收到 3 个连续重复的 ACK 时,就会快速地重传,不必等待 RTO 超时再重传。

发⽣快速重传的拥塞发⽣算法:

  • 拥塞窗口大小 cwnd = cwnd/2
  • 慢启动阀值 ssthresh = cwnd
  • 进入快速恢复算法

④、快速恢复

快速重传和快速恢复算法一般同时使用。快速恢复算法认为,还有 3 个重复 ACK 收到,说明网络也没那么糟糕,所以没有必要像 RTO 超时那么强烈。

正如前面所说,进入快速恢复之前,cwnd 和 sshthresh 已被更新:

  • cwnd = cwnd /2
  • sshthresh = cwnd

然后,进⼊快速恢复算法如下:

  • cwnd = sshthresh + 3
  • 重传重复的那几个 ACK(即丢失的那几个数据包)
  • 如果再收到重复的 ACK,那么 cwnd = cwnd +1
  • 如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK,表明恢复过程已经结束,可以再次进入了拥塞避免的算法了。

TCP粘包拆包

TCP 是面向流,没有界限的一串数据。TCP 底层并不了解上层业务数据的具体含义,它会根据 TCP 缓冲区的实际情况进行包的划分,所以在业务上认为,一个完整的包可能会被 TCP 拆分成多个包进行发送也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的 TCP 粘包和拆包问题。

  • 要发送的数据小于 TCP 发送缓冲区的大小,TCP 将多次写入缓冲区的数据一次发送出去,将会发生粘包;
  • 接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包;
  • 要发送的数据大于 TCP 发送缓冲区剩余空间大小,将会发生拆包;
  • 待发送数据大于 MSS(最大报文长度),TCP 在传输前将进行拆包。即 TCP 报文长度 - TCP 头部长度 > MSS。

TCP和UDP的区别

TCP 是面向连接的,而 UDP 是无连接的。

  • TCP: 适用于那些对数据准确性要求高于数据传输速度的场合。例如:网页浏览、电子邮件、文件传输(FTP)、远程控制、数据库链接。
  • UDP: 适用于对速度要求高、可以容忍一定数据丢失的场合。例如:QQ 聊天、在线视频、网络语音电话、广播通信。容忍一定的数据丢失。

IP

①、寻址:每个连接到网络的设备都有一个唯一的 IP 地址。IP 协议使用这些地址来标识数据包的源地址和目的地址,确保数据包能够准确地传输到目标设备。

②、路由:IP 协议负责决定数据包在网络传输中的路径。比如说路由器使用路由表和 IP 地址信息来确定数据包的最佳传输路径。

③、分片和重组:当数据包过大无法在某个网络上传输时,IP 协议会将数据包分成更小的片段进行传输。接收端会根据头部信息将这些片段重新组装成完整的数据包。

一个 IP 地址在这鞥个互联网范围内是惟一的,一般可以这么认为,IP 地址 = {<网络号>,<主机号>}。

ARP

ARP(Address Resolution Protocol,地址解析协议)是网络通信中的一种协议,主要目的是将网络层的 IP 地址解析为链路层的 MAC 地址。

 MAC地址和IP地址

  • MAC 地址是数据链路层和物理层使用的地址,是写在网卡上的物理地址,用来定义网络设备的位置,不可变更。
  • IP 地址是网络层和以上各层使用的地址,是一种逻辑地址。IP 地址用来区别网络上的计算机。

ICMP

ICMP(Internet Control Message Protocol) ,网际控制报文协议。

  • ICMP 协议是一种面向无连接的协议,用于传输出错报告控制信息。
  • 它是一个非常重要的协议,它对于网络安全具有极其重要的意义。它属于网络层协议,主要用于在主机与路由器之间传递控制信息,包括报告错误、交换受限控制和状态信息等。
  • 当遇到 IP 数据无法访问目标、IP 路由器无法按当前的传输速率转发数据包等情况时,会自动发送 ICMP 消息。

比如我们日常使用得比较多的 ping,就是基于 ICMP 的。

http://www.xdnf.cn/news/1181557.html

相关文章:

  • go语言基础教程:1. Go 下载安装和设置
  • Java网络编程入门:从基础原理到实践(二)
  • 算法第三十八天:动态规划part06(第九章)
  • uboot FPGA调试环境搭建
  • io_uring:Linux异步I/O的革命性突破
  • 星慈光编程虫2号小车讲解第四篇--触摸按键
  • 平时遇到的错误码及场景?404?400?502?都是什么场景下什么含义,该怎么做 ?
  • vue3核心语法
  • (进阶向)Python第十四期OpenCv图像预处理方法[2]
  • 跨境支付入门~国际支付结算(稳定币)
  • 深度分析Java多线程机制
  • AI实践:Pydantic
  • Spring之SSM整合流程详解(Spring+SpringMVC+MyBatis)
  • 【Linux】常用命令(一)
  • 洛谷P1512 伊甸园日历游戏
  • SQL基础⑫ | 视图篇
  • C++ - 仿 RabbitMQ 实现消息队列--服务端核心模块实现(三)
  • 基于深度学习的图像分类:使用MobileNet实现高效分类
  • Python进阶第三方库之Matplotlib
  • 深度学习(鱼书)day01--感知机
  • LeetCode 23:合并 K 个升序链表
  • 【C++】使用中值滤波算法过滤数据样本中的尖刺噪声
  • rust-方法语法
  • C++STL系列之set和map系列
  • 基于python django的农业可视化系统,以奶牛牧场为例
  • 用 Function Call 让 AI 主动调用函数(超入门级示例)|保姆级大模型应用开发实战
  • SpringBoot航空订票系统的设计与实现
  • 进阶系统策略
  • 技术赋能多元探索:我的技术成长与行业洞察
  • Linux应用开发基础知识——进程学习2(exec函数、system函数、popen函数)(三)