TCP看似复杂,其实可以归纳为以下5种报文:
(1)SYN
(2)Data (唯一携带用户数据)
(3)FIN
(4)Reset
(5)ACK
- 其中1、2、3分别为建立连接、数据传输、断开连接,这三种报文对方接收到一定要ACK确认,为何要确认,因为这就是可靠传输的依赖的机制。如果对方在超时时间内不确认,发送方会一直重传,直到对方确认为止、或到达重传上限次数而Reset连接。
- 4、5 为重置连接报文、确认ACK报文,这两种报文对方接收到要ACK确认吧?不需要!自然发送方也不会重传这2种类型的报文。
为何Reset报文不需要ACK确认?
因为发送Reset报文的一端,在发送完这个报文之后,和该TCP Session有关的内存结构体瞬间全部释放,无论对方收到或没有收到,关系并不大。
- 如果对方收到Reset报文,也会释放该TCP Session 的相关内存结构体。
- 如果对方没有收到Reset 报文,可能会继续发送让接收方弹射出Reset报文的报文,到最后对方一样会收到Reset 报文,并最终释放内存。
为何ACK报文不需要ACK确认?
这里的ACK报文,是指没有携带任何数据的裸ACK报文,对方收到这样的ACK报文,自然也不需要ACK。
否则,对方为了ACK己方的ACK,那己方收到对方的ACK,也要ACK对方的ACK,这就是一个死循环,永无止息。所以为了避免这个死循环,一律不允许ACK对方的裸ACK报文。
为什么TCP建立连接不是四次握手?
- A 发送SYN 报文给B,这是第一次报文交互。
- B发送ACK确认A的SYN报文,这是第二次报文交互
- B发送自己的SYN报文给A,这是第三次报文交互
- A需要ACK确认B的SYN报文,这是第四次报文交互
- 以上的演绎没有问题,但是报文2、3为何要分开发送呢?
- 增加了延迟不说,同时还白白浪费了网络的带宽,完全可以将报文2、3合并起来,不就是在报文2的ACK状态位的位置置“1”就结了吗?
一句话概括,TCP连接握手,握的是啥?
- 通信双方数据原点的序列号!
TCP作为一种可靠传输控制协议,其核心思想:既要保证数据可靠传输,又要提高传输的效率,而用三次恰恰可以满足以上两方面的需求!
TCP可靠传输的精髓:TCP连接的一方A,由操作系统动态随机选取一个32位长的序列号(Initial Sequence Number)
- 假设A的初始序列号为1000,以该序列号为原点,对自己将要发送的每个字节的数据进行编号,1001,1002,1003…,并把自己的初始序列号ISN告诉B,让B有一个思想准备,什么样编号的数据是合法的,什么编号是非法的,比如编号900就是非法的,同时B还可以对A每一个编号的字节数据进行确认。如果A收到B确认编号为2001,则意味着字节编号为1001-2000,共1000个字节已经安全到达。
- 同理B也是类似的操作,假设B的初始序列号ISN为2000,以该序列号为原点,对自己将要发送的每个字节的数据进行编号,2001,2002,2003…,并把自己的初始序列号ISN告诉A,以便A可以确认B发送的每一个字节。如果B收到A确认编号为4001,则意味着字节编号为2001-4000,共2000个字节已经安全到达。
为什么TCP建立连接不是两次握手?
- 因为双方都需要确认对方的起始序号! 这里必须需要两次握手了!
- 还有一次发起同步请求.