程序猿周周
⌨️ 短视频小厂BUG攻城狮
如果文章对你有帮助,记得关注、点赞、收藏,一键三连哦,你的支持将成为我最大的动力
本文是《后端面试小册子》系列的第 3️⃣ 篇文章,该系列将整理和梳理笔者作为 Java 后端程序猿在日常工作以及面试中遇到的实际问题,通过这些问题的系统学习,也帮助笔者顺利拿到阿里、字节、华为、快手等多个大厂 Offer,也祝愿大家能够早日斩获自己心仪的 Offer。
PS:《后端面试小册子》已整理成册,目前共十三章节,总计约二十万字,欢迎关注公众号【程序猿周周】获取电子版和更多学习资料(最新系列文章也会在此陆续更新)。公众号后台可以回复关键词「电⼦书」可获得这份面试小册子。文中所有内容都会在 Github 开源,项目地址 csnotes,如文中存在错误,欢迎指出。如果觉得文章还对你有所帮助,赶紧点个免费的 star 支持一下吧!
标题 | 地址 |
---|---|
MySQL数据库面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122910606 |
Redis面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122934938 |
计算机网络面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122973684 |
操作系统面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122994599 |
Linux面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/122994862 |
Spring面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123016872 |
Java基础面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123080189 |
Java集合面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123171501 |
Java并发面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123266624 |
Java虚拟机面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123412605 |
Java异常面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123462676 |
设计模式面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123490442 |
Dubbo面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123538243 |
Netty面试题总结(2022版) | https://blog.csdn.net/adminpd/article/details/123564362 |
协议是为进行网络中数据交换而建立的规则、标准或规定称为网络协议,简称协议。控制两个对等实体(或多个实体)进行通信的规则的集合。
服务是指下层为紧邻的上层提供的功能调用,也就是垂直的。对等实体在协议的控制下,使得本层能为上一层提供服务,但要实现本层协议还需要使用下一层所提供的服务。
二者的区别于:
协议是控制对等实体之间通信的规则,是水平的。
服务是下层通过层间接口向上层提供的功能,是垂直的。
二者的关系:
协议的实现保证了能够向上一层提供服务,要实现本层协议还需使用下层提供的服务
ref 简述协议与服务的区别、关系
ISO/OSI | TCP/IP | Protocol | PDU | Facility |
---|---|---|---|---|
应用层(Application) | 应用层 | HTTP, TFTP, FTP, NFS, WAIS, SMTP | 数据(data) | Gateway |
表示层(Presentation) | Telnet, Rlogin, SNMP, Gopher | |||
会话层(Session) | SMTP, DNS | |||
传输层(Transport) | 传输层 | TCP, UDP | 数据段(segment) | |
网络层(Network) | 网络层 | IP, ICMP, ARP, RARP, AKP, UUCP | 数据包(packet) | 路由器 |
数据链路层(Data Link) | 数据链路层 | FDDI, Ethernet, Arpanet, PDN, SLIP, PPP | 帧(frame) | 交换机、网桥 |
物理层(Physical) | IEEE 802.1A, IEEE 802.2 to IEEE 802.11 | 比特(bit) | 中继器、集线器 |
注:PDU(协议数据单元)
上文我们已经知道什么是网络协议以及分层结构,回答这个问题,首先需要了解计算机网络分层协议带来的好处:
1)各层之间是独立的。某一层并不需要知道它的下一层是如何实现的,而仅仅需要知道该层通过层间的接口(即界面)所提供的服务。由于每一层只实现一种相对独立的功能,因而可将一个难以处理的复杂问题分解为若干个较容易处理的更小一些的问题。这样,整个问题的复杂程度就下降了。
2)灵活性好。当任何一层发生变化时(例如由于技术的变化),只要层间接口关系保持不变,则在这层以上或以下各层均不受影响。此外,对某一层提供的服务还可进行修改。
3)当某层提供的服务不再需要时,甚至可以将这层取消。
4)结构上可分割开。各层都可以采用最合适的技术来实现。
5)易于实现和维护。这种结构使得实现和调试一个庞大而又复杂的系统变得易于处理,因为整个的系统已被分解为若干个相对独立的子系统。
6)能促进标准化工作。因为每一层的功能及其所提供的服务都已有了精确的说明。
当然,分层当然也有一些缺点,比如有些功能会在不同的层次中重复出现,因而产生了额外开销。
ref 计算机网络为什么要分层?
为了降低组网复杂程度,减少工作量和方便异种机的连接,考虑充分利用通信线路资源,提高网络可靠性和完整性,简化设计,将数据处理和通信处理分开,划分为通讯子网(下三层)和资源子网(上三层)。
ref 什么是资源子网和通信子网,分别有什么特点。?
ARP协议(Address Resolution Protocol),全称地址解析协议。其作用是将已知 IP 地址转换为 MAC 地址,因为在以太网环境中,数据的传输所依懒的是 MAC 地址而非 IP 地址。
每个主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表,以表示 IP 地址和 MAC 地址之间的对应关系。ARP缓存(ARP表)是 ARP地址解析协议能够高效运行的关键。
1)主机(网络接口)新加入网络时(也可能只是mac地址发生变化,接口重启等),会发送免费ARP报文把自己IP地址与Mac地址的映射关系广播给其它主机;
2)网络上的主机接收到免费 ARP 报文时,会更新自己的ARP缓冲区。将新的映射关系更新到自己的ARP表中;
3)某个主机需要发送报文时,首先检查 ARP 列表中是否有对应 IP 地址的目的主机的 MAC 地址,如果有,则直接发送数据,如果没有,就向本网段的所有主机发送 ARP 数据包,该数据包包括的内容有:源主机 IP 地址,源主机 MAC 地址,目的主机的 IP 地址等;
4)当本网络的所有主机收到该 ARP 数据包时:
5)源主机收到 ARP 响应包后。将目的主机的 IP 和 MAC 地址写入 ARP 列表,并利用此信息发送数据。如果源主机一直没有收到 ARP 响应数据包,表示 ARP 查询失败。
ref ARP地址解析协议原理
以太网是局域网使用最广泛的协议之一,由于部署简单,价格低廉,被 IEEE 委员会标准化,其正式标准是 IEEE 802.3
。以太网协议则是用于实现链路层的数据传输和 MAC 地址封装。
如图所示,以太网的数据帧由它由 6 字节的目的 MAC 地址,6 字节的源 MAC 地址,2 字节的*类型域(用于标示封装在这个 Frame 里面的数据的类型)。接下来是 46-1500 字节的数据和 4 字节的帧校验。
ref 网络协议之以太网协议解析
PPP 全程 Point to Point Protocol,中文为点对点协议。是为在同等单元之间传输数据包这样的简单链路设计的链路层协议。这种链路提供全双工操作,并按照顺序传递数据包。设计目的主要是用来通过拨号或专线方式建立点对点连接发送数据,使其成为各种主机、网桥和路由器之间简单连接的一种共通的解决方案。
介质访问控制协议。
数据传输的可靠性是通过数据链路层和网络层的点对点和传输层的端对端保证的。端到端与点到点是针对网络中传输的两端设备间的关系而言的。
端到端通信是针对传输层来说的。它是一个网络连接,指的是在数据传输之前,在发送端与接收端之间(忽略中间有多少设备)为数据的传输建立一条链路,链路建立以后,发送端就可以发送数据,知道数据发送完毕,接收端确认接收成功。 也就是说在数据传输之前,先为数据的传输开辟一条通道,然后在进行传输。从发送端发出数据到接收端接收完毕结束。
点到点通信是针对数据链路层或网络层来说的。点对点是基于 MAC 地址或 IP 地址。指一个设备发数据给与该该设备直接连接的其他设备,这台设备又在合适的时候将数据传递给与它相连的下一个设备,通过一台一台直接相连的设备把数据传递到接收端。
其主要区别还是,端到端关心的开始与结束,点到点关心的中间过程。可以说 端到端是由无数个点到点构成的。
ref 计算机网络中端到端与点到点的区别
ICMP 全称 Internet Control Message Protocol,即 Internet 控制报文协议。它是 TCP/IP 协议簇的一个子协议,用于在IP主机、路由器之间传递控制消息。
主要用来检测网络通信故障和实现链路追踪,最典型的应用就是 ping 和 traceroute
通过发送回送请求报文和回送回答报文来检测源主机到目的主机的链路是否有问题,目的地是否可达,以及通信的延迟情况。
通过发送探测报文来获取链路地址信息。
1)第一个探测报文 TTL 为 1,到达第一个路由器时,TTL 减 1 为 0 所以丢掉这个探测包,同时向源主机发回 ICMP 时间超过报文,这时源主机就获得了第一个路由器的 IP 地址;
2)接着源主机发送第二个探测报文,TTL 增 1 为 2,到达第一个路由器 TTL 减 1 为 1 并转发探测包到第二个路由器,这时 TTL 再减 1 为 0,丢掉这个探测包并向源主机发回 ICMP 时间超过报文,源主机就获得了第二个路由器的IP地址;
3)以此类推,直到探测报文到达 traceroute 的目的地,这时源主机就获得了到目的地的每一跳路由的 IP 地址。
如图执行 traceroute 命令打印出可执行程序主机,一直到目标主机之前经历多少路由器:
TTL 是 Time To Live 的缩写,该字段指定 IP包被路由器丢弃之前允许通过的最大网段数量。(需要注意的是 TTL 与 DNS TTL 二者都是生存时间,前者指 ICMP 包的转发次数或跳数,后者指域名解析信息在DNS中的存在时间。)
TTL 的作用是限制 IP数据包在计算机网络中的存在的时间,以避免IP包在网络中的无限循环和收发,节省了网络资源,并能使IP包的发送者能收到告警消息。TTL的最大值是255,TTL的一个推荐值是64。
VIP 即虚拟 IP 地址是一个不与特定计算机或一个计算机中的网络接口卡(NIC)相连的 IP 地址。数据包被发送到这个 VIP 地址,但是所有的数据还是经过真实的网络接口。
何为虚拟IP,就是一个未分配给真实主机的IP,也就是说对外提供数据库服务器的主机除了有一个真实IP外还有一个虚拟IP,使用这两个IP中的 任意一个都可以连接到这台主机,所有项目中数据库链接一项配置的都是这个虚IP,当服务器发生故障无法对外提供服务时,动态将这个虚IP切换到备用主机。
至于如何切换,其实现原理主要是靠 TCP/IP 的 ARP 协议。因为 IP 地址只是一个逻辑地址,在以太网中 MAC 地址才是真正用来进行数据传输的物理地址,每台主机中都有一个 ARP 高速缓存,存储同一个网络内的 IP 地址与 MAC 地址的对应关系,以太网中的主机发送数据时会先从这个缓存中查询目标 IP 对应的 MAC 地址,会向这个 MAC 地址发送数据。操作系统会自动维护这个缓存,这就是整个实现的关键。
ref 虚拟IP,地址漂移
1)TCP 面向连接,UDP 无连接;
2)TCP 保证数据的可靠传输,数据传送无差错,不丢失,无重复,按序到达;
3)TCP 连接一对一,UDP支持更广泛;
4)UDP 实时性好,效率高,适用场大量客户端短消息传输;
5)TCP 面向数据流,UDP 面向数据报。
1)序列和;
2)序列号和确认应答机制;
3)重传机制(超时重传,累计确认、快速重传);
4)流量控制(滑动窗口协议);
5)拥塞控制(慢启动、拥塞避免、拥塞发生、快速恢复);
在发送一个数据之后,就开启一个定时器,若是在这个时间内没有收到发送数据的ACK确认报文,则对该报文进行重传,在达到一定次数还没有成功时放弃并发送一个复位信号。
累计确认就是TCP协议的确认方法,TCP使用可变长度报文段来发送数据,重传时,报文段数据可能会比原报文段数据包含更多的数据,因此对数据报和报文段无法进行简单的确认。TCP使用流序号对流中的一个位置进行确认,即序号和确认号一一对应,接收方使用序号将报文段重新排序,且以正确接收到的流的最长连续前缀进行确认。
超时时间计算是开启定时器的设定时间,从而保证网络资源利用率,避免因定时器的时间(RTO)不确定而影响网络传输效率。
后面拥塞控制章节会讲。
ref TCP协议的确认重传机制
通信双方在数据传输时,发送方的速率与接收方的速率是不一定相等,如果发送方的发送速率太快,会导致接收方处理不过来,这时候接收方只能把处理不过来的数据存在缓存区里(失序的数据包也会被存放在缓存区里)。
如果缓存区满了发送方还在疯狂着发送数据,接收方只能把收到的数据包丢掉,大量的丢包会极大着浪费网络资源,因此,我们需要控制发送方的发送速率,让接收方与发送方处于一种动态平衡才好。
故对发送方发送速率的控制,我们称之为流量控制。
我们在 TCP 如何实现可靠传输一章中说道 TCP 实现有序传输采用了确认应答机制,如果通信双发仅接收到一帧,确认一帧,再发送一帧,实现简单的停止等待协议。那么整个网络的吞吐量将会非常的低。
滑动窗口协议用于网络数据传输时的流量控制,以避免拥塞的发生。该协议允许发送方在停止并等待确认前发送多个数据分组。由于发送方不必每发一个分组就停下来等待确认,因此该协议可以加速数据的传输,提高网络吞吐量。
它本质上是描述接收方数据报缓冲区大小的数据,发送方根据这个数据来计算自己最多能发送多长的数据。这个窗口大小为 0 时,发送方将停止发送数据。启动定时器,等待这个窗口变成非 0。
滑动窗口协议必须保证数据包的按序传输,发送窗口中的序列号代表已发送但尚未收到确认的数据包,发送窗口可持续地维持一系列未经确认的数据包,因为发送方窗口内的数据包可能在传输过程中丢失或损坏,所以发送过程必须把发送窗口中的所有数据包保存起来以备重传。发送窗口一旦达到最大值,发送过程就必须停止接收新的数据包,直到有空闲缓存区。
接收窗口外的数据包都要丢弃,当序列号等于接收窗口下限的数据包到达时,把它提交给应用程序并向发送端发送确认,接收窗口向前移动一位。发送窗口和接收窗口上下限无需相同,大小也无需相同,但接收窗口大小需保持固定,发送窗口大小可随着数据包而改变。
如何控制
1)接收方 ACK 报文会携带窗口信息,发送方收到之后,便会调整自己的发送速率,也就是调整自己发送窗口的大小;
2)发送方接收到 rwnd==0 的报文后停止发送,并启动定时器,每隔一段时间就发个测试报文去询问接收方接收窗口大小,即等待接收方 rwnd>0 的报文。
TCP 是双工的协议,会话双方都可以同时接收、发送数据。TCP 会话双方都各自维护一个发送窗口和一个接收窗口,各自的接收窗口大小取决于应用、系统、硬件的限制。当链路变好或者变差,这个窗口会发生变化。
PS,在早期的 TC 协议中,接受接受窗口的大小确实是固定的,不过随着网络的快速发展,固定大小的窗口太不灵活了,成为TCP性能瓶颈之一。
接受窗口如果太小的话,显然这是不行的,这会严重浪费链路利用率,增加丢包率。那是否越大越好呢?答否,当接收窗口达到某个值的时候,再增大的话也不怎么会减少丢包率的了,而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。
接收方在发送确认报文的时候,会告诉发送发自己的接收窗口大小,而发送方的发送窗口会据此来设置自己的发送窗口,但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻,就已经在一边处理堆在自己缓存区的数据了,所以一般情况下接收窗口 >= 发送窗口。
ref 通俗易懂讲解TCP流量控制机制,了解一下
所谓拥塞控制,就是提高网络利用率,降低丢包率,并保证网络资源的对每条数据流的公平性。拥塞控制是一个全局性的过程,涉及到所有的主机、路由器,以及与降低网络传输性能有关的所有因素。
拥塞控制的几个主要方法包括:慢启动、拥塞避免、快速重传和快速恢复。
慢开始并非指拥塞窗口(cwnd)在过程中增长的慢,而是启动时把拥塞窗口设置为一个最大报文段 MSS 的数值。而在每收到一个对新的报文段的确认后,把拥塞窗口增加至多一个 MSS的数值(即指数增长)。用这样的方法逐步增大发送方的拥塞窗口,可以使分组注入到网络的速率更加合理。
当 cwnd 增长到一个阈值 ssthresh 时,就开始使用拥塞避免算法,即每经过一个往返时间 RTT 就把发送方的 cwnd 加 1,进行线性增长。
以上是发送端在未检测到拥塞时所采用的积极避免拥塞的方法。接下来介绍拥塞发生时(可能发生在慢启动阶段或者拥塞避免阶段)拥塞控制的行为。先来了解一下发送端可以判断拥塞发生的依据:
做法是把 ssthresh 置为出现拥塞时的拥塞窗口的一半(但不能小于2),以及 cwnd 置为 1 进行慢开始。目的是迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间把队列中积压的分组处理完毕。
发送端如果连续收到 3 个重复的确认报文端,就认为是拥塞发生了,具体实现步骤:
1)快速重传(Fast retransmit):要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方),而不要等到自己发送数据时捎带确认;
2)快速恢复(Fast retransmit):发送方接收到三个重复 ACK 报文后,把慢开始门限 ssthresh 减半,并将 CWND 设置为新的 ssthresh,然后立即重传丢失的报文段,并开始进行拥塞避免算法。
ref 拥塞控制
TCP报文是TCP层传输的数据单元,也叫报文段。
由上图中的 TCP 报文格式可知,TCP 报文首部有 20 字节的固定首部以及最大长度为 40 字节的偏移数据构成,即 TCP 报文头部最大 60 字节(计算方式后面会讲)。
其中固定首部包括:
包括源端口号和目的端口号两部分,分别占 2 字节,用来标识同一台计算机的不同的应用进程。
TCP 报头中的源端口号和目的端口号同 IP 数据报中的源 IP 与目的 IP 唯一确定一条 TCP 连接。
序号是本报文段发送的数据组的第一个字节的序号。在 TCP 传送的流中,每一个字节一个序号。
如一个报文段的序号为 300,此报文段数据部分共有 100 字节,则下一个报文段的序号为 400。所以序号确保了 TCP 传输的有序性。确认号,指下一个期待收到的字节序号,表明该序号之前的所有数据已经正确无误的收到。确认号只有当 ACK 标志为 1 时才有效。比如建立连接时,SYN 报文的 ACK 标志位为 0。
序号和确认号分别占 4 字节。
首部长度也叫数据偏移,因为首部可能含有可选项内容,因此 TCP 报头的长度是不确定的,首部长度实际上指示了数据区在报文段中的起始偏移值。
由于首部长度只占到了 4bit 大小,所以能表示的最大长度是 2^4 - 1 = 15
,同时它的单位是 4 字节,所以首部最大长度是 4 * 15 = 60
字节。
保留:6 位
控制位:6 位
包括 URG、ACK、PSH、RST、SYN 和 FIN 六个,每一个标志位表示一个控制功能。
1)URG:紧急指针标志,为 1 时表示紧急指针有效,为 0 则忽略紧急指针。
2)ACK:确认序号标志,为1时表示确认号有效,为0表示报文中不含确认信息,忽略确认号字段。
3)PSH:push标志,为1表示是带有push标志的数据,指示接收方在接收到该报文段以后,应尽快将这个报文段交给应用程序,而不是在缓冲区排队。
4)RST:重置连接标志,用于重置由于主机崩溃或其他原因而出现错误的连接。或者用于拒绝非法的报文段和拒绝连接请求。
5)SYN:同步序号,用于建立连接过程,在连接请求中,SYN=1和ACK=0表示该数据段没有使用捎带的确认域,而连接应答捎带一个确认,即SYN=1和ACK=1。
6)FIN:结束标志,用于释放连接,为 1 时表示发送方已经没有数据发送了,即关闭本方数据流。
滑动窗口大小,用来告知发送端接受端的缓存大小,以此控制发送端发送数据的速率,从而达到流量控制。窗口大小是一个 16bit 的字段,因而窗口大小最大为 65535。
奇偶校验,此校验和是对整个的 TCP 报文段,包括 TCP 头部和 TCP 数据,以 16 位字进行计算所得。由发送端计算和存储,并由接收端进行验证。
只有当 URG 标志置 1 时紧急指针才有效。紧急指针是一个正的偏移量,和顺序号字段中的值相加表示紧急数据最后一个字节的序号。 TCP 的紧急方式是发送端向另一端发送紧急数据的一种方式。
最常见的可选字段是最长报文大小,又称为 MSS(Maximum Segment Size),每个连接方通常都在通信的第一个报文段(为建立连接而设置 SYN 标志为 1 的那个段)中指明这个选项,它表示本端所能接受的最大报文段的长度。选项长度不一定是 32 位的整数倍,所以要加填充位,即在这个字段中加入额外的零,以保证 TCP 头是 32 的整数倍。
TCP 报文段中的数据部分是可选的。在一个连接建立和一个连接终止时,双方交换的报文段仅有 TCP 首部。
如果一方没有数据要发送,也使用没有任何数据的首部来确认收到的数据。在处理超时的许多情况中,也会发送不带任何数据的报文段。
ref TCP报文格式详解
ref TCP SYN洪泛攻击的原理及防御方法
TCP 中主要有四个计时器,包括重传计时器、坚持计时器、保活计时器、时间等待计时器。
目的:为了控制丢失的报文段或者丢弃的报文段。这段时间为对报文段的等待确认时间。
创建时间:在TCP发送报文段时,会创建对次特定报文段的重传计时器。
可能发生的两种情况:在截止时间(通常为60秒)到之前,已经收到了对此特定报文段的确认,则撤销计时器;在截止时间到了,但为收到对此特定报文段的确认,则重传报文段,并且将计时器复位。
重传时间:2*RTT(Round Trip Time,为往返时间)
目的:主要解决零窗口大小通知可能导致的死锁问题
死锁问题的产生:当接收端的窗口大小为0时,接收端向发送端发送一个零窗口报文段,发送端即停止向对端发送数据。此后,如果接收端缓存区有空间则会重新给发送端发送一个窗口大小,即窗口更新。但接收端发送的这个确认报文段有可能会丢失,而此时接收端不知道已经丢失并认为自己已经发送成功,则一直处于等待数据的状态;而发送端由于没有收到该确认报文段,就会一直等待对方发来新的窗口大小,这样一来,双方都处在等待对方的状态,这样就形成了一种死锁问题。如果没有应对措施,这种局面是不会被打破的。为了解决这种问题,TCP为每一个连接设置了坚持计时器。
工作原理:当发送端TCP收到接收端发来的零窗口通知时,就会启动坚持计时器。当计时器的期限到达时,发送端就会主动发送一个特殊的报文段告诉对方确认已经丢失,必须重新发送。【这个特殊的报文段就称为探测报文段,探测报文段只有1个字节的大小,里边只有一个序号,该序号不需要被确认,甚至在计算其他部分数据的确认时该序号会被忽略。】
截止期的设置:设置为重传时间的值。但如果没有收到接收端的响应,则会发送另一个探测报文段,并将计时器的值加倍并复位,直到大于门限值(一般为60秒)。在此之后,发送端会每隔60秒发送一个探测报文段,直到窗口重新打开。
目的:主要是为了防止两个TCP连接出现长时间的空闲。当客户端与服务器端建立TCP连接后,很长时间内客户端都没有向服务器端发送数据,此时很有可能是客户端出现故障,而服务器端会一直处于等待状态。保活计时器就是解决这种问题而生的。
工作原理:每当服务器端收到客户端的数据时,都将保活计时器重新设置(通常设置为2小时)。过了2小时后,服务器端如果没有收到客户端的数据,会发送探测报文段给客户端,并且每隔75秒发送一个,当连续发送10次以后,仍没有收到对端的来信,则服务器端认为客户端出现故障,并会终止连接。
时间等待计时器是在连接终止期间使用的。
当TCP关闭连接时并不是立即关闭的,在等待期间,连接还处于过渡状态。这样就可以使重复的FIN报文段在到达终点之后被丢弃。
时间设置:一般为报文段寿命期望值的2倍。
ref TCP中的四个计时器
TCP 粘包就是指发送方发送的若干包数据到达接收方时粘成了一包,从接收缓冲区来看,后一包数据的头紧接着前一包数据的尾,出现粘包的原因是多方面的,可能是来自发送方,也可能是来自接收方。
为什么会产生这样的现象?
这是由于 TCP 为提高性能,发送端会将需要发送的数据发送到缓冲区,等待缓冲区满了之后,再将缓冲中的数据发送到接收方。同理,接收方也有缓冲区这样的机制,来接收数据。
而 UDP 则是面向消息传输的,是有保护消息边界的,接收方一次只接受一条独立的信息,所以不存在粘包问题。
如何处理粘包现象?
1)对于发送方造成的粘包问题,可以通过关闭 Nagle 算法来解决,使用 TCP_NODELAY 选项来关闭算法;
2)接收方没有办法来处理粘包现象,只能将问题交给应用层来处理;
3)应用层的解决办法简单可行,不仅能解决接收方的粘包问题,还可以解决发送方的粘包问题。
循环处理,应用程序从接收缓存中读取分组时,读完一条数据,就应该循环读取下一条数据,直到所有数据都被处理完成,但是如何判断每条数据的长度呢?
ref tcp粘包和拆包的处理方案
1)第一次握手:建立连接时,客户端发送 syn 包(syn=x)到服务器,并进入 SYN_SENT 状态,等待服务器确认;
2)第二次握手:服务器收到 syn 包,须确认客户的 SYN(ack=x+1),同时自己也发送一个 SYN 包(syn=y),即 SYN+ACK 包,此时服务器进入 SYN_RECV 状态;
3)第三次握手:客户端收到服务器的 SYN+ACK 包,向服务器发送确认包 ACK(ack=y+1),此包发送完毕,客户端和服务器进入 ESTABLISHED(TCP连接成功)状态,完成三次握手。
1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号;
2)服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间;
3)客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据);
4)服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认;
5)客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态;
6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
*ref TCP的三次握手与四次挥手理解及面试题(很全面)
因为当服务端收到客户端的 SYN 连接请求报文后,可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的,SYN 报文是用来同步的。而关闭连接时服务端收到 FIN 报文后很可能并不会立即关闭 SOCKET,所以只能先回复一个 ACK 报文给客户端,“你发的 FIN 报文我收到了”。只有等到服务端所有的报文都发送完了,才能发送 FIN 报文,因此不能一起发送。故需要四步握手。
三次握手完成了两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。如果把三次握手改成仅需要两次握手,可能会造成死锁是。
如计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
MSL 即最大报文段生存时间,理论上四个报文都发送完毕后我们就可以直接进入 CLOSE 状态,但我们必须假设网络是不可靠的,最后一个 ACK 很可能丢失。所以 TIME_WAIT 状态就是用来重发可能丢失的 ACK 报文。
在客户端发送出最后的 ACK 丢失后,服务端如果没有收到 ACK 将不断重复发送 FIN 片段。所以客户端不能立即关闭,它必须确认服务端接收到了最后的 ACK。客户端在发送出 ACK 之后进入到 TIME_WAIT 状态,同时会设置一个计时器,等待 2MSL 的时间。如果在该时间内再次收到 FIN,那么会重发ACK并再次等待 2MSL。
所谓的 2MSL 是两倍的 MSL(Maximum Segment Lifetime)。MSL 指一个片段在网络中最大的存活时间,2MSL 就是一个发送和一个回复所需的最大时间。如果直到 2MSL,客户端都没有再次收到 FIN,那么客户端推断 ACK 已经被成功接收,则结束 TCP 连接。
广播 UDP 与单播 UDP 的主要区别就是 IP 地址不同,广播使用广播地址 255.255.255.255,通过该 IP 地址可将消息发送到在同一广播网络上的每个主机。值得强调的是:本地广播信息是不会被路由器转发。当然这是十分容易理解的,因为如果路由器转发了广播信息,那么势必会引起网络瘫痪。这也是为什么IP协议的设计者故意没有定义互联网范围的广播机制。
广播地址通常用于在网络游戏中处于同一本地网络的玩家之间交流状态信息等。其实广播顾名思义,就是想局域网内所有的人说话,但是广播还是要指明接收者的端口号的,因为不可能接受者的所有端口都来收听广播。
多播,也称为“组播”,将网络中同一业务类型主机进行了逻辑上的分组,进行数据收发的时候其数据仅仅在同一分组中进行,其他的主机没有加入此分组不能收发对应的数据。
多播的应用主要有网上视频、网上会议等。
ref UDP 单播、广播、多播
1)DNS对输入网址进行域名解析;
2)建立TCP连接(三次握手);
3)客户端发送HTTP请求,服务端响应请求;
4)浏览器解析渲染页面;
5)连接结束(四次挥手)。
ref 从输入一个网址到浏览器显示页面经历的过程,如是等等
主要依次查询浏览器、操作系统、本地域名服务器、根域名服务器、主(顶级)域名服务器、注册域名服务器中的域名与 IP 映射关系。
1)浏览器先检查自身缓存中有没有被解析过的这个域名对应的 IP 地址,如果有,解析结束。(同时域名被缓存的时间也可通过 TTL 属性来设置。)
2)如果浏览器没有命中缓存,则检查操作系统缓存中有没有对应的已解析过的结果。而操作系统也有一个域名解析的过程。(在 windows 中可通过 c 盘中一个叫 hosts 的文件来设置,如果在这指定了一个域名对应的 IP,则浏览器会优先使用这个 IP 地址。)
3)如果至此还没有命中域名,才会真正的请求本地域名服务器(LDNS)来解析这个域名,这台服务器一般在你的城市的某个角落,距离你不会很远,并且这台服务器的性能都很好,一般都会缓存域名解析结果,大约80%的域名解析到这里就完成了;
4)如果LDNS仍然没有命中,就直接跳到Root Server 域名服务器请求解析;
5)根域名服务器返回给LDNS一个所查询域的主域名服务器(gTLD Server,国际顶尖域名服务器,如.com .cn .org等)地址;
6)此时LDNS再发送请求给上一步返回的 gTLD;
7)接受请求的 gTLD 查找并返回这个域名对应的 Name Server 的地址,这个 Name Server 就是网站注册的域名服务器;
8)Name Server 根据映射关系表找到目标 IP 返回给 LDNS;
9)LDNS 缓存这个域名和对应的 IP;
10)LDNS把解析的结果返回给用户,用户根据TTL值缓存到本地系统缓存中,域名解析过程至此结束。
ref 详解DNS域名解析全过程
Http 是基于TCP面向连接的无状态应用层超文本传输协议。
GET: 请求指定的页面信息,并返回实体主体。
HEAD: 只请求页面的首部。
POST: 请求服务器接受所指定的文档作为对所标识的URI的新的从属实体。
PUT: 从客户端向服务器传送的数据取代指定的文档的内容。
DELETE: 请求服务器删除指定的页面。
OPTIONS: 允许客户端查看服务器的性能。
TRACE: 请求服务器在响应中的实体主体部分返回所得到的内容。
PATCH: 实体中包含一个表,表中说明与该URI所表示的原内容的区别。
MOVE: 请求服务器将指定的页面移至另一个网络地址。
COPY: 请求服务器将指定的页面拷贝至另一个网络地址。
LINK: 请求服务器建立链接关系。
UNLINK: 断开链接关系。
WRAPPED: 允许客户端发送经过封装的请求。
Extension-mothed:在不改动协议的前提下,可增加另外的方法。
ref HTTP协议请求方式: 中GET、POST和HEAD的介绍
来源HTTP1.0种定义的三种请求方式,只请求页面的首部,不返回响应主体。简单来说就是,HEAD 方法与 GET 类似,但是 HEAD 并不返回消息体。在一个 HEAD 请求的消息响应中,HTTP 投中包含的元信息应该和一个 GET 请求的响应消息相同。
这种方法可以用来获取请求中隐含的元信息,而无需传输实体本身。并经常用来测试超链接的有效性,可用性和最近修改。
ref HTTP之HEAD请求
GET在浏览器回退时是无害的,而POST会再次提交请求
GET把参数包含在URL中(安全),POST通过request body传递参数
GET请求参数会被完整保留在浏览器历史记录里,而POST中的参数不会被保留
GET请求在URL中传送的参数是有长度限制的,而POST没有
GET 和 POST 最大的区别主要是 GET 请求是幂等性的,POST 请求不是。这个是它们本质区别,上面的只是在使用上的区别。
幂等指的是多次请求某一个资源应该具有同样的副作用,因此不能用get请求做数据的增删改这些有副作用的操作。
ref get 和 post 区别
1)缓存策略:HTTP 1.1 中引入更多的缓存头来控制缓存策略;
2)带宽和连接优化:引入 range 头域来请求资源的一部分,返回 206 状态码,支持断点续传;
3)错误通知管理:新增 24 个错误状态响应码,如 409(Conflict)、410(Gone);
4)Host头处理:1.1 的请求和响应消息都应支持 Host(主机名)头域,且请求消息中如果没有会报一个 400 错误;
5)长连接:默认开启keep-alive,支持长连接和请求的流水线(流水线未实现)。
1)二进制分帧;
2)多路复用;(与Http1.1长连接(流水线)区别:1.x依旧是串行,会阻塞后续请求。)
3)首部压缩:通过缓存表避免重复header的传输;
4)优先级和依赖性:请求时告知服务器资源分配权重,优先加载重要资源;
5)服务端推送。
ref HTTP/2 相比 1.0 有哪些重大改进?
1)100(继续):服务器已收到请求的一部分,等待其余部分;
2)101(切换协议):服务器根据客户端的请求切换协议;
2XX 成功处理
3XX 重定向
1)301(永久)302(临时);
2)303 307 308区别:link
1)404(未找到);
2)405(方法禁用);
1)500(服务器内部错误);
2)504(网关超时)。
ref HTTP状态码 1xx,2xx,3xx,4xx 意思
HTTPS 是以安全为目标的 HTTP 通道,是 HTTP 的安全版。HTTPS 的安全基础是 SSL。SSL 协议位于 TCP/IP 协议与各种应用层协议之间,为数据通讯提供安全支持。SSL 协议可分为两层:SSL 记录协议(SSL Record Protocol),它建立在可靠的传输协议(如TCP)之上,为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL 握手协议(SSL Handshake Protocol),它建立在 SSL 记录协议之上,用于在实际的数据传输开始前,通讯双方进行身份认证、协商加密算法、交换加密密钥等
1)HTTPS 协议需要到 CA(Certificate Authority,证书颁发机构)申请证书,一般免费证书较少,因而需要一定费用。
2)HTTP 是超文本传输协议,信息是明文传输,HTTPS 则是具有安全性的 SSL 加密传输协议。
3)HTTP 和 HTTPS 使用的是完全不同的连接方式,使用的端口也不一样,前者是80,后者是443。
4)HTTP 的连接很简单,是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
ref HTTP 和 HTTPS 的区别(面试常考题)
1)客户端请求建立SSL链接,并向服务端发送一个随机数–Client random和客户端支持的加密方法,比如RSA公钥加密,此时是明文传输。
2)服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
3)客户端收到服务端的回复后利用服务端的公钥,加上新的随机数–Premaster secret 通过服务端下发的公钥及加密方法进行加密,发送给服务器。
4)服务端收到客户端的回复,利用已知的加解密方式进行解密,同时利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key。
此后的HTTP链接数据传输即通过对称加密方式进行加密传输。
ref SSL四次握手
对称加密和非对称加密的主要区别在于是否使用同一个密钥加解密。
ref 浅谈对称加密与非对称加密
证书是公开的,中间人可以随意得到证书,但私钥是无法获取的,一份公钥是不可能推算出其对应的私钥,中间人即使拿到证书也无法伪装成合法服务端,因为无法对客户端传入的加密数据进行解密。
1)本地请求被劫持(如DNS劫持等),所有请求均发送到中间人的服务器。
2)中间人服务器返回中间人自己的证书。
3)客户端创建随机数,通过中间人证书的公钥对随机数加密后传送给中间人,然后凭随机数构造对称加密对传输内容进行加密传输。
4)中间人因为拥有客户端的随机数,可以通过对称加密算法进行内容解密。
5)中间人以客户端的请求内容再向正规网站发起请求。
6)因为中间人与服务器的通信过程是合法的,正规网站通过建立的安全通道返回加密后的数据。
7)中间人凭借与正规网站建立的对称加密算法对内容进行解密。
8)中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输。
9)客户端通过与中间人建立的对称加密算法对返回结果数据进行解密。
由于缺少对证书的验证,所以客户端虽然发起的是 HTTPS 请求,但客户端完全不知道自己的网络已被拦截,传输内容被中间人全部窃取。
使用 CA 证书。权威机构是要有认证的,不是随便一个机构都有资格颁发证书,不然也不叫做权威机构。另外,证书的可信性基于信任制,权威机构需要对其颁发的证书进行信用背书,只要是权威机构生成的证书,我们就认为是合法的。所以权威机构会对申请者的信息进行审核,不同等级的权威机构对审核的要求也不一样,于是证书也分为免费的、便宜的和贵的。
首先,一个 CA 证书包括颁了发机构信息、公钥、公司信息、域名、有效期和指纹等信息。
浏览器发起 HTTPS 请求时,服务器会返回网站的 SSL 证书,浏览器需要对证书做以下验证:
1)验证域名、有效期等信息是否正确。证书上都有包含这些信息,比较容易完成验证。
2)判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书,操作系统、浏览器会在本地存储权威机构的根证书,利用本地根证书可以对对应机构签发证书完成来源验证。
3)判断证书是否被篡改(需要与 CA 服务器进行校验)。
4)判断证书是否已吊销。通过CRL(Certificate Revocation List 证书注销列表)和 OCSP(Online Certificate Status Protocol 在线证书状态协议)实现,其中 OCSP 可用于第3步中以减少与 CA 服务器的交互,提高验证效率。
以上任意一步都满足的情况下浏览器才认为证书是合法的。
HTTPS 并不包含对随机数的安全保证,HTTPS 保证的只是传输过程安全,而随机数存储于本地,本地的安全属于另一安全范畴,应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。
同时 HTTPS 可以防止用户在不知情的情况下通信链路被监听,对于主动授信的抓包操作是不提供防护的,因为这个场景用户是已经对风险知情。要防止被抓包,需要采用应用级的安全防护,例如采用私有的对称加密,同时做好移动端的防反编译加固,防止本地算法被破解。
用来指明IP地址的哪些位标识的是主机所在的子网,以及哪些位标识的是主机的位掩码。
ref 如何理解子网掩码?
1)URL重写;
2)表单隐藏字段;
3)Token+localStorage。