当前位置：首页 > news >正文

网络基础二——TCP可靠性实现机制补充2

news 文章来源：https://blog.csdn.net/qq_33093885/article/details/137411951 2024/10/29 12:26:42

验证客户端和服务端三次握手和四次挥手时的状态

三次握手

#include <sys/types.h>        
#include <sys/socket.h>
int listen(int sockfd, int backlog);

netstat ntp
//查看连接的状态

将TCP服务端套接字设置为listen状态之后，此时服务端是处于LISTEN状态的；服务端没有使用accept接口时，在收到客户端的连接请求时双方会经历3次握手，最终都处于ESTABLISHED状态；即连接的建立和accept没有关系，三次握手是双方操作系统自动完成的；

当listen的第二个参数设为一时，能建立全连接的连接数是2；操作系统会将没有被上层accept的连接管理起来，对它们先描述再组织，并且以队列的方式管理这些连接结构；三次握手时每次形成的连接本质上就是创建一个连接结构体对象并将其链入到队列当中，而accept就是从队列中将连接取走和特定的文件关联起来，返回特定的文件描述符；listen的第二个参数+1表示已经建立好的连接队列的最大长度，这个队列叫做全连接队列；accept和连接入队还有全连接队列构成了CP模型；服务端三次握手完成或者建立连接成功就将连接入队列，如果队列满了就无法入队列了，就会将连接状态设置为SYN_RECV状态，换句话说就是因为全连接队列满了，服务端将客户端发送过来的第三次握手应答报文直接丢弃了；

如果服务端长时间无法得到应答就会释放掉SYN_RECV状态的连接，这种连接叫做半连接；半连接也需要进行管理，所以也会存在半连接队列，节点并不会长时间维持；

这样就出现了客户端和服务器连接不一致的问题；服务端直接将应答丢弃，但是确实是收到了应答，所以第二次握手是可靠的，知道客户端建立连接成功了，并不会发送RST标志位；对于客户端建立连接成功了，但是发送数据不成功，就转而继续开始进行三次握手；

大量建立半连接会导致真正地SYN洪水；服务器资源有限制不会挂掉，但是其他客户端就无法正常的访问了；

全连接队列长度不可以太长，因为上层处理繁忙时，就无法保证将全连接队列获取完，而队列长度过长就会导致资源闲置，维护还要有成本，而且变相地减少了上层空间，降低了处理的效率；而队列的存在可以保证，半连接变成全连接和全连接被上层处理可以并发运行；所以一般全连接队列的长度一般要设置为10左右；

四次挥手

当客户端关闭连接时，服务端的连接会处于CLOSE_WAIT状态，由于服务端不关闭连接，会维持此状态维持一段时间，直到关闭连接时，才会将此状态改为LAST＿ACK，收到应答后关闭连接；

主动关闭连接的一方最终会先处于TIME_WAIT状态(连接没有完全断开)，一般维持60-120s的时长，这时候就不可以重新绑定端口号，因为连接没有完全断开意味着IP和端口号还在被使用，并且一个端口号只能绑定一个进程，所以重启服务会失败，得等待60-120s；对于一个服务器不可以立即重启会产生很大的损失，所以需要修改此状态，进行地址复用；

#include <sys/types.h>          /* See NOTES */
#include <sys/socket.h>
int getsockopt(int sockfd, int level, int optname,void *optval, socklen_t *optlen);
int setsockopt(int sockfd, int level, int optname,const void *optval, socklen_t optlen);//将TIME_WAIT的IP和端口号复用；
//第一个参数是要被修改属性的套接字，第二个参数一般是SOL_SOCKET表示在套接字层，第三个参数表示操作名字，如：复用IP和端口号，第四个参数表示将选项设置为有效；
int opt = 1;
setsockopt(listensockfd_, SOL_SOCKET, SO_REUSEADDR|SO_REUSEPORT, &opt, sizeof(opt));
//这样就可以重新建立好连接了

客户端能够立即重连是因为使用的是系统分配的随机端口号，所以重连时的端口号与上一次不一样，就不会出现绑定失败的情况；

MSL：数据报在网络中最多存活的时长；

TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态；MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s；可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值；

1.TIME_WAIT等待两个MSL时间是因为要让历史数据在网络中消散(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的)；序号一般是随机的，防止黑客的恶意攻击和历史保温的影响；

2.让断开连接四次挥手具有较好的容错性；

最大存在时长不等于最大传送时长；还包括了异常的路由阻塞时间；一般TIME_WAIT时长为60-120秒；如果没有accept可能就会没有TIME_WAIT状态，直接关闭；

11.3.7流量控制

流量控制不仅保证了可靠性，而且提高了效率；捎带应答也是保证可靠性并且提高效率；

流量控制，发送方通过接收到接收方发送过来的报头(16位窗口大小)知道接收方接收缓冲区剩余空间的大小，进而调整发送速度；

对于第一次发送数据报文时，也要保证发送的数据量是合理的；因为正式通信交换数据之前，要通过进行三次握手来可靠的建立连接，这期间是发送了报文的，通信双发都可以得知对方接收缓冲区的剩余空间大小，也可以携带16位窗口大小；

第三次握手的时候其实是可以携带数据的，即可以是携带应答；

当接收方的接收缓冲区写满了，发送发继续发送报文会产生丢包，为了大规模的减少这种问题，就需要进行流量控制；1.发送方会定期的向接收方发送窗口探测(仅仅是一个报头，不携带数据，所以丢失不会产生大影响)，当发送方收到窗口探测应答，则说明有空间了或者接收端返回了上次数据报文的应答也可以说明有空间了；2.接收方会主动发送窗口更新消息(也是一种报头)；

以上两种方式一起使用选择最优的，一定程度上提高了效率，而且两种方式提高了容错性；

如果两种方式是执行了一定次数后还没有成功就会认为网络异常并且关闭连接；

TCP窗口大小(接收缓冲区的大小)默认最大就是65535字节，但是可以配合TCP首部40字节的选项窗口扩大因子M使用，实际的窗口大小就是窗口字段的值左移M位，这还与操作系统实际提供多大的缓冲区有关；

11.3.8滑动窗口

如果串行的发送数据报文加确认应答，确实可以保证可靠性，但是效率太低；所以除了控制使用串行的方式，常规都是使用并行的方式发送一批数据报文后才接受一批确认应答；没有收到应答就会使用超时重传机制；

为了保证数据的可靠性需要在设置的特殊时间间隔里将大量的发送数据报文管理起来；这些数据报文本来就存在于发送缓冲区，没必要专门再拷贝一份的方式维护，只需要将发送缓冲区进行划分即可；

可以简单地划分为三部分从左往右依次为已发送已确认区域，已发送未确认区域，待发送区域；对于已发送已确认的区域是可以被覆盖的；已发送未确认区域可以继续发送数据，即支持发送一批数据，如果没有收到应答就继续维护此数据，如果收到了应答就将此数据移动到已发送已确认区域，表示此数据已经被清理掉；已发送未确认区域就叫做滑动窗口；

滑动窗口是发送缓冲区的一部分；

滑动窗口的数据是可以直接发送给接收方的，这样就可以一次性发送一批数据报文，等到接收到应答时，在将数据移动到另一个区域，不再维护；如果没有收到应答，就可以进行补发；

滑动窗口的大小默认是接收方的16位窗口大小，但是还需要考虑到网络的情况；

对于发送缓冲区区域的划分可以使用双指针的方式(数组下标)如：win_start，win_end，来划分成三个区域；维护发送缓冲区其实就是修改这些特殊下标缓冲区；

收到确认就是应答就是将start右移，如果接收方的接收缓冲区变大了，就将end右移使得滑动窗口变大；这样的过程就像是在滑动；换句话说滑动的本质就是指针的右移；

网络是不支持发送大块数据的，只能分段发送；

验证客户端和服务端三次握手和四次挥手时的状态

11.3.7流量控制

11.3.8滑动窗口

相关文章：