51-http-4-TCPIP三次握手

概述

目的是为了保证可靠的通信

三个版本的解释

版本一

简单说,让双方都证实对方能发收。
知道对方能收是因为收到对方的因为收到而发的回应。
具体:
1:A发,B收, B知道A能发
2:B发,A收, A知道B能发收
3:A发,B收, B知道A能收


tcp三次握手是tcp的建立连接的过程,所谓连接就是客户端知道服务端的发送和接收能力是否正常,服务端知道客户端的发送和接收能力是否正常。

第一次握手,客户端向服务端发送报文,服务端接收到信息之后,知道了客户端的发送能力正常

第二次握手,服务端向客户端发送报文,客户端接收到了信息之后,知道了服务端的发送和接收能力都正常

第三次握手,客户端再向服务端发送报文,服务端接收到信息之后,知道了客户端的发送和接收能力都正常

至此,三次握手完成,客户端和服务端都确定了双方的发送和接收能力,可以进行数据传输了

版本二:图解HTTP

按层次分,TCP 位于传输层,提供可靠的字节流服务。

所谓的字节流服务(Byte Stream Service)是指,为了方便传输,将大块数据分割成以报文段(segment)为单位的数据包进行管理。而可靠的传输服务是指,能够把数据准确可靠地传给对方。一言以蔽之,TCP 协议为了更容易传送大数据才把数据分割,而且 TCP 协议能够确认数据最终是否送达到对方。

确保数据能到达目标

为了准确无误地将数据送达目标处,TCP 协议采用了三次握手(three-way handshaking)策略。用 TCP 协议把数据包送出去后,TCP不会对传送后的情况置之不理,它一定会向对方确认是否成功送达。握手过程中使用了 TCP 的标志(flag) —— SYN(synchronize) 和ACK(acknowledgement)。

发送端首先发送一个带 SYN 标志的数据包给对方。接收端收到后,回传一个带有 SYN/ACK 标志的数据包以示传达确认信息。最后,发送端再回传一个带 ACK 标志的数据包,代表“握手”结束。

若在握手过程中某个阶段莫名中断,TCP 协议会再次以相同的顺序发送相同的数据包。

除了上述三次握手,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连接握手,握的是啥?

通信双方数据原点的序列号!

以此核心思想我们来分析二、三、四次握手的过程。

A <-------> B

四次握手的过程:

1.1 A 发送同步信号SYN + A'sInitial sequence number

1.2 B 确认收到A的同步信号,并记录A's ISN 到本地,命名 B's ACK sequence number
**
1.3 B发送同步信号
SYN** + **B's Initial sequence number
**
1.4 A确认收到B的同步信号,并记录B's ISN 到本地,命名 A's ACK sequence number

很显然1.2和1.3 这两个步骤可以合并,**只需要三次握手,**可以提高连接的速度与效率。

二次握手的过程:

2.1 A 发送同步信号SYN + A'sInitial sequence number

2.2 B发送同步信号SYN + B'sInitial sequence number + B's ACK sequence number

这里有一个问题,A与B就A的初始序列号达成了一致,这里是1000。但是B无法知道A是否已经接收到自己的同步信号,如果这个同步信号丢失了,A和B就B的初始序列号将无法达成一致。

于是TCP的设计者将SYN这个同步标志位SYN设计成占用一个字节的编号(FIN标志位也是),既然是一个字节的数据,按照TCP对有数据的TCP segment 必须确认的原则,所以在这里A必须给B一个确认,以确认A已经接收到B的同步信号。

有童鞋会说,如果A发给B的确认丢了,该如何?
A会超时重传这个ACK吗?不会!TCP不会为没有数据的ACK超时重传

那该如何是好?B如果没有收到A的ACK,会超时重传自己的SYN同步信号,一直到收到A的ACK为止。

补充阅读

第一个包,即A发给B的SYN 中途被丢,没有到达B

A会周期性超时重传,直到收到B的确认

第二个包,即B发给A的SYN +ACK 中途被丢,没有到达A

B会周期性超时重传,直到收到A的确认

第三个包,即A发给B的ACK 中途被丢,没有到达B

A发完ACK,单方面认为TCP为 Established状态,而B显然认为TCP为Active状态:

a. 假定此时双方都没有数据发送,B会周期性超时重传,直到收到A的确认,收到之后B的TCP 连接也为 Established状态,双向可以发包。

b. 假定此时A有数据发送,B收到A的 Data + ACK,自然会切换为established 状态,并接受A的Data。

c. 假定B有数据发送,数据发送不了,会一直周期性超时重传SYN + ACK,直到收到A的确认才可以发送数据。


记得第一次看TCP握手连接的时候,有同样的疑问,我的疑问是,为何不是两次呢?

后来随着对网络的理解深入,明白TCP报文是交由IP网络来负责运输,IP网络并不能保证TCP报文到达目的地,既然IP网络是指望不上了,那TCP就自力更生吧,TCP必须依赖自身的努力来保证数据传输的可靠。

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连接应该是四次消息交互啊。

1.A 发送SYN 报文给B,这是第一次报文交互。

2. B发送ACK确认A的SYN报文,这是第二次报文交互

3. B发送自己的SYN报文给A,这是第三次报文交互

4. A需要ACK确认B的SYN报文,这是第四次报文交互

以上的演绎没有问题,但是报文2、3为何要分开发送呢?增加了延迟不说,同时还白白浪费了网络的带宽,完全可以将报文2、3合并起来,不就是在报文2的ACK状态位的位置置“1”就结了吗?

这就是三次消息交互的由来!

推荐阅读

车小胖谈网络