目录
1.常说的四层、五层、七层网络模型有什么区别?
2.TCP/IP 网络模型中的五层模型,每层分别有什么用?
3.介绍一下 HTTP 协议
8.HTTPS 和 HTTP 的区别是什么?
10.HTTP3 和 HTTP2 的区别是什么?
11.TCP 建立连接的过程是怎样的?
12.为什么是三次握手???
13.TCP 断开连接的过程是怎样的?
14.第四次挥手为什么要等待2MSL(60s)
15.为什么是四次挥手?
16.TCP 滑动窗⼝是什么?
17.发送方一直发送数据,但是接收方处理不过来怎么办?(流量控制)
18.TCP 半连接队列和全连接队列是什么?
19.粘包/拆包是怎么发生的?怎么解决这个问题?
20.浏览器地址栏输入网站按回车后发生了什么?
21、https的请求过程?
22、TCP是如何保证可靠性的
23、对称加密和非对称加密的区别?
24、websoket和http的区别?
25、Websoket是什么?
26、什么是AUTH2.0协议?有哪几种认证方式?什么是JWT令牌?和普通令牌有什么区别?
27、什么是SSO?
28、什么是认证和授权?如何设计一个权限认证框架?
TCP与UDP区别总结
Cookies和session区别
HTTPS和HTTP的区别
http长连接和短连接的区别
HTTPS是如何保证安全传输的
常见的 Web 攻击
重要协议分布图
TCP/IP模型原为四层,而TCP/IP五层模型实际上是TCP/IP与OSI七层模型的混合后的产物。说到底,这些模型的出现目的是为了使大家都使用统一的协议(通信规则)来通信。可以看到,五层模型和七层模型在物理层、数据链路层、网络层、传输层都用的是相同的协议,他们是统一的。不同点只在于应用层部分。应用程序复杂多变,比如电子邮件用的是SMTP协议、WEB服务器用HTTP协议。应用程序可以根据自己的需求特点,来使用各种不同的协议。而五层模型和七层模型在应用层的理念各有优劣,也因此在不同的协议中得到实现。
TCP/IP协议是互联网协议(簇)的统称,他是互联网标准通信的基础,它提供点对点的链接机制,将数据应该如何封装、定址、传输、路由以及在目的地如何接收,都加以标准化。而OSI模型是开放式系统互联通信参考模型——笔者的理解是:
OSI是一个完整的、完善的宏观模型,他包括了硬件层(物理层),当然也包含了很多上面途中没有列出的协议(比如DNS解析协议等);而TCP/IP(参考)模型,更加侧重的是互联网通信核心(也是就是围绕TCP/IP协议展开的一系列通信协议)的分层,因此它不包括物理层,以及其他一些不想干的协议;其次,之所以说他是参考模型,是因为他本身也是OSI模型中的一部分,因此参考OSI模型对其分层。
TCP/IP网络模型总共有五层
1.应用层:我们能接触到的就是应用层了,手机,电脑这些这些设备都属于应用层。
2.传输层:就是为应用层提供网络支持的,当设备作为接收⽅时,传输层则要负责把数据包传给应⽤,但是⼀台设备上可能会有很多应⽤在接收或者传输数据,因此需要⽤⼀个编号将应⽤区分开来,这个编号就是端⼝。所以 TCP 和 UDP 协议就是在这一层的
3.网络层:是负责传输数据的,最常使用的 ip 协议就在该层,⽹络层负责将数据从⼀个设备传输到另⼀个设备,世界上有很多设备,⽹络层需要有区分设备的编号。我们⼀般⽤ IP 地址给设备进⾏编号
4.数据链路层:每⼀台设备的⽹卡都会有⼀个 MAC 地址,它就是⽤来唯⼀标识设备的。路由器计算出了下⼀个⽬的地 IP 地址,再通过 ARP 协议找到该⽬的地的 MAC 地址,这样就知道这个 IP 地址是哪个设备的了。路由器就是通过数据链路层来知道这个 ip 地址是属于哪个设备的,它主要为⽹络层提供链路级别传输的服务。
5.物理层:当数据准备要从设备发送到⽹络的时候,需要把数据包转换成电信号,让其可以在物理介质中传输,它主要是为数据链路层提供⼆进制传输的服务。
HTTP 协议是基于 TCP 协议实现的,它是一个超文本传输协议,其实就是一个简单的请求-响应协议,它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。它主要是负责点对点之间通信的。超文本就是用超链接的方法,将各种不同空间的文字信息组织在一起的网状文本。比如说html,内部定义了很多图片视频的链接,放在浏览器上就呈现出了画面。
4.GET 和 POST有什么区别?
GET 和 POST 本质上就是 TCP 链接,并无差别。
1.SSL安全协议
HTTP 是超⽂本传输协议,信息是明⽂传输,存在安全⻛险的问题。
HTTPS 则解决 HTTP 不安全的缺陷,在TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 安全协议,使得报⽂能够加密传输。
2.建立连接
HTTP 连接建⽴相对简单, TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。
HTTPS 在 TCP 三次握⼿之后,还需进⾏ SSL/TLS 的握⼿过程,才可进⼊加密报⽂传输。
3.端口号
HTTP 的端⼝号是 80。
HTTPS 的端⼝号是 443。
4.CA证书
HTTPS 协议需要向 CA(证书权威。机构)申请数字证书来保证服务器的身份是可信的。
1.协议不同
HTTP2 是基于 TCP 协议实现的
HTTP3 是基于 UDP 协议实现的
2.QUIC
HTTP3 新增了 QUIC 协议来实现可靠性的传输
3.握手次数
HTTP2 是基于 HTTPS 实现的,建立连接需要先进行 TCP 3次握手,然后再进行 TLS 3次握手,总共6次握手
HTTP3 只需要 QUIC 的3次握手
第一次握手:A 的 TCP 进程创建一个 传输控制块 TCB ,然后向 B 发出连接请求报文段。之后将同步位 SYN 设置为 1,同时选择一个初始序列号 seq=x,这时客户端 A 进入到 SYN-SENT(同步已发送)状态。
第二次握手:B 收到连接请求报文段,如果同意建立连接,则向 A 发送确认。在确认报文段中 同步位 SYN=1、确认位 ACK=1、确认号 ack=x+1,同时也为自己选择一个初始序列号 seq=y,这时服务器 B 进入 SYN-RCVID 状态。
第三次握手:A 收到 B 的确认以后,再向 B 发出确认。确认报文 ACK=1、确认号ack=y+1。这时A进入到 ESTAB-LISHED 状态。当B接收到A的确认后,也进入 ESTAB-LISHED 状态。连接建立完成
1.为了防止已经失效的连接请求报文段突然又传到服务端,因而产生错误
如果客户端连续发送多次 SYN 建⽴连接的报⽂,如果出现了网络拥堵,可能会有旧连接先于新连接到达的情况,就可能会出现连接覆盖,要避免这种情况,最少需要三次握手
2.三次握⼿正好避免资源浪费
三次握⼿就已经是理论上建立可靠连接的最小次数了,所以不需要更多的连接
3.同步双⽅初始序列号
同步序列号(可以鉴别重复数序,按序接受等)其实并不要三次握手,只要一来一回两次就可以了
第一次挥手:A 先发送连接释放报文段,段首部的终止控制位 FIN=1,序号seq=u(等于A前面发送数据的最后一个序号加1);然后 A 进入 FIN-WAIT-1(终止等待1)状态,等待 B 的确认。
第二次挥手:B 收到 A 的连接释放报文段后,立刻发出确认报文段,确认号 ack=u+1,序号 seq=v(等于 B 前面发送数据的最后一个序号加1);然后 B 进入 CLOSE-WAIT(关闭等待)状态。
第三次挥手:A 收到 B 的确认报文段后进入到 FIN-WAIT-2(终止等待2)状态,继续等待 B 发出连接释放报文段;
若 B 已经没有数据要发送,B 就会向 A 发送连接释放报文段,段首部的终止控制位 FIN=1,序号 seq=w(半关闭状态可能又发送了一些数据),确认号 ack=u+1,这时B进入 LAST-ACK(最后确认)状态,等待A的确认。
第四次挥手:A收到B的连接释放报文段并发出确认,确认段中 确认位 ACK=1,确认号 ack=w+1,序号 seq=u+1;然后 A 进入到TIME-WAIT(时间等待)状态。当 B 再接收到该确认段后,B 就进入 CLOSED 状态。
首先 2MSL 的时间是从客户端(A)接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内,因为客户端(A)的 ACK 没有传输到服务端(B),客户端(A)又接收到了服务端(B)重发的 FIN 报文,那么 2MSL 时间会被重置。等待 2MSL 原因如下
1.得原来连接的数据包消失
1)如果B没有收到自己的ACK,会超时重传FiN那么A再次接到重传的FIN,会再次发送ACK
2)如果B收到自己的ACK,也不会再发任何消息,
在最后一次挥手后 A 并不知道 B 是否接到自己的 信息
包括 ACK 是以上哪两种情况,A 都需要等待,要取这两种情况等待时间的最大值,以应对最坏的情况发生,这个最坏情况是:去向ACK消息最大存活时间(MSL) + 来向FIN消息的最大存活时间(MSL)。这刚好是2MSL,这个时间,足以使得原来连接的数据包在网络中消失。
2.保证 ACK 能被服务端接收到从而正确关闭链接
因为这个 ACK 是有可能丢失的,会导致服务器收不到对 FIN-ACK 确认报文。假设客户端不等待 2MSL ,而是在发送完 ACK 之后直接释放关闭,一但这个 ACK 丢失的话,服务器就无法正常的进入关闭连接状态。
因为 tcp 可以在发送数据的同时也能接受数据,要实现可靠的连接关闭,A 发出结束报文 FIN,收到 B 确认后 A 知道自己没有数据需要发送了,B 知道 A 不再发送数据了,自己也不会接收数据了,但是此时 A 还是可以接收数据,B 也可以发送数据;当 B 发出 FIN 报文的时候此时两边才会真正的断开连接,读写分开。
TCP 是每发送⼀个数据,都要进⾏⼀次确认应答。只有上一个收到了回应才发送下一个,这样效率会非常低,因此引进了滑动窗口的概念.
其实就是在发送方设立一个缓存区间,将已发送但未收到确认的消息缓存起来,假如一个窗口可以发送 5 个 TCP 段,那么发送方就可以连续发送 5 个 TCP 段,然后就会将这 5 个 TCP 段的数据缓存起来,这 5 个 TCP 段是有序的,只要后面的消息收到了 ACK ,那么不管前面的是否有收到 ACK,都代表成功,窗⼝⼤⼩是由接收方决定的。
窗⼝⼤⼩就是指不需要等待应答,还可以发送数据的大小。
如果接收方处理不过来,发送方就会触发重试机制再次发送数据,然而这个是有性能损耗的,为了解决这个问题,TCP 就提出了流量控制,为的就是让发送方知道接受方的处理能力。
也就是说,每次接收方接受到数据后会将剩余可处理数据的大小告诉发送方。
比如接受方滑动窗口可用大小为400字节,发送方发送过来100字节的数据,那么接收方剩余可用滑动窗口大小就为300字节,这是发送方就知道下次返送数据的大小范围了。
但是这里有一个问题,数据会存放在缓冲区,但是这个缓冲区是操作系统控制的,当系统繁忙的时候,会缩减缓冲区减小,可能就会造成丢包的问题。
如: 发送方接收方窗口大小各为200字节,发送方发送100字节的给接收方,此时双方各剩100字节,但是此时操作系统非常忙,将接收方的缓存区减少了50字节,这时接收方就会告诉发送方,我还有50字节可用,但是在接收方发送到达之前,发送方是不知道的,只会看到自己还有100字节可用,那么就继续发送数据,如果发送了80字节数据,那么接收方缓存区大小为50字节,就会丢失30字节的数据,也就是会发生丢包现象。
我们会发现,这个问题发生的原因就是减少了缓存,又收缩了窗口大小,所以 TCP 是不允许同时减少缓存⼜收缩窗⼝的。
服务端收到客户端发出的 SYN 请求后,会把这个连接信息存储到半链接队列(SYN 队列)。
服务端收到第三次握⼿的 ACK 后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到全连接队列(accept 队列),等待进程调⽤ accept 函数时把连接取出来。
这两个队列都是有大小限制的,当超过容量后就会将链接丢弃,或者返回 RST 包。
TCP 发送数据时会根据 TCP 缓冲区的实际情况进行包的划分,一个完整的包可能会被 TCP 拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是 TCP 粘包和拆包问题。
发生 TCP 粘包的原因:
1.发送的数据小于 TCP 缓冲区大小,TCP将缓冲区中的数据(数据属于多条业务内容)一次发送出去可能就会发生粘包。
2.接收数据端的应用层没有及时读取接收缓冲区中的数据,将发生粘包。
发生 TCP 拆包的原因:
1.待发送数据大于最大报文长度,TCP 在传输前将进行拆包。
2.发送的数据大于 TCP 发送缓冲区剩余空间大小,将会发生拆包。
解决方案:
1.发送端给每个数据包添加包首部,首部中包含数据包的长度,这样接收端在接收到数据后,通过该字段就可以知道每个数据包的实际长度了。
2.发送端将每个数据包设置固定长度,这样接收端每次从读取固定长度的数据把每个数据包拆分开。
3.可以在数据包之间设置边界,如添加特殊符号,接收端可以通过这个特殊符号来拆分包。
1:解析网址,生成 HTTP 请求信息
2:根据 DNS 服务器查询真实请求的 IP 地址,如果本地服务器有缓存则直接返回
3:得到了 IP 以后,向服务器发送 TCP 连接,TCP 连接经过三次握手。
4:接受 TCP 报文后,对连接进行处理,对 HTTP 协议解析
5:服务器返回响应
6:浏览器接受响应,显示页面,渲染页面
用户在浏览器里输入一个https网址,然后连接到server的443端口。
服务器必须要有一套数字证书,可以自己制作,也可以向组织申请,区别就是自己颁发的证书需要客户端验证通过。这套证书其实就是一对公钥和私钥。
服务器将自己的数字证书(含有公钥)发送给客户端。
客户端收到服务器端的数字证书之后,会对其进行检查,如果不通过,则弹出警告框。如果证书没问题,则生成一个密钥(对称加密),用证书的公钥对它加密。
客户端会发起HTTPS中的第二个HTTP请求,将加密之后的客户端密钥发送给服务器。
服务器接收到客户端发来的密文之后,会用自己的私钥对其进行非对称解密,解密之后得到客户端密钥,然后用客户端密钥对返回数据进行对称加密,这样数据就变成了密文。
服务器将加密后的密文返回给客户端。
客户端收到服务器发返回的密文,用自己的密钥(客户端密钥)对其进行对称解密,得到服务器返回的数据。
HTTP协议的特点:
1、服务器只能响应客户端的请求,不能主动向客户端推送数据
2、客户端的每次请求都需要连接、断开,即每次请求都是一个全新的请求
WebSocket的特点:
1、客户端与服务器端在连接时可以互相推据数据
2、客户端连接到服务器之后,会一直保持连接的状态,直到有一端主动断开连接
WebSocket是双向的,在客户端-服务器通信的场景中使用的全双工协议,与HTTP不同,它以ws://或wss://开头。它是一个有状态协议,这意味着客户端和服务器之间的连接将保持活动状态,直到被任何一方(客户端或服务器)终止。在通过客户端和服务器中的任何一方关闭连接之后,连接将从两端终止。
让我们以客户端-服务器通信为例,每当我们启动客户端和服务器之间的连接时,客户端-服务器进行握手随后创建一个新的连接,该连接将保持活动状态,直到被他们中的任何一方终止。建立连接并保持活动状态后,客户端和服务器将使用相同的连接通道进行通信,直到连接终止。
新建的连接被称为WebSocket。一旦通信链接建立和连接打开后,消息交换将以双向模式进行,客户端-服务器之间的连接会持续存在。如果其中任何一方(客户端服务器)宕掉或主动关闭连接,则双方均将关闭连接。套接字的工作方式与HTTP的工作方式略有不同,状态代码101表示WebSocket中的交换协议。
如果我们需要通过网络传输的任何实时更新或连续数据流,则可以使用WebSocket。如果我们要获取旧数据,或者只想获取一次数据供应用程序使用,则应该使用HTTP协议,不需要很频繁或仅获取一次的数据可以通过简单的HTTP请求查询,因此在这种情况下最好不要使用WebSocket。
场景:
Oauth2.0是一个开发标准,允许用户授权登录第三方应用程序访问他们存储在另外的服务提供者上的信息,而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。
Oauth2.0协议的认证流程,简单理解,就是允许我们将之前的授权和认证过程交给一个独立的第三方进行担保。
Oauth2.0协议有四种认证方式,具体如下:
1、授权码模式:
2、简化模式:
3、密码模式:
4、客户模式:
Oauth2.0的使用场景通常称为联合登录。一处注册,多出使用。
SSO Single Sign On 单点登录。一处登录,多处同时登录。
SSO的实现关键带是将Session信息集中存储。比如使用Spring Security框架等实现。
认证:就是对系统访问者身份进行确认。用户名密码登录、二维码登录、手机短信登录、指纹、刷脸等等
授权:就是对系统访问者的行为进行控制。授权通常是在认证之后,对系统内的用户隐私数据进行保护。后台接口访问权限、前台控制的访问权限。
RBAC模型:主体->角色->资源->访问系统的行为。
认证和授权也是一个权限认证框架进行扩展的两个主要方面。
1.TCP面向连接(如打电话要先拨号建立连接)提供可靠的服务;UDP是无连接的,即发送数据之前不需要建立连接,;UDP尽最大努力交付,即不保证可靠交付。(由于UDP无需建立连接,因此UDP不会引入建立连接的时延,TCP需要在端系统中维护连接状态,比如接受和发送缓存,拥塞控制,序号与确认号的参数等,故TCP会比UDP慢)
2.UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高的通信或广播通信。
3. 每一条TCP连接只能是一对一的;UDP支持一对一,一对多,多对一和多对多的交互通信
4 UDP分组首部开销小,TCP首部开销20字节;UDP的首部开销小,只有8个字节。
5. TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的(一次交付一个完整的报文,报文不可分割,报文是UDP数据报处理的最小单位)。
6.UDP适合一次性传输较小数据的网络应用,如DNS,SNMP等
Cookie和Session都是客户端与服务器之间保持状态的解决方案
1,存储的位置不同,cookie:存放在客户端,session:存放在服务端。Session存储的数据比较安全
2,存储的数据类型不同
两者都是key-value的结构,但针对value的类型是有差异的
cookie:value只能是字符串类型,session:value是Object类型
3,存储的数据大小限制不同
cookie:大小受浏览器的限制,很多是是4K的大小, session:理论上受当前内存的限制,
4,生命周期的控制
cookie的生命周期当浏览器关闭的时候,就消亡了
(1)cookie的生命周期是累计的,从创建时,就开始计时,20分钟后,cookie生命周期结束,
(2)session的生命周期是间隔的,从创建时,开始计时如在20分钟,没有访问session,那么session生命周期被销毁
1.HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全, HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议,要比http协议安全。
2. https协议需要到ca申请证书,一般免费证书较少,因而需要一定费用。
3、http和https使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
https://www.cnblogs.com/wqhwe/p/5407468.html
在HTTP/1.0中默认使用短连接。也就是说,客户端和服务器每进行一次HTTP操作,就建立一次连接,任务结束就中断连接。而从HTTP/1.1起,默认使用长连接,用以保持连接特性。什么是TCP粘包/拆包?发生原因?解决方案 一个完整的业务可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这个就是TCP的拆包和粘包问题。原因:1. 应用程序写入数据的字节大小大于套接字发送缓冲区的大小.2. 进行MSS大小的TCP分段。( MSS=TCP报文段长度-TCP首部长度)3. 以太网的payload大于MTU进行IP分片。( MTU指:一种通信协议的某一层上面所能通过的最大数据包大小。)解决方案:1. 消息定长。2. 在包尾部增加回车或者空格符等特殊字符进行分割3. 将消息分为消息头和消息尾。4. 使用其它复杂的协议,如RTMP协议等。
https通过使用对称加密、|非对称加密、数字证书等方式来保证数据的安全传输。
1.什么是SQL注入攻击
攻击者在HTTP请求中注入恶意的SQL代码,服务器使用参数构建数据库SQL命令时,恶意SQL被一起构造,并在数据库中执行。
用户登录,输入用户名 lianggzone,密码 ‘ or ‘1’=’1 ,如果此时使用参数构造的方式,就会出现
select * from user where name = ‘lianggzone’ and password = ‘’ or ‘1’=‘1’
不管用户名和密码是什么内容,使查询出来的用户列表不为空。如何防范SQL注入攻击使用预编译的PrepareStatement是必须的,但是一般我们会从两个方面同时入手。
Web端
1)有效性检验。
2)限制字符串输入的长度。
服务端
1)不用拼接SQL字符串。
2)使用预编译的PrepareStatement。
3)有效性检验。(为什么服务端还要做有效性检验?第一准则,外部都是不可信的,防止攻击者绕过Web端请求)
4)过滤SQL需要的参数中的特殊字符。比如单引号、双引号。
2.什么是XSS攻击
跨站点脚本攻击,指攻击者通过篡改网页,嵌入恶意脚本程序,在用户浏览网页时,控制用户浏览器进行恶意操作的一种攻击方式。如何防范XSS攻击
1)前端,服务端,同时需要字符串输入的长度限制。
2)前端,服务端,同时需要对HTML转义处理。将其中的”<”,”>”等特殊字符进行转义编码。
防 XSS 的核心是必须对输入的数据做过滤处理。
3.什么是CSRF攻击
跨站点请求伪造,指攻击者通过跨站请求,以合法的用户的身份进行非法操作。可以这么理解CSRF攻击:攻击者盗用你的身份,以你的名义向第三方网站发送恶意请求。CRSF能做的事情包括利用你的身份发邮件,发短信,进行交易转账,甚至盗取账号信息。如何防范CSRF攻击
安全框架,例如Spring Security。
token机制。在HTTP请求中进行token验证,如果请求中没有token或者token内容不正确,则认为CSRF攻击而拒绝该请求。
验证码。通常情况下,验证码能够很好的遏制CSRF攻击,但是很多情况下,出于用户体验考虑,验证码只能作为一种辅助手段,而不是最主要的解决方案。
referer识别。在HTTP Header中有一个字段Referer,它记录了HTTP请求的来源地址。如果Referer是其他网站,就有可能是CSRF攻击,则拒绝该请求。但是,服务器并非都能取到Referer。很多用户出于隐私保护的考虑,限制了Referer的发送。在某些情况下,浏览器也不会发送Referer,例如HTTPS跳转到HTTP。
1)验证请求来源地址;
2)关键操作添加验证码;
3)在请求地址添加 token 并验证。
4.什么是文件上传漏洞
文件上传漏洞,指的是用户上传一个可执行的脚本文件,并通过此脚本文件获得了执行服务端命令的能力。
许多第三方框架、服务,都曾经被爆出文件上传漏洞,比如很早之前的Struts2,以及富文本编辑器等等,可被攻击者上传恶意代码,有可能服务端就被人黑了。如何防范文件上传漏洞
文件上传的目录设置为不可执行。
1)判断文件类型。在判断文件类型的时候,可以结合使用MIME Type,后缀检查等方式。因为对于上传文件,不能简单地通过后缀名称来判断文件的类型,因为攻击者可以将可执行文件的后缀名称改为图片或其他后缀类型,诱导用户执行。
2)对上传的文件类型进行白名单校验,只允许上传可靠类型。
3)上传的文件需要进行重新命名,使攻击者无法猜想上传文件的访问路径,将极大地增加攻击成本,同时向shell.php.rar.ara这种文件,因为重命名而无法成功实施攻击。
4)限制上传文件的大小。
5)单独设置文件服务器的域名。
5.DDos 攻击
客户端向服务端发送请求链接数据包,服务端向客户端发送确认数据包,客户端不向服务端发送确认数据包,服务器一直等待来自客户端的确认
没有彻底根治的办法,除非不使用TCP
DDos 预防:
1)限制同时打开SYN半链接的数目
2)缩短SYN半链接的Time out 时间
3)关闭不必要的服务
1.arp协议的工作原理
地址解析协议,即ARP(Address Resolution Protocol),是根据IP地址获取物理地址的一个TCP/IP协议。
1.发送ARP请求的以太网数据帧 广播 到以太网上的每个主机,ARP请求帧中包含了目的主机的IP地址。
2.目的主机收到了该ARP请求之后,会发送一个ARP应答,里面包含了目的主机的MAC地址。
ARP协议工作原理:
每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表,以表示 IP 地址和 MAC 地址之间的对应关系。
主机(网络接口)新加入网络时(也可能只是mac地址发生变化,接口重启等), 会发送免费ARP报文把自己IP地址与Mac地址的映射关系广播给其他主机。
网络上的主机接收到免费ARP报文时,会更新自己的ARP缓冲区。将新的映射关系更新到自己的ARP表中。
某个主机需要发送报文时,首先检查 ARP 列表中是否有对应 IP 地址的目的主机的 MAC 地址,如果有,则直接发送数据,如果没有,就向本网段的所有主机发送 ARP 数据包,该数据包包括的内容有:源主机 IP 地址,源主机 MAC 地址,目的主机的 IP 地址等。
当本网络的所有主机收到该 ARP 数据包时:
(A)首先检查数据包中的 IP 地址是否是自己的 IP 地址,如果不是,则忽略该数据包。
(B)如果是,则首先从数据包中取出源主机的 IP 和 MAC 地址写入到 ARP 列表中,如果已经存在,则覆盖。
(C) 然后将自己的 MAC 地址写入 ARP 响应包中,告诉源主机自己是它想要找的 MAC 地址。
6.源主机收到 ARP 响应包后。将目的主机的 IP 和 MAC 地址写入 ARP 列表,并利用此信息发送数据。如果源主机一直没有收到 ARP 响应数据包,表示 ARP 查询失败。ARP高速缓存(即ARP表)是 ARP地址解析协议能够高效运行的关键
2.什么是RARP?工作原理
概括: 反向地址转换协议,网络层协议,RARP与ARP工作方式相反。 RARP使只知道自己硬件地址的主机能够知道其IP地址。RARP发出要反向解释的物理地址并希望返回其IP地址,应答包括能够提供所需信息的RARP服务器发出的IP地址。
原理:
(1)网络上的每台设备都会有一个独一无二的硬件地址,通常是由设备厂商分配的MAC地址。主机从网卡上读取MAC地址,然后在网络上发送一个RARP请求的广播数据包,请求RARP服务器回复该主机的IP地址。
(2)RARP服务器收到了RARP请求数据包,为其分配IP地址,并将RARP回应发送给主机。
(3)PC1收到RARP回应后,就使用得到的IP地址进行通讯。
3.dns是什么?dns的工作原理
将主机域名转换为ip地址,属于应用层协议,使用UDP传输。(DNS应用层协议,以前有个考官问过)
过程:
总结: 浏览器缓存,系统缓存,路由器缓存,IPS服务器缓存,根域名服务器缓存,顶级域名服务器缓存,主域名服务器缓存。
一、主机向本地域名服务器的查询一般都是采用递归查询。
二、本地域名服务器向根域名服务器的查询的迭代查询。
1)当用户输入域名时,浏览器先检查自己的缓存中是否 这个域名映射的ip地址,有解析结束。
2)若没命中,则检查操作系统缓存(如Windows的hosts)中有没有解析过的结果,有解析结束。
3)若无命中,则请求本地域名服务器解析( LDNS)。
4)若LDNS没有命中就直接跳到根域名服务器请求解析。根域名服务器返回给LDNS一个 主域名服务器地址。
5) 此时LDNS再发送请求给上一步返回的gTLD( 通用顶级域), 接受请求的gTLD查找并返回这个域名对应的Name Server的地址
6) Name Server根据映射关系表找到目标ip,返回给LDNS
7) LDNS缓存这个域名和对应的ip, 把解析的结果返回给用户,用户根据TTL值缓存到本地系统缓存中,域名解析过程至此结束
4.rip协议是什么
RIP动态路由选择协议(网络层协议)
RIP是一种基于距离矢量(Distance-Vector)算法的协议,它使用跳数(Hop Count)作为度量来衡量到达目的网络的路由距离。RIP通过UDP报文进行路由信息的交换,使用的端口号为520。
工作原理:
RIP路由协议用“更新(UNPDATES)”和“请求(REQUESTS)”这两种分组来传输信息的。每个具有RIP协议功能的路由器每隔30秒用UDP520端口给与之直接相连的机器广播更新信息。并且在( 用“路程段数”(即“跳数”)作为网络距离的尺度。每个路由器在)给相邻路由器发出路由信息时,都会给每个路径加上内部距离。
路由器的收敛机制:
任何距离向量路由选择协议(如RIP)都有一个问题,路由器不知道网络的全局情况,路由器必须依靠相邻路由器来获取网络的可达信息。由于路由选择更新信息在网络上传播慢,距离向量路由选择算法有一个慢收敛问题,这个问题将导致不一致性产生。
RIP较少路由收敛机制带来的问题:
1)记数到无穷大机制: RIP协议允许最大跳数为15。大于15的目的地被认为是不可达。 当路径的跳数超过15,这条路径才从路由表中删除。
2) 水平分割法: 路由器不向路径到来的方向回传此路径。当打开路由器接口后,路由器记录路径是从哪个接口来的,并且不向此接口回传此路径。
3) 破坏逆转的水平分割法: 忽略在更新过程中从一个路由器获取的路径又传回该路由器
4)保持定时器法: 防止路由器在路径从路由表中删除后一定的时间内(通常为180秒)接受新的路由信息。 保证每个路由器都收到了路径不可达信息
5) 触发更新法: 当某个路径的跳数改变了,路由器立即发出更新信息,不管路由器是否到达常规信息更新时间都发出更新信息。
RIP的缺点
1、由于15跳为最大值,RIP只能应用于小规模网络;2、收敛速度慢;3、根据跳数选择的路由,不一定是最优路由。
5.OSPF协议?OSPF的工作原理
OSPF(Open Shortest Pass First,开放最短路径优先协议),是一个最常用的内部网管协议,是一个链路状态协议。(网络层协议,)
原理:
OSPF组播的方式在所有开启OSPF的接口发送Hello包,用来确定是否有OSPF邻居,若发现了,则建立OSPF邻居关系,形成邻居表,之后互相发送LSA(链路状态通告)相互通告路由,形成LSDB(链路状态数据库)。再通过SPF算法,计算最佳路径(cost最小)后放入路由表。