我是靠谱客的博主 野性鸭子,这篇文章主要介绍常见TCP/IP协议栈相关问题TCP相关UDP相关,现在分享给大家,希望可以做个参考。

文章目录

  • TCP相关
  • UDP相关

TCP相关

  1. TCP三次握手过程
    在这里插入图片描述

  2. TCP四次挥手过程
    在这里插入图片描述

  3. 为什么建立连接需要三次握手,而断开连接需要四次挥手
    三次握手主要是提供一种确认机制,防止之前已经因分组丢失而失效的连接请求突然又重传到了服务端,导致服务端误以为客户端又发起了一次连接;那么断开连接时需要四次挥手,主要是由于TCP是双向通信的,读写是不同的两个通道,服务端的读通道被关闭后写通道的数据可能还未发送完毕,因此两个通道需要分开来发送FIN包及其ACK包,就出现了一般情况下的四次挥手。

  4. TIME_WAIT 状态持续时间及原因
    持续时间是最长分节生命期MSL的2倍。这个值是与系统有关的。为什么需要 TIME_WAIT?1)在某个方向上的分组最多存活MSL秒就会被丢弃,往返一次就是2MSL,这确保了老的重复分组在新连接建立后已被丢弃而不会再次出现。2)若最后一个ACK丢失,需要重传这个ACK,因此需要延时关闭连接,这可以可靠地实现TCP双向连接的正确终止。

  5. 慢启动
    最大报文段:即我们说的一个包,大小为MSS,在SYN阶段互相通知对方这个值。
    分组:一次发送多个包称为一个分组
    拥塞:分组丢失意味着网络发生了拥塞。当拥塞发生时,我们希望降低分组进入网络的速率。
    慢启动是拥塞控制的第一步,使连接建立后发包(每个包大小MSS)的速率(一次发多少包)以指数级缓慢增长而不是立即开始就以滑动窗口大小win为准进行大量发包,它引入了一个拥塞窗口(cwnd,单位依然为字节而不是包数),cwnd初始化1个MSS,然后每收到一次ACK就乘2,一次可发的数据量为min{cwnd, win},最终为win。它避免建立初始就发出大量的数据包导致较慢的链路出现一些问题如大量分组丢失又大量重传。

  6. 拥塞避免
    慢启动虽然可以解决连接初始的拥塞问题,但其cwnd不断增大的过程中不可避免地可能超过链路的极限,再次导致拥塞。拥塞的直接现象:超时和收到重复的ACK。拥塞避免算法一般与慢启动混在一起,它又增加了一个门限值ssthresh,初始化为65535。当cwnd ≤ ssthresh时,认为连接处于慢启动控制阶段;否则认为连接处于拥塞避免控制阶段。
    慢启动控制阶段:发送数据量依然以2倍2倍地增长;
    拥塞避免控制阶段:发送数据量每次增加1个MSS,变成一种加性增长;
    收到重复ACK的拥塞:ssthresh变为cwnd的一半(严格地说是min{cwnd, win}的一半且最小2个MSS),连接立即进入拥塞避免阶段,发包数的增长速度变为加性;
    超时的阻塞:除了上面这一步外,cwnd变回1个MSS,此时重新进入慢启动;(似乎可以认为超时比重复ACK要严重)
    在这里插入图片描述

  7. 超时重传、快速重传和快速恢复
    重传定时器用于超时重传算法,每重传一次后的超时时间值由又会增加一倍直至64秒,这就是所谓指数退避。
    当连续收到3个或3个以上的重复ACK时,这很可能意味着报文丢失了,此时我们立即重传丢失的报文段,而不需等到超时定时器溢出,即所谓快速重传算法。
    显然快速重传与前面说的拥塞避免有交集,此时超时定时器并没有超时,因此进入了拥塞避免阶段。此时cwnd继续加性增长,最终还是可能引起严重拥塞导致的超时而进入慢启动。于是我们会想:虽然刚刚发生拥塞时就采取慢启动会立即减少发送的数据量进而减缓拥塞,但慢启动相当于熄火后再启动,速度跳变太大了,而且能收到重复ACK说明网络拥塞还没有那么严重,对于刚开始有点拥塞的网络似乎没有必要这样一刀切。那能不能不要直接熄火而只是把速度降低一些?这时就引入了快速恢复。(可以理解为如果立即采取慢启动措施就是慢速恢复了)
    现在拥塞避免阶段实际由快速重传和快速恢复共同完成。
    实际上,引入快速重传和快速恢复后,收到3次重复ACK时,除了会1)将ssthresh变为cwnd的一半,2)还会令cwnd = ssthresh + 3×MSS,毕竟至少有3个分组是已确认收到的了;3)之后如果继续接收到重复ACK(可能中间丢了很多个分组),则cwnd每次加1个MSS(即加性增长),此时允许cwnd继续增长是因为收到一个ACK就意味着对端还是能够收到分组的;4)当下一个正常收到最新数据的ACK返回时,立即令:cwnd = ssthresh,此时相当于cwnd变为了发生拥塞前的一半,也就是速度只降了一半,比起慢启动直接熄火要好一些。在第4步中,最新的ACK实际上包含了对快速重传的分组以及发生快速重传前那些已经被正常接收了的分组的确认,因为重传之后后面的数据还会继续照常传输而不会停在那里等待这个重传的分组确认。

在这里插入图片描述

  1. 总结一下传输过程的拥塞控制:
    1 连接刚建立时开始发数据:执行慢启动,cwnd以指数级增长;
    2 cwnd大于ssthresh时:进入拥塞避免,cwnd加性增长;
    3 出现连续3次重复ACK,则快速重传该丢失的分组,并令ssthresh = cwnd / 2cwnd = ssthresh + 3×MSS;重传分组与新数据被确认后,立即令cwnd = ssthresh,完成快速恢复。
    4 若重传定时器超时,拥塞很严重,进入慢启动;
    在这里插入图片描述

  2. TCP首部长度,有哪些字段
    在这里插入图片描述

  3. TCP在listen时的参数backlog的意义
    backlog指示了全连接队列的容量大小。参考

  4. accept发生在三次握手的哪一步?
    在这里插入图片描述
    Syn队列又称半连接队列,Accept队列又称全连接队列。
    accept()实际是从Accept队列取出连接的节点,并分配给它一个fd。其实这个节点被称为TCP控制块tcb。

    那么操作系统是如何找到某个连接的客户端对应的节点的?通过socket的五元组。
    此外,队列中的tcb节点的生命周期是什么样的?其将伴随整个连接建立过程,若连接过程失败,重传也没有响应,则生命周期提前结束。

  5. 三次握手过程中有哪些不安全因素?
    SYN泛洪攻击等。参考

  6. TCP是如何保证数据顺序正确的?
    超时重传,包含快速重传,然后根据序号对数据重新排序。关于重传机制的参考

  7. TCP的缺点
    1 ack确认时间长;
    2 重发次数较多;

  8. 关闭连接过程几种情况的分析
    服务端出现大量close_wait是什么情况?
    ——客户端关闭连接后,服务端没有及时调用close关闭socket
    服务端出现大量time_wait是什么情况?
    ——服务端主动调用了close,此时要查一下服务端的逻辑是否合理
    ——如果逻辑合理,则应设置 SO_REUSEADDR
    服务端出现大量fin_wait_1、fin_wait_2是什么情况?
    ——服务端主动调用close后,对端一直不调用close。要结束这种状态,只能通过kill让操作系统去回收进程资源。

  9. 描述TCP协议时主要涵盖三个方面:
    连接建立、数据传输(慢启动、拥塞避免、重传等),连接关闭。上面都有涉及。

  10. 四个定时器
    1 超时重传定时器
    2 坚持定时器——persist,对端告知窗口为0了不要发送了,但坚持要发送,只不过要等时间到了就查询一下现在是否有窗口,有则继续发送;
    3 KeepAlive探活定时器
    4 TIME_WAIT状态定时器

UDP相关

  1. UDP主要用在哪里?
    大数据量下载(如迅雷)
    实时性要求高的游戏
    DNS协议(但多个域名服务器之间同步数据是用TCP)

  2. UDP的缺点
    两端建立联系的过程:多个客户端并发向一个服务端端口发数据时可能出现脏数据,即多个数据包出现乱序。

  3. UDP的并发怎么做?
    服务端recvfrom一个客户端后,新建一个socket fd,sendto到这个客户端,之后就用这个fd跟这个客户端通信。这是因为一个fd就有一个自己的recvbuffer,这样就不会出现脏数据的问题。

  4. UDP的首部
    在这里插入图片描述

最后

以上就是野性鸭子最近收集整理的关于常见TCP/IP协议栈相关问题TCP相关UDP相关的全部内容,更多相关常见TCP/IP协议栈相关问题TCP相关UDP相关内容请搜索靠谱客的其他文章。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(100)

评论列表共有 0 条评论

立即
投稿
返回
顶部