面试-TCP

面试-TCP面试 TCP 1 画出 TCP 报文 字段 长度 含义 Source Port 16 比特 源端口 标识哪个应用程序发送 Destination Port 16 比特 目的端口 标识哪个应用程序接收 Sequence Number 32 比特 序号字段 TCP 链接中传输的数据流中每个字节都编上一个序号 序号字段的值指的是本报文段所发送的数据的第一个字节的序号

大家好,我是讯享网,很高兴认识大家。

面试-TCP

1.画出TCP报文

在这里插入图片描述
讯享网

字段 长度 含义
Source Port 16比特 源端口,标识哪个应用程序发送。
Destination Port 16比特 目的端口,标识哪个应用程序接收。
Sequence Number 32比特 序号字段。TCP链接中传输的数据流中每个字节都编上一个序号。序号字段的值指的是本报文段所发送的数据的第一个字节的序号。
Acknowledgment Number 32比特 确认号,是期望收到对方的下一个报文段的数据的第1个字节的序号,即上次已成功接收到的数据字节序号加1。只有ACK标识为1,此字段有效。
Data Offset 4比特 数据偏移,即首部长度,指出TCP报文段的数据起始处距离TCP报文段的起始处有多远,以32比特(4字节)为计算单位。最多有60字节的首部,若无选项字段,正常为20字节。
Reserved 6比特 保留,必须填0。
URG 1比特 紧急指针有效标识。它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)。
ACK 1比特 确认序号有效标识。只有当ACK=1时确认号字段才有效。当ACK=0时,确认号无效。
PSH(push) 1比特 标识接收方应该尽快将这个报文段交给应用层。接收到PSH = 1的TCP报文段,应尽快的交付接收应用进程,而不再等待整个缓存都填满了后再向上交付。
RST 1比特 重建连接标识。当RST=1时,表明TCP连接中出现严重错误(如由于主机崩溃或其他原因),必须释放连接,然后再重新建立连接。
SYN(Synchronize Sequence Numbers) 1比特 同步序号标识,用来发起一个连接。SYN=1表示这是一个连接请求或连接接受请求。
FIN 1比特 发端完成发送任务标识。用来释放一个连接。FIN=1表明此报文段的发送端的数据已经发送完毕,并要求释放连接。
Window 16比特 窗口:TCP的流量控制,窗口起始于确认序号字段指明的值,这个值是接收端正期望接收的字节数。窗口最大为65535字节。
Checksum 16比特 校验字段,包括TCP首部和TCP数据,是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。在计算检验和时,要在TCP报文段的前面加上12字节的伪首部。
Urgent Pointer 16比特 紧急指针,只有当URG标志置1时紧急指针才有效。TCP的紧急方式是发送端向另一端发送紧急数据的一种方式。紧急指针指出在本报文段中紧急数据共有多少个字节(紧急数据放在本报文段数据的最前面)。
Options 可变 选项字段。TCP协议最初只规定了一种选项,即最长报文段长度(数据字段加上TCP首部),又称为MSS。MSS告诉对方TCP“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节”。 新的RFC规定有以下几种选型:选项表结束,无操作,最大报文段长度,窗口扩大因子,时间戳。 窗口扩大因子:3字节,其中一个字节表示偏移值S。新的窗口值等于TCP首部中的窗口位数增大到(16+S),相当于把窗口值向左移动S位后获得实际的窗口大小。 时间戳:10字节,其中最主要的字段是时间戳值(4字节)和时间戳回送应答字段(4字节)。 选项确认选项:
Padding 可变 填充字段,用来补位,使整个首部长度是4字节的整数倍。
data 可变 TCP负载。

在这里插入图片描述

2.介绍TCP连接的三次握手?追问:为什么需要进行三次握手。

在这里插入图片描述

在这里插入图片描述

1.主机A发送标志syn=1,随机产生seq =的数据包到服务器,主机B由syn=1知道,A要求建立连接; 此时状态A为SYN_SENT,B为LISTEN
在这里插入图片描述

2.主机B收到请求后要确认连接信息,向A发送ack =(主机A的seq+1),标志syn=1,ack=1,随机产生seq=的包, 此时状态A为ESTABLISHED,B为SYN_RCVD 
在这里插入图片描述

3.主机A收到后检查ack 是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,主机A会再发送ack =(主机B的seq+1),标志ack=1,主机B收到后确认seq值与ack=1则连接建立成功。 此时A、B状态都变为ESTABLISHED

为什么需要进行三次握手?

1.在建立连接时,服务器可以把SYN和ACK放在一个包中发送。

2.假设不采用"三次握手",那么只要 server 发出确认,新的连接就建立了。由于现在 client 并没有发出建立连接的请求,因此不会理睬 server 的确认,也不会向 server 发送数据。但 server 却以为新的传输连接已经建立,并一直等待 client 发来数据。这样,server 的很多资源就白白浪费掉了

3.两次握手还有一个不好的地方,就是会更容易受到 SYN 攻击

3.介绍TCP断开的四次挥手,追问:为什么TCP的挥手需要四次?

四次挥手过程

1.主机A发送位码为FIN = 1,用来关闭客户A到服务器B的数据传送。A的状态为FIN_WAIT_1

2.服务器B收到这个FIN,回复一个ACK,确认序号为收到的序号+1.此时A为FIN_WAIT_2,B为CLOSE_WAIT

3.服务器B关闭与客户端A的连接,发送一个FIN给客户端A。这时A为TIME_WAIT,B为LAST_ACK

4.客户端A发回ACK报文,并将确认序号设置为收到序号+1.这时A,B都关闭,状态变为CLOSED

当2,3步骤中ACK和FIN在同一个包中发送,A的状态会直接从FIN_WAIT_1变为TIME_WAIT

为什么TCP挥手需要四次?

在断开连接时,如果一端收到FIN包,但此时仍有数据未发送完,此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后,再向对端发送FIN,断开这个方向的连接。
  因此很多时候FIN和ACK需要在两个数据包中发送,因此需要四次握手。

4.为什么建立连接需要三次握手,而断开连接需要四次握手?

因为每个方向都需要一个FIN和ACK,当一端发送了FIN包之后,处于半关闭状态,此时仍然可以接收数据包。
  在建立连接时,服务器可以把SYN和ACK放在一个包中发送。
  但是在断开连接时,如果一端收到FIN包,但此时仍有数据未发送完,此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后,再向对端发送FIN,断开这个方向的连接。
  因此很多时候FIN和ACK需要在两个数据包中发送,因此需要四次握手

5.描述TCP和UDP的区别?

  • 1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接
  • 2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保证可靠交付
  • 3、TCP通过校验和,重传控制,序号标识,滑动窗口、确认应答实现可靠传输。如丢包时的重发控制,还可以对次序乱掉的分包进行顺序控制。
  • 4、UDP具有较好的实时性,工作效率比TCP高,适用于对高速传输和实时性有较高的通信或广播通信。
  • 5、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
  • 6、TCP对系统资源要求较多,UDP对系统资源要求较少。

6.TCP的SYN攻击过程?追问:如何防御?

TCP的SYN攻击过程

SYN攻击是基于TCP连接的三次握手的半连接,属于DOS攻击。攻击者发送完第一次握手后,服务器维护一个未连接队列并发送回复,但是攻击者不发送第三次握手的ack,造成服务器会等待,浪费CPU和内存,在半连接存活时间内有大量的半连接就会造成服务器无法服务现象

防御措施

1.降低SYN timeout时间,使得主机尽快释放半连接的占用。

2.采用SYN Cookie设置,如果短时间内连续收到某个IP的重复SYN请求,则认为受到了该IP的攻击,丢弃来自该IP的后续请求报文

3.在网关处设置过滤,拒绝将一个源IP地址不属于其来源子网的包进行更远的路由

7.TCP是如何通过滑动窗口协议实现流量控制和拥塞控制?

流量控制

防止发送方发的太快,耗尽接收方的资源,从而使接收方来不及处理

(1)接收端抑制发送端的依据:接收端缓冲区的大小
(2)流量控制的目标是接收端,是怕接收端来不及处理
(3)流量控制的机制是丢包

实现流量控制

使用滑动窗口
滑动窗口
1.滑动窗口是什么?
滑动窗口是类似于一个窗口一样的东西,是用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小,这样就可以实现。

当一个连接建立时,连接的每一端分配一个缓冲区来保存输入的数据,并将缓冲区的尺寸发送给另一端。当数据到达时,接收方发送确认,其中包含了自己剩余的缓冲区尺寸。剩余的缓冲区空间的大小被称为窗口( w i n d o w) ,指出窗口大小的通知称为窗口通告(window advertisement) 。接收方在发送的每一确认中都含有一个窗口通告。

如果接收方应用程序读数据的速度能够与数据到达的速度一样快,接收方将在每一确认中发送一个正的窗口通告。然而,如果发送方操作的速度快于接收方(由于CPU更快) ,接收到的数据最终将充满接收方的缓冲区,导致接收方通告一个零窗口( zero window) 。发送方收到一个零窗口通告时,必须停止发送,直到接收方重新通告一个正的窗口。

拥塞控制

防止发送方发的太快,使得网络来不及处理,从而导致网络拥塞。

流量控制和拥塞控制的联系和区别

相同点

  • 1.现象都是丢包
  • 2.实现机制都是让发送方发包降速

不同点

1.丢包位置不同

  • 流量控制丢包位置是在接收端上
  • 拥塞控制丢包位置是在路由器上

2.作用的对象不同

  • 流量控制的对象是接收方,怕发送方发的太快,使得接收方来不及处理。
  • 拥塞控制的对象是网络,怕发送发发的太快,造成网络拥塞,使得网络来不及处理

联系

拥塞控制:拥塞控制通常表示的是一个全局性的过程,它会涉及到网络中所有的主机、 所有的路由器和降低网络传输性能的所有因素。

流量控制:流量控制发生在发送端和接收端之间,只是点到点之间的控制

8.TCP有哪些定时器?

1.建立连接定时器(connection-establishment timer)

在建立TCP连接的过程中,在发送SYN时, 会启动一个定时器(默认应该是3秒),如果SYN包丢失了, 那么3秒以后会重新发送SYN包的(当然还会启动一个新的定时器, 设置成6秒超时),当然也不会一直没完没了的发SYN包, 在/proc/sys/net/ipv4/tcp_syn_retries 可以设置到底要重新发送几次SYN包。

2.重传计时器(Retransmission Timer)

为了控制丢失的报文段或丢弃的报文段,也就是对报文段确认的等待时间。

当TCP发送报文段时,就创建这个特定报文段的重传计时器。可能发生两种情况:若计时器超时之前收到对报文段的确认,则测下喔计时器;若在收到对特定报文段的确认之前计时器超时,则重传该报文,并把计时器复位。

3.延迟应答定时器(delayed ACK timer)

延迟应答也被成为捎带ACK, 这个定时器是在延迟应答的时候使用的。 为什么要延迟应答呢? 延迟应答是为了提高网络传输的效率。

举例说明,比如服务端收到客户端的数据后, 不是立刻回ACK给客户端, 而是等一段时间(一般最大200ms),这样如果服务端要是有数据需要发给客户端,那么这个ACK就和服务端的数据一起发给客户端了, 这样比立即回给客户端一个ACK节省了一个数据包

4.坚持计时器(Persistent Timer)

专门为零窗口同时设计

当发送端收到零窗口的确认时,就启动坚持计时器,当坚持计时器截止期到时,发送端TCP就发送一个特殊的报文段,叫探测报文段,这个报文段只有一个字节的数据。探测报文段有序号,但序号永远不需要确认,甚至在计算对其他部分数据的确认时这个序号也被忽略。探测报文段提醒接收端TCP,确认已丢失,必须重传。

坚持计时器的截止期设置为重传时间的值,但若没有收到从接收端来的响应,则发送另一个探测报文段,并将坚持计时器的值加倍和并复位,发送端继续发送探测报文段,将坚持计时器的值加倍和复位,知道这个值增大到阈值为止(通常为60秒)。之后,发送端每隔60s就发送一个报文段,直到窗口重新打开为止;

5.保活计时器(Keeplive Timer)

每当服务器收到客户的信息,就将keeplive timer复位,超时通常设置2小时,若服务器超过2小时还没有收到来自客户的信息,就发送探测报文段,若发送了10个探测报文段(每75秒发送一个)还没收到响应,则终止连接。

6.FIN_WAIT_2定时器(FIN_WAIT_2 timer)

主动关闭的一端调用完close以后(即发FIN给被动关闭的一端, 并且收到其对FIN的确认ACK)则进入FIN_WAIT_2状态。如果这个时候因为网络突然断掉、被动关闭的一段宕机等原因,导致主动关闭的一端不能收到被动关闭的一端发来的FIN,主动关闭的一段总不能一直傻等着,占着资源不撒手吧?这个时候就需要FIN_WAIT_2定时器出马了, 如果在该定时器超时的时候,还是没收到被动关闭一端发来的FIN,直接释放这个链接。

7.时间等待计时器(Time_Wait Timer)

在连接终止期使用,当TCP关闭连接时,并不认为这个连接就真正关闭了,在时间等待期间,连接还处于一种中间过度状态。这样就可以使重复的FIN报文段在到达终点后被丢弃,这个计时器的值通常设置为一个报文段寿命期望值的两倍。

9.有哪些应用层协议基于TCP,哪些基于UDP?

TCP:FTP,HTTP,HTTPS,Telnet,SMTP,POP3,DNS

UDP:DNS,SNMP,NFS

10.TIME_WAIT状态持续时间及原因

TIME_WAIT状态也称为2MSL等待状态。每个具体YCP实现必须选择一个报文段最大生存时间MSL(MAXimum Segment Lifetime)。任何报文段被丢弃前在网络内的最长时间

RFC 793 [Postel 1981c]指出MSL为2分钟。然而,实现中的常用值是30秒,1分钟,或2分钟。

当TCP执行一个主动关闭,并发回最后一个ACK,该链接必须在TIME_WAIT状态停留的时间为2倍MSL。这样可让TCP再次发送ACK以防这个ACK丢失(另一端超时并重发最后的FIN)

持续时间未2MSL,一个数据包在网络中的最长生存时间为MSL。假设最后客户端回复的ACK丢失,服务器端会在超时时间到来时,重传最后一个FIN包。

ACK和FIN在网络中的最长生存时间就为2MSL,这样就可以可靠的断开TCP的双向连接。

(后续补充)

小讯
上一篇 2025-03-15 23:27
下一篇 2025-04-03 23:13

相关推荐

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/24795.html