TCP详解

• 面向连接的、可靠的、基于字节流的传输层通信协议
• 将应用层的数据流分割成报文段发送给目标节点
• 数据包都有序号
• 用校验（奇偶检验、海明码）来检测数据在传输过程中是否有误

TCP头部

• 源端口号、目的端口号：标识主机中的进程，两字节
• 序列号：四个字节，标识第一个数据字节的序号
• 确认序列号号：四个字节期望收到对方下一个报文 的第一个数据字节的序列号
• 数据偏移：一个字节，由于TCP头部长度不固定，这个字节指出第一个数据距离头部有多远
• 保留：一个字节，一般为0
• 控制位：一个字节，有8个控制位
  URG：紧急指针标志，为1表示紧急指针有效
  ACK：确认序列号，1有效，0表示确认序列号效
  PUH：push标志，1表示应尽快将报文交给应用程序，而不是在缓冲区排队
  RST：重置连接标志，用于拒绝由于故障导致错误的连接和非法的连接请求
  SYN：同步序列号，用于建立连接过程，当SYN等于1，ACK为0表示未使用捎带确认号
  FIN：用于释放连接
• 滑动窗口大小：两个字节，用于告知发送方滑动窗口的大小，以达到流量控制
• 校验和：两个字节，校验头部
• 紧急指针：两个字节，只有当URG为1该字段才有效，指出本报文紧急字段的字节数
• 可选项

三次握手

• 第一次握手：客户端给服务端发一个 SYN 报文（seq=x，SYN=1），此时客户端处于 SYN_SENT 状态。初始序号的报文段不能携带数据，但要消耗掉一个序号。（为了防止对服务器 的恶意攻击）
• 第二次握手：服务器收到客户端的 SYN 报文之后（服务器确认了客户端的发送能力），发送确认报文（SYN=1，ACK=1，确认号ack=x+1，seq=y）此时服务器处于 SYN_RCVD 的状态。（此报文段也不可携带数据）
• 第三次握手：客户端收到 SYN 报文之后（客户端确认了服务器的发送和接收能力），会发送一个 ACK 报文（seq=x+1，ack=y+1，SYN=1，ACK=1）（让服务器确认客户端的接收能力）
  服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
  ACK报文段可以携带数据，不携带数据则不消耗序号。

SYN攻击

Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪
防护措施：SYN队列满后，通过tcp_syncookies参数回发SYN Cookie，正常的客户端会回发SYN Cookie ，则可之间建立连接

保活机制

• 如果建立连接后，客户端出现故障，服务器会向客户端发送探测保活报文
• 在发送一定次数保活探测报文仍未收到回应则中断连接

四次挥手

• 第一次挥手：（客户端数据发送完毕后）客户端发送FIN 报文（FIN=1，序号seq=u），此时客户端处于 FIN_WAIT1 状态，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。
• 第二次挥手：服务端收到 FIN 之后发送 ACK 报（ACK=1，确认号ack=u+1，序号seq=v）服务端处于 CLOSE_WAIT 状态。此时的TCP处于半关闭状态，客户端到服务端的连接释放。
  客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。
• 第三次挥手：（服务器数据也发送完毕后）服务端也想断开连接了，发 FIN 报文（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），此时服务端处于 LAST_ACK 的状态，等待客户端的确认。
• 第四次挥手：客户端收到 FIN 之后，发送 ACK 报文ACK=1，seq=u+1，ack=w+1）作为应答，此时客户端处于 TIME_WAIT 状态。需要过2MSL以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态。
  服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。
  服务器出现大量CLOSE_WAIT状态原因：
  对方关闭连接，而我方忙于读写，没有及时关闭
• 检查释放资源代码
• 检查线程配置

滑动窗口（流量控制）

滑动窗口解决的是流量控制的的问题，就是如果接收端和发送端对数据包的处理速度不同，如何让双方达成一致。

• TCP会话的双方都各自维护一个发送窗口和一个接收窗口。
• 各自的接收窗口大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）
• 各自的发送窗口则要求取决于对端通告的接收窗口。

发送方的发送缓存内的数据都可以被分为4类:

• 已发送，已收到ACK
• 已发送，未收到ACK
• 未发送，但允许发送
• 未发送，但不允许发送

接收方的缓存数据分为3类：

• 已接收（含发送了ACK和未发送ACK）
• 未接收但准备接收
• 未接收而且不准备接收

滑动机制
发送窗口只有收到发送窗口内字节的ACK确认，才会移动发送窗口的左边界。

接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。

遵循快速重传、累计确认、选择确认等规则。

发送方发的window size = 8192;就是接收端最多发送8192字节，这个8192一般就是发送方接收缓存的大小。