一 ISN序列号探究
本文主要探究'三次'握手建立TCP连接的'细节'
备注： 某些问题探究的'比较深入',当前用不到,暂时通过'链接'引入进来
吃水不忘挖井人： '小林 coding'① 初始序列号 ISN 是如何随机产生的
ISN: 初始化序列号 'Initial Sequence Number' 接收方和发送方都会'产生'
tcpdump -S: 指定'打印'每个监听到的数据包的TCP'绝对'序列号而'非相对'序列号
② 为什么每次建立 TCP 连接时,初始化的序列号都要求不一样呢
③ 为什么是三次握手？不是两次、四次？
④ 三次握手过程中状态变化
1、'客户端'状态变化
备注： client '主动'发送方
2、'服务端'状态变化
二 三次握手过程握手丢失
遗留： 三次握手'过程'中,不同场景'握手丢失'在'wiresahrk'以什么颜色'显示'?① 第一次握手丢失了,会发生什么
细节点： 在'第1次'的基础上又'重试'的次数,关注'等待'时间
内核参数： 'tcp_syn_retries'
场景： 假设 tcp_syn_retries 参数值为'3',探究当客户端的 SYN 报文一直在网络中'丢失'时过程
说明： 有时间通过'iptables'以及'wireshark'模拟看现象
SYN 报文什么时候情况下会被丢弃
② 第二次握手丢失了,会发生什么?
分析： 'SYN-ACK'丢失
1、 对于'客户端'的感知,是不是因为'第一次握手'的'SYN'报文丢失导致服务端没有回'SYN-ACK'
2、 对于'服务端'的感知,怎么还没有回我'ACK'确认报文,是不是第二次握手'SYN-ACK'丢失了
内核参数： 'tcp_synack_retries'
场景：假设'tcp_syn_retries'值为 1,'tcp_synack_retries'值为2,第二次握手'一直'丢失场景
++++++++++++++++ '具体过程' ++++++++++++++++
③ 第三次握手丢失了,会发生什么?
场景： 假设'tcp_synack_retries'参数值为 2,那么当第'三'次握手一直'丢失'时
++++++++++++++++ '具体过程' ++++++++++++++++
