【网络八股】TCP八股

请简述TCP/IP模型中每层的作用,典型协议和典型设备

TCP/IP模型中,自顶向下分别为应用层,传输层,网络层,数据链路层、物理层。
应用层典型的协议有:HTTP,HTTPS,FTP协议,SMTP协议,没有典型设备,主要负责产生网络数据,网络数据来源于进程。
传输层典型的协议有:TCP,UDP协议,没有典型设备,主要负责端与端之间的传输,端就指的是端口
网络层典型的协议有:IP协议,ICMP协议,典型的设备是路由器,主要负责路由选择,为网络数据选择一条合适的路由。
数据链路层典型的协议有:以太网协议,典型的设备是交换机,主要负责相邻设备之间的传输。负责将数据从A节点传输到B节点。
物理层典型的协议有:以太网协议,典型的设备是集线器和中继器,主要负责将光电信号转换为二进制数据,或者将二进制数据转换为光电信号。

介绍一下三次握手的过程

要从三个角度来分析:
1.数据包名称
2.双方的状态变化
3.包序的变化

介绍一下四次挥手的过程

要从三个角度来分析:
1.数据包名称
2.双方的状态变化
3.包序的变化

必须三次握手吗,两次不行吗?为什么

不行,从两个角度说明:
1.两次握手之后,站到客户端的角度,认为连接已经建立,但是站到服务端的角度,SYN_RECV状态并没有转换为ESTBASLISH状态,认为连接没有建立
2.只能证明服务端的接收和发送能力是正常的,也能证明客户端的发送能力是正常的,但是不能证明客户端的接收能力也正常

ACK数据包消耗TCP的序号吗

1.纯的ACK数据包是不消耗TCP序号的
2.ACK+SYN,ACK+FIN这类没有包含应用层数据的数据包,消耗1个序号
3.携带应用层数据的数据包,会将应用层数据逐字节进行标记,其消耗的序号为应用层数据的大小

三次握手中可以携带应用层数据吗

可以,但是只能在第三次握手的时候携带数据
如果在第一次和第二次握手的时候携带了数据,如果有人恶意用大量数据访问服务端,就会导致服务端需要消耗大量资源去保存这些数据,是不合理的。
但是在第三次握手的时候,客户端已经认为连接建立了,那么发送数据也是合理的,但是日常在第三次握手的时候就发送数据的场景不多见

四次挥手时,可以携带应用层数据吗?

可以
两次挥手之后,被动断开连接方可以给主动断开连接方发生数据(这个过程发生在两次挥手之后,第三次挥手之前)

主动断开连接方,为什么要等待2MSL时间?

如果是服务端等待2MSL,那么意味着是服务端先断开连接的。
MSL:报文最大生成时间,报文在网络上存在的最长时间
在这里插入图片描述
总结:为了防止主动断开连接方发送的ACK丢失,被动断开连接方会重传FIN报文

详细阐述:主动断开连接方接收到被动断开连接方发送的FIN报文后,变为了TIME_WAIT状态,然后需要等待2MSL,在2MSL的时间内收到被动断开连接方发送的ACK报文后才能变为CLOSED状态,就是由于存在发送的ACK报文在网络中丢失,那么被动断开连接方会重传FIN报文,因此2MSL的时间=自己发送的ACK报文的MSL + 重传FIN报文的MSL。

如果服务端不进行accept,那么最多可以完成多少个连接

listen函数有两个参数

listen(int socket, int backlog)

socket表示的是侦听套接字,是socket函数的返回值,backlog是已完成连接队列的大小
因为服务端会将连接分为未完成连接队列(中放的是正在进行三次握手的连接),已完成连接队列(已经完成三次握手的连接),而未完成连接队列中已经完成的连接会被放入已完成连接队列中

不进行accept的话,最多可以完成backlog+1个连接

服务端最多可以完成多少个TCP连接?

1.服务端完成TCP连接的个数是取决于操作系统的上限
2.操作系统会规定一个值,open files来规定一个进程最多可以打开多少个文件描述符
3.我的机器中看到的是1024,意味着最多能够打开1024个文件描述符,意味着服务端最多可以完成的TCP连接数为1024-3-1,3是一个进程默认的标准输入,标准输出,标准错误,1表示侦听套接字
4.当然open files的值可以通过ulimit -n来进行修改

三次握手中,连接的序号一定从0开始吗?

不一定,初始序号是动态的
1.初始化序号可以看作是32位计数器,这样选择序号的目的在于防止被网络延迟的分组后续又被传输,从而导致错误的解释
2.三次握手中,客户端和服务端互相交换初始化序号,之后的数据包就按照约定的初始化序号向下使用。如果固定为0,则会导致网络攻击者很容易模拟TCP数据包,来攻击服务端。

三次握手中,为什么要协商MSS的长度

MSS:TCP最大传输报文长度,意思是TCP将数据递交给网络层的数据大小。
在三次握手时,双方就MSS大小进行协商,取其较小值。
协商的目的是:
1.如果没有进行协商,如果传递的数据包过大,递交给网络层之后,IP协议会进行分片,而IP协议是不可靠的,如果发生一个分片丢失,那么TCP会认为整个数据包丢失,会重传整个TCP数据包
2.如果TCP交给网络层的数据大小满足MSS,那么IP协议不会进行分片传输

服务端出现大量close_wait状态,是什么原因,有什么危害,应该怎么办?

close_wait状态只会出现在四次挥手的被动断开连接方,也就意味着服务端是被动断开连接方

只有当主动断开连接方发送给被动断开连接方FIN报文之后,被动断开连接方才会从estbalish状态转换到close_wait状态,而进一步转换到last_ack状态需要被动断开连接方调用close函数,进行关闭的操作。

如果服务端出现大量close_wait状态,说明服务端没有调用close函数,进一步的原因可能是:
1.close函数被阻塞
2.执行close函数的线程,在执行到close之前有非常耗时的操作
3.根据实际情况看还有其他的可能导致没有调用到close函数

会导致占用大量的服务端资源

TCP维护的序号最大是多少,超出最大值后序号是多少?

按照TCP包头中32位序号来看,维护的序号范围是0–>4294967295

当超出这个序号的最大范围后,就会发生“序号回绕”,也就是从最大值回到0开始继续向后走。

用无符号char类型来举例:
0-255的范围
如果当前序号在254,接下来有一个4字节的数据包,TCP维护的序号就是255->0->1->2,接下来的序号就是3.

什么是确认应答机制?

当发送方发送一个数据包,接收方需要进行接收确认,返回ack来确认收到了这个数据包
而确认的本质是在确认序号。而序号本质上就是数据,因为TCP对应用层的每个字节都进行了编号

超时重传时间是固定的吗?怎么计算?

超时重传时间(RTO)是不固定的,是随着报文往返时间(RTT)进行动态变化的。
简单的说:RTT时间小,说明网络情况好,则RTO变小,RTT时间长,说明网络情况查,则RTO变大

什么是快重传?快重传存在效率问题吗?

快重传是为了在没有触发超时重传的时候,就触发发送方传递了数据。
本质上是为了提高传输效率的

做法:当发送方连续收到三次同样的确认数据包,就会触发快重传,立即发送丢失的数据包。

是存在效率问题的:主要问题就是当序号为A的数据包已经后续的几个数据包都丢失之后,那么虽然对当前的数据包进行了快重传,但是后续丢失的数据包也需要再次等3次同样的数据包才能触发快重传,这样会导致效率较低。

解决办法 SACK,在TCP头部的40字节选项中,描述接收方收到了哪些数据包,那么在发送方来说,就会知道哪些数据包丢失了,就会触发快重传进行发送。

理解TCP的缓冲区

TCP的缓冲区是操作系统内核中的一块空间。
1.发送缓冲区和接收缓冲区都是环形队列
2.调用send函数,进程产生的数据会被放到发送缓冲区中,TCP会择机将缓冲区的数据发送;
3.调用recv函数,会从TCP的接收缓冲区中将数据拷贝到准备好的空间

理解滑动窗口中的窗口

窗口就是TCP允许暂时不需要收到ACK确认的报文

操作系统会将发送缓冲区分为:已经发送并且已经确认收到的区域,已经发送暂时不需要确认的区域,可以发送但未发送的区域,不能发送的区域

当收到靠后的ack确认之后,窗口可以向后滑动吗?

可以,因为当收到靠后的ack确认之后,意味着靠前的数据包对方是收到的,因此哪些数据包就不需要再保存了,窗口就可以向后滑动了

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值