网络部分常见问题-CSDN博客

UDP协议具有无连接、不可靠、面向数据报的特点，而TCP是面相连接、可靠传输、面向字节流的。具体来说：UDP协议双方在发送数据前不需要沟通对端是否能正常通信，只需知道对端的IP和端口就可以发送数据；而TCP协议双方在发送数据前会建立连接，确保对端能正常通信，同时沟通双方发送后续数据的细节。UDP不保证数据是可靠、有序的到达对端；而TCP保证数据可靠、有序的到达对端。UDP协议调用接口与应用层或网络层递交数据时以单条数据组织数据报（不会合并数据）；而TCP协议会将数据放入对应的缓冲区，对于传输的数据没有明显的边界，对接收方而言可以按照任意字节进行接收。

三次握手

三次握手是为了确认双方的接收和发送能力是否正常，同时指定双方的初始化序列号并约定最大报文段长度MSS，为后面的可靠性传输做准备；

具体流程：

第一次握手：客户端向服务端发送一个SYN报文（链接发起数据报），此时客户端处于SYN_SENT状态。此报文syn标志位设为1，并设置客户端初始化序列号为n。
第二次握手：服务端向客户端发送一个SYN+ACK报文（连接发起并确认的数据报），此时服务端处于SYN_RCVD状态（此时操作系统为该TCP连接分配TCP缓存与变量）【服务器端在第二次握手时分配资源，客户端在第三次握手时分配资源】。此报文syn和ack标志位设为1，同时也设置服务端初始化序列号x，确认号ack=n+1；
第三次握手：客户端向服务端发送ACK报文（确认数据报），此时服务端处于ESTABLISHED状态；服务端收到ACK报文后也处于ESTABLISHED状态。此报文ack标志位设为1，同时序列号seq=n+1，确认号ack=x+1；纯ACK报文不消耗序列号，下一次发送报文还是用这个序列号。

Ps：MSS（最大报文段长度，可以理解为有效载荷的最大值）

IP头部+TCP头部+有效载荷/MSS <= MTU

MTU（最大传输单元）：46 <= MTU <= 1500

为什么需要三次握手，两次不行吗？

三次握手的目的是为了确认双方的接收和发送能力是否正常，第一次握手验证了客户端的发送和服务端的接收正常，第二次握手验证了服务端的发送正常，但站在服务端的角度看并不确定客户端是否收到了SYN+ACK报文，因此并不能确认客户端的接收是否正常。所以需要第三次握手，才能得出双发的接收和发送能力正常的结论。

同时阻止重复历史连接，例如：A发送一个请求连接报文因为网络问题长时间滞留，到第二次连接通信释放连接后才到B，这是一个失效的请求连接报文，此时B以为是A发送的新的请求连接，于是发出确认字符，如果没有三次握手，该连接建立，但是A并没有发出请求连接，所以B就会一直等待A发送确认字符，这样B等了很久，白白浪费B的资源。

如果纯ACK不需要确认，那如果丢了怎么办

此时客户端处于ESTABLISHED状态，可以像服务端发送数据，例如发的第一个数据报的类型其实是PSH+ACK，同样有确认的作用，然后让服务端连接建立完成。

SYN攻击是什么？

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。客户端在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。

在 Linux/Unix 上可以使用系统自带的 netstat 命令来检测 SYN 攻击

Ps: SYN-ACK 重传次数的问题：服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

四次挥手

第一次挥手：主动断开连接方发送FIN报文，此时主动断开连接方处于FIN_WAIT_1状态，等待被动断开连接方确认。
第二次挥手：被动断开连接方发送ACK报文，此时被动连接方处于CLOSE_WAIT状态。主动断开连接方收到确认后，进入FIN_WAIT2状态，等待被动断开连接方发送的连接释放报文。此时的TCP处于半关闭状态，主动断开连接方到被动断开连接方的连接释放。
第三次挥手：被动断开连接方没有要发送的数据时，被动断开连接方发送FIN报文，此时被动连接方处于LAST_ACK状态，等待主动连接方确认。
第四次挥手：主动断开连接方发送ACK报文，此时主动断开连接方处于TIME_WAIT状态，等待2MSL时间以确保服务器收到ACK报文后变为CLOSED状态。被动断开连接方收到确认后，变为CLOSED状态。

四次挥手释放连接时，等待2MSL的意义?

为了确保主动断开连接方第四次挥手的ACK报文能够到达被动断开连接方，等待2MSL的时候，如果由于网络等一系列原因产生了丢包，1MSL时间内被动断开连接方会超时重传FIN报文，因此等待2MSL时间以保证第四次挥手的ACK报文能够到达被动断开连接方。

确认应答机制

在三次握手建立连接时，连接双方会约定数据的初始序列号，在后续的数据传输时，TCP会给传输数据的每个字节编号，接收方通过确认序号，在ACK报文中告诉发送方期望下一个发送数据的序号（隐含意思就是这个序号之前的数据都收到了）。从而保证数据可靠有序的到达对端。

滑动窗口机制

由于TCP采用确认应答机制，需要等待对端的确认应答报文，如果发一个报文就要等待确认，效率太低。滑动窗口机制允许TCP发送方将发送缓冲区（环形队列）窗口内的多组数据（组成多个TCP数据包）发送到网络，并行传递而暂时不需要立即确认。

如果中间发生数据丢包，接收方会给发送方恢复3次重复的确认应答（这三个ACK的ack=丢包数据的起始序号），发送方收到后，触发快重传，重传该报文。

流量控制机制

TCP考虑传输效率问题，除了从自身发送数据量考虑，还需要考虑对方的接收能力以及网络的转发能力。因此TCP还采用流量控制机制动态改变滑动窗口的大小，从而控制发送的数据量。TCP头部16位窗口大小包含接收缓冲区的接受能力（缓冲区大小），同时发送方还维护了拥塞窗口来探测网络的转发能力，发送方根据接收方的ACK报文返回的窗口大小和自身维护的拥塞窗口大小，来动态调整滑动窗口大小。

五种高级IO模型

IO的过程是在内核当中的过程，分为两步：等待和拷贝数据。

阻塞IO：在内核将数据准备好之前，系统调用会一直等待。

非阻塞IO：如果内核还未将数据准备好，系统调用会直接返回，并返回EWOULDBLOCK错误码（EWOULDBLOCK 就是EAGAIN）阻塞IO需要搭配循环的方式反复尝试读写文件描述符，然而轮循对于CPU来说是巨大的浪费，只有在特定场景才使用。

信号驱动IO：内核将数据准备好的时候，使用SIGIO信号通知应用程序进行IO操作。

IO多路转接：能同时循环监听多个文件描述符的就绪状态。IO多路转接属于阻塞IO，但可以对多个文件描述符进行阻塞监听，所以效率较阻塞IO高

异步IO：由内核在数据拷贝完成后，通知应用程序处理数据（而信号驱动是告诉应用程序去拷贝数据（举例调用recv函数））。当应用程序调用aio_read时，将等待和数据拷贝的任务交给内核，而程序控制权仍然在应用进程，应用进程继续处理其他事情，是一种非阻塞的状态；当内核在数据拷贝完成后，通知应用程序去处理数据。（异步IO是拷贝好了你去处理数据吧，信号驱动IO是数据来了，你去拷贝数据吧）。