TCP 的数据包如何组织?
透视一个协议的最原始的方法就是看它的数据包,一个TCP 的报文格式如下:
这里面的字段就包括了:
源端口
表明发送端所使用的端口号,用于目标主机回应。
目的端口
表明要连接的目标主机的端口号。
序号
表明发送的数据包的顺序,一般为上次发送包中的顺序号+1。
若该数据包是整个TCP连接中的第一个包(SYN包),则该值是随机生成的。
确认号
表明本端TCP已经接收到的数据,其值表示期待对端发送的下一个字节的序号。
实际上告诉对方,在这个序号减1以前的字节已正确接收。
若该数据包是整个TCP连接中的第一个包(SYN包),则确认号一般为0。
数据偏移
表示以32位(4字节)为单位的TCP分组头的总长度(首部长度),用于确定用户数据区的起始位置。
在没有可变内容的情况下,TCP头部的大小为20字节,对应该值为5。
标志位
紧急标志位(URG):开启时表明此数据包处于紧急状态应该优先处理
确认标志位(ACK):开启时表明确认号有效,否则忽略确认号
推送标志位(PSH):开启时表明应该尽快交付给应用进程,而不必等到缓存区填满才推送,比如 telnet 的场景
复位标志位(RST):开启时表明TCP连接出现连接出现错误,数据包非法拒绝连接
同步标志位(SYN):开启时表明连接建立的标志
终止标志位(FIN):开启时表明释放一个连接
窗口大小
表明期望接受到的数据包字节数,用于拥塞控制。
校验和
实现对TCP报文头以及数据区进行校验。
紧急指针
在紧急状态下(URG打开),指出窗口中紧急数据的位置(末端)。
选项(可变)
用于支持一些特殊的变量,比如最大分组长度(MSS)。
填充
用于保证可变选项为32 bit的整数倍。
黑板:一般情况下TCP 头部为20字节,加上20字节的 IP头部,一个数据包至少包含40字节的头部
一、TCP 工作流程
链是指链路,这个是物理层的概念,比如光缆光纤,或是无线的电磁波。
但这里所说的链路其实是网络连接的意思,即IP 上层的概念。
那么,一个TCP 正常的通讯流程,会包含建链(建立连接)、传输数据、拆链(关闭连接),如下图所示:
(图来自网络)
据上图所示,在进行 TCP 进行数据传输时,都不可避免的会经过这两个阶段:
三次握手建立连接
执行数据传输、双方读写
四次挥手释放连接
下面,重点说明下建链与拆链的过程
二、 三次握手
在建立TCP连接时,需要经过三次交互,也成为三次握手(HandShake)。
1、客户端发起连接请求,发送 SYN包(SYN=i)到服务器,并进入到SYN-SEND状态,等待服务器确认
2、服务器收到SYN包后,必须确认客户的 SYN(ack=i+1),同时自己也发送一个SYN包(SYN=k),即SYN+ACK包,此时服务器进入SYN-RECV状态
3、客户端收到服务器的SYN+ACK包,向服务器发送确认报ACK(ack=k+1),此后客户端和服务器进入ESTABLISHED状态,双方可以开始传送数据。
在谈论三次握手的时候,有几个问题是需要关注的:
问题1. 为什么是三次握手
这个问题在技术面试时屡试不爽,原话是能不能两次,或者是四次握手呢?
答案就是,TCP 是可靠的传输,在建立连接时就应该经过两端的确认过程,如上面的流程,
只有在三次握手的情况下,客户端和服务端都经过了一次真正(SYN+ACK)的确认过程。这样的连接便认为是可信的。
此外,如果仅仅只是两次握手,一旦网络不稳定造成 SYN 包重传则会直接导致重复建立连接,浪费资源。
问题2. 什么是syn flood攻击
syn flood 是一种经典的 ddos攻击手段,这里面用到了TCP 三次握手存在的漏洞。
在上面的图中,可以看到当服务端接收到 SYN 后进入 SYN-RECV 状态,此时的连接称为半连接,同时会被服务端写入一个 半连接队列。
想象一下,如果攻击者在短时间内不断的向服务端发送大量的 SYN 包而不响应,那么服务器的 半连接队列很快会被写满,从而导致无法工作。
实现 syn flood 的手段,可以通过伪造源 IP 的方式,这样服务器的响应就永远到达不了客户端(握手无法完成);
当然,通过设定客户端防火墙规则也可以达到同样的目的。
对 syn flood 实现拦截是比较困难的,可以通过启用 syn_cookies 的方式实现缓解,但这通常不是最佳方案。
最好的办法是通过专业的防火墙来解决,基本上所有的云计算大T 都具备这个能力。
关于 syn flood 可以看看这篇文章
问题3. 半连接队列和全连接队列如何调优
这里提到了一个"半连接队列"(syns queue),与其对应的还有一个 "全连接队列"(accept queue)
前者用于暂存未建立完全的连接,后者是连接在成功建立后进入的一个队列。
半连接队列默认大小可以通过内核参数调整:
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
黑板:tcp_max_syn_backlog 在 syn_cookies 开启时是无效的,这两个选项存在冲突
对于全连接队列,如果服务器未能及时通过 accept 调用将其中的连接取走,会导致队列溢出(连接失效)
全连接队列的大小的内核调优方式:
echo 4096 > /proc/sys/net/core/somaxconn
那么,是不是只有内核调优这种方法能影响这两个参数呢?答案是否定的。
实际上,在应用层调用 socket listen 时也支持设置一个 backlog参数,这几个之间的关系如下:
半连接队列长度 = min(backlog,内核 net.core.somaxconn,内核 tcp_max_syn_backlog)
全连接队列长度 = min(backlog,内核 net.core.somaxconn)
黑板:一般的应用服务器如 netty、tomcat 都支持设置 backlog 参数,但是在真正进行调优时还需要配合考虑内核参数的配置。
三、 四次挥手
在释放连接时,由于TCP是全双工的,因此最后要由两端分别进行关闭,这个流程如下:
1、客户端发送一个FIN,用来关闭客户端到服务器的数据传送,客户端进入FIN_WAIT_1状态。
2、服务器收到FIN后,发送一个ACK给客户端,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),服务器进入CLOSE_WAIT状态,而客户端进入FIN_WAIT2状态。
3、服务器发送一个FIN,用来关闭服务器到客户端的数据传送,服务器进入LAST_ACK状态。
4、客户端收到FIN后,客户端进入TIME_WAIT状态,接着发送一个ACK给服务器,确认序号为收到序号+1,服务器进入CLOSED状态,完成释放。
关闭连接有主动关闭和被动关闭一说,这里为了简化理解,我们以客户端作为主动关闭方,服务器为被动关闭方。
四次挥手需要关注的问题:
问题1. 为什么是四次挥手
发送FIN的一方就是主动关闭(客户端),而另一方则为被动关闭(服务器)。
当一方发送了FIN,则表示在这一方不再会有数据的发送。
其中当被动关闭方受到对方的FIN时,此时往往可能还有数据需要发送过去,因此无法立即发送FIN(也就是无法将FIN与ACK合并发送),
而是在等待自己的数据发送完毕后再单独发送FIN,因此整个过程需要四次交互。
问题2. 什么是半关闭
客户端在收到第一个FIN的ACK响应后,会进入FIN_WAIT2 状态时,此时服务器处于 CLOSE_WAIT状态,这种状态就称之为半关闭。
从半关闭到全关闭,需要等待第二次FIN的确认才算结束。此时,客户端要等到服务器的FIN才能进入TIME_WAIT,
如果对方迟迟不发送FIN呢,则会等待一段时间后超时,这个可以通过内核参数tcp_fin_timeout控制,默认是60s。
问题3. 为什么服务器会有大量 closewait
半关闭的状态下的服务器连接会处于 closewait 状态,直到服务器发送了FIN。
那么在应用层则是调用socket.close()会执行FIN的发送,如果服务器出现大量CLOSE_WAIT状态的连接,那么有可能的原因:
服务器压力过大,根本来不及调用close
存在连接泄露问题(Bug),服务器未及时关闭连接
问题4. timewait 会带来什么问题
当客户端收到了对方的FIN时,会进入TIME_WAIT状态,此时会保持一段时间再进入CLOSE状态。
这么做的原因主要还是为了可靠的关闭连接。在将TCP 进行可靠性设计之时就考虑了许多网络的不稳定性的因素,比如:
发送给对方的ACK 可能会无法及时收到,此时对方可能重传FIN过来,如果提前进入CLOSE则会返回RST而不是ACK,就会影响关闭流程。
因此 TIME_WAIT 状态默认会持续一段时间,直到确认不会再有重传的数据包之后再安全的关闭。
黑板:这里timewait的持续时间默认是 2MSL(总共1分钟),这个MSL叫Max Segment Lifetime*,也就是关于一个数据包在网络中传输的最大生命周期的预设。
MSL默认是30s,当然这个值在现在已经可以大幅度缩减。可见在当时在设计之初,网络状况有多么的糟糕。
那么timewait会带来什么问题?
如果频繁的主动关闭连接,可能会产生大量 timewait,由于timewait 的连接占用了一个句柄及少量内存(4K),那么就有可能会影响其他连接的建立,比如:
出现 too many open files 异常..
该如何解决:
重用连接,避免频繁关闭,比如使用连接池
参数调优,比如开启tcp_tw_reuse选项支持timewait连接的重复使用。
黑板:HTTP 协议里头发现了timewait的问题,于是在 HTTP 1.1 中定义了 KeepAlive 用来支持连接的重用。
问题5. RST 是什么,为什么会出现
RST 是一个特殊的标记,用来表示当前应该立即终止连接。以下这些情况都会产生RST:
向一个未被监听的端口发送数据
对方已经调用 close 关闭连接
存在一些数据未处理(接收缓冲区),请求关闭连接时,会发送RST强制关闭
某些请求发生了超时
RST 机制有时候也会被利用,做一些端口的扫描,如下:
-> 端口开启,可接受SYN
-> 端口关闭,响应RST