首部格式
各个段位说明:
- 源端口和目的端口: 各占 2 字节.端口是传输层与应用层的服务接口.传输层的复用和分用功能都要通过端口才能实现
- 序号: 占 4 字节.TCP 连接中传送的数据流中的每一个字节都编上一个序号.序号字段的值则指的是本报文段所发送的数据的第一个字节的序号
- 确认号: 占 4 字节,是期望收到对方的下一个报文段的数据的第一个字节的序号
- 数据偏移/首部长度: 占 4 位,它指出 TCP 报文段的数据起始处距离 TCP 报文段的起始处有多远.“数据偏移”的单位是 32 位字(以 4 字节为计算单位)
保留: 占 6 位,保留为今后使用,但目前应置为 0 - 紧急URG: 当 URG=1 时,表明紧急指针字段有效.它告诉系统此报文段中有紧急数据,应尽快传送(相当于高优先级的数据)
- 确认ACK: 只有当 ACK=1 时确认号字段才有效.当 ACK=0 时,确认号无效
- PSH(PuSH): 接收 TCP 收到 PSH = 1 的报文段,就尽快地交付接收应用进程,而不再等到整个缓存都填满了后再向上交付
- RST (ReSeT): 当 RST=1 时,表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因）,必须释放连接,然后再重新建立运输连接
- 同步 SYN: 同步 SYN = 1 表示这是一个连接请求或连接接受报文
- 终止 FIN: 用来释放一个连接.FIN=1 表明此报文段的发送端的数据已发送完毕,并要求释放运输连接
- 检验和: 占 2 字节.检验和字段检验的范围包括首部和数据这两部分.在计算检验和时,要在 TCP 报文段的前面加上 12 字节的伪首部
- 紧急指针: 占 16 位,指出在本报文段中紧急数据共有多少个字节（紧急数据放在本报文段数据的最前面）
- 选项: 长度可变.TCP 最初只规定了一种选项,即最大报文段长度 MSS.MSS 告诉对方 TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节.” [MSS(Maximum Segment Size)是 TCP 报文段中的数据字段的最大长度.数据字段加上 TCP 首部才等于整个的 TCP 报文段]
- 填充: 这是为了使整个首部长度是 4 字节的整数倍
- 其他选项:
– 窗口扩大: 占 3 字节,其中有一个字节表示移位值 S.新的窗口值等于TCP 首部中的窗口位数增大到(16 + S),相当于把窗口值向左移动 S 位后获得实际的窗口大小
– 时间戳: 占10 字节,其中最主要的字段时间戳值字段(4字节)和时间戳回送回答字段(4字节)
– 选择确认: 接收方收到了和前面的字节流不连续的两2字节.如果这些字节的序号都在接收窗口之内,那么接收方就先收下这些数据,但要把这些信息准确地告诉发送方,使发送方不要再重复发送这些已收到的数据。
三次握手
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：
怎么理解三次握手，为什么不是两次或四次
我们可以模拟两个人的通信，假设A在南极，B在北极，A想和B通信，
- 第一次握手: A发起通话，这个时候A并不知道B有没有收到，必须等B给出回应，告诉A。也就是说第一次握手，A并不知道自己的发送和接收的功能正不正常
- 第二次握手: B收到A的消息了，B知道了自己了接收没有问题，A的发送没有问题，然后回复A，这个时候，B并不知道自己的发送有没有问题，必须等待A的回复
- 第三次握手: A 收到B的回复，A知道了自己的发送接收没有问题，B的接收和发送没有问题，但是B还不知道自己的发送有没有问题，经过A第三次握手告诉B，B收到A的回复后，A，B双方都知道的自己和对方的发送和接收都没有问题，这样才能进行全双工通信。
经过上面的分析，必须经过三次握手，确保双方的 接收 和 发送都没有问题，少了一次就没法保证双方的收发没有问题，多了就多余了。
四次挥手
所谓的四次挥手即TCP连接的释放(解除)。连接的释放必须是一方主动释放，另一方被动释放。以下为客户端主动发起释放连接的图解：
四次挥手过程说明
1、 客户端发送断开TCP连接请求的报文，其中报文中包含seq序列号，是由发送端随机生成的，并且还将报文中的FIN字段置为1，表示需要断开TCP连接。（FIN=1，seq=x，x由客户端随机生成）
2、 服务端收到客户端的断开请求，不会立马断开，因为服务端收到断开请求后，有可能还在向客户端发送数据，所以服务端会先回复客户端发送的TCP断开请求报文，其包含seq序列号，是由回复端随机生成的，而且会产生ACK字段，ACK字段数值是在客户端发过来的seq序列号基础上加1进行回复，以便客户端收到信息时，知晓自己的TCP断开请求已经得到验证。（FIN=1，ACK=x+1，seq=y，y由服务端随机生成）
3、 服务端在回复完客户端的TCP断开请求后，不会马上进行TCP连接的断开，服务端会先确保断开前，会确认传输到A的数据已经传输完毕，一旦确认传输数据完毕，就会将回复报文的FIN字段置1，并且产生随机seq序列号。（FIN=1，ACK=x+1，seq=z，z由服务端随机生成）
4、 客户端收到服务端的TCP断开请求后，会回复服务端的断开请求，包含随机生成的seq字段和ACK字段，ACK字段会在服务端的TCP断开请求的seq基础上加1，从而完成服务端请求的验证回复。（FIN=1，ACK=z+1，seq=h，h为客户端随机生成）
至此TCP断开的4次挥手过程完毕
为什么客户端在TIME-WAIT阶段要等2MSL?
- 为的是确认服务器端是否收到客户端发出的ACK确认报文
- 当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
- 服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文。
- 所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因。
校验和计算
RFC 793的TCP校验和定义：
首先，把伪首部、TCP报头、TCP数据分为16位的字，如果总长度为奇数个字节，则在最后增添一个位都为0的字节。把TCP报头中的校验和字段置为0（否则就陷入鸡生蛋还是蛋生鸡的问题）。
其次，用反码相加法累加所有的16位字（进位也要累加）。
最后，对计算结果取反，作为TCP的校验和。
举列说明：
1、首先将检验和置零；
2、然后将TCP伪首部部分，TCP首部部分，数据部分都划分成16位的一个个16进制数
3、将这些数逐个相加，记得溢出的部分加到最低位上，这是循环加法：
0xc0a8+ 0x0166+……+0x0402=0x9b49
4、最后将得到的结果取反，则可以得到检验和位0x64b6
流量控制
流量控制的原因
- 双方在通信的时候，发送方的速率与接收方的速率是不一定相等，如果发送方的发送速率太快，会导致接收方处理不过来，这时候接收方只能把处理不过来的数据存在缓存区里（失序的数据包也会被存放在缓存区里）。
- 如果缓存区满了发送方还在疯狂着发送数据，接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源，因此，我们需要控制发送方的发送速率，让接收方与发送方处于一种动态平衡才好。
流量控制的依据：
（1）接收端抑制发送端的依据：接收端缓冲区的大小
（2）流量控制的目标是接收端，是怕接收端来不及处理
（3）流量控制的机制是丢包
在确认应答策略中，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段，这样做有一个比较大的缺点，就是性能比较差，尤其是数据往返的时间长的时候，使用滑动窗口，就可以一次发送多条数据，从而就提高了性能。
- 滑动窗口知识点
（1）接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK来通知发送端
（2）窗口大小字段越大，说明网络的吞吐率越高
（3）窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，即就是说不需要接收端的应答，可以一次连续的发送数据
（4）操作系统内核为了维护滑动窗口，需要开辟发送缓冲区，来记录当前还有那些数据没有应答，只有确认应答过的数据，才能从缓冲区删掉
如何进行流量控制
-
接收方每次收到数据包，可以在发送确定报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。
-
发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。
发送方何时再继续发送数据
当发送方停止发送数据后，该怎样才能知道自己可以继续发送数据？
我们可以采用这样的策略：当接收方处理好数据，接受窗口 win > 0 时，接收方发个通知报文去通知发送方，告诉他可以继续发送数据了。当发送方收到窗口大于0的报文时，就继续发送数据。
不过这时候可能会遇到一个问题，假如接收方发送的通知报文，由于某种网络原因，这个报文丢失了，这时候就会引发一个问题：接收方发了通知报文后，继续等待发送方发送数据，而发送方则在等待接收方的通知报文，此时双方会陷入一种僵局。
为了解决这种问题，我们采用了另外一种策略：当发送方收到接受窗口 win = 0 时，这时发送方停止发送报文，并且同时开启一个定时器，每隔一段时间就发个测试报文去询问接收方，打听是否可以继续发送数据了，如果可以，接收方就告诉他此时接受窗口的大小；如果接受窗口大小还是为0，则发送方再次刷新启动定时器。
1、这里说明下，由于TCP/IP支持全双工传输，因此通信的双方都拥有两个滑动窗口，一个用于接受数据，称之为接收窗口；一个用于发送数据，称之为拥塞窗口(即发送窗口)。指出接受窗口大小的通知我们称之为窗口通告。
2、接收窗口的大小固定吗？
在早期的TCP协议中，接受接受窗口的大小确实是固定的，不过随着网络的快速发展，固定大小的窗口太不灵活了，成为TCP性能瓶颈之一，也就是说，在现在的TCP协议中，接受窗口的大小是根据某种算法动态调整的。
3、接受窗口越大越好吗？
接受窗口如果太小的话，显然这是不行的，这会严重浪费链路利用率，增加丢包率。那是否越大越好呢？答否，当接收窗口达到某个值的时候，再增大的话也不怎么会减少丢包率的了，而且还会更加消耗内存。所以接收窗口的大小必须根据网络环境以及发送发的的拥塞窗口来动态调整。
4、发送窗口和接受窗口相等吗？
接收方在发送确认报文的时候，会告诉发送发自己的接收窗口大小，而发送方的发送窗口会据此来设置自己的发送窗口，但这并不意味着他们就会相等。首先接收方把确认报文发出去的那一刻，就已经在一边处理堆在自己缓存区的数据了，所以一般情况下接收窗口 >= 发送窗口。
拥塞控制
在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫做网络拥塞。
在计算机网络中数位链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。
若出现拥塞而不进行控制，整个网络的吞吐量将随输入负荷的增大而下降。
当输入的负载到达一定程度 吞吐量不会增加，即一部分网络资源会丢失掉，网络的吞吐量维持在其所能控制的最大值，转发节点的缓存不够大这造成分组的丢失是拥塞的征兆。
TCP的四种拥塞控制算法
1.慢开始
a.算法原理：当主机开始发送数据时，如果立即将大量数据字节注入到网络，那么就有可能因为不清楚当前网络的负荷情况而引起网络阻塞。所以，最好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值。通常在刚刚发送报文段时，先把拥塞窗口cwnd设置为一个最大报文段MSS(MSS是TCP数据包每次能够传输的最大数据分段)的数值。而在每收到一个新的报文段的确认后，把拥塞窗口增加至多一个MSS的数值。用这样的方法逐步增大发送方的拥塞窗口cwnd，可以使分组注入到网络的速率更加合理。（慢开始当中的“慢”并不是指cwnd的增长速率慢，而是在TCP开始发送报文段时先设置cwnd = 1,使得发送方在开始时只发送一一个报文段）
当rwnd足够大的时候，为了防止拥塞窗口cwnd的增长引起网络阻塞，还需要另外一个变量------慢开始门限ssthresh.
1、 当cwnd < ssthresh时，使用上述慢启动算法；
2、当cwnd >ssthresh时，停止使用慢启动算法，改用拥塞避免算法；
b.慢开始的局限性
1、需要获得网络内部流量分布的信息，浪费可用的网络容量，额外开销；
2、估算合理的ssthresh值并不容易，可能耗时较长；
注：1、接收端窗口rwnd，又称通知窗口（awnd），是接收端根据目前的接收缓存大小所许诺的最新窗口值，是来自接收端的流量控制。
2、拥塞窗口cwnd是发送端根据自己估计的网络阻塞程度而设置的窗口值，是来自发送端的流量控制。
3、MSS是TCP数据包每次能够传输的最大数据分段，其中并不包括TCP首部。而MSS只出现在syn报文段当中。一般来说MSS的值在不分段的情况下越大越好（eg:一个外出接口的MSS值时MTU减去IP和TCP首部长度）
2.拥塞避免
a.算法思路：让拥塞窗口cwnd缓慢的增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍，这样拥塞窗口cwnd按线性规律缓慢的增长，比慢开始算法的拥塞窗口增长速率缓慢的多
无论是慢启动算法还是拥塞避免算法，只要判断网络出现拥塞，就要把慢启动开始门限（ssthresh）设置为发送窗口的一半（>=2），cwnd设置为1，然后再使用慢启动算法，这样做的目的能迅速的减少网络当中的数据传输，使发生拥塞的路由器能够把队列中堆积的分组处理完毕。拥塞窗口是按照线性的规律增长
b.控制过程
（1）TCP连接初始化，将拥塞窗口cwnd设置为1个报文段，即cwnd = 1;
（2）执行慢开始算法，cwnd按指数规律增长，知道cwnd == ssthresh时，开始执行拥塞避免算法，cwnd开始按照线性规律增长；
（3）当网络发生拥塞，把ssthresh值更新为拥塞前ssthresh值的一半，cwnd重新设置为1，再按照2执行；
例如：
a.在TCP连接进行初始化的时候，cwnd = 1，ssthresh = 16;
b.在慢启动算法开始时，cwnd的初始值是1，每次发送方收到一个ACK拥塞窗口就增加1，当ssthresh == cwnd时，启动拥塞控制算法，拥塞窗口按照线性规律增长；
c.当cwnd = 24时，网络出现超时，发送方收不到确认ACK，此时设置ssthresh = 12,设置cwnd = 1,然后开始慢启动算法，当cwnd = ssthresh=12，慢启动算法变为拥塞控制算法，cwnd按照线性速度增长
AIMD（加法增大乘法减小）
a.乘法减小：无论在慢启动阶段还是在拥塞控制阶段，只要网络出现超时，就是将cwnd置为1，sthresh置为cwnd的一半，然后开始执行慢启动算法
b.加法增大：当网络频发出现超时情况时，ssthresh就下降的很快，为了减少注入到网络当中的分组数，而加法增大是执行拥塞避免算法后，是拥塞窗口缓慢的增大，以防止网络过早出现拥塞。
这两个结合起来就是AIMD算法，是使用最广泛的算法。拥塞避免算法不能够完全避免网络y拥塞，通过控制拥塞窗口的大小只能使网络不易出现拥塞。
3.快重传
一条TCP连接有时会因为等待重传计时的超时而空闲较长时间，慢开始和拥塞避免无法解决这类问题，因此提出了快重传和快恢复的拥塞控制方法。
a.算法过程：
快重传算法要求首先接收方收到一个失序的报文段后立刻发出重复确认，而不要等待自己发送数据时才进行捎带确认，如下图:
在上图中，接收方成功的接受了发送方发来的M1,M2并且分别发送了ACK，现在接收方没有收到M3，而收到了M4，显然接收方不能确认M4，因为M4是失序的报文段。如果根据可靠性传输原理接收方什么都不做，但是按照快速重传算法，在收到M4,M5等报文段的时候，不断重复的向发送方发送M2的ACK，如果接收方一连收到三个重复的ACK，那么发送方不必等待重传计时器到期，由于发送方尽早重传未被确认的报文段
4.快恢复
1).当发送方连续收到三个重复确认时，执行“乘法减小”算法，慢启动门限减半，为了预防网络发生阻塞
2).由于发送方现在认为网络很可能没有发生阻塞，因此现在不执行慢启动算法，而是把cwnd值设置为慢启动门限减半后的值，然后开始执行拥塞避免算法，拥塞窗口cwnd值线性增大。
TCP拥塞控制面试题
1、什么是拥塞？什么是拥塞控制？
在某段时间内，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就称为拥塞。
简单的说拥塞产生的原因有两点：（1）接收方容量不够（2）网络内部有瓶颈
拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
2、检测网络拥塞的方法？
检测网络拥塞的指标是：由于缺少缓存空间而被丢弃的分组的百分数、平均队列长度、超时重传的分组数、平均分组时延、分组时延的标准差等，这些指标的上升都标志着拥塞的增长。
可以使用这种方法来检测，在路由转发的分组中保留一个比特或字段，用该比特或字段的值表示网络有没有拥塞或产生了拥塞。也可以由一些主机或路由器周期性的发出探测分组，以询问拥塞是否发生。
3、网络拥塞的表现？
（1）收到重复的ACK。发送的包可能有些丢失，但是接收方没有接收到，而发送方由于发送窗口还可以发送，还在继续发，而接收方由于没有收到丢失的那个包，只能不断请求发送那个包对应的序列号。
（2）出现了超时。当网路发生拥塞的时，路由器就要丢弃分组。因此只要发送方没有按时收到应当到达的确认报文，也就是说，只要出现了超时，就可以猜想网络可能出现了拥塞。（现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率都很小，远小于1%）（这也是发送方如何知道网络发生了拥塞的方法）