一. 协议特点 & 报文段

① 特点

• 面向连接；虚连接（并非物理连接）
• 因为是全双工，所以需要用到缓存
  
• 比如下图，用123字节和TCP头组成报文段
  

② 报文段首部格式

• 序号：比如上图的123传递成功后，发送方要传送456字节，那么组成报文段中的序号就是4。
• 确认号：用序号的例子，123传递成功后，接收方发送的报文段的确认号就是4
  （表示123已经收到，期待接收到4）
• 填充：TCP首部大小需要满足是4B的倍数，因此需要填充0来结合选项大小满足4B
• 数据偏移：由“填充”可知，TCP首部大小不一定是20B，因此需要用“数据偏移"部分来记录TCP首部的实际大小。
  
• URG = 1：可以直接插队到最前面
• 控制位、窗口可以结合后面的例子理解，这里可以先看定义。
  
• 对于检验和，UDP的第四个字段是17，和TCP的6不同。
  

二. TCP连接管理

• 类似打电话，采用客户服务器方式
  

① 建立联系（三次握手）

• 参考上图男女的对话
• 有ACK就有ack
• x，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 = RTT${}_1$。
  发送第二个后，RTTs由RTT${}_1$和RTT${}_2$来决定（并非平均），以此类推。
  

冗余ACK（快速重传）

• 通过收到多次冗余ack，判断报文段丢失
  

三. 流量控制

① 定义

• 发送方的发送窗口：取接收窗口和拥塞窗口的最小值。
• 发送窗口可以动态变化
• 滑动窗口类似链路层的滑动窗口。
  

② 实例

• 接收方可能会让发送方发送窗口为0，此时不能再发送。
  此时接收方把缓存数据上传，传完后再让接收方继续发。
  
• 在上例结束后，可能B会让A继续传输，但是发送报文段丢失。那么可能双方会一直僵持。解决方法见下图。
  

四. TCP拥塞控制

① 定义

• 拥塞：网络状况不好，接收、发送数据慢
• 流量控制：点到点，防止发送方发太快，出问题知道找哪台主机。
• 拥塞控制：全局，发送方发送不到接收方，出问题不知道找哪台主机
  

② 拥塞控制四种算法

慢开始和拥塞避免

• 慢开始：虽然是指数增长，但是起点低（1、2、4…）
• ssthresh：慢开始门限值，说明要开始慢点加了。
• 新ssthresh：一发生拥塞，就生成新ssthresh，值为拥塞时cwnd的一半（如图中为 24/2 = 12）
• 拥塞直接降到1。
  

快重传和快恢复

• 拥塞降到新ssthresh（而非1），因此叫快恢复。
• 在收到3个确认的时候就得到新ssthresh
• 用到快重传算法（见三.②）