经典网络分层?
通常情况下分为TCP/IP五层协议和OSI七层协议,其中TCP/IP五层协议自下往上可以分为:物理层、数据链路层、网络层、传输层以及应用层,而OSI七层协议是把TCP/IP协议中的应用层分为了会话层、表示层和应用层
在浏览器的地址栏中输入URL,后续的网络世界发生了什么?
-
解析URL,用DNS服务来确定Web服务器和文件名
-
解析DNS,先用DNS服务器查询服务器域名对应的IP地址
-
根据解析到的信息生成http请求,TCP通过三次握手建立连接。
-
如果使用的是https协议,会进行对数据进行加密,然后再通过TCP的三次握手进行建立连接。
-
通过传输层,在头部添加TCP首部
-
通过网络层,添加报文头(报文头里包含了发送方和接收方的IP地址)
-
通过数据链路层,添加MAC头部(包含了发送方和接收方的MAC地址等信息,用于两点之间的传输)
-
通过网卡转换信号(二进制数字信息 —>电信号)在网线上传输、通过交换机(电信号—>数字信号)、再经过路由器,最终到达服务器,服务器会一层层扒开数据的外层,返回用户需要的信息,数据会再倒着走一遍,一步一步的返给发送端。
-
最后当浏览器全部解析完服务器发送的响应之后,向服务器发起TCP的四次挥手,断开连接。
什么是DNS服务?使用的是UDP协议 Ping命令
DNS(Domain Name System)是互联网中用于将域名(例如www.example.com)转换为IP地址的分布式命名系统。它充当了互联网的电话簿,帮助用户在浏览器中输入域名时找到对应的服务器IP地址,DNS使用的是UDP协议。
-
客户端发出一个DNS请求,查询URL的IP地址,并发给本地DNS服务器
-
本地域名服务器收到客户端的请求后,先查看缓存里的表格能否找到URL,如果有直接返回IP地址,如果没有,本地DNS就会去查询根域名服务器(由于根域名服务器是最高层次的,它不直接用于解析域名)
-
根域名服务器收到请求后,会根据URL的顶级域名提供所对应的顶级域名服务器的地址
-
顶级域名服务器提供权威DNS服务器的地址
-
本地DNS服务器得到地址后,访问权威DNS服务器,权威DNS服务器查询对应的IP地址,返回给本地DNS服务器
-
最后本地DNS服务器将IP地址返回给客户端,客户端与目标建立连接
TCP和UDP有什么特点和区别?
TCP和UDP工作在传输层,是用来对数据可靠传输 和通信
TCP的主要特点:
-
面向连接 :TCP协议会将通信双方建立起连接
-
如何做链接管理的?通过TCP三次握手来建立连接、通过TCP四次挥手来断开连接
-
重传机制有哪些?
-
超时重传:发送数据时设定一个定时器,当超过指定的时间后,没有收到对方的ACK确认应答报文,就会重新发该数据。超时周期是动态变化的,会出现超时周期相对较长的情况。于是就出现了快速重传。
-
快速重传:当发送方收到三个相同的ACK报文时,会在定时器过期之前,重传丢失及丢失之后的所有数据包。会出现重传没有收到的数据还是重传没有收到数据之后的所有数据?
-
SACK(选择确认性):在TCP的头部选项里添加一个SACK,让发送方知道哪些数据没有被成功收到,可以只重传没有收到的数据
-
D-SACK:优化了SACK
-
可以让发送方知道是发送的包丢失了,还是接收方返回的ACK包丢失了
-
可以知道是不是发送方发送的包是不是被网络延迟了
-
可以知道网络中是不是把发送方的数据包给复制了
-
-
-
-
可靠的:TCP是一种可靠的传输协议,通过使用确认和重传机制来确保数据可靠性
-
面向字节流
-
怎么保证数据的有序性?给每个数据编上序列号,并且发送总数据长度及每个数据的长度,从而来确定数据是否有序,有便于传输后的确认及丢失后重传不会出现乱序。
-
粘包问题
粘包问题指服务端接收多个数据包时,无法区分这些数据包的边界,导致解析错误。
解决方法:一般通过固定消息的长度、用特殊字符作为边界、使用自定义消息结构三种方式来进行分包
-
TCP传输数据时,可靠性比较高,但是传输效率比较慢所以TCP主要用于上传下载、HTTP请求、文件传输等场景
UDP的主要特点:
-
无连接
-
不可靠
-
面向报文
UDP相比于TCP的传输速度更快,但不保证传输的结果(不关心传送的消息是否成功被接收),所以它主要用于音频/视频的通话、实时游戏等场景
TCP如何实现拥塞控制和流量管理的?
流量管理:TCP提供的一种机制,它可以让【发送方】根据【接收方】的实际接收能力来控制发送的信息量,减少了接收端的压力。
-
滑动窗口机制:给发送方和接收方都分配一个动态窗口缓冲区,发送方和接收方通过窗口来进行信息的交互。发送方可以一次性发送多个包,接收方可以从窗口中取数据。并且【发送方】是根据【接收方】缓存窗口可接受的数据量而发送数据包的。解决了发送方一次只能发送一个包的问题以及缓解了接收方的压力。
拥塞控制:避免【发送方】的数据填满整个网络
-
慢启动
-
拥塞避免
-
拥塞发生
-
快速恢复
如何实现一个可靠的UDP?
可以在UDP的底层实现一些TCP的机制,例如基于UDP的QUIC协议可以实现类似TCP的可靠性传输
TCP的三次握手?期间用户端和服务端分别处于什么状态?
客户端:closed(关闭状态)、服务端:closed(关闭状态)
第一步:客户端发送SYN(包)给服务端。这个包包含了客户端的初始序列号以及请求建立连接的标志位(SYN=1)
客户端:SYN_SENT(同步已发送状态)、服务端:LISTEN(监听状态)
第二步:服务端接收到SYN包后,会发送一个SYN/ACK(同步/确认)包给客户端。这个包包含了服务器的初始序列号以及对客户端的请求建立连接的确认。
客户端:SYN_SENT(同步已发送状态)、服务端:SYN_RCVD(同步已接收状态)
第三步:客户端收到SYN/ACK包后,会发送一个ACK(确认)包给服务器,确认服务器的请求建立连接。此时连接已经建立,客户端和服务器可以开始进行数据传输。
客户端:ESTABLISHED(已建立连接状态)、服务端:ESTABLISHED(已建立连接状态)
通过三次握手,客户端和服务器就建立了可靠的连接。这种机制可以确保双方都同意建立连接,并且可以互相确认对方的请求和确认。
为什么TCP是三次握手,而不是两次或四次?
反证法:两次太少,不能保证可靠的连接,并且可能造成SYN超时问题、四次太多,会造成资源浪费。
SYN超时和泛洪攻击是什么?解决策略有哪些?
SYN超时:在TCP三次握手过程中,当服务器接收到客户端发送的SYN包后,会发送一个SYN/ACK包作为响应。但是如果客户端在一定时间内没有收到服务器的响应,就会认为连接建立失败,这个时间就成为SYN超时。SYN超时可能由网络延迟、拥塞或网络故障等原因引起的。
泛洪攻击:泛洪攻击是一种网络攻击方式,攻击者通过发送大量的伪造源IP地址的SYN请求包给目标服务器,目的是耗尽服务器的资源,
当服务器接收到大量的伪造SYN请求后,会为每一个请求分配资源并等待客户端发送ACK包进行确认。由于伪造的源IP地址,服务器无法收到ACK包,这就导致服务器资源被大量占用,无法正常服务其他合法的请求。
解决策略:
-
SYN超时解决策略
-
增加SYN超时时间
-
优化网络连接
-
加强服务器性能
-
-
泛洪攻击解决策略
-
使用防火墙
-
启用SYN Cookie
-
IP过滤和限制
-
使用负载均衡
-
增加服务器资源
-
第三次握手时,发送方可以带其他数据吗?
可以带其他数据。但是根据TCP协议的规定,第三次握手时不会携带其他数据。第三次握手知识用于确认连接的建立,并不包含其他应用层数据。
TCP的四次挥手?期间用户端和服务端分别处于什么状态?
客户端:ESTABLISHED(已建立连接状态)、服务端:ESTABLISHED(已建立连接状态)
第一步:当客户端想要关闭连接时,它发送一个FIN(结束)包给服务器,表示不再发送数据给服务端了。
客户端:FIN_WAIT_1(终止等待状态1)、服务端:CLOSE_WAIT(关闭等待状态)
第二步:服务端收到FIN包后,发送一个ACK包给客户端,确认收到了客户端的关闭请求,但是可能还有一些数据没有处理完
客户端:FIN_WAIT_2(终止等待状态2)、服务端:LAST_ACK(最后确认状态)
第三步:服务器发送一个FIN包给客户端,表示服务器也准备关闭连接
客户端:TIME_WAIT(时间等待状态)、服务端:CLOSED(关闭状态)
第四步:客户端收到FIN包后,发送一个ACK包给服务器,确认收到了服务器的关闭请求,此时连接关闭
关闭连接后是立马断开的吗?
不是。在四次挥手完成后,连接会进入TIME_WAIT状态,这个状态会持续一段时间(通常是2倍的MSL,即最大报文寿命),用来确保在网络中所有的数据包都已经被正常接收。在TIME_WAIT状态结束后,连接才会完全关闭,资源被释放。
为什么需要四次挥手?讲讲time_wait和close_wait。
TCP连接是双向传输数据的,当有一方需要断开连接时,会发送一个FIN包,对方回复一个ACK包,一个方向上的连接关闭了,双向就需要两个FIN-ACK包才能完成断开连接操作,故需要四次挥手操作。
time_wait:表示一个连接已经完成了关闭状态,并且在等待最后的确认报文。
主要有两个作用:
-
防止上一次连接中的延迟或重复的数据包被下一次复用连接错误 的接收
-
确保被动关闭方能在规定时间内正常关闭连接
如果没有time_wait状态或者time_wait的时间太短,就可能导致数据错乱或者连接失败
close_wait:表示对方已经发送了关闭连接的请求,等待本端应用程序也关闭连接。
主要作用:
-
为了让应用程序有机会处理完剩余的数据,并主动关闭连接。
如果没有应用程序没有及时调用close()操作,就可能导致大量的close_wait主状态积累,占用系统资源
TCP的保活机制Keepalive
如果两端的 TCP 连接一直没有数据交互,达到了触发 TCP 保活机制的条件,那么内核里的 TCP 协议栈就会发送探测报文。
-
如果对端程序是正常工作的。当 TCP 保活的探测报文发送给对端, 对端会正常响应,这样 TCP 保活时间会被重置,等待下一个 TCP 保活时间的到来。
-
如果对端主机宕(dàng)机(死机)(注意不是进程崩溃,进程崩溃后操作系统在回收进程资源的时候,会发送 FIN 报文,而主机宕机则是无法感知的,所以需要 TCP 保活机制来探测对方是不是发生了主机宕机),或对端由于其他原因导致报文不可达。当 TCP 保活的探测报文发送给对端后,石沉大海,没有响应,连续几次,达到保活探测次数后,TCP 会报告该 TCP 连接已经死亡。
HTTP与HTTPS有哪些区别?
-
HTTP是超文本传输协议,信息是明文传输的,存在安全风险问题;HTTPS解决了HTTP不安全的缺陷,在TCP和HTTP网络层之间加入了SSL/TLS安全协议,信息能够加密传输。
-
HTTPS可以防止DNS的攻击,HTTP更容易受 到攻击
-
HTTP默认端口是80;https默认端口是443。
-
HTTPS协议需要想CA认证机构申请SSL证书,来保证服务器的身份是可信的,HTTP不用。所以HTTPS的速度会略慢一些
什么是SSL协议?
SSL协议是一种用于保护网络通信安全的加密协议,位于传输层之上,主要用于在客户端和服务端之间的加密连接以及确认服务器和客户端的身份,保证数据在传输中的完整性和保密性
HTTPS如何优化TCP三次握手的?
-
添加TLS/SSL握手过程:确保数据传输的完整性和保密性
-
会话复用:将首次TLS/SSL捂手协商的对称加密秘钥缓存起来,待下次需要建立连接时,直接复用这个秘钥,减少性能损耗。
-
持久连接:HTTPS可以使用HTTP的持久连接来减少TCP的建立与关闭次数,从而提高性能
HTTPS就真的安全吗?
不一定。客户端通过浏览器向服务器发起HTTPS请求时,可能会被假基站获取全部信息,再由假基站和服务器完成TLS握手,从而导致信息泄露。
解决方法:假基站给服务端发送信息时用的是伪造的证书,这个证书是可以被客户端识别出非法的,只要客户端拒接接受假基站的证书就不会被假基站监听信息了。
HTTP几个版本中的变化
HTTP/1.1
-
使用了长连接(Keep-Alive)(用户态实现的)方式改善了1.0版本短连接造成的性能开销问题
-
支持管道网络传输,只要第一个请求发送出去就可以发送第二个请求,减少响应时间
但存在以下问题:
-
请求 / 响应头部(Header)未经压缩就发送,首部信息越多延迟越大。只能压缩
Body
的部分; -
发送冗长的首部。每次互相发送相同的首部造成的浪费较多;
-
服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据,也就是队头阻塞;
-
没有请求优先级控制;
-
请求只能从客户端开始,服务器只能被动响应。
HTTP/2
-
头部压缩,降低了延迟
-
二进制格式,便于传输
-
并发传输,提高传输效率
-
服务器主动推送资源,减少相应时间
HTTP/3
-
把HTTP下层的TCP协议改成了UDP协议,解决了队头阻塞的问题
GET和POST有哪些区别?
-
GET主要是用于获取资源,POST主要是用于提交资源
-
数据位置:GET请求是把请求数据附加在URL的查询字符串中;而POST请求是把请求数据放到消息体中,作为请求的一部分
-
请求数据长度限制:GET请求对URL长度有限制,一般在几千字符左右;POST请求对请求数据长度没有限制
-
数据类型:GET的请求数据是通过键值对以明文形式出现在URL中;POST的请求数据是隐藏在消息体中,更加安全
-
数据语义:GET请求是具有幂等性的,即使重复请求多次也不会对服务器产生影响,只是获取数据,可以被缓存;POST请求不具有幂等性,当创建、更新、产出数据时会对服务器产生影响,不适合被缓存
-
安全性:GET请求适合用于获取数据,参数暴露在URL中,容易被拦截、篡改,不安全;POST请求把请求数据放在消息体中,更加安全
什么是幂等性?哪个请求具有天生的幂等性?
幂等性是指对同一个操作的多次重复执行所产生的效果与执行一次的效果相同。GET先天具有幂等性