• 网络编程基础(二):TCP/IP协议基础:TCP信息头、TCP状态机与握手/挥手、TCP的粘包和粘包、SYN超时与SYN Flood攻击、TIME_WAIT


    一. TCP基础原理

    1. TCP头的格式 和 segment

    1.1. TCP头的格式

    TCP的包是没有IP地址的,那是IP层上的事。但是有源端口和目标端口。一个TCP连接需要四个元组来表示是同一个连接(src_ip, src_port, dst_ip, dst_port)准确说是五元组,还有一个是协议。

    在这里插入图片描述

    头中四个重要的参数:

    参数说明
    Sequence Number包的序号,用来解决网络包乱序(reordering)问题。
    Acknowledgement NumberACK——用于确认收到,用来解决不丢包的问题。
    Window又叫Advertised-Window,也就是著名的滑动窗口(Sliding Window),用于解决流控的
    TCP Flag包的类型,主要是用于操控TCP的状态机的

     

    1.2. segment

    TCP网络协议中:第二层上的数据,我们叫Frame,在第三层上的数据叫Packet,第四层的数据叫Segment。

    发送数据时

    我们程序的数据首先会打到TCP的Segment中,然后TCP的Segment会打到IP的Packet中,然后再打到以太网Ethernet的Frame中,传到对端后,各个层解析自己的协议,然后把数据交给更高层的协议处理。

     
     

    2. TCP的状态机与连接与关闭连接

    先来一张TCP状态机的状态转换图,表示了client和server端状态的转换流程。
    在这里插入图片描述
    图中的11种状态

    状态解释
    listenserver等待client端发来的连接请求
    syn_sentclient发送一个syn报文,代表应用程序执行了主动打开的操作,并等待对端回应以此完成连接的建立
    syn_recvserver端收到了client的syn报文,并发送了SYN/ACK报文(这个报文同时设置了SYN和ACK位),等待client发送ACK,以此完成建立进入established
    fin_wait1应用程序关闭了连接。client发送一个fin报文,用来中断连接并等待对端发来的ACK。
    fin_wait2fin_wait1的client端已经收到了server发来的ACK(半关闭)
    closing之前处在FIN_WAIT1状态的client正在等待对端发送ACK,但却收到了FIN。这表示server端也正在尝试执行一个主动关闭。(换句话说,这两个TCP节点几乎在同一时刻发送了FIN报文。即同时关闭)
    time_waitclient完成主动关闭后,收到了fin报文(server端执行了一个被动关闭)。此时client将在time_wait阶段中等待一段时间,为了确保tcp连接可靠的终止,同时确保任何老的报文在重新建立连接之前超时,当固定段超时后,连接就关闭了,相关内核资源得到释放。
    close_waitserver端收到(处于fin_wait1的client发送)fin报文后,将状态设置为close_wait状态。
    last_ack应用程序被动关闭,处于close_wait状态的server端发送一个fin报文给client并等待确认。收到ack报文时,连接关闭,相关内核资源释放
    closed关闭状态

     
     

    3. 三次握手与四次挥手

    先了解几个概念:

    1. 双工的概念:TCP是全双工的
      全双工:client在给server发送信息的同时server也可以client发送信息;
      半双工:server可以给client发送信息或相反,但是client和server不能同时发。
       
    2. 发送syn表示和对方建立一个连接,ack表示收到对方的syn后做出回应,是两个操作。

    在这里插入图片描述

     

    3.1. 建立连接:三次握手

    对于三次握手建立连接,有一个主要动作是初始化Sequence Number的初始值,client和server要互相通知自己的SN初始值是多少,此过程称为 SYN(Synchronize Sequence Numbers)。 以便之后数据传递过程中不出现乱序的问题。

    • 第一次:建立连接。client发送SYN报文(其中位置设置为1,SN设置为J),并进入syn_send状态,等待服务器确认
    • 第二次:server收到SYN报文后,ack:进行报文确认(设置Acknowledgment Number为J+1),syn:同时发送自己的SYN报文(位置设置为1,SN设置为k),server置为syn_recv。
    • 第三次:client收到SYN+ACK报文段后,设置AN(k+1),并发送SYN,之后client和server都进入establish状态。

     

    3.2. 关闭连接:四次挥手

    server端或client端,都可以是发起者

    • 第一次挥手:client(可以是client或server),发送fin(设置sequence Number 和 Acknowledgment Number)报文段给server,client进入fin_wait1状态,表示client没有数据要发送给server端了。
    • 第二次挥手:sever收到了client的fin报文后,回复client一个ack(AN(=SN+1))报文,client收到后,状态为fin_wait2。此时告诉client,server接收到了它的请求且server要做一些关闭自己前的清理工作。
    • 第三次挥手:server向client发送fin(清理工作已经做完,请求关闭连接)报文,并将自己设置为close_wait.
    • 第四次挥手:client收到server的fin报文,向server发送ack报文,然后client进入time_wait状态。server收到ack,就关闭连接,此时,client等待2MEL后依然没有收到回复,则说明server已正常关闭,此时client也关闭连接。

     

    3.3. TCP四次挥手过程中,为什么需要等待2MSL,才进入CLOSED关闭状态

    2MSL,two Maximum Segment Lifetime,即两个最大段生命周期。

    假设主动发起挥手的是client,那么需要2MSL的原因是:

    1. 为了保证client发送的ack报文server端能收到:
      假设ack报文段丢失,server端就收不到报文。server端因报文超时,重传fin+ack(二、三次挥手)给client确认,此时client就能在2MSL(超时 + 1MSL)收到重传的fin+ack报文段,然后发送ack给server,重新开启2MSL计时。
       
    2. 防止已失效的连接请求报文段出现在本连接中:
      client发完最后一个ack报文段后,再经过2MSL就可以使本连接持续的时间内,所产生的所有报文段都消失,这样就可以使下一个连接中不会出现这种旧的连接报文段

     
     

    二. TCP连接相关问题

    1. 建立连接时SYN超时

    假设server端收到client发送的syn,并回复了ack后,client掉线了,server没有再接收到client的ack,此时连接就处于一个中间状态。于是server再一定时间内没有收到ack时就重发syn-ack。
    linux下,默认重试为5次,分别为:1、2、4、8、16共31秒,第五次后再等待超过32s后(client和server都知道第五次也失效了),还没有接收到client的ack,就会断开这个连接。共63秒。

     

    2. SYN Flood攻击与半连接队列ing

    SYN Flood攻击——给服务器发了一个SYN后,就下线了,于是服务器需要默认等63s才会断开连接,这样,攻击者就可以把服务器的syn连接的队列耗尽,让正常的连接请求不能处理。

    linux下给了一个叫tcp_syncookies的参数来应对

    当SYN队列满了后,TCP会通过源地址端口、目标地址端口和时间戳创建出一个特别的Sequence Number发回去(又叫cookie),如果是攻击者则不会有响应,如果是正常连接,则会把这个 SYN Cookie发回来,然后服务端可以通过cookie建连接(即使你不在SYN队列中)。

     

    3. 关闭连接时TIME_WAIT状态过多的危害

    3.1. 会出现的问题

    1. time_wait 状态结束前,该socket所占用的端口将一直无法释放。在高并发(没秒几万qps)且采用短连接方式的交互系统,在运行一段时间后,系统中就会出现大量的time_wait状态,当time_wait将系统中可用的端口都占用完了,就出现无法向server端创建新的socket连接的情况,此时系统几乎停转,任何连接都不能建立。
    2. 大量的time_wait也会占用一定的fd、内存和cpu资源,当然这个量比较小,不是主要危害。

     

    3.2. 优化time_wait过多的方式

    a. 调整系统内核参数

    修改/etc/sysctl.conf文件,一般涉及下面的几个参数:

    net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;
    net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;
    net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。
    net.ipv4.tcp_fin_timeout =  修改系统默认的 TIMEOUT 时间
    net.ipv4.tcp_max_tw_buckets = 5000 表示系统同时保持TIME_WAIT套接字的最大数量,(默认是18000). 当TIME_WAIT连接数量达到给定的值时,所有的TIME_WAIT连接会被立刻清除,并打印警告信息。但这种粗暴的清理掉所有的连接,意味着有些连接并没有成功等待2MSL,就会造成通讯异常。一般不建议调整
    
    其他优化:
    
    net.ipv4.ip_local_port_range = 1024 65535 增加可用端口范围,让系统拥有的更多的端口来建立链接,这里有个问题需要注意,对于这个设置系统就会从1025~65535这个范围内随机分配端口来用于连接,如果我们服务的使用端口比如8080刚好在这个范围之内,在升级服务期间,可能会出现8080端口被其他随机分配的链接给占用掉,这个原因也是文章开头提到的端口被占用的另一个原因
    net.ipv4.ip_local_reserved_ports = 7005,8001-8100 针对上面的问题,我们可以设置这个参数来告诉系统给我们预留哪些端口,不可以用于自动分配。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

     

    b. 使用nginx调整短链接为长链接

    简介一下短连接和长连接

    短连接:连接->传输数据->关闭连接

    • HTTP是无状态的,浏览器和服务器每进行一次HTTP操作,就建立一次连接,但任务结束就中断连接。
    • 也可以这样说:短连接是指SOCKET连接后发送后接收完数据后马上断开连接。
       

    长连接:连接->传输数据->保持连接 -> 传输数据-> 。。。->关闭连接。

    • 长连接指建立SOCKET连接后不管是否使用都保持连接,但安全性较差

    长连接比短连接从根本上减少了关闭连接的次数,减少了TIME_WAIT状态的产生数量,在高并发的系统中,这种方式的改动非常有效果,可以明显减少系统TIME_WAIT的数量。

     

    从client到nginx的长连接

    默认情况下,nginx已经自动开启了对client连接的keep alive支持。
    一般场景可以直接使用,但是对于一些比较特殊的场景,还是有必要调整个别参数(keepalive_timeout和keepalive_requests)。

    http {
        keepalive_timeout  120s 120s;
        keepalive_requests 10000;
    }
    
    keepalive_timeout:
    第一个参数:设置keep-alive客户端连接在服务器端保持开启的超时值(默认75s);
    第二个参数:可选、在响应的header域中设置一个值“Keep-Alive: timeout=time”;通常可以不用设置;
    
    
    keepalive_requests:
    一个keep alive建立之后,nginx就会为这个连接设置一个计数器,记录这个keep alive的长连接上已经接收并处理的客户端#请求的数量#。
    如果达到这个参数设置的最大值时,则nginx会强行关闭这个长连接,逼迫客户端不得不重新建立新的长连接。
    
    默认值100凑合够用:
    QPS=10000时,客户端每秒发送10000个请求(通常建立有多个长连接),每个连接只能最多跑100次请求,意味着平均每秒钟就会有100个长连接因此被nginx关闭。
    同样意味着为了保持QPS,客户端不得不每秒中重新新建100个连接。
    因此,就会发现有大量的TIME_WAIT的socket连接(即使此时keep alive已经在client和nginx之间生效)。
    因此对于QPS较高的场景,非常有必要加大这个参数,以避免出现大量连接被生成再抛弃的情况,减少TIME_WAIT。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19

     

    从nginx和server的长连接
    upstream http_backend {
     server 127.0.0.1:8080;
    
     keepalive 1000;//设置nginx到upstream服务器的空闲keepalive连接的最大数量
    }
    
    server {
     ...
    
    location /http/ {
     proxy_pass http://http_backend;
     proxy_http_version 1.1;//开启长链接
     proxy_set_header Connection "";
     ...
     }
    }
    
    proxy_set_header Connection "";
    清理从client过来的http header,因为即使是client和nginx之间是短连接,nginx和upstream之间也是可以开启长连接的。这种情况下必须清理来自client请求中的"Connection" header。
    
    但这个地方需要注意如果有一些认证鉴权的cookie或者session信息在head里面,
    不建议开启此选项,或者对需要保留的header要保存下来,否则这些信息可能会丢掉从而发不到上游upstream的服务器上。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22

     
     

    三. 数据传输相关

    1. TCP的粘包和拆包

    TCP中的negal算法:

    通信两端有很多小的数据包要发送,虽然传送的数据很少,但是流程一点没少,也需要tcp的各种确认,校验,这样小的数据包如果很多,会造成网络资源很大的浪费。
    negal算法做了这样一件事:当来了一个很小的数据包,我不急于发送这个包,而是等来了更多的包,将这些小包组合成大包之后一并发送,提高了网络传输的效率。

    TCP是面向流的:

    client到server端数据传输过程中,因为TCP面向流数据没有边界,所以TCP会根据缓冲区(例如1024字节为一个缓冲区)进行包的划分。
    一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。

    在这里插入图片描述

    1. 正常的理想情况,两个包恰好满足TCP缓冲区的大小或达到TCP等待时长,分别发送两个包;
    2. 粘包:两个包较小,间隔时间短,发生粘包,合并成一个包发送; 拆包:一个包过大,超过缓存区大小,拆分成两个或多个包发送;
    3. 拆包和粘包:Packet1过大,进行了拆包处理,而拆出去的一部分又与Packet2进行粘包处理。

     
    解决方案:

    1. 给每个数据包添加包首部,首部包含数据包的长度,当服务器端获取到指定的包长时才说明获取完整。
    2. 指定包的结束标识,这样当我们获取到指定的标识时,说明包获取完整。
    3. 在数据包之间设置边界,如添加特殊符号,这样,接收端通过这个边界就可以将不同的数据包拆分开。

     
     

    2. 可靠传输及乱序问题-TCP滑动窗口

    TCP必需要解决的可靠传输以及包乱序(reordering)的问题,所以,TCP必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。

    见下篇:ing
     

    3. TCP的拥塞处理

    见下篇:ing

     

    4. 所以:TCP是如何确保数据的可靠性

    连接和断开的可靠性(三次握手,四次挥手)、有状态(哪些数据发送了,哪些没发)、可控制(超时重传、流量控制、拥塞控制等)。

    1. TCP的连接是基于三次握手,而断开则是基于四次挥手。确保连接和断开的可靠性。
    2. 有状态:TCP会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
    3. 可控制:它有数据包校验、ACK应答、超时重传(发送方)、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)和拥塞控制等机制。

     
     

    参考:
    LWIP应用开发|TCP/IP设计原理二
    https://www.eet-china.com/mp/a68780.html

    如何优化高并发TCP链接中产生的大量的TIME_WAIT的状态

  • 相关阅读:
    Largebin Attack原理详解
    通过shell批量更新多台linux上jar包
    Java面试题-Java核心基础-第九天(泛型)
    找出重复成员
    深入解析Laravel框架:目录结构全解析
    前端项目性能优化合集
    Spring框架系列(9) - Spring AOP实现原理详解之AOP切面的实现
    java进制与位运算
    2022-08-27 AndroidR 插入USB设备自动授权不弹出权限对话框
    Multivariate Time-series Anomaly Detection viaGraph Attention Network
  • 原文地址:https://blog.csdn.net/hiliang521/article/details/126551184