请简述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确认之后，意味着靠前的数据包对方是收到的，因此哪些数据包就不需要再保存了，窗口就可以向后滑动了