抓包整理————tcp 三次握手[九]

前言

简单抓包一下3次握手。

正文

握手的目标：

1. 同步sequence 序列化

初始化序列化ISN(Initial Sequence Number)

1. 交换tcp 通信参数

如MSS、窗口比例因子、选择性确认、指定校验和算法。这个后面讲。

简单的在linux 抓取一下:

这里面就是确认机制哈:

这上面标识说一下哈：s 就是syn的意思，然后这个.就是ack的意思。

然后这里有一个s.标识发送 syn 加 ack，所以不要认为一个包就是一个意思哈，可能包含几种意思，一般来说是两种。

为什么两边的seq 不一样呢？且他们为什么不从0开始呢？

这是因为网络中报文会延迟会重发也可能丢失造成的影响。（后面补系列会这个问题）

SYN：同步序列编号（Synchronize Sequence Numbers）。

握手的第一个报文:

握手的第二个报文:

第三次握手:

演示一下哈,给大家抓个包助助兴。

看这个我们的发起端口是61110，然后对方的目的端口是80。

发起这个握手请求。

然后看下被连接方在干啥。

然后连接方又发了一个ack过去:

这里看到一般发syn的时候一般有一个叫做options的，这个后面跟滑动窗口有关。

状态变迁:

这里说一下状态哈，大概连接的时候有下面几个状态：

1. closed
2. listen
3. syn-sent
4. syn-received
5. established

比如a 是客户端，b是服务端。

a 一开始是closed 状态，然后b是listen状态。

然后a主动发送sync，然后就变成了syn-send，b收到就变成了syn-received.

当a 收到sync+ack 就变成了established状态，b发送ack后也变成了established 状态。

这里讲一下syn洪流攻击的原理哈。

上面看到这个图，就是一直发送syn，然后对方就要发送给我syn+ack，但是我不回。

这样对方就要重新发，一直保持这个状态，或者超时。就是操作系统回这个syn+ack 是在一个队列里面，如果排队很长，自然就慢了。

这里想解释一下为什么3次握手的时候，为什么ack要加一，或者说为什么要消费掉一个序列号。

很多人解释是是因为发送方包含了SYN标志位或FIN标志位，认为标志位也是一种数据，但我感觉还是没有解释为什么要这么做。

假设a发送了一个sync包0为b，但是没有响应，然后又发了一个，b回了一个ack 为0 加他的sync假设是1000吧，这意味着下次a发送的还应该是0.

然后a 发送ack为1000给b，这个时候。这个时候第一个没有响应的包到了，那么这个时候b就不确认a的包，到底是想重新连接呢？还是说这是网络延迟包可以丢弃呢。

总之呢，就是为什么有序列号这个东西，就是为了让双方沟通起来是顺序的。

结

大概是整理了一下3次握手，下一节如何优化3次握手过程。