文章目录
一. 协议特点 & 报文段① 特点② 报文段首部格式二. TCP连接管理① 建立联系（三次握手）SYN洪泛攻击② 连接释放（四次挥手）三. TCP流量控制① 序号② 重传冗余ACK（快速重传）三. 流量控制① 定义② 实例四. TCP拥塞控制① 定义② 拥塞控制四种算法慢开始和拥塞避免快重传和快恢复一. 协议特点 & 报文段
① 特点
面向连接；虚连接（并非物理连接）因为是全双工，所以需要用到缓存比如下图，用123字节和TCP头组成报文段
② 报文段首部格式
序号：比如上图的123传递成功后，发送方要传送456字节，那么组成报文段中的序号就是4。确认号：用序号的例子，123传递成功后，接收方发送的报文段的确认号就是4（表示123已经收到，期待接收到4）填充：TCP首部大小需要满足是4B的倍数，因此需要填充0来结合选项大小满足4B数据偏移：由“填充”可知，TCP首部大小不一定是20B，因此需要用“数据偏移"部分来记录TCP首部的实际大小。
URG = 1：可以直接插队到最前面控制位、窗口可以结合后面的例子理解，这里可以先看定义。
对于检验和，UDP的第四个字段是17，和TCP的6不同。
二. TCP连接管理
类似打电话，采用客户服务器方式① 建立联系（三次握手）
参考上图男女的对话有ACK就有ackx，y都是随机的用到了控制位中的SYN(同步位)，和ACK(确认位)返回确认的确认时，可以携带数据。SYN洪泛攻击
用SYN cookie来解决简述：大量进行ROUND 1，而不进行ROUND 3，让服务器大量TCP连接挂起，浪费资源。② 连接释放（四次挥手）
先看下图男女对话，TCP的连接释放过程就类似下图半关闭状态：只是单向的连接释放，而非互相的连接释放。ROUND 2(ack=u+1)时客户端不用回复确认报文段，因为已经进入半关闭状态。ROUND 3的ack=u+1，因为ROUND 2时客户端并没有回送报文段。ROUND 3的seq = w，不一定有 w = v + 1，因为ROUND 2 - 3之间服务端可能还在发信息ROUND 4等待原理：
1） 如果确认报文段丢失了，A会在2MSL内收到B重发的ROUND 3数据报，并重新开始计算2MSL：如果之后报文段继续丢失，则重来一次这个操作；如果收到了，就圆满结束。
2）如果不设置这个操作，可能会出现因为报文段丢失，导致B一直处于等待报文段状态，无法正常结束。
3）为什么是2MSL：ROUND 4丢失的情况下，在1MSL的时候服务器会重传ROUND 3，然后再经历一个1MSL抵达客户端，
三. TCP流量控制
网络层不可靠，靠传输层用TCP实现可靠。如果是UDP，则在应用层实现可靠。机制：校验、序号、确认、重传
① 序号
发送123后（发123时序号字段为1）可见此时两方缓存都有123，发送方要等收到确认收到123的信息后才能把123从缓存中去掉。（便于在丢失时可以重传）此时发送了456、78，但是只有78传到了。则接收方回送报文段时，报文段首部确认号仍为4之后补上456后，因为接收方缓存中已经有78了，因此回送的报文段首部确认号会是9（累计确认）
② 重传
RTTs：发送第一个时，RTTs = RTT1_11。发送第二个后，RTTs由RTT1_11和RTT2_22来决定（并非平均），以此类推。
冗余ACK（快速重传）
通过收到多次冗余ack，判断报文段丢失三. 流量控制
① 定义
发送方的发送窗口：取接收窗口和拥塞窗口的最小值。发送窗口可以动态变化滑动窗口类似链路层的滑动窗口。② 实例
接收方可能会让发送方发送窗口为0，此时不能再发送。此时接收方把缓存数据上传，传完后再让接收方继续发。
在上例结束后，可能B会让A继续传输，但是发送报文段丢失。那么可能双方会一直僵持。解决方法见下图。
