OSI与TCP/IP的各层的结构，都有哪些协议呢？

哦，我好像知道，我说一下我的理解，这个主要有两种参考模型，一种是基于OSI的参考模型，可以分为7层，分别是：物理层、数据链路层、网络层、运输层、会话层、表示层和应用层；另一种是基于TCP、IP的参考模型，可以分为4层，分别是：网络接口层、网络层、运输层和应用层。

关于每一层的协议，我知道的还不少呢，我来说说我知道的吧。

应用层：RIP、FTP、DNS、Telnet、SMTP、HTTP、WWW

我知道的还不少吧，嘚瑟一下，让我一口气说完吧。

表示层：JPEG、MPEG、ASCII，MIDI 会话层：RPC、SQL 传输层：TCP、UDP、SPX 网络层：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGMP 数据链路层：PPP、HDLC、VLAN、MAC 物理层：RJ45、IEEE802.3

你能解释一下RJ45吗？

嗯嗯嗯，你自己查一下吧。。。

你能说说三次握手和四次挥手吗？

三次握手需要经过下面的过程状态：

• LISTEN：表示服务器的某个Socket处于监听状态，可以接受连接了。
• SYN_SENT：当客户端socket执行connet连接时，它首先发送一个SYN报文，紧接着进入SYN_SENT状态，并等待服务端发送三次握手中的第2个报文。
• SYN_RCVD：这个状态表示收到了SYN报文，在正常状态服务端的socket在建立TCP连接时的三次握手会话中的一个中间状态，但是，需要注意的是netstat是很难看到这种状态。当客户端收到服务端的ACK后，服务端就进入到了ESTABLISHED状态了。
• ESTABLISHED：表示已经建立连接了。

四次挥手过程状态：

• FIN_WAIT_1：这个状态其实是在建立连接时，一方想要主动关闭连接，然后向对方发送FIN报文，然后自己进入到此状态；同时，当对方回应ACK后，自己就进入到FIN_WAIT_2状态，FIN_WAIT_1也是比较难以看到的。（主动方状态）
• FIN_WAIT_2：这个状态是当主动要求关闭的一方要求关闭时，但暂时还有数据需要传输，稍后再关闭。（主动方状态）
• TIME_WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，等待2MSL后即可回到CLOSED可用状态了。（主动方状态）
• CLOSE_WAIT：该状态表示在等待关闭，当对方发送FIN报文给自己时，你会发送一个ACK报文给对方，此时就进入到了CLOSE_WAIT状态。接下来，实际上你真正需要考虑的就是你是否还有数据发送给对方，如果此时没有了，那么你就可以close这个SOCKET了，发送FIN报文给对方，关闭连接。（被动方状态）
• LAST_ACK：状态是指被动方发送FIN报文后，最后等待对方的ACK报文，收到后，就可以进入到CLOSED状态。（被动方状态）
• CLOSED：表示连接中断。

结合上方的解释和两张图，就可以很好的理解三次握手和四次挥手的整个过程的，这个还是比较重要的，很多面试中都会考察，这也是计算机网络最基础的知识。

在TIME_WAIT状态中，如果TCP客户端的最后一次发送的ACK丢失了，会发生什么？

如果丢失了，此时会触发重发机制，因为，在此状态下，等待的时间是依赖于实现方法的，一般可以为30s、1min和2min。等待结束后，就关闭连接了，并且所有的资源都会释放。

为什么收到Server的确认之后，client还需要进行第三次握手？

可能由于网络连接延时，已经失效的连接到达服务端，这时服务端以为是客户端的请求，所以发送ack到客户端，�然后等待�客户端的数据传输过来，然而，此时，客户端并没有想要进行连接（因为此时客户端没有发出连接），因此，如果不采用三次握手，进行客户端确认，服务端就会一直等待客户端，导致服务端的资源白白浪费。

为什么要采用四次挥手

确保数据能够完全传输。 挥手的过程是：主机1发送Fin，表示我没有数据要发送了，然后，主机2发送ACK进行确认，但是，这个时候，主机2还是可以发送数据给主机1的，不能就�关闭连接，所以，只有当主机2也发送了Fin之后，才可以进行关闭。

time _wait状态产生的原因

• 可靠的实现tcp全双工连接的终止：考虑网络是不可靠的，当客户端发送ACK服务端一定收到了，如果没有收到，可以重发，如果客户端在time-wait状态等待2MSL时长，还没有收到服务的的FIN，就可以关闭自己的连接了。
• 允许老的重复连接在网络中消逝：网络中可能存在已经失效的连接，time-wait可以使得本连接持续的时间内产生的所有的连接都在网络中消逝，不会出现旧的连接了。

time-wait过多的危害

本地端口数量有限，如果有大量的time-wait，会发现本地用于新建连接的端口缺乏，本地很难再建立新的对外连接。

如何消除大量TCP短连接引发的time—wait

• 改为长连接
• 增大可用端口

当关闭连接时，最后一个ACK丢失怎么办

如果在time-wait状态下，最后一个ACK丢失，由于有两个MSL时长等待，所有，会有新的FIN从服务端发送过来，这时，客户端会重新发送ACK。 如果在closed状态下，客户端收不到服务端重传的FIN，客户端也不会重传ACK，那么服务端就永远无法关闭链接。

TCP如何保证可靠传输

• 在传递数据之前，会有三次握手来建立连接
• TCP会将数据分割为最合适发送的数据块，也就是分割为合理的长度
• TCP发出一个段后，会启动定时器，等待目的端确认，如果不能收到确认，就会重发，这也就是超时重发机制
• 当TCP收到另一端的数据时，会向对方发送一个确认，通常会延迟一点发送，这是因为需要对包的完整性进行验证
• TCP将保持首部和数据的检验和。目的是为了保证数据在传输过程中的任何变化，如果收到的段的检验和由差错，TCP会丢弃这个报文段和不确认收到此报文段
• TCP会对失序的数据进行数据重新排序，然后再交给应用层
• TCP会丢去重复的数据
• TCP会进行流量控制。TCP的连接每一方都有一个固定大小的缓冲空间，其只允许接收端只允许另一端发送接收端缓冲区能接纳的数据，这可以防止缓冲区溢出。需要注意的是：TCP使用的流量控制协议是可变大小的滑动窗口协议
• TCP会进行拥塞控制，当网络拥塞时，会适当的减少数据的发送。

TCP建立连接之后，怎么保持连接？

目前保持连接的方式有两种技术实现，第一，采用TCP协议层实现的Keepalive机制，第二，由应用层实现的HeartBeat心跳包。

Keepalive机制 该机制的原理是：TCP协议会向对方发一个keepalive探针包，对方收到包之后，正常会回复一个ACK，出现错误会回复一个RST，如果对方没有任何回复，服务器每隔一段时间再发送keepalive探针包，如果连续发送多个包之后都没有回复，则说明连接断开。

心跳包机制 该机制原理是：客户端或者服务端会发送一个类似心跳一样每隔固定时间发送一次，客户端在一定时间内没有收到服务端的回应，则可认为服务端不可用，同上，如果服务端在一定时间内没有收到客户端发送的心跳包，则认为客户端掉线。

TCP三次握手有哪些漏洞?

一是，DDOS攻击（分布式拒绝服务）：利用攻击软件通过大量的机器同时对服务进行攻击，规模大，危害大。

目前有两种主流的DDOS攻击：SYN Flood攻击和TCP全连接攻击。

• SYN Flood攻击：利用tcp协议的缺陷，发送大量伪造的tcp连接请求，导致被攻击方资源耗尽。出现的原因是：在TCP三次握手过程中，假设用户发送了SYN报文后掉线，那么服务器在发出SYN+ACK是无法收到客户端的ACK报文，这时，服务端是会一直不断的重试并等待一段时间后丢弃这个未完成的连接的，如果有大量的伪造的攻击报文，发送到了服务端，服务端将为了维护一个非常大的半连接队列而消耗过多的CPU时间和内存，这就会导致服务器失去响应。
• TCP全连接攻击：这种攻击是为了绕过防火墙设计的，它能够绕过防火墙，导致服务器有大量的TCP连接，最终导致服务器拒绝服务。

解决SYN Flood攻击的方法

• 设置SYN timeout时间：SYN timeout时间是指服务端一直不断的重试并等待的这段时间。
• 设置SYN cookie，判断是否连续收到某个ip的重复SYN报文，如果是，以后就丢弃这个ip地址的包
• 设置SYN cache，先不分配系统资源，现用cache保存半开连接，直到收到正确的ACK在分配资源
• 硬件防火墙

解决TCP全连接攻击的方法

• 限制SYN流量
• 定期扫描缺陷
• 在骨干节点设置防火墙
• 有足够的机器可以承受攻击
• 过滤不必要的服务和端口

二是，Land攻击，该攻击是利用了TCP三次握手时，通过向一个主机发送一个用于建立连接的TCP SYN报文而实现对目标主机的攻击，这种方式与正常的TCP SYN报文不同的是：Land攻击的报文源ip地址和目标ip地址是一样的，都是目标主机的ip地址。

由于目标IP地址和源IP地址是一样的，因此，ACK报文就发给了主机本身，如果大量的SYN报文进行发送，目标计算机也不能正常工作。

tcp如何实现流量控制和拥塞控制？

流量控制采用滑动窗口机制。 拥塞控制采用拥塞避免方法。

滑动窗口原理 TCP是全双工通信，因此每一方的滑动窗口都包括了接收窗口+发送窗口，接收窗口负责处理自己接收到的数据，发送窗口负责处理自己要发送出去的数据。滑动窗口的本质其实就是维护几个变量，通过这些变量将TCP处理的数据分为几类，同时在发送出一个报文、接收一个报文对这些变量做一定的处理维护。 （1）N是发送窗口的起始字节，也就是说：字节序号 < N的字节都已经发送出去且已经收到ack，确认无误了； （2）nextSeq就是下一次发送报文的首部Seq字段（Seq即b第一个字节的序号，这些这里不讲了），表示字节序号在 [N,nextSeq)区间的都已经使用过，发送出去了，但是还未收到ack确认； （3） N+size就是窗口的最后一个可用字节序号，size是发送窗口的大小，就是每次接收到的报文中的Win字段的值，Win字段其实就是对方接收窗口的大小。 如何让维护这几个值呢？ （1）每接收到一个一个报文要做如下事情：检查接收报文的ack，将N 置为 ack，即往前移到ack这个值；读取报文中的Win字段值，即对方的最新接收窗口大小，从而更新N+size的值。 （2）每发送一个报文，就更改nextSeq的值，发送了多少个字节就把nextSeq往前移多少，但是不要超出N+size。

拥塞避免方法 慢启动、拥塞避免、快重传和快恢复

以上是两张原理图，根据这两张原理图应该可以比较好理解，如果想要深入理解，可以参考这篇文章：https://www.cnblogs.com/a3192048/p/12241296.html。

经典问题：TCP和UDP的区别？

• TCP基于连接的协议，UDP是无连接的协议。
• TCP可以保证数据发送的可靠性，UDP不可靠。
• TCP可以重排序，UDP不可以。
• TCP速度慢，UDP较快。
• TCP是重量级协议，UDP是轻量级协议。
• TCP有流量控制和拥塞控制机制，UDP没有。
• TCP面向字节流的协议，UDP面向报文。
• TCP只能单播，不能发送广播和组播，UDP可以。

TCP应用场景： 效率要求不高，但需要数据的准确性，例如，文件传输、邮件传输、远程登录等等。 UDP应用场景： 效率要求高，准确性要求不高，例如，微信视频，语音聊天等。

为什么TCP比UDP安全，还有人用UDP、为什么UDP快?

• UDP不需要建立连接.
• UDP不需要维护连接的状态.
• UDP头部开销小，只需要�8字节.
• UDP没有拥塞控制，不会影响主机的发送频率，所以�速度上比tcp有优势.