TCP报文段的首部格式
TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段
TCP报文段首部前20个字节是固定的，后面有4n（n为整数）个字节可以根据需要而增加，整个报头最多为60字节
首部字段：
端口号
端口号字段包括源端口号与目的端口号；
每个端口号字段长度为16 位（2字节），分别表示发送该报文段的应用进程的源端口号与接收进程的目的端口号。
序号
序号字段长度为32位（4个字节），序号范围在0～（232-1），即0～4284967295；序号增加到232-1后，下一个序号又回到0；
为发送字节流中的每个字节都按顺序编号,起始序号必须在连接建立时设置；序号字段值是本报文段所发送的数据的第一个字节的序号
例如，一个报文段的序号字段为301，携带数据为100字节，第二个报文段的序号就要是401
确认号
确认号字段长度为32 位（4字节）；确认号表示一个进程已经正确接收序号为N-1之前的字节（包含N-1），要求发送方下一个应该发送序号为N的字节的报文段。
例如，A发送一个序号为301，长度为100个字节的数据给B，B此时需要回复一个为401的确认号，以此来确认已经收到前400个字节的数据
报头长度
报头长度也称数据偏移，都是说头部长度，只是角度不同。报头长度字段的长度为4位;TCP报头长度是以4字节为一个单元来计算的，实际报头长度是在20～60字节，因此这个字段的值是在5至15之间。
保留
占6位，保留今后使用，目前全部置为0
控制字段
控制字段定义了6种不同的控制位或标志位;
控制字段将在TCP的连接建立和终止、流量控制，以及数据传送中发挥作用。
| 标志 | 说明 |
|---|---|
| SYN | 在连接时对序号进行同步 |
| ACK | 确认字段的值有效。当ACK=1时，确认号才有效 |
| FIN | 终止连接 |
| RST | 连接必须复位。TCP连接出现严重差错要重新建立连接。还可用来拒绝一个非法报文段或拒绝打开一个链接。 |
| URG | 紧急指针字段的值有效。有紧急数据尽快传送，插入到报文段最前面，与紧急指针配合使用。 |
| PSH | 将数据推向前，希望立即收到对方响应。接收方收到后尽快交付给接收应用进程 |
窗口大小
窗口字段长度为16位;窗口的长度值是在0～65535之间；
窗口字段值指示对方最多可以发送的字节数，作为发送方确定发送窗口的依据。明确指出了从被确认的字节算起可以发送的数据量。窗口字段值是动态变化的。窗口值为0也是合法的。表示接收方暂时不能接收数据，发送方要停止发送。
校验和
计算校验和与UDP校验和的方法相同；
TCP校验和同样需要伪报头，唯一不同的是协议字段的值是6。
紧急指针
紧急指针字段的长度为16位，只有当紧急标志URG=1时，这个字段才有效，这时的报文段中包括紧急数据；指出了紧急数据的末尾在报文段中的位置。
TCP软件要在优先处理完紧急数据之后才能够恢复正常操作。
注意，即使窗口为零时也可以发送紧急数据。
TCP最早只规定了一种选项，即最大报文段长度MSS（Maximum Segment Size）
TCP报文段的最大长度与窗口长度的概念不同：
- 设置窗口大小是通知发送方下一次可以连续传输的字节数；
- 最大段长度MSS是在构成一个TCP 报文段时最多可以在报文的数据- - 字段中放置的数据字节数量；
- MSS值的确定与每次传输的窗口大小无关；
- MSS是TCP报文中数据部分的最大长度，不包括报头长度。
TCP的运输连接
建立连接-->三次握手
B的TCP服务器先创建传输控制块TCB，准备接受客户进程的连接请求，然后服务进程就处于listen状态。
第一次握手：首先创建传输控制模块TCB，向B发出连接请求报文段，这是首部中的同步位SYN=1，同时选择1个随机初始序号x，此时不能携带数据，但需要消耗一个序号。
第二次握手：B收到请求后，如果同意连接的情况下，向A发送确认。此时SYN=1，ACK=1，确认号ack=x+1，同时自己选择一个初始序列号seq=y。此时这个报文也不能携带数据，但需要消耗一个序号。
第三次握手：A收到B的确认后，需要向B确认，确认报文段ACK=1，ack=y+1，seq=x+1，这时连接已建立。此时，若这个报文不携带数据则不消耗序列号，下一个报文的序列号还是seq=x+1。
问题：为什么A最后要在发送一次确认？
答：主要是防止已失效的连接请求报文突然又传送到了B，从而产生错误。
由于有了A再发一次确认，当一个失效的请求到B后，B发来一个确认，而A此时并没有请求，所以不会理睬此B的确认，也不会再发一次确认。从而没有建立连接。
断开连接-->四次挥手
- 第一次挥手：主机A发送位码为FIN＝1，用来关闭客户A到服务器B的数据传送。此时A的状态为FIN_WAIT_1
- 服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。此时A为FIN_WAIT_2，B为CLOSE_WAIT
- 服务器B关闭与客户端A的连接，发送一个FIN给客户端A。此时A为TIME_WAIT，B为LAST_ACK
- 客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。此时A、B都关闭了，状态变为CLOSED。
当（2）、（3）步中的ACK和FIN在一个包中发送时，A的状态会直接从FIN_WAIT_1变为TIME_WAIT
问题：为什么建立连接需要三次握手，而断开连接需要四次握手？
因为每个方向都需要一个FIN和ACK，当一端发送了FIN包之后，处于半关闭状态，此时仍然可以接收数据包。
在建立连接时，服务器可以把SYN和ACK放在一个包中发送。
但是在断开连接时，如果一端收到FIN包，但此时仍有数据未发送完，此时就需要先向对端回复FIN包的ACK。等到将剩下的数据都发送完之后，再向对端发送FIN，断开这个方向的连接。
因此很多时候FIN和ACK需要在两个数据包中发送，因此需要四次握手
DOS攻击和SYN洪水攻击
DOS攻击利用合理的服务请求占用过多的服务资源，使正常用户的请求无法得到相应。
常见的DOS攻击有计算机网络带宽攻击和连通性攻击。
带宽攻击指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。
连通性攻击指用大量的连接请求冲击计算机，使得所有可用的操作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求。
SYN洪水攻击
SYN洪水攻击属于DOS攻击的一种，它利用TCP协议缺陷，通过发送大量的半连接请求，耗费CPU和内存资源。
客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送SYN报文，服务器回复ACK确认报文，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN报文被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。
