三次握手四次挥手

OSI七层 TCP五层

7.应用层
6.表现层
5.会话层       5.应用层
4.传输层       4.传输层
3.网络层       3.网络层
2.数据链路层   2.数据链路层
1.物理层       1.物理层

应用层：http协议

保留后面的标志位中每一个位都有自己的作用


提前说明：
TCP是面向字节流的 而且为每一个字节都编号了
我们用seq来标记当前的报文第一个字节的序列号

• seq是看主人的 不同的主人seq的初始值都不同
  同一个主人的相邻两次请求都是 第一次seq=seq1 第二次seq=seq1+1
  如果不是两次相邻的请求 比如同一个主人上一次发送到v 这一次就要是v+1
• ack是看seq的 你是对那个请求发送确认帧 ack=seq+1

三次握手描述

• 第一次握手:
  客户端发送一个连接请求报文段 同步位SYN置1 发送序号seq为随机数x 因为还没有链接 所以客户端没有期待没有ACK
• 第二次握手：
  服务端接收到数据包后由标志位SYN=1知道客户端请求建立连接
  返回一个连接请求的确认报文段 SYN置1 分配缓存和变量 序号字节seq=y
  服务端期待客户端的序列号为seq+1确认位ACK=1 确认号字段ack=seq+1=x+1
• 第三次握手：
  客户端检验收到的服务端确认号ACK是否=1 检验ack是否x+1字节
  如果都有 万事俱备 发送确认的确认 发送数据 ACK=1 ack=seq+1=y+1
  但是此时的SYN=0 因为不需要再确认
  客户端发送的序号要在最开始的x基础上加一seq=x+1
  当服务端接收检查ACK 和 ack是否为Y+1也没问题 两边完成三次握手 开始正式传输

SYN洪范攻击

在第二次和第三次服务器和客户端都分配了缓存和变量
在第二次服务端给客户端发送 等待服务端的ack之前这段时间称为半连接

如果此时服务器等待客户端的确认帧的过程中
客户端有大量伪造的ip地址 又向服务端发送SYN请求连接（就是第一次握手）
造成服务端又确认连接请求 等待客户端确认的确认（第二次握手）
但是在第二次握手等待客户端的ACK的过程中 客户端中的ip地址就是捏造的 所以等不来真正的ACK 超时了服务端就又发送第二次握手 最后导致真正的第二次握手被挤出队列 导致系统瘫痪

四次挥手

FIN 结束位 请求释放连接
seq:报文段第一个字节的序号

• 第一次挥手：
  客户端向服务端发送释放连接请求 FIN置1 因为释放是随机的时间点你也不知道具体seq是多少 所以seq=u
• 第二次挥手
  服务端确认收到客户端的释放请求 ACK=1 ack=u+1
  但是在这期间服务端没有停止自己对客户端的传递 所以随机字节序号seq=v
• 第三次挥手
  因为TCP是全双工通信 所以只有一方的断开连接没有真正的断开 还要另一方也断 于是服务端发送释放连接请求 FIN=1 由于服务端还在不停的发送 所以服务端此时的seq也是一个随机的 seq=w 并且服务端还在期待客户端传递的u+1号字段 所以ack=u+1
• 第四次挥手
  客户端发送确认收到了服务端的释放请求的确定~
  ACK=1 ack=w+1 因为服务端自从发送了请求释放连接之后就再也没发送任何的字节 所以现在的字节seq=u+1

三次握手：
我来了 
                                         我同意你来 我也来了
我收到了你的同意 我开始发送数据喽

四次挥手：
我走了
                       知道了 我还有话要说
                       说完了 我也走了
好
    2MLS后真的走了