传输控制协议（英语: Transmission Control Protocol ，缩写：TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能。用户数据报协议（UDP）是同一层内另一个重要的传输协议。

数据在TCP层称为流 (Stream)，数据分组称为分段 (Segment)。作为比较，数据在IP层称为 Datagram ，数据分组称为分片 (Fragment)。 UDP 中分组称为Message。

TCP 的特性

  • TCP 提供一种面向连接的、可靠的字节流服务
  • 在一个 TCP 连接中，仅有两方进行彼此通信。广播和多播不能用于 TCP
  • TCP 使用校验和，确认和重传机制来保证可靠传输
  • TCP 给数据分节进行排序，并使用累积确认保证数据的顺序不变和非重复
  • TCP 使用滑动窗口机制来实现流量控制，通过动态改变窗口的大小进行拥塞控制

注意：TCP 并不能保证数据一定会被对方接收到，因为这是不可能的。TCP 能够做到的是，如果有可能，就把数据递送到接收方，否则就（通过放弃重传并且中断连接这一手段）通知用户。因此准确说 TCP 也不是 100% 可靠的协议，它所能提供的是数据的可靠递送或故障的可靠通知。

三次握手与四次挥手

三次握手

所谓三次握手(Three-way Handshake)，是指建立一个 TCP 连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立 TCP 连接，并同步连接双方的序列号和确认号，交换 TCP 窗口大小信息。在 socket 编程中，客户端执行 connect() 时。将触发三次握手。

  • 第一次握手(SYN=1, seq=x):

    客户端发送一个 TCP 的 SYN 标志位置1的包，指明客户端打算连接的服务器的端口，以及初始序号 X,保存在包头的序列号 (Sequence Number) 字段里。

    发送完毕后，客户端进入 SYN_SEND 状态。

  • 第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1):

    服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号，放到 Seq 域里，同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1，即X+1。

    发送完毕后，服务器端进入 SYN_RCVD 状态。

  • 第三次握手(ACK=1，ACKnum=y+1):

    客户端再次发送确认包(ACK)，SYN 标志位为0，ACK 标志位为1，并且把服务器发来 ACK 的序号字段+1，放在确定字段中发送给对方，并且在数据段放写ISN的+1

    发送完毕后，客户端进入 ESTABLISHED 状态，当服务器端接收到这个包时，也进入 ESTABLISHED 状态，TCP 握手结束

三次握手的过程的示意图:

TCP三次握手

如果服务器端接到了客户端发的SYN后回了SYN-ACK后客户端掉线了，服务器端没有收到客户端回来的ACK，那么，这个连接处于一个中间状态，既没成功，也没失败。于是，服务器端如果在一定时间内没有收到的TCP会重发SYN-ACK。

在Linux下，默认重试次数为5次，重试的间隔时间从1s开始每次都翻倍，5次的重试时间间隔为1s, 2s, 4s, 8s, 16s，总共31s，第5次发出后还要等32s才知道第5次也超时了，所以，总共需要 1s + 2s + 4s+ 8s+ 16s + 32s = 63s，TCP才会断开这个连接。使用三个TCP参数来调整行为：tcp_synack_retries 减少重试次数；tcp_max_syn_backlog，增大SYN连接数；tcp_abort_on_overflow决定超出能力时的行为。

四次挥手

TCP 的连接的拆除需要发送四个包，因此称为四次挥手(Four-way handshake)，也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作，在 socket 编程中，任何一方执行 close() 操作即可产生挥手操作。

  • 第一次挥手(FIN=1，seq=x)

    假设客户端想要关闭连接，客户端发送一个 FIN 标志位置为1的包，表示自己已经没有数据可以发送了，但是仍然可以接受数据。

    发送完毕后，客户端进入 FIN_WAIT_1 状态。

  • 第二次挥手(ACK=1，ACKnum=x+1)

    服务器端确认客户端的 FIN 包，发送一个确认包，表明自己接受到了客户端关闭连接的请求，但还没有准备好关闭连接。

    发送完毕后，服务器端进入 CLOSE_WAIT 状态，客户端接收到这个确认包之后，进入 FIN_WAIT_2 状态，等待服务器端关闭连接。

  • 第三次挥手(FIN=1，seq=y)

    服务器端准备好关闭连接时，向客户端发送结束连接请求，FIN 置为1。

    发送完毕后，服务器端进入 LAST_ACK 状态，等待来自客户端的最后一个ACK。

  • 第四次挥手(ACK=1，ACKnum=y+1)

    客户端接收到来自服务器端的关闭请求，发送一个确认包，并进入 TIME_WAIT 状态，等待可能出现的要求重传的 ACK 包。

    服务器端接收到这个确认包之后，关闭连接，进入 CLOSED 状态。

四次挥手的示意图:

TCP四次挥手

KeepAlive 机制(http Keep-Alive 参考http)

KeepAlive并不是TCP协议规范的一部分，但在几乎所有的TCP/IP协议栈（不管是Linux还是Windows）中，都实现了KeepAlive功能。

RFC1122#TCP Keep-Alives

在Linux内核设置

KeepAlive默认不是开启的，如果想使用 KeepAlive，需要在你的应用中设置SO_KEEPALIVE才可以生效。

查看当前的配置：

cat /proc/sys/net/ipv4/tcp_keepalive_time
cat /proc/sys/net/ipv4/tcp_keepalive_intvl
cat /proc/sys/net/ipv4/tcp_keepalive_probes

在Linux中我们可以通过修改 /etc/sysctl.conf 的全局配置：

net.ipv4.tcp_keepalive_time=7200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=9

添加上面的配置后输入 sysctl -p 使其生效，你可以使用 sysctl -a | grep keepalive 命令来查看当前的默认配置

如果应用中已经设置 SO_KEEPALIVE，程序不用重启，内核直接生效

在Nginx中配置

在Nginx中配置TCP的KeepAlive非常简单，在listen指令下配置so_keepalive就可以了，具体配置

so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]

例子

so_keepalive=30m::10
   will set the idle timeout (TCP_KEEPIDLE) to 30 minutes,
   leave the probe interval (TCP_KEEPINTVL) at its system default,
   and set the probes count (TCP_KEEPCNT) to 10 probes.

和Http中Keep-Alive的关系

  • HTTP协议的 Keep-Alive 意图在于连接复用，同一个连接上串行方式传递请求-响应数据
  • TCP的KeepAlive机制意图在于保活、心跳，检测连接错误

SYN攻击

  1. 什么是 SYN 攻击（SYN Flood）?

    • 在三次握手过程中，服务器发送 SYN-ACK 之后，收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后，服务器才能转入 ESTABLISHED 状态.

    • SYN 攻击指的是，攻击客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN包，服务器回复确认包，并等待客户的确认。由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，导致目标系统运行缓慢，严重者会引起网络堵塞甚至系统瘫痪。

    • SYN 攻击是一种典型的 DoS/DDoS 攻击。

  2. 如何检测 SYN 攻击

    • 检测 SYN 攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

  3. 如何防御 SYN 攻击

    • SYN攻击不能完全被阻止，除非将TCP协议重新设计。我们所做的是尽可能的减轻SYN攻击的危害，常见的防御 SYN 攻击的方法有如下几种：

      • 缩短超时（SYN Timeout）时间
      • 增加最大半连接数
      • 过滤网关防护
      • SYN cookies技术