传输层 TCP连接管理 建立TCP连接/状态/变迁

传输层 TCP连接管理 建立TCP连接/状态/变迁

TCP是面向连接的协议，所以使用TCP的时候要先建立连接，建立连接是通过三次握手来实现的。

三次握手的目标

同步 Sequence 序列号

初始序列号 ISN（Initial Sequence Number）

服务器端和客户端之间的所使用的seq都是不同的，所以在握手当中的三次都要分别交换这个isn。

交换 TCP 通讯参数

如 MSS（最大报文段）、窗口比例因子（想扩大滑动窗口的时候）、选择性确认（更有效的重传丢失的报文）、指定校验和算法

三次握手

client首先将它的ins发给server，server收到syn之后，它要回一个ack，server也要发自己的ins让客户端知道我的序列号在哪，当然客户端也要回一个ack。

第二步可以将syn/ack放在一个报文当中，一次性的发给client。

上面就是三次握手，三次握手当中使用了syn，就是同步的意思，也使用了ack确认。

-c只抓取3个包，因为3个包正好是前面的3次握手，-S用绝对序列号替换相对序列号。

这里client传输了它的isn，seq 1676510846，给到了server，server会回加1，ack 1676510847，client收到这个报文之后就知道server确认了，同时server也发送了自己的isn，seq 715862251，client通过最后一个ack通过对seq 715862251确认+1，那么就是3次握手。

这个isn seq是随机的，每次都是不同的。

三次握手(1)：SYN 报文

syn要在标记位的第七位置为1，那么就代表这个一个syn报文。在seq当中填入我们的序列号码，也就是我们的isn。

三次握手(2)： SYN/ACK 报文

在第二个报文当中其实就是ack+syn，这里面重点关注4个地方。

序列号，也就是server中使用的isn，确认号码就是我收到client的isn+1，为了让确认号码有效，我要在flag当中第四位ACK置为1，第七位SYN置为1.

三次握手(3)： ACK 报文

最后一个ACK报文在ACK位置置为1，让确认号码有效。

TCP的连接建立

应用程序在通信的时候，也即是进程在通信的时候，浏览器访问web站点，HTTP协议要想发送的话，我这个计算机要先去调用TCP协议，先建立连接，发送tcp建立连接的请求，服务端给我一个确认，我再给服务器一个确认。需要发三个数据包。

建立了TCP连接之后，再发送B，因而产生错误。比如下面这种情况：A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。本来这是一个早已失效的报文段。但是 B 收到此失效的链接请求报文段后，就误认为 A 又发出一次新的连接请求。于是就向 A 发出确认报文段，同意建立连接。 对于上面这种情况，如果不进行第三次握手，B 发出确认后就认为新的运输连接已经建立了，并一直等待 A 发来数据。B 的许多资源就这样白白浪费了。 如果采用了三次握手，由于 A 实际上并没有发出建立连接请求，所以不会理睬 B 的确认，也不会向 B 发送数据。B 由于收不到确认，就知道 A 并没有要求建立连接。

TCP的连接建立

客户端和服务端建立TCP连接的时候，这样的数据包是不带数据的，然后它还有个特点，SYN叫做同步标记位，syn这个标记位为1，ack为确认，确认为0说明，说明tcp首部确认的字段是无效的。

确认通常就是告诉对方收到了第多少个数据包，你该发多少个数据包，因为客户端从来没有收到服务器这边的数据包，所以这个确认号就没有意义，所以这个标记位为0。

参数可以看到最大传输报文段mss 1460。

允许选择性确认。

接受窗口是64240。

上面tcp建立请求包含了上面这些信息，接受窗口是多大，最大报文是多大，是不是支持选择性确认。

上面是首部+选项部分，没有数据部分。

上面是建立连接的请求。

建立TCP连接确认

ack syn标记位为1，说明ack确认标记位起作用了，说明确认字段有意义，可以看到序号为0，确认号为1，告诉客户端1以前的字节都收到了。

下面是服务器的参数。

确认的确认

这是第三个包，ack标志位为1，syn标记位为0了，也就是说只有前面两个数据包请求和确认的syn标记位才为1。

TCP三次握手

来看看客户端和服务端状态。

一开始客户端这里tcp连接是close的，发一个建立tcp连接的请求，syn标记位为1，ack标记位为0，序号是客户端随机给的。

服务器收到之后是listen状态，监听客户端的请求，之后变为syn received状态，之后给客户端发送确认，标记位都为1，y是服务器设定的一个序号，比较大的随机数，确认号为x+1，告诉客户端x收到了，你该发x+1个字节了。

客户端收到确认之后状态为establish建立连接。

之后客户端再给它发确认的确认，ACK大写的代表标记位，小写的代表序号和确认号。

当执行三次握手的时候，客户端和服务器关于这条连接的状态都在发生变迁，当理解了tcp状态是如何变迁的时候，就能够更有效的定位一些复杂的网络问题。

下面是三次握手当中所涉及的5种状态，

最初大家都是close的状态，其中服务器需要监听80 443等端口，所以处于listen状态，在三次握手完成之后，大家都需要进入establish的状态，对于状态怎么查看呢，使用netstat工具来查看。

[root@master networking]# netstat -anp | grep tcptcp 0 0 169.254.25.10:9254 0.0.0.0:* LISTEN 4505/kube-proxy tcp 0 0 192.168.111.6:2379 0.0.0.0:* LISTEN 1781/etcd tcp 0 0 127.0.0.1:2379 0.0.0.0:* LISTEN 1781/etcd tcp 0 0 192.168.111.6:2380 0.0.0.0:* LISTEN 1781/etcd tcp 0 0 0.0.0.0:31759 0.0.0.0:* LISTEN 4505/kube-proxy 1091/master tcp 0 0 169.254.25.10:50542 169.254.25.10:9254 TIME_WAIT - tcp 0 0 192.168.111.6:2379 192.168.111.6:50166 ESTABLISHED 1781/etcd tcp 0 0 169.254.25.10:50642 169.254.25.10:9254 TIME_WAIT - tcp 0 0 192.168.111.6:49878 192.168.111.6:2379 ESTABLISHED 2595/kube-apiserver tcp 0 0 192.168.111.6:50118 192.168.111.6:2379 ESTABLISHED

可以看到有listen的状态，有establish的状态，在介绍4次握手关闭的时候，往往会看到大量time_wait状态。

回过头来看三次握手的状态变迁，首先客户端发起了syn，客户端立刻就会进入syn-sent的状态，在netstat当中很难看到这个状态，因为当我们收到syn+ack之后我们就会从syn-sent进入到establish状态了，这个过程可能非常当能只有几百毫秒，所以很难观察到这样一个状态。

当服务器收到syn之后，它会进入syn-received的状态，这个状态会一直延续下去，直到客户端返回ack，那么也会进入establish状态。

从syn-send和syn-received可以很清楚的看到，就是看这个syn有没有发，还是说我收到了，以此来命名的。

有些攻击者就会不使用操作系统内核提供的tcp栈，而是自己简单的构造出来syn的帧，发给了server之后，它却不发ack，使得大量的连接都处于syn-received的状态，以至于占用了server太多的资源，使得正常的连接无法正常的建立，这就是syn的一种攻击方式。

两端同时发送SYN：双方使用固定源端口且同时建连接

TCB： Transmission Control Block，保存连接使用的源端口、目的端口、目的 ip、序号、应答序号、对方窗口大小、己方窗口大小、tcp 状态、tcp 输入/输出队列、应用层输出队列、tcp 的重传有关变量等（保存连接当中使用的各种状态信息，比如我的端口和对方的端口，等）

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。