面试问题浓缩总结
小游
2021-03-20

运输层(TCP,UDP)

# TCP的三次握手

img

# 问题1 TCP可以建立两次握手嘛

不可以。有两个原因：首先，可能会出现已失效的连接请求报文段又传到了服务器端。

其次，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

# 问题2 第三次握手中，如果客户端的ACK未送达服务器，会怎样？

Server端： 由于Server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。

Client端，两种情况：

  1. 在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态
  2. 在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

# 问题三 如果已经建立了连接，但客户端出现了故障怎么办？

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

# 问题四 什么是初始序列号

TCP连接的一方A，随机选择一个32位的序列号（Sequence Number）作为发送数据的初始序列号（Initial Sequence Number，ISN），比如为1000，以该序列号为原点，对要传送的数据进行编号：1001、1002...三次握手时，把这个初始序列号传送给另一方B，以便在传输数据时，B可以确认什么样的数据编号是合法的；同时在进行数据传输时，A还可以确认B收到的每一个字节，如果A收到了B的确认编号（acknowledge number）是2001，就说明编号为1001-2000的数据已经被B成功接受。

# TCP的四次挥手

img

# 问题1 为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态意义是什么）？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。

# 如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

# 客户端TIME_WAIT状态的意义是什么？

网络情况不好时，如果主动方无TIME_WAIT等待，关闭前个连接后，主动方与被动方又建立起新的TCP连接，这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接；

第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。

MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

# TIME-WAIT 和 CLOSE-WAIT 详解

TIME_WAIT 是主动关闭链接时形成的，等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。 由于TIME_WAIT 的时间会非常长，因此server端应尽量减少主动关闭连接

一些爬虫服务器或者WEB服务器上经常会遇到这个问题，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态

为什么要这么长时间呢？

  1. 防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）
  2. 可靠的关闭TCP连接。在主动关闭方发送的最后一个ack(fin)，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于CLOSED状态 ，就会响应rst而不是ack。所以主动方要处于TIME_WAIT状态，而不能是CLOSED。另外这么设计TIME_WAIT会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。

这东西可以通过修改配置文件来解决

CLOSE_WAIT是被动关闭连接是形成的。就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。此时，recv/read已收到FIN的连接socket，会返回0。

因为linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了，接着就是大量Too Many Open Files异常，Tomcat崩溃。

参考

  1. 服务器TIME_WAIT和CLOSE_WAIT详解和解决办法 - 知乎 (zhihu.com) (opens new window)
  2. TIME_WAIT和CLOSE_WAIT状态区别_kobejayandy的专栏-CSDN博客 (opens new window)

# 大量的time-wait是什么原因？

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。

# TCP半连接状态

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态。

半连接队列

在三次握手协议中，服务器维护一个半连接队列，存放半连接。该队列为每个客户端的SYN包（syn=j）开设一个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的ACK确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。

TCP半连接与SYN攻击 - 简书 (jianshu.com) (opens new window)

# TCP和UDP的包头

TCP的包头如下

image.png

UDP的包头如下

image.png

IP报文格式如下

image.png

TCP的16位校验和怎么计算的

这里写图片描述

1、首先将检验和置零； 2、然后将TCP伪首部部分，TCP首部部分，数据部分都划分成16位的一个个16进制数 3、将这些数逐个相加，记得溢出的部分加到最低位上，这是循环加法： 0xc0a8+ 0x0166+……+0x0402=0x9b49 4、最后将得到的结果取反，则可以得到检验和位0x64b6

TCP校验和（Checksum）的原理和实现_造梦先森Kai的专栏-CSDN博客 (opens new window)

# TCP流量控制

使用滑动窗口协议实现。流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。

零窗口：将窗口字段设置为 0，这个时候就叫零窗口。发送方必须暂停发送数据，但是会启动一个持续计时器(persistence timer)，到期后发送一个大小为1字节的探测数据包，以查看接收窗口状态。如果接收方能够接收数据，就会在返回的报文中更新接收窗口大小，恢复数据传送。

img

# 滑动窗口

在TCP协议中，发送算法各有一个窗口，接收方会在确认报文中通过窗口字段来告诉发送方，发送方根据这个值和其它信息设置自己的窗口大小

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {32, 33} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

img

# 模拟滑动窗口

img

  • 发送方接收到了对方发来的报文 ack = 33, win = 10，知道对方收到了 33 号前的数据，现在期望接收 [33, 43) 号数据。发送方连续发送了 4 个报文段假设为 A, B, C, D, 分别携带 [33, 35), [35, 36), [36, 38), [38, 41) 号数据。
  • 接收方接收到了报文段 A, C，但是没收到 B 和 D，也就是只收到了 [33, 35) 和 [36, 38) 号数据。接收方发送回对报文段 A 的确认：ack = 35, win = 10。
  • 发送方收到了 ack = 35, win = 10，对方期望接收 [35, 45) 号数据。发送方向法B，C，D然后发送了一个报文段 E，它携带了 [41, 44) 号数据。
  • 需要注意的是，接收方接收 tcp 报文的顺序是不确定的，并非是一定先收到 35 再收到 36，也可能是先收到 36，37，再收到 35.

# TCP拥塞控制

# 什么情况下会出现拥塞

  • 在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏——产生拥塞(congestion)。
  • 出现资源拥塞的条件：对资源需求的总和 > 可用资源
  • 若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降。

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

# 拥塞控制的四种算法

慢开始、拥塞避免、快重传、快恢复

img

# 慢开始和拥塞避免

  1. 发送的最初执行慢开始，令 cwnd=1，发送方只能发送 1 个报文段； 当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...
  2. 因为每次都是加倍，所以可能增长很快，我们可以 设置一个慢启动阈值 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。
  3. 如果出现了超时，则令 ssthresh = cwnd/2，然后重新执行慢开始。

# 快重传与快恢复

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

在发送方，如果收到 三个重复确认 ，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

总结： 简单点来说我们收到三个重复的报文确认时，我们执行快重传，重传丢失的报文。然后我们令ssthresh = cwnd/2 ，cwnd = ssthresh这个过程就是快恢复。

img

# 如何确定发送窗口上限

发送方的发送窗口的上限值应当取为接收方窗口 rwnd 和拥塞窗口 cwnd 这两个变量中较小的一个，即应按以下公式确定：发送窗口的上限值 = Min {rwnd, cwnd}

  • 当 rwnd < cwnd 时，是接收方的接收能力限制发送窗口的最大值。
  • 当 cwnd < rwnd 时，则是网络的拥塞限制发送窗口的最大值。

# 流量控制和拥塞控制区别

  • 拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。
  • 拥塞控制是一个全局性的过程，涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。
  • 流量控制往往指在给定的发送端和接收端之间的点对点通信量的控制。
  • 流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
  • 流量控制属于通信双方协商；拥塞控制涉及通信链路全局。
  • 流量控制需要通信双方各维护一个发送窗、一个接收窗，对任意一方，接收窗大小由自身决定，发送窗大小由接收方响应的TCP报文段中窗口值确定；拥塞控制的拥塞窗口大小变化由试探性发送一定数据量数据探查网络状况后而自适应调整。
  • 实际最终发送窗口 = min{流控发送窗口，拥塞窗口}。

# TCP和UDP

# TCP和UDP的区别

  1. TCP是面向连接的，UDP是无连接的（无连接就是UDP发送数据之前不需要建立连接）
  2. TCP是可靠的，UDP是不可靠的（不可靠就是UDP接收方收到报文后，不需要给出任何确认）
  3. TCP只支持点对点通信，UDP支持一对一、一对多、多对一、多对多；
  4. TCP是面向字节流的，UDP是面向报文的；（面向字节流是指发送数据时以字节为单位，一个数据包可以拆分成若干组进行发送，而UDP一个报文只能一次发完。）
  5. TCP有拥塞控制机制，UDP没有。网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用是很重要的，比如媒体通信，游戏；
  6. TCP首部开销（20字节）比UDP首部开销（8字节）要大
  7. UDP 的主机不需要维持复杂的连接状态表

# TCP和UDP如何选择

对某些实时性要求比较高的情况，选择UDP，比如游戏，媒体通信，实时视频流（直播），即使出现传输错误也可以容忍；其它大部分情况下，HTTP都是用TCP，因为要求传输的内容可靠，不出现丢失

HTTP不能选择UDP，因为HTTP需要基于可靠的传输协议，而UDP不可靠

# 面向连接和无连接的区别

无连接的网络服务（数据报服务）-- 面向连接的网络服务（虚电路服务）

虚电路服务：首先建立连接，所有的数据包经过相同的路径，服务质量有较好的保证；

数据报服务：每个数据包含目的地址，数据路由相互独立（路径可能变化）；网络尽最大努力交付数据，但不保证不丢失、不保证先后顺序、不保证在时限内交付；网络发生拥塞时，可能会将一些分组丢弃；

# TCP如何保证传输可靠

  1. 数据包校验
  2. 对失序数据包重新排序（TCP报文具有序列号）
  3. 丢弃重复数据
  4. 应答机制：接收方收到数据之后，会发送一个确认（通常延迟几分之一秒）；
  5. 超时重发：发送方发出数据之后，启动一个定时器，超时未收到接收方的确认，则重新发送这个数据；
  6. 流量控制：确保接收端能够接收发送方的数据而不会缓冲区溢出

# TCP的粘包与拆包

1、要发送的数据大于TCP发送缓冲区剩余空间大小，将会发生拆包。

2、待发送数据大于MSS（最大报文长度），TCP在传输前将进行拆包。

3、要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去，将会发生粘包。

4、接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

粘包、拆包解决办法

通过以上分析，我们清楚了粘包或拆包发生的原因，那么如何解决这个问题呢？解决问题的关键在于如何给每个数据包添加边界信息，常用的方法有如下几个：

1、发送端给每个数据包添加包首部，首部中应该至少包含数据包的长度，这样接收端在接收到数据后，通过读取包首部的长度字段，便知道每一个数据包的实际长度了。

2、发送端将每个数据包封装为固定长度（不够的可以通过补0填充），这样接收端每次从接收缓冲区中读取固定长度的数据就自然而然的把每个数据包拆分开来。

3、可以在数据包之间设置边界，如添加特殊符号，这样，接收端通过这个边界就可以将不同的数据包拆分开。

TCP 粘包/拆包的原因及解决方法 - 简书 (jianshu.com) (opens new window)

# socket编程

# socket有几个队列

TCP三次握手建立连接的过程中，内核通常会为每一个LISTEN状态的Socket维护两个队列：

  • SYN队列（半连接队列）：这些连接已经接到客户端SYN；
  • ACCEPT队列（全连接队列）：这些连接已经接到客户端的ACK，完成了三次握手，等待被accept系统调用取走。

# QUIC

Quic 全称 quick udp internet connection [1]，“快速 UDP 互联网连接”，（和英文 quick 谐音，简称“快”）是由 google 提出的使用 udp 进行多路并发传输的协议。

Quic 相比现在广泛应用的 http2+tcp+tls 协议有如下优势 [2]：

  1. 减少了 TCP 三次握手及 TLS 握手时间。
  2. 改进的拥塞控制。
  3. 避免队头阻塞的多路复用。
  4. 连接迁移。
  5. 前向冗余纠错。

科普：QUIC协议原理分析 - 知乎 (zhihu.com) (opens new window)

编辑 (opens new window)
上次更新: 2021/04/26, 21:27:03
网络层(IP,ICMP,ARP)
应用层(HTTP,SMTP)

← 应用层(HTTP,SMTP)→

Theme by Vdoing | Copyright © 2021-2021 小游