目录
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 是全双工通信协议,数据的发送和接收需要两次一来一回,也就是四次,来确保双方都能正确关闭连接。
- 第一次挥手:客户端表示数据发送完成了,准备关闭,你确认一下。
- 第二次挥手:服务端回话说 ok,我马上处理完数据,稍等。
- 第三次挥手:服务端表示处理完了,可以关闭了。
- 第四次挥手:客户端说好,进入 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 的。