TCP Retrasmission
Fast Retrasmission
TCP—序号、确认号
建立连接三次握手，释放连接四次挥手
SYN：同步
先建立连接，然后在开始发送数据，服务器连续发好几个包，客户端才发一个
两方都有可能成为接收方，都有可能成为发送方，数据的传输是双向的。
真实情况是连发好几个包，才发送一个确认号
序号：告诉对方，我现在发送到哪里了
ACK：告诉对方我现在接收到那了，你接下来继续给我发
以上图片用到的数据是相对值，并非真实值，真实值是一个很大的值
第一部分是建立连接，第二部分才开始收发数据
序号的值是随机生成的，两端的初始值完全不一样。
建立连接的请求，同步包数据部分是零的，只有首部
ack在收到对方多少的数据上加1
建立连接之后，客户端发送http请求，数据部分占k字节
对对方发送数据的回应，数据部分为0
只要是基于TCP的，你都要先建立连接，在发送数据，在释放连接
三次握手，一般都是客户端发起，不可能是服务器发起的
客户端一开始是出于关闭状态的
服务器占用一个端口，在这个端口上运行服务器软件，进行监听客户端发过来的数据
TCP—建立连接—状态解读
◼ CLOSED：client处于关闭状态
◼ LISTEN：server处于监听状态，等待client连接
◼ SYN-RCVD：表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
◼ SYN-SENT：表示client已发送SYN报文，等待server的第2次握手
◼ ESTABLISHED：表示连接已经建立
TCP—建立连接—前2次握手的特点
◼ SYN都设置为1
◼ 数据部分的长度都为0
◼ TCP头部的长度一般是32字节
固定头部：20字节
选项部分：12字节
◼ 双方会交换确认一些信息
比如MSS、是否支持SACK、Window scale（窗口缩放系数）等
这些数据都放在了TCP头部的选项部分中（12字节）
只有拿到windows scale，根据windows，才会知道windows size
windows*windows scale=windows size
TCP—建立连接—疑问
◼ 为什么建立连接的时候，要进行3次握手？2次不行么？
主要目的：防止server端一直等待，浪费资源
◼ 如果建立连接只需要2次握手，可能会出现的情况
假设client发出的第一个连接请求报文段，因为网络延迟，在信息交流完毕，连接释放以后的某个时间才到达server
本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求
于是server就向client发出确认报文段，同意建立连接
如果不采用“三次握手”，那么只要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包，强制关闭连接（把服务器给惹毛了）
（看到超时那部分就可以了）