Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1857013
  • 博文数量: 38
  • 博客积分: 690
  • 博客等级: 中士
  • 技术积分: 3715
  • 用 户 组: 普通用户
  • 注册时间: 2012-06-27 14:06
文章分类

全部博文(38)

文章存档

2018年(8)

2016年(4)

2015年(2)

2014年(1)

2013年(3)

2012年(20)

分类: LINUX

2018-11-29 12:52:17


一直都想整理一下关于TCP方面的白话文章,可是拖延症导致迟迟未动手,这次公司技术分享,终于动手整理一下。内容太多,分成两篇  http://blog.chinaunix.net/uid-27105712-id-5794026.html

tcp 协议 是互联网中最常用的协议 , 开发人员基本上天天和它打交道,对它进行深入了解。 可以帮助我们排查定位bug和进行程序优化。下面我将就TCP几个点做深入的探讨

一、TCP连接阶段

一、TCP 三次握手

1、两次握手行不行?
two_handle.png
two_handle.pn

客户端:收到 ack 后 分配连接资源。 发送数据
服务器 : 收到 syn 后立即 分配连接资源

缺陷:
当ack 丢失后, 服务器认为连接建立了,等待客户端发送数据。 但是客户端并没有建立连接。服务器一直在等待数据,耗费资源。
PS: 网上有说法是什么TCP全双工需要互相确认,个人觉得和这个没有任何关系的。

2、三次握手
three_handle.png
three_handle.png

客户端:收到ACK, 立即分配资源
服务器:收到ACK, 立即分配资源

缺陷: 同样问题, 最后一个ACK,服务器没有收到, 这是 客户端分配了资源, 但是服务器没有分配资源。 客户端并不知道,继续发送数据。服务器会返回 RST 信号。 因此问题影响不大。

3、四次、五次、六次...握手?
more_handle.png
more_handle.png

既然三次握手也不是100%可靠, 那四次,五次,六次。。。呢? 其实都一样,不管多少次都有丢包问题。

二、连接状态变化

1、正常连接
full-connect.png
full-connect.png
2、半连接
half-open.png
half-open.png

client 只发送一个 SYN, server 分配一个tcb, 放入syn队列中。 这时候连接叫半连接状态;如果server 收不到 client 的ACK, 会不停重试 发送 ACK-SYN 给client 。重试间隔 为 2 的 N 次方 叠加(2^0 , 2^1, 2^2 ....);直至超时才释放syn队列中的这个 TCB;
在半连接状态下, 一方面会占用队列配额资源,另一方面占用内存资源。我们应该让半连接状态存在时间尽可能的小

3、异常状况
unopen.png
unopen.png

当client 向一个未打开的端口发起连接请求时,会收到一个RST回复包

三、backlog 队列

1、tcp接收端有两个队列:一个是 syn 队列 , 另一个是 accept 队列
  • syn 队列 : 收到 客户端syn 的时候, 在syn队列分配一个 TCB,也叫半连接队列
  • accept 队列 : 当收到客户端 ack 时候,把 TCB 从syn队列移到 accept中来, 也叫全连接队列
    tcp_queue.png
    tcp_queue.png
2、队列大小如何设置?
  • 设置syn 队列大小

    1. /proc/sys/net/ipv4/tcp_max_syn_backlog
  • 设置 accept 队列大小


    1. int listen(int sockfd, int backlog);

    2. /proc/sys/net/core/somaxconn

当listen 的 backlog 和 somaxconn 都设置了得时候, 取两者min值

3、当前连接队列大小查看


  1. #ss -
  2. Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port 
  3. tcp   LISTEN 1      0            *:8888          *:*

Recv-Q 是accept 队列当前个数, Send-Q 设置最大值

4、SYN队列满的情况
  • 若设置 net.ipv4.tcp_syncookies = 0 ,则直接丢弃当前 SYN 包;
  • 若设置 net.ipv4.tcp_syncookies = 1 ,发送ACK+SYN;
5、ACCEPT队列满的情况
  • 若设置 tcp_abort_on_overflow = 1 ,则 TCP 协议栈回复 RST 包,并直接从 SYN queue 中删除该连接信息;
  • 若设置 tcp_abort_on_overflow = 0 ,则 TCP 协议栈将该连接标记为 acked ,但仍保留在 SYN queue 中,并启动 timer 以便重发 SYN-ACK 包;当 SYN-ACK 的重传次数超过 net.ipv4.tcp_synack_retries 设置的值时,再将该连接从 SYN queue 中删除;
6、SYN flooding

这种SYN洪水攻击是一种常见攻击方式,就是利用半连接队列特性,占满syn 队列的 资源,导致 client无法连接上。
解决方案:

  • 缩短SYN队列超时时间 : 设置系统配置 net.ipv4.tcp_synack_retries, 减少 重发 syn-ack 次数
  • Syn Cache技术 : 这种技术是在收到SYN数据报文时不急于去分配TCB,而是先回应一个SYN ACK报文,并在一个专用HASH表(Cache)中保存这种半开连接信息,直到收到正确的回应ACK报文再分配TCB到accept队列。在linux系统中这种Cache每个半开连接只需使用160字节,远小于TCB所需的736个字节。
  • Syn Cookie技术: 相对于 Syn Cache技术, 这里不分配任何资源,只是巧妙的用算法计算一个Sequence Number 放在 SYN 请求中。 为了能正确匹配识别 client 回应的 ACK 中 Sequence Number。 完全靠算法 来 完成。 如果开启了 SYN cookies 选项,在半连接队列满时,SYN cookies 并不丢弃 SYN 请求,而是将源目的 IP、源目的端口号、接收到的客户端初始序列号以及其他一些安全数值等信息进行 hash 运算,并加密后得到服务器端的初始序列号,称之为 cookie 。服务器端在发送初始序列号为 cookie 的 SYN+ACK 包后,会将分配的连接请求块释放。如果接收到客户端的 ACK 包,服务器端将客户端的 ACK 序列号减 1 得到的值,与上述要素 hash 运算得到的值比较,如果相等,直接完成三次握手,构建新的连接。SYN cookies 机制的核心就是避免攻击造成的大量构造无用的连接请求块,导致内存耗尽,而无法处理正常的连接请求。(echo 1 > /proc/sys/net/ipv4/tcp_syncookies)
7、哪些是内核自动完成的动作,哪些是应用层触发
  • client 调用 connect 函数 , 三次握手在内核协议栈自动完成,connect 函数立即返回,不管server端是否是调用了 accept函数没有。
  • server调用 accept函数, 才从 accept队列移除 TCB资源 ,返回socket 句柄句柄 给应用程序。
  • 如果server端的synt队列未满 ,client端调用connect 函数,不管server是否调用accept与否,都会立即返回; 如果队列满,client则一直重复发送SYN( 间隔 2的幂递增)到直至超时返回。

二、TCP关闭阶段

一、TCP 四次 挥手

1、正常关闭流程
close-stage.png
close-stage.png
2、三次挥手行不行
close-three-way.png
close-three-way.png

为什么不像握手那样合并成三次挥手? 因为和刚开始连接情况,连接是大家都从0开始, 关闭时有历史包袱的。server(被动关闭方) 收到 client(主动关闭方) 的关闭请求FIN包。 这时候可能还有未发送完的数据,不能丢弃。 所以需要分开。事实可能是这样


image.png
image.png

当然,在没有待发数据,并且允许 Delay ACK 情况下, FIN-ACK合并还是非常常见的事情,这是三次挥手是可以的。

3、二次挥手行不行

同上

4、半关闭(CLOSE_WAIT)

CLOSE_WAIT 是被动关闭方才有的状态

被动关闭方 [收到 FIN 包 发送 ACK 应答] 到 [发送FIN, 收到ACK ] 期间的状态为 CLOSE_WAIT, 这个状态仍然能发送数据。 我们叫做半关闭, 下面用个例子来分析:

image.png
image.png

这个是我实际生产环境碰到的一个问题,长连接会话场景,server端收到client的rpc call 请求1,处理发现请求包有问题,就强制关闭结束这次会话, 但是 因为client 发送 第二次请求之前,并没有去调用recv,所以并不知道 这个连接被server关闭, 继续发送 请求2 , 此时是半连接,能够成功发送到对端机器,但是recv结果后,遇到连接已经关闭错误。

CLOSE_WAIT 和 后面提到的 TIME_WAIT 一样,都是存在潜在危害,CLOSE_WAIT 状态下 文件句柄资源没有释放。要知道系统 句柄资源也是有限的。要尽快释放close掉。

5、同时关闭
image.png
image.png

如果 client 和 server 恰好同时发起关闭连接。这种情况下,两边都是主动连接,都会进入 TIME_WAIT状态

4、TIME_WAIT 状态
  • TIME_WAIT 状态 是主动关闭方才有的状态:这种状态下有个让开发人员都很苦恼的普遍性问题,端口耗尽, 我们知道,端口数据类型是 unsigned short。 最大值是 65535. 所以 一台机 上 最多分配 65535个端口(不考虑accept的tcp资源情况下,也可以看成一台机器最多只能分配这么链接数)。
    然而,
    TIME_WAIT* 持续保持时间是 2*MSL( Maximum segment lifetime)。 默认是 2分钟。( 通过这个可以修改 /proc/sys/net/ipv4/tcp_fin_timeout)。想想在并发高的机器上 2分钟 很容易发起超过 6w多个短链接请求。 这时候就出现端口不够用,connect 错误“Cannot assign requested address” 。

  • TIME_WAIT的如此设计是为了解决2个问题

以下两种讨论的两种情况都是 假设 前后两次连接都是相同四元组( 源ip,源端口,目的ip,目的端口),都是属于 "在不相关的连接中接受延迟的段"现象

1、被动关闭方在LAST_ACK状态(已经发送FIN),等待主动关闭方的ACK应答,但是 ACK丢掉, 主动方并不知道,以为成功关闭。因为没有TIME_WAIT等待时间,可以立即创建新的连接, 新的连接发送SYN到前面那个未关闭的被动方,被动方认为是收到错误指令,会发送RST。导致创建连接失败。

image.png
image.png


2、主动关闭方断开连接,如果没有TIME_WAIT等待时间,可以马上建立一个新的连接,但是前一个已经断开连接的,延迟到达的数据包。 被新建的连接接收,如果刚好seq 和 ack字段 都正确, seq在滑动窗口范围内(只能说机率非常小,但是还是有可能会发生),会被当成正确数据包接收,导致数据串包。 如果不在window范围内,则没有影响( 发送一个确认报文(ack 字段为期望ack的序列号,seq为当前发送序列号),状态变保持原样)

image.png
image.png


4、解决TIME_WAIT 问题

TIME_WAIT 问题比较比较常见,特别是CGI机器,并发量高,大量连接后段服务的tcp短连接。因此也衍生出了多种手段解决。虽然每种方法解决不是那么完美,但是带来的好处一般多于坏处。还是在日常工作中会使用。
1、改短TIME_WAIT 等待时间


  1. /proc/sys/net/ipv4/tcp_fin_timeout

这个是第一个想到的解决办法,既然等待时间太长,就改成时间短,快速回收端口。但是实际情况往往不乐观,对于并发的机器,你改多短才能保证回收速度呢,有时候几秒钟就几万个连接。太短的话,就会有前面两种问题小概率发生。


2、禁止Socket lingering

  1. struct linger stLinger; stLinger.l_onoff = 1;
  2. stLinger.l_linger = 0;
  3. setsockopt(fdC, SOL_SOCKET, SO_LINGER, ( void *)&stLinger, sizeof(stLinger));

这种情况下关闭连接,会直接抛弃缓冲区中待发送的数据,会发送一个RST给对端,相当于直接抛弃TIME_WAIT, 进入CLOSE状态。同样因为取消了 TIME_WAIT 状态,会有前面两种问题小概率发生。

3、tcp_tw_reuse
net.ipv4.tcp_tw_reuse选项是 从 TIME_WAIT 状态的队列中,选取条件:1、remote 的 ip 和端口相同, 2、选取一个时间戳小于当前时间戳; 用来解决端口不足的尴尬。

  1. net/ipv4/tcp_ipv4.c
  2. int tcp_twsk_unique(struct sock *sk, struct sock *sktw, void *twp)
  3. {
  4.     /* ……省略…… */
  5.     if (tcptw->tw_ts_recent_stamp &&
  6.         (!twp || (sock_net(sk)->ipv4.sysctl_tcp_tw_reuse &&
  7.                  get_seconds() - tcptw->tw_ts_recent_stamp > 1))) {
  8.         /* ……省略…… */
  9.         return 1;
  10.     }

  11.     return 0;
  12. }

  13. net/ipv4/inet_hashtables.c
  14. static int __inet_check_established(struct inet_timewait_death_row *death_row,
  15.                     struct sock *sk, __u16 lport,
  16.                     struct inet_timewait_sock **twp)
  17. {
  18.     /* ……省略…… */
  19.     sk_nulls_for_each(sk2, node, &head->chain) {
  20.         if (sk2->sk_hash != hash)
  21.             continue;

  22.         if (likely(INET_MATCH(sk2, net, acookie,
  23.                      saddr, daddr, ports, dif))) {
  24.             if (sk2->sk_state == TCP_TIME_WAIT) {
  25.                 tw = inet_twsk(sk2);
  26.                 if (twsk_unique(sk, sk2, twp))
  27.                     break;
  28.             }
  29.             goto not_unique;
  30.         }
  31.     }
  32.     /* ……省略…… */
  33. }
那么如果我能在新连接中识别出此包为非法包,是不是就可以丢掉这些无用包,解决问


需要实现这些功能,需要扩展一下tcp 包头。 增加 时间戳字段。 发送者 在每次发送的时候。 在tcp包头里面带上发送时候的时间戳。 当接收者接收的时候,在ACK应答中除了TCP包头中带自己此时发送的时间戳,并且把收到的时间戳附加在后面。也就是说ACK包中有两个时间戳字段。结构如下:

image.png
image.png

那我们接下来一个个分析tcp_tw_reuse是如何解决TIME_WAIT的两个问题的

tcp_tw_reuse 使用有三个条件:
1、必须开启 timestamp,通过 net.ipv4.tcp_timestamp 参数设置, linux 2.6 后缺省是打开的;
2、必须客户端和server同时支持 timestamp. 在连接握手阶段协商:当一方不开启时,两方都将停用timestamps。比如client端发送的SYN包中带有timestamp选项,但server端并没有开启该选项。则回复的SYN-ACK将不带timestamp选项,同时client后续回复的ACK也不会带有timestamp选项。当然,如果client发送的SYN包中就不带timestamp,双向都将停用timestamp。
3、 tcp_tw_reuse 只对outgoing connections 有效。也就是发起连接方 client 有效。 server端产生新的连接是不会复用 TIME_WAIT 资源

  1. LAST_ACK收到 SYN问题: LAST_ACK 状态 socket 苦苦等待 主动关闭方的ACK应答,但是却收到了SYN。注意:敲黑板,划重点了。此时检查有timestamp字段的话,不会立即发送RST包,而是比较timestamp字段时间戳非常新,明显不是自己这个连接建立时候SYN延迟包。这时候恢复 FIN + ACK, 对方收到 回复一个RST结束上个连接。 继续发SYN建立新的连接 。这样就解决料老的连接无法关闭,新的连接无法建立的问题。
image.png
image.png
  1. 收到上一个连接数据串包问题,也是检查这个数据包的TCP头里面的timestamp,比较发现远远小于上一次TCP包的timestamp ,于是丢弃这个包即可。

4、tcp_tw_recycle

tcp_tw_recycle自 Linux内核4.12版以来,已被弃用, 大家可以放心的不用了

tcp_tw_recycle 也是借助 timestamp机制。顾名思义, tcp_tw_reuse 是复用 端口,并不会减少 TIME-WAIT 数量。你去查询机器上TIME-WAIT 数量,还是 几千几万个,这点对有强迫症的同学感觉很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT资源。会减少 机器上 TIME-WAIT 数量。

tcp_tw_recycle 工作原理是。

  • 动态缩小TIME-WAIT 时间, 不再是 2*MSL时间回收来回收TIME-WAIT资源,而是根据 RTO(Retransmission TimeOut)即重传超时时间, 这个时间根据一套特定算法来动态计算,当TIME-WAIT 停留时间大于 RTO。系统释放资源。 这招可以减少TIME-WAIT 数量

  • 为了解决TIME-WAIT 收到不相关连接数据包的问题, 内核会纪录 TIME-WAIT 状态下 最后一次 收到包的时间戳,和ip地址等信息。(注意是IP地址没有端口信息哦)。如果收到连接SYN包(注意只在连接时候检测哦),先检查remote IP 有没有 相关的 TIME-WAIT状态,如果有则比较时间戳,如果时间戳比最后一次收到时间戳还要小,则这个包被认为是延迟包,丢弃掉。

存在问题: 一般情况下我们不建议使用tcp_tw_recycle , 因为它在 存在 NAT 网关的时候。 会出问题。NAT是地址共享, 而 tcp_tw_recycle 机制下恰恰又是根据ip纪录时间戳信息的。在 NAT下,多台机器上client。 对于server 可能是同一个IP。由于客户端的时间戳可能不一致。会导致连接不上问题。
NAT网络在国内使用非常普遍,家庭网络基本上NAT网络, N个设备共享一个IP地址。 公司办公网基本上也是如此。

NAT-NET.png
NAT-NET.png
image.png
image.png

阅读(6971) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~