计算机网络 -- TCP的三次握手

计算机网络 -- TCP的三次握手

参考：https://blog.csdn.net/qq_38950316/article/details/81087809

一）、TCP协议的特点

定义：

1.是一个面向连接的、可靠的、基于字节流的传输层协议。

2.将应用层的数据分割成报文段并发送给目标节点的TCP层。

3.数据都有序号，对方收到则发ACK确认，没有则重传。

4.使用校验和来校验数据在传输过程中是否有误。

二）、TCP报文头的结构

TCP报文头结构如下：

请求报文头由4个字节，32位二进制数组成。

第一层：

源端口 目的端口 （各占16位）

第二层

序列号（占32位）

官方作用：用来标记数据段的顺序，Tcp把连接发送的所有字节数据都编上号，第一个字节序号由本地随机产生，给字节编上号后，就给每一个报文段编上号，每个报文段的编号就是该报文段第一个字节的编号。

个人理解： tcp协议的数据段由32位二进制组成，给数据段的所有字节数据都编上号，TCP将数据分割成报文段分发的目标节点的TCP层，因为给每个字节都编上了序号，那么，每一个数据段都有其对应的序号啦，即该数据段的第一个字节所对应的编号就是该数据的的编号，这样有利于接收方对数据的重排，保证的接收数据的可靠性。

第三层

ack确认号（占32位）： 期望收到下一个字节的编号。

例: 客户端A向 -- >服务端 B发送了一个报文段，该报文段的序号为301， 长度为200，服务端B成功接收了改报文段，响应客户端确认收到将ack = 501的值传给客户端A,期望下一次收到的报文段的字节编号从502开始。

第四层

偏移量 保留 URG/ACK/PSH/RST/SYN/FIN (占16位) 窗口（占16位）

URG: 紧急指针， 0：有效 1：忽略紧急指针

ACK: 确认标志 ，1: 确认有效， 0：报文中不含确认信息，忽略确认字段。

PSH: push标志，接收方接收到报文后应该尽快交付给用用程序，而不是在缓冲区 中排队。

RST: 重置连接标志，重置错误连接。

SYN: 同步连接序号，用于建立连接，SYN =1, ACK = 0（连接请求报文段） 没有使 用请求捎带的确认方式; SYN =1, ACK =1 （连接接受报文段）使用连接请求捎 带的连接方式。

第五层

检验和(占16位) 紧急指针(占16位)

第六层

可选项

三）、TCP的3次握手

TCP三次握手的过程

1.客户端A主动打开处于closed状态，服务端B被动打开处于closed状态

2.服务进程创建传输控制块等待客户请求，此时服务器处于监听状态

3.客户端A创建传输控制块，发送连接请求报文，此时客户端进程进入同步已发送 状态SYN-SEND

​ 请求报文内容：SYN =1, seq = x ；(第一次握手)

​ 特点： 该请求报文并没有携带数据，但是服务端也消耗了一个字节，当服务端发 回确认报文时，期待收到下一个字节的编号， ack = x + 1;

​ SYN: 同步连接序号，

​ seq : 报文段的第一个字节的编号，刚开始的seq是随机的一个数

4.服务器同意连接，并发送一个确认报文，此时服务器进入同步收到状态SYN- RCVD

​ 确认报文内容：SYN =1, ACK = 1, seq = y, ack = x+1;（第二次握手）

​ ack: 期待收到下一个字节的编号

​ seq：是服务端响应报文段的字节编号

5.客户端进入连接状态ESTAB-LISHED

​ 连接报文内容：SYN =1, ACK =1, seq = x +1, ack = y+1;（第三次握手）

6.服务端进入到连接状态ESTAB-LISHED

四）、三次握手的常见面试题

1.说说TCP的3次握手

答：第一次握手，客户端向服务端发送请求报文SYN =1,seq =1,之后客户端进入 SYN-SEND（同步已发送状态)。

​ 第二次握手，服务端接受到了客户端的请求报文，向客户端发送确认报文， SYN =1, ACK=1, seq = y, ack = x + 1, 虽然客户端的请求报文并没有携带数据， 但服 务端还是消耗了一个字节，所以ack = x +1，此时服务端处于SYN- RCVD（同步收到状态）。

​ 第三次握手，客户端接受到确认报文后向服务端发送连接报文，SYN =1,ACK =1,seq = x+1, ack = y+1, 客户端也消耗了服务端一个字节因此ack =1。

2.为什么要建立三次握手才能进行连接

答：为了初始化Sequence Number的值。

3.首次握手的隐患，SYN超时的问题

SYN超时的场景：

服务端接收到客户端SYN,回复SYN-ACK时未收到ACK确认，即服务端接收到客户的请求报文，回复SYN-ACK后，刚好，Client下线了，服务端接受不到客户端的ACK确认，此时，连接处于中间状态，既不成功也没有失败，此时服务端会不断重发SYN-ACK直至超时才会断开连接，在liunx系统下默认重发事务次数为5次，重发的时间间隔一次为1,2,4,816s 一共为31s，在第5次发送出去后还要等待32s才能判定超时，因此在liunx系统下默认等待时间为63s.

SYN超时引发的问题：

SYN-flood问题，当有一些恶意程序向服务器发送了一个连接请求后，就直接下线，导致服务器发送SYN-ACK不能接收到ACK确认 ，服务器进入了等待状态，耗尽服务器的SYN连接队列,使得正常的连接请求不能处理。

解决：当SYN队列满了之后,通过tcp_synCookies参数回发一个SYN cookies，TCP会根据源地址端口、目标地址端口和时间戳，打造出一个特别的seqence Number,即syn-cookies，若为正常连接，client端会直接回发一个SYN cookies，直接建立连接,如果是恶意连接，则不会有任何响应。

4.建立连接，Client出现了故障改怎么办

连接成功后，客户端突然出现了故障。

答: TCP的保活机制。

设置保活时间，keep alive time,在这段时间内，连接处于非活动状态，开启保活功能的一方会向对象发送探测保活功能，如果发送方没有收到确认报文，在我们设置好的保活时间间隔，keep alive time interval 继续发送探测保活报文，直至发送次数达到保活探测数，即等于keep alive count，此时对方主机确认为不可达，连接也将被中断。