目录
- 💪
- 1、OSI的七层模型分别是?各自的功能是什么🔥
- 2、为什么需要三次握手?两次不行?🔥
- 3、为什么需要四次挥手?三次不行🔥
- 4、TCP与UDP有哪些区别?各自应用场景🔥
- 5、TCP可靠传输的原理🔥
- 6、HTTP1.0、1.1、2.0的版本区别
- 7、POST和GET有哪些区别?各自应用场景
- 8、HTTP哪些常用的状态码及使用场景
- 9、HTTP状态码301和302的区别,都有哪些用途
- 10、什么是SQL注入?举个例子🔥
- 11、谈一谈XSS攻击🔥
- 12、HTTPS和HTTP的区别
- 13、对称加密与非对称加密的区别
- 14、简单说下每一层对应的网络协议有哪些
- 15、ARP协议的工作原理
- 16、TCP和UDP分别对应的常见应用层协议有哪些🔥
- 17、为什么time-wait状态必须等待2msl的时间呢
- 18、谈谈你对停止等待协议的理解
- 19、谈谈你对ARQ协议的理解
- 20、谈谈你对滑动窗口的了解
- 21、谈谈你对流量控制的理解
- 22、什么是粘包
- 23、HTTP方法有哪些
- 24、在浏览器中输入URL地址到显示主页的过程🔥
- 25、DNS的解析过程
- 26、什么是数字签名
- 27、什么是数字证书
- 28、Keep-Alive和非Keep-Alive有什么区别
- 29、URI和URL的区别是什么
- 30、HTTP是不保存状态的协议,如何保存状态
口诀:物联网淑慧试用
总结:
刚开始客户端处于 closed 的状态,服务端处于 listen 状态。然后:
三次握手的作用是为了确认双份的接收与发送能力是否正常。解释一下为啥只有三次握手才能确认双方的接受与发送能力是否正常,而两次却不可以:
三次握手的作用
什么是半连接队列
服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。当然还有一个全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
刚开始双方都处于 establised 状态,假如是客户端先发起关闭请求,则:
这里特别需要主要的就是TIME_WAIT这个状态了,这个是面试的高频考点,就是要理解,为什么客户端发送 ACK 之后不直接关闭,而是要等一阵子才关闭。这其中的原因就是,要确保服务器是否已经收到了我们的 ACK 报文,如果没有收到的话,服务器会重新发 FIN 报文给客户端,客户端再次收到 FIN 报文之后,就知道之前的 ACK 报文丢失了,然后再次发送 ACK 报文。
至于 TIME_WAIT 持续的时间至少是一个报文的来回时间。一般会设置一个计时,如果过了这个计时没有再次收到 FIN 报文,则代表对方成功就是 ACK 报文,此时处于 CLOSED 状态。
TCP协议的主要特点:
UDP协议的特点:
TCP和UDP的区别:
常用协议:
TCP和UDP应用场景
HTTP/1.0规定浏览器与服务器只保持短暂的连接,浏览器的每次请求都需要与服务器建立一个TCP连接,服务器完成请求处理后立即断开TCP连接。我们知道TCP连接的建立需要三次握手,是很耗费时间的一个过程。所以,HTTP/1.0版本的性能比较差。
HTTP/1.1引入了持久连接,所谓的持久连接即TCP连接默认不关闭,可以被多个请求复用。同时还引入了管道机制,即在同一个TCP连接里面,客户端可以同时发送多个请求。
HTTP/2采用了多路复用。即在一个连接里,客户端和浏览器都可以同时发送多个请求或回应,而且不用按照顺序一一对应。能这样做有一个前提,就是HTTP/2进行了二进制分帧,即 HTTP/2 会将所有传输的信息分割为更小的消息和帧(frame),并对它们采用二进制格式的编码。
使用场景:GET 用于获取资源,而 POST 用于传输实体主体。
常用状态码:
状态码 | 含义 |
---|---|
101 | 切换请求协议,从HTTP切换到WebSocket |
200 | 请求成功,有响应体 |
301 | 永久重定向:会缓存 |
302 | 临时重定向:不会缓存 |
304 | 协商缓存命中 |
400 | 请求错误 |
403 | 服务器禁止访问 |
404 | 资源未找到 |
500 | 服务器端错误 |
503 | 服务器繁忙 |
301重定向的概念:301重定向,指页面永久性转移,表示为资源或页面永久性地转移到了另一个位置。网页开发过程中,时常会遇到网站目录结构的调整,将页面转移到一个新地址;网页扩展名的改变,这些变化都会导致网页地址发生改变,此时用户收藏夹和搜索引擎数据库中的旧地址是一个错误的地址,访问之后会出现404页面,直接导致网站流量的损失,或者是我们需要多个域名跳转至同一个域名时也是需要进行301重定向。
301重定向的优点:提升网站权重
302重定向:302重定向指页面暂时性转移,表示资源或页面暂时转移到另一个位置,常被用作网址劫持,容易导致网站降权,严重时网站会被封掉,不推荐使用。
SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。
应对方法:
参数绑定:使用预编译手段,绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能,攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中,对于传递的参数我们一般是使用 # 和$
来获取参数值。
当使用#时,变量是占位符,就是一般我们使用javajdbc的PrepareStatement时的占位符,所有可以防止sql注入;当使用$
时,变量就是直接追加在sql中,一般会有sql注入问题。
使用正则表达式过滤传入的参数
XSS是一种经常出现在web应用中的计算机安全漏洞,与SQL注入一起成为web中最主流的攻击方式。XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点,进而添加一些脚本代码嵌入到web页面中去,使别的用户访问都会执行相应的嵌入代码,从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。
原因解析:过于信任客户端提交的数据!
解决办法:不信任任何客户端提交的数据,只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。
具体的解决办法:将重要的cookie标记为http only, 这样的话Javascript 中的document.cookie语句就不能获取到cookie了(如果在cookie中设置了HttpOnly属性,那么通过js脚本将无法读取到cookie信息,这样能有效的防止XSS攻击)
Http协议运行在TCP之上,明文传输,客户端与服务器端都无法验证对方的身份。Https是身披SSL(Secure Socket Layer)外壳的Http,运行于SSL上,SSL运行于TCP之上,是添加了加密和认证机制的HTTP。二者之间存在如下不同:
Https的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制
网络层的 ARP 协议完成了 IP 地址与物理地址MAC的映射。首先,每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表,以表示 IP 地址和 MAC 地址的对应关系。当源主机需要将一个数据包要发送到目的主机时,会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址:如果有,就直接将数据包发送到这个 MAC 地址;如果没有,就向本地网段发起一个 ARP 请求的广播包,查询此目的主机对应的 MAC 地址。
TCP对应的应用层协议:FTP、SMTP、POP3、HTTP
UDP对应的应用层协议:DNS
停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组;在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认
自动重传请求 ARQ 协议:停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认,就重传前面发送过的分组(认为刚才发送过的分组丢失了)。因此每发送完一个分组需要设置一个超时计时器,这种自动重传方式常称为自动重传请求 ARQ。
TCP 利用滑动窗口实现流量控制的机制。滑动窗口是一种流量控制技术。早期的网络通信中,通信双方不会考虑网络的拥挤情况直接发送数据。由于大家不知道网络拥塞状况,同时发送数据,导致中间节点阻塞掉包,谁也发不了数据,所以就有了滑动窗口机制来解决此问题。
TCP 中采用滑动窗口来进行传输控制,滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。
TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。
在进行 Java NIO 学习时,可能会发现:如果客户端连续不断的向服务端发送数据包时,服务端接收的数据会出现两个数据包粘在一起的情况。
接收端收到了两个数据包,但是这两个数据包要么是不完整的,要么就是多出来一块,这种情况即发生了拆包和粘包。拆包和粘包的问题导致接收端在处理的时候会非常困难,因为无法区分一个完整的数据包。
怎么解决拆包和粘包
分包机制一般有两个通用的解决方法:
UDP 没有粘包问题,但是有丢包和乱序。不完整的包是不会有的,收到的都是完全正确的包。
客户端发送的 请求报文 第一行为请求行,包含了方法字段:
为了避免数据在传输过程中被替换,比如黑客修改了你的报文内容,但是你并不知道,所以我们让发送端做一个数字签名,把数据的摘要消息进行一个加密,比如 MD5,得到一个签名,和数据一起发送。然后接收端把数据摘要进行 MD5 加密,如果和签名一样,则说明数据确实是真的。
对称加密中,双方使用公钥进行解密。虽然数字签名可以保证数据不被替换,但是数据是由公钥加密的,如果公钥也被替换,则仍然可以伪造数据,因为用户不知道对方提供的公钥其实是假的。所以为了保证发送方的公钥是真的,CA 证书机构会负责颁发一个证书,里面的公钥保证是真的
在早期的 HTTP/1.0 中,浏览器每次 发起 HTTP 请求都要与服务器创建一个新的 TCP 连接,服务器完成请求处理后立即断开 TCP 连接,服务器不跟踪每个客户也不记录过去的请求。
在 HTTP/1.1 版本中默认使用持久连接,在此之前的 HTTP 版本的默认连接都是使用非持久连接,如果想要在旧版本的 HTTP 协议上维持持久连接,则需要指定 connection 的首部字段的值为 Keep-Alive 来告诉对方这个请求响应完成后不要关闭,下一次咱们还用这个请求继续交流
然而,Keep-Alive 并不是没有缺点的,当长时间的保持 TCP 连接时容易导致系统资源被无效占用,若对 Keep-Alive 模式配置不当,将有可能比非 Keep-Alive 模式带来的损失更大。
URI 的作用像身份证号一样,URL 的作用更像家庭住址一样。
HTTP 是一种不保存状态,即无状态(stateless)协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢?Session 机制的存在就是为了解决这个问题,Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session,过了时间限制,就会销毁这个 Session)。
既然 Session 存放在服务器端,那么我们如何实现 Session 跟踪呢?大部分情况下,我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。
Cookie被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。