目录
注意:以下图片均为网上搬运
参考连接:https://blog.csdn.net/qq_45966440/article/details/121389301
如果有错,欢迎评论区指正
1.说一下TCP的三次握手、四次挥手?
- 序列号seq:占4个字节,这个报文段中的第一个字节的数据编号,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号。
- 确认号ack:占4个字节,当前报文段最后一个字节的编号+1即为确认号,确认号指的是期望接收到下一个字节的编号。
- 确认ACK:占1位,仅当ACK=1时,确认号字段才有效。ACK=0时,确认号无效
- 同步SYN:请求建立连接,连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。
- 终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接
(PS:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。)
三次握手
- 第一次握手:客户端发送带有 SYN 标志的数据包到服务端,服务端收到表示客户端的发送能力没有问题
- 第二次握手:服务端发送带有 SYN/ACK 标志的数据包到客户端,客户端收到表示服务端的发送和接收能力没有问题
- 第三次握手:客户端发送带有带有 ACK 标志的数据包到服务端,服务端收到表示客户端的接收能力没有问题
追问:为什么要三次握手?一次,两次不行吗?
三次握手的目的是:建立可靠的通信信道,双方确认自己与对方的发送与接收是正常的.
- 那么TCP仅需两次握手,第二次握手时,服务端返回给客户端的确认报文丢失了,客户端这边认为服务端没有和他建立连接,而服务端却以为已经和客户端建立了连接,并且服务端开始向客户端发送数据,但客户端并不会接收这些数据,浪费了资源。如果是三次握手,不会出现双方连接还未完全建立成功就开始发送数据的情况。
- 如果此时服务端接收到了一个早已失效的来自客户端的连接请求报文,会向客户端发送确认报文同意建立TCP连接。但因为客户端并不需要向服务端发送数据,所以此次TCP连接没有意义并且浪费了资源。
又追问:第 2 次握手传回了 ACK,为什么还要传回 SYN?
- 服务端传回客户端所发送的 ACK 是为了告诉客户端,我接收到的信息确实就是你所发送的信号了,这表明从客户端到服务端的> 通信是正常的。而回传 SYN也就是同步序列编号则是为了建立并确认从服务端到客户端的通信
四次挥手
- 第一次挥手:客户端向服务端发送的数据完成后,向服务端发起释放连接报文,报文包含标志位FIN=1,序列号seq=u。此时客户端只能接收数据,不能向服务端发送数据。
- 第二次挥手:服务端收到客户端的释放连接报文后,向客户端发送确认报文,包含标志位ACK=1,序列号seq=v,确认号ack=u+1。此时客户端到服务端的连接已经释放掉,客户端不能像服务端发送数据,服务端也不能向客户端发送数据。但服务端到客户端的单向连接还能正常传输数据。
- 第三次挥手:服务端发送完数据后向客户端发出连接释放报文,报文包含标志位FIN=1,标志位ACK=1,序列号seq=w,确认号ack=u+1。
- 第四次挥手:客户端收到服务端发送的释放连接请求,向服务端发送确认报文,包含标志位ACK=1,序列号seq=u+1,确认号ack=w+1。
追问:为什么TCP连接的时候是3次,关闭的时候却是4次?
- 关闭连接时,客户端向服务端发送FIN 时,仅仅表示客户端不再发送数据了但是还能接收数据。
- 服务器收到客户端的FIN 报文时,先回一个ACK应答报文,而服务端可能还有数据需要处理和发送,等服务端不再发送数据时,>才发送FIN 报文给客户端来表示同意现在关闭连接。
从上面过程可知,服务端通常需要等待完成数据的发送和处理,所以服务端的ACK 和FIN一般都会分开发送,从而比三次握手导>致多了一次。
2.TCP中拥塞控制和流量控制有什么区别?
流量控制是TCP 提供的可以让「发送方」根据「接收方」的实际接收能力控制发送数据量的⼀种机制。因为如果一直无脑的发数据给对方,但对方处理不过来,那么就会导致触发重发机制,从而导致网络流量的无端的浪费
拥塞控制就是为了防止过多的数据注入到网络中使网络中的路由器或链路不至于过载。
在某段时间内,若对网络中某一资源需求超过了该资源所能提供的可用部分,网络性能就变坏了,这种情况就叫拥塞。
拥塞控制和流量控制不同,拥塞控制是一个全局性的过程,而流量控制指点对点通信量的控制。
追问:流量控制具体怎么控制的?
- TCP利用滑动窗口机制实现流量控制。
- 在通信过程中,接收方根据自己接收缓存的大小,动态地调整发送方的发送窗口大小,即接收窗口rwnd,发送方的发送窗口取接收窗口rwnd和拥塞窗口cwnd的最小值。
又追问:拥塞控制具体的算法怎么样的?
TCP 的拥塞控制采用了四种算法,即慢开始 、 拥塞避免 、快重传、快恢复:
- 慢开始 : 慢开始算法的思路是当主机开始发送数据时由小到大逐渐增大发送窗口,也就是由小到大逐渐增大拥塞窗口数值。>cwnd 初始值为 1,每经过一个传播轮次,cwnd 加倍。因为如果立即把大量数据字节注入到网络,那么可能会引起网络阻塞。
- 拥塞避免 : 拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大,即每经过一个往返时间 RTT 就把发送放的 cwnd 加 1。
- 快重传与快恢复: 在 TCP/IP 中,快速传和块恢复(fast retransmit and recovery,FRR)是一种拥塞控制算法,它能**快速恢
复丢失的数据包。**没有 FRR,如果数据包丢失了,TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内,没有新的或
复制的数据包被发送。有了 FRR,如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认,它会假定确认件指出的数据段丢失了,并立即重传这些丢失的数据段。有了 FRR,就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时,快速重传和恢复(FRR)能最有效地工作。当有多个数据信息包在某一段很短的时间内丢失时,它则不能很有效地工作。
3.说⼀说TCP与UDP的区别?
UDP:
1.UDP是无连接的, 在传送数据之前不需要先建立连接,远地主机在收到 UDP 报文后,不需要给出任何确认。
2.UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的连接状态表。
3.UDP是面向报文的。发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付IP层。
TCP:
- TCP是面向连接的运输层协议。在传送数据之前必须先建立连接,数据传送结束后要释放连接。
- 每一条TCP连接只能有两个端点,每一条TCP只能是点对点的。
- TCP 提供可靠交付的服务,通过TCP连接传送的数据,无差错、不丢失、不重复,并且按时到达。
- TCP提供全双工通信。TCP允许通信双方得到应用进程在任何时候都能发送数据。
- 面向字节流。含义是:虽然应用程序和TCP的交互是一次一个数据块,但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。TCP中的“流”是指流入到进程或者从进程流出的字节序列。
追问:既然你说TCP提供的可靠的服务,那么TCP 协议如何保证可靠传输?
主要有校验和、序列号、超时重传、流量控制及拥塞避免等几种方法:
- 1.应用数据被分割成 TCP 认为最适合发送的数据块。TCP 给发送的每一个包进行编号,接收方对数据包进行排序,把有序数据传送给应用层。
- 2.校验和:TCP 将保持它首部和数据的检验和。这是一个端到端的检验和,目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错,TCP 将丢弃这个报文段和不确认收到此报文段。
- 3.TCP 的接收端会丢弃重复的数据。
- 4.流量控制: TCP 连接的每一方都有固定大小的缓冲空间,TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据,能提示发送方降低发送的速率,防止包丢失。TCP 利用滑动窗口实现流量控制。
- 5.拥塞控制: 当网络拥塞时,减少数据的发送。
- 6.ARQ 协议: 也是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认。在收到确认后再发下一个分组。
- 7.超时重传: 当 TCP 发出一个段后,它启动一个定时器,等待目的端确认收到这个报文段。如果不能及时收到一个确认,将重发这个报文段。
4.说⼀说GET与POST有哪些区别?
GET- 从指定的服务器中获取数据
POST - 提交数据给指定的服务器处理
GET方法:
使用GET方法时,查询字符串(键值对)被附加在URL地址后面一起发送到服务器:
/test/demo_form.jsp?name1=value1&name2=value2
区别(post全部都相反):
- GET请求能够被缓存
- GET请求会保存在浏览器的浏览记录中
- GET请求的URL能够保存为浏览器书签
- GET请求有长度限制
5.说一下在浏览器中输入URL 地址到显示主页的过程?
总体来说分为以下几个过程:
- DNS 解析:浏览器查询 DNS,获取域名对应的 IP 地址
- TCP 连接:浏览器获得域名对应的 IP 地址以后,浏览器向服务器请求建立链接,发起三次握手
- 发送 HTTP 请求:TCP 连接建立起来后,浏览器向服务器发送 HTTP 请求
- 服务器处理请求并返回 HTTP 报文:服务器接收到这个请求,并根据路径参数映射到特定的请求处理器进行处
理,并将处理结果及相应的视图返回给浏览器 - 浏览器解析渲染页面
- 连接结束
追问:整个过程会使用哪些协议?
- 1.首先浏览器查找域名的IP地址的过程会使用DNS协议
- 2.与服务器建立TCP连接使用到了TCP协议
- 3.建立TCP协议时,需要发送数据,发送数据在网络层使用IP协议
- 4.IP数据包在路由器之间,路由选择使用OSPF协议
5.路由器在与服务器通信时,需要将ip地址转换为MAC地址,需要使用ARP协议
6.在TCP建立完成后,使用HTTP协议访问网页
6.HTTP 1.0 和 HTTP 1.1 的主要区别是什么?
- 长连接 : 在 HTTP/1.0 中,默认使用的是短连接,也就是说每次请求都要重新建立一次连接。HTTP 1.1 起,默认使用长连接,默认开启 Connection: keep-alive。
- 错误状态响应码:在 HTTP1.1 中新增了 24 个错误状态响应码。
- 缓存处理:在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires来做为缓存判断的标准,HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since,If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
- 带宽优化及网络连接的使用:在HTTP1.0中会存在浪费带宽的现象,主要是因为不支持断点续传功能,客户端只是需要某个对象的一部分,服务端却将整个对象都传了过来。在HTTP1.1中请求头引入了range头域,它支持只请求资源的某个部分,返回的状态码为206。
7.谈下你对 HTTP 长连接和短连接的理解?
在 HTTP/1.0 中默认使用短连接。也就是说,客户端和服务器每进行一次 HTTP 操作,就建立一次连接,任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源(如 JavaScript 文件、图像文件、CSS 文件等),每遇到这样一个 Web 资源,浏览器就会重新建立一个 HTTP 会话。
而从 HTTP/1.1 起,默认使用长连接。在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。实现长连接需要客户端和服务端都支持长连接。
HTTP 协议的长连接和短连接,实质上是 TCP 协议的长连接和短连接。
8.说一下HTTP 和 HTTPS 的区别?
有下面几个区别:
- 开销:HTTPS协议需要到CA申请证书,一般免费证书很少,需要交费
- 资源消耗:HTTP是超文本传输协议,信息是明文传输,HTTPS则是具有安全性的SSL加密传输协议,需要消耗更多的CPU和内存资源
- 端口不同:HTTP和 HTTPS使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443
- 安全性:HTTP 是超文本传输协议,信息是明文传输,存在安全风险的问题。而HTTPS 则解决 HTTP 不安全的缺陷,在 TCP 和 HTTP 网络络层之间加入了 SSL/TLS 安全协议,使得报文能够加密传输
9.说说HTTP的优缺点(特点)?
优点:
HTTP最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。
- 简单:HTTP基本的报文格式就是header + body ,头部信息也是key-value简单文本的形式,易于理解,降低了学习和使用的门槛。
- 灵活和易于扩展:
- HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死,都允许开发人员自定义和扩充。
- 同时HTTP由于是工作在应用层,则它下层可以随意变化。
- HTTPS也就是在HTTP与TCP层之间增加了SSL/TLS安全传输层,HTTP/3甚至把TCP层换成了基于UDP的QUIC。
- 应用广泛和跨平台:互联网发展至今,HTTP的应用范围非常的广泛,从台式机的浏览器到手机上的各种APP。
缺点:
- 通信使用明文(不加密),内容可能会被窃听
- 不验证通信方的身份,因此有可能遭遇伪装
- 无法证明报文的完整性,所以有可能已遭篡改
10.说说URI 和 URL 的区别是什么?
- URI(Uniform Resource Identifier)是统一资源标志符,可以唯一标识一个资源。
- URL(Uniform Resource Locator)是统一资源定位符,可以提供该资源的路径。它是一种具体的 URI,即 URL 可以用来标识一个资源,而且还指明了如何 locate 这个资源。
打个比喻,URI 的作用像身份证号一样,URL 的作用更像家庭住址一样。URL 是一种具体的 URI,它不仅唯一标识资源,而且还提供了定位该资源的信息。
11.HTTP是不保存状态的协议,如何保存⽤户状态?
HTTP 是⼀种不保存状态,即⽆状态(stateless)协议。也就是说 HTTP 协议⾃身不对请求和响应之间的通信状态进⾏保存。那么我们保存⽤户状态呢?Session 机制的存在就是为了解决这个问题,Session 的主要作⽤就是通过服务端记录⽤户的状态。典型的场景是购物⻋,当你要添加商品到购物⻋的时候,系统不知道是哪个⽤户操作的,因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的Session 之后就可以标识这个⽤户并且跟踪这个⽤户了(⼀般情况下,服务器会在⼀定时间内保存这个Session,过了时间限制,就会销毁这个Session)。
在服务端保存 Session 的⽅法很多,最常⽤的就是内存和数据库(⽐如是使⽤内存数据库redis保存)。既然 Session 存放在服务器端,那么我们如何实现 Session 跟踪呢?⼤部分情况下,我们都是通过在Cookie 中附加⼀个 Session ID 来⽅式来跟踪。
Cookie 被禁⽤怎么办?
最常⽤的就是利⽤ URL 重写把 Session ID 直接附加在URL路径的后⾯。
12.Cookie的作⽤是什么?和Session有什么区别?
Cookie 和 Session都是⽤来跟踪浏览器⽤户身份的会话⽅式,但是两者的应⽤场景不太⼀样。
Cookie ⼀般⽤来保存⽤户信息 ⽐如①我们在 Cookie 中保存已经登录过得⽤户信息,下次访问⽹站的时候⻚⾯可以⾃动帮你登录的⼀些基本信息给填了;②⼀般的⽹站都会有保持登录也就是说下次你再访问⽹站的时候就不需要重新登录了,这是因为⽤户登录的时候我们可以存放了⼀个 Token 在 Cookie中,下次登录的时候只需要根据 Token 值来查找⽤户即可(为了安全考虑,重新登录⼀般要将 Token重写);③登录⼀次⽹站后访问⽹站其他⻚⾯不需要重新登录。**Session 的主要作⽤就是通过服务端记录⽤户的状态。 **典型的场景是购物⻋,当你要添加商品到购物⻋的时候,系统不知道是哪个⽤户操作的,因为 HTTP 协议是⽆状态的。服务端给特定的⽤户创建特定的 Session 之后就可以标识这个⽤户并且跟踪这个⽤户了。
Cookie 数据保存在客户端(浏览器端),Session 数据保存在服务器端。
Cookie 存储在客户端中,⽽Session存储在服务器上,相对来说 Session 安全性更⾼。如果要在Cookie 中存储⼀些敏感信息,不要直接写⼊ Cookie 中,最好能将 Cookie 信息加密然后使⽤到的时候再去服务器端解密。