第十天：TCP序号_确认号 建立连接

第十天：TCP序号_确认号 建立连接

在建立HTTP请求之前需要经历三次连接

​ 这就是三次握手，我主动发送数据包给你，我想和你建立连接，然后服务器也给我一个回复，ACK就是回应，然后我再向你发送一次建立请求，通过后就开始传送数据。

就像上图一样，值得注意的是，SYN（同步）只有前两次都是1，其余都是0

执行完三次握手后，就会发送HTTP请求

当所有数据完成后，就会发送200，表明服务器发送完成

序号

知道你的序号和长度，那么我返回的长度就是ACK：序号+数据长度

假设每发一个包，服务器就会给一个响应。序号和确认号是相对值。

我们看到的是1，实际上他是把一个真实的大数字放在序号号确认号

我们现在看看原生的值，一开始我们再建立连接的时候就要确定，那是怎么确认的？

在建立连接时，除了会发送SYN，还会发送一个序号初始值，从第一次握手就会发送一个序号初始值，而这个序号是随机生成的。当第二次握手时，服务器也会向客户端发送一个序号初始值，也是随机生成。

所以实际我们的序号都是相对值，通过这样的方式可以保护网络安全。

服务器和客户端都有自己的序号初始值，由于都是随机生成，一般着两个序号是不一样的

接下来，我们具体来分析一下这9步

第1步

建立连接的时候，SYN为0，只有TCP的头部，发送的第一部分只有头部。

当ACK为0时，ack的数据数据都没有意义。

第2步

为什么这里的ACK为1？

实际上ACK是收到数据后的回应，因为我之前收到的数据是0，所以我这里收到的ACK就是1

第3步

此时此刻的SYN为0，这里的ack为1是为了响应上一次的ACK

第四步

为什么这里ACK为什么还是1？，因为第三次和第四次都是客服端给服务端发数据，因为上次一次服务器发送给我的数据是0，所以ACK是1

建立连接之后，发送HTTP请求，前三次的数据部分都是0，但是从第四次开始，就有数据了，这里的数据实际上就是HTTP数据部分

第五步

首先看ACK，我们先看第四次，我们发现客服端给我们的数据是K个字节，说明我们收到了K个字节，所以这里的字节就是k+1个字节，希望对方从k+1开始发送

然后我们来看看seq，因为之前没有数据，肯定就是从1开始

第六步

为什么这里的ack还是k+1,因为ACK是对上一次发送的数据的回应，很明显，这里还是K+1，

seq为什么变成了b1+1了呢

这里是第二个包的序号绝对是前面发送数据包的长度+1。

第七步

第8步

这几步与第六包差不多。

第九步

当数据发送完成后，客服端回应服务端，ACK：b1+b2+b3+b4+1，表示收到了这么多字节，并且希望从这数据发送

SYN表示同步请求，表示服务器第一次发送东西给我；我第一次发送东西给服务器，SYN都为1，也是在这个时候才会给出原生的初始值

现在我们带上真实初始序号来看看过程

在这里值得注意的是，客服端发出的序号s1和等会服务器返回给客户端的序号也是s1，同理服务器发出的序号S2，等会客服端返回的序号也是S2，这两者是各干各的

初始值=原生值-相对值

我们再来来回顾一下，来看看这个图

这个就是这个过程

建立连接—三次握手

状态解读

CLOSED:client处于关闭状态

LISTEN:server处于监听状态，等待client连接

SYN-RCVD:表示server接收到了SYN报文

SYN-SENT:表示client已发送SYN报文，等待server的第2次握手

ESTABLISHED:表示连接已经建立

前两次握手的特点

• SYN都设置为1

• 数据长度都为0

• TCP头部长度一般都为32字节

  固定头部：20字节

  选项部分：12字节

• 双方会交换确认一些信息

  比如MSS、是否支持SACK（选择性确认）、window scale（窗口缩放系数）

  这些数据都会放在头部的选项部分

为什么一定要三次握手？两次不行吗?

我想和你建立连接，然后你回应了我说，没问题，我也想和你连接，这样的方式从逻辑上也没有问题，那究竟是为什么呢？

主要目的：防止server端一直等待，浪费资源

如果只建立两次握手，可能会出现的情况

• 假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server

• 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出一个新的连接请求

• 于是server就像client发出报文确认报文段，同意进建立连接

• 如果不采取三次握手，那只要server发出确认，新的连接就建立了

• 由于现在client并没有想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据

采取三次方式的方法就可以防止上述现象的发生

第三次失败了会怎么处理?

此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包

如果server多次发送重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭