一. TCP基础原理
1. TCP头的格式 和 segment
1.1. TCP头的格式
TCP的包是没有IP地址的,那是IP层上的事。但是有源端口和目标端口。一个TCP连接需要四个元组来表示是同一个连接(src_ip, src_port, dst_ip, dst_port)准确说是五元组,还有一个是协议。
头中四个重要的参数:
参数 | 说明 |
---|---|
Sequence Number | 包的序号,用来解决网络包乱序(reordering)问题。 |
Acknowledgement Number | ACK——用于确认收到,用来解决不丢包的问题。 |
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种状态
状态 | 解释 |
---|---|
listen | server等待client端发来的连接请求 |
syn_sent | client发送一个syn报文,代表应用程序执行了主动打开的操作,并等待对端回应以此完成连接的建立 |
syn_recv | server端收到了client的syn报文,并发送了SYN/ACK报文(这个报文同时设置了SYN和ACK位),等待client发送ACK,以此完成建立进入established |
fin_wait1 | 应用程序关闭了连接。client发送一个fin报文,用来中断连接并等待对端发来的ACK。 |
fin_wait2 | fin_wait1的client端已经收到了server发来的ACK(半关闭) |
closing | 之前处在FIN_WAIT1状态的client正在等待对端发送ACK,但却收到了FIN。这表示server端也正在尝试执行一个主动关闭。(换句话说,这两个TCP节点几乎在同一时刻发送了FIN报文。即同时关闭) |
time_wait | client完成主动关闭后,收到了fin报文(server端执行了一个被动关闭)。此时client将在time_wait阶段中等待一段时间,为了确保tcp连接可靠的终止,同时确保任何老的报文在重新建立连接之前超时,当固定段超时后,连接就关闭了,相关内核资源得到释放。 |
close_wait | server端收到(处于fin_wait1的client发送)fin报文后,将状态设置为close_wait状态。 |
last_ack | 应用程序被动关闭,处于close_wait状态的server端发送一个fin报文给client并等待确认。收到ack报文时,连接关闭,相关内核资源释放 |
closed | 关闭状态 |
3. 三次握手与四次挥手
先了解几个概念:
- 双工的概念:TCP是全双工的
全双工:client在给server发送信息的同时server也可以client发送信息;
半双工:server可以给client发送信息或相反,但是client和server不能同时发。
- 发送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的原因是:
- 为了保证client发送的ack报文server端能收到:
假设ack报文段丢失,server端就收不到报文。server端因报文超时,重传fin+ack(二、三次挥手)给client确认,此时client就能在2MSL(超时 + 1MSL)收到重传的fin+ack报文段,然后发送ack给server,重新开启2MSL计时。
- 防止已失效的连接请求报文段出现在本连接中:
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. 会出现的问题
- time_wait 状态结束前,该socket所占用的端口将一直无法释放。在高并发(没秒几万qps)且采用短连接方式的交互系统,在运行一段时间后,系统中就会出现大量的time_wait状态,当time_wait将系统中可用的端口都占用完了,就出现无法向server端创建新的socket连接的情况,此时系统几乎停转,任何连接都不能建立。
- 大量的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 针对上面的问题,我们可以设置这个参数来告诉系统给我们预留哪些端口,不可以用于自动分配。
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。
从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. TCP的粘包和拆包
TCP中的negal算法:
通信两端有很多小的数据包要发送,虽然传送的数据很少,但是流程一点没少,也需要tcp的各种确认,校验,这样小的数据包如果很多,会造成网络资源很大的浪费。
negal算法做了这样一件事:当来了一个很小的数据包,我不急于发送这个包,而是等来了更多的包,将这些小包组合成大包之后一并发送,提高了网络传输的效率。
TCP是面向流的:
client到server端数据传输过程中,因为TCP面向流数据没有边界,所以TCP会根据缓冲区(例如1024字节为一个缓冲区)进行包的划分。
一个完整的包可能会被TCP拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是所谓的TCP粘包和拆包问题。
- 正常的理想情况,两个包恰好满足TCP缓冲区的大小或达到TCP等待时长,分别发送两个包;
- 粘包:两个包较小,间隔时间短,发生粘包,合并成一个包发送; 拆包:一个包过大,超过缓存区大小,拆分成两个或多个包发送;
- 拆包和粘包:Packet1过大,进行了拆包处理,而拆出去的一部分又与Packet2进行粘包处理。
解决方案:
- 给每个数据包添加包首部,首部包含数据包的长度,当服务器端获取到指定的包长时才说明获取完整。
- 指定包的结束标识,这样当我们获取到指定的标识时,说明包获取完整。
- 在数据包之间设置边界,如添加特殊符号,这样,接收端通过这个边界就可以将不同的数据包拆分开。
2. 可靠传输及乱序问题-TCP滑动窗口
TCP必需要解决的可靠传输以及包乱序(reordering)的问题,所以,TCP必需要知道网络实际的数据处理带宽或是数据处理速度,这样才不会引起网络拥塞,导致丢包。
见下篇:ing
3. TCP的拥塞处理
见下篇:ing
4. 所以:TCP是如何确保数据的可靠性
连接和断开的可靠性(三次握手,四次挥手)、有状态(哪些数据发送了,哪些没发)、可控制(超时重传、流量控制、拥塞控制等)。
- TCP的连接是基于三次握手,而断开则是基于四次挥手。确保连接和断开的可靠性。
- 有状态:TCP会记录哪些数据发送了,哪些数据被接收了,哪些没有被接受,并且保证数据包按序到达,保证数据传输不出差错。
- 可控制:它有数据包校验、ACK应答、超时重传(发送方)、失序数据重传(接收方)、丢弃重复数据、流量控制(滑动窗口)和拥塞控制等机制。
参考:
LWIP应用开发|TCP/IP设计原理二
https://www.eet-china.com/mp/a68780.html