小码哥《网络协议从入门到底层原理》笔记（九）：TCP序号、确认号、建立连接、释放连接第一步建立连接，客户端向服务器发送S

我的Github地址

小码哥《恋上数据结构与算法》笔记

极客时间《iOS开发高手课》笔记

iOS大厂面试高频算法题总结

iOS面试资料汇总

序号、确认号

SYN都设置为1
数据部分的长度都为0
TCP头部的长度一般是32字节
- 固定头部：20字节
- 选项部分：12字节
双方会交换确认一些信息
- 比如MSS，是否支持SACK，Window scale（窗口缩放系数）等
- 这些数据都放在了TCP头部的选项部分中（12字节）

为什么建立连接的时候，要进行3次握手，2次不行吗？
- 主要目的: 防止server端一直等待，浪费资源
如果建立连接只需要2次握手，可能会出现的情况
- 假设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包，强制关闭连接

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等

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建立连接的