什么是TCP/IP五层模型?它们的作用是啥?基于TCP/IP实现的应用(层协议)有哪些?
TCP/IP五层模型,从上向下分别是:
- 应用层:应用程序本身,应用层的作用是负责应用程序之间的数据通讯。不同的网络应用需要哦不同的应用层协议,比如发电子邮件需要SMTP、文件传输需要FTP协议、网络远程访问需要哦Telnet协议
- 传输层:传输层的作用是负责两台主机之间(从源地址到目的地)的数据传输。如传输控制协议(TCP)能够保证数据可靠的从源主机发送到目标主机
- 网络层:网络层的作用是负责网络上的地址管理和路由选择。在数据通讯时,可以选择很多条路径到目标地址
- 数据链路层:数据链路层的作用是负责设备之间的数据帧传送和识别的。数据在传输时现需要经过多个设备进行数据传输,而数据链路层就是i负责相邻设备间的数据传输和识别的。数据链路层可以完全消除网络层和物理层之间的不同,将数据在链路层进行有效的识别和传输
- 物理层:物理层的作用是负责将数据转换成信号,再将信号转换成数据。转换方法因通讯媒体不同而不同,所以没有特定的协议
使用TCP/IP实现的应用有哪些
网络上的大部分通讯协议都是基于TCP/IP模型实现的,例如一下这些常见的应用层协议:
- HTTP:一种用于传输超文本的协议,常用于Web程序之间的通讯
- HTTPS:基于TLS/SSL安全协议对HTTP进行加密和身份验证,用于保护Web通信的安全性
- DNS:用于将域名解析成IP地址,将域名和IP进行映射
说一下DNS的执行流程?
DNS的执行流程如下:
- 用户发起域名查询:用户在浏览器中输入网址的时候,浏览器首先尝试解析这个域名
- 本地DNS解析器查询本地缓存:本地DNS计息期首先检查本地缓存中是否存有与所查询域名相关的IP地址记录。如果有,直接返回
- 向递归DNS服务器发送查询请求:如果本地没有所查询的IP地址记录,本地的DNS解析及将向配置的递归DNS服务器发送查询请求
- 递归DNS服务器查询根域名服务器:如果递归DNS服务器也没有所需的IP地址记录,它会向根域名服务器发送查询请求。根域名服务器是域名系统的顶层服务器,扶着管理顶级域名服务器IP地址
- 根域名服务器返回顶级域名服务器的IP地址:根域名服务器收到查询请求后,会返回负责所查询域名顶级域的顶级域名服务器的IP地址,例如.com、.net等
- 递归DNS服务器查询顶级域名服务器:递归DNS服务器接收到根域名服务器返回的顶级域名服务器IP地址后,将向该顶级域名服务器发送查询请求
- 顶级域名服务器返回权威域名服务器的IP地址:顶级域名服务器接收到查询请求后,会返回负责权威域名服务器的IP地址,如example.com域的域名服务器的IP地址
- 递归DNS服务器查询权威域名服务器:递归DNS服务器继续向权威域名服务器发送查询请求
- 权威域名服务器返回所查询域名的IP地址:权威域名服务器收到查询请求后,会返回所查询域名的IP地址记录
- 递归DNS服务器将IP地址记录返回给本地DNS解析器:最后,递归DNS服务器将获取到的IP地址记录返回给本地DNS解析器
- 本地DNS解析器将IP地址记录返回给用户设备:最终,本地DNS解析器将获取到的IP地址记录返回给用户设备,用户设备可根据该IP地址访问所查询域名的服务
总结来说:它包括了从本地DNS缓存查询开始,逐级向根域名服务器、顶级域名服务器、权威域名服务器的查询过程,最终返回所查询域名的IP地址给用户设备
根域名服务器、顶级域名服务器和权威域名服务器有什么区别?
根域名服务器在整个 DNS 体系中起着导航作用,帮助其他 DNS 服务器找到正确路径;顶级域名服务器针对某一类顶级域名进行管理;而权威域名服务器则具体负责某个域名区域内的详细信息解析工作,它们的关系如图所示:
在浏览器中输入URL地址之后会执行哪些流程?
执行流程如下:
- URL解析:浏览器首先会解析用户输入的URL地址,提取出协议、主机名、端口号、路径等信息
- DNS解析:浏览器将域名解析成IP地址
- 建立TCP连接:浏览器根据URL中的协议(通常是HTTP或HTTPS)建立与服务器的TCP连接。如果是HTTPS,还需要进行SSL/TLS握手过程建立安全连接
- 发送HTTP请求:浏览器向服务器发送HTTP请求,包括请求方法(GET、POST等)、请求头、请求体等
- 服务器处理请求:服务器接收到浏览器发送的HTTP请求之后,根据请求的内容执行相应的处理,可能涉及到查询数据库、处理业务逻辑等
- 服务器返回响应:服务器处理完请求之后,会返回HTTP响应给浏览器,响应包括状态码(如200表示成功)、响应头(Content-Type、Set-Cookie等)、响应体(网页内容)等信息
- 浏览器渲染页面:浏览器接收到服务器返回的HTTP相应之后,会根据相应的内容开始渲染页面,包括解析HTML、CSS、JS等文件,并且把它们显示在浏览器窗口
- 关闭TCP连接:页面加载完成之后,浏览器会关闭与服务器的TCP连接,释放资源
GET请求和POST请求有什么区别?POST请求更安全吗?
GET请求和POST请求区别如下:
- 数据传输方式不同:GET请求数据以明文形式显示在URL中,可以被轻松地获取、收藏、修改;POST请求数据被封装在请求体中,相当于GET请求来说更难被直接获取或修改
- 请求长度限制不同:GET请求受浏览器和服务器对URL长度的先致,一般不能超过2KB;POST请求理论上没有长度限制,但是实际啥啊是哪个受服务器地限制,大多数服务器都会设置请求体大小地上限
- 回滚和刷新不同:GET请求可以直接进行回退和刷新,不会对用户和程序产生任何影响;而POST请求如果直接回滚和刷新会将数据再次提交
- 使用场景不同:GET请求适用于获取资源的新消息,比如查看网页、获取图片等查询操作;POST请求适合用于向服务器提交数据并产生副作用的操作,比如提交表单,上传文件等数据提交操作
POST请求相比GET请求更加安全,但是POST请求地数据被封装在请求体中,用一些抓包工具就可以直接获取到其内容。只要是HTTP协议的,都不是安全的
301和302有什么区别?为什么不建议使用302?
301和302都是用于请求重定向地状态码,所谓的请求重定向是指访问某个URL的时候,会自动跳转另一个URL。但是它们,一个表示请求的资源已经被永久性(301)的移动到另一个位置,而302是临时的移动到另一个位置,客户端应该通过重定向到新的位置获取资源。它们主要的区别如下:
- 行为不同:当服务器返回301状态码的时候,表示请求的资源已经永久性的移动到了新的位置;当服务器返回302的时候,表示请求资源暂时性地移动到了新的位置
- 后续操作不同:客户端在收到301响应的时候,后续应该更新书签或链接,将原来的替换成新的URL,并且以后的请求都是直接使用新的URL获取资源;客户端收到302响应的时候,后续应该继续使用原来的URL请求资源
- 搜索引擎处理不同:搜索引擎通常会将 301 重定向视为对新 URL 的引用,将之前的 URL 的搜索排名改为新的URL;搜索引擎通常不会将 302 重定向视为对新 URL 的引用,不会将之前的 URL 的搜索排名传递给新的URL
为什么不建议使用302
- SEO影响:302状态码暗示着资源的临时移动,搜索引擎不会更新其索引以反映新的搜索引擎通常不会更新其索引以反映新的URL。这意味着原始URL的排名和权重可能会受到影响,因为搜索引擎会继续将原始URL视为资源的主要位置
- 用户体验问题:302 重定向可能导致页面加载速度变慢,对用户体验产生负面影响。每次发生重定向,都会增一次请求和响应的网络开销,延迟页面的加载时间
- 安全性问题:恶意攻击者可以利用 302 重定向进行网络钓鱼攻击或重定向劫持。他们可能会伪造 302 重定向使用户被重定向到恶意站点,诱导用户泄露敏感信息或下载恶意软件
请求转发和请求重定向有什么区别?举个例子通俗易懂的说明一下
请求转发(Forword)和请求重定向(Redirect)区别如下:
- 定义不同
- 请求转发:发生在服务器程序内部,当服务器端收到一个客户端的请求之后,会先将请求转发给目标地址,再将目标地址返回结果转发给客户端
- 请求重定向:服务器端接受到客户的请求之后,会给客户端返回一个临时的响应头,这个临时响应头中记录了,客户端需要再次发送请求(重定向)地URL地址,客户端在收到了地址之后,会将请求发送到新的地址,这个就是请求重定向
- 请求方不同
- 请求转发是服务器端的行为,服务器端代替客户端发送请求,并将结果返回给客户端;而重定向是客户端的行为
- 数据共享不同
- 请求转发是服务端实现的,所以整个执行流程中,客户端(浏览器端)只需要发送一次请求,因此整个交互的过程中使用的都是一个Request请求对象和一个Response响应对象,所以整个请求过程中,请求和返回的数据是共享的;而请求重定向客户端发送两次完全不同的请求,所以两次请求数据是不同的
- 最终的URL地址不同
- 请求转发是服务器端实现的,再将结果返回给客户端,所以整个请求的过程中的URL地址是不变的;而请求重定向是服务器端告诉客户端“你去另一个地方访问”,所以浏览器会重新再发一次请求,因此客户端最终显示的URL也为最终跳转的地址,而非刚开始的请求地址,所以URL地址发生了改变
- 代码实现不同
请求转发:
@RequestMapping("/fw")
public void forward(HttpServletReguest reguest, HttpSeryletResponse response) throws ServletException,IOException{
request.getRequestDispatcher("/index.html").forward(request, response);
}
请求重定向:
@RequestMapping("/rt")
public void redirect(HttpServletRequest request, HttpServletResponse response) throws
IOException{
response.sendRedirect("/index.html");
}
为什么要使用HTTPS?HTTP存在什么问题?
HTTP在互联网通信中起着至关重要的作用,但是它存在一些安全性的问题,所以需要使用HTTPS来增强网络通信的安全。HTTP主要存在以下问题:
- 数据明文传输:HTTP默认情况下是以明文形式传输的,这意味着任何在网络路径上的中间节点(路由器、代理服务器)都能够捕获和查看用户信息
- 缺乏完整性的验证:由于HTTP不提高数据完整性的校验机制,恶意第三方可以轻易的篡改传输中的数据内容,接收方也无法察觉
- 身份验证缺失:使用HTTP时,不验证通讯方的真实身份,可能会遭到伪装。也就是所谓的“中间人攻击”,即攻击者冒充合法服务器,截取并篡改通信内容
HTTPS具有以下的优点:
- 加密:对客户端和服务器端之间的通信内容进行加密,防止数据被窃取和监听
- 认证:通过证书颁发机构(CA)签发的数字证书来验证服务器的身份,保证用户与正确的服务器建立连接
- 完整性:通过消息认证码(MAC)或者散列函数对数据进行完整性校验,防止数据在传输过程中被篡改
什么是中间人攻击?如何解决中间人攻击?
中间人攻击是指,正常情况下本应该是客户端和服务器进行交互的,但是在中间多出了一个中间人,盗取和篡改双方通讯的内容
所以说中间人攻击主要是有两个问题:
- 身份认证问题
- 数据篡改问题
如何解决中间人攻击
使用HTTPS就可以完美的解决中间人功能估计,HTTPS使用以下两种方式来解决:
- 解决身份认证问题:使用CA数字则行数
- 解决数据篡改问题:使用加密通讯
CA认证证书:HTTPS 解决信任问题采用的是数字证书的解决方案,也就是服务器在创建之初,会先向一个大家都认可的第三方平台申请一个可靠的数字证书,然后在客户端访问(服务器端)时,服务器端会先给客户端一个数字证书,以证明自己是一个可靠的服务器端,而非中间人
加密通讯:使用加密通讯之后,第一次通讯的密钥只有在真正的服务器端报错,所以即使中间人拦截了信息,因为是密文并且没有密钥,所以是破解不了的
说一下HTTPS执行流程?
HTTPS是一种在HTTP协议的基础上通过SSL/TLS协议提供了加密处理和身份认证的网络协议,用于确保通信内容的安全性。HTTPS执行的流程如下:
- 客户端请求连接:用户在浏览器中输入HTTPS网址并且发起连接请求。浏览器验证URL合法性,并确认时HTTPS请求
- 服务器响应并返回CA证书:
- 服务器接收到请求之后,返回其数字证书(CA证书),其中包含了服务器的身份信息以及公钥
- 浏览器验证服务器证书的有效性,包含检查证书是否过期、是否由受信任的CA签发、域名是否匹配
- 密钥协商与握手阶段:
- 如果证书有效,浏览器生成一个随机数作为会话密钥(对称密钥)的一部分
- 客户端使用服务器证书中的公钥加密整个会话密钥和其他参数(加密套件、随机数等),然后发给服务器
- 这个过程可能涉及多种握手模式,例如 RSA、DH/ECDH 密钥交换算法等
- 共享会话密钥:
- 服务器接收到加密后的信息之后,用私钥解密得到会话的密钥
- 此时,客户端和服务端都拥有了同一份会话密钥,但是该密钥在网络传输的过程中并没有明文出现
- 数据传输阶段:
- 使用协商好的会话密钥,双方开始使用TLS/SSL协议进行对称加密的数据传输
- 所有的应用层数据(比如HTTP请求和响应的消息体)都会被这个会话密钥加密,从而保证数据的机密性和完整性
- 完整性校验:在数据传输期间,还会使用哈希算法以及消息认证码(MAC)来确保数据未被篡改
- 关闭连接:当通信完成后,通过TLS/SSL的四次挥手或者其他安全机制结束会话,释放资源
什么时加密套件
加密套件是一组加密算法、密钥交换算法和摘要算法的集合,用于加密和认证网络通信的数据。它通常由以下几部分组成:
-
密钥交换算法:用于在通信双方之间安全地交换密钥的算法,例如RSA、Diffie-Hellman等
-
加密算法:用于对通信中的数据进行加密的算法,例如AES、3DES等
-
摘要算法:用于对通信中的数据进行摘要计算,以确保数据的完整性,例如SHA-256、SHA-1等
加密套件的选择对通信的安全性至关重要。通常,服务器和客户端在SSL/TLS握手过程中协商选择一种适当的加密套件来确保通信的安全性。这种协商过程可以确保通信双方都能够支持最强大的加密算法和最安全的密钥交换算法,以提供最高级别的安全性
TCP为什么要三次握手?二次或四次握手行不行?
TCP采用三次握手流程如下:
- 客户端发送连接请求(SYN):客户端向服务器发送一个SYN标志的TCP数据包,表示客户端要建立连接,并指明客户端的初始序列号
- 服务器回复连接确认和连接请求(SYN+ACK):服务器收到客户端的连接请求之后,向客户端发送一个SYN和ACK标识的数据包,表示服务器同意建立连接,并指明服务器的初始序列号
- 客户端回复连接确认(ACK):客户端收到服务器的连接确认和连接请求之后,向服务器发送一个ACK标志的TCP数据包,表示客户端接受了服务器的确认,连接建立完成
三次握手的目的有以下几点:
- 双方能够确认对方的能力:在三次握手的过程中,客户端和服务器端都能够确认对方的能力和状态,确保双方可以正常通信
- 防止过时连接请求的影响:如果服务器收到了过时连接请求,但是客户端并没有真正的发起连接,那么服务器在收到第三次握手的确认之前不会分配这个连接请求,避免资源浪费
二次握手或四次握手并不是TCP协议所采用的标准握手流程,它们都存在一些问题:
-
二次握手:在这种情况下,客户端发送连接请求后,服务器直接发送确认,这样客户端并不能确认服务器的状态,容易造成连接的不稳定性和不可靠性。
-
四次握手:在这种情况下,多了一次确认的过程,增加了通信的开销,而且不必要,因为三次握手已经足够确保连接的可靠性。
因此,TCP采用三次握手的机制是为了在可靠地建立连接的同时,保证通信的高效性和可靠性