raochaoxun

raochaoxun

关注
发信
关注(28)粉丝(399)

畅谈linux下TCP(上)


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

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

一、TCP连接阶段

一、TCP 三次握手

1、两次握手行不行？

two_handle.pn

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

2、三次握手
畅谈linux下TCP(上)-LMLPHP
three_handle.png

客户端：收到ACK， 立即分配资源
服务器：收到ACK， 立即分配资源

3、四次、五次、六次...握手?
畅谈linux下TCP(上)-LMLPHP
more_handle.png

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

二、连接状态变化

1、正常连接

full-connect.png
2、半连接
畅谈linux下TCP(上)-LMLPHP
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

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

三、backlog 队列

1、tcp接收端有两个队列：一个是 syn 队列 ， 另一个是 accept 队列
  • syn 队列 : 收到 客户端syn 的时候， 在syn队列分配一个 TCB，也叫半连接队列
  • accept 队列 : 当收到客户端 ack 时候，把 TCB 从syn队列移到 accept中来， 也叫全连接队列
    畅谈linux下TCP(上)-LMLPHP
    tcp_queue.png
2、队列大小如何设置？
  • 设置syn 队列大小


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


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

    3. /proc/sys/net/core/somaxconn

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

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


  1. #ss -a 
  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、正常关闭流程
畅谈linux下TCP(上)-LMLPHP
close-stage.png
2、三次挥手行不行

close-three-way.png

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


畅谈linux下TCP(上)-LMLPHP
image.png

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

3、二次挥手行不行

同上

4、半关闭(CLOSE_WAIT)

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

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

畅谈linux下TCP(上)-LMLPHP
image.png

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

5、同时关闭
畅谈linux下TCP(上)-LMLPHP
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个问题：

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

畅谈linux下TCP(上)-LMLPHP
image.png


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

畅谈linux下TCP(上)-LMLPHP
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 状态的队列中，选取条件：１、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.     }

  12.     return 0;
  13. }

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

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


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

畅谈linux下TCP(上)-LMLPHP
image.png

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

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

4、tcp_tw_recycle

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状态，如果有则比较时间戳，如果时间戳比最后一次收到时间戳还要小，则这个包被认为是延迟包，丢弃掉。


NAT-NET.png
畅谈linux下TCP(上)-LMLPHP
image.png

12-17 03:35
Powered by LMLPHP ©2024 raochaoxun 0.077431