抓包整理————tcp 三次握手[九]
前言
简单抓包一下3次握手。
正文
握手的目标：
- 同步sequence 序列化
初始化序列化ISN(Initial Sequence Number)
- 交换tcp 通信参数
如MSS、窗口比例因子、选择性确认、指定校验和算法。这个后面讲。
简单的在linux 抓取一下:
这里面就是确认机制哈:
这上面标识说一下哈：s 就是syn的意思，然后这个.就是ack的意思。
然后这里有一个s.标识发送 syn 加 ack，所以不要认为一个包就是一个意思哈，可能包含几种意思，一般来说是两种。
为什么两边的seq 不一样呢？且他们为什么不从0开始呢？
这是因为网络中报文会延迟会重发也可能丢失造成的影响。（后面补系列会这个问题）
SYN：同步序列编号（Synchronize Sequence Numbers）。
握手的第一个报文:
握手的第二个报文:
第三次握手:
演示一下哈,给大家抓个包助助兴。
看这个我们的发起端口是61110，然后对方的目的端口是80。
发起这个握手请求。
然后看下被连接方在干啥。
然后连接方又发了一个ack过去:
这里看到一般发syn的时候一般有一个叫做options的，这个后面跟滑动窗口有关。
状态变迁:
这里说一下状态哈，大概连接的时候有下面几个状态：
- closed
- listen
- syn-sent
- syn-received
- 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次握手过程。
