有连接，可靠传输，面向字节流
16位源端口号
16位目的端口号
4位首部长度
报头的长度，报头中包含了“选项” optional =>可选择的，0 - 15 ，4个字节，TCP 报头的最大长度是 60 字节
保留位（6位）UDP 想升级，非常费劲，就导致 UDP 的报文长度始终受到 64
KB 的限制。保留位，现在不使用，但是先占个位置，说不定以后就使用到了
6个最关键的标志位
可靠传输
什么是可靠传输？
可靠传输，是否可以做到数据的 100% 到达对方呢？不能做到的！！！
发送的数据，能够知道对方是否收到，就可以认为是“可靠传输”
1）如果知道对、对方收到了，传输成功
2）如果知道对方没收到（丢包），采取其他补救措施
核心机制一:确认应答
实现让发送方知道接受方是否收到数据
发送方发送了数据之后,接受方,一旦接收到了,就会给发送方返回一个"应答报文"告诉发送方"我已经收到了数据"
网络上会出现"后发先至"的情况
为了解决上述问题,就引入了"序号和确认序号"对于数据的传输进行标识
TCP 是字节流传输的
序号和确认序号是针对"字节"进行编号的
一个 TCP 数据报,包含多个字节,如何体现所有编号呢?
编号是连续递增的,要知道 TCP 载荷的第一个字节的编号是多少,后面的每一个字节的编号就都知道了
32 位序号和数据:填写数据报部分的第一个字节编号几就行了
同一个 TCP 连接,序号会连续累加,下一个数据报的序号在上一个数据报的最后一个的序号基础上继续递增
确认序号只在应答报文中生效
确认序号根据收到的数据的最后一个字节的序号进行加一来进行填充
这一位为 1 ,确认序号字段就会有效负责是属于"无效字段"
确认序号的含义:
1.所有 < 确认序号的数据,接收方已经收到了
2.发送方接下来应该是从确认序号的位置开始,继续发送数据
这样的规则,非常有用,会在后面的特性中,有所体会
确认应答,就是 TCP 实现可靠传输的,最关键机制之一
这个地方的长度有多少,就看你代码是怎么写的
确认应答,关键是,数据顺利到达,通过 ack 告知发送方
实际传输中,很有可能丢包的
TCP 核心机制二:超时从传
确认应答的重要补充,针对丢包的场景的
超时:发送方,判定是否出现丢包的条件
重传:发现数据丢包,就在发一次(概率性问题)
假设一个数据包,传输过程中,丢包的概率大概是 10%(相当大的数字)
连续传输两次,数据包至少一次到达对方的概率是多少?
1 - 10% * 10% => 99%
传输次数的增加,数据报到达对方的概率概率大幅度增加
计算机中,一般不喜欢"无限的等",最大等待时间"超时时间"