关注公众号:高性能架构摸索。后盾回复【材料】,能够收费支付

笔者从事后端技术十余年,期间也面试他人,也有被他人面试,明天特意将这些面试的知识点总结下,心愿可能在工作或者面试中帮忙到大家。

说说OSI模型和TCP/IP模型

OSI(Open System Interconnection,开放式通信互联) 是由 ISO(International Organization for Standardization,国际标准化组织) 制订的规范模型。旨在将世界各地的各种计算机互联。然而,OSI 模型过于宏大、简单。参照此模型,技术人员开发了 TCP/IP 协定栈,简化 OSI 七层模型为 TCP/IP 四层模型。取得了更宽泛的应用。

OSI 模型和 TCP/IP 模型比照:

什么是TCP

TCP(Transmission Control Protocol 传输控制协议)是一种面向连贯(连贯导向)的、牢靠的、 基于IP的传输层协定。

TCP是如何保证数据牢靠的

  • 通过数据流的形式传输,将数据截成正当的长度;
  • 对每段报文进行编号,保障数据流的程序;
  • 收到数据进行重排序,并且抛弃反复数据;
  • 收到报文后,给出确认响应;
  • 超时重发;
  • 校验和;
  • 流量管制(针对本程序的承受能力)和拥塞管制(针对整个网络)。

说说TCP和UDP的区别

协定差异

性能TCPUDP
是否连贯面向连贯无连贯
传输可靠性牢靠不牢靠
利用场合传输大量数据传输大量数据
速度

区别总结:

  • TCP 的面向连贯的,在发送数据之前要建设连贯;UDP 是无连贯的,即发送数据之前不须要建设连贯;
  • TCP 提供牢靠的服务,通过 TCP 连贯传送的数据,不失落,不反复,且按序达到。UDP 尽最大致力交付,不保障牢靠交付;
  • TCP 面向字节流,把数据看成一连串无构造的字节流;UDP 是面向报文的,对应用程序的报文既不拆分也不合并;
  • TCP 有流量管制和拥塞管制,UDP 没有拥塞管制;
  • TCP 连贯只能是点到点的,UDP 反对一对一,一对多,多对一和多对多的交互通信;
  • TCP首部至多开销 20 字节,UDP 的首部构造简略,开销小,只有8个字节;
  • 因为 TCP 要保护连贯和保障可靠性,所以对系统资源的要求较多, UDP 绝对要小得多。

TCP建设连贯的过程

TCP建设连贯产生在client端调用connect零碎调用的时候。其目标是为了对每次发送的数据量进行跟踪与协商(即替换单方窗口大小),确保数据段的发送和接管同步,依据所接管到的数据量而确认数据发送、接管结束后何时吊销分割,并建设虚连贯。

TCP建设连贯的过程,是一个三次握手的过程。

  • 第一次握手:client端向server发送连贯申请,SYN=1(SYN示意发送端与接收端要建设连贯),seq = x。此时client端进入SYN_SENT阶段
  • 第二次握手:server在收到client端的申请后,向client回复SYN = 1(SYN示意发送端与接收端要建设连贯) 和 ACK = 1(示意对发送端申请进行应答),seq = y, ack = x + 1。此时server端进入SYN_RCVD阶段
  • 第三次握手:client端收到server端的申请和响应之后,同样须要向server端回复音讯。向server端发送ACK = 1(示意对server端的响应),seq = x + 1,ack = y + 1.此时客户端进入ESTABLISH阶段。server端在收到该ACK后,也进入ESTABLISH阶段。

艰深了解:

  • A 想要和 B 通信,首先跟 B 说:“我想和你通信”;
  • B 收到这条信息之后,回复 A 说:“收到。我也想和你通信”;
  • A 收到之后就晓得,原来 B 也想通信,回复 B 说:“收到”。

上述三次握手过程,咱们用图示意为。

为什么建设连贯是3次,而不是2次或者4次

按理说,在客户端收到服务器发过来的确认报文后(第二次握手后),通信单方就能够确定对方的申请建设连贯的用意了,那为什么客户端还要再发送一次 ACK 报文呢?

次要是避免曾经生效的连贯申请报文又达到服务器端这种状况。

“曾经生效的连贯申请报文”是这样产生的:当网络环境差的时候,客户端发送的连贯申请报文可能失落,也有可能滞留在某个节点。当客户端期待肯定工夫后,没有收到服务器发送的确认报文,就认为之前发送的连贯申请报文生效了。客户端会再次发送连贯申请报文。

然而如果滞留在某个节点的报文通过长时间延迟后达到了服务器端,服务器并不知道这是一个生效的报文,它认为是客户端的失常连贯申请,就会返回确认报文,批准连贯建设。

如果采纳2次握手的办法,这时新的连贯曾经建设了。然而实际上,客户端并没有发动申请,它不会对服务端的确认报文做出反馈,更不会发送数据给服务端。而服务端却认为新的连贯曾经建设,始终再期待客户端发送数据,这样就造成了资源的节约。

而如果采纳4次握手的状况,就是将第二次SYN和ACK分成两步来操作,这样会浪费资源以及性能节约。

采纳3次握手就能够防止这样状况。上述的情景下,服务器没有收到客户端对本人发送过来的确认报文的 ACK 报文,就晓得客户端没有申请建设连贯。

TCP断开连接的过程

当client端和server端的数据传输实现之后,就须要断开连接,以节俭资源。断开连接的过程,咱们个别称之为四次挥手(与建设连贯的三次握手绝对应)。

  • 第一次挥手:client端向server端发送断开连接的申请,通知server端,我这边不再须要跟你传输数据。发送FIN=1(示意发送断开连接申请),seq=x,此时client端处于FIN_WAIT_1阶段
  • 第二次挥手:server端在收到client端的断开申请后,须要通知客户端曾经收到申请。因而向client端回复ACK=1,seq=y,ack=x+1(示意对client发送的seq=x进行确认)。此时client端处于FIN_WAIT_2阶段,server端处于CLOSE_WAIT阶段。
  • 第三次挥手:当server端不再须要与client端传输数据,就向client端发送断开连接的申请。FIN=1(示意发送断开连接申请),ACK=1(示意对client端的上一次断开连接应答)。seq=z,ack=x+1(上一次断开连接申请时候seq=x)。此时server端处于LAST_ACK阶段。
  • 第四次挥手:client端收到server端断开连接的申请后,需作出应答,因而ACK=1.seq=x+1,ack=w+1(示意对上一次申请的应答)

艰深了解:

  • A 没有数据发送,就和 B 说:“我没有数据给你了,然而如果你还有数据没发送完,则不用急着断开,还能够持续发送数据”;
  • B 收到后,会通知 A说:“收到。”,而后持续发送数据给 A;
  • 当 B 端确定数据已发送实现,则通知 A:“好了,我这边数据发完了,筹备好敞开连贯了”;
  • A 听到后,和 B 说:“好的,你断开吧。”,而后在期待 2MSL 工夫后断开。

至此,断开连接的过程解说结束,用图的形式如下:

为什么client要期待 2MSL 后才断开连接?

网络的状态是不确定的,最初 Client 发送的确认报文可能失落。 如果确认报文失落并且 Client 不期待,间接断开连接。此时 Server 端在发送 FIN 报文后,不会收到任何响应。期待一段时间后,会重发 FIN 报文,但此时 Client 端曾经敞开。Server 就会始终重发 FIN 报文。而如果 Client 端处于期待状态时,就会回复确认报文给 Server,让 Server 敞开。同时,在 2MSL 内没有收到 FIN 报文,阐明 Server 端收到了确认报文,曾经敞开,这样本人也能够敞开了。 2MSL 是从 Client 到 Server 工夫的2倍,也就是发送确认报文和承受 FIN 报文的工夫。

为什么TCP断开连接是4次

因为TCP是全双工,在一端断开连接之后,另外一端在须要的时候,也须要断开连接。每一端的断开须要两次,即FIN和ACK,所以整个过程就是四次。

TCP是怎么进行流量管制

TCP必须要解决的牢靠传输以及包乱序的问题,所以,TCP必须要晓得网络理论的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。这就引入了滑动窗口和拥塞窗口。

在发送端通过拥塞窗口,在接收端通过滑动窗口。

滑动窗口协定是传输层进行流控的一种措施,接管方通过通告发送方本人的能够承受缓冲区大小(这个字段越大阐明网络吞吐量越高),从而管制发送方的发送速度,不过如果接收端的缓冲区一旦面临数据溢出,窗口大小值也会随之被设置一个更小的值告诉给发送端,从而控制数据发送量(发送端会依据接收端批示,进行流量管制)。

避免过多的数据注入到网络中,这样能够使网络中的路由器或链路不致过载。拥塞管制所要做的都有一个前提:网络可能接受现有的网络负荷。拥塞管制是一个全局性的过程,波及到所有的主机、路由器,以及与升高网络传输性能无关的所有因素。

在浏览器中输出一个url后,浏览器的行为

浏览器自身是一个客户端,当你输出URL的时候,首先浏览器会去申请DNS服务器,通过DNS获取相应的域名对应的IP,而后通过IP地址找到IP对应的服务器后,要求建设TCP连贯,等浏览器发送完HTTP Request(申请)包后,服务器接管到申请包之后才开始解决申请包,如果申请的资源蕴含有动静语言的内容,那么服务器会调用动静语言的解释引擎负责解决“动静内容”,并将解决失去的数据装在HTTP Response(响应)包返回给客户端;客户端收到来自服务器的响应后开始渲染这个Response包里的主体(body),等收到全副的内容随后断开与该服务器之间的TCP连贯。