◼ URG（Urgent）
当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送
◼ ACK（Acknowledgment）
当ACK=1时，确认号字段才有效
◼ PSH（Push）
◼ RST（Reset）
当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
◼ SYN（Synchronization）
当SYN=1、ACK=0时，表明这是一个建立连接的请求
若对方同意建立连接，则回复SYN=1、ACK=1
◼ FIN（Finish）
当FIN=1时，表明数据已经发送完毕，要求释放连接
◼ 序号（Sequence Number）
占4字节
首先，在传输过程的每一个字节都会有一个编号
在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号
◼ 确认号（Acknowledgment Number）
占4字节
在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号
◼ 窗口（Window）
占2字节
这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）
1. TCP-建立连接--3次握手
数据发送
建立连接 次握手
第1次连接：SYN=1代表要和服务器建立连接请求，sep=x 为客户端要获取服务端数据的第一个字节的编号
第2次连接：SYN=1代表要和客户端建立连接请求，sep=y 为服务器要获取客户端数据的第一个字节的编号，ACK=1为回应客户端请求，ack=x+1为期望客户端下一次传过来X的下一个数据的第一个开始序号
第3次连接：SYN=0本次不需要发送连接请求，ACK=1为回应服务器请求，sep=x+1 为客户端要获取服务器数据x的下一个数据的第一个序号，ack=y+1为期望服务器下一次传过来y的下一个数据的第一个开始序号
1.1 建立连接--状态解读
◼ CLOSED：client处于关闭状态
◼ LISTEN：server处于监听状态，等待client连接
◼ SYN-RCVD：表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
◼ SYN-SENT：表示client已发送SYN报文，等待server的第2次握手
◼ ESTABLISHED：表示连接已经建立
1.2 建立连接 前 次握手的特点
◼ SYN都设置为1
◼ 数据部分的长度都为0
◼ TCP头部的长度一般是32字节
固定头部：20字节
选项部分：12字节
◼ 双方会交换确认一些信息
比如MSS、是否支持SACK、Window scale（窗口缩放系数）等
这些数据都放在了TCP头部的选项部分中（12字节）
1.3 建立连接--疑问
◼ 为什么建立连接的时候，要进行3次握手？2次不行么？
主要目的：防止server端一直等待，浪费资源
◼ 如果建立连接只需要2次握手，可能会出现的情况
假设client发出的第一个连接请求报文段，因为网络延迟没有到达server，然后client又重新发了一个连接请求，这次能正常到达server，然后server和client能正常建立连接并相互发送数据，数据发送完成并连接释放，而前面第一个连接在连接释放以后的某个时间才到达server
本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求
于是server就向client发出确认报文段，同意建立连接
如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了
由于现在client前面已经建立连接并完成了请求，并没有再想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据
但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了
◼ 采用“三次握手”的办法可以防止上述现象发生
例如上述情况，client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接
◼ 第3次握手失败了，会怎么处理？
此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包
如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接
2. TCP-释放连接--4次挥手
TCP-释放连接 4次挥手
2.1 释放连接--状态解读
◼ FIN-WAIT-1：表示想主动关闭连接
向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
◼ CLOSE-WAIT：表示在等待关闭
当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
◼ FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
◼ CLOSING：一种比较罕见的例外状态
表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
表示双方都正在关闭连接
◼ LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文
当收到ACK报文后，即可进入CLOSED状态了
◼ TIME-WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可进入CLOSED状态了
如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时
✓ 可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态
◼ CLOSED：关闭状态
◼ 由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD、FIN-WAIT-1等
2.2 释放连接--细节
◼ TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开
◼ client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
一般是等待2倍的MSL（Maximum Segment Lifetime，最大分段生存期）
✓ MSL是TCP报文在Internet上的最长生存时间
✓ 每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟
✓ 可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包都会在2MSL时间内消失了）
◼ 如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN
这时可能出现的情况是
① client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
② client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来
它可能是想跟server建立连接的
2.3 释放连接--疑问
◼ 为什么释放连接的时候，要进行4次挥手？
TCP是全双工模式
第1次挥手：当主机1发出FIN报文段时
✓ 表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
第2次挥手：当主机2返回ACK报文段时
✓ 表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的
第3次挥手：当主机2也发送了FIN报文段时
✓ 表示主机2告诉主机1，主机2已经没有数据要发送了
第4次挥手：当主机1返回ACK报文段时
✓ 表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接
2.4 释放连接--抓包
◼ 有时候在使用抓包工具的时候，有可能只会看到“3次“挥手
这其实是将第2、3次挥手合并了
◼ 当server接收到client的FIN时，如果server后面也没有数据要发送给client了
这时，server就可以将第2、3次挥手合并，同时告诉client两件事
✓ 已经知道client没有数据要发
✓ server已经没有数据要发了